Thread: Re: [Ndiswrapper-general] IBM 802.11abg success..
Status: Beta
Brought to you by:
pgiri
From: Jan K. <jan...@we...> - 2005-03-03 08:58:14
Attachments:
smime.p7s
|
Giridhar Pemmasani wrote: > > The log indicates that this driver is trying to allocate too big a block in > interrupt context, which is not good. Try alternate drivers that are known to > work for this chipset. > The log also indicates that the driver calls NdisAllocateMemoryWithTag from wrapper_timer_handler, i.e. from DISPATCH_LEVEL, which is legal according to the Windows DDK. So, I would say there is a bug hidden in the memory allocation routine. Is kmalloc called with the correct flags (GFP_ATOMIC)? Even if the requested block is too large for an allocation within non-preemptible context, ndiswrapper should better report an error back to the caller than causing an oops. Jan |
From: Kevin D. <kde...@ya...> - 2005-03-03 14:06:30
|
Ok, I upgraded to 1.1rc4 and the behavior of the driver changes. I am also usin= g a=20 16K kernel stack modified fedora kernel 2.6.10-1.766_FC3.stk16 from linuxan= t. With this combination I get a "cable not connected error" from dhclient. So= no=20 networking at all now with ndiswrapper. I did note in the Changelog the following info * Use MDL functions when initializing ndis_packet while sending packets. Th= is fixes crashes with Fedora kernels (and amd64 driver at least). Does this apply to all Fedora Kernels, including i386 ones? If so am I just= =20 out of luck trying to use a Fedora Kernel even with the 16K kernel stack=20 patch? Kevin Mar 3 06:44:03 localhost kernel: ndiswrapper version 1.1rc4 loaded=20 (preempt=3Dno,smp=3Dno) Mar 3 06:44:04 localhost kernel: ndiswrapper: driver net5211=20 (,12/27/2004,4.0.100.140) loaded Mar 3 06:44:04 localhost kernel: ACPI: PCI interrupt 0000:02:02.0[A] -> GS= I=20 11 (level, low) -> IRQ 11 Mar 3 06:44:04 localhost kernel: ndiswrapper: using irq 11 Mar 3 06:44:04 localhost kernel: ndiswrapper (NdisAllocateMemory:201):=20 Windows driver allocating too big a block at DISPATCH_LEVEL: 156816 Mar 3 06:44:04 localhost kernel: Debug: sleeping function called from inva= lid=20 context at mm/slab.c:2061 Mar 3 06:44:04 localhost kernel: in_atomic():1, irqs_disabled():0 Mar 3 06:44:04 localhost kernel: [<c01188af>] __might_sleep+0x7b/0x85 Mar 3 06:44:04 localhost kernel: [<c0147e58>] kmem_cache_alloc+0x1b/0x45 Mar 3 06:44:04 localhost kernel: [<c0156515>] __get_vm_area+0x9e/0x168 Mar 3 06:44:04 localhost kernel: [<c0156601>] get_vm_area+0x22/0x24 Mar 3 06:44:04 localhost kernel: [<c015679e>] __vmalloc+0x39/0xf0 Mar 3 06:44:04 localhost kernel: [<f8c124d9>] NdisAllocateMemory+0x8d/0xa= 0=20 [ndiswrapper] Mar 3 06:44:04 localhost kernel: [<f8c124ff>]=20 NdisAllocateMemoryWithTag+0x13/0x16 [ndiswrapper] Mar 3 06:44:04 localhost kernel: [<f8c111a0>]=20 wrapper_timer_handler+0x13d/0x17a [ndiswrapper] Mar 3 06:44:04 localhost kernel: [<f8c11063>]=20 wrapper_timer_handler+0x0/0x17a [ndiswrapper] Mar 3 06:44:04 localhost kernel: [<c0124750>] run_timer_softirq+0x1ff/0x2= ff Mar 3 06:44:04 localhost kernel: [<c0120b59>] __do_softirq+0x35/0x79 Mar 3 06:44:04 localhost kernel: [<c0104edc>] do_softirq+0x38/0x3f Mar 3 06:44:04 localhost kernel: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mar 3 06:44:04 localhost kernel: [<c0104e16>] do_IRQ+0x70/0x7a Mar 3 06:44:04 localhost kernel: [<c01035b2>] common_interrupt+0x1a/0x20 Mar 3 06:44:04 localhost kernel: [<c020a182>] acpi_processor_idle+0xf1/0x= 1f6 Mar 3 06:44:04 localhost kernel: [<c010108f>] cpu_idle+0x1f/0x34 Mar 3 06:44:04 localhost kernel: [<c03a8665>] start_kernel+0x16b/0x16d Mar 3 06:44:05 localhost kernel: wlan0: ndiswrapper ethernet device=20 00:05:4e:47:68:c6 using driver net5211, configuration file=20 168C:1014:17AB:8331.5.conf Mar 3 06:44:05 localhost kernel: wlan0: encryption modes supported: WEP, W= PA=20 with TKIP, WPA with AES/CCMP Mar 3 06:44:05 localhost kernel: ndiswrapper (NdisAllocateMemory:201):=20 Windows driver allocating too big a block at DISPATCH_LEVEL: 156816 Mar 3 06:44:11 localhost kernel: ip_tables: (C) 2000-2002 Netfilter core t= eam Mar 3 06:44:34 localhost kernel: ip_tables: (C) 2000-2002 Netfilter core t= eam Mar 3 06:46:13 localhost kernel: ndiswrapper: device wlan0 removed On Thursday 03 March 2005 01:57 am, Jan Kiszka wrote: > Giridhar Pemmasani wrote: > > The log indicates that this driver is trying to allocate too big a block > > in interrupt context, which is not good. Try alternate drivers that are > > known to work for this chipset. > > The log also indicates that the driver calls NdisAllocateMemoryWithTag > from wrapper_timer_handler, i.e. from DISPATCH_LEVEL, which is legal > according to the Windows DDK. So, I would say there is a bug hidden in > the memory allocation routine. Is kmalloc called with the correct flags > (GFP_ATOMIC)? Even if the requested block is too large for an allocation > within non-preemptible context, ndiswrapper should better report an > error back to the caller than causing an oops. > > Jan |
From: Kevin D. <kde...@ya...> - 2005-03-04 15:14:42
|
I tried an eariler version of the driver version 3.1.102.27a http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=3DMIGR-58748 It loaded with no problems and I was able to scan for networks and saw seve= ral=20 in the area (there are 4 in my neighborhood).=20 I ran the following commands iwconfig eth1 essid {my id} iwconfig eth1 key {my key}=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(tried derivitives on this card with=20 "open" and=20 "restricted") ifconfig eth1 up dhclient eth1 This resulted in dhclient timing out and not connecting. Setting a manual ip on the card didn't seem to help. In fact ifconfig show = no=20 traffic on the card.. even after I do a ping. Any other options? Kevin On Thursday 03 March 2005 07:06 am, Kevin DeKorte wrote: > Ok, > > I upgraded to 1.1rc4 and the behavior of the driver changes. I am also > using a 16K kernel stack modified fedora kernel 2.6.10-1.766_FC3.stk16 fr= om > linuxant. > > With this combination I get a "cable not connected error" from dhclient. = So > no networking at all now with ndiswrapper. > > I did note in the Changelog the following info > > * Use MDL functions when initializing ndis_packet while sending packets. > This fixes crashes with Fedora kernels (and amd64 driver at least). > > Does this apply to all Fedora Kernels, including i386 ones? If so am I ju= st > out of luck trying to use a Fedora Kernel even with the 16K kernel stack > patch? > > Kevin > > > > > Mar 3 06:44:03 localhost kernel: ndiswrapper version 1.1rc4 loaded > (preempt=3Dno,smp=3Dno) > Mar 3 06:44:04 localhost kernel: ndiswrapper: driver net5211 > (,12/27/2004,4.0.100.140) loaded > Mar 3 06:44:04 localhost kernel: ACPI: PCI interrupt 0000:02:02.0[A] -> > GSI 11 (level, low) -> IRQ 11 > Mar 3 06:44:04 localhost kernel: ndiswrapper: using irq 11 > Mar 3 06:44:04 localhost kernel: ndiswrapper (NdisAllocateMemory:201): > Windows driver allocating too big a block at DISPATCH_LEVEL: 156816 > Mar 3 06:44:04 localhost kernel: Debug: sleeping function called from > invalid context at mm/slab.c:2061 > Mar 3 06:44:04 localhost kernel: in_atomic():1, irqs_disabled():0 > Mar 3 06:44:04 localhost kernel: [<c01188af>] __might_sleep+0x7b/0x85 > Mar 3 06:44:04 localhost kernel: [<c0147e58>] kmem_cache_alloc+0x1b/0x45 > Mar 3 06:44:04 localhost kernel: [<c0156515>] __get_vm_area+0x9e/0x168 > Mar 3 06:44:04 localhost kernel: [<c0156601>] get_vm_area+0x22/0x24 > Mar 3 06:44:04 localhost kernel: [<c015679e>] __vmalloc+0x39/0xf0 > Mar 3 06:44:04 localhost kernel: [<f8c124d9>] > NdisAllocateMemory+0x8d/0xa0 [ndiswrapper] > Mar 3 06:44:04 localhost kernel: [<f8c124ff>] > NdisAllocateMemoryWithTag+0x13/0x16 [ndiswrapper] > Mar 3 06:44:04 localhost kernel: [<f8c111a0>] > wrapper_timer_handler+0x13d/0x17a [ndiswrapper] > Mar 3 06:44:04 localhost kernel: [<f8c11063>] > wrapper_timer_handler+0x0/0x17a [ndiswrapper] > Mar 3 06:44:04 localhost kernel: [<c0124750>] > run_timer_softirq+0x1ff/0x2ff Mar 3 06:44:04 localhost kernel:=20 > [<c0120b59>] __do_softirq+0x35/0x79 Mar 3 06:44:04 localhost kernel:=20 > [<c0104edc>] do_softirq+0x38/0x3f Mar 3 06:44:04 localhost kernel:=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Mar 3 06:44:04 localhost kernel: [<c0104e16>] do_IRQ+0x70/0x7a > Mar 3 06:44:04 localhost kernel: [<c01035b2>] common_interrupt+0x1a/0x20 > Mar 3 06:44:04 localhost kernel: [<c020a182>] > acpi_processor_idle+0xf1/0x1f6 Mar 3 06:44:04 localhost kernel:=20 > [<c010108f>] cpu_idle+0x1f/0x34 Mar 3 06:44:04 localhost kernel:=20 > [<c03a8665>] start_kernel+0x16b/0x16d Mar 3 06:44:05 localhost kernel: > wlan0: ndiswrapper ethernet device 00:05:4e:47:68:c6 using driver net5211, > configuration file > 168C:1014:17AB:8331.5.conf > Mar 3 06:44:05 localhost kernel: wlan0: encryption modes supported: WEP, > WPA with TKIP, WPA with AES/CCMP > Mar 3 06:44:05 localhost kernel: ndiswrapper (NdisAllocateMemory:201): > Windows driver allocating too big a block at DISPATCH_LEVEL: 156816 > Mar 3 06:44:11 localhost kernel: ip_tables: (C) 2000-2002 Netfilter core > team Mar 3 06:44:34 localhost kernel: ip_tables: (C) 2000-2002 Netfilter > core team Mar 3 06:46:13 localhost kernel: ndiswrapper: device wlan0 > removed > > On Thursday 03 March 2005 01:57 am, Jan Kiszka wrote: > > Giridhar Pemmasani wrote: > > > The log indicates that this driver is trying to allocate too big a > > > block in interrupt context, which is not good. Try alternate drivers > > > that are known to work for this chipset. > > > > The log also indicates that the driver calls NdisAllocateMemoryWithTag > > from wrapper_timer_handler, i.e. from DISPATCH_LEVEL, which is legal > > according to the Windows DDK. So, I would say there is a bug hidden in > > the memory allocation routine. Is kmalloc called with the correct flags > > (GFP_ATOMIC)? Even if the requested block is too large for an allocation > > within non-preemptible context, ndiswrapper should better report an > > error back to the caller than causing an oops. > > > > Jan |
From: Giridhar P. <gi...@lm...> - 2005-03-03 15:30:05
|
What is happening is that NdisAllocateMemoryWithTag is being called for a memory size > KMALLOC_THRESHOLD, so vmalloc is being called as kmalloc won't be able to allocate such large chunk. Since this function is called from DISPATCH_LEVEL, kernel complains about in_atomic error. This is why I suggested using an alternate driver. I have tested Atheros driver from AT&T sometime back, although that was for a different chipset version. Oops is due to different problem which has been fixed right after 1.1rc4. -- Giri |