Bug 211757 - kernel starts slow with ata warnings
Summary: kernel starts slow with ata warnings
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 5
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeff Garzik
QA Contact: Brian Brock
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2006-10-21 23:15 UTC by Paul Johnson
Modified: 2013-07-03 02:30 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-05-06 16:31:27 UTC

Attachments (Terms of Use)

Description Paul Johnson 2006-10-21 23:15:39 UTC
Description of problem:

The system still works, but the boot seems to hang a long long time while it
spits out messages about the ata1 and ata2 ports. This is happening on a system
with IDE hard disks, not SATA.  In dmesg, the messages look like this.

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
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
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
SELinux:  Disabled at runtime.
SELinux:  Unregistering netfilter hooks
audit(1161448000.189:2): selinux=0 auid=4294967295
ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 17 (level, low) -> IRQ 177
Intel 82802 RNG detected
hdc: ATAPI 48X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20

Version-Release number of selected component (if applicable):

How reproducible: I upgraded 2 Dell Optiplex 270 systems and got this same problem.

Steps to Reproduce:
1. Let RPM update kernel
Actual results:

Expected results:

No warnings, or at least some assurance that everything is OK.

Additional info:

Comment 1 Bert DeKnuydt 2006-10-24 09:08:16 UTC
Exactly the same problem on an  HP d530 CMT.

Enabling or disabling these unused ports in the BIOS does not seem to make 
any difference.

Comment 2 jjaakkol 2006-10-24 14:24:35 UTC
I can confirm this on Optiplex 270. It also happens on Dell OptiPlex GX620 with
sata drives installed in the first interface, but no sata drives on the second
sata interface. Lspci list the sata interface as follows: 
00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) Serial ATA 
Storage Controllers cc=IDE (rev 01).

It seems that something is unhappy with sata interfaces which have no drives.

Also, this bug seems to be a duplicate of #211591:

Comment 3 mreymann 2006-10-26 10:57:35 UTC
I can confirm this error on a Dell Optiplex GX280 using kernel
2.6.18-1.2200.fc5smp. Also, many people seem to have the same problem on FC6.
For more cases, see: http://www.fedoraforum.org/forum/showthread.php?p=657291

Comment 4 Vasile Gaburici 2006-12-08 15:36:05 UTC
Following comment #2 here and my post for #211591: in my case I do have a disk
attached to one the sata channels, but the other channel is empty. The disk gets
detected OK if the BIOS enables it, otherwise it doesn't. Still, I get the exact
same boot messages for both channels regardless whether the disk gets detected
or not. I also tried to boot without the disk (it's not the boot drive), but I
get the same result. So the disk does not seem to matter.

Also, the system works all right despite this nuisance at boot time.

Comment 5 Bug Zapper 2008-04-04 04:03:23 UTC
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

Comment 6 Bug Zapper 2008-05-06 16:31:25 UTC
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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