serial on lombard

serial on lombard

[Mario Scarpa]

[-- Attachment #1: Type: text/plain, Size: 433 bytes --]

Hi there,

there's something I cannot get rid of. When I try to
use minicom to dial with the internal modem of my
lombard 400MHz I get a "/dev/ttyS0 no such file or dir"
error; when I try to use setserial or stty on the same
device everything works ok. I'm using debian potato.
Attached there 's the 'strace minicom' output: hope this helps.

Thanks guys and ... great work !

-- 
Mario Scarpa

Mondonet NOC
Phone: +39 06 52.47.37.02

[-- Attachment #2: out --]
[-- Type: text/plain, Size: 5492 bytes --]

execve("/usr/bin/minicom", ["minicom"], [/* 22 vars */]) = 0
brk(0)                                  = 0x1876b1c
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=0200000, st_size=939928254, ...}) = 0
mmap(ptrace: umoven: Input/output error
)                                  = 0x30014000
close(3)                                = 0
open("/lib/libncurses.so.4", O_RDONLY)  = 3
fstat(3, {st_mode=0200000, st_size=939928248, ...}) = 0
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096
mmap(ptrace: umoven: Input/output error
)                                  = 0x1755000
mprotect(0x1798000, 359544, PROT_NONE)  = 0
mmap(0, 0, PROT_NONE, MAP_FILE, 0, 0)   = 0x17d5000
mmap(0, 0, PROT_NONE, MAP_FILE, 0, 0)   = 0x17ec000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
fstat(3, {st_mode=0200000, st_size=939928254, ...}) = 0
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096
mmap(ptrace: umoven: Input/output error
)                                  = 0x30016000
mmap(ptrace: umoven: Input/output error
)                                  = 0x163c000
mprotect(0x171e000, 159112, PROT_NONE)  = 0
mmap(0x8080808, 134744072, 0x8080808, MAP_PRIVATE|0x10200, 50529027, 0x4040404) = 0x172c000
mmap(0, 0, PROT_NONE, MAP_FILE, 0, 0)   = 0x1741000
close(3)                                = 0
munmap(0x30014000, 8116)                = 0
getpid()                                = 455
brk(0)                                  = 0x1876b1c
brk(0x1876cbc)                          = 0x1876cbc
brk(0)                                  = 0x1876cbc
brk(0x1877000)                          = 0x1877000
getuid()                                = 0
getgid()                                = 0
geteuid()                               = 0
getegid()                               = 0
brk(0)                                  = 0x1877000
brk(0x1878000)                          = 0x1878000
socket(PF_UNIX, SOCK_STREAM, 0)         = 3
connect(3, {sun_family=AF_UNIX, sun_path="/var/run/.nscd_socket"}, 110) = -1 ECONNREFUSED (Connection refused)
close(3)                                = 0
open("/etc/nsswitch.conf", O_RDONLY)    = 3
fstat(3, {st_mode=0200000, st_size=939928248, ...}) = 0
mmap(ptrace: umoven: Input/output error
)                                  = 0x30014000
read(3, "# /etc/nsswitch.conf\n#\n# Examp"..., 4096) = 465
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x30014000, 4096)                = 0
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=0200000, st_size=939928254, ...}) = 0
mmap(ptrace: umoven: Input/output error
)                                  = 0x30014000
close(3)                                = 0
open("/lib/libnss_compat.so.2", O_RDONLY) = 3
fstat(3, {st_mode=0200000, st_size=939928248, ...}) = 0
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096
mmap(ptrace: umoven: Input/output error
)                                  = 0x1610000
mprotect(0x161b000, 67532, PROT_NONE)   = 0
mmap(0, 0, PROT_NONE, MAP_FILE, 0, 0)   = 0x1620000
close(3)                                = 0
open("/lib/libnsl.so.1", O_RDONLY)      = 3
fstat(3, {st_mode=0200000, st_size=939928254, ...}) = 0
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096
mmap(ptrace: umoven: Input/output error
)                                  = 0x15d7000
mprotect(0x15eb000, 85880, PROT_NONE)   = 0
mmap(0, 0, PROT_NONE, MAP_FILE, 0, 0)   = 0x15f7000
mmap(0, 0, PROT_NONE, MAP_FILE, 0, 0)   = 0x15fe000
close(3)                                = 0
munmap(0x30014000, 8116)                = 0
uname({sys="Linux", node="caramela", ...}) = 0
open("/etc/passwd", O_RDONLY)           = 3
fcntl(3, F_GETFD)                       = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
fstat(3, {st_mode=0200000, st_size=939928248, ...}) = 0
mmap(ptrace: umoven: Input/output error
)                                  = 0x30014000
_llseek(0x3, 0, 0, 0x7ffff648, 0x1)     = 0
read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1517
close(3)                                = 0
munmap(0x30014000, 4096)                = 0
open("/etc/minirc.dfl", O_RDONLY)       = 3
fstat(3, {st_mode=0200000, st_size=939928248, ...}) = 0
mmap(ptrace: umoven: Input/output error
)                                  = 0x30014000
read(3, "# Machine-generated file - use \""..., 4096) = 300
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x30014000, 4096)                = 0
open("/root/.minirc.dfl", O_RDONLY)     = -1 ENOENT (No such file or directory)
open("/root/.macros", O_RDONLY)         = -1 ENOENT (No such file or directory)
setregid(0, 0)                          = 0
setreuid(0, 0)                          = 0
stat("/var/lock", {st_mode=0400000, st_size=25, ...}) = 0
open("/var/lock/LCK..ttyS0", O_RDONLY)  = -1 ENOENT (No such file or directory)
rt_sigaction(0xe, 0x7ffff698, 0x7ffff728, 0x8) = 0
alarm(0x2, 0x7ffff7b4, 0, 0x8, 0x7f7f7f7f) = 0
open("/dev/ttyS0", O_RDWR|O_NONBLOCK)   = 3
--- SIGALRM (Alarm clock) ---
alarm(0, 0x1, 0, 0x8, 0x7f7f7f7f)       = 0
rt_sigaction(0xe, 0x7ffff698, 0x7ffff728, 0x8) = 0
write(2, "minicom: cannot open /dev/ttyS0:"..., 59minicom: cannot open /dev/ttyS0: No such file or directory
) = 59
setregid(0, 0)                          = 0
setreuid(0, 0)                          = 0
exit(1)                                 = ?

Re: serial on lombard

[Benjamin Herrenschmidt]

On Thu, Oct 14, 1999, Mario Scarpa <m.scarpa@mondonet.net> wrote:

>there's something I cannot get rid of. When I try to
>use minicom to dial with the internal modem of my
>lombard 400MHz I get a "/dev/ttyS0 no such file or dir"
>error; when I try to use setserial or stty on the same
>device everything works ok. I'm using debian potato.
>Attached there 's the 'strace minicom' output: hope this helps.

This exact same problem happens on my wallstreet. I'm not yet 100% sure,
but I think this is because minicom sets up some kind of timeout on the
open call via an alarm signal which fails since the powerbook internal
modem will block the opening process for about 2.5 second in the open
call. We added this tempo since the modem is only powered up when the
port is opened, and it needs approximately this time before beeing able
to answer commands. This used to cause most connection scripts
(especially default PPP scripts) to fail.

Fixing minicom is in my todolist, I'll try to give it a look next we.

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: serial on lombard

[Michael Schmitz]

> alarm(0x2, 0x7ffff7b4, 0, 0x8, 0x7f7f7f7f) = 0
> open("/dev/ttyS0", O_RDWR|O_NONBLOCK)   = 3
> --- SIGALRM (Alarm clock) ---
> alarm(0, 0x1, 0, 0x8, 0x7f7f7f7f)       = 0
> rt_sigaction(0xe, 0x7ffff698, 0x7ffff728, 0x8) = 0
> write(2, "minicom: cannot open /dev/ttyS0:"..., 59minicom: cannot open /dev/ttyS0: No such file or directory
> ) = 59

The port blocks on open, and you get a timeout. 

The serial port won't open without carrier detected. minicom fails to set
the port characteristics properly (or the Mac serial driver doesn't honor
minicom's port settings), and gives a very confusing error message (open
/dev/ttyS0 timed out would have been more accurate). 

Set ttyS0 to ignore DCD with stty clocal </dev/ttyS0, perhaps.

	Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: serial on lombard

[Momchil Velikov]

