ipw2100 vs ndis(4) -- does it work for anybody?

Ulrich Spoerlein uspoerlein at gmail.com
Wed May 3 19:32:04 UTC 2006


Scot, Bill,

Scot Hetzel wrote:
> You need to use the ndisgen script to create the NDIS kernel module
> for your card.
> 
> ndisgen /compat/ndis/w70n51.inf /compat/ndis/w70n51.sys

Thanks! Since when is this required? I think I never ran this tool
before. Where is this documented?

Anyway, now ndis0 is attached, but it is very, very unstable.

ndis0: <Intel(R) PRO/Wireless LAN 2100 3A Mini PCI Adapter> mem 0xfaffc000-0xfaffcfff irq 9 at device 3.0 on pci2
ndis0: NDIS API version: 5.1
ndis0: Ethernet address: 00:0c:f1:3b:f0:41

This is using the IPW driver for XP, version 1.2.4.35, similar panics
happened with the 1.2.2.8 driver. I'm running 6.1-RC from Apr. 25 on a
Dell Inspiron 8600 (Centrino) with a MiniPCI version of the IPW 2100
adapter.

none1 at pci2:3:0: class=0x028000 card=0x25618086 chip=0x10438086 rev=0x04 hdr=0x00
    vendor   = 'Intel Corporation'
    device   = 'Intel(R) PRO/Wireless 2100 LAN Card Driver'
    class    = network

Running 'ifconfig ndis0 up scan' several times, I get:
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x38 
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc053f3aa
stack pointer           = 0x28:0xed2dc024
frame pointer           = 0x28:0xed2dc024
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 257 (ifconfig)
[thread pid 257 tid 100052 ] 
Stopped at      device_is_alive+0x6:    cmpl    $0,0x38(%eax)
db> tr
Tracing pid 257 tid 100052 td 0xc4d7b300 
device_is_alive(0,0,0,2,0) at device_is_alive+0x6
ntoskrnl_finddev(faffc000,0,ed2dc164,c4c37980,c520dca0) at ntoskrnl_finddev+0x19
ntoskrnl_finddev(faffc000,0,ed2dc164,c4c0b000,c520d490) at ntoskrnl_finddev+0xb4
ntoskrnl_finddev(faffc000,0,ed2dc164,c4c0b380,c532ed00) at ntoskrnl_finddev+0xb4
ntoskrnl_finddev(faffc000,0,ed2dc164,c4bd0a80,c53550b0) at ntoskrnl_finddev+0xb4
ntoskrnl_finddev(faffc000,0,ed2dc164,c4b4cc00,c5366100) at ntoskrnl_finddev+0xb4
ntoskrnl_finddev(faffc000,0,ed2dc164,c4bd0480,c5205980) at ntoskrnl_finddev+0xb4
ntoskrnl_finddev(faffc000,0,ed2dc164,c5181c40,c534a5c0) at ntoskrnl_finddev+0xb4
MmMapIoSpace(faffc000,0,1000,0,ed2dc200) at MmMapIoSpace+0x4a
NdisMMapIoSpace(c53682c4,c5310200,faffc000,0,1000) at NdisMMapIoSpace+0x1f
_end(c5368000,0,ed2dc230,c5065e0b,c5368000) at 0xc4bc6761
w70n51_sys_drv_data_start(c5368000,c5310200,c0938bb6,c5368000,0) at w70n51_sys_drv_data_start+0x1233
w70n51_sys_drv_data_start(ed2dc280,ed2dc284,ed2dc288,e,c5310200) at w70n51_sys_drv_data_start+0x96b
x86_stdcall_wrap_end(c4efc000,0,0,c4efc000,80206910) at x86_stdcall_wrap_end+0x1e
ndis_init(c4efc000,0,0,0,0) at ndis_init+0x37
ndis_ioctl(c4ebfc00,80206910,c52300e0) at ndis_ioctl+0x333
ifhwioctl(80206910,c4ebfc00,c52300e0,c4d7b300,0) at ifhwioctl+0x337
ifioctl(c4f80b20,80206910,c52300e0,c4d7b300,0) at ifioctl+0xc3
soo_ioctl(c4f1bb40,80206910,c52300e0,c4b00d80,c4d7b300) at soo_ioctl+0x487
ioctl(c4d7b300,ed2dcd04,3,0,247) at ioctl+0x41d
syscall(3b,3b,3b,3,1) at syscall+0x2b7
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x4813881f, esp = 0xbfbfe48c, ebp = 0xbfbfe4d8 ---
db>

