HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

Hello again

I have performed some tests; and reached the following conclusions regarding this matter.
As always, UniProcessor kernels have no problems; only SMP ones.

kernel 2.2.17 + idepatches, hde (i.e., on the HPT366) at UDMA(66):
I was unable to cause any corruption despite my best efforts

kernel 2.4.0-test11-ac4, hde at UDMA(66):
Corrupted first test.

kernel 2.4.0-test11-ac4, hda at UDMA(33):
I was unable to cause any corruption despite my best efforts

kernel 2.4.0-test11-ac4, hde at UDMA(33) [i.e., using a 40 way cable]:
I was unable to cause any corruption despite my best efforts

Or, in table form:
Kernel Controller Mode Status:
2.2.17 HPT366 UDMA66 WorksForMe<tm>

2.4.0   PIIX4       UDMA33  WorksForMe<tm>
2.4.0   HPT366      UDMA33  WorksForMe<tm>
2.4.0   HPT366      UDMA66  Corruption

Further details:
The drive in question is a Seagate Barracuda 7200 rpm "ata66" 13.6gig drive
hdparm v3.6 identifies it as

/dev/hde

Model=ST313620A, FwRev=3.07, SerialNo=7BW0QXYA
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0 BuffType=0(?), BuffSize=512kB, MaxMultSect=16, MultSect=off DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2 CurCHS=65535/1/63, CurSects=-4128706, LBA=yes, LBAsects=26692776 tDMA={min:120,rec:120}, DMA modes: mword0 mword1 mword2 IORDY=on/off, tPIO={min:240,w/IORDY:120}, PIO modes: mode3 mode4 UDMA modes: mode0 mode1 *mode2 mode3 mode4

The system is the infamous BP6, with the latest bios and two celeron 466 cpu's, clocked at 7 * 66 MHz (=466).

The "tests" I used were crude but effective;
cp -aR /usr/src/linux /usr/src/testing/one
diff -dur /usr/src/linux /usr/src/testing/one looking for any differences (of which there should be zero)

This was repeated for a system which was very unloaded (i.e., just booted);
then with various other tasks running - X, Netscape, a simple program that mallocs 100 Mb. Since the machine has 128 Mb, this program should force the computer to the edge of swap - which I have previously noted to alter the rate of corruption.
Also two simultaneous cp's were run to further load the hdd system :)

As an interesting observation; Linux 2.4 is more "aggressive" about swap than 2.2; 2.2 leaves all of the 100 Mb program resident, and uses ~18 Mb of cache. 2.4 swaps some of it out, to offer more cache. 2.4 is also more "usable" with the HDD thrashing than 2.2; response times are snappier, etc. etc.
Well done.

Since there doesn't appear to be any corruption in UDMA66 mode in 2.2, I don't feel the hardware to be totally broken; instead I feel the 2.4 driver is not-quite-right. I will remain at UDMA33 on the HPT controller in 2.4 for the time being; although I am amiable to testing UDMA66 some more :)

Goodnight And Happy Hacking
Gerard Sharp
Two Penguins at 1024x768
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

This has the missing ide-pci code from 2.2.
It stablized my BP6 on the HPT core.

Cheers,

Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development

diff -urN linux-2.4.0-t12-7-pristine/drivers/ide/cs5530.c linux-2.4.0-t12-7/drivers/ide/cs5530.c
@@ -257,6 +257,14 @@
 	unsigned short pcicmd = 0;
 	unsigned long flags;
 
+#if defined(DISPLAY_CS5530_TIMINGS) && defined(CONFIG_PROC_FS)
+	if (!cs5530_proc) {
+		cs5530_proc = 1;
+		bmide_dev = dev;
+		cs5530_display_info = &cs5530_get_info;
+	}
+#endif /* DISPLAY_CS5530_TIMINGS && CONFIG_PROC_FS */
+
 	pci_for_each_dev (dev) {
 		if (dev->vendor == PCI_VENDOR_ID_CYRIX) {
 			switch (dev->device) {

@@ -326,14 +334,6 @@
 	pci_write_config_byte(master_0, 0x43, 0xc1);
 
 	restore_flags(flags);
-
-#if defined(DISPLAY_CS5530_TIMINGS) && defined(CONFIG_PROC_FS)
-	if (!cs5530_proc) {
-		cs5530_proc = 1;
-		bmide_dev = dev;
-		cs5530_display_info = &cs5530_get_info;
-	}
-#endif /* DISPLAY_CS5530_TIMINGS && CONFIG_PROC_FS */
 
 	return 0;
 }

diff -urN linux-2.4.0-t12-7-pristine/drivers/ide/hpt366.c linux-2.4.0-t12-7/drivers/ide/hpt366.c
@@ -346,6 +346,9 @@
 
 static int hpt3xx_tune_chipset (ide_drive_t *drive, byte speed)
 {
+	if ((drive->media != ide_disk) && (speed < XFER_SW_DMA_0))
+		return -1;
+
 	if (!drive->init_speed)
 		drive->init_speed = speed;
 

@@ -428,6 +431,9 @@
 	byte ultra66		= eighty_ninty_three(drive);
 	int  rval;
 
+	if ((drive->media != ide_disk) && (speed < XFER_SW_DMA_0))
+		return ((int) ide_dma_off_quietly);
+
 	if ((id->dma_ultra & 0x0020) &&
 	    (!check_in_drive_lists(drive, bad_ata100_5)) &&
 	    (HPT370_ALLOW_ATA100_5) &&

@@ -617,8 +623,14 @@
 		pci_write_config_byte(dev, PCI_ROM_ADDRESS, dev->resource[PCI_ROM_RESOURCE].start | PCI_ROM_ADDRESS_ENABLE);
 
 	pci_read_config_byte(dev, PCI_CACHE_LINE_SIZE, &test);
+
+#if 0
 	if (test != 0x08)
 		pci_write_config_byte(dev, PCI_CACHE_LINE_SIZE, 0x08);
+#else
+	if (test != (L1_CACHE_BYTES / 4))
+		pci_write_config_byte(dev, PCI_CACHE_LINE_SIZE, (L1_CACHE_BYTES / 4));
+#endif
 
 	pci_read_config_byte(dev, PCI_LATENCY_TIMER, &test);
 	if (test != 0x78)

diff -urN linux-2.4.0-t12-7-pristine/drivers/ide/ide-dma.c linux-2.4.0-t12-7/drivers/ide/ide-dma.c
@@ -90,6 +90,8 @@
 #include <asm/io.h>
 #include <asm/irq.h>
 
+#undef CONFIG_BLK_DEV_IDEDMA_TIMEOUT
+
 extern char *ide_dmafunc_verbose(ide_dma_action_t dmafunc);
 
 #ifdef CONFIG_IDEDMA_NEW_DRIVE_LISTINGS

@@ -515,9 +517,17 @@
 			return check_drive_lists(drive, (func == ide_dma_good_drive));
 		case ide_dma_verbose:
 			return report_drive_dmaing(drive);
+		case ide_dma_timeout:
+#ifdef CONFIG_BLK_DEV_IDEDMA_TIMEOUT
+			/*
+			 * Have to issue an abort and requeue the request
+			 * DMA engine got turned off by a goofy ASIC, and
+			 * we have to clean up the mess, and here is as good
+			 * as any.  Do it globally for all chipsets.
+			 */
+#endif /* CONFIG_BLK_DEV_IDEDMA_TIMEOUT */
 		case ide_dma_retune:
 		case ide_dma_lostirq:
-		case ide_dma_timeout:
 			printk("ide_dmaproc: chipset supported %s func only: %d\n", ide_dmafunc_verbose(func),  func);
 			return 1;
 		default:

diff -urN linux-2.4.0-t12-7-pristine/drivers/ide/ide-pci.c linux-2.4.0-t12-7/drivers/ide/ide-pci.c
@@ -753,6 +753,12 @@
 			if (hpt363_shared_pin && hpt363_shared_irq) {
 				d->bootable = ON_BOARD;
 				printk("%s: onboard version of chipset, pin1=%d pin2=%d\n", d->name, pin1, pin2);
+#if 1
+				/* I forgot why I did this once, but it fixed something. */
+				pci_write_config_byte(dev2, PCI_INTERRUPT_PIN, dev->irq);
+				printk("PCI: %s: Fixing interrupt %d pin %d to ZERO \n", d->name, dev2->irq, pin2);
+				pci_write_config_byte(dev2, PCI_INTERRUPT_LINE, 0);
+#endif
 			}
 			break;
 		}

The patch had a large amount of ^M's (about 1 per line), but applied cleanly after being passed through "sed" :)

Unfortunately, it has NOT fixed the problem :(

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Hi !

For what it's worth, I did try out this patch for my problem also without any noticable difference.

The problem being that the kernel hangs after a dma timeout in the partition detection phase during bootup for speeds higher than udma 44. This is an IBM-DTLA-307030 connected to a hpt366 pci card on a BH6 motherboard.

/Håkan

---------------------------------------
e-mail: [email protected] |
or [email protected] |
---------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Until we manage to get a response from HPT on what they changed in the 1.26 version of their BIOS to accomodate these drives, we shouldn't attempt to run them at that speed on the HPT366.

Linus, please apply.

@@ -55,6 +55,9 @@
 };
 
 const char *bad_ata66_4[] = {
+	"IBM-DTLA-307075",
+	"IBM-DTLA-307045",
+	"IBM-DTLA-307030",
 	"WDC AC310200R",
 	NULL
 };

dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Well try the latest out there...test12-pre7.

Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

In message <[email protected]>, And

Hi !

This is with test12-pre7 and HPT-bios 1.27.

Regards.

/Håkan

---------------------------------------
e-mail: [email protected] |
or [email protected] |
---------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

My system is test12-pre7 also; but the bios is only 1.22 - but I am using the 'RU' bp6 bios, which I thought to be the latest. Any pointers on how to get a newer HPT-bios?

Good Day and Happy Hacking
Gerard Sharp
Two Penguins at 1024x768
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

test12-pre8 and 2.2.18 is out and I do not chase BIOS revs in general. I work off the originals HPT366 1.07 this is because the lowest comman variable must be addressed and hope that the new stuff will not fail the backwards compatablity issue.

Cheers,

Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

The patch contained a large number of ^M's (about 1 per line), but applied cleanly after being passed through "sed"

It, however, has NOT corrected the problem :( :( Corruption still occurs, now under 2.4.0-test12-pre7

Good Day and Happy Hacking
Gerard Sharp
Two Penguins at 1024x768
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/