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 <[EMAIL PROTECTED]> | "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:
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.qubesoft.com/ http://www.etla.net/~n_hibma/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
