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 CranReceived 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