Christopher Hoover wrote:
> I played with pwc + ohci-07111.patch on the SA-1111 ohci hc a bit more.
> Definitely no love coming from that device.
The patch seems to behave fine for control/bulk/interrupt and, for
"mpg321" audio playback, iso-out (which seems to avoid unlinking,
so it may not be a good test). So far I've not seen symptoms like
you have, although I heard Nemosoft had similar PWC problems.
So what I did is just send Greg the completely innocuous bits
(including a few that weren't in 0711), so I can figure out
what's up with the more extensive updates. Most folk will still
be unlikely to hit those unlink races (they probably explain some
of the exotic OHCI flakes seen in 2.4), but I want them fixed in
2.5 so other things can improve too ... :)
> Here are example hangs/crashes:
> ========================================================================
> {complete hang, no sysrq, no heartbeat)
Suggestive of something ... not clear what you mean by "heartbeat"
though. Some ARM-specific thing?
> ========================================================================
>
> Unable to handle kernel NULL pointer dereference at virtual address
> 00000000
> Internal error: Oops: c3cf7007
>
> ...
>
> Trace; c4cadef8 <[ohci-hcd]ohci_urb_dequeue+0/84>
> Trace; c02c71a8 <hcd_unlink_urb+168/23c>
>
>>>r6; c3f2ccbc <_end+3bb5ca4/491efe8>
>>>r4; c0458260 <_end+e1248/491efe8>
>>
>
> Trace; c02c7040 <hcd_unlink_urb+0/23c>
> Trace; c02c7868 <usb_unlink_urb+40/4c>
>
>>>r6; c040ec00 <_end+97be8/491efe8>
>>>r4; c040ec60 <_end+97c48/491efe8>
I'm not clear what's up with this backtrace. Exactly where
was the oops? It seems to point to several different places
at the same time, and there wasn't a disassembly. In fact it
looks like there were two or three (or more) ksymoops outputs
intermixed ... maybe that's just how the ARM one works, but
it makes no sense to me at all.
Maybe you could tell me which line (C code) seems to be giving
you the null pointer exception? Ksymoops output ought to be a
nice solid clue as to what's going wrong, but in this case it
seems to have failed in that role ... :)
> Trace; c02c7828 <usb_unlink_urb+0/4c>
> Trace; c4ca0f04 <[pwc]pwc_isoc_cleanup+4c/6c>
I took a look at this one routine, and it looks a wee
bit dubious. Specifically, it's got URBs active when
it changes the altsetting; it ought to kill the urbs
first. You (or Nemosoft) might switch those around,
and then retest ... you're certainly forcing the code
to go into some error paths, and maybe you could avoid
them and then not run into problems.
The current Linux-USB stack handles altsettings with a
dose of luck, and it's better to avoid relying on that
until usbcore adds interlocks so config/altsetting changes
clear out endpoint state (including nuking active urbs)
before they try to do their real work.
That said, null pointer exceptions shouldn't happen in
such cases either, and I'd like to know how that one
is happening.
- Dave
>>-----Original Message-----
>>From: David Brownell [mailto:[EMAIL PROTECTED]]
>>Sent: Thursday, July 11, 2002 4:55 PM
>>To: Nemosoft Unv.; Christopher Hoover
>>Subject: PWC and OHCI on 2.5.24
>>
>>
>>OK, here's a biggish patch that I believe will address that
>>problem you both reported ... please let me know.
>>
>>The patch addresses quite a bit more than just that PWC
>>issue, since I was in the middle of fixing something basic in
>>how unlinks are handled. It incidentally shrinks the size of
>>the non-debug driver by maybe 1% (smp-x86), and fixes several
>>(of the) other bugs I happened to see.
>>
>>...
-------------------------------------------------------
This sf.net email is sponsored by: Jabber - The world's fastest growing
real-time communications platform! Don't just IM. Build it in!
http://www.jabber.com/osdn/xim
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
