[2.6.23.1] PCI device locking up the computer when its module loads

[2.6.23.1] PCI device locking up the computer when its module loads

[Chris Rankin]

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"!

Cheers,
Chris



      ___________________________________________________________ 
Want ideas for reducing your carbon footprint? Visit Yahoo! For Good  http://uk.promotions.yahoo.com/forgood/environment.html

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

[Andrew Morton]

On Mon, 22 Oct 2007 13:43:16 +0100 (BST) Chris Rankin <rankincj@yahoo.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"!
> 

(+linux-wireless)

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

[Dan Williams]

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@yahoo.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

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

[Chris Rankin]

--- Dan Williams <dcbw@redhat.com> wrote:
> 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 problem with this case is that pci_enable_device() is the very first thing that the driver
calls, but (as I understand it) I have no hope of sending commands to the device until this
function returns. This is a "catch 22" situation from my perspective, because how am I supposed to
know which device interrupt to disable if I can't call pci_enable_device()?

Does the 2.4 kernel survive because IRQs are disabled globally during module_init() or something?

Cheers,
Chris



      ___________________________________________________________ 
Want ideas for reducing your carbon footprint? Visit Yahoo! For Good  http://uk.promotions.yahoo.com/forgood/environment.html

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

[Chris Rankin]

> > On Mon, 22 Oct 2007 13:43:16 +0100 (BST) Chris Rankin <rankincj@yahoo.com> wrote:
> > > 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.

Interestingly, I have just discovered that I can do the following on this machine *without*
locking it up (on Linux 2.6.23.9):

# cat /sys/bus/pci/devices/0000:00:0e.0/enable
0
# echo 1 > /sys/bus/pci/devices/0000:00:0e.0/enable
# cat /sys/bus/pci/devices/0000:00:0e.0/enable
1

where according to lspci:

00:0e.0 Network controller: Netgear MA301 802.11b Wireless PCI Adapter (rev 02)

Doesn't writing to this sysfs file also call pci_enable_device()? Loading the hostap_plx module is
still instantly lethal.

Cheers,
Chris



      __________________________________________________________
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com

