Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory
--- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory
-- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory
--- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory
On Wed, 12 Dec 2007 08:56:44 + (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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory
--- 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory
On Sun, 9 Dec 2007 19:41:58 + (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-
> SERR-
> 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory
--- 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: -0009f7ff : System RAM 0009f800-0009 : reserved 000a-000b : Video RAM area 000c-000cbfff : Video ROM 000e4000-000e : Adapter ROM 000f-000f : System ROM 0010-17ffdbff : System RAM 0010-002adf17 : Kernel code 002adf18-0034a263 : Kernel data 17ffdc00-17fffbff : ACPI Tables 17fffc00-17ff : ACPI Non-volatile Storage e800-e8000fff : :00:0d.0 e800-e8000fff : ohci_hcd e8001000-e8001fff : :00:0d.1 e8001000-e8001fff : ohci_hcd e8002000-e8002fff : :00:0e.0 e8003000-e80030ff : :00:0d.2 e8003000-e80030ff : ehci_hcd e810-e81f : PCI Bus #01 e810-e810 : :01:00.0 e810-e810 : radeonfb mmio e812-e813 : :01:00.0 ec00-efff : :00:00.0 f000-f7ff : PCI Bus #01 f000-f7ff : :01:00.0 f000-f7ff : radeonfb framebuffer fffe7000- : reserved # lspci -tvvv -[:00]-+-00.0 Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge +-01.0-[: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 :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- SERR- http://uk.mail.yahoo.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory
--- 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory
On Sun, 9 Dec 2007 22:13:09 + (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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory
On Sun, 9 Dec 2007 22:06:21 + (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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory
--- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory
On Sun, 9 Dec 2007 19:41:58 + (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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory
--- 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory
On Sun, 9 Dec 2007 19:41:58 + (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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
