Bug in serial.c

Bug in serial.c

[Marc Karasek]

I am doing some embedded development with the 2.4.x series and have noticed
a few things..

1) In 2.4.2 in order to compile with module support you also had to turn on
smp support.  This has been fixed in the 2.4.3 release.  This bloated the
kernel image to 600k+ which in an embedded world is not a good thing :-)

2) In 2.4.3 the console port using ttySX is broken.  It dumps fine to the
terminal but when you get to a point of entering data (login, configuration
scripts, etc) the terminal does not accept any input.  

So far I have been able to debug to the point where I see that the kernel is
receiving the characters from the serial.c driver.  But it never echos them
or does anything else with them.  I will continue to look into this at this
end.  

I was also wondering if anyone else has seen this or if a patch is avail for
this bug??

Marc Karasek
Sr. Firmware Engineer
iVivity Inc
marc_karasek@ivivity.com  

Re: Bug in serial.c

[Disconnect]

On Thu, 19 Apr 2001, Marc Karasek did have cause to say:

> 2) In 2.4.3 the console port using ttySX is broken.  It dumps fine to the
> terminal but when you get to a point of entering data (login, configuration
> scripts, etc) the terminal does not accept any input.  

Most gettys and such take a /dev/tty* argument, which has to be changed to
point to the serial port for a serial console. Config scripts (and
anything else) specifically using /dev/tty or /dev/console should work
fine, however. (I wouldn't recommend pointing a getty at /dev/console - we
had some issues on a headless server trying that. Easiest to point it at
/dev/ttyS0 or whatnot.)

> 
> So far I have been able to debug to the point where I see that the kernel is
> receiving the characters from the serial.c driver.  But it never echos them
> or does anything else with them.  I will continue to look into this at this
> end.  
> 
> I was also wondering if anyone else has seen this or if a patch is avail for
> this bug??
> 
> Marc Karasek
> Sr. Firmware Engineer
> iVivity Inc
> marc_karasek@ivivity.com  
> -
> 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/
---
   _.-=<Disconnect>=-._
|     dis@sigkill.net    | And Remember...
\  shawn@healthcite.com  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C++++$ ULBS*++++$ P+>+++ L++++>+++++ 
E--- W+++ N+@ o+>$ K? w--->+++++ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b++++>$ DI++++ D++(+++) G++ e* h(-)* r++ y++
------END GEEK CODE BLOCK------

Re: Bug in serial.c

[Richard B. Johnson]

On Thu, 19 Apr 2001, Marc Karasek wrote:

> I am doing some embedded development with the 2.4.x series and have noticed
> a few things..
>
[SNIPPED...]
 
> 
> 2) In 2.4.3 the console port using ttySX is broken.  It dumps fine to the
> terminal but when you get to a point of entering data (login, configuration
> scripts, etc) the terminal does not accept any input.  
>

It is not broken. It is used all the while in our embeded systems.
 
> So far I have been able to debug to the point where I see that the kernel is
> receiving the characters from the serial.c driver.  But it never echos them
> or does anything else with them.  I will continue to look into this at this
> end.  
> 

Did you ever initialize the terminal? And I'm not talking about baud-rate.
There is a termios structure of information necessary to configure a
terminal for I/O.

> I was also wondering if anyone else has seen this or if a patch is avail for
> this bug??

You refer to a BUG?  There isn't any of the kind you describe.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

RE: Bug in serial.c

[Marc Karasek]

I think maybe we have a miscommunication here..  I am not running any apps
(yet) all I am trying to do is get it to boot up under 2.4.3.  The
apps/daemons/modules are the next step.  I am just booting the standard
kernel to a login prompt.  (I am usng busybox for init.)  Before a login
prompt a script is run as part of inittab to setup the eth0 port, etc...
This requires some input from the console (in this case ttyS0).  It is at
this point that 2.4.2 works (accepts input and lets the script continue)
2.4.3 just sits there, you can bang on the keys all you want :-(  


Also, I did a diff between serial.c in 2.4.2 & 2.4.3 and there are a lot of
changes...  

 

-----Original Message-----
From: Richard B. Johnson
To: Marc Karasek
Sent: 4/19/01 12:07 PM
Subject: RE: Bug in serial.c 

On Thu, 19 Apr 2001, Marc Karasek wrote:

>  Did something change between 2.4.2 & 2.4.3? Under 2.4.2 I did not
have to
> init the terminal (are you refering to the host or client side?) and
just
> accepted the defaults (9600, 8n1) which was fine for debug and
terminal I/O.
> 
> 
> My issue is with 2.4.2 it works with 2.4.3 (same .config) it does not.
So
> in my mind this is a bug of some type.....  :-) 
> 
> Which kernel are you using in your embedded project??
> 

I have conditional compiles for 2.2.17 to 2.2.19 plus 2.4.1, 2.4.2,
2.4.3, 2.4.4-pre(something, maybe 4).

There have been a lot of changes (and bugs), but Serial TTY I/O has
not been one of them -- and I use RS-232C with ANSI escape sequences
(vt101 DEC), because we don't have a screen-card or a keyboard. I
would have been first to notice.

Of course my code DID initialize the terminal from the start, if yours
didn't, the defaults may have changed. There was an old bug with
flow-control (an X-OFF stuck-state), that required the terminal
to opened and closed twice to clear. I still have the work-around
in the init code.


/*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-*/
/*
 *  Since we __are__ init, we have to everything that is necessary to
 *  startup and maintain the system.
 */
