Re: usb panic

I can confirm this, I posted about the same thing a few months ago, and was just told "not to do that", but if you have a fix I'd be willing to test it out.

--
Anish Mistry

----- Original Message -----
From: des_at_des.no (Dag-Erling Smørgrav)
Date: Monday, January 26, 2004 2:11 pm
Subject: usb panic

> Doing "kldunload ums; kldload ums" while a mouse was connected (to
> trigger a devd event without having to physically disconnect and
> reconnect the mouse) triggered the following panic:
> 
> kernel: type 12 trap, code=0
> Stopped at      strncpy+0x14:   movb    0(%edx),%al
> db> where
> strncpy(c66a6524,0,10,c1745504,c66a6400) at strncpy+0x14
> usbd_fill_deviceinfo(c5f92900,c66a6400,1,0,c05b707e) at 
> usbd_fill_deviceinfo+0x121usbioctl(c05ffe20,c1745504,c66a6400,1,c64aa690) at usbioctl+0x223
> spec_ioctl(ec00ab88,ec00ac34,c04f4c0f,ec00ab88,c05f7bc0) at 
> spec_ioctl+0xf2spec_vnoperate(ec00ab88) at spec_vnoperate+0x13
> vn_ioctl(c63f3aa0,c1745504,c66a6400,c66fb080,c64aa690) at 
> vn_ioctl+0x17fioctl(c64aa690,ec00ad14,3,1,282) at ioctl+0x37c
> syscall(2f,2f,2f,6,0) at syscall+0x22b
> Xint0x80_syscall() at Xint0x80_syscall+0x1d
> --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x880b7a17, esp = 
> 0xbfbfe2ac, ebp = 0xbfbfe458 ---
> 
> as usual, dumps are broken, but the code at least looks like this:
> 
> (gdb) l *(usbd_fill_deviceinfo+0x121)
> 0x33d5 is in usbd_fill_deviceinfo 
> (/usr/src/sys/dev/usb/usb_subr.c:1282).1277            if (dev-
> >subdevs != NULL) {
> 1278                    for (i = 0; dev->subdevs[i] &&
> 1279                                 i < USB_MAX_DEVNAMES; i++) {
> 1280                            strncpy(di->udi_devnames[i], 
> USBDEVPTRNAME(dev->subdevs[i]),
> 1281                                    USB_MAX_DEVNAMELEN);
> 1282                            di-
> >udi_devnames[i][USB_MAX_DEVNAMELEN-1] = '\0';
> 1283                    }
> 1284            } else {
> 1285                    i = 0;
> 1286            }
> 
> so dev->subdevs[i] is not NULL, but it does not have a name since
> USBDEVPTRNAME(dev->subdevs[i]) is NULL.  Looks like better locking and
> invariants are required; it shouldn't be possible (IMHO) for that code
> to stumble across an incomplete bdev.
> 
> (BTW, we should use strlcpy() here rather than strncpy())
> 
> DES
> -- 
> Dag-Erling Smørgrav - des_at_des.no
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-
> unsubscribe_at_freebsd.org"