Project

General

Profile

Bug #361

uplcom(4) update from FreeBSD

Added by Johannes.Hofmann almost 14 years ago. Updated almost 14 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Hi Sascha, me objects :-)
I just got two crashes while accessing the updated driver...
Unfortunately no dumps though. I will try to fix this.
Is anyone using the current version of uplcom without problems?

Johannes

History

#1

Updated by Johannes.Hofmann almost 14 years ago

Ok, I finally got a core dump. The dump device was too small after
a memory upgrade...

Here is what I got:

(kgdb) bt
#0 dumpsys () at thread.h:83
#1 0xc028d3c3 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:355
#2 0xc028da56 in panic (
fmt=0xc06cb0e8 "uhci_abort_xfer: not in process context")
at /usr/src/sys/kern/kern_shutdown.c:757
#3 0xc06b802b in uhci_abort_xfer (xfer=0xc330c920, status=USBD_CANCELLED)
at /usr/src/sys/bus/usb/usb/../../../bus/usb/uhci.c:1934
#4 0xc06b7f80 in uhci_device_bulk_abort (xfer=0x0)
at /usr/src/sys/bus/usb/usb/../../../bus/usb/uhci.c:1900
#5 0xc06b4d6e in usbd_ar_pipe (pipe=0xc328bfe0)
at /usr/src/sys/bus/usb/usb/../../../bus/usb/usbdi.c:746
#6 0xc06b4a6d in usbd_abort_pipe (pipe=0x0)
at /usr/src/sys/bus/usb/usb/../../../bus/usb/usbdi.c:548
#7 0xc06e477d in ucomstopread ()
#8 0xc06e41b5 in ucomstop ()
#9 0xc02b1f91 in ttyflush (tp=0xea7e2190, rw=3)
at /usr/src/sys/kern/tty.c:1323
#10 0xc02b02ca in ttyinput (c=3, tp=0xea7e2190) at /usr/src/sys/kern/tty.c:459
#11 0xc06e4639 in ucomreadcb ()
#12 0xc06b4e90 in usb_transfer_complete (xfer=0xea7e2190)
at /usr/src/sys/bus/usb/usb/../../../bus/usb/usbdi.c:830
#13 0xc06b76d2 in uhci_idone (ii=0x0)
at /usr/src/sys/bus/usb/usb/../../../bus/usb/uhci.c:1480
---Type <return> to continue, or q <return> to quit---
#14 0xc06b75b4 in uhci_check_intr (sc=0xd6f345c0, ii=0xc330c990)
at /usr/src/sys/bus/usb/usb/../../../bus/usb/uhci.c:1355
#15 0xc06b750e in uhci_softintr (v=0xd6f345c0)
at /usr/src/sys/bus/usb/usb/../../../bus/usb/uhci.c:1282
#16 0xc06b23aa in usb_schedsoftintr (bus=0x0)
at /usr/src/sys/bus/usb/usb/../../../bus/usb/usb.c:831
#17 0xc06b74cc in uhci_intr1 (sc=0xd6f345c0)
at /usr/src/sys/bus/usb/usb/../../../bus/usb/uhci.c:1246
#18 0xc06b734e in uhci_intr (arg=0xd6f345c0)
at /usr/src/sys/bus/usb/usb/../../../bus/usb/uhci.c:1161
#19 0xc02716dd in ithread_handler (arg=0xb)
at /usr/src/sys/kern/kern_intr.c:766
#20 0xc0293f30 in lwkt_create (func=0, arg=0x0, tdp=0xc05abfe8, template=0x0,
tdflags=Cannot access memory at address 0x18
) at /usr/src/sys/kern/lwkt_thread.c:1290
Previous frame inner to this frame (corrupt stack?)
(kgdb)

This after some ^C and cable pulling while using /dev/ucom0.

Regards,
Johannes

#2

Updated by qhwt+dfly almost 14 years ago

Hi,
On Tue, Nov 07, 2006 at 10:01:17PM +0000, Johannes Hofmann wrote:
> Johannes Hofmann <> wrote:
> > Hi Sascha, me objects :-)
> > I just got two crashes while accessing the updated driver...
> > Unfortunately no dumps though. I will try to fix this.
>
> Ok, I finally got a core dump. The dump device was too small after
> a memory upgrade...
>
> Here is what I got:
>
> (kgdb) bt
> #0 dumpsys () at thread.h:83
> #1 0xc028d3c3 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:355
> #2 0xc028da56 in panic (
> fmt=0xc06cb0e8 "uhci_abort_xfer: not in process context")
> at /usr/src/sys/kern/kern_shutdown.c:757
> #3 0xc06b802b in uhci_abort_xfer (xfer=0xc330c920, status=USBD_CANCELLED)
:
> (kgdb)
>
> This after some ^C and cable pulling while using /dev/ucom0.

Apparently uplcom.c in FreeBSD now uses taskqueue to avoid this situation.
I'm not sure we can do it the same way, though.

revision 1.27
date: 2005-01-31 22:58:10 +0900; author: akiyama; state: Exp; lines: +18 -0;
Use a taskqueue to handle port status changes.
Calling ucom layer directly from interrupt context make a panic.

MFC after: 1 week

Cheers.

#3

Updated by dillon almost 14 years ago

:...
:
:Apparently uplcom.c in FreeBSD now uses taskqueue to avoid this situation.
:I'm not sure we can do it the same way, though.
:
: revision 1.27
: date: 2005-01-31 22:58:10 +0900; author: akiyama; state: Exp; lines: +18 -0;
: Use a taskqueue to handle port status changes.
: Calling ucom layer directly from interrupt context make a panic.
:
: MFC after: 1 week
:
:Cheers.

Yah, you'll have to port the taskqueue change.

The panic is not *actually* due to a missing process context, because
the curproc check was removed from that particular codepath. It's due
to the routine being called from an interrupt. The procedure does
some nasty stuff, including calling tsleep(), so it really can't be
called directly from an interrupt.

-Matt
Matthew Dillon
<>

#4

Updated by Johannes.Hofmann almost 14 years ago

Thanks for the hint! I have an updated patch at
http://www.ecademix.com/JohannesHofmann/uplcom2.diff.gz

No crashes so far.

Johannes

#5

Updated by dillon almost 14 years ago

:Thanks for the hint! I have an updated patch at
:http://www.ecademix.com/JohannesHofmann/uplcom2.diff.gz
:
:No crashes so far.
:
: Johannes

The patch looks very good. Do you think its ready for commit on Monday
or do you want some more time to work on it?

-Matt
Matthew Dillon
<>

#6

Updated by Johannes.Hofmann almost 14 years ago

I think it's ready for commit. However I am also thinking about porting
some changes to the generic ucom driver from FreeBSD.
But that should probabely be done separately.

#7

Updated by swildner almost 14 years ago

Allright, I've committed it. Thanks for submitting.

Sascha

Also available in: Atom PDF