Bug 215884 - ata_piix timeouts
ata_piix timeouts
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-16 00:37 EST by James Morris
Modified: 2007-11-30 17:11 EST (History)
6 users (show)

See Also:
Fixed In Version: 2.6.19-1.2895.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-11 13:37:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg output (21.97 KB, text/plain)
2006-11-16 00:37 EST, James Morris
no flags Details

  None (edit)
Description James Morris 2006-11-16 00:37:46 EST
Description of problem:


Version-Release number of selected component (if applicable):
kernel-xen-2.6.18-1.2849.fc6

(also happens with non-xen kernel)

How reproducible:

Always

Steps to Reproduce:
1. Boot system
2.
3.
  
Actual results:

During boot, a bunch of ATA timeouts are experienced (see attachment), slowing
down the boot process significantly.  The system seems to work ok eventually.

Expected results:

No timeout/reset messages.

Additional info:

See attachment.
Comment 1 James Morris 2006-11-16 00:37:46 EST
Created attachment 141341 [details]
dmesg output
Comment 2 James Morris 2006-11-16 00:39:07 EST
These are the relevant messages from the dmesg.

SCSI subsystem initialized
libata version 2.00 loaded.
ata_piix 0000:00:1f.2: version 2.00
ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0xFE00 ctl 0xFE12 bmdma 0xFEA0 irq 16
ata2: SATA max UDMA/133 cmd 0xFE20 ctl 0xFE32 bmdma 0xFEA8 irq 16
scsi0 : ata_piix
ata1: port is slow to respond, please be patient
ata1: port failed to respond (30 secs)
ata1: SRST failed (status 0xFF)
ata1: SRST failed (err_mask=0x100)
ata1: softreset failed, retrying in 5 secs
ata1: SRST failed (status 0xFF)
ata1: SRST failed (err_mask=0x100)
ata1: softreset failed, retrying in 5 secs
ata1: SRST failed (status 0xFF)
ata1: SRST failed (err_mask=0x100)
ata1: reset failed, giving up
scsi1 : ata_piix
ata2: port is slow to respond, please be patient
ata2: port failed to respond (30 secs)
ata2: SRST failed (status 0xFF)
ata2: SRST failed (err_mask=0x100)
ata2: softreset failed, retrying in 5 secs
ata2: SRST failed (status 0xFF)
ata2: SRST failed (err_mask=0x100)
ata2: softreset failed, retrying in 5 secs
ata2: SRST failed (status 0xFF)
ata2: SRST failed (err_mask=0x100)
ata2: reset failed, giving up
device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: dm-devel@redhat.com
Comment 3 Konrad Rzeszutek 2006-11-16 09:55:50 EST
Just curious, what happends if you use the 'ahci' driver instead of the
'ata_piix' ? 

The way to have it in the initrd image is to add in /etc/modprobe.conf something
like this:

alias scsi_hostadapter ahci
alias scsi_hostadapter1 ata_piix

and run 'mkinitrd' as so:
mkinitrd /boot/initrd_test.img kernel-xen-2.6.18-1.2849.fc6

and in your grub.conf file change the initrd line to point to this test one.

Don't overrite the old initrd in case the 'ahci' completly fails.
Comment 4 James Morris 2006-11-16 10:58:52 EST
With that, udev (or something after that) seems to be causing the ata_piix
module to load.  I was able to stop it being loaded with:

alias scsi_hostadapter ahci
options ata_piix foobar

which appears to make the module load fail.  There's probably a better way.

Comment 5 Konrad Rzeszutek 2006-11-16 11:39:30 EST
Did the change (use 'ahci') fix the problem?
Comment 6 James Morris 2006-11-16 11:41:04 EST
Yes, but something keeps trying to load ata_piix.
Comment 7 Konrad Rzeszutek 2006-11-16 12:15:16 EST
Bill,

Putting you as CC. How does one 'over-ride' the kudzu/udev behaviour to _not_
load the ata_piix? As I understand it, kudzu looks up stuff from the hwdata
packages to figure out what module to load - or was that the way it worked under
RHEL4, but in RHEL5 it is different?

Thank you.
Comment 8 Pete Zaitcev 2006-11-16 12:31:47 EST
This is a duplicate of bug 206221 surely. For some reason Jeff ignores it.

It never occured to me to force-load ahci, because ahci and ata_piix are
entirely different. But apparently some chipsets implement both interfaces.

Kudzu is not involved into this at all, so we should spare Bill the cc:
Neither is udev (just telling you in case you want to add Harald as well).
Module aliases are resolved by modprobe, part of module-init-tools,
which are taken over by Jon Masters (helloooo Jon).
Comment 9 Bill Nottingham 2006-11-16 13:35:53 EST
The PCI id matches both modules, therefore both modules are loaded. Ordering is
determined by:

1) modprobe.conf entries (if you have them)
2) the order returned by modprobe --show-depends
3) (anaconda only) the order returned by kudzu
Comment 10 Jon Masters 2006-11-16 14:07:50 EST
Dunno what to really recommend here. module-init-tools is doing the right thing.
If you changed the PCI table to remove the identical PCI ID from the ata_piix
driver then you wouldn't get both loaded - but that's not a good fix. I'm just
going to sit here and look pretty (well, try) until someone says upstream fixed
ata_piix :-)
Comment 11 James Morris 2006-11-16 14:18:12 EST
Added jgarzik, who likely knows how to solve this cosmic mystery upstream.
Comment 12 Konrad Rzeszutek 2006-11-16 15:29:55 EST
Bill,

Is there some sort order imposed by the tools? For example, this PCI device
8086:2652 has both drivers set:

[root@dhcp78-17 ~]# cd /lib/modules/`uname -r`
[root@dhcp78-17 2.6.18-1.2739]# cat modules.alias |grep 2652
alias pci:v00008086d00002652sv*sd*bc*sc*i* ahci
alias pci:v00008086d00002652sv*sd*bc*sc*i* ata_piix

But during installation the order is swapped (BZ  215567).

I looked in the modules.dep (part of the initrd) and the 'ahci' is first. 
But in the modules.alias (part of the initrd), the order is reversed:
[root@dhcp78-17 modules]# cat modules.alias | grep 2652
alias pci:v00008086d00002652sv*sd*bc*sc*i* ata_piix
alias pci:v00008086d00002652sv*sd*bc*sc*i* ahci

That seems to point to the tools that generate the initrd modules.alias file,
which I believe is 'trimmodalias' and are part of ananconda-runtime package.

Adding Peter to this BZ since he is the expert when it comes to this.
Comment 13 Pete Zaitcev 2006-11-16 16:07:06 EST
No, there's no sort order of any kind in module aliases.

BTW, I'm taking it back about bug 206221. That bug is about the regression:
there was no timeout before, and there is a timeout now. And that system
uses ICH7 (8086:27c0), so ahci cannot drive it. So please don't dup.
Comment 14 Will Woods 2007-01-12 13:47:19 EST
Can you try kernel-2.6.19-1.2895.fc6, which is currently in updates-testing? It
fixes the SRST problems on my ICH7-based machine.
Comment 15 Will Woods 2007-04-11 13:37:40 EDT
No response; closing as fixed.

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