[2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory

[Chris Rankin]

Hi,

I've recently been having trouble loading the hostap_plx 802.11b wireless networking driver, and
this evening I managed to narrow the problem down to these lines of code by copying code from
hostap_plx into a "test driver" until the test driver also locked the PC up:

        /* read CIS; it is in even offsets in the beginning of attr_mem */
        for (i = 0; i < CIS_MAX_LEN; i++)
                cis[i] = readb(attr_mem + 2 * i);

If I comment these lines out then my test driver just complains about the garbage CIS information
and fails gracefully. Leave these lines in and my PC freezes instantly.

These lines are part of the prism2_plx_check_cis() function, which is called when the module first
loads. CIX_MAX_LEN is a #define for 256, and cis is a u8* pointer previously allocated as:

cis = kmalloc(CIS_MAX_LEN, GFP_KERNEL);

attr_mem is one of the function's paramters, and is defined as void __iomem *attr_mem.

As far as I can tell, the PCI I/O memory information is correct, and matches what lspci tells me:

00:0e.0 Network controller: Netgear MA301 802.11b Wireless PCI Adapter (rev 02)
        Subsystem: Netgear MA301 802.11b Wireless PCI Adapter
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+
FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR-
<PERR-
        Interrupt: pin A routed to IRQ 5
        Region 1: I/O ports at 1000 [size=128]
        Region 2: Memory at e8002000 (32-bit, non-prefetchable) [size=4K]
        Region 3: I/O ports at 1080 [size=64]

so there is apparently 4K of I/O memory at 0xe8002000.

Can anyone help me understand why my PC is locking up when it executes this code, please?

Thanks,
Chris



      __________________________________________________________
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com

Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory

[Arjan van de Ven]

On Sun, 9 Dec 2007 19:41:58 +0000 (GMT)
Chris Rankin <rankincj@yahoo.com> wrote:

> Hi,
> 
> I've recently been having trouble loading the hostap_plx 802.11b
> wireless networking driver, and this evening I managed to narrow the
> problem down to these lines of code by copying code from hostap_plx
> into a "test driver" until the test driver also locked the PC up:
> 
>         /* read CIS; it is in even offsets in the beginning of
> attr_mem */ for (i = 0; i < CIS_MAX_LEN; i++)
>                 cis[i] = readb(attr_mem + 2 * i);
> 
> If I comment these lines out then my test driver just complains about
> the garbage CIS information and fails gracefully. Leave these lines
> in and my PC freezes instantly.
> 
> These lines are part of the prism2_plx_check_cis() function, which is
> called when the module first loads. CIX_MAX_LEN is a #define for 256,
> and cis is a u8* pointer previously allocated as:
> 
> cis = kmalloc(CIS_MAX_LEN, GFP_KERNEL);
> 
> attr_mem is one of the function's paramters, and is defined as void
> __iomem *attr_mem.


can you check if the attr_mem is properly ioremap'd ?
(probably with ioremap_nocache)


>         Region 2: Memory at e8002000 (32-bit, non-prefetchable)
> [size=4K] Region 3: I/O ports at 1080 [size=64]
> 
> so there is apparently 4K of I/O memory at 0xe8002000.
> 
> Can anyone help me understand why my PC is locking up when it
> executes this code, please?

I wonder if there's anything else in that area as well..


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory

[Chris Rankin]

--- Arjan van de Ven <arjan@infradead.org> wrote:
> can you check if the attr_mem is properly ioremap'd ?
> (probably with ioremap_nocache)

Can you elaborate, please? I am not familiar with these I/O primitives.

> I wonder if there's anything else in that area as well..

So I should check /proc/iomem? But wouldn't Linux complain if two PCI devices conflicted as you're
suggesting?

Cheers,
Chris





      ___________________________________________________________
Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/

Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory

[Arjan van de Ven]

On Sun, 9 Dec 2007 22:06:21 +0000 (GMT)
Chris Rankin <rankincj@yahoo.com> wrote:

> --- Arjan van de Ven <arjan@infradead.org> wrote:
> > can you check if the attr_mem is properly ioremap'd ?
> > (probably with ioremap_nocache)
> 
> Can you elaborate, please? I am not familiar with these I/O
> primitives.

the memory you feed to readl() and co isnt the actual PCI resource;
you need to use ioremap() on the PCI resource to get a pointer that you can then feed to readl()....

> 
> > I wonder if there's anything else in that area as well..
> 
> So I should check /proc/iomem? But wouldn't Linux complain if two PCI
> devices conflicted as you're suggesting?

the other one might not be PCI..


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory

[Chris Rankin]

--- Arjan van de Ven <arjan@infradead.org> wrote:
> the memory you feed to readl() and co isnt the actual PCI resource;
> you need to use ioremap() on the PCI resource to get a pointer that you can then feed to
> readl()....

I gathered that much, and there is indeed a call to ioremap() in the code. So are you suggesting
that  I try replacing that ioremap() call with ioremap_nocache()?

Cheers,
Chris


      ___________________________________________________________
Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/

Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory

[Chris Rankin]

--- Arjan van de Ven <arjan@infradead.org> wrote:
> > > I wonder if there's anything else in that area as well..

This is what /proc/iomem contains:

00000000-0009f7ff : System RAM
0009f800-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000cbfff : Video ROM
000e4000-000effff : Adapter ROM
000f0000-000fffff : System ROM
00100000-17ffdbff : System RAM
  00100000-002adf17 : Kernel code
  002adf18-0034a263 : Kernel data
17ffdc00-17fffbff : ACPI Tables
17fffc00-17ffffff : ACPI Non-volatile Storage
e8000000-e8000fff : 0000:00:0d.0
  e8000000-e8000fff : ohci_hcd
e8001000-e8001fff : 0000:00:0d.1
  e8001000-e8001fff : ohci_hcd
e8002000-e8002fff : 0000:00:0e.0
e8003000-e80030ff : 0000:00:0d.2
  e8003000-e80030ff : ehci_hcd
e8100000-e81fffff : PCI Bus #01
  e8100000-e810ffff : 0000:01:00.0
    e8100000-e810ffff : radeonfb mmio
  e8120000-e813ffff : 0000:01:00.0
ec000000-efffffff : 0000:00:00.0
f0000000-f7ffffff : PCI Bus #01
  f0000000-f7ffffff : 0000:01:00.0
    f0000000-f7ffffff : radeonfb framebuffer
fffe7000-ffffffff : reserved

# lspci -tvvv
-[0000:00]-+-00.0  Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge
           +-01.0-[0000:01]----00.0  ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]
           +-07.0  Intel Corporation 82371AB/EB/MB PIIX4 ISA
           +-07.1  Intel Corporation 82371AB/EB/MB PIIX4 IDE
           +-07.2  Intel Corporation 82371AB/EB/MB PIIX4 USB
           +-07.3  Intel Corporation 82371AB/EB/MB PIIX4 ACPI
           +-0d.0  NEC Corporation USB
           +-0d.1  NEC Corporation USB
           +-0d.2  NEC Corporation USB 2.0
           +-0e.0  Netgear MA301 802.11b Wireless PCI Adapter
           +-0f.0  Creative Labs SB Live! EMU10k1
           \-0f.1  Creative Labs SB Live! Game Port

