I insert one printk into drivers/serial/serial_core.c:
uart_set_termios() to describe the issue.
static void uart_set_termios(struct tty_struct *tty, struct termios
*old_termios)
{
----snip----
unsigned int cflag = tty->termios->c_cflag;
BUG_ON(!kernel_locked());
+++printk("new_termios flag: 0x%x, old_termios flag: 0x%x\n");
+++ cflag, old_termios->c_cflag);
----snip ----
}
When I telnet my board and run the following command:
---- root:~> stty -F /dev/ttyS0 -crtscts
I got the following result from the console of my board:
---- root:~>new_termios flag: 0x1cb1, old_termios flag: 0x80001cb1
That's correct. CRTSCTS flag is clear
But when I type "ENTER" key on the console, I got:
----root:~>new_termios flag: 0x80001cb1, old_termios flag: 0x1cb1
The CRTSCTS flag is set back. But I didn't set it back, I just type "ENTER".
I guess, Is it a serial core bug?
-Aubrey
> When I telnet my board and run the following command:
> ---- root:~> stty -F /dev/ttyS0 -crtscts
>
> I got the following result from the console of my board:
> ---- root:~>new_termios flag: 0x1cb1, old_termios flag: 0x80001cb1
>
> That's correct. CRTSCTS flag is clear
>
> But when I type "ENTER" key on the console, I got:
> ----root:~>new_termios flag: 0x80001cb1, old_termios flag: 0x1cb1
What code is running on that console at the time. Most likely that user
code is also saving/restoring terminal settings so overwrite yours
On 2/1/07, Alan <[email protected]> wrote:
> > When I telnet my board and run the following command:
> > ---- root:~> stty -F /dev/ttyS0 -crtscts
> >
> > I got the following result from the console of my board:
> > ---- root:~>new_termios flag: 0x1cb1, old_termios flag: 0x80001cb1
> >
> > That's correct. CRTSCTS flag is clear
> >
> > But when I type "ENTER" key on the console, I got:
> > ----root:~>new_termios flag: 0x80001cb1, old_termios flag: 0x1cb1
>
> What code is running on that console at the time. Most likely that user
> code is also saving/restoring terminal settings so overwrite yours
>
I implemented the serial driver by myself, :). See the attachment.
I didn't save/restore terminal setting in the my_set_termios().
I trace this back till tty_tioctl(..., unsigned long arg), everytime I
type "ENTER" key,
the argument "arg" passed into tty_ioctl() is the address of a termios
structure, which include wrong c_cflag. It seems once the flag is
assigned by uart_set_options the first time, it's never changed. So
even userspace application changed the flag, it will be set back soon.
I'll dig into it. But I still think it's a bug.
-Aubrey
On Thu, Feb 01, 2007 at 10:33:40AM +0800, Aubrey Li wrote:
> On 2/1/07, Alan <[email protected]> wrote:
> >What code is running on that console at the time. Most likely that user
> >code is also saving/restoring terminal settings so overwrite yours
> >
>
> I implemented the serial driver by myself, :). See the attachment.
> I didn't save/restore terminal setting in the my_set_termios().
>
> I trace this back till tty_tioctl(..., unsigned long arg), everytime I
> type "ENTER" key,
> the argument "arg" passed into tty_ioctl() is the address of a termios
> structure, which include wrong c_cflag.
If userspace is issuing an ioctl to re-enable crtscts, and the kernel
is obliging, how can this be a kernel bug?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On 2/1/07, Russell King <[email protected]> wrote:
> On Thu, Feb 01, 2007 at 10:33:40AM +0800, Aubrey Li wrote:
> > On 2/1/07, Alan <[email protected]> wrote:
> > >What code is running on that console at the time. Most likely that user
> > >code is also saving/restoring terminal settings so overwrite yours
> > >
> >
> > I implemented the serial driver by myself, :). See the attachment.
> > I didn't save/restore terminal setting in the my_set_termios().
> >
> > I trace this back till tty_tioctl(..., unsigned long arg), everytime I
> > type "ENTER" key,
> > the argument "arg" passed into tty_ioctl() is the address of a termios
> > structure, which include wrong c_cflag.
>
> If userspace is issuing an ioctl to re-enable crtscts, and the kernel
> is obliging, how can this be a kernel bug?
But the fact is not.
1) kernel boot up and enable crtscts by default
2) issue an ioctl to disable crtscts.
3) not do anything but type "ENTER", kernel re-enable crtscts.
That's wrong. Terminal setting seems not be recorded by the serial core.
Is it clear?
-Aubrey
On 2/1/07, Tosoni <[email protected]> wrote:
> If I understand Alan'answer correctly:
>
> You appear to use a *shell* on that console. The shell gets your ENTER key
> and in the succeeding processing the shell resets the crtscts flag to what
> the shell thinks is right for him.
>
> The shell must make some tty tweaking in order to allow you to edit the
> commands.
>
> You must disable login, shell and anything on that port in order to make a
> significant test. But beware that in this case you will close and reopen the
> port each time you run your test.
>
But the problem seems not like you said.
if enable crtscts by default, your thoughts makes sense.
But if disable crtscts by default, the fact is not as your thoughts.
The following is the test result on my side.
===================================
root:~> cflag = 0x80001cb1, old = 0x1cb1
cflag = 0x1cb1, old = 0x80001cb1
cflag = 0x1cb1, old = 0x1cb1
===================================
When run "stty -F /dev/ttyS0 crtscts",
I got
------------
root:~> cflag = 0x80001cb1, old = 0x1cb1
------------
That means crtscts in the old terminal setting is disabled. Now it's enabled.
But When I type "ENTER" key,
I got
------------
cflag = 0x1cb1, old = 0x80001cb1
cflag = 0x1cb1, old = 0x1cb1
------------
That means terminal setting is back to crtscts disabled. But here I
didn't do anything to disable it, I just type "ENTER", crtscts setting
should keep enabled. What makes it back to disabled? Now I guess there
must be something wrong with serial core.
-Aubrey
On Thu, Feb 01, 2007 at 06:09:24PM +0800, Aubrey Li wrote:
> On 2/1/07, Russell King <[email protected]> wrote:
> >On Thu, Feb 01, 2007 at 10:33:40AM +0800, Aubrey Li wrote:
> >> On 2/1/07, Alan <[email protected]> wrote:
> >> >What code is running on that console at the time. Most likely that user
> >> >code is also saving/restoring terminal settings so overwrite yours
> >> >
> >>
> >> I implemented the serial driver by myself, :). See the attachment.
> >> I didn't save/restore terminal setting in the my_set_termios().
> >>
> >> I trace this back till tty_tioctl(..., unsigned long arg), everytime I
> >> type "ENTER" key,
> >> the argument "arg" passed into tty_ioctl() is the address of a termios
> >> structure, which include wrong c_cflag.
> >
> >If userspace is issuing an ioctl to re-enable crtscts, and the kernel
> >is obliging, how can this be a kernel bug?
>
> But the fact is not.
> 1) kernel boot up and enable crtscts by default
> 2) issue an ioctl to disable crtscts.
> 3) not do anything but type "ENTER", kernel re-enable crtscts.
>
> That's wrong. Terminal setting seems not be recorded by the serial core.
serial core does not and should not "record" the terminal settings.
That's the job of the tty layer.
> Is it clear?
No. You haven't analysed the call path causing tty_ioctl() to be
invoked, so you have no basis to point the finger *anywhere* at the
moment.
Find out from where tty_ioctl() is called - maybe by adding a call
to dump_stack(). I think you'll find it is coming from userspace.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
> I implemented the serial driver by myself, :). See the attachment.
> I didn't save/restore terminal setting in the my_set_termios().
Driver looks fine.
> I trace this back till tty_tioctl(..., unsigned long arg), everytime I
> type "ENTER" key,
> the argument "arg" passed into tty_ioctl() is the address of a termios
> structure, which include wrong c_cflag. It seems once the flag is
> assigned by uart_set_options the first time, it's never changed. So
> even userspace application changed the flag, it will be set back soon.
> I'll dig into it. But I still think it's a bug.
Which application (see from current->pid) seems to be calling the
tty_ioctl with the "wrong flag" ?
Aubrey Li wrote:
> But When I type "ENTER" key,
>
> I got
> ------------
> cflag = 0x1cb1, old = 0x80001cb1
> cflag = 0x1cb1, old = 0x1cb1
> ------------
> That means terminal setting is back to crtscts disabled. But here I
> didn't do anything to disable it, I just type "ENTER", crtscts setting
> should keep enabled. What makes it back to disabled? Now I guess there
> must be something wrong with serial core.
Is there an mgetty or similar program monitoring
the same serial port?
--
Paul Fulghum
Microgate Systems, Ltd.
On 2/1/07, Russell King <[email protected]> wrote:
> On Thu, Feb 01, 2007 at 06:09:24PM +0800, Aubrey Li wrote:
> > On 2/1/07, Russell King <[email protected]> wrote:
> > >On Thu, Feb 01, 2007 at 10:33:40AM +0800, Aubrey Li wrote:
> > >> On 2/1/07, Alan <[email protected]> wrote:
> > >> >What code is running on that console at the time. Most likely that user
> > >> >code is also saving/restoring terminal settings so overwrite yours
> > >> >
> > >>
> > >> I implemented the serial driver by myself, :). See the attachment.
> > >> I didn't save/restore terminal setting in the my_set_termios().
> > >>
> > >> I trace this back till tty_tioctl(..., unsigned long arg), everytime I
> > >> type "ENTER" key,
> > >> the argument "arg" passed into tty_ioctl() is the address of a termios
> > >> structure, which include wrong c_cflag.
> > >
> > >If userspace is issuing an ioctl to re-enable crtscts, and the kernel
> > >is obliging, how can this be a kernel bug?
> >
> > But the fact is not.
> > 1) kernel boot up and enable crtscts by default
> > 2) issue an ioctl to disable crtscts.
> > 3) not do anything but type "ENTER", kernel re-enable crtscts.
> >
> > That's wrong. Terminal setting seems not be recorded by the serial core.
>
> serial core does not and should not "record" the terminal settings.
> That's the job of the tty layer.
OK, if tty layer save the new terminal settings to an old one properly,
How could this happen?
>
> > Is it clear?
>
> No. You haven't analysed the call path causing tty_ioctl() to be
> invoked, so you have no basis to point the finger *anywhere* at the
> moment.
>
> Find out from where tty_ioctl() is called - maybe by adding a call
> to dump_stack(). I think you'll find it is coming from userspace.
>
If I recall correctly, the call path is as follows:
sys_ioctl->vfs_ioctl->do_ioctl->tty_ioctl->n_tty_ioctl->set_termios,
In set_termios, tmp_termios will be pointed to the argument "arg",
which includes the wrong c_cflag.
Yes, from the back trace stack, it appears to come from userspace. But
I didn't startup any application. If there should be one, I think it's
shell.
But why shell remembers the initial terminal settings correctly, other
than last inital terminal settings? It must be passed from kernel
space, from tty layer, right?
I can't believe it's caused by the userspace, I'll go further to find
the root cause.
-Aubrey
On Fri, Feb 02, 2007 at 01:54:23AM +0800, Aubrey Li wrote:
> On 2/1/07, Russell King <[email protected]> wrote:
> >serial core does not and should not "record" the terminal settings.
> >That's the job of the tty layer.
>
> OK, if tty layer save the new terminal settings to an old one properly,
> How could this happen?
I don't understand that comment.
> >No. You haven't analysed the call path causing tty_ioctl() to be
> >invoked, so you have no basis to point the finger *anywhere* at the
> >moment.
> >
> >Find out from where tty_ioctl() is called - maybe by adding a call
> >to dump_stack(). I think you'll find it is coming from userspace.
> >
>
> If I recall correctly, the call path is as follows:
>
> sys_ioctl->vfs_ioctl->do_ioctl->tty_ioctl->n_tty_ioctl->set_termios,
And here is the proof that it's *userspace* which is effecting this change.
If "sys_ioctl" is the very first function in the list then that's a result
of some userspace process issuing an ioctl.
> Yes, from the back trace stack, it appears to come from userspace. But
> I didn't startup any application. If there should be one, I think it's
> shell.
Shells typically alter the termios settings - eg, to turn off echo while
they're waiting for command input. When command input has finished (by
pressing the enter key) they typically turn it back on.
Changing the termios settings while the shell is waiting for input is not
something they expect to happen, and this is the kind of behaviour I'd
expect in this scenario.
> I can't believe it's caused by the userspace, I'll go further to find
> the root cause.
Ho hum. Guess you're in for a long investigation then. 8/
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: