Bug 116747 - [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile 1400 wireless card
Summary: [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile 1400 wireless card
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: 7.0-CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-wireless (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-29 18:40 UTC by Roar Pettersen
Modified: 2018-05-28 19:49 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roar Pettersen freebsd_committer 2007-09-29 18:40:01 UTC
Trying to get my Dell TrueMobile 1400 wireless card working on my freshly
installed FreeBSD 7.0, using "ndisgen" to convert the Windows driver.

Loading the kenel module "bcmwl5_sys.ko", then the system crash :


[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".

Unread portion of the kernel message buffer:
no match for IoGetDeviceObjectPointer
ndis0: <Dell TrueMobile 1400 Dual Band WLAN Mini-PCI Card> mem 0xdfcfe000-0xdfcfffff irq 17 at device 3.0 on pci3
ndis0: [ITHREAD]
ndis0: NDIS API version: 5.1


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x2
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0x2
stack pointer           = 0x28:0xe62eb78c
frame pointer           = 0x28:0x7b4
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 1043 (kldload)
trap number             = 12
panic: page fault
cpuid = 0
Uptime: 1m52s
Physical memory: 1007 MB
Dumping 56 MB: 41 25 9

#0  doadump () at pcpu.h:195
195             __asm __volatile("movl %%fs:0,%0" : "=r" (td));

How-To-Repeat: # kldload bcmwl5_sys.ko
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2007-10-08 01:53:16 UTC
Responsible Changed
From-To: freebsd-i386->freebsd-net

Reclassify.
Comment 2 Harald Hanche-Olsen 2008-03-15 16:07:10 UTC
(I wasn't sure whether to append to this pr or file my own: My problem
seems related but is not identical. Anyway, here goes:)

I have an old-ish laptop with the Dell TrueMobile 1180 Internal
802.11b Mini PCI Card. I get a kernel panic not after kld_load
bcmwl5_sys.ko, but only after trying to run ifconfig on the interface
instead:

System: FreeBSD odin 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386

[The system is freshly installed, and bcmwl5_sys.ko is freshly
 generated on the new system.]

First, when running "kldload bcmwl5_sys.ko" I get these messages on
the console:

ndis0: <Dell TrueMobile 1180 Internal 802.11b Mini PCI Card> mem 0xffc000-0xf8ffdfff irq 9 at device 3.0 on pci2
ndis0: [ITHREAD]
ndis0: NDIS API version: 5.0
ndis0: NDIS ERROR: c000138d (unknown error)
ndis0: NDIS ERROR: c000138d (unknown error)
ndis0: using obsoleted if_watchdog interface
ndis0: Ethernet address: 00:90:4b:b0:07:5b

Next, when I run "ifconfig ndis0 odin ssid foonet mode 11b" I get
ndis0: NDIS ERROR: c000138d (unknown error)
ndis0: NDIS ERROR: c000138d (unknown error)

[IIRC, I used to get these under 6.2 as well, so I assume they're
harmless]

and then the kernel panic.  Output from kgdb below.

# kgdb /boot/kernel/kernel /var/crash/vmcore.1
[...]

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address	= 0x0
fault code		= supervisor read, page not present
instruction pointer	= 0x20:0xc0a46e7c
stack pointer	        = 0x28:0xf0890b04
frame pointer	        = 0x28:0xf0890b3c
code segment		= base rx0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, def32 1, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 848 (ndis0 taskq)
trap number		= 12
panic: page fault
cpuid = 0
Uptime: 4m58s
Physical memory: 755 MB
Dumping 272 MB: 257 241 225 209 193 177 161 145 129 113 97 81 65 49 33 17 1

#0  doadump () at pcpu.h:195
195	pcpu.h: No such file or directory.
	in pcpu.h
(kgdb) where
#0  doadump () at pcpu.h:195
#1  0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2  0xc0754719 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:563
#3  0xc0a4905c in trap_fatal (frame=0xf0890ac4, eva=0)
    at /usr/src/sys/i386/i386/trap.c:899
#4  0xc0a492e0 in trap_pfault (frame=0xf0890ac4, usermode=0, eva=0)
    at /usr/src/sys/i386/i386/trap.c:812
#5  0xc0a49c8c in trap (frame=0xf0890ac4) at /usr/src/sys/i386/i386/trap.c:490
#6  0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7  0xc0a46e7c in memcpy () at /usr/src/sys/i386/i386/support.s:692
Previous frame inner to this frame (corrupt stack?)
(kgdb) #
Comment 3 Dan Lukes 2009-11-10 12:48:33 UTC
Just for evidence ...

Same problem (unknown NDIS error C000138D then panic) but immediatelly 
on kernel module load.

OS FreeBSD 7.2-RELEASE-p3
card:
Atheros AR8131
vendor:device:
   chip: 1969:1063
   card: 1025:0229
   NDIS 5.1
   windows driver version 1.0.0.26

			Dan
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2011-04-11 23:57:37 UTC
Responsible Changed
From-To: freebsd-net->freebsd-wireless
Comment 5 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:49:09 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.