The wireless PC card is device 0000:00:0e.0. And replacing ioremap() with ioremap_nocache() did
not help either.

This is the PCI entry for the host bridge:

00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+
FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR-
<PERR-
        Latency: 64
        Region 0: Memory at ec000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [a0] AGP version 1.0
                Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3-
Rate=x1,x2
                Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x2

One other thing I should mention is that this card works fine in an old P120/Zappa motherboard
machine running Linux 2.4.34.

Cheers,
Chris



      __________________________________________________________
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com

Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory

[Stefano Brivio]

On Sun, 9 Dec 2007 19:41:58 +0000 (GMT)
Chris Rankin <rankincj@yahoo.com> wrote:

> Hi,
> 
> I've recently been having trouble loading the hostap_plx 802.11b wireless
> networking driver, and this evening I managed to narrow the problem down
> to these lines of code by copying code from hostap_plx into a "test
> driver" until the test driver also locked the PC up:
> 
>         /* read CIS; it is in even offsets in the beginning of attr_mem */
>         for (i = 0; i < CIS_MAX_LEN; i++)
>                 cis[i] = readb(attr_mem + 2 * i);

Not a fix, but if you load the module with ignore_cis = 1, it should work.


-- 
Ciao
Stefano

Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory

[Chris Rankin]

--- Stefano Brivio <stefano.brivio@polimi.it> wrote:
> Not a fix, but if you load the module with ignore_cis = 1, it should work.

Well, if the I/O memory mapping is broken then wouldn't that just move the problem down to the
next attempt to access it?

Cheers,
Chris



      __________________________________________________________
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com

Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory

[Stefano Brivio]

On Sun, 9 Dec 2007 22:13:09 +0000 (GMT)
Chris Rankin <rankincj@yahoo.com> wrote:

> --- Stefano Brivio <stefano.brivio@polimi.it> wrote:
> > Not a fix, but if you load the module with ignore_cis = 1, it should work.
> 
> Well, if the I/O memory mapping is broken then wouldn't that just move the
> problem down to the next attempt to access it?

Dunno but this helped in a similar crash I had some months ago, IIRC.


-- 
Ciao
Stefano

Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory

[Andrew Morton]

On Sun, 9 Dec 2007 19:41:58 +0000 (GMT)
Chris Rankin <rankincj@yahoo.com> wrote:

