As summary states. Basically I can boot with an initrd containing sis5513/ide_core, but one containing pata_sis/libata does not work. It makes it through the initial boot, getting into the Arch Linux init scripts, and dying at the remount root step (`mount -n -o remount,rw /`). By dying, the initscripts proceed no further, the kernel has no more printk() output, and the HDD activity light on the machine stays on. I also have to hard reset at this point. Running Arch Linux, 3.0-ARCH #1 SMP PREEMPT Wed Aug 17 20:24:07 UTC 2011 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz GenuineIntel GNU/Linux (really 3.0.3). I have bene experiencing this behavior ever since the pata stuff came into existence way back when, and have had to stick with the IDE drivers since, so this is not a new problem. I'm guessing some compatibility hack is missing? Relevant debug files that I can think of are attached. Please let me know what more you need. Obtaining anything from pata is a pain in the ass as I had to use netconsole to do that, so please let me know everything you may want or need upfront if I need to boot into that initrd.
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