RE: 2.6.9: serial_core: uart_open

From: karl malbrain
Date: Tue Jul 12 2005 - 15:37:03 EST


>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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/