> Hi,
> 
> I've recently been having trouble loading the hostap_plx 802.11b wireless networking driver, and
> this evening I managed to narrow the problem down to these lines of code by copying code from
> hostap_plx into a "test driver" until the test driver also locked the PC up:
> 
>         /* read CIS; it is in even offsets in the beginning of attr_mem */
>         for (i = 0; i < CIS_MAX_LEN; i++)
>                 cis[i] = readb(attr_mem + 2 * i);
> 
> If I comment these lines out then my test driver just complains about the garbage CIS information
> and fails gracefully. Leave these lines in and my PC freezes instantly.
> 
> These lines are part of the prism2_plx_check_cis() function, which is called when the module first
> loads. CIX_MAX_LEN is a #define for 256, and cis is a u8* pointer previously allocated as:
> 
> cis = kmalloc(CIS_MAX_LEN, GFP_KERNEL);
> 
> attr_mem is one of the function's paramters, and is defined as void __iomem *attr_mem.
> 
> As far as I can tell, the PCI I/O memory information is correct, and matches what lspci tells me:
> 
> 00:0e.0 Network controller: Netgear MA301 802.11b Wireless PCI Adapter (rev 02)
>         Subsystem: Netgear MA301 802.11b Wireless PCI Adapter
>         Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+
> FastB2B-
>         Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR-
> <PERR-
>         Interrupt: pin A routed to IRQ 5
>         Region 1: I/O ports at 1000 [size=128]
>         Region 2: Memory at e8002000 (32-bit, non-prefetchable) [size=4K]
>         Region 3: I/O ports at 1080 [size=64]
> 
> so there is apparently 4K of I/O memory at 0xe8002000.
> 
> Can anyone help me understand why my PC is locking up when it executes this code, please?
> 

I guess something like this:


