RE: [ECOS] How to debug synchronisation in the usbs.c in a new usb-driver for the ARM at91sam7s...

["Derek Bouius" <derek dot bouius at sympatico dot ca>]

The problem is a race condition between checking the completed flag and executing the callback.
I will describe the flow of the usbs_devtab_write:
1. Initialize the variables (signal, mutex, etc)
2. Setup the callback function - (Callback sets the signal) 
3. Start the transfer
4. Lock the mutex.
5. Check if wait.completed
...race condition....
	6. Wait for signal -- waits here forever in some cases if the callback was executed after #5 and before #6
7. Unlock the mutex.
...
..

What happens in the lower level driver is that the (#3) start_tx_fn() enables the interrupt. That can fire immediately and call the
callback from within the dsr. Executing #5 above can happen inbetween the enable of the interrupt and the actual interrupt.

The same process can occur in the read.

Derek


 

-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch] 
Sent: Thursday, February 16, 2006 11:26 AM
To: Derek Bouius
Cc: andrew@lunn.ch; munz@speag.ch; ecos-discuss@sourceware.org
Subject: Re: [ECOS] How to debug synchronisation in the usbs.c in a new usb-driver for the ARM at91sam7s...

On Thu, Feb 16, 2006 at 11:15:25AM -0500, Derek Bouius wrote:

> I am not registered for the mailing list, but peruse it once in a
> while, so I am not sure if my mail will go through to it. Feel free
> to repost it if it doesn't.

It got through.

> What we did to fix the locking issue was change the mutex to a
> semaphore. See the patch. It seems to work reliably.

Did you understand what the problem was with the condition variable?
Could you explain it?

        Thanks
                Andrew




-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss