linux-kernel - Re: [2.6.23.1] PCI device locking up the computer when its module loads

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]

Date:	Mon, 29 Oct 2007 07:29:25 -0400
From:	Dan Williams <dcbw@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Chris Rankin <rankincj@...oo.com>, linux-kernel@...r.kernel.org,
	linux-wireless@...r.kernel.org
Subject: Re: [2.6.23.1] PCI device locking up the computer when its module
	loads

On Mon, 2007-10-29 at 00:36 -0700, Andrew Morton wrote:
> On Mon, 22 Oct 2007 13:43:16 +0100 (BST) Chris Rankin <rankincj@...oo.com> wrote:
> 
> > Hi,
> > 
> > I have a Netgear MA301 PLX wireless networking adapter which wants to use the hostap_plx driver in
> > Linux 2.6.23.1. This very same piece of hardware works fine in an old(!) P120 machine running
> > 2.4.33, but makes the 2.6.23.1 kernel freeze as soon as the pci_enable_device() function is called
> > in prism2_plx_probe. What seems to happen is that IRQ 5 is signalled (the adapter's IRQ, according
> > to lspci), but the handler function hasn't been installed yet and so the kernel disables IRQ 5 and
> > locks up. However, the documentation that I have read implies that calling pci_enable_device()
> > before requesting the IRQ number to install the handler on is "The Right Thing to do", because
> > otherwise the IRQ number might change.
> > 
> > I have tried booting with "acpi=off nolapic" to no effect. The kernel is UP with 4K stacks and
> > PREEMPT.
> > 
> > Can anyone suggest what a suitable fix might be, please? Because I am currently thinking "CLI" and
> > "STI"!
> > 

This same sort of problem was just fixed for iwl4965.  The fix for that
was to disable device interrupts until everything the driver needed
(including interrupt handler) was set up and ready before re-enabling
them, I think.  See the thread "iwl4965 detection problem" and the mail
from Jes Sorensen on 2007-10-26.

The orinoco_plx driver appears to enable interrupts (in
orinoco_plx_hw_init()) after calling request_irq, but there's an
interesting comment in ..._hw_init():

	/* bjoern: We need to tell the card to enable interrupts, in
	   case the serial eprom didn't do this already.  See the
	   PLX9052 data book, p8-1 and 8-24 for reference. */

Perhaps your card's EPROM tells the card to enable interrupts too early?
Not sure how to fix that though.

Dan

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