RE: 2.6.9: serial_core: uart_open

["karl malbrain" <karl@petzent.com>]

>On Tue, 12 Jul 2005, karl malbrain wrote:
>
>>> On Tue, 12 Jul 2005, karl malbrain wrote:
>>
>>>> The uart_open code loops waiting for CD to be asserted (whenever CLOCAL
>>>> is not set).  The bottom of the loop contains the following code:
>>>>
>>>> up(&state->sem);
>>>> schedule();
>>>> down(&state->sem);
>>>>
>>>> if( signal_pending(current) )
>>>>   break;
>>>>
>>>> When I issue an open("/dev/ttyS1", O_RDWR) from a terminal session on
>>>> the console, the system seems to come to a stop in this loop until the
>>>> process is killed.  I suspect that the scheduler is choosing this
process
>>>> to run again because of an elevated console priority of some sort.
>>>>
>>>> Is there a kernel mechanism to put a process to sleep until awakened by
>>>> an event to replace this looping behaviour?
>>>>
>>>> Thanks, karl malbrain, malbrain-at-yahoo-dot-com
>>>>
>>>
>>> In the first place, you should perform an open(O_NDELAY), so the open
>>> returns immediately with anything that has potential "modem-control".
>>> Then you can set the device to blocking using fcntl(F_GETFL), F_SETFL.
>>
>>> Also, the task that is waiting for the open() is sleeping. That's
>>> what schedule() does.
>>
>>> Cheers,
>>> Dick Johnson
>>
>> I'm looking for the POSIX behaviour of delaying the open until CD is
>> asserted by the modem.  If schedule() doesn't select another process to
run,

>schedule() gives the CPU to any runnable process. That's how it works.
>Most all drivers that are waiting for an event will give up the CPU
>by executing schedule(). That's how-come you can be doing something
>useful while file-I/O is occurring.

That looks like a problem.  If uart_open is just calling schedule() and if
the current process running in uart_open is being selected again, the system
is hung.

>> no wonder the system is hung at this point, because the uart_open loop
>> doesn't break until CD is asserted by the modem.  This sounds like a
serious
>> bug.

>You need to look at your code.

The code:
#include <fcntl.h>
#include <stdio.h>

int main (void)
{
int fd = open ("/dev/ttyS1");
printf("Opened\n");
}

>
> karl_m
>
>There is no bug although there may be a bug in your code.
>Just do `cat /dev/ttyS1` or whatever your device is. It will
>wait on the open if modem-control is enabled, and you can see
>from another terminal that nothing is spinning.

>$ ps laxw | grep cat
>
>0     0 11555  2791  17   0  3512  348 -      S    tty2       0:00 cat
/dev/ttyS0
>                                               |
>                                               |__ clearly sleeping
>
>0     0 11610 11556  16   0  3656  568 -      R    tty3       0:00 grep cat

Are you sure that CLOCAL is not set on /dev/ttyS0? and that the cat is not
sleeping on a read???  That's my original question: how can uart_open be
changed to put the process to sleep rather than looping like it does now.

>Cheers,
>Dick Johnson

karl m



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/