Date: Thu, 31 Mar 2005 07:49:58 -0500 From: Mike Tancsa <mike@sentex.net> To: ticso@cicely.de Cc: freebsd-usb@freebsd.org Subject: panic: uhci_abort_xfer: not in process context (was Re: uplcom / ucom problems on RELENG_5) Message-ID: <6.2.1.2.0.20050331074641.04f72eb8@64.7.153.2> In-Reply-To: <6.2.1.2.0.20050330145628.053abc68@64.7.153.2> References: <6.2.1.2.0.20050329222822.04f7c500@64.7.153.2> <20050330104102.GK33677@cicely12.cicely.de> <6.2.1.2.0.20050330071753.055388b8@64.7.153.2> <20050330124923.GR33677@cicely12.cicely.de> <6.2.1.2.0.20050330085751.03594e08@64.7.153.2> <20050330141443.GA33677@cicely12.cicely.de> <6.2.1.2.0.20050330092200.047a7928@64.7.153.2> <20050330143836.GB33677@cicely12.cicely.de> <6.2.1.2.0.20050330094120.02fca188@64.7.153.2> <6.2.1.2.0.20050330103630.047abfa8@64.7.153.2> <6.2.1.2.0.20050330145628.053abc68@64.7.153.2>
next in thread | previous in thread | raw e-mail | index | archive | help
Unfortunately the box coredumped overnight
putc to a clist with no reserved cblocks
putc to a clist with no reserved cblocks
putc to a clist with no reserved cblocks
putc to a clist with no reserved cblocks
panic: uhci_abort_xfer: not in process context
Uptime: 6h55m12s
Dumping 254 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
Dump complete
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
Console: serial port
[releng5-865]# kgdb kernel.debug /var/crash/vmcore.5
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:=
=20
Undefined symbol "ps_pglobal_lookup"]
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".
#0 doadump () at pcpu.h:159
159 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (td));
(kgdb) bt full
#0 doadump () at pcpu.h:159
No locals.
#1 0xc051fa5e in boot (howto=3D260) at ../../../kern/kern_shutdown.c:410
first_buf_printf =3D 1
#2 0xc051fcf4 in panic (fmt=3D0xc06fc4ee "uhci_abort_xfer: not in process=
=20
context") at ../../../kern/kern_shutdown.c:566
td =3D (struct thread *) 0xc1502000
bootopt =3D 260
newpanic =3D 0
ap =3D 0xc1502000 "\020\aP=C1 =E9O=C1"
buf =3D "uhci_abort_xfer: not in process context", '\0' <repeats=
216=20
times>
#3 0xc04c5c47 in uhci_abort_xfer (xfer=3D0xc183ed00,=20
status=3DUSBD_NORMAL_COMPLETION) at ../../../dev/usb/uhci.c:1958
uxfer =3D (struct uhci_xfer *) 0xc183ed00
ii =3D (uhci_intr_info_t *) 0xc183ed6c
upipe =3D (struct uhci_pipe *) 0xc19c7e00
sc =3D (uhci_softc_t *) 0xc15b8000
std =3D (uhci_soft_td_t *) 0x0
#4 0xc04c5bc9 in uhci_device_bulk_abort (xfer=3D0xc183ed00) at=20
../../../dev/usb/uhci.c:1921
No locals.
#5 0xc04d2ebb in usbd_ar_pipe (pipe=3D0xc19c7e00) at=20
../../../dev/usb/usbdi.c:762
xfer =3D 0x0
#6 0xc04d2c1f in usbd_abort_pipe (pipe=3D0xc19c7e00) at=20
../../../dev/usb/usbdi.c:556
err =3D USBD_NORMAL_COMPLETION
#7 0xc04c3cf5 in ucomstopread (sc=3D0x0) at ../../../dev/usb/ucom.c:1160
No locals.
#8 0xc04c38ba in ucomstop (tp=3D0xc171c000, flag=3D1) at=20
../../../dev/usb/ucom.c:934
sc =3D (struct ucom_softc *) 0xc1754c00
#9 0xc054b393 in ttyflush (tp=3D0xc171c000, rw=3D1) at=
../../../kern/tty.c:1420
No locals.
#10 0xc054974d in ttyinput (c=3D26, tp=3D0xc171c000) at=
../../../kern/tty.c:445
iflag =3D 11010
lflag =3D 1483
cc =3D (cc_t *) 0xc171c0b4=20
"\004=FF=FF\177\027\025\022\b\003\034\032\031\021\023\026\017\001"
i =3D 0
err =3D 0
#11 0xc04c3be5 in ucomreadcb (xfer=3D0xc183ed00, p=3D0xc1754c00,=20
status=3DUSBD_NORMAL_COMPLETION) at linedisc.h:122
sc =3D (struct ucom_softc *) 0xc1754c00
tp =3D (struct tty *) 0xc171c000
err =3D USBD_NORMAL_COMPLETION
cc =3D 69
cp =3D (
u_char *) 0xc175f099 "\032\033\034\035\036\037=20
!\"#$%&'()*+,-./0123456789:;<=3D>?@ABCDEFGHIJKLMNOPQRSTUV\021=20
~~=FF}#=C0BCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abc"
lostcc =3D 0
#12 0xc04d2ffc in usb_transfer_complete (xfer=3D0xc183ed00) at=20
../../../dev/usb/usbdi.c:851
pipe =3D 0xc19c7e00
dmap =3D (usb_dma_t *) 0xc183ed3c
---Type <return> to continue, or q <return> to quit---
sync =3D 0
erred =3D 0
repeat =3D 0
polling =3D 0
#13 0xc04c54af in uhci_idone (ii=3D0x0) at ../../../dev/usb/uhci.c:1500
xfer =3D 0xc183ed00
upipe =3D (struct uhci_pipe *) 0xc19c7e00
std =3D (uhci_soft_td_t *) 0x0
status =3D 0
nstatus =3D 0
actlen =3D 222
#14 0xc04c538c in uhci_check_intr (sc=3D0xc15b8000, ii=3D0xc183ed6c) at=20
../../../dev/usb/uhci.c:1375
std =3D (uhci_soft_td_t *) 0x0
lstd =3D (uhci_soft_td_t *) 0xc15e8f20
status =3D 0
#15 0xc04c52de in uhci_softintr (v=3D0xc15b8000) at=
../../../dev/usb/uhci.c:1305
sc =3D (uhci_softc_t *) 0xc15b8000
ii =3D (uhci_intr_info_t *) 0x0
nextii =3D (uhci_intr_info_t *) 0xc199d26c
#16 0xc04d0499 in usb_schedsoftintr (bus=3D0x0) at=
../../../dev/usb/usb.c:864
No locals.
#17 0xc04c52ab in uhci_intr1 (sc=3D0xc15b8000) at=
../../../dev/usb/uhci.c:1275
status =3D 1
ack =3D 1
#18 0xc04c513c in uhci_intr (arg=3D0xc15b8000) at=
../../../dev/usb/uhci.c:1190
sc =3D (uhci_softc_t *) 0x0
#19 0xc050c371 in ithread_loop (arg=3D0xc14f7580) at=20
../../../kern/kern_intr.c:547
ithd =3D (struct ithd *) 0xc14f7580
ih =3D (struct intrhand *) 0xc15df680
td =3D (struct thread *) 0xc1502000
p =3D (struct proc *) 0xc1500710
count =3D 0
warming =3D 0
warned =3D 0
#20 0xc050b604 in fork_exit (callout=3D0xc050c220 <ithread_loop>,=20
arg=3D0xc14f7580, frame=3D0xcbca3d48) at ../../../kern/kern_fork.c:790
p =3D (struct proc *) 0xc1500710
td =3D (struct thread *) 0x0
#21 0xc06a2afc in fork_trampoline () at ../../../i386/i386/exception.s:209
No locals.
(kgdb)
At 04:02 PM 30/03/2005, Mike Tancsa wrote:
>At 10:37 AM 30/03/2005, Mike Tancsa wrote:
>>At 09:54 AM 30/03/2005, Mike Tancsa wrote:
>>
>>>>So far I only know about reconnecting, which likely isn't an
>>>>acceptable workaround for you.
>>>
>>>Thanks, you mean reconnecting the USB device ? Sadly no, that wont work=
=20
>>>for us when the unit is 80km away :( Or is there a way to do this=20
>>>programtically?
>>
>>I wonder if "set choked" in ppp might be tuned a bit to avoid this=20
>>issue. Time to experiment a bit.
>
>So far so good. If I change add "set choked 10", I am not able to hang=20
>the usb port like I was before.
>
>The value is quite a change from the default 120 seconds, but still 10=20
>seconds to transmit (for my application anyways which is a modem backup if=
=20
>the DSL fails) is adequate. I am going to let it run 48hrs to see if it=20
>still stable. On one device, I am running just continuous pings, and I am=
=20
>kicking off the connection every 10 min from the terminal server. On=20
>another machine, I am running it with random bursts of data and kicking it=
=20
>off every 5min.
>
> ---Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.2.1.2.0.20050331074641.04f72eb8>