On 10/28/06, Mail List <lists@xxxxxxxxxxxx> wrote:
ata1: SATA max UDMA/133 cmd 0xFE00 ctl 0xFE12 bmdma 0xFEA0 irq 169 ata2: SATA max UDMA/133 cmd 0xFE20 ctl 0xFE32 bmdma 0xFEA8 irq 169 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
There have been many many threads about this, actually since the most recent kernel update in FC5 (kernel-2.6.18-1.2200.fc5), but certainly since FC6 too. This could be an upstream kernel issue (?). I don't think I've seen any definitive explanation or if it, or is being working on. But it seems that the newest kernels (specifically the ata_piix module) are now thinking that certain ATA chipsets (mostly from Dell, such as GX270's) also support SATA drives, when in fact your system doesn't. This may be in part because there was a unification of the SATA and ATA drivers (in the ata_piix module). Anyway, since it thinks your system supports SATA it then attempts to probe for all SATA drives, and since there are no drives and in fact no SATA bus, it has to wait for the SATA bus reset commands (SRST) to time out. Supposedly harmless, except for the insanely long boot times. That's my understanding of it anyway. -- Deron Meranda -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