int main(int argc, char *argv[])
{
    MEM *mem;
    size_t i;
    int fd, flags;
    speed_t baud;
    if((mem = (MEM *) malloc(sizeof(MEM))) == NULL)
        ERRORS(Malloc);
    strcpy(argv[0], "Platinum");
    argv[0] = mem->argv0;
    argv[1] = mem->argv1;
    argv[2] = NULL;
/*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-*/
/*
 *  We may have failed to open an initial console. Therefore, we do the
 *  terminal stuff over from scratch.
 */
    clr(&mem->st,  sizeof(struct termios));
    mem->st.c_cc[VINTR]    = (char) 'C' - 64;
    mem->st.c_cc[VQUIT]    = (char) '\\'- 64;
    mem->st.c_cc[VERASE]   = (char) '?' + 64;
    mem->st.c_cc[VKILL]    = (char) 'U' - 64;
    mem->st.c_cc[VEOF]     = (char) 'D' - 64;
    mem->st.c_cc[VTIME]    = (char)  0;
    mem->st.c_cc[VMIN]     = (char)  1;
    mem->st.c_cc[VSWTC]    = (char) '@' - 64;
    mem->st.c_cc[VSTART]   = (char) 'Q' - 64;
    mem->st.c_cc[VSTOP]    = (char) 'S' - 64;
    mem->st.c_cc[VSUSP]    = (char) 'Z' - 64;
    mem->st.c_cc[VEOL]     = (char) '@' - 64;
    mem->st.c_cc[VREPRINT] = (char) 'R' - 64;
    mem->st.c_cc[VDISCARD] = (char) 'O' - 64;
    mem->st.c_cc[VWERASE]  = (char) 'W' - 64;
    mem->st.c_cc[VLNEXT]   = (char) 'V' - 64;
    mem->st.c_cc[VEOL2]    = (char) '@' - 64;
    mem->st.c_oflag = OPOST|ONLCR;
    mem->st.c_iflag = ICRNL|IXON;
    mem->st.c_lflag =
ISIG|ICANON|ECHO|ECHOE|ECHOK|ECHOCTL|ECHOKE|IEXTEN;
    mem->st.c_cflag = B9600|CS8|CREAD|HUPCL|CLOCAL;
/*
 *  Because of a bug in the Linux 2.4.0 terminal driver, we have to do
 *  this twice to get the flow-control turned off.
 */
    for(i=0; i< 2; i++)
    {
        (void)close(STDIN_FILENO);
        (void)close(STDOUT_FILENO);
        (void)close(STDERR_FILENO);
        if((fd = open(stdcmd, O_RDWR|O_NDELAY, 0)) < 0)
            fd = open(Altcons, O_RDWR|O_NDELAY);
        if((flags = fcntl(fd, F_GETFL, 0)) == FAIL)
            ERRORS(Fcntl);
        flags &= ~O_NDELAY;
        if(fcntl(fd, F_SETFL, flags) == FAIL)
            ERRORS(Fcntl);
        if(!!fd)
        {
            if(dup2(fd, STDIN_FILENO) == FAIL)
                ERRORS(Dup2);
            if(dup2(fd, STDOUT_FILENO) == FAIL)
                ERRORS(Dup2);
            if(dup2(fd, STDERR_FILENO) == FAIL)
                ERRORS(Dup2);
            if(fd > 2) (void)close(fd);
        }
        else                         /* fd is STDIN_FILENO  */
        {
            if(dup(fd) == FAIL)      /* Make STDOUT_FILENO  */
                ERRORS(Dup);
            if(dup(fd) == FAIL)      /* Make STDERR_FILENO  */
                ERRORS(Dup);
        }
        if(tcflush(STDIN_FILENO, TCIFLUSH) < 0)
            ERRORS(Tcflush);
        if(tcsetattr(STDIN_FILENO, TCSANOW, &mem->st) < 0)
            ERRORS(Tcsetattr);
    }



Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: Bug in serial.c

[Steven Walter]

On Thu, Apr 19, 2001 at 11:32:20AM -0400, Marc Karasek wrote:
> I am doing some embedded development with the 2.4.x series and have noticed
> a few things..
> 
> 1) In 2.4.2 in order to compile with module support you also had to turn on
> smp support.  This has been fixed in the 2.4.3 release.  This bloated the
> kernel image to 600k+ which in an embedded world is not a good thing :-)
> 
> 2) In 2.4.3 the console port using ttySX is broken.  It dumps fine to the
> terminal but when you get to a point of entering data (login, configuration
> scripts, etc) the terminal does not accept any input.  
> 
> So far I have been able to debug to the point where I see that the kernel is
> receiving the characters from the serial.c driver.  But it never echos them
> or does anything else with them.  I will continue to look into this at this
> end.  
> 
> I was also wondering if anyone else has seen this or if a patch is avail for
> this bug??

Just a "me, too!" here.  I've seen some symptoms very similar to this
with the same kernel version.  When I try to run a getty a tty which is
also the console (not sure what happens if it isn't a console) it
freezes up and doesn't respond or echo kernels.  Works on 2.4.2, just
like yours.

>From an strace of getty, it appears to be hanging in ioctl(..., TCSETSW
I hope this gets resolved.  Its more than a little irritating.
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell

Re: Bug in serial.c

[Fabrice Gautier]

Same thing for me.

I'm using busybox as init/getty/shell.

Everything works fine with 2.4.2.
With 2.4.3 console output is fine but not input.

Thanks

-- 
Fabrice Gautier <gautier@email.enstfr>