Bug in termios

[Eric Norum]

Why is the rawInBuf.Semaphore a counting semaphore?    Should it not  
be a binary semaphore?

On Oct 19, 2006, at 6:48 AM, jennifer at oarcorp.com wrote:

> I have a system with 12 serial port.  The driver is configured to be
> interrupt driven with one character arrival per interrupt.   
> Furthermore,
> I am using 1 task which is set up to poll the serial ports in raw  
> mode at
> a 10 ms rate and distribute any data that has arrived.  To do this  
> I have
> set VMIN and VTIME to 0.  The problem occurs on high bandwidth devices
> (after they have ran a while), when the device is turned off.   
> Turning off
> the device results in the system locking up for several seconds then
> recovering.  Analysis has shown that the read command is locking the
> system during this time.  It appears to me that the problem is  
> happening
> is that inside of termios.c in the fillBufferQueue routine.  While the
> device is running there are always characters available so  
> rawInBuff.Head
> and rawInBuffTail are never equal.   Then ccount is always >=  c_cc 
> [VMIN]
> which results in wait being set to 0 and the semaphore never being
> decremented even thought it being incremented approximately 20 times
> during the 10 ms application task poll rate.  When the serial  
> device is
> turned off and the characters are emptied out of the termios  
> buffer, this
> results in a spinlock of obtaining the rawInBufSemaphore several  
> hundred
> thousand times.
>
> I have tried several things to balance the semaphore count,  but can’t
> seem to get something that doesn’t break some other aspect of termios.
> Any suggestions would be appreciated
>
> Thanks
> Jennifer
>

-- 
Eric Norum <norume at aps.anl.gov>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20061019/3d5ad48b/attachment-0001.html>