Date: Mon, 8 Jan 2001 23:12:46 +0000 (GMT) From: Nick Hibma <n_hibma@calcaphon.com> To: Jon Simola <jon@abccom.bc.ca> Cc: FreeBSD Hackers Mailing List <hackers@FreeBSD.ORG> Subject: Re: Broken-by-design USB device? Message-ID: <Pine.BSF.4.20.0101082114170.21226-100000@henny.webweaving.org> In-Reply-To: <Pine.BSF.3.96.1010108115303.19021A-100000@newmail.netbistro.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> uhid0: vendor 0x6666 product 0x0667, rev 1.00/2.88, addr 2, iclass 3/0 > uhid0: no report descriptor > device_probe_and_attach: uhid0 attach returned 6 > ugen0: vendor 0x6666 product 0x0667, rev 1.00/2.88, addr 2 > ugen0: setting configuration index 0 failed > device_probe_and_attach: ugen0 attach returned 6 Just as a note on the side, the fact that the attach of the generic driver fails (while setting config 0, which is a sort of a soft reset) could indicate that there is something fishy going on with respect to fetching the report descriptor. I seems to freeze. And now back to your scheduled 'panic' demolition: It still bombs in the middle of DEVOPMETH in: device_probe_t *m = (device_probe_t *) DEVOPMETH(dev, device_probe); which is #define DEVOPMETH(DEV, OP) \ ((DEVOPDESC(OP)->offset >= DEVOPS(DEV)->maxoffset) \ ? DEVOPDESC(OP)->deflt \ : DEVOPS(DEV)->methods[DEVOPDESC(OP)->offset]) while executing 56: 3b 02 cmp (%edx),%eax with edx == dev->ops and eax == device_probe_ops->offset (don't you hate i386 assembler syntax?) and edx apparently being 0. Which as far as I can see is impossible in the subr_bus.c code. So that leaves 'memory spamming' as the only option :-( Apart from that, I have no clue which driver tries to attach after the ugen driver is finished. Because that is the last driver that makes an attempt. Could you do the following: Boot the machine and when it panics type the following commands: show registers x/x $ecx,0x20 x/c *($ecx+0x24),0x10 which will print three things: the contents of all registers (show registers), then the 32 longs at address $ecx (x/x $ecx,20), basically the contents of the struct device in DEVICE_PROBE, in which the 6th element (at +0x14) should be zero. And then the string that is pointed to by the nameunit element in the struct device. This last one should give us a hint at which device is failing. Never mind if the last one gives you a page fault. nameunit might be zero. I really am at a loss what this could be :( Nick > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc011d58a > stack pointer = 0x10:0xc030b920 > frame pointer = 0x10:0xc030b920 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > interrupt mask = net tty bio cam > kernel: type 12 trap, code=0 > Stopped at DEVICE_PROBE+0xe: cmpl 0(%edx),%eax > db> trace > DEVICE_PROBE(c0d32400,c0d32400,c0d32800,0,0) at DEVICE_PROBE+0xe > device_probe_child(c0d32800,c0d32400,c0d32500,0,c0d32530) at device_probe_child+0xc1 > device_probe_and_attach(c0d32400) at device_probe_and_attach+0x3d > usbd_probe_and_attach(c0d32800,c0d32500,2,3,c0d32500) at usbd_probe_and_attach+0xef > usbd_new_device(c0d32800,c0d33000,1,200,2,c0d327c0) at usbd_new_device+0x1dd > uhub_explore(c0d32980,c0d32a00,c0d31580,0,c030be50) at uhub_explore+0x1d4 > usb_attach(c0d32a00,c030be6c,c0154967,c0d32a00,c0d33000) at usb_attach+0xf1 > DEVICE_ATTACH(c0d32a00,c0d33000,c0d31580,0,1) at DEVICE_ATTACH+0x2e > device_probe_and_attach(c0d32a00) at device_probe_and_attach+0x63 > uhci_pci_attach(c0d31580,c030beb8,c0154967,c0d31580,c0d31580) at uhci_pci_attach+0x33f > DEVICE_ATTACH(c0d31580,c0d31580,c0d31b00,0,0) at DEVICE_ATTACH+0x2e > device_probe_and_attach(c0d31580) at device_probe_and_attach+0x63 > bus_generic_attach(c0d31a80,c030bef0,c0154967,c0d31a80,c0d31a80) at bus_generic_attach+0x16 > DEVICE_ATTACH(c0d31a80,c0d31a80,c0d31c80,0,1) at DEVICE_ATTACH+0x2e > device_probe_and_attach(c0d31a80) at device_probe_and_attach+0x63 > bus_generic_attach(c0d31b00,c030bf28,c0154967,c0d31b00,c0d31b00) at bus_generic_attach+0x16 > DEVICE_ATTACH(c0d31b00,c0d31b00,c0a25800,0,1) at DEVICE_ATTACH+0x2e > device_probe_and_attach(c0d31b00) at device_probe_and_attach+0x63 > bus_generic_attach(c0d31c80,c0d31c80,c030bf54,c011d60e,c0d31c80) at bus_generic_attach+0x16 > nexus_attach(c0d31c80,c030bf70,c0154967,c0d31c80,c0d31c80) at nexus_attach+0xd > DEVICE_ATTACH(c0d31c80,c0d31c80,c02791f0,310000,1) at DEVICE_ATTACH+0x2e > device_probe_and_attach(c0d31c80) at device_probe_and_attach+0x63 > root_bus_configure(c0a25800,c0258f8c,0) at root_bus_configure+0x16 > configure(0,309c00,310000,0,c011d014) at configure+0x33 > mi_startup(c030bfb4,b0206,ffe,310000,c0159069) at mi_startup+0x70 > begin() at begin+0x4b > db> > > > --- > Jon Simola <jon@abccom.bc.ca> | "In the near future - corporate networks > Systems Administrator | reach out to the stars, electrons and light > ABC Communications | flow throughout the universe." -- GITS > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- Qube Software, Ltd. Private: n_hibma@qubesoft.com n_hibma@webweaving.org n_hibma@freebsd.org http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.20.0101082114170.21226-100000>