Re: Kernel panic; fatal trap 12; on task 22, USB0: was Re: Moused issues?
On Saturday 06 October 2007, Joe Altman wrote: chthonic.com/crash-crash-crash Hi, Do you have options KDB in your kernel config file ? http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-options.html You should get a prompt when it panics. Then you type in bt for backtrace. Maybe you could take a picture of that. Probably someone is accessing a NULL pointer. --HPS ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic; fatal trap 12; on task 22, USB0: was Re: Moused issues?
On Sun, Oct 07, 2007 at 11:01:41AM +0200, Hans Petter Selasky wrote: On Saturday 06 October 2007, Joe Altman wrote: chthonic.com/crash-crash-crash Hi, Do you have options KDB in your kernel config file ? Following your suggestion, I did try this; and there was no change from kernel panic and reboot. http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-options.html You should get a prompt when it panics. There was no prompt. Then you type in bt for backtrace. Maybe you could take a picture of that. Personally, it's a bit embarassing to be so helpless that I am forced to take a picture. I suppose if I could be certain about how to compile bootblocks, I might be able to do something on the serial console with a laptop. But the one time I attempted that was a disaster. Is my speculation about the ...no dump device found... correct? Is it that swapon and multiuser has not occurred, and so there can occur no dump to the swap space? Probably someone is accessing a NULL pointer. If any more damage occurs, ISTM that my entire installation will be accessing a NULL pointer; the following message is from the most recent dmesg, and is new: warning: KLD '/boot/kernel.old.bootable/drm.ko' is newer than the linker.hints file Since my hardware appears to not work with the available source, who knows how that will go? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel panic; fatal trap 12; on task 22, USB0: was Re: Moused issues?
NB: I've copied -usb because it looks to me like it's definitely USB that's implicated; but I still need a clue for getting a crash dump; -questions seems the place to ask for that. On Sun, Sep 23, 2007 at 07:57:41PM -0400, Joe Altman wrote: uname for the machine on which it fails: 6.2-STABLE FreeBSD 6.2-STABLE #0: Sun Sep 2 17:30:39 EDT 2007 i386 Is it possible to get more info on this for debugging short of putting debugging in the kernel, and configuring a dump device; rebuilding world, and hoping my machine does not become unusable? I'm still seeing the USB associated crashes, with sources updated several times and world remade between Sept. 23 and Oct. 6, 11 AM EDT. The above uname shows the only kernel I can use. I've attempted to obtain a dump using these instructions: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html#KERNELDEBUG-OBTAIN And here, I think, are the relevent details. In /etc/rc.conf, I have: ##Crash dumpdev=AUTO dumpdir=/var/tmp/crash /var/tmp/crash exists with appropriate permissions; and swapinfo shows 2 Gig of space: ~ $: swapinfo Device 1M-blocks UsedAvail Capacity /dev/ad0s1b 20480 2048 0% AIUI, dumpdev=AUTO dictates the use of /dev/ad0s1b. /var/tmp has this much free space: df -m /dev/ad0s1f 3962 618 302717%/var/tmp However, my kernel tosses this message to the console: Fatal trap 12: page fault while in kernel mode snip and indicates a problem with task 22, USB[1] 0. Prior to problem with task 22, USB 0; it was the same fatal trap, task 25, USB 1. Then it indicates that there is no dump device. It seems to me that all I should have to do is define the dumpdev in rc.conf to obtain a dump; and in my case, since /var is smaller than RAM and swap, define /var/tmp/crash. So it looks to me as if I am experiencing what is described here: ...a kernel is crashing before dumpon(8) can be executed. taken from the kerneldebug.html page. Or am I missing something in the configuration of the dump device? If not, is my only option to put a dump directive into my kernel config? If so, what is the proper syntax? device dump or something else? Also, I decided it was easier for my to snap a picture than transcribe the screen; it's here if anyone is interested: chthonic.com/crash-crash-crash I'm limping along, I think; and would appreciate some clues, please. One more data point: I'm using an IBM PIII laptop; and I do not experience any crash on that; and my AMD dual core does not crash either; all three machines use, AFAICT, the same USB code. Thanks. [1] The USB controller is: Intel 82801EB (ICH5) USB controller and Intel 82801EB/R (ICH5) USB 2.0 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Moused issues?
On Sat, Sep 22, 2007 at 05:12:45PM -0400, Nick Evans wrote: Try using version 1.94 of ums.c in /sys/dev/usb/. This fixes my Razor. Newer versions don't crash on me, but the mouse attaches then does nothing. Thank you for the suggestion, Nick; but no joy: the kernel compile fails: /usr/src/sys/dev/usb/ums.c: In function `ums_match': /usr/src/sys/dev/usb/ums.c:202: error: `UIPROTO_MOUSE' undeclared (first use in this function) /usr/src/sys/dev/usb/ums.c:202: error: (Each undeclared identifier is reported only once /usr/src/sys/dev/usb/ums.c:202: error: for each function it appears in.) /usr/src/sys/dev/usb/ums.c: In function `ums_attach': /usr/src/sys/dev/usb/ums.c:341: error: `UQ_MS_BAD_CLASS' undeclared (first use in this function) *** Error code 1 Oddly, my AMD64 laptop uses ums.c 1.77.2.5 2007/06/17 along with the new moused, etcetera; and it does not fall over with or without the Razer attached to it. I'd mark it down to an oddness in my source tree on the i386 desktop; but since Nick seems to have had the same problem with a Razer, I can't. uname for the machine on which it fails: 6.2-STABLE FreeBSD 6.2-STABLE #0: Sun Sep 2 17:30:39 EDT 2007 i386 Is it possible to get more info on this for debugging short of putting debugging in the kernel, and configuring a dump device; rebuilding world, and hoping my machine does not become unusable? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Moused issues?
Or maybe USB; I can't tell. Background: Beginning around 5 PM EDT Sept. 21 I upgraded world and rebuilt my kernel; after rebooting to install the new kernel at about 9 PM, the system panicked and tossed something like this on the console (I'm working from memory; it was late and I was tired): Fatal trap 12: page fault while in kernel mode followed by a bunch of other text, no dump device, and then a reboot in fifteen seconds countdown. The process seemed to hang somewhere around initializing or querying the mouse, a Razer USB. I rebooted and chose kernel.old; it works fine; and it looks like the code (I'm working on an uninformed hunch here) for moused.c did change just before the time I upgraded source. http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/moused/moused.c.diff?r1=1.70.2.5;r2=1.70.2.6;f=h Again: I'm guessing based on what I see failing in the boot process; and on the things I can find that changed in the source tree: I can see other things that changed at about the same time; for instance, kld.3, kld.c,libutil.h in /usr/src/lib/libutil/; it looks like these things are relevant to loading ums(4) bits. Any clues? If the only way to investigate further is to build a debugging kernel and configure a dump device, I'm afraid I cannot build any sort of debugging kernel; I am pretty sure it would render my machine unusable and given that I've just reinstalled it on June 16, I'd rather not risk it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
