Bug 27370
| Summary: | kernel crash when trying to query the USB device "wingman rumblepad" (logitech gamepad) | ||
|---|---|---|---|
| Product: | Base System | Reporter: | alec <alec> |
| Component: | kern | Assignee: | Nick Hibma <n_hibma> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
alec
2001-05-16 02:40:00 UTC
On Tue, May 15, 2001 at 06:31:15PM -0700, alec@barea.org wrote: > When booting, if the wingman rumblepad is plugged, the kernel is > crasjing when querying usb devices. If it's not plugged, no problem. > I it's plugged after the boot, device is recognized, then when > doing "usbdevs" the kernel crashes. > Kernel debugging is not enabled, so no core, can be enabled on > request if needed, just ask. We'll certainly need the panic message and maybe a bactrace from a vmcore and a debugging kernel. Can you produce these? David. David Malone wrote: > On Tue, May 15, 2001 at 06:31:15PM -0700, alec@barea.org wrote: > > When booting, if the wingman rumblepad is plugged, the kernel is > > crasjing when querying usb devices. If it's not plugged, no problem. > > I it's plugged after the boot, device is recognized, then when > > doing "usbdevs" the kernel crashes. > > > Kernel debugging is not enabled, so no core, can be enabled on > > request if needed, just ask. > > We'll certainly need the panic message and maybe a bactrace from > a vmcore and a debugging kernel. Can you produce these? > > David. Hello David, The only way i know to get the panic message is to write it down by hand, hopefully you have a better one, please tell me. I'm gonna enable the debug symbols in the kernel and get back to you as soon as it's done. Cheers, Alec Hi David, hi Alec, I got some infos for this problem. I attached a Logitech Wingman Force Feedback Wheel ;-) Other device, same problem... but I have the panic-message: --------------- uhci0: <VIA 83C572 USB controller> port 0xd400-0xd41f irq5 at device 4.2/ on pci0 usb0: <VIA 83C572 USB controller> on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhid0: Logitech Inc. product 0xc293, rev 1.00/1.01, addr 2, iclass 3/0 uhid0: no report descriptor device_probe_and_attach: uhid0 attach returned 6 ugen0: Logitech Inc. product 0xc293, rev 1.00/1.01, addr 2 ugen0: setting configuration index 0 failed device_probe_and_attach: ugen0 attach returned 6 uhci1: <VIA 83C572 USB controller> port 0xd000-0xd01f irq 5 at device 4.3/ on pci0 usb1: <VIA 83C572 USB controller> on uhci1 usb1: USB revision 1.0 Fatal trap12: page fault while in Kernel mode fault virtual address = 0x64003a fault code = supervisor read, page not present instruction pointer = 0x8:0xc016a8b2 stack pointer = 0x10:0xc03cb954 frame pointer = 0x10:0xc03cb968 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) interrupt mask = net tty bio cam trap number = 12 panic: page fault Uptime 0s -------------------------- bye... Thomas Hi,
On my current box (running current from yesterday) the problem seems to be
that uhid.c's attach function is trying to free the same memory twice.
uhid_attach calls usbd_alloc_report_desc (line 229 or so),
usbd_alloc_report_desc calls usbd_get_report_desc which fails.
The usbd_alloc_report_desc free's the descriptor, and then
uhid_attach tries to free it again. uhid_attach seems to be the only function
which tries to free the descriptor if usbd_alloc_report_desc fails. Removing
the free fixes this.
Thanks,
Ian
*** uhid.c.orig Fri Jun 29 13:43:28 2001
--- uhid.c Fri Jun 29 13:43:46 2001
***************
*** 230,237 ****
if (err) {
printf("%s: no report descriptor\n", USBDEVNAME(sc->sc_dev));
sc->sc_dying = 1;
- if (desc != NULL)
- free(desc, M_USBDEV);
USB_ATTACH_ERROR_RETURN;
}
--- 230,235 ----
;
Responsible Changed From-To: freebsd-bugs->n_hibma Nick - this PR contains a sensible looking patch - though it looks like usbd_alloc_report_desc should also set *descp to NULL before returning in it's last error case. State Changed From-To: open->closed Committed. Thanks! You're a star! You've just fixed a long standing bug for me :-) |
