Bug #556
closedusb stick/hub detach panic
Description
hey,
100% reproducible panic on detach of my usb stick. ehci is loaded as well. UP system.
#12 0xc0194734 in kprintf (fmt=0xdeadc0de <Address 0xdeadc0de out of bounds>)
at /usr/build/src/sys/kern/subr_prf.c:304
#13 0xc0260cfd in usb_disconnect_port (up=0xc415a178, parent=0xdeadc0de)
at /usr/build/src/sys/bus/usb/usb_subr.c:1382
#14 0xc02621a3 in uhub_detach (self=0xc415a100) at /usr/build/src/sys/bus/usb/uhub.c:610
#15 0xc018d9ae in device_detach (dev=0xc415a100) at device_if.h:48
#16 0xc018cef9 in device_delete_child (dev=0xdeadc0de, child=0xc415a100)
at /usr/build/src/sys/kern/subr_bus.c:591
#17 0xc0260d4b in usb_disconnect_port (up=0xc698b1f4, parent=0xdeadc0de)
at /usr/build/src/sys/bus/usb/usb_subr.c:1387
#18 0xc0261f33 in uhub_explore (dev=0xc4139940) at /usr/build/src/sys/bus/usb/uhub.c:460
#19 0xc025c6b7 in usb_discover (v=0xc695d9e0) at /usr/build/src/sys/bus/usb/usb.c:780
#20 0xc025bf71 in usb_event_thread (arg=0xc695d9e0) at /usr/build/src/sys/bus/usb/usb.c:469
gdb is broken somehow, the 0xdeadc0de arguments are not true, except for for kprintf.
(kgdb) fra 13
#13 0xc0260cfd in usb_disconnect_port (up=0xc415a178, parent=0xdeadc0de)
at /usr/build/src/sys/bus/usb/usb_subr.c:1382
1382 kprintf("%s: at %s", USBDEVPTRNAME,
(kgdb) p dev->subdevs0
$1 = 0xc415a190
(kgdb) p *dev->subdevs0
$2 = {ops = 0xc415abf8, link = {tqe_next = 0xdeadc0de, tqe_prev = 0xdeadc0de},
parent = 0xdeadc0de, children = {tqh_first = 0xdeadc0de, tqh_last = 0xdeadc0de},
driver = 0xdeadc0de, devclass = 0xdeadc0de, unit = -559038242,
nameunit = 0xdeadc0de <Address 0xdeadc0de out of bounds>,
desc = 0xdeadc0de <Address 0xdeadc0de out of bounds>, busy = -559038242, state = 3735929054,
devflags = 3735929054, flags = 49374, order = 173 '�', pad = 222 '�, ivars = 0xdeadc0de,
softc = 0x0}
this stick has an integrated usb hub.
dump arriving on leaf at ~corecode/crash/*13*
cheers
simon
Updated by sepherosa almost 18 years ago
No further child deletion means uhub has no children (i.e. umass) at
this point. Children probably detached long before we reach here but
uhub was not informed about the detaching.
Please
1) uncomment uhub.c line 744 recompile kernel and modules.
uhub_child_detached() is the place where uhub is informed about
children detaching. If child is not found in the upper loop, then
things probably go very wrong :(
2) give me the dmesg after you plugin the stick
3) give me the message printed on console immediately before panic
Best Regards,
sephe
Updated by alexh over 15 years ago
Does this bug still occur? Did anyone experience it lately? Is it worth keeping
this bug report open?
Updated by corecode over 15 years ago
Alex Hornung (via DragonFly issue tracker) wrote:
Does this bug still occur? Did anyone experience it lately? Is it worth keeping
this bug report open?
I lost the USB stick, but I'm sure the bug still exists.
cheers
simon
Updated by dillon over 15 years ago
:
:Alex Hornung (via DragonFly issue tracker) wrote:
:> Does this bug still occur? Did anyone experience it lately? Is it worth=
: keeping=20
:> this bug report open?
:
:I lost the USB stick, but I'm sure the bug still exists.
:
:cheers
: simon
I still get panics on boot when my USB keyboard is attached to certain
ports. It could be related.
-Matt
Updated by tuxillo almost 11 years ago
- Description updated (diff)
- Category set to Driver
- Assignee changed from 0 to tuxillo
- Target version set to 3.8
Grab.
Updated by tuxillo over 10 years ago
- Status changed from New to Feedback
Hi all,
Is there any way we can check this at all? We're using U4B now.
Matt, do you still have that keyboard/computer?
Best regards,
Antonio Huete
Updated by profmakx almost 10 years ago
- Status changed from Feedback to Closed
This is invalid with the new USB stack around.