AJZaurusUSB

Issue 71: Sometimes ends in a Kernel Panic

Reported by Nikolaus Schaller, May 7, 2010

mostly when AJZaurusUSB is running on a portable Mac which is sent 
to Sleep mode and after wakeup, the kernel will crash.

It was also seen crashing when the connected device (Openmoko 
Freerunner) was booting. This has disappeared with more recent Linux 
kernels on the Freerunner so it may be a protocol bug for which 
AJZaurusUSB is not robust enough.

Comment 1 by Nikolaus Schaller, Jun 25, 2010

I managed to repeatedly force the MacBook to kernel-panic (freein an 
mbuf that is already free):

1. load AJZaurusUSB
2. plug in an Openmoko Freerunner
3. check that everything works
4. start an application that communicates with the Freerunner (e.g. 
ping)
5. send MacBook to Sleep
6. wake up MacBook by pressing a key

After recompiling on Mac OS X 10.6.4 and using FireWire kdp, I got 
the following stack backtrace for further analyses (and at least 
finding a work-around):

(gdb) bt
#0  Debugger (message=0x5cf328 "panic") at 
/SourceCache/xnu/xnu-1504.7.4/osfmk/i386/AT386/model_dep.c:867
#1  0x0021b455 in panic (str=0x591664 "Kernel trap at 0x%08x, 
type %d=%s, registers:\nCR0: 0x%08x, CR2: 0x%08x, CR3: 0x%08x, CR4: 
0x%08x\nEAX: 0x%08x, EBX: 0x%08x, ECX: 0x%08x, EDX: 0x%08x\nCR2: 
0x%08x, EBP: 0x%08x, ESI: 0x%08x, EDI: 0x%08x\nE"...) at 
/SourceCache/xnu/xnu-1504.7.4/osfmk/kern/debug.c:303
#2  0x002a8ab2 in panic_trap [inlined] () at :994
#3  0x002a8ab2 in kernel_trap (state=0x2f8bbdd0) at 
/SourceCache/xnu/xnu-1504.7.4/osfmk/i386/trap.c:943
#4  0x0029e9a8 in trap_from_kernel () at cpu_data.h:384
#5  0x0048bd19 in mbuf_len (mbuf=0x0) at 
/SourceCache/xnu/xnu-1504.7.4/bsd/kern/kpi_mbuf.c:432
#6  0x2f59c3d5 in 
net_lucid_cake_driver_AJZaurusUSB::USBTransmitPacket 
(this=0x5ba5000, packet=0x0) at 
/usr/share/QuantumSTEP/System/Sources/AJZaurusUSB/Sources/Provider.cp
p:1012
#7  0x2f59a6d6 in net_lucid_cake_driver_AJZaurusUSB::outputPacket 
(this=0x5ba5000, pkt=0x0, param=0x0) at 
/usr/share/QuantumSTEP/System/Sources/AJZaurusUSB/Sources/Client.cpp:
588
#8  0x009eb07f in last_kernel_symbol ()
#9  0x009eb413 in last_kernel_symbol ()
#10 0x009eb5dc in last_kernel_symbol ()
#11 0x0022fb84 in thread_call_thread (group=0x0) at 
/SourceCache/xnu/xnu-1504.7.4/osfmk/kern/thread_call.c:847
(gdb)
Owner: hns

Comment 2 by Nikolaus Schaller, Jun 25, 2010

Analysis:
it looks as if outputPacket() is called with a NULL packet. 
USBTransmitPacket() is not prepared for this for two reasons:
a) the second loop assumes that you can call mbuf_len(pkt)
b) the packet is finally passed to freePacket()

Comment 3 by Nikolaus Schaller, Jun 26, 2010

Apparently has been fixed. The reason was that power management (to 
receive setPowerState) was not initialized correctly since 
AJZaurusUSB is a subclas of IOEthernet. Such drivers already do some 
powermanagement - but only if initialized by different IOKit calls. 
It turned out that correct registration is sufficient since sleep 
calls disable() and wakeup calls enable(). These methods already 
flush all buffers and shut down the USB pipes. But they were not 
called due to bad power management registration.
Status: Fixed

Created: 14 years 9 months ago by Nikolaus Schaller

Updated: 14 years 7 months ago

Status: Fixed

Owner: Nikolaus Schaller

Labels:
Type:Defect
Priority:Medium