Hi, David Brownell: > This was on 2.4? Or something more current?
2.4.current.
> For 2.6.recent,
> try the latest BK snapshot, which sorts out certain classes
> of integration problems (maybe this one).
>
> Plus, I don't know where $SUBJECT came from
>
I'll do 2.6 later. For various reasons, switching kernels to 2.6 is not
a good option right now. One of these reasons is that I want to
understand why the problem exists before playing with stuff that may or
may not make it go away, and so does my client, and so does their
customer for that matter.
$SUBJECT derives from the fact that one effect of this purported DMA
failure is that the kernel thinks that the address assignment URB timed
out, and reports an error. 2.4.27 sortof forgets to decrease the bus
refcount in that case. :-/
> > Kernel USB debugging shows that the chip is up (after all, it does find
> > the serial portsat the other end of the USB bus) but simply fails to
> > DMA-write across the PCI bus to the HCCA area (the main memory DMA area
> > which is used to talk to the OHCI chip). The most direct evidence for that
> > is that the frame counter is zero and stays that way.
>
> But the counter on the chip is still running? What does "lspci -v"
> tell you about whether DMA is still enabled?
AFAIK: yes, but I'll check that tomorrow.
"lspci -vv" shows no difference whatsoever between a hung card and a
working one.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
signature.asc
Description: Digital signature
