Date: Fri, 12 Jan 2001 11:50:27 +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.0101121148150.3031-100000@henny.webweaving.org> In-Reply-To: <Pine.BSF.3.96.1010108152741.19021C-100000@newmail.netbistro.com>
next in thread | previous in thread | raw e-mail | index | archive | help
First of all, you are not wasting my time (I _asked_ for the info, right?). More probably it is the other way around with you having to crash you machine all the time ... :-) Second the info your supplying is good quality. Thanks for that. I'll have a look after the weekend (I'll try and not be a sad person while on holiday) ... oh hell ... I have enough space on my laptop for a usr/src/sys tree of STABLE ... sigh, they'll hate me now... Thanks. Nick On Thu, 11 Jan 2001, Jon Simola wrote: > 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 <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 > > > -- 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.0101121148150.3031-100000>