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. Fix: er...don't use the gamepad? ;) How-To-Repeat: just plug the gamepad and boot, or use "usbdevs"
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 :-)