# Atheros AR5523 fatal trap 12 on 8.1-RELEASE



## da1 (Oct 31, 2010)

Hello fellas,

I have a 8.1-RELEASE i386 on a Lenovo T400. I have a generic kernel into which I compiled PF+ALTQ, VESA,SC_PIXEL_MODE, VIMAGE, IPSEC, crypto and IPSEC_DEBUG.

Earlier today, my usb dongle (Atheros AR5523) did not power up under a linux distro (debian) so I wanted to give it a go under FreeBSD.

Unfortunately, I got a fatal trap 12. Bellow I will describe 2 scenarios:

*Scenario 1:*
The OS is booted up, and I plug in the USB dongle. First, I get 
	
	



```
Oct 31 21:01:37 i386 kernel: ugen7.2: <Atheros Communications Inc> at usbus7
Oct 31 21:01:37 i386 kernel: ugen7.2: <Atheros Communications Inc> at usbus7 (disconnected)
```
 and the I get the kernel trap (see "pic1" - attachment).

*Scenario 2:*
Laptop is powered down. I plug in the dongle and power it up. During the power on, I get some kind of error msg in dmesg (see "pic2"). The pc boots up fine, but when I unplug the dongle, I get the fatal trap again ("pic1").

I noticed the fatal trap was complaining about not being able to dump because no dump device was defined. So I defined one in rc.conf:

```
dumpdev="AUTO"
dumpdir="/var/crash"
```
 and got 93MB of dump after I plugged in the USB dongle.

Here is the output of kgdb:

```
# kgdb kernel.debug /var/crash/vmcore.0
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:
ugen7.2: <Atheros Communications Inc> at usbus7
uath0: <Atheros Communications Inc AR5523, rev 2.00/0.01, addr 2> on usbus7


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x18
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc098b1ad
stack pointer           = 0x28:0xe5fb9adc
frame pointer           = 0x28:0xe5fb9aec
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         = 14 (usbus7)
trap number             = 12
panic: page fault
cpuid = 0
Uptime: 1m57s
Physical memory: 1925 MB
Dumping 93 MB: 78 62 46 30 14

Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/snd_hda.ko
Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/sound.ko
Reading symbols from /boot/kernel/ahci.ko...Reading symbols from /boot/kernel/ahci.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ahci.ko
Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/atapicam.ko
Reading symbols from /boot/kernel/acpi_ibm.ko...Reading symbols from /boot/kernel/acpi_ibm.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi_ibm.ko
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linprocfs.ko
#0  doadump () at pcpu.h:246
246             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb)
```

Unfortunately for me, I can't make heads or tails of it.

Anyway, since the device was not working under Linux plus FreeBSD, I thought it had some hardware problem but then, I tried it under a Win 7 x64 box and bam, it worked.

I know there are no drivers for AR5523 under FreeBSD but my question is this, why is the kernel crashing ? It doesn't look good to me.


----------



## richardpl (Oct 31, 2010)

Kernel should probably not panic, so this appears to be uath bug.
Without bt it is near to impossible to fix panic.

To get bt, type bt and press enter at (kgdb) prompt.


----------



## da1 (Nov 1, 2010)

This is what I get:

```
(kgdb) bt
#0  doadump () at pcpu.h:246
#1  0xc08e5be7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416
#2  0xc08e5e49 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:590
#3  0xc0c60b7c in trap_fatal (frame=0xe5fb9a9c, eva=24) at /usr/src/sys/i386/i386/trap.c:938
#4  0xc0c60de0 in trap_pfault (frame=0xe5fb9a9c, usermode=0, eva=24) at /usr/src/sys/i386/i386/trap.c:851
#5  0xc0c616f9 in trap (frame=0xe5fb9a9c) at /usr/src/sys/i386/i386/trap.c:533
#6  0xc0c4420b in calltrap () at /usr/src/sys/i386/i386/exception.s:165
#7  0xc098b1ad in ifindex_alloc_locked (idxp=0xe5fb9b0a) at /usr/src/sys/net/if.c:267
#8  0xc0990438 in if_alloc (type=71 'G') at /usr/src/sys/net/if.c:420
#9  0xc082e104 in uath_attach (dev=0xc63e0680) at /usr/src/sys/dev/usb/wlan/if_uath.c:405
#10 0xc090ed1f in device_attach (dev=0xc63e0680) at device_if.h:178
#11 0xc090ff1c in device_probe_and_attach (dev=0xc63e0680) at /usr/src/sys/kern/subr_bus.c:2620
#12 0xc0809cae in usb_probe_and_attach_sub (udev=0xc5936c00, uaa=0xe5fb9c18) at /usr/src/sys/dev/usb/usb_device.c:1155
#13 0xc0809ed1 in usb_probe_and_attach (udev=0xc5936c00, iface_index=255 'Ã¿') at /usr/src/sys/dev/usb/usb_device.c:1307
#14 0xc081318f in uhub_explore (udev=0xc5945400) at /usr/src/sys/dev/usb/usb_hub.c:241
#15 0xc07fd9af in usb_bus_explore (pm=0xc5809d34) at /usr/src/sys/dev/usb/controller/usb_controller.c:244
#16 0xc0815f04 in usb_process (arg=0xc5809cd4) at /usr/src/sys/dev/usb/usb_process.c:166
#17 0xc08bad11 in fork_exit (callout=0xc0815e10 <usb_process>, arg=0xc5809cd4, frame=0xe5fb9d38) at /usr/src/sys/kern/kern_fork.c:844
#18 0xc0c44280 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270
```


----------