Michael Schmitz wrote:
> 
> > alarm(0x2, 0x7ffff7b4, 0, 0x8, 0x7f7f7f7f) = 0
> > open("/dev/ttyS0", O_RDWR|O_NONBLOCK)   = 3
> > --- SIGALRM (Alarm clock) ---
> > alarm(0, 0x1, 0, 0x8, 0x7f7f7f7f)       = 0
> > rt_sigaction(0xe, 0x7ffff698, 0x7ffff728, 0x8) = 0
> > write(2, "minicom: cannot open /dev/ttyS0:"..., 59minicom: cannot open /dev/ttyS0: No such file or directory
> > ) = 59
> 
> The port blocks on open, and you get a timeout.

But there is O_NONBLOCK, and according to POSIX, 
" ... if O_NONBLOCK flags is set or if CLOCAL has been set,
  the open() function shall return immediately without
  waiting for the connection."

Note that this is the/a way to set CLOCAL -- open the device with O_NONBLOCK
and then tcsetattr() or whatever.

> 
> The serial port won't open without carrier detected. minicom fails to set
> the port characteristics properly (or the Mac serial driver doesn't honor
> minicom's port settings), and gives a very confusing error message (open
> /dev/ttyS0 timed out would have been more accurate).
> 
> Set ttyS0 to ignore DCD with stty clocal </dev/ttyS0, perhaps.

This should help, but the problem is in the driver.

Regards,
-velco

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: serial on lombard

[Chris Ridd]

On Thu, 14 Oct 1999 14:31:51 +0300, Momchil Velikov wrote:
> 
> Michael Schmitz wrote:
> > 
> > > alarm(0x2, 0x7ffff7b4, 0, 0x8, 0x7f7f7f7f) = 0
> > > open("/dev/ttyS0", O_RDWR|O_NONBLOCK)   = 3
> > > --- SIGALRM (Alarm clock) ---
> > > alarm(0, 0x1, 0, 0x8, 0x7f7f7f7f)       = 0
> > > rt_sigaction(0xe, 0x7ffff698, 0x7ffff728, 0x8) = 0
> > > write(2, "minicom: cannot open /dev/ttyS0:"..., 59minicom: cannot open /dev/ttyS0: No such file or directory
> > > ) = 59
> > 
> > The port blocks on open, and you get a timeout.
> 
> But there is O_NONBLOCK, and according to POSIX, 
> " ... if O_NONBLOCK flags is set or if CLOCAL has been set,
>   the open() function shall return immediately without
>   waiting for the connection."
> 
> Note that this is the/a way to set CLOCAL -- open the device with O_NONBLOCK
> and then tcsetattr() or whatever.

The open on /dev/ttyS0 returns a valid fd, so it is succeeding. As BenH 
pointed out, the problem is the SIGALRM ringing which causes Minicom to 
erroneously think it couldn't open the device.

Chris


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: serial on lombard

[Benjamin Herrenschmidt]

On Thu, Oct 14, 1999, Chris Ridd <Chris.Ridd@messagingdirect.com> wrote:

>> Note that this is the/a way to set CLOCAL -- open the device with
O_NONBLOCK
>> and then tcsetattr() or whatever.
>
>The open on /dev/ttyS0 returns a valid fd, so it is succeeding. As BenH 
>pointed out, the problem is the SIGALRM ringing which causes Minicom to 
>erroneously think it couldn't open the device.

I just checked and yes, the driver doesn't check the O_NONBLOCK flag, it
always block for 2.5s (since, I think, there's no DCD, it's a hackish
workaround). Now, we could eventually check more closely, it's possible
that there's actually a DTR on this internal modem. I heard from Apple
sources that the wiring of this modem to the SCC was a little bit weird,
it's possible that the DTR is indeed available either on the flow control
input pin (but I don't think so) or on the GPio pin. In this case, we
should check this instead of waiting for an arbitrary amount of time.

Note that this error should not happen with other serial ports, this
tempo is only used with the powerbook's internal modem (triggered by the
"cobalt" compatible propery in the device tree).

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: serial on lombard

[Momchil Velikov]

