Am Mittwoch, 19. März 2003 23:39 schrieb David Brownell:
> Oliver Neukum wrote:
> > Hi Dave,
> >
> > does this remove your doubts about race conditions in the synchronous
> > API?
>
> It's a lot closer ... I'll try it.  Yes, it's odd that there
> was no pre-existing "wait_event_timeout()", and that's the
> call we need to make that implementation behave right.

I thought about that. I still have no clue as to the reason.

> Some further cleanup:  abolish "struct usb_api_data", it's
> exactly the same as "struct completion".  Then likely that
> completion callback can just call complete(). And why are
> you initializing the waitqueue head twice?  Also:  if I

Do I? Where? Cerebral insufficiency, most likely. It's past midnight
here.

> were doing it, I'd not use the synchronous unlink call;
> "ought not" to matter, but we can be more sure than that.

That's dangerous. We must have absolute confidence about whether
the message has gone over the wire or not.
Suppose it's a reset. We'd have a device at address zero without knowing
it. So this seems to be the easiest way.

> Curiously enough, I seem to have found a way to reproduce
> the previous "raced timeout" message -- which is IMO proof
> that my doubts were well deserved.  (Specifically the ones
> about the implementation being broken; API is another issue.)
>
> Basically, with the system under heavy USB loads (two EHCI
> devices putting 20+ MByte/sec loads, plus the device side
> logic of one of those -- net 70+ MByte/sec!) and interrupt
> load to match ... system latencies were high enough that I
> couldn't enumerate a new device.  I got the "raced" message,
> then first khubd and then the rest of the USB stack locked
> up.  There was another wierdness going on too, but clearly
> the synchronization replaced by your patch was also broken.

This is odd. How was the system load? Doesn't it have to be insanely
high for a kernel thread not running for several seconds after being
woken up?
Or is this an IO scheduling bug? Control messages should have priority
over bulk, shouldn't they?

        Regards
                Oliver



-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink?
You could win a Tablet PC. Get a free Tablet PC hat just for playing.
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to