RE: kernel panic in usb0; was: RE: using vkbd device
In gdb bt only shows two entries. The function where the panic occurred and 0x0! that is normal you don't want to jump into gdb that soon. there is hardly anything set up. use the sysctl to enter gdb later. BTW, after boot -gd, when gdb attaches I have a kernel panic too. But I can just enter continue and the kernel continues booting. Is that ok? what do you mean panic? I never use -gd, just -g then hitting ^ALT-ESC or using th esysctl makes me enter the debugger when I need to. Ok, may be, I am doing something stupidly wrong. 1. Added DIAGNOSTIC, USB_DEBUG, INVARIANT_SUPPORT, INVARIANTS to my configuration and installed a new debug kernel. 2. Booted the target to the loader prompt. unload kernel load kerneld boot -gd 3. gdb -k kernel.debug target remote /dev/cuaa0 on my workstation. 4. Arrived in Debugger() and pressed c. 5. The kernel booted. I saw the usual boot messages. After seeing IP filtering initialized..., I saw: panic: usb_cold_explore: busses to explore when !cold. 6. Found, that cold is indeed 0. 7. Booted again up to 4. and set a breakpoint at usb_cold_explore(). Pressed c and got (from gdb): Continuing. Cannot insert breakpoint 1: Cannot access memory at address 0xc01e5a37. At the same time the target console showed twice: Fatal trap 12: page fault... ... supervisor read, page not present ... So, do I have something very wrong in my kernel configuration? (See attached file) What about HZ=400 and NO_SWAPPING? Any known problems? Can't I set a breakpoint at that early stage of booting? Thanks for any help, Norbert MOPSD Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: kernel panic in usb0; was: RE: using vkbd device
When quickly connecting/disconnecting i guess you mean here unplug the keyboard and then immediately plug it back, right? sounds like he means repeatedly. yes booting with -gd drops you into the (gdb) debugger immediatly.. I presume you have a gdb looking at the serial port and have a serial debug port defined then? Yes. That's what I did: boot -gd gdb -k kernel.debug target remote /dev/cuaa0 In gdb bt only shows two entries. The function where the panic occurred and 0x0! BTW, after boot -gd, when gdb attaches I have a kernel panic too. But I can just enter continue and the kernel continues booting. Is that ok? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: kernel panic in usb0; was: RE: using vkbd device
When quickly connecting/disconnecting i guess you mean here unplug the keyboard and then immediately plug it back, right? I mean plug in / plug out, repeat for ever. can you tell what value pipe handle has? i suspect its NULL yes can you tell what value iface handle has? i suspect its NULL yes thats ok. splusb is defined as splbio oh, ok. what is your usb controller? uhci/ohci? what chip? ohci AcerLabs M5237 (Aladdin-V) please compile kernel with DIAGNOSTIC and USB_DEBUG. then try to adjust various debug knobs with sysctl(8) to get debug traces. at this point it looks like a race condition of some sort (to me). ok, I'll try this. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic in usb0; was: RE: using vkbd device
Norbert Koch wrote: When quickly connecting/disconnecting i guess you mean here unplug the keyboard and then immediately plug it back, right? sounds like he means repeatedly. yes booting with -gd drops you into the (gdb) debugger immediatly.. I presume you have a gdb looking at the serial port and have a serial debug port defined then? Yes. That's what I did: boot -gd gdb -k kernel.debug target remote /dev/cuaa0 In gdb bt only shows two entries. The function where the panic occurred and 0x0! that is normal you don't want to jump into gdb that soon. there is hardly anything set up. use the sysctl to enter gdb later. BTW, after boot -gd, when gdb attaches I have a kernel panic too. But I can just enter continue and the kernel continues booting. Is that ok? what do you mean panic? I never use -gd, just -g then hitting ^ALT-ESC or using th esysctl makes me enter the debugger when I need to. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel panic in usb0; was: RE: using vkbd device
The ukbd-specific detaching only works, because I implemented something in ukbd.c, that Hans Petter Selasky [EMAIL PROTECTED] suggested in thread usbd.conf: detach ukbd. (See the patch files, I posted there) When the kernel panics, it does this in usb0 kernel thread. I figured out that this is only related to connecting/disconnecting the usb keyboard. It panics without kbdmux loaded and it panics with unmodified ukbd.c. So I'll have to try to remote debug it, as my embedded device has no swap space at all and so no core dump device (256MB flash/256 MD dram). Hello, I am observing spurious crashes in usb0 under FreeBSD 4.11. Kernel configuration/hardware: HZ=400, NO_SWAPPING, DEVICE_POLLING (with kern.polling.user_frac=90), fxp ethernet, 6x sio, ohci, Pentium MMX 166 MHz When quickly connecting/disconnecting a usb keyboard, after some time I have a panic in process 3 (usb0), either at usbd_ar_pipe+0x7 (when detaching) or at usbd_get_interface_descriptor+0x6 (when attaching). Stack traces are: (a) usbd_ar_pipe+0x7 usbd_ar_pipe(0,...) usbd_abort_pipe(0,...) ukbd_enable_intr() ukbd_term() ukbd_detach() DEVICE_DETACH() device_detach() device_delete_child() usb_discommect_port() uhub_explore() usb_discover() usb_event_thread() (b) usbd_get_interface_descriptor+0x6 usbd_get_interface_descriptor(0) ukbd_attach(c0bf3b80) DEVICE_ATTACH() device_probe_and_attach() usbd_probe_and_attach() usbd_new_device() uhub_explore() usb_discover() usb_event_thread() In situation(a), ipl is at bio, ks_intr_pipe is NULL when calling usbd_abort_pipe(). In situation (b), ipl is at none, USB_ATTACH_START() in USB_ATTACK(ukbd) in ukbd.c seems to make problems. The above stack traces are from ddb. Booting the kernel with -gd and using gdb -k didn't give more information. I almost always get an unusable empty stack trace and different crash addresses. It seems like 'usbd_setup_pipe: failed to start endpoint, IOERROR' always comes before the crash and ipl is mostly at bio, never at usb. When I'm doing these tests, I have an ssh console connected through fxp0 where I run usbd -dv. Any idea? Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic in usb0; was: RE: using vkbd device
Norbert, The ukbd-specific detaching only works, because I implemented something in ukbd.c, that Hans Petter Selasky [EMAIL PROTECTED] suggested in thread usbd.conf: detach ukbd. (See the patch files, I posted there) When the kernel panics, it does this in usb0 kernel thread. I figured out that this is only related to connecting/disconnecting the usb keyboard. It panics without kbdmux loaded and it panics with unmodified ukbd.c. So I'll have to try to remote debug it, as my embedded device has no swap space at all and so no core dump device (256MB flash/256 MD dram). I am observing spurious crashes in usb0 under FreeBSD 4.11. Kernel configuration/hardware: HZ=400, NO_SWAPPING, DEVICE_POLLING (with kern.polling.user_frac=90), fxp ethernet, 6x sio, ohci, Pentium MMX 166 MHz could you try to compile kernel with debugging information? not sure if it will fit into ram. When quickly connecting/disconnecting i guess you mean here unplug the keyboard and then immediately plug it back, right? a usb keyboard, after some time I have a panic in process 3 (usb0), either at usbd_ar_pipe+0x7 (when detaching) or at usbd_get_interface_descriptor+0x6 (when attaching). Stack traces are: (a) usbd_ar_pipe+0x7 usbd_ar_pipe(0,...) usbd_abort_pipe(0,...) ukbd_enable_intr() ukbd_term() ukbd_detach() DEVICE_DETACH() device_detach() device_delete_child() usb_discommect_port() uhub_explore() usb_discover() usb_event_thread() can you tell what value pipe handle has? i suspect its NULL (b) usbd_get_interface_descriptor+0x6 usbd_get_interface_descriptor(0) ukbd_attach(c0bf3b80) DEVICE_ATTACH() device_probe_and_attach() usbd_probe_and_attach() usbd_new_device() uhub_explore() usb_discover() usb_event_thread() can you tell what value iface handle has? i suspect its NULL can you please compile the kernel with DIAGNOSTIC and check for messages from usb system? In situation(a), ipl is at bio, ks_intr_pipe is NULL when calling usbd_abort_pipe(). thats ok. splusb is defined as splbio In situation (b), ipl is at none, USB_ATTACH_START() in USB_ATTACK(ukbd) in ukbd.c seems to make problems. not sure about this one The above stack traces are from ddb. Booting the kernel with -gd and using gdb -k didn't give more information. I almost always get an unusable empty stack trace and different crash addresses. too bad :( It seems like 'usbd_setup_pipe: failed to start endpoint, IOERROR' always comes before the crash and ipl is mostly at bio, never at usb. what is your usb controller? uhci/ohci? what chip? When I'm doing these tests, I have an ssh console connected through fxp0 where I run usbd -dv. Any idea? please compile kernel with DIAGNOSTIC and USB_DEBUG. then try to adjust various debug knobs with sysctl(8) to get debug traces. at this point it looks like a race condition of some sort (to me). thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic in usb0; was: RE: using vkbd device
Maksim Yevmenkin wrote: Norbert, I am observing spurious crashes in usb0 under FreeBSD 4.11. Kernel configuration/hardware: HZ=400, NO_SWAPPING, DEVICE_POLLING (with kern.polling.user_frac=90), fxp ethernet, 6x sio, ohci, Pentium MMX 166 MHz could you try to compile kernel with debugging information? not sure if it will fit into ram. doesn't have to.. the debug info is not loaded. only made available to the debugger When quickly connecting/disconnecting i guess you mean here unplug the keyboard and then immediately plug it back, right? sounds like he means repeatedly. a usb keyboard, after some time I have a panic in process 3 (usb0), either at usbd_ar_pipe+0x7 (when detaching) or at usbd_get_interface_descriptor+0x6 (when attaching). Stack traces are: (a) usbd_ar_pipe+0x7 usbd_ar_pipe(0,...) usbd_abort_pipe(0,...) ukbd_enable_intr() ukbd_term() ukbd_detach() DEVICE_DETACH() device_detach() device_delete_child() usb_discommect_port() uhub_explore() usb_discover() usb_event_thread() can you tell what value pipe handle has? i suspect its NULL (b) usbd_get_interface_descriptor+0x6 usbd_get_interface_descriptor(0) ukbd_attach(c0bf3b80) DEVICE_ATTACH() device_probe_and_attach() usbd_probe_and_attach() usbd_new_device() uhub_explore() usb_discover() usb_event_thread() can you tell what value iface handle has? i suspect its NULL can you please compile the kernel with DIAGNOSTIC and check for messages from usb system? In situation(a), ipl is at bio, ks_intr_pipe is NULL when calling usbd_abort_pipe(). thats ok. splusb is defined as splbio In situation (b), ipl is at none, USB_ATTACH_START() in USB_ATTACK(ukbd) in that would be ATTACH not ATACK!:-) ukbd.c seems to make problems. not sure about this one The above stack traces are from ddb. Booting the kernel with -gd and using gdb -k didn't give more information. I almost always get an unusable empty stack trace and different crash addresses. booting with -gd drops you into the (gdb) debugger immediatly.. I presume you have a gdb looking at the serial port and have a serial debug port defined then? please compile kernel with DIAGNOSTIC and USB_DEBUG. then try to adjust various debug knobs with sysctl(8) to get debug traces. at this point it looks like a race condition of some sort (to me). thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