Next thing I tried was running wpa_supplicant, to associate with an
WPA-AP, I immediately got
panic: vm_fault: fault on nofault entry, addr: ed2da000
KDB: enter: panic
[thread pid 100 tid 100052 ]
Stopped at      kdb_enter+0x2b: nop      
db> bt
Tracing pid 100 tid 100052 td 0xc4d7b300
kdb_enter(c06ec93f) at kdb_enter+0x2b
panic(c06fe4b4,ed2da000,0,ed2dc00c,c053bcf1) at panic+0xbb
vm_fault(c1043000,ed2da000,1,0,c4d7b300) at vm_fault+0x16c
trap_pfault(ed2dc12c,0,ed2daf58) at trap_pfault+0x182
trap(c4f00090,ed2d0028,c4bc0028,ed2dc29c,ed2dc2c8) at trap+0x2fd
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc4f73e32, esp = 0xed2dc16c, ebp = 0xed2dc27c ---
w70n51_sys_drv_data_start(c504b000,d010122,c54ba000,200,ed2dc2d0) at 0xc4f73e32
x86_stdcall_wrap_end(c4f03000,d010122,c54ba000,ed2dc33c,c4f03000) at x86_stdcall_wrap_end+0x1e
ndis_ioctl(c4ec0800,c01c697b,c546d060,c4ec08b4,ed2dcc44) at ndis_ioctl+0x6cf
in_control(c5045b20,c01c697b,c546d060,c4ec0800,c4d7b300) at in_control+0xba6
ifioctl(c5045b20,c01c697b,c546d060,c4d7b300,0) at ifioctl+0x198
soo_ioctl(c4f1b0d8,c01c697b,c546d060,c4b00d80,c4d7b300) at soo_ioctl+0x487
ioctl(c4d7b300,ed2dcd04,3,38,297) at ioctl+0x41d
syscall(3b,3b,3b,bfbfe9b0,0) at syscall+0x2b7
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x482a081f, esp = 0xbfbfe95c, ebp = 0xbfbfe9c8 ---

Next up, I often get panics on attach, ie., when loading the module. One
lead to this panic:

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xc5386cf0
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc0935b98
stack pointer           = 0x28:0xe3594c70
frame pointer           = 0x28:0xe3594c74
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 13 (swi4: clock sio)
[thread pid 13 tid 100003 ]
Stopped at      ntoskrnl_remove_timer+0x4:      movl    0x18(%eax),%ebx
db> tr
Tracing pid 13 tid 100003 td 0xc4b03a80
ntoskrnl_remove_timer(c093d620,0,c093a5be,d82,4) at ntoskrnl_remove_timer+0x4
ntoskrnl_timercall(c5386cd8) at ntoskrnl_timercall+0x27
softclock(0) at softclock+0x27b
ithread_execute_handlers(c4b02624,c4b00480) at ithread_execute_handlers+0x121
ithread_loop(c4a6c0d0,e3594d38) at ithread_loop+0x54
fork_exit(c051535c,c4a6c0d0,e3594d38) at fork_exit+0x70
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xe3594d6c, ebp = 0 ---
db>

I guess I'm doing something rather stupid.

Ulrich Spoerlein

PS: This looks somewhat like PR kern/83586
-- 
 PGP Key ID: 20FEE9DD				Encrypted mail welcome!
Fingerprint: AEC9 AF5E 01AC 4EE1 8F70  6CBD E76E 2227 20FE E9DD
Which is worse: ignorance or apathy?
Don't know. Don't care.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060503/faf35630/attachment.pgp


More information about the freebsd-stable mailing list