Re: Panic with ugen

From: Bruce Cran <bruce_at_cran.org.uk>
Date: Wed, 10 Dec 2003 22:44:12 +0000
On Tue, Dec 02, 2003 at 07:03:51PM +0000, Jay Cornwall wrote:
> Martin wrote:
> 
> >>Could you try the attached patch (rm -f sys/dev/usb/ugen.c, cvs up 
> >>sys/dev/usb/ugen.c, patch ...) to see if it alleviates the panic? It 
> >>should at least give a more specific panic, if it doesn't fix the problem.
> 
> >Sorry for the delay, I got a busy weekend.
> 
> And sorry for the delay here too. Had a busy start-of-week. :\
> 
> >I still got a panic after starting the small piece of code, but it looks
> >like this now:
> >
> >fatal trap 12
> >fault virtual address = 0x5
> >supervisor read, page not present
> >[...]
> >
> >trace shows me "ugen_set_config()" at top of the stack.
> 
> Hmm. I'm afraid I'm not really sure why my patch doesn't fix the problem.
> 
> Unfortunately, to fix this I think I'd need to be able to reproduce the 
> panic locally and do some debugging. Otherwise, I'd just be guessing at 
> what's causing the problem.
> 
> If you could provide a full backtrace with a debug-enabled kernel 
> ('makeoptions DEBUG=-g' in your kernel configuration file, with GDB using 
> kernel.debug to obtain symbols - I think onlamp.com had a tutorial on doing 
> this) I may be able to locate where things are going wrong. But if it's too 
> much hassle for you, I think it'd be best to pass this on to a developer 
> with a machine to test the panic on.
> 
> Thanks for trying the patches, though. :)

I've just had the same panic on -CURRENT:

ugen0: at uhub1 port 1 (addr 2) disconnected^M
WARNING: Driver mistake: destroy_dev on 114/1^M
panic: don't do that^M
Debugger("panic")^M
db> tr^M
Debugger(c05eb534) at Debugger+0x45^M
panic(c05e8a79,c05e8aac,72,1,1) at panic+0xbb^M
destroy_dev(c47f3b00,2,c4852860,e9b25c84,c47ff53d) at destroy_dev+0x32^M
ugen_destroy_devnodes(c4851000,c47f3900,c4851000,c484f100,c484f100) at
ugen_destroy_devnodes+0x5b^M
ugen_detach(c484f100) at ugen_detach+0xc1^M
device_detach(c484f100) at device_detach+0x56^M
device_delete_child(c47b4980,c484f100,c482661e,2,c43e9240) at
device_delete_child+0x31^M
usb_disconnect_port(c47b4730,c47b4980,3,c43e9270,c47b4708) at
usb_disconnect_port+0x90^M
uhub_explore(c47fc600,c43ee9e0,e9b25d1c,c4812372,c43ee9e0) at
uhub_explore+0x144^M
usb_discover(c43ee9e0,c4812328,e9b25d34,c04ab904,c43ee9e0) at
usb_discover+0x2f^M
usb_event_thread(c43ee9e0,e9b25d48,c43ee9e0,c4812328,0) at
usb_event_thread+0x4a^M
fork_exit(c4812328,c43ee9e0,e9b25d48) at fork_exit+0x90^M
fork_trampoline() at fork_trampoline+0x8^M

This was after trying to get my Speedtouch USB modem working - I
kldloaded ugen, ran and stopped the ppp daemon which runs pppoa2 a few
times, and then unplugged the modem.  It's an EHCI usb port.

I've got a full crash dump, but I don't
know what to do with it since it lists the 'dumping++' line of
kern_shutdown, not the actual panic code.   If there's anything there of any
use, I'll keep the vmcore file.   uname "FreeBSD buffy.brucec.backnet
5.2-CURRENT FreeBSD 5.2-CURRENT #0: Wed Dec 10 21:12:15 GMT 2003
root_at_:/usr/obj/usr/src/sys/MYKERNEL  i386"

--
Bruce Cran
Received on Wed Dec 10 2003 - 13:45:12 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:33 UTC