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]
Message-ID: <20100121193951.GS24305@caffeine.csclub.uwaterloo.ca>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