linux-kernel - Re: Strange EHCI/OHCI IRQ and other PCI errors on boot with 2.6.32 (which 2.6.26 did not see) on Geode LX/CS5536.

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] [day] [month] [year] [list]

Date:	Thu, 21 Jan 2010 14:39:51 -0500
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>,
	linux-kernel@...r.kernel.org, linux-geode@...ts.infradead.org,
	linux-usb@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: Strange EHCI/OHCI IRQ and other PCI errors on boot with 2.6.32
	(which 2.6.26 did not see) on Geode LX/CS5536.

On Wed, Jan 20, 2010 at 08:52:03PM -0500, Alan Stern wrote:
> You could try changing the set of drivers loaded in memory.  For 
> example, after booting with irqpoll you can unload ehci-hcd plus some 
> other driver, and then load ehci-hcd again.  If the IRQ storm occurs 
> then you'll know where to look.
> 
> > > Does 2.6.26 fail on the new machine?
> > 
> > Yes.
> > 
> > As far as I can tell some machines don't see the problem.  I am still
> > investigating that.
> 
> Same kernel, initramfs, and everything else?

Same 2.6.26 kernel, there is no initramfs involved.  Some user space
code has been updated on this one.

> What I meant was: Is your current 2.6.26 still built using the same 
> .config as the old 2.6.26 which used to work okay?

I haven't actually rebuilt 2.6.26.  It is the same kernel image.

I wonder if some of the cpu modules have a flaw that's making the IRQ
line go crazy.  I wasn't normally using it before except when a cellular
usb modem was installed.

I will try booting the same release of software on my box as the one
that works and see if it still sees a problem...

So it turns out every box behaves the same, but only if I change the
order things are loaded in.  If I load the usb driver before programming
the FPGA on the LPC bus, then I get the IRQ flood.  If I program the
FPGA first, then no problem.  I don't understand why since the LPC bus
has been told not to handle IRQ 5 at all, and the FPGA has the pin tri
stated and it is pulled up as per LPC SERIRQ spec, yet somehow it is
driving the system mad.  So the whole problem seems to be that by
adding udev I made usb load earlier than it used to, and then when
I tried building USB into the kernel instead, it loads even earlier,
and in both cases it complains.  Previously I just loaded things manually
in the order that made sense, but I really want to go to more modern
ways of doing things.  I guess I will have to tell udev to ignore the
usb controller and load that one manually after the FPGA.  At least
things make some sense now.

-- 
Len Sorensen
--
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/