Christian Kujau wrote:
> I've noticed a *very* long delay upon booting current -mm kernels.
> Here's a snippet from netconsole with 2.6.17-mm6:
>
> ------------snip--------------------
> [ 50.651945] ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 16
> [ 50.655774] NVRM: loading NVIDIA Linux x86_64 Kernel Module 1.0-7182 Wed Apr 19 13:55:00 PDT 2006
> [ 50.763074] ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [APCJ] -> GSI 23 (level, high) -> IRQ 23
> [ 51.078391] intel8x0_measure_ac97_clock: measured 50730 usecs
> [ 51.082255] intel8x0: clocking to 46828
> [ 51.651890] ohci1394: fw-host0: AT dma reset ctx=0, aborting transmission
> [ 229.450216] input: USB HIDBP Keyboard 046a:0001 as /class/input/input0
> [ 229.458201] usbcore: registered new driver usbkbd
> [ 229.462264] drivers/usb/input/usbkbd.c: :USB HID Boot Protocol keyboard driver
> [ 229.473883] input: Logitech USB-PS/2 Optical Mouse as /class/input/input1
> [ 229.479629] usbcore: registered new driver usbmouse
> ------------snap--------------------
>
> So, we're waiting 3 minutes from 'ohci1394: aborting transmission' until
> 'input: USB HIDBP' kicks in and boot continues as usual. Unfortunately
> I'm not sure since when this unusual delay is present as I don't
> monitor the box' startups closely. With 2.6.18-rc1 it's:
[...also delayed but without "AT dma reset ctx=0, aborting
transmission", and it gets to "ieee1394: Host added"...]
> While I'm trying to find out the first kernelversion with these
> symptoms: any ideas on this one?
No idea here. I don't have an idea what could cause a delay with a
timeout of 3 minutes in the 1394 drivers.
Perhaps you should add a printk at the beginning of input's init
function. The delay could happen during the startup of the input layer
instead of the 1394 drivers.
> I can see the "[PATCH 2.6.17-rc5-mm2 00/18] ieee1394: misc updates"
> patchset, maybe I'll start with this one....
In order to avoid patch mismerges, you could grab the broken-out patches
from
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
and start bisecting within the set of 1394 patches. Among them, the
patches to sbp2, dv1394, and raw1394 are unrelated to the problem. Note
that "origin.patch" touches drivers/ieee1394/ too.
You could also test Linux 2.6.17.x with patchkit v121 from
http://me.in-berlin.de/~s5r6/linux1394/updates/ applied. As far as
drivers/ieee1394/ is concerned, this is the same as the 1394 drivers in
2.6.17-mm6, and I believe 2.6.18-rc1-mm1 too.
If 2.6.17.x + latest 1394 has the delay, try original 2.6.17.x too
unless you didn't already.
If 2.6.17.x + latest 1394 does not have the delay, then the 1394 updates
are _perhaps_ not to blame.
The VIA VT6306 OHCI controller which you have according to your lspci
output is known to work; yours doesn't even have the small quirk
mentioned in http://www.linux1394.org/view_device.php?id=713 .
--
Stefan Richter
-=====-=-==- -=== -=-=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
