Red Hat Bugzilla – Bug 85828
boot is delayed scanning for serial ata drives
Last modified: 2007-04-18 12:51:55 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030206 Description of problem: When booting Intel 845PEBT2 based system, boot delays on the last two lines of the following: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ICH4: IDE controller at PCI slot 00:1f.1 PCI: Enabling device 00:1f.1 (0005 -> 0007) PCI: Found IRQ 5 for device 00:1f.1 PCI: Sharing IRQ 5 with 00:1d.2 ICH4: chipset revision 2 ICH4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio SiI3112 Serial ATA: IDE controller at PCI slot 02:06.0 PCI: Found IRQ 10 for device 02:06.0 SiI3112 Serial ATA: chipset revision 1 SiI3112 Serial ATA: not 100% native mode: will probe irqs later ide2: MMIO-DMA at 0xe080dc00-0xe080dc07, BIOS settings: hde:pio, hdf:pio ide3: MMIO-DMA at 0xe080dc08-0xe080dc0f, BIOS settings: hdg:pio, hdh:pio hda: LITE-ON LTR-24102M, ATAPI CD/DVD-ROM drive hdb: CREATIVEDVD-ROM DVD5240E, ATAPI CD/DVD-ROM drive hdc: IC35L080AVVA07-0, ATA DISK drive blk: queue c03ca3a0, I/O limit 4095Mb (mask 0xffffffff) hde: no response (status = 0xfe) hdg: no response (status = 0xfe) After the scan timeouts, boot proceeds normally. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.boot without serial ata drives on intel 845PEBT2 2. 3. Actual Results: Lengthy delay during detection on IDE devices scanning for drives on serial ata. Expected Results: no delay Additional info:
Same problem on my Gigabyte GA-7VAXP Ultra : Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx SiI3112 Serial ATA: IDE controller at PCI slot 00:08.0 SiI3112 Serial ATA: chipset revision 2 SiI3112 Serial ATA: not 100%% native mode: will probe irqs later ide0: MMIO-DMA at 0xd080d000-0xd080d007, BIOS settings: hda:pio, hdb:pio ide1: MMIO-DMA at 0xd080d008-0xd080d00f, BIOS settings: hdc:pio, hdd:pio PDC20276: IDE controller at PCI slot 00:0f.0 PDC20276: chipset revision 1 PDC20276: not 100%% native mode: will probe irqs later ide2: BM-DMA at 0xc400-0xc407, BIOS settings: hde:pio, hdf:pio ide3: BM-DMA at 0xc408-0xc40f, BIOS settings: hdg:pio, hdh:pio VP_IDE: IDE controller at PCI slot 00:11.1 VP_IDE: chipset revision 6 VP_IDE: not 100%% native mode: will probe irqs later VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci00:11.1 ide4: BM-DMA at 0xd400-0xd407, BIOS settings: hdi:DMA, hdj:pio ide5: BM-DMA at 0xd408-0xd40f, BIOS settings: hdk:DMA, hdl:pio hda: no response (status = 0xfe) # <---- These two take about 30 seconds each hdc: no response (status = 0xfe) # <---- the second one hde: QUANTUM FIREBALLlct20 20, ATA DISK drive blk: queue c03bf1c0, I/O limit 4095Mb (mask 0xffffffff) hdi: CD-W540E, ATAPI CD/DVD-ROM drive hdk: CD-532E-B, ATAPI CD/DVD-ROM drive ide2 at 0xb400-0xb407,0xb802 on irq 10 ide4 at 0x1f0-0x1f7,0x3f6 on irq 14 ide5 at 0x170-0x177,0x376 on irq 15 hde: host protected area => 1 hde: 39876480 sectors (20417 MB) w/418KiB Cache, CHS=39560/16/63, UDMA(33) I have no SATA devices connected. This bug makes the kernel part of the boot take 70 seconds instead of 10 seconds. The BIOS needs much less time to scan for S-ATA devices ( about 10-20 seconds for both channels ) HW info : AMD Athlon 900 VIA KT400 north bridge VIA VT8235 south bridge Silicon Image sil3112A S-ATA SW-info: Red Hat Linux 9 (Shrike) kernel-2.4.20-8.athlon.rpm Note: This bug looks very similar to bug #84401
According to Andre Hedrick, this 2x30 secs timeout is according to the specs. He recommends using the kernel parameters hdx=noprobe hdy=noprobe as a workaround. A change for this delay may be implemented, as other drivers don't wait 30 seconds, neither does the BIOS.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/