Benjamin Herrenschmidt wrote:
> 
> On Thu, Oct 14, 1999, Chris Ridd <Chris.Ridd@messagingdirect.com> wrote:
> 
> >> Note that this is the/a way to set CLOCAL -- open the device with
> O_NONBLOCK
> >> and then tcsetattr() or whatever.
> >
> >The open on /dev/ttyS0 returns a valid fd, so it is succeeding. As BenH
> >pointed out, the problem is the SIGALRM ringing which causes Minicom to
> >erroneously think it couldn't open the device.
> 
> I just checked and yes, the driver doesn't check the O_NONBLOCK flag, it

This is not necessarily wrong, if the driver's routine doesn't block,
there is no need to check O_NONBLOCK, no matter how slow the routine is.

> always block for 2.5s (since, I think, there's no DCD, it's a hackish
> workaround). Now, we could eventually check more closely, it's possible
> that there's actually a DTR on this internal modem. I heard from Apple
> sources that the wiring of this modem to the SCC was a little bit weird,
> it's possible that the DTR is indeed available either on the flow control
> input pin (but I don't think so) or on the GPio pin. In this case, we
> should check this instead of waiting for an arbitrary amount of time.
> 
> Note that this error should not happen with other serial ports, this
> tempo is only used with the powerbook's internal modem (triggered by the
> "cobalt" compatible propery in the device tree).

I guess, Chris is right. Minicom should use the alarm only as a mean to
cause open() to return -1 and EINTR. And it has to account for such
devices by setting larger timeout.

Regards,
-velco

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: serial on lombard

[Michael Schmitz]

> 
> On Thu, Oct 14, 1999, Chris Ridd <Chris.Ridd@messagingdirect.com> wrote:
> 
> >> Note that this is the/a way to set CLOCAL -- open the device with
> O_NONBLOCK
> >> and then tcsetattr() or whatever.

My bad. I was confused by the alarm coming in after the open call apparently
returned. And I had forgotten the specific trick to set CLOCAL. 

> >The open on /dev/ttyS0 returns a valid fd, so it is succeeding. As BenH 
> >pointed out, the problem is the SIGALRM ringing which causes Minicom to 
> >erroneously think it couldn't open the device.

But it shouldn't timeout if the open hadn't blocked some way or other. 
 
