RE: 2.6.9: serial_core: uart_open

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

>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,
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.

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/