--- a/drivers/net/wireless/hostap/hostap_plx.c~a
+++ a/drivers/net/wireless/hostap/hostap_plx.c
@@ -343,13 +343,14 @@ static int prism2_plx_check_cis(void __i
 	int i, pos;
 	unsigned int rmsz, rasz, manfid1, manfid2;
 	struct prism2_plx_manfid *manfid;
+	int len = min(CIS_MAX_LEN, attr_len);
 
-	cis = kmalloc(CIS_MAX_LEN, GFP_KERNEL);
+	cis = kmalloc(len, GFP_KERNEL);
 	if (cis == NULL)
 		return -ENOMEM;
 
 	/* read CIS; it is in even offsets in the beginning of attr_mem */
-	for (i = 0; i < CIS_MAX_LEN; i++)
+	for (i = 0; i < len; i++)
 		cis[i] = readb(attr_mem + 2 * i);
 	printk(KERN_DEBUG "%s: CIS: %02x %02x %02x %02x %02x %02x ...\n",
 	       dev_info, cis[0], cis[1], cis[2], cis[3], cis[4], cis[5]);
@@ -361,8 +362,8 @@ static int prism2_plx_check_cis(void __i
 	manfid1 = manfid2 = 0;
 
 	pos = 0;
-	while (pos < CIS_MAX_LEN - 1 && cis[pos] != CISTPL_END) {
-		if (pos + 2 + cis[pos + 1] > CIS_MAX_LEN)
+	while (pos < len - 1 && cis[pos] != CISTPL_END) {
+		if (pos + 2 + cis[pos + 1] > len)
 			goto cis_error;
 
 		switch (cis[pos]) {
@@ -401,7 +402,7 @@ static int prism2_plx_check_cis(void __i
 		pos += cis[pos + 1] + 2;
 	}
 
-	if (pos >= CIS_MAX_LEN || cis[pos] != CISTPL_END)
+	if (pos >= len || cis[pos] != CISTPL_END)
 		goto cis_error;
 
 	for (manfid = prism2_plx_known_manfids; manfid->manfid1 != 0; manfid++)
_

would be a bit safer, but looking at your /proc/iomem I doubt if it will
fix anything.

It might be interesting to see what value of `i' is causing it to fall
over.

Did any earlier version of the 2.6 kernel work OK?

Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory

[Chris Rankin]

--- Andrew Morton <akpm@linux-foundation.org> wrote:
> It might be interesting to see what value of `i' is causing it to fall over.

I tried unrolling the loop, but a single byte read for i = 0 is enough to lock things up.

> Did any earlier version of the 2.6 kernel work OK?

Unfortunately, I don't know. I swapped this card out of the old 2.4.x machine into a machine
already running Fedora 7. The card works when I put it back into the 2.4 machine too, so it's not
a hardware problem with the card.

So I suppose the next step would be trying a linux 2.6.0 kernel? Or was hostap included in the
kernel later than that?

Cheers,
Chris




      ___________________________________________________________
Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/

Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory

[Andrew Morton]

On Wed, 12 Dec 2007 08:56:44 +0000 (GMT) Chris Rankin <rankincj@yahoo.com> wrote:

> --- Andrew Morton <akpm@linux-foundation.org> wrote:
> > It might be interesting to see what value of `i' is causing it to fall over.
> 
> I tried unrolling the loop, but a single byte read for i = 0 is enough to lock things up.

hm.  Could be some platform thing.  Strange.  It might be worth checking
around that ioremap, make sure that the value which it returned is the one
which is being used in the function-which-hangs, etc.


> > Did any earlier version of the 2.6 kernel work OK?
> 
> Unfortunately, I don't know. I swapped this card out of the old 2.4.x machine into a machine
> already running Fedora 7. The card works when I put it back into the 2.4 machine too, so it's not
> a hardware problem with the card.
> 
> So I suppose the next step would be trying a linux 2.6.0 kernel? Or was hostap included in the
> kernel later than that?

hostap_plx.c first appeared in 2.6.14.

Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory

[Chris Rankin]

--- Andrew Morton <akpm@linux-foundation.org> wrote:
> hm.  Could be some platform thing.  Strange.  It might be worth checking
> around that ioremap, make sure that the value which it returned is the one
> which is being used in the function-which-hangs, etc.

OK, not difficult to try. (This is x86, BTW.) But I'm still baffled as to precisely why it is
hanging. Is it waiting for a value from the PCI bus that never appears, or something? Are there
any other PCI-related tests that I can do to check that the device has been initialised correctly
on the bus, please?

> hostap_plx.c first appeared in 2.6.14.

OK, I can build one of those kernels. Before then, I think that hostap was provided as an external
source package.

Cheers,
Chris


      __________________________________________________________
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com

Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory

[Chris Rankin]

-- Andrew Morton <akpm@linux-foundation.org> wrote: 
> hostap_plx.c first appeared in 2.6.14.
> 

Just a thought: How far back will I be able to compile kernels correctly with gcc 4.1.2?
Specifically:

gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33)

Cheers,
Chris



      __________________________________________________________
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com

Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory

[Chris Rankin]

--- Andrew Morton <akpm@linux-foundation.org> wrote:
> > > Did any earlier version of the 2.6 kernel work OK?

Kernel 2.6.14 does not work any better than 2.6.23.x, and my F8 userspace environment rejects a
2.4.35 kernel. I will try a 2.6.0 kernel next, but have noticed tonight that a stock Fedora kernel
also hangs when it tries to load the orinoco_plx.ko kernel module. (This module also expect a
PLX9052 bridge.)

For reference, I have found a datasheet for the PLX9052 here:

http://www.dyneng.com/plx_9052.pdf

One theory could be that the PLX9052 chip requires an extra initialisation step for an Intel
SE440BX-2 motherboard (the board that hangs) vs an older Intel Zappa motherboard (where the chip
works OK). However, I don't know anything like enough about PCI to guess what such a step might
be.

Cheers,
Chris



      __________________________________________________________
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com