Re: [RESEND][2.6.15] New ATA error messages on upgrade to 2.6.15

[Kyle Moffett <mrmacman_g4@mac.com>]

On Apr 2, 2006, at 17:24:43, Alan Cox wrote:
> On Sul, 2006-04-02 at 15:55 -0400, Kyle Moffett wrote:
> > (2)  It's extremely unlikely that the card itself is faulty; it  
> > exhibits identical symptoms on both drives and has ever since I  
> > originally purchased the card and installed 2.4.X on the system.
>
> If it has always shown those symptoms then I'd say its quite likely  
> the card if the crystals/PLLs on it are out. It looks like the  
> timing is wrong, which means either the input clocks (eg PCI clock)  
> are wrong (eg 37.5Mhz not 33 due to BIOS overclock settings or just  
> plain out), the card has a dodgy crystal/PLL or the kernel set it  
> up wrong.
>
> PCI timings won't move between motherboards, PLL faults wont move  
> between cards.
>
> Unless anyone else is seeing the same problem with the same card  
> variant or you have two cards that do it then there isn't much that  
> can be done I suspect other than assume the hardware is iffy,  
> rightly or wrongly. I'd have expected a lot more reports if it were  
> the controller.

Hmm, okm thanks for the information.  If it was possible, I'd be  
extremely suspicious that the card's firmware was either buggy or  
Linux didn't know how to repsond to the odd hardware variant; I don't  
recall them producing that model of card for very long, so it's quite  
possible there aren't many of them around and they have some kind of  
timing quirk nobody knows about.

CRC issues aside, there is that other MULTWRITE_EXT error that only  
occurs on hdi (and if I swap hdi and hdg, the error follows the  
drive).  The error also is specific to 2.6.15+, it does not occur on  
the 2.6.12+patch that I switched from a month ago.  I'm assuming that  
since the drive/card stop giving BadCRC errors that they're able to  
communicate successfully at the extremely low speed.

With a little more tinkering with hdparm I was able to determine that  
the drives on the built-in controller and the primary bus of the PCI  
controller were both in DMA mode, the former in udma4 and the latter  
in udma3.  The originally problematic drive (the one giving the  
MULTWRITE_EXT errors) was in PIO mode, though "hdparm -d1 /dev/hdi"  
"fixed" that problem and resulted in a drastic increase in drive bus  
speed as measured  by "hdparm -tT".  (from 2MB/sec to around 23MB/sec  
or so).  hdi ended up in udma2 according to "hdparm -i"

Just for clarity, I'm repeating the _new_ error below.  This one  
recurs about once or twice an hour, but only on the samsung drive.   
If the answer is (as it seems likely) "Your drive has bad firmware  
but the error is totally harmless", then I'll be perfectly happy,  
although I'd kind of prefer if the kernel could detect the buggy  
firmware and work around it (maybe by switching back to whatever the  
old behavior was, whenever changed).  I'd otherwise be happy to git- 
bisect except for the fact that a number of people rely on this  
system for day-to-day activities.

> Mar 28 03:15:13 penelope kernel: hdi: status timeout: status=0xd0  
> { Busy }
> Mar 28 03:15:13 penelope kernel: PDC202XX: Secondary channel reset.
> Mar 28 03:15:13 penelope kernel: hdi: no DRQ after issuing  
> MULTWRITE_EXT
> Mar 28 03:15:13 penelope kernel: ide4: reset: success

The drive on the built-in controller is correctly set to udma4 mode,  
though if I attempt to bump that up to udma5 (which is listed as  
supported in "hdparm -i /dev/hda"), then the drive becomes completely  
unresponsive until the next reboot.  I'm waiting for the RAID to  
finish rebuilding before I try increasing the UDMA speed on the other  
drives to see what happens.

Thanks again for the help and consideration!

Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/