Re: 9.1: boot-time delay?

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	Hello.  I suppose it's not possible to configure ahcisata in the BIOS on the long-delay
machines?  I'm guessing this is some quirk of the pciide(4) and piixide(4) drivers.  Not to be too 
flip, but do you expect these machines to reboot frequently in production?  If not, then I'd 
probably live with the delay on reboot as at this point, I'd be concerned that any fix I came up with
for it would have implications down the road which might be more serious and more impactful on
operations.  I certainly understand the need to know what's going on, but if a machine only
reboots once or twice a year in production, then ...

	Any newer hardware should have ahcisaata capable SATA controllers, so this problem should
go away as the hardware ages out.

-thanks
-Brian

On May 25,  3:33pm, Mouse wrote:
} Subject: Re: 9.1: boot-time delay?
} >> Will HZ=1000 be sufficient and does that reduce the boot time?
} > The latter is a good question which is likely to hint at possible
} > causes.  I'll experiment with various HZ values and see what happens.
} 
} At HZ=8000, the delay (based on the bracketed numbers) is almost
} exactly 22 seconds.
} 
} At HZ=4000, it's almost exactly 10 seconds.
} 
} At HZ=2000, it's almost exactly 4.3 seconds.
} 
} Based on a quadratic fit to those three data points, all I need to do
} is set HZ to 0 and it will reach the rest of the boot 1.2 seconds
} before it gets to uhub3.  Clearly, this machine includes resublimated
} thiotimoline somewhere in its hardware makeup.
} 
} Seriously, though...
} 
} I've just heard from one of the other people working with this.  I was
} told that, on a different hardware platform, the delay is gone even
} with HZ=8000.  I have an instance of that platform among my development
} machines; I tried it and I see the same thing, even with a bit-for-bit
} identical kernel.
} 
} I spent a little time playing with boot -c and disabling various
} things, as suggested by Martin Husemann upthread.
} 
} Disabling ehci* (what that hardware uses for USB) shuts off all USB
} support, of course.  It does nothing for the delay.
} 
} Disabling piixide* still gets the delay, but it also still finds wd0;
} it just attaches pciide* instead of piixide*.
} 
} Disabling both piixide* and pciide* gets rid of wd* _and_ gets rid of
} the delay.  (It doesn't boot fully, of course, beause it has no root
} device.  But it reaches the root device prompt after some four seconds
} instead of 25-plus.)
} 
} Disabling wd does not fix the delay, but it doesn't completely
} eliminate wd; I still see "wd at ... not configured" messages, so it's
} found in some sense.  (I haven't tried completely removing wd from the
} kernel config.)
} 
} The machine without the delay has wd drives, but they attach at
} ahcisata instead of piixide/pciide.  The piixide attachment (the
} machine that exhibits the delay) is
} 
} piixide0 at pci0 dev 31 function 2: Intel 6 Series Serial ATA Controller (rev. 0x05)
} piixide0: bus-master DMA support present
} piixide0: primary channel configured to native-PCI mode
} piixide0: using ioapic0 pin 19 for native-PCI interrupt
} atabus0 at piixide0 channel 0
} piixide0: secondary channel configured to native-PCI mode
} atabus1 at piixide0 channel 1
} ...
} piixide1 at pci0 dev 31 function 5: Intel 6 Series Serial ATA Controller (rev. 0x05)
} piixide1: bus-master DMA support present
} piixide1: primary channel wired to native-PCI mode
} piixide1: using ioapic0 pin 19 for native-PCI interrupt
} atabus2 at piixide1 channel 0
} piixide1: secondary channel wired to native-PCI mode
} atabus3 at piixide1 channel 1
} ...
} wd0 at atabus0 drive 0
} wd0: <ST500DM002-1BD142>
} wd0: drive supports 16-sector PIO transfers, LBA48 addressing
} wd0: 465 GB, 969021 cyl, 16 head, 63 sec, 512 bytes/sect x 976773168 sectors (0 bytes/physsect; first aligned sector: 8)
} wd0: 32-bit data port
} wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100), WRITE DMA FUA, NCQ (32 tags)
} wd0(piixide0:0:0): using PIO mode 4, Ultra-DMA mode 5 (Ultra/100) (using DMA), WRITE DMA FUA EXT
} wd1 at atabus2 drive 0
} wd1: <SATADOM-SV 3ME3>
} wd1: drive supports 1-sector PIO transfers, LBA48 addressing
} wd1: 7641 MB, 15525 cyl, 16 head, 63 sec, 512 bytes/sect x 15649200 sectors
} wd1: 32-bit data port
} wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), WRITE DMA FUA, NCQ (32 tags)
} wd1(piixide1:0:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA), WRITE DMA FUA EXT
} 
} In contrast, the ahcisata attachment, on the machine with no delay, is
} 
} ahcisata0 at pci0 dev 23 function 0: vendor 8086 product a102 (rev. 0x31)
} ahcisata0: 64-bit DMA
} ahcisata0: AHCI revision 1.31, 4 ports, 32 slots, CAP 0xe734ff43<EMS,PSC,SSC,PMD,SAM,ISS=0x3=Gen3,SCLO,SAL,SALP,SSNTF,SNCQ,S64A>
} ahcisata0: interrupting at msi1 vec 0
} atabus0 at ahcisata0 channel 0
} atabus1 at ahcisata0 channel 1
} atabus2 at ahcisata0 channel 2
} atabus3 at ahcisata0 channel 3
} ...
} ahcisata0 port 0: device present, speed: 6.0Gb/s
} ahcisata0 port 3: PHY offline
} ahcisata0 port 1: PHY offline
} ahcisata0 port 2: PHY offline
} ...
} wd0 at atabus0 drive 0
} wd0: <WDC WD20EFRX-68EUZN0>
} wd0: drive supports 16-sector PIO transfers, LBA48 addressing
} wd0: 1863 GB, 3876021 cyl, 16 head, 63 sec, 512 bytes/sect x 3907029168 sectors (0 bytes/physsect; first aligned sector: 8)
} wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), NCQ (32 tags) w/PRIO
} wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA), NCQ (31 tags) w/PRIO
} 
} I don't suppose this gives anyone any helpful thoughts?
} 
} /~\ The ASCII				  Mouse
} \ / Ribbon Campaign
}  X  Against HTML		mouse%rodents-montreal.org@localhost
} / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
>-- End of excerpt from Mouse