From owner-freebsd-hackers Thu Jan 11 22:52:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from newmail.netbistro.com (newmail.netbistro.com [204.239.167.35]) by hub.freebsd.org (Postfix) with SMTP id 799F037B400 for ; Thu, 11 Jan 2001 22:52:08 -0800 (PST) Received: (qmail 4299 invoked by uid 1020); 12 Jan 2001 06:48:34 -0000 Date: Thu, 11 Jan 2001 22:48:34 -0800 (PST) From: Jon Simola X-Sender: jon@newmail.netbistro.com Reply-To: Jon Simola To: Nick Hibma Cc: FreeBSD Hackers Mailing List Subject: Re: Broken-by-design USB device? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 8 Jan 2001, Nick Hibma wrote: > 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. I'd still bet on the hardware being suspect. It's got all the prime labelling of a quality product: "PS-PC USB Converter" "Full Colors" "Special Design, Extra Stable & Highly Compatibility" > 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 db> show registers cs 0x8 ds 0xc0a20010 es 0xc0150010 await+0xe4 fs 0xc0300010 ss 0x10 eax 0x9 ecx 0xc0d32400 edx 0 ebx 0x6 esp 0xc030b920 ebp 0xc030b920 esi 0xc0a227b0 edi 0xc0d32400 eip 0xc011d58a DEVICE_PROBE+0xe efl 0x90282 > x/x $ecx,0x20 db> x/x $ecx,0x20 0xc0d32400: 0 0 0 0 0xc0d32410: 0 0 0 c0d2ac40 0xc0d32420: 0 c0a22040 0 0 0xc0d32430: 0 0 0 0 0xc0d32440: 0 0 0 0 0xc0d32450: 0 0 0 0 0xc0d32460: 0 0 0 0 0xc0d32470: 0 0 0 0 > x/c *($ecx+0x24),0x10 db> x/c *($ecx+0x24),0x10 0xc0a22040: uhid0\000\000\000\000\000\000\000\000\000\000\000 > 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 :( If I'm following you, the info above will just prove that something is too broken to figure out. If I can find another one of these things I'll just mail it to you. Other than that, I'll stop wasting your time :) Thank you very much for the help. --- Jon Simola | "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