problem with a cobalt RaQ550 system and DMA (Serverworks OSB4 in impossible state)

Hello,

I'm trying to install Debian on 4 RaQ550 with each 2 80GB disks. All seems OK with 3 of RaQ, but with one, it crash when I put the two disks in a RAID1 meta device. In fact, it as crash at about 6% before the 70GB partition is fully synchronized.

The error message is:

===================================================================
Serverworks OSB4 in impossible state.
Disable UDMA or if you are using Seagate then try switching disk types on this controller. Please report this event to [email protected]
OSB4: continuing might cause disk corruption.
===================================================================

I have also send the same email as this one to [email protected].

After some search, it seems I must enable MWDMA for my disks. (ref:
http://www.cs.helsinki.fi/linux/linux-kernel/2002-33/0836.html )

Here is the configuration : 2 IDE 80GB disks, one on hda, one on hdc. The kernel is the stock 2.4.20, with cobalt patches. The cobalt patches don't modify the drivers/ide/serverworks.c.

IDE part of lspci -v:

00:0f.1 IDE interface: ServerWorks CSB5 IDE Controller (rev 92) (prog-if 8f [Master SecP SecO PriP PriO])
Subsystem: Sun Microsystems Computer Corp.: Unknown device c000
Flags: bus master, medium devsel, latency 64
I/O ports at fcd8 [size=8]
I/O ports at fcd4 [size=4]
I/O ports at fcc8 [size=8]
I/O ports at fcc4 [size=4]
I/O ports at fcb0 [size=16]
I/O ports at fcac [size=4]

/proc/ide/hda and /proc/ide/hdc say it's a ST380021A. (I have no physical access to the system now...)

I have try to set the DMA of the disks with:

    hdparm -X66 -d 1 /dev/hda
    hdparm -X66 -d 1 /dev/hdc

but this has cause a direct hangup (with the same message "Serverworks OSB4 in impossible state...."). Maybe I don't use correctly hdparm, as this is my first attempt with it.

At this time, I have disabled the dma with:
hdparm -d 0 /dev/hda
hdparm -d 0 /dev/hdc
and the sync in in the way (but say we need about 6 hours to finish, comparing to the unmodifed test giving about 1 hour).

So my questions are :

- what can I do ?
- may this problem come also with the others RaQ we have (as far as I know, they are the same, and they are ordered at the same time)
- is the system safe without dma ?

Thanks in advance for any help, or any pointer to a solution. (Of course, I can apply a patch to the kernel if this may correct the problem).

Olivier

Olivier Bornet                 |      français : http://puck.ch/f
Swiss Ice Hockey Results       |      english  : http://puck.ch/e
http://puck.ch/                |      deutsch  : http://puck.ch/g
[email protected]         |      italiano : http://puck.ch/i
Get my PGP-key at http://puck.ch/pgp or at http://wwwkeys.pgp.net

Bad block I think. Its a bug fixed in 2.4.21pre. It trips a sanity check for an OSB4 bug inadvertantly. 2.4.21pre handles CSB5 with full UDMA and OSB4 in MWDMA2 without tripping wrongly.

If your chipset is CSB5 you can also just comment out the check and rebuild

Alan

Hi Alan,

At this time, I have compiled and installed a 2.4.20-ac2 + some cobalt patches. Is the bug also fixed in 2.4.20-ac2, or must I rebuild the 2.4.20 with the check commented out ?

(currently, the sync of the partition is in the way with the ac2 kernel... just started... need about 100 minutes to finish...).

I will comment out the check tomorrow if this is needed.

Thanks for your help, and keep up the good work.

Olivier

Olivier Bornet                 |      français : http://puck.ch/f
Swiss Ice Hockey Results       |      english  : http://puck.ch/e
http://puck.ch/                |      deutsch  : http://puck.ch/g
[email protected]         |      italiano : http://puck.ch/i
Get my PGP-key at http://puck.ch/pgp or at http://wwwkeys.pgp.net

Hi Olivier,

There is an interaction problem between the Serverworks IDE controller and some Seagate BlockPoint drives. They aren't handling the bus throttling correctly on ATA bus writes and are sometimes overflowing their FIFOs.

The CSB5 in UDMA mode 5 sends 3 words after the drive de-asserts DDMARDY- (per ATA spec section 9.14.3.2) but these drives sometimes have problems when the three extra words are sent and overflows its FIFO. Other IDE controllers only send 2 extra words and don't cause this to happen.

The only work around we have found is to limit these drives to ATA mode 4. Supposedly newer Seagate firmware for these drives will report only UDMA mode 4 capable, but for earlier drives (like those probably found in your raq550) try this patch against 2.4.20.

-duncan

@@ -100,6 +100,12 @@
 #include <linux/stat.h>
 #include <linux/proc_fs.h>
 
+const char *bad_ata100[] = {
+	"ST340016A",
+	"ST380021A",
+	NULL
+};
+
 static struct pci_dev *bmide_dev;
 static byte svwks_revision = 0;
 

@@ -107,6 +113,14 @@
 extern int (*svwks_display_info)(char *, char **, off_t, int); /* ide-proc.c */
 extern char *ide_media_verbose(ide_drive_t *);
 
+static int check_in_drive_lists (ide_drive_t *drive, const char **list)
+{
+	while (*list)
+		if (!strcmp(*list++, drive->id->model))
+			return 1;
+	return 0;
+}
+
 static int svwks_get_info (char *buffer, char **addr, off_t offset, int count)
 {
 	char *p = buffer;

@@ -420,7 +434,8 @@
 	int ultra100 	= (ultra66 && svwks_revision >= SVWKS_CSB5_REVISION_NEW) ? 1 : 0;
 	byte speed;
 
-	if ((id->dma_ultra & 0x0020) && (udma_66) && (ultra100)) {
+	if ((id->dma_ultra & 0x0020) && (udma_66) && (ultra100) &&
+	    !check_in_drive_lists(drive, bad_ata100)) {
 		speed = XFER_UDMA_5;
 	} else if (id->dma_ultra & 0x0010) {
 		speed = ((udma_66) && (ultra66)) ? XFER_UDMA_4 : XFER_UDMA_2;

Hi Duncan,

Thanks ! This is the solution. I have applied the patch, and the sync was now OK after about 1 hours for the 70 GB.

Is this patch already applyed on the 2.4.21-pre kernels ? If not can someone apply it ?

One more time, thanks for your help.

Olivier

Olivier Bornet                 |      français : http://puck.ch/f
Swiss Ice Hockey Results       |      english  : http://puck.ch/e
http://puck.ch/                |      deutsch  : http://puck.ch/g
[email protected]         |      italiano : http://puck.ch/i
Get my PGP-key at http://puck.ch/pgp or at http://wwwkeys.pgp.net

Hi all,

I reply to myself, after having test this solution.

The 2.4.20-ac2 patched kernel help a little : the system don't crash anymore. But the disk is marked as defective, and is removed from the raid1 metadevice.

One other problem with the -ac2 is the speed for the rebuild : it seems to be 2 times slower than with the Ducan patch. (about 2 hours instead of 1 hour).

So, my solution is to use the patch from Ducan. I hope it (or a derivative form of it) will be included in the next kernel releases.

Good day, and thanks all for the help.

Olivier

Olivier Bornet                 |      français : http://puck.ch/f
Swiss Ice Hockey Results       |      english  : http://puck.ch/e
http://puck.ch/                |      deutsch  : http://puck.ch/g
[email protected]         |      italiano : http://puck.ch/i
Get my PGP-key at http://puck.ch/pgp or at http://wwwkeys.pgp.net

Here is a 2.4.21-rc1 version of the patch, with a few modificaions due to the changes in IDE..

Actually UDMA mode detection is not working at all for CSB5 in 2.4.21-rc1 because svwks_revision variable is set in __init function so was reading as 0 in svwks_ratemask(). This made it think UDMA mode 2 was the max supported, when in reality new revisions do UDMA mode 5 and old revisions are mode 4 max.

The bad_ata100 list has been extended to include the whole family of Barracuda ATA IV drives; we only shipped the 80gb and 40gb models from that series so the others were not listed before.

-duncan

diff -ruN linux-2.4.21-rc1.orig/drivers/ide/pci/serverworks.c linux-2.4.21-rc1/drivers/ide/pci/serverworks.c
@@ -203,11 +203,22 @@
 }
 #endif  /* defined(DISPLAY_SVWKS_TIMINGS) && defined(CONFIG_PROC_FS) */
 
+static int check_in_drive_lists (ide_drive_t *drive, const char **list)
+{
+	while (*list)
+		if (!strcmp(*list++, drive->id->model))
+			return 1;
+	return 0;
+}
+
 static u8 svwks_ratemask (ide_drive_t *drive)
 {
 	struct pci_dev *dev     = HWIF(drive)->pci_dev;
 	u8 mode;
 
+	if (!svwks_revision)
+		pci_read_config_byte(dev, PCI_REVISION_ID, &svwks_revision);
+
 	if (dev->device == PCI_DEVICE_ID_SERVERWORKS_OSB4IDE) {
 		u32 reg = 0;
 		if (isa_dev)

@@ -221,13 +232,15 @@
 		/* Check the OSB4 DMA33 enable bit */
 		return ((reg & 0x00004000) == 0x00004000) ? 1 : 0;
 	} else if (svwks_revision < SVWKS_CSB5_REVISION_NEW) {
-		return 1;
+		return 2;
 	} else if (svwks_revision >= SVWKS_CSB5_REVISION_NEW) {
 		u8 btr = 0;
 		pci_read_config_byte(dev, 0x5A, &btr);
-		mode = btr;
+		mode = btr & 0x3;
 		if (!eighty_ninty_three(drive))
 			mode = min(mode, (u8)1);
+		if (mode == 3 && check_in_drive_lists(drive, svwks_bad_ata100))
+			mode = 2;
 	}
 	if (((dev->device == PCI_DEVICE_ID_SERVERWORKS_CSB6IDE) ||
 	     (dev->device == PCI_DEVICE_ID_SERVERWORKS_CSB6IDE2)) &&

diff -ruN linux-2.4.21-rc1.orig/drivers/ide/pci/serverworks.h linux-2.4.21-rc1/drivers/ide/pci/serverworks.h
@@ -11,6 +11,16 @@
 #define SVWKS_CSB5_REVISION_NEW	0x92 /* min PCI_REVISION_ID for UDMA5 (A2.0) */
 #define SVWKS_CSB6_REVISION	0xa0 /* min PCI_REVISION_ID for UDMA4 (A1.0) */
 
+/* Seagate Barracuda ATA IV Family drives in UDMA mode 5
+ * can overrun their FIFOs when used with the CSB5 */
+const char *svwks_bad_ata100[] = {
+	"ST320011A",
+	"ST340016A",
+	"ST360021A",
+	"ST380021A",
+	NULL
+};
+
 #define DISPLAY_SVWKS_TIMINGS	1
 
 #if defined(DISPLAY_SVWKS_TIMINGS) && defined(CONFIG_PROC_FS)

Oops, this analysis is wrong.. The svwks_revision variable is set in the init_chipset_svwks() function, which doesn't appear to ever get called because dev->irq==0. The init_chipset function is also responsible for the call to ide_pci_register_host_proc(), so since it isn't being called there is no /proc/ide/svwks.

I think for Serverworks IDE you will never get a valid dev->irq out of the pci config register, so maybe should there still be a call to d->init_chipset in this block from drivers/ide/setup-pci.c:

  } else if (!pciirq) {
      if (noisy)
          printk(KERN_WARNING "%s: bad irq (%d): will probe later\n",
                 d->name, pciirq);
      pciirq = 0;
  }

-duncan

The revision id is read when we init_chipset_svwks, which comes from the PCI setup. If the chip is in legacy mode we call init chipset early on regardless. If it is in native mode it gets called too and we ignore its view of the IRQ (since thats now PCI defined).

Yeah I saw that after I hit send, but for serverworks the init_chipset is not always called because it can fall into a corner case when in native mode because the PCI interrupt pin register is hardwired to zero (don't ask me why...) so it follows a codepath in do_ide_setup_pci_device() where init_chipset isn't called.

This patch adds the function call, which fixes the svwks_revision variable and the missing /proc/ide/svwks:

@@ -609,7 +609,7 @@
                if (noisy)
                        printk(KERN_WARNING "%s: bad irq (%d): will probe later\n",
                                d->name, pciirq);
-               pciirq = 0;
+               pciirq = (d->init_chipset) ? d->init_chipset(dev, d->name) : 0;
        } else {
                if (d->init_chipset)
                        d->init_chipset(dev, d->name);

Because the max supported mode for CSB5 < rev 0x92 is udma 4 (=2), not udma 2 (=1).

-duncan

That would imply a problem in the PCI layer, since the IRQ should have been assigned, and if the IRQ is not assigned we can't use the device.

I'll take a look.

It might just be another unfortunate serverworks chipset bug...

The CSB5 doesn't appear to fully support native mode--sure you can put it in native mode (!) and you're free to assign the BARs any way you want, but it still assumes IRQ14 for ide0 and IRQ15 for ide1 when they should really be collapsed and shared on a single PCI (non-compatibility) interrupt.

While it might be possible to re-route the interrupts using the pirq table and a few different bits in the southbridge, that still wouldn't solve the problem of PCI config reg 0x3c being read-only and set to zero in the IDE function..

The best answer might be to not use native mode. We can force it into legacy mode with a pci quirk and it works, but its ugly:

@@ -631,6 +631,22 @@
                interrupt_line_quirk = 1;
 }
 
+/*
+ *     Serverworks CSB5 IDE does not fully support native mode
+ */
+static void __init quirk_svwks_csb5ide(struct pci_dev *pdev)
+{
+       u8 prog;
+       pci_read_config_byte(pdev, PCI_CLASS_PROG, &prog);
+       if (prog & 5) {
+               prog &= ~5;
+               pdev->class &= ~5;
+               pci_write_config_byte(pdev, PCI_CLASS_PROG, prog);
+               /* need to re-assign BARs for compat mode */
+               quirk_ide_bases(pdev);
+       }
+}
+
 /*
  *  The main table of quirks.
  */

@@ -702,6 +718,8 @@
 
        { PCI_FIXUP_FINAL,      PCI_VENDOR_ID_CYRIX,    PCI_DEVICE_ID_CYRIX_PCI_MASTER, 

quirk_mediagx_master },

+ { PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_CSB5IDE, quirk_svwks_csb5ide },
+
#ifdef CONFIG_X86_IO_APIC
{ PCI_FIXUP_FINAL, PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8131_APIC,
quirk_amd_8131_ioapic },

-duncan

Could be. I've never seen one in native mode.

Looks sane but your mailer ate the patch (line wrap monster got it)

Can you resend as an attachment ?