>Number:         36276
>Category:       kern
>Synopsis:       ucycom causes kernel panic when accessing Delorme USB Earthmate LT-20 GPS
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri May 04 21:25:00 +0000 2007
>Originator:     David Howland
>Release:        NetBSD 4.99.18
>Organization:
>Environment:
NetBSD micron 4.99.18 NetBSD 4.99.18 (GENERIC) #10: Fri May  4 12:20:18 EDT 2007  root@micron:/usr/obj/sys/arch/i386/compile/GENERIC i386
>Description:
The ucycom driver causes a kernel panic when trying to access my USB GPS device.

Running -current on a i386 and a GENERIC kernel.

Support for the Delorme USB Earthmate LT-20 GPS device is not yet working.  Nick Hudson has committed the USB vendor and product codes, but the ucycom driver does not yet take ownership of the device like it is supposed to.

I have modified my kernel to make the ucycom driver recognize the device.

The dmesg report looks like this:

uhidev0 at uhub0 port 1 configuration 1 interface 0
uhidev0: DeLorme Publishing DeLorme USB Earthmate, rev 1.00/0.01, addr 
2, iclass 3/0
ucycom0 at uhidev0

I did a MAKEDEV ttyY0 to create the /dev entry.

However...

Any access to /dev/ttyY0 results in an immediate kernel panic.

Here is the backtrace from GDB:


#21 0xc010b677 in calltrap ()
#22 0xc043c66d in sleepq_enqueue (sq=0xc0a299b0, pri=22, wchan=0xc15fb700,
     wmesg=0xc091c0fd "uhidevwi", sobj=0xc098d5d0) at 
/usr/src/sys/kern/kern_sleepq.c:216
#23 0xc043ca4a in sleepq_block (sq=0xc0a299b0, pri=22, wchan=0xc15fb700,
     wmesg=0xc091c0fd "uhidevwi", timo=0, catch=true, sobj=0xc098d5d0)
     at /usr/src/sys/kern/kern_sleepq.c:295
#24 0xc043f003 in ltsleep (ident=0xc15fb700, priority=278, 
wmesg=0xc091c0fd "uhidevwi", timo=0,
     interlock=0x0) at /usr/src/sys/kern/kern_synch.c:492
#25 0xc06a60f4 in usbd_intr_transfer (xfer=0xc15fb700, pipe=0xc164d300, 
flags=0, timeout=0,
     buf=0xc15bf620, size=0xcaf31e1c, lbl=0xc091c0fd "uhidevwi")
     at /usr/src/sys/dev/usb/usbdi_util.c:495
#26 0xc06b4936 in uhidev_write (sc=0x0, data=0xc15bf620, len=32)
     at /usr/src/sys/dev/usb/uhidev.c:644
#27 0xc06b91e5 in ucycomstart (tp=0xcaf02b84) at 
/usr/src/sys/dev/usb/ucycom.c:569
#28 0xc045fde8 in ttstart (tp=0xc098d5d0) at /usr/src/sys/kern/tty.c:1566
#29 0xc04620ac in ttyinput_wlock (c=-1063085648, tp=0xcaf02b84) at 
/usr/src/sys/kern/tty.c:692
#30 0xc046440d in ttyinput (c=50, tp=0xc098d5d0) at 
/usr/src/sys/kern/tty.c:716
#31 0xc06b8bbe in ucycom_intr (addr=0xc15c0d00, ibuf=0xc15bf600, len=32)
     at /usr/src/sys/dev/usb/ucycom.c:913
#32 0xc06b4db4 in uhidev_intr (xfer=0xc1524800, addr=0xc15c1e80, 
status=USBD_NORMAL_COMPLETION)
     at /usr/src/sys/dev/usb/uhidev.c:455
#33 0xc06a53ea in usb_transfer_complete (xfer=0xc1524800) at 
/usr/src/sys/dev/usb/usbdi.c:824
#34 0xc030da04 in uhci_idone (ii=<value optimized out>) at 
/usr/src/sys/dev/usb/uhci.c:1529
#35 0xc030e4d1 in uhci_softintr (v=0xc1527000) at 
/usr/src/sys/dev/usb/uhci.c:1404
#36 0xc04d2c5f in softintr_dispatch (which=1) at 
/usr/src/sys/arch/x86/x86/softintr.c:104
#37 0xc010b33a in Xsoftnet ()


The only thing I notice is the worrying "sc=0x0" argument to uhidev_write.

If I compile the ucycom driver with #define UCYCOM_DEBUG  and  ucycomdebug=11,

cat /dev/ttyY0 results in the following output before the crash.


ucycomopen: unit=0
ucycomopen: sc=0xc15e7300
ucycomopen: tp=0xcaf02754
ucycomparam: baud=0
ucycomparam: l_modem
ucycomopen: sc->sc_obuf=0xc15bf740
ucycomread: sc=0xc15e7300, tp=0xcaf02754, uio=0xcc0fcbb0, flag=0
ucycom_intr: ibuf[0..30) = 24 50 53 54 4d 56 45 52 2c 47 50 53 20 56 65 72 73 69 6f 6e 20 34 2e 32 30 2e 35 20 52 65
ucycom_intr: char=0x24
ucycomstart(32): sc->sc_obuf[0] = 0
sc->sc_obuf[1] = 1
ucycomstart(32): data = 24
ucycomstart: sc->sc_obuf[0..32) = 00 01 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

This is where the kernel panics with a page fault.
the first 'sync' in ddb gives...

syncing disks... ucycom_intr: ibuf[0..30) = 24 50 53 54 4d 56 45 52 2c 47 50 53 20 56 65 72 73 69 6f 6e 20 34 2e 32 30 2e 35 20 52 65
ucycom_intr: char=0x24
ucycomstart: no go, state=0x4c
ucycom_intr: char=0x50
ucycomstart: no go, state=0x4c
...
ucycom_intr: char=0x52
ucycomstart: no go, state=0x4c
ucycom_intr: char=0x65
ucycomstart: no go, state=0x4c

Second 'sync' finally makes it dump core and reboot.


I'm fairly sure that the LT-20 should work the same as the original USB earthmate that is already supported by the ucycom driver (they have the same cypress comm. controller), however, even if the driver is not ready, it should not result in a kernel panic.


>How-To-Repeat:
Start with a -current kernel from after May 3rd, 2007.
Patch src/sys/dev/usb/ucycom.c as follows:

--- ucycom.c.orig	2007-05-02 23:25:30.000000000 -0400
+++ ucycom.c
@@ -175,6 +175,7 @@ Static void ucycom_get_cfg(struct ucycom
  Static const struct usb_devno ucycom_devs[] = {
  	{ USB_VENDOR_CYPRESS, USB_PRODUCT_CYPRESS_USBRS232 },
  	{ USB_VENDOR_DELORME, USB_PRODUCT_DELORME_EARTHMATE },
+	{ USB_VENDOR_DELORME, USB_PRODUCT_DELORME_EARTHMATE_LT20 },
  };
  #define ucycom_lookup(v, p) usb_lookup(ucycom_devs, v, p)


Then compile a kernel and plug in a Delorme USB Earthmate LT-20 GPS.

then, as root, try to access /dev/ttyY0

>Fix:
no fix yet