Bug #2300


DFBSD v3.0.0.6.gbd613-RELEASE - EHCI module unload panic

Added by tuxillo about 12 years ago. Updated over 9 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:



When unloading ehci module, after few seconds of activity I get this panic:

Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic->id = 01000000
fault virtual address = 0x48
fault code = supervisor read data, page not present
instruction pointer = 0x8:0xffffffff806ce788
stack pointer = 0x10:0xffffffe0a36aa870
frame pointer = 0x10:0xffffffe0a36aa908
code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 0, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 680
current thread = pri 6
trap number = 12
panic: page fault
cpuid = 1


(kgdb) bt
#0 _get_mycpu () at ./machine/thread.h:69
#1 md_dumpsys (di=<optimized out>) at /usr/src/sys/platform/pc64/x86_64/dump_machdep.c:263
#2 0xffffffff80499ea5 in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:925
#3 0xffffffff8049a50b in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:387
#4 0xffffffff8049a7c2 in panic (fmt=0xffffffff807a86cb "%s") at /usr/src/sys/kern/kern_shutdown.c:831
#5 0xffffffff807598d4 in trap_fatal (frame=0xffffffe0a36aa7b8, eva=<optimized out>)
at /usr/src/sys/platform/pc64/x86_64/trap.c:1018
#6 0xffffffff80759ae1 in trap_pfault (frame=0xffffffe0a36aa7b8, usermode=0)
at /usr/src/sys/platform/pc64/x86_64/trap.c:912
#7 0xffffffff8075a0b5 in trap (frame=0xffffffe0a36aa7b8) at /usr/src/sys/platform/pc64/x86_64/trap.c:617
#8 0xffffffff80743fdf in calltrap () at /usr/src/sys/platform/pc64/x86_64/exception.S:188
#9 0xffffffff806ce788 in usbioctl (ap=0xffffffe0a36aa918) at /usr/src/sys/bus/usb/usb.c:614
#10 0xffffffff8047bf3c in dev_dioctl (dev=0xffffffe07dede490, cmd=<optimized out>, data=<optimized out>,
fflag=<optimized out>, cred=<optimized out>, msg=<optimized out>) at /usr/src/sys/kern/kern_device.c:243
#11 0xffffffff80665ac1 in devfs_fo_ioctl (fp=0xffffffe07df2b0d8, com=536892675, data=<optimized out>,
ucred=<optimized out>, msg=<optimized out>) at /usr/src/sys/vfs/devfs/devfs_vnops.c:1449
#12 0xffffffff804cb26e in fo_ioctl (fp=0xffffffe07df2b0d8, com=536892675,
data=0xffffffe0a36aaa58 "p\367\377\377\377\177", cred=0xffffffe00e2c7260, msg=0xffffffe0a36aab68)
at /usr/src/sys/sys/file2.h:88
#13 0xffffffff804cb725 in mapped_ioctl (fd=<optimized out>, com=536892675, uspc_data=<optimized out>,
map=<optimized out>, msg=<optimized out>) at /usr/src/sys/kern/sys_generic.c:733
#14 0xffffffff804cb7be in sys_ioctl (uap=0xffffffe00e2c7260) at /usr/src/sys/kern/sys_generic.c:552
#15 0xffffffff8075a891 in syscall2 (frame=0xffffffe0a36aac18) at /usr/src/sys/platform/pc64/x86_64/trap.c:1231
#16 0xffffffff8074422b in Xfast_syscall () at /usr/src/sys/platform/pc64/x86_64/exception.S:323
#17 0x000000000000002b in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Core available upon request. Also, if someone is experiencing this too please add your findings to this ticket.

Antonio Huete


usb_detach01.diff (302 Bytes) usb_detach01.diff Destroy device upon usb_detach() tuxillo, 03/09/2013 11:09 AM

Related issues 1 (0 open1 closed)

Related to Bug #2402: Showstopper panics for Release 3.2Closedtuxillo08/15/2012

Actions #1

Updated by swildner about 12 years ago

So what is the ioctl number it is failing on (ap->a_cmd in frame 9 should have it e.g.)?

Actions #2

Updated by tuxillo about 11 years ago

It still happens in latest master as of today.

Basically the problem is that the /dev/usbN device in question remains, hence the loop doing select() on usbd(8) issues a new ioctl() to an already deregistered device which has no softc at all anymore.

Attached patch fixes it by removing the device related to EHCI from /dev, but this causes usbd(8) to die. There must be a better solution, so any pointer is welcome.

Actions #3

Updated by tuxillo about 10 years ago

  • Description updated (diff)
  • Category set to Driver
  • Status changed from In Progress to Feedback
  • Target version set to 3.8


Can you please have a look at the attached patch? Does it look okay for you?

The fact that usbd(8) dies could just be an issue in the daemon itself that had to be handled separatedly.

Antonio Huete

Actions #4

Updated by tuxillo over 9 years ago

  • Status changed from Feedback to Closed
  • Target version changed from 3.8 to 4.2

Since we have a new USB stack I'm closing this one.


Also available in: Atom PDF