> I just checked and yes, the driver doesn't check the O_NONBLOCK flag, it
> always block for 2.5s (since, I think, there's no DCD, it's a hackish

Nah, that's the 2.5 sec wait for powering up the modem, which is,
unfortunately, before the block_til_ready. We could forgo this wait period
on O_NONBLOCK (maybe mark the wait pending, and make the next operation wait
instead). 
Anyway: how come open returns successfully but minicom still gets the
timeout? 

	Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: serial on lombard

[Benjamin Herrenschmidt]

On Thu, Oct 14, 1999, Michael Schmitz
<schmitz@opal.biophys.uni-duesseldorf.de> wrote:

>Nah, that's the 2.5 sec wait for powering up the modem, which is,
>unfortunately, before the block_til_ready. We could forgo this wait period
>on O_NONBLOCK (maybe mark the wait pending, and make the next operation wait
>instead). 
>Anyway: how come open returns successfully but minicom still gets the
>timeout? 

I fixed my minicom by bumping the timeout to 4 seconds:

--- minicom-1.82.orig/src/main.c	Thu Aug 27 00:54:16 1998
+++ minicom-1.82/src/main.c	Thu Oct 14 16:20:00 1999
@@ -158,7 +158,7 @@
   if (setjmp(albuf) == 0) {
 	portfd = -1;
 	signal(SIGALRM, get_alrm);
-	alarm(2);
+	alarm(4);
 #if defined(O_NDELAY) && defined(F_SETFL)
 	portfd = open(dial_tty, O_RDWR|O_NDELAY);
 	if (portfd >= 0){

I'll send this to the maintainer as well.

I'd like to add the patch to the existing patches in the .rpm, however I
don't know at all how RPM works and how to re-package that stuff, and I
really don't have time to read a doc today.

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: serial on lombard

[Momchil Velikov]

Benjamin Herrenschmidt wrote:
> --- minicom-1.82.orig/src/main.c        Thu Aug 27 00:54:16 1998
> +++ minicom-1.82/src/main.c     Thu Oct 14 16:20:00 1999
> @@ -158,7 +158,7 @@
>    if (setjmp(albuf) == 0) {
>         portfd = -1;
>         signal(SIGALRM, get_alrm);
> -       alarm(2);
> +       alarm(4);
>  #if defined(O_NDELAY) && defined(F_SETFL)
>         portfd = open(dial_tty, O_RDWR|O_NDELAY);
>         if (portfd >= 0){

I think the code should be as follows:
   signal( SIGALRM, a_signal_handler_which_just_returns );
   alarm(4);
   portfd = open( dial_tty, O_RDWR|O_NONBLOCK);
   alarm(0);
   if( portfd >= 0 ) {
      ...

In old code (and in the patched one too) there is a race condition
between clearing the alarm and signal delivery. A sequence similar
to the above one relies only on the return value of open().
Regards,
-velco

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: serial on lombard

[Michael Schmitz]

> I think the code should be as follows:
>    signal( SIGALRM, a_signal_handler_which_just_returns );
>    alarm(4);
>    portfd = open( dial_tty, O_RDWR|O_NONBLOCK);
>    alarm(0);
>    if( portfd >= 0 ) {
>       ...
> 
> In old code (and in the patched one too) there is a race condition
> between clearing the alarm and signal delivery. A sequence similar
> to the above one relies only on the return value of open().
> Regards,

alarm(0) only clears the timer and won't change the return value of open. 
Watching the strace output closely you will see that the return value of 
open is filled in only after the alarm fired. The macserial open fails to 
check for pending signals after completing the modem powerup wait, and 
can't detect the timeout. 

	Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: serial on lombard

[Momchil Velikov]

Michael Schmitz wrote:
> 
> > I think the code should be as follows:
> >    signal( SIGALRM, a_signal_handler_which_just_returns );
> >    alarm(4);
> >    portfd = open( dial_tty, O_RDWR|O_NONBLOCK);
> >    alarm(0);
> >    if( portfd >= 0 ) {
> >       ...
> >
> > In old code (and in the patched one too) there is a race condition
> > between clearing the alarm and signal delivery. A sequence similar
> > to the above one relies only on the return value of open().
> > Regards,
> 
> alarm(0) only clears the timer and won't change the return value of open.
> Watching the strace output closely you will see that the return value of
> open is filled in only after the alarm fired. The macserial open fails to
> check for pending signals after completing the modem powerup wait, and
> can't detect the timeout.

There is no need to change the return value of open(). One should _examine_ it,
and the minicom doesn't do this -- its on the 0-branch of setjmp.
Actually, there is _absolutely_ no need for alarm() -- if you say
O_NONBLOCK, you should not expect to block and you should not try to work
around with some fancy timeouts and stuff. The old code, the proposed patch
and my proposal are simply pointless -- that's to say, they all try
to solve a problem which doesn't exist (and thay fail, of course ;-).

Regards,
-velco

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: serial on lombard

[Michael Schmitz]

> I fixed my minicom by bumping the timeout to 4 seconds:
> 
> --- minicom-1.82.orig/src/main.c	Thu Aug 27 00:54:16 1998
> +++ minicom-1.82/src/main.c	Thu Oct 14 16:20:00 1999
> @@ -158,7 +158,7 @@
>    if (setjmp(albuf) == 0) {
>  	portfd = -1;
>  	signal(SIGALRM, get_alrm);
> -	alarm(2);
> +	alarm(4);
>  #if defined(O_NDELAY) && defined(F_SETFL)
>  	portfd = open(dial_tty, O_RDWR|O_NDELAY);
>  	if (portfd >= 0){

And I fixed it by modifying the serial port startup() code. Seems to work as
well - do we really need to wait that long for the modem to power up, or
will the modem just refuse to handshake while initializing?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: serial on lombard

[Benjamin Herrenschmidt]

On Thu, Oct 14, 1999, Michael Schmitz
<schmitz@opal.biophys.uni-duesseldorf.de> wrote:

>And I fixed it by modifying the serial port startup() code. Seems to work as
>well - do we really need to wait that long for the modem to power up, or
>will the modem just refuse to handshake while initializing?

What did you change in the startup() code ?

On the wallstreet, at least, (and possibly on the Lombard, if Paul could
check that the FCR bits are actually the same), without this delay, the
modem will not answer to AT commands. This causes almost all PPP dialers
out there to fail with their default scripts. It's possible to work
around this on some dialers (kppp has a tempo setting) but not all of
them. That's the main reason why we added this code. (I think Paul added
the clean sleep code, I originally throwed an horrible mdelay() which
locked the entire kernel waiting for the modem).


-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: serial on lombard

[Michael Schmitz]

> On Thu, Oct 14, 1999, Michael Schmitz
> <schmitz@opal.biophys.uni-duesseldorf.de> wrote:
> 
> >And I fixed it by modifying the serial port startup() code. Seems to work as
> >well - do we really need to wait that long for the modem to power up, or
> >will the modem just refuse to handshake while initializing?
> 
> What did you change in the startup() code ?

Pass !(filep->f_flags & O_NONBLOCK) as third argument 'do_wait' to startup,
and replace the if (delay) with if (delay && do_wait). 

> On the wallstreet, at least, (and possibly on the Lombard, if Paul could
> check that the FCR bits are actually the same), without this delay, the
> modem will not answer to AT commands. This causes almost all PPP dialers
> out there to fail with their default scripts. It's possible to work
> around this on some dialers (kppp has a tempo setting) but not all of
> them. That's the main reason why we added this code. (I think Paul added
> the clean sleep code, I originally throwed an horrible mdelay() which
> locked the entire kernel waiting for the modem).

That's possible; I have not tried a PPP dialer so far. Turns out that the
Gnome dialer is happy with this setup and initializes the modem fine as
before. The boneheaded thing still won't accept my ATX3 though. 
If the missing delay is a problem, we could push the delay to the subsequent 
write. But if mincom is the only program that is unhappy with the wait, it
sure is sufficient to fix minicom (and make the serial driver return
-ERESTARTSYS or similar if the wait was interrupted by a signal).

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: serial on lombard

[Mario Scarpa]

Michael Schmitz wrote:
>  But if mincom is the only program that is unhappy with the wait, it
> sure is sufficient to fix minicom (and make the serial driver return
> -ERESTARTSYS or similar if the wait was interrupted by a signal).

What about chat ? Fixing it will give a lot of us the
possibility to use PPP via command line (which I prefer
btw :)) and, Micheal, chat seems not to work.

-- 
Mario Scarpa

Mondonet NOC
Phone: +39 06 52.47.37.02

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: serial on lombard

[Benjamin Herrenschmidt]

On Thu, Oct 14, 1999, Mario Scarpa <m.scarpa@mondonet.net> wrote:

>>  But if mincom is the only program that is unhappy with the wait, it
>> sure is sufficient to fix minicom (and make the serial driver return
>> -ERESTARTSYS or similar if the wait was interrupted by a signal).
>
>What about chat ? Fixing it will give a lot of us the
>possibility to use PPP via command line (which I prefer
>btw :)) and, Micheal, chat seems not to work.

Could you elaborate ? With the current sleeping driver, both chat and PPP
are working just fine on my wallstreet from the command line. Is there
something wrong for you ?

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: serial on lombard

[Mario Scarpa]

> >What about chat ? Fixing it will give a lot of us the
> >possibility to use PPP via command line (which I prefer
> >btw :)) and, Micheal, chat seems not to work.
> 
> Could you elaborate ? With the current sleeping driver, both chat and PPP
> are working just fine on my wallstreet from the command line. Is there
> something wrong for you ?

The new sleeping driver !!!
I missed it. It works ok now.
Thanks.
 
-- 
Mario Scarpa

Mondonet NOC
Phone: +39 06 52.47.37.02

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: serial on lombard

[Michael Schmitz]

> Michael Schmitz wrote:
> >  But if mincom is the only program that is unhappy with the wait, it
> > sure is sufficient to fix minicom (and make the serial driver return
> > -ERESTARTSYS or similar if the wait was interrupted by a signal).
> 
> What about chat ? Fixing it will give a lot of us the
> possibility to use PPP via command line (which I prefer
> btw :)) and, Micheal, chat seems not to work.

What about it? I've never tried it. I can post a diff if you want to try my
kernel hack, but maybe it would make more sense to narrow down why chat
fails. strace -f pppd should also trace chat if pppd is set up to use chat.

	Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/