Skip site navigation (1)Skip section navigation (2)
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>