20 secs. wait to Ubuntu splash screen - Aargh !

[Ocky]

A few days ago I got a new desktop PC. Everything is new, except the 2 hard
drives, which being in good condition, we removed from the old PC and inserted
into the new PC.
That way I didn't need to reinstall either Windows XP nor Ubuntu Hardy and
also didn't need to repair Grub as a Windows XP repair install proved to be
unnecessary.
All is perfect except that Ubuntu now takes 20 secs. from 'Starting -' to reach the splash screen.
I deleted these two lines from fstab as the new PC has no floppy drive and only
one cd/dvd drive, but it still takes 20 secs. ........
/dev/scd1 /media/cdrom1 udf,iso9660 user,noauto,exec,utf8 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0 0
(Windows XP loads very fast - in 22/24 secs. to usable desktop)
I suppose it's not really a problem as everything else in Ubuntu is fast and
smooth - but it does niggle.
Any suggestions that I could try ?

[Mrkvonic]

You must have introduced another hardware element, which is being probed. Did you try booting in verbose, to see what takes so long, or using bootchart to identify the bottleneck?
Mrk

[Ocky]

Thank you Mrk.
I am not quite sure where to find the problem - have taken the liberty of
uploading the bootchart image for your perusal ... time permitting of course :P
I will also ask a friend more knowledgeable than I am to check.
There is of course this big gap after init ...

[FluxGFX]

Ummm wow... everything seems to start to load about 15seconds in the boot process.

[Arup]

With ext4 on my 2TB drive it boots in under 15 sec here in dual quad core PC.

[Ocky]

Yeah, but I have a small problem and only 3 GB RAM (32 bit Hardy ext3).
Take away the strange delay of 15/20 secs and I suppose I would not be far off.
Hopefully Mrk. will have a look. :)

[Mrkvonic]

Took a look. The things that take time are the initialization of hardware, namely your ata/sata devices. Did you enable new devices in bios when you plugged in the new drives? Perhaps you can test by disabling one by one and see if things change? You might have a faulty sata cable or such alike or maybe too little power on one of the ports. Also try disabling/enabling ahci in bios for each of these devices, see if this helps.
Mrk

[Ocky]

I will have a look - surely new sata cables are OK as no probs with loading
of XP, the second drive on which Ubuntu resides also has one ntfs partition.
Thanks.

Edit: Could it by any chance be due to having added all_generic_ide to the boot parameters ?
I needed that for the old PC, but maybe not required now for the new one.

[Mrkvonic]

Definitely! Do try that!
Mrk

[Ocky]

-{ Quote: "Definitely! Do try that!
Mrk" }-
Unfortunately no luck. Will have to delve a bit more... sata controller etc.
Regards.

[wilbertnl]

I would avoid the splash screen by hitting the escape button or editing the grub line (remove splash) and see if the boot messages give me an indication of where the boot takes more time.

[Ocky]

Only solution would probably be a reinstall due to all the new hardware
added - see my first post. Bootchart shows that everything loads after
roughly 15+ seconds - no bottlenecks after that delay.
Am dual booting with XP which now loads in 17 seconds or less so ruling
out any SATA cable/controller problems.
I wonder if restoring my remastersys backup taken just before getting the
new PC would fix the delay ? I am reluctant to do this as otherwise
my 8.04LTS is working just great.

[Ocky]

A verbose boot showed the following delays/pauses...

1.202793] io scheduler cfq registered (default)
9.200005] pci 0000:00:1a.7: EHCI: BIOS handoff failed (BIOS bug?) 01010001
17.200005] pci 0000:00:1d.7: EHCI: BIOS handoff failed (BIOS bug?) 01010001

In other words there is along delay in handing off to Bios.
These threads show the problems experienced by other Intel MB users.



https://lists.linux-foundation.org/pipermail/bugme-new/2008-December/020541.html
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/275351

Extract from thread....

-{ Quote: "As the Intel (the author of said spec) is saying that this is just "general
information" that does not relate specifically DG45ID (and, by extension,
probably other motherboards manufactured by Intel) I'd suggest chancing the
value of msec from 5000 to 50 in /drivers/usb/host/pci-quirks.c on line 274.
Doing that would still be compliant to the specification[1] (the time that OS
must wait is not specified so why not assume the OS manufacturer can decide).
" }-
I have a DP45SG board. Can I safely try the above ? There will be no fix from
Intel via a bios upgrade according to the above threads. So if the above
suggestion does not work, I will be doomed to have this delay in booting
on all Linux Ubuntu distros forever - unless there will one day be a workaround
from the Ubuntu devs.

Edit: I can't locate /drivers/usb/host/pci-quirks.c
Patch which may work, but where is above file location ??
And here is a patch which let's you set an arbritary handoff timeout in the
kernel command line with the new parameter named ehci_ho_to. If you want 50ms
timeout then just set: ehci_ho_to=50.

--- a/drivers/usb/host/pci-quirks.c 2009-03-03 23:35:15.000000000 +0100
+++ b/drivers/usb/host/pci-quirks.c 2009-03-04 00:00:37.000000000 +0100
@@ -51,6 +51,7 @@
#define EHCI_USBLEGCTLSTS 4 /* legacy control/status */
#define EHCI_USBLEGCTLSTS_SOOE (1 << 13) /* SMI on ownership change */

+int ehci_ho_to = 5000;

/*
* Make sure the controller is completely inactive, unable to
@@ -209,6 +210,17 @@ static void __devinit quirk_usb_handoff_
iounmap(base);
}

+int __init ehci_ho_to_setup(char *str)
+{
+ if (str != NULL && *str != '\0') {
+ ehci_ho_to = simple_strtol(str, NULL, 0);
+ if (ehci_ho_to < 10) ehci_ho_to = 10;
+ }
+ return 1;
+}
+
+__setup("ehci_ho_to=", ehci_ho_to_setup);
+
static void __devinit quirk_usb_disable_ehci(struct pci_dev *pdev)
{
int wait_time, delta;
@@ -271,7 +283,7 @@ static void __devinit quirk_usb_disable_
/* if boot firmware now owns EHCI, spin till
* it hands it over.
*/
- msec = 5000;
+ msec = ehci_ho_to;
while ((cap & EHCI_USBLEGSUP_BIOS) && (msec > 0)) {
tried_handoff = 1;
msleep(10);


Edit: I suppose this means recompiling the kernel - way beyond my very limited capabilities.
Hopefully there will be a fix.

[Ocky]

With reference to my previous post, is it possible to add ehci_ho_to=50
to the kernel line boot parameters by just editing the grub menu (e) when
booting up, or will such a parameter be ignored or cause problems ?

-{ Quote: "And here is a patch which let's you set an arbritary handoff timeout in the
kernel command line with the new parameter named ehci_ho_to. If you want 50ms
timeout then just set: ehci_ho_to=50. etc. etc...." }-

[Mrkvonic]

I would be very cautious when applying hacking tips and tricks suggestions on the net. Most are very special cases applicable only to the user's machine. I would not mess about with bios flashing and such, but that's me. Nor would I custom compile for home use except for testing.

Is the 20 second delay really that difficult to live with? How often do you reboot?

Mrk

[Ocky]

-{ Quote: "I would be very cautious when applying hacking tips and tricks suggestions on the net. Most are very special cases applicable only to the user's machine. I would not mess about with bios flashing and such, but that's me. Nor would I custom compile for home use except for testing.

Is the 20 second delay really that difficult to live with? How often do you reboot?

Mrk" }-
About 2x a day :) will take your advice.
Hopefully the fix will be built into future kernels.