Committed by Sascha:
http://www.dragonflybsd.org/cvsweb/src/sys/dev/usbmisc/uplcom/uplcom.c?rev=1.9&content-type=text/x-cvsweb-markup

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

Sascha

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.

: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 
					<dillon@backplane.com>

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

No crashes so far.

 Johannes

:...
:
: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 
					<dillon@backplane.com>

Hi,
On Tue, Nov 07, 2006 at 10:01:17PM +0000, Johannes Hofmann wrote:
> Johannes Hofmann <Johannes.Hofmann@gmx.de> 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.

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

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