linux-kernel - Re: PROBLEM: kernel hang in ohci init

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200707152206.26995.david-b@pacbell.net>
Date:	Sun, 15 Jul 2007 22:06:26 -0700
From:	David Brownell <david-b@...bell.net>
To:	"Satyam Sharma" <satyam.sharma@...il.com>,
	"Timo Lindemann" <tlindemann@...or.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: PROBLEM: kernel hang in ohci init

On Sunday 15 July 2007, Satyam Sharma wrote:
> On 7/15/07, Timo Lindemann <tlindemann@...or.de> wrote:

> > It is just odd that up to (not including) the 2.6.21-series every kernel
> > boots, and after that, they just freeze.

On *your* system, note -- all my OHCI+PCI systems that have
been upgraded to 2.6.22 are behaving just peachy-keen-swell.
And that's true for most people, it seems...

> > I am kinda stumped here.

It gets that way sometimes.  Thing is, pci-quirks.c runs early
enough in the boot process -- before the OHCI driver can even
run!! -- that you can probably rule out the USB stack as being
the cause of this regression.  Disable the USB host controllers
in your config, and see what happens...

> Hey, just try git-bisect already :-)
> 
> In fact, you can first try by just reverting / un-applying that patch that
> you initially had a suspicion on. 

Extremely unlikely to matter, since it wouldn't have been able
to run that early.  Plus, you were seeing problems even before
that recent change to pci-quirks ... 

> Or, because you've already spent 
> some time tracking down the issue, you could simply go through the
> git history of that file / subsystem in question 

Where the subsystem in question is early PCI/ACPI initialization,
before the drivers start binding to PCI devices... it's always
annoying when changes in that area cause USB to break, since the
only involvement of USB is to display a "rude failure" symptom.
It took a long time to get the IRQ setup glitches fixed!

One thing you might do is enable all the ACPI debug messaging and
disable the usb/host/pci-quirks.c stuff (just comment it all out),
assuming you can boot without USB keyboard/mouse.  Then compare
the relevant diagnostics between "good" and "bad" kernels.  It's
likely something interesting will appear.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/