Bug 41582 - IDE drivers work, PATA do not with SiS 5513 IDE/ATA Controller
Summary: IDE drivers work, PATA do not with SiS 5513 IDE/ATA Controller
Alias: None
Product: IO/Storage
Classification: Unclassified
Component: Serial ATA (show other bugs)
Hardware: All Linux
: P1 high
Assignee: Jeff Garzik
Depends on:
Reported: 2011-08-23 05:35 UTC by Dan McGee
Modified: 2012-05-12 13:47 UTC (History)
5 users (show)

See Also:
Kernel Version:
Regression: No
Bisected commit-id:

lsmod and dmesg output from ide/pata (25.28 KB, application/x-gzip)
2011-08-23 05:36 UTC, Dan McGee
Logs with libata.dma=0 set (15.50 KB, application/x-gzip)
2011-08-31 16:52 UTC, Dan McGee
Possible fix (1.51 KB, patch)
2011-09-02 18:19 UTC, Alan
Details | Diff
Possible fix (correct version) (1.55 KB, patch)
2011-09-02 18:26 UTC, Alan
Details | Diff
Clean up the 0x40/0x70 register selection code (3.51 KB, patch)
2011-09-02 18:58 UTC, Dan McGee
Details | Diff
Use UDMA/100 if required, not 133 (2.55 KB, patch)
2011-09-02 19:00 UTC, Dan McGee
Details | Diff

Description Dan McGee 2011-08-23 05:35:34 UTC
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.
Comment 1 Dan McGee 2011-08-23 05:36:08 UTC
Created attachment 69722 [details]
lsmod and dmesg output from ide/pata
Comment 2 Tejun Heo 2011-08-23 07:46:11 UTC
cc'ing Alan. Alan, any ideas?
Comment 3 Dan McGee 2011-08-30 19:06:05 UTC
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.
Comment 4 Dan McGee 2011-08-31 01:04:27 UTC
Possibly related, old mailing list thread: http://marc.info/?l=linux-kernel&m=118811521801785&w=2
Comment 5 Dan McGee 2011-08-31 16:52:16 UTC
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.
Comment 6 Dan McGee 2011-08-31 16:52:50 UTC
Created attachment 71042 [details]
Logs with libata.dma=0 set
Comment 7 Dan McGee 2011-09-01 15:34:13 UTC
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
Comment 8 Dan McGee 2011-09-02 14:20:43 UTC
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.


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.
Comment 9 Alan 2011-09-02 18:18:43 UTC
Thats actually a very very helpful bit of information.
Comment 10 Alan 2011-09-02 18:19:59 UTC
Created attachment 71382 [details]
Possible fix
Comment 11 Alan 2011-09-02 18:26:12 UTC
Created attachment 71402 [details]
Possible fix (correct version)
Comment 12 Dan McGee 2011-09-02 18:44:28 UTC
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.
Comment 13 Dan McGee 2011-09-02 18:58:45 UTC
Created attachment 71412 [details]
Clean up the 0x40/0x70 register selection code
Comment 14 Dan McGee 2011-09-02 19:00:11 UTC
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.
Comment 15 Bartlomiej Zolnierkiewicz 2011-09-06 17:50:35 UTC
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..
Comment 16 Bartlomiej Zolnierkiewicz 2011-09-06 17:56:11 UTC
PS just to be clear wrt. sis5513 MWDMA support - it was verified against data sheets at the time it was implemented
Comment 17 Dan McGee 2011-09-06 19:20:14 UTC

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.
Comment 18 Florian Mickler 2012-01-12 21:52:49 UTC
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

Note You need to log in before you can comment on or make changes to this bug.