public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* RE: 2.6.9: serial_core: uart_open
@ 2005-07-12 19:27 karl malbrain
  0 siblings, 0 replies; 17+ messages in thread
From: karl malbrain @ 2005-07-12 19:27 UTC (permalink / raw)
  To: Linux-Os@Analogic. Com; +Cc: Linux-Kernel@Vger. Kernel. Org

>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




^ permalink raw reply	[flat|nested] 17+ messages in thread
[parent not found: <Pine.LNX.4.61.0507151150290.11664@chaos.analogic.com>]
[parent not found: <Pine.LNX.4.61.0507130850110.18969@chaos.analogic.com>]
* RE: 2.6.9: serial_core: uart_open
@ 2005-07-12 20:32 karl malbrain
  0 siblings, 0 replies; 17+ messages in thread
From: karl malbrain @ 2005-07-12 20:32 UTC (permalink / raw)
  To: Linux-Os@Analogic. Com; +Cc: Linux-Kernel@Vger. Kernel. Org

>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




^ permalink raw reply	[flat|nested] 17+ messages in thread
* 2.6.9: serial_core: uart_open
@ 2005-07-12 18:36 karl malbrain
  2005-07-12 21:03 ` Russell King
  0 siblings, 1 reply; 17+ messages in thread
From: karl malbrain @ 2005-07-12 18:36 UTC (permalink / raw)
  To: linux-kernel

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




^ permalink raw reply	[flat|nested] 17+ messages in thread
end of thread, other threads:[~2005-07-15 20:48 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-07-12 19:27 2.6.9: serial_core: uart_open karl malbrain
     [not found] <Pine.LNX.4.61.0507151150290.11664@chaos.analogic.com>
2005-07-15 16:57 ` karl malbrain
     [not found] <Pine.LNX.4.61.0507130850110.18969@chaos.analogic.com>
2005-07-13 17:53 ` karl malbrain
2005-07-14  8:26   ` Russell King
2005-07-14 17:16     ` karl malbrain
2005-07-14 18:57       ` Russell King
2005-07-14 19:30         ` karl malbrain
2005-07-14 22:35         ` karl malbrain
2005-07-15  7:28           ` Russell King
2005-07-15 16:02             ` karl malbrain
2005-07-15 20:32               ` Russell King
2005-07-15 20:48                 ` karl malbrain
2005-07-15 16:20             ` karl malbrain
  -- strict thread matches above, loose matches on Subject: below --
2005-07-12 20:32 karl malbrain
2005-07-12 18:36 karl malbrain
2005-07-12 21:03 ` Russell King
2005-07-12 21:17   ` karl malbrain

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox