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
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
