On Mon, 22 Oct 2007 13:43:16 +0100 (BST) Chris Rankin <[email protected]> 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)
--- Dan Williams <[email protected]> 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
On Mon, 2007-10-29 at 00:36 -0700, Andrew Morton wrote:
> On Mon, 22 Oct 2007 13:43:16 +0100 (BST) Chris Rankin <[email protected]> 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
--- Andrew Morton <[email protected]> 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/
On Sun, 9 Dec 2007 19:41:58 +0000 (GMT)
Chris Rankin <[email protected]> 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?
On Sun, 9 Dec 2007 19:41:58 +0000 (GMT)
Chris Rankin <[email protected]> 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
--- Stefano Brivio <[email protected]> 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
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
--- Andrew Morton <[email protected]> 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
On Sun, 9 Dec 2007 22:13:09 +0000 (GMT)
Chris Rankin <[email protected]> wrote:
> --- Stefano Brivio <[email protected]> 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
-- Andrew Morton <[email protected]> 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
--- Andrew Morton <[email protected]> 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
--- Arjan van de Ven <[email protected]> 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
On Wed, 12 Dec 2007 08:56:44 +0000 (GMT) Chris Rankin <[email protected]> wrote:
> --- Andrew Morton <[email protected]> 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.
> > On Mon, 22 Oct 2007 13:43:16 +0100 (BST) Chris Rankin <[email protected]> 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
--- Arjan van de Ven <[email protected]> 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/
--- Arjan van de Ven <[email protected]> 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/
On Sun, 9 Dec 2007 22:06:21 +0000 (GMT)
Chris Rankin <[email protected]> wrote:
> --- Arjan van de Ven <[email protected]> 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 [email protected]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Sun, 9 Dec 2007 19:41:58 +0000 (GMT)
Chris Rankin <[email protected]> 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 [email protected]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org