Bug 41582
Summary: | IDE drivers work, PATA do not with SiS 5513 IDE/ATA Controller | ||
---|---|---|---|
Product: | IO/Storage | Reporter: | Dan McGee (dpmcgee) |
Component: | Serial ATA | Assignee: | Jeff Garzik (jgarzik) |
Status: | CLOSED CODE_FIX | ||
Severity: | high | CC: | alan, bzolnier, florian, thomas, tj |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | Subsystem: | ||
Regression: | No | Bisected commit-id: | |
Attachments: |
lsmod and dmesg output from ide/pata
Logs with libata.dma=0 set Possible fix Possible fix (correct version) Clean up the 0x40/0x70 register selection code Use UDMA/100 if required, not 133 |
Description
Dan McGee
2011-08-23 05:35:34 UTC
Created attachment 69722 [details]
lsmod and dmesg output from ide/pata
cc'ing Alan. Alan, any ideas? Anything I can do to help here? Just not where to start debugging or anything; I'm willing to look into this more but no real idea where to start as I'm not too proficient with hardware-level stuff. Possibly related, old mailing list thread: http://marc.info/?l=linux-kernel&m=118811521801785&w=2 Booting with libata.dma=0 "works". Obviously it is stuck in PIO4 mode and a heck of a lot slower, but we don't hang on boot. Looking at all the logs, this is rather odd, and could point to something amiss. Note that hda in the IDE drivers is only configured to UDMA/100, whereas the pata drivers attempt to set it to UDMA/133. The drive itself is capable of that speed, but I wonder if we are trying to push the controller past its limit. Unfortunately this is my boot/root disk, so no real possiblity of booting without it without some serious setup changes. ide-dmesg.txt:[ 1.486919] hda: UDMA/100 mode selected ide-dmesg.txt:[ 1.487229] hdb: UDMA/100 mode selected ide-dmesg.txt:[ 2.506927] hdc: UDMA/44 mode selected ide-dmesg.txt:[ 2.507179] hdd: UDMA/100 mode selected pata-dmesg.txt:[ 1.213746] ata1.00: configured for UDMA/133 pata-dmesg.txt:[ 1.277803] ata1.01: configured for UDMA/100 pata-dmesg.txt:[ 1.520277] ata2.00: configured for UDMA/44 pata-dmesg.txt:[ 1.583865] ata2.01: configured for UDMA/100 New dmesg/etc. logs attached after booting with libata.dma=0. Created attachment 71042 [details]
Logs with libata.dma=0 set
Yet another who knows how useful data point, but I see the following in dmesg when running `hdparm -i /dev/sr0` (yet smartctl doesn't generate it, maybe hdparm is just doing something silly): [86947.681384] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 [86947.681884] ata2.00: failed command: IDENTIFY DEVICE [86947.682367] ata2.00: cmd ec/00:01:00:00:00/00:00:00:00:00/40 tag 0 pio 512 in [86947.682369] res 01/04:01:01:14:eb/00:00:00:00:00/00 Emask 0x3 (HSM violation) [86947.683349] ata2.00: status: { ERR } [86947.683847] ata2.00: error: { ABRT } [86947.684370] ata2: soft resetting link [86947.888250] ata2.00: configured for PIO4 [86947.945923] ata2.01: configured for PIO4 [86947.946755] ata2: EH complete It appears the 100 vs 133 speed thing was a big deal. If I boot with the following, forcing UDMA5 (100) on all ports except my CDROM drive which only supports UDMA3 (44), things boot and are working as expected. libata.force=udma5,2.00:udma3 It seems the only thing needing to be solved here is why the new driver things UDMA6 is supported when the old driver does not. Thats actually a very very helpful bit of information. Created attachment 71382 [details]
Possible fix
Created attachment 71402 [details]
Possible fix (correct version)
Oh damn, I already figured this out and came up with patches I'm testing now. Cleaned up the reg54 junk a bit too, I'll attach them once I confirm working. Created attachment 71412 [details]
Clean up the 0x40/0x70 register selection code
Created attachment 71422 [details]
Use UDMA/100 if required, not 133
Tested with this and the previous patch, confirmed working on my system with no libata.force options required anymore. This is *very* similar to Alan's patch, totally independent on the eventual outcome. Biggest difference is not repeating the reg54 business over and over and refactoring that out.
Hi Dan, You may add: Reviewed-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> to both your patches as they look good to me. BTW The FIXME comment in the pata_sis driver: /* FIXME: need data sheet to add MWDMA here. Also lacking on ide/pci driver */ is still valid (though sis5513 driver has been supporting MWDMA for some time now) if you would be interested in fixing this driver.. PS just to be clear wrt. sis5513 MWDMA support - it was verified against data sheets at the time it was implemented Bartlomiej, Thanks for reviewing the patches, I really appreciate it. As far as MWDMA support, it seems like this was attempted back in 2009 in commit f20941f334d8fdb6b598658979709b4e94cd034b and later reverted in commit 1b52f2a41c41052d2a7c78af0bd9b8b11d70f49a. I might be a tad in over my head attempting to do that correctly, but if I find the time I can give it a shot. A patch referencing this bug report has been merged in Linux v3.2-rc1: commit f30f9a5e7bc130c727712342dd064ae8d188b170 Author: Dan McGee <dpmcgee@gmail.com> Date: Wed Sep 7 11:23:19 2011 -0500 pata_sis: add mode_filter method for certain sis5513 chipsets |