panic 01/25/04 kernel in uhci uplcom

Shunsuke Akiyama akiyama at jp.FreeBSD.org
Sun Jan 30 07:01:16 PST 2005


At Thu, 27 Jan 2005 08:13:18 -0800,
Sean McNeil wrote:
> 
> On Wed, 2005-01-26 at 23:30 +0900, Shunsuke Akiyama wrote:
> > At Wed, 26 Jan 2005 00:25:49 -0800,
> > Sean McNeil wrote:
> > 
> > > I got a panic on a recent kernel:
> > > 
> > > FreeBSD server.mcneil.com 6.0-CURRENT FreeBSD 6.0-CURRENT #2: Fri Jan  7
> > > 18:21:53 PST 2005     root at server.mcneil.com:/usr/obj/usr/src/sys/AMD64
> > > amd64
> > > 
> > > Jan 25 23:50:39 server syslogd: kernel boot file
> > > is /boot/kernel.old/kernel
> > > Jan 25 23:50:39 server kernel: panic: uhci_abort_xfer: not in process
> > > context
> > > Jan 25 23:50:39 server kernel: Uptime: 1m39s
> > > Jan 25 23:50:39 server kernel: interrupt                   total
> > > Jan 25 23:50:39 server kernel: irq1: atkbd0                           2
> > > Jan 25 23:50:39 server kernel: irq0: clk                         323813
> > > Jan 25 23:50:39 server kernel: irq4: sio0                             5
> > > Jan 25 23:50:39 server kernel: irq8: rtc                          20738
> > > Jan 25 23:50:39 server kernel: irq14: ata0                          722
> > > Jan 25 23:50:39 server kernel: irq15: ata1                          186
> > > Jan 25 23:50:39 server kernel: irq16: re0                            62
> > > Jan 25 23:50:39 server kernel: irq17: fwohci0                         1
> > > Jan 25 23:50:39 server kernel: irq19: dc0                             2
> > > Jan 25 23:50:39 server kernel: irq20: atapci0                      6006
> > > Jan 25 23:50:39 server kernel: irq21: uhci0 uhci1+                  136
> > > Jan 25 23:50:39 server kernel: Total                      351673
> > > Jan 25 23:50:39 server kernel: KDB: stack backtrace:
> > > Jan 25 23:50:39 server kernel: hardclock() at hardclock+0x1eb
> > > Jan 25 23:50:39 server kernel: intr_execute_handlers() at
> > > intr_execute_handlers+0x102
> > > Jan 25 23:50:39 server kernel: lapic_handle_intr() at lapic_handle_intr
> > > +0x21
> > > Jan 25 23:50:39 server kernel: Xapic_isr1() at Xapic_isr1+0x7d
> > > Jan 25 23:50:39 server kernel: --- interrupt, rip = 0xffffffff802eb1e1,
> > > rsp = 0xffffffffb19187e0, rbp = 0xffffffffb1918810 ---
> > > Jan 25 23:50:39 server kernel: cv_wait() at cv_wait+0x1
> > > Jan 25 23:50:39 server kernel: ata_queue_request() at ata_queue_request
> > > +0x1e8
> > > Jan 25 23:50:39 server kernel: ata_controlcmd() at ata_controlcmd+0x8b
> > > Jan 25 23:50:39 server kernel: ata_shutdown() at ata_shutdown+0xb8
> > > Jan 25 23:50:39 server kernel: boot() at boot+0x25c
> > > Jan 25 23:50:39 server kernel: panic() at panic+0x167
> > > Jan 25 23:50:39 server kernel: uhci_abort_xfer() at uhci_abort_xfer+0x68
> > > Jan 25 23:50:39 server kernel: usbd_abort_pipe() at usbd_abort_pipe+0x27
> > > Jan 25 23:50:39 server kernel: ucomstopread() at ucomstopread+0x27
> > > Jan 25 23:50:39 server kernel: ucomstop() at ucomstop+0x2f
> > > Jan 25 23:50:39 server kernel: ttyflush() at ttyflush+0x34
> > > Jan 25 23:50:39 server kernel: ttymodem() at ttymodem+0x9e
> > > Jan 25 23:50:39 server kernel: ucom_status_change() at
> > > ucom_status_change+0x93
> > > Jan 25 23:50:39 server kernel: uplcom_intr() at uplcom_intr+0x94
> > > Jan 25 23:50:39 server kernel: usb_transfer_complete() at
> > > usb_transfer_complete+0x201
> > > Jan 25 23:50:39 server kernel: uhci_softintr() at uhci_softintr+0x100
> > > Jan 25 23:50:39 server kernel: uhci_intr1() at uhci_intr1+0xd5
> > > Jan 25 23:50:39 server kernel: ithread_loop() at ithread_loop+0xd3
> > > Jan 25 23:50:39 server kernel: fork_exit() at fork_exit+0x8f
> > > Jan 25 23:50:39 server kernel: fork_trampoline() at fork_trampoline+0xe
> > > Jan 25 23:50:39 server kernel: --- trap 0, rip = 0, rsp =
> > > 0xffffffffb1918d00, rbp = 0 ---
> > 
> > Oh, usbd_abort_pipe() and underlaying uhci_abort_xfer() should be
> > called from non interrupt context only.  uhci_abort_xfer() checks this
> > condition and make a panic.
> > 
> > This is not a problem only for uplcom(4).  Both umodem(4) and
> > uvscom(4) potentially have a same problem.
> > 
> > Please try attached patch and let me know the result.
> 
> This patch eliminated my panic.
> 
> Thanks,
> Sean

Thank you for reporting.
I'll commit these changes.

Regards,
-- 
Shunsuke Akiyama
akiyama at jp.FreeBSD.org
akiyama at FreeBSD.org


More information about the freebsd-current mailing list