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>