Bug #1488: panic: ohci_abort_xfer: not in process context - DragonFlyBSD - DragonFlyBSD bugtracker

Actions

Copy link

Bug #1488

closed

panic: ohci_abort_xfer: not in process context

Added by rumcic about 15 years ago. Updated over 11 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Category:

Target version:

Start date:

Due date:

% Done:

Estimated time:

Description

Noticed on latest master that the usb stack is broken for me (well, the umass
part that is) on both my dfly master installations (on one, I had previous
problems with usb, for example with ehci none of the umass devices get
detected, the other installation had no problems with usb up till now).

Inserted an usb flash drive into the usb port and started a dd of=/dev/da8
(tried to dd a dfly usb image onto the flash drive). After a second of
activity on the flash drive, dd got stuck in physstr state and the whole usb
stack seemed to be blocked (had a usb mouse plugged in which stopped
responding). After playing around a bit I disconnected a tip(1) session on
ucom0 (have an usb->serial converter so that I can abuse the serial console on
another machine) and a panic occured.
Note: I'm not sure but during the playing around I think I also tried
kldloading ehci to see if anything happened.

The dump is located at leaf:~rumko/crash/ohci and the backtrace is:
#0 dumpsys () at ./machine/thread.h:83
#1 0xc01e6d95 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:375
#2 0xc01e705a in panic (fmt=0xc047b884 "ohci_abort_xfer: not in process
context") at /usr/src/sys/kern/kern_shutdown.c:802
#3 0xc036d9c2 in ohci_abort_xfer (xfer=0xc5c24268, status=USBD_CANCELLED)
at /usr/src/sys/bus/usb/ohci.c:2257
#4 0xc036dcb6 in ohci_device_bulk_abort (xfer=0xc5c24268)
at /usr/src/sys/bus/usb/ohci.c:3028
#5 0xc0375454 in usbd_abort_pipe (pipe=0xc5bc6ee0)
at /usr/src/sys/bus/usb/usbdi.c:741
#6 0xc0370aad in ucomstopread (sc=0xc5c6d218)
at /usr/src/sys/dev/usbmisc/ucom/ucom.c:1181
#7 0xc0371098 in ucomstop (tp=0xd554a770, flag=1)
at /usr/src/sys/dev/usbmisc/ucom/ucom.c:943
#8 0xc02118ad in ttyflush (tp=0xd554a770, rw=1)
at /usr/src/sys/kern/tty.c:1357
#9 0xc0211bbd in ttylclose (tp=0xd554a770, flag=<value optimized out>)
at /usr/src/sys/kern/tty.c:1339
#10 0xc0371b85 in ucomclose (ap=0xfa7ffb3c)
at /usr/src/sys/dev/usbmisc/ucom/ucom.c:461
#11 0xc01cd516 in dev_dclose (dev=0xc5c45800, fflag=3, devtype=8192)
at /usr/src/sys/kern/kern_device.c:127
#12 0xc032d440 in devfs_spec_close (ap=0xfa7ffb80)
at /usr/src/sys/vfs/devfs/devfs_vnops.c:922
#13 0xc0240a3a in vop_close (ops=0xd554bcd0, vp=0xf63581e8, fflag=3)
at /usr/src/sys/kern/vfs_vopops.c:258
#14 0xc023fcf4 in vn_close (vp=0xf63581e8, flags=3)
at /usr/src/sys/kern/vfs_vnops.c:396
#15 0xc032bd4d in devfs_specf_close (fp=0xdc723c60)
at /usr/src/sys/vfs/devfs/devfs_vnops.c:961
#16 0xc01cf643 in fdrop (fp=0xdc723c60) at /usr/src/sys/sys/file2.h:121
#17 0xc01cf96e in closef (fp=0xdc723c60, p=0xdc62ef58)
at /usr/src/sys/kern/kern_descrip.c:2288
#18 0xc01cfe2f in fdfree (p=0xdc62ef58, repl=0x0)
at /usr/src/sys/kern/kern_descrip.c:1926
#19 0xc01d6572 in exit1 (rv=0) at /usr/src/sys/kern/kern_exit.c:350
#20 0xc01d6917 in sys_exit (uap=0xfa7ffcf0)
at /usr/src/sys/kern/kern_exit.c:116
#21 0xc03fa8e9 in syscall2 (frame=0xfa7ffd40)
at /usr/src/sys/platform/pc32/i386/trap.c:1339
#22 0xc03e7be6 in Xint0x80_syscall ()
at /usr/src/sys/platform/pc32/i386/exception.s:876
#23 0x280e4bcb in ?? ()
--
Regards,
Rumko

Actions

Copy link

Updated by dillon about 15 years ago

:Inserted an usb flash drive into the usb port and started a dd of=/dev/da8
:(tried to dd a dfly usb image onto the flash drive). After a second of
:activity on the flash drive, dd got stuck in physstr state and the whole usb
:stack seemed to be blocked (had a usb mouse plugged in which stopped
:responding). After playing around a bit I disconnected a tip(1) session on

This has happened to me.

:ucom0 (have an usb->serial converter so that I can abuse the serial console on
:another machine) and a panic occured.
:Note: I'm not sure but during the playing around I think I also tried
:kldloading ehci to see if anything happened.

I looked at your kernel core.  The two problems are related.  The USB
    interrupt is trying to allocate memory from its interrupt and is stuck
    in contigmalloc().  That leaves the interrupt count bumped and
    caused the assertion when you disconnected from the tip session.

Basically folks we need to significantly rewrite the usb driver.
    I'll see if I can at least get the memory allocations out of
    the interrupt code at least, that might help matters.