Bug 122166 - (SATA ICH5)Huge boot delay due to SATA controller with no disks attached
(SATA ICH5)Huge boot delay due to SATA controller with no disks attached
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Garzik
Depends On:
  Show dependency treegraph
Reported: 2004-05-01 04:27 EDT by Rick Richardson
Modified: 2013-07-02 22:19 EDT (History)
1 user (show)

See Also:
Fixed In Version: fc3test3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-16 08:59:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Rick Richardson 2004-05-01 04:27:15 EDT
I have an Intel D845PEBT2 mobo with onboard IDE and SATA controllers.
 There are no disks attached to the SATA controller.  There is no way
to disable the SATA controller in the BIOS.

When FC1-test3 boots, it goes thru a several minute delay while it
tries to find (non-existent) disks on the SATA controller.  This is
not very accceptable.  You either need to greatly shorten the probe
time (to a few seconds at most), or provide a way to permanently
disable probing on that controller.
Comment 1 Robert G. Fries 2004-05-11 02:24:27 EDT
A workaround for this bug is to add 'hde=noprobe hdg=noprobe' to the
boot options.  This bug seems related to #85828 for Red Hat Linux.
I noticed the delay with RH9, but it was about only about a third as

This appears to be because FC test3 does multiple retries w/ 30-second
timeouts for each SATA controller (ide2 and ide3 on a D845PEBT2)
while RH9 only does one each.
Comment 2 Dave Rigby 2004-05-12 18:02:20 EDT
I have experienced the same problem with FC2 test3, with a Silicon
Image SiI3112 on-board controller. I have one SATA drive connected tot
he first channel but nothing on the second. I get the same ~30 second
wait on booting while the kernel scans for a non-existent drive on the
second channel.
Comment 3 radon 2004-05-22 12:40:31 EDT
The adding of hde=noprobe hdg=noprobe solve the problem of long boot
time. This method still does not solve the loading of the "smartd"
service failure at boot up. Is there any way to solve the "smartd"
problem? Thanks.
Comment 4 Emanuele Blanco 2004-06-09 12:41:28 EDT
Try to change your /etc/smartd.conf to your needs.
Comment 5 Rick Richardson 2004-10-16 08:59:49 EDT
This is fixed in fc3test3.  Thanks.

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