Date: Fri, 12 Nov 2004 15:38:40 -0800 From: Julian Elischer <julian@elischer.org> To: Adam Kropelin <akropel1@rochester.rr.com> Cc: usb@freebsd.org Subject: Re: anyone seen this problem.. Message-ID: <41954980.6050201@elischer.org> In-Reply-To: <049301c4c90a$d8109d80$03c8a8c0@kroptech.com> References: <41953285.8070405@elischer.org> <4195340C.6030201@elischer.org> <049301c4c90a$d8109d80$03c8a8c0@kroptech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Adam Kropelin wrote: > Julian Elischer wrote: > >> Julian Elischer wrote: >> >>> >>> I'm working in 4.10++ plus a few MFC patches.. >>> >>> One of our applications regularly crashes when using a uhid device. >> >> >> >> ^^^^^ ugen > > > I've been able to panic the kernel fairly easily using ugen (this is > on 5.2.1 and 5.3). The trigger seems to be a length mismatch where the > device returns a different amount of data than was expected for a > particular transfer. I'm suspecting memory corruption since it will > often fail the ioctl a few times before actually panicing. > > I am not sufficiently clued to obtain a kernel backtrace like you did. > I presume I need to configure something to dump me into a kernel > debugger upon panic instead of the automatic reboot I'm currently > getting. I'll read up on such things and see if I can determine how > closely my situation matches yours. you need to set dumpdev="/dev/ad0s1b" in /etc/rc.conf and after the next boot. cd /(kernelcompile directory) kgdb kernel.debug /var/crash/vmcore.0 (probably best to make /var/crash a symlink somewhere with more space) 'bt' to get a stacktrace. > > > --Adam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41954980.6050201>