Something strange seems to have happened to my serial console setup.
I boot with console=ttyS1,115200n8 and I have a getty running on
/dev/ttyS1.
On older kernels, or if I remove the console= boot parameter, then my
getty works fine. On 3.19.3 with the console= parameter, something's
wrong with termios and I can't log in. Running:
# stty icanon </dev/ttyS1
breaks line this (partial strace results included):
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
ioctl(0, SNDCTL_TMR_STOP or SNDRV_TIMER_IOCTL_GINFO or TCSETSW,
{B115200 opost -isig icanon -echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
write(2, "stty: ", 6stty: ) = 6
write(2, "standard input: unable to perfor"..., 58standard input:
unable to perform all requested operations) = 58
IOW, the setting didn't stick. On the bad kernel, stty works just
fine on ttyS0. If I switch to using console=ttyS0,115200, then stty
works on ttyS1 and fails on ttyS0.
I have no idea what's going on here. I have two apparently identical
boxes. One of them has this problem and the other doesn't.
Thanks,
Andy
Hi Andy,
On 04/08/2015 05:17 PM, Andy Lutomirski wrote:
> Something strange seems to have happened to my serial console setup.
> I boot with console=ttyS1,115200n8 and I have a getty running on
> /dev/ttyS1.
>
> On older kernels, or if I remove the console= boot parameter, then my
> getty works fine. On 3.19.3 with the console= parameter, something's
> wrong with termios and I can't log in. Running:
Thanks for the report.
1. Please attach your dmesg.
2. Is this behavior new to 3.19.3? (iow, what was the last version
that you noticed didn't do this)
Regards,
Peter Hurley
> # stty icanon </dev/ttyS1
>
> breaks line this (partial strace results included):
>
> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
> ioctl(0, SNDCTL_TMR_STOP or SNDRV_TIMER_IOCTL_GINFO or TCSETSW,
> {B115200 opost -isig icanon -echo ...}) = 0
> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
> write(2, "stty: ", 6stty: ) = 6
> write(2, "standard input: unable to perfor"..., 58standard input:
> unable to perform all requested operations) = 58
>
> IOW, the setting didn't stick. On the bad kernel, stty works just
> fine on ttyS0. If I switch to using console=ttyS0,115200, then stty
> works on ttyS1 and fails on ttyS0.
>
> I have no idea what's going on here. I have two apparently identical
> boxes. One of them has this problem and the other doesn't.
On Wed, Apr 8, 2015 at 2:29 PM, Peter Hurley <[email protected]> wrote:
> Hi Andy,
>
> On 04/08/2015 05:17 PM, Andy Lutomirski wrote:
>> Something strange seems to have happened to my serial console setup.
>> I boot with console=ttyS1,115200n8 and I have a getty running on
>> /dev/ttyS1.
>>
>> On older kernels, or if I remove the console= boot parameter, then my
>> getty works fine. On 3.19.3 with the console= parameter, something's
>> wrong with termios and I can't log in. Running:
>
> Thanks for the report.
> 1. Please attach your dmesg.
> 2. Is this behavior new to 3.19.3? (iow, what was the last version
> that you noticed didn't do this)
I didn't have the problem before I reinstalled this box, upgraded from
3.15 to 3.19.3, and updated by Dell iDRAC7 firmware. Booting into
3.13-something does *not* fix the problem, so I'm not at all convinced
that the kernel version matters much. I'll try reverting the iDRAC7
thing, but I don't see why that would make any difference at all to
Linux.
dmesg attached. I don't even know what to look for there, though.
>
> Regards,
> Peter Hurley
>
>> # stty icanon </dev/ttyS1
>>
>> breaks line this (partial strace results included):
>>
>> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
>> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
>> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
>> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
>> ioctl(0, SNDCTL_TMR_STOP or SNDRV_TIMER_IOCTL_GINFO or TCSETSW,
>> {B115200 opost -isig icanon -echo ...}) = 0
>> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
>> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
>> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
>> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
>> write(2, "stty: ", 6stty: ) = 6
>> write(2, "standard input: unable to perfor"..., 58standard input:
>> unable to perform all requested operations) = 58
>>
>> IOW, the setting didn't stick. On the bad kernel, stty works just
>> fine on ttyS0. If I switch to using console=ttyS0,115200, then stty
>> works on ttyS1 and fails on ttyS0.
>>
>> I have no idea what's going on here. I have two apparently identical
>> boxes. One of them has this problem and the other doesn't.
>
--
Andy Lutomirski
AMA Capital Management, LLC
On 04/08/2015 05:40 PM, Andy Lutomirski wrote:
> On Wed, Apr 8, 2015 at 2:29 PM, Peter Hurley <[email protected]> wrote:
>> Hi Andy,
>>
>> On 04/08/2015 05:17 PM, Andy Lutomirski wrote:
>>> Something strange seems to have happened to my serial console setup.
>>> I boot with console=ttyS1,115200n8 and I have a getty running on
>>> /dev/ttyS1.
>>>
>>> On older kernels, or if I remove the console= boot parameter, then my
>>> getty works fine. On 3.19.3 with the console= parameter, something's
>>> wrong with termios and I can't log in. Running:
>>
>> Thanks for the report.
>> 1. Please attach your dmesg.
>> 2. Is this behavior new to 3.19.3? (iow, what was the last version
>> that you noticed didn't do this)
>
> I didn't have the problem before I reinstalled this box, upgraded from
> 3.15 to 3.19.3, and updated by Dell iDRAC7 firmware. Booting into
> 3.13-something does *not* fix the problem, so I'm not at all convinced
> that the kernel version matters much. I'll try reverting the iDRAC7
> thing, but I don't see why that would make any difference at all to
> Linux.
I think this is related to DRAC; maybe upgrading the firmware reset
the Serial communication settings in the system bios?
1. What's your getty command line?
2. Contents of /proc/tty/driver/serial when you think getty is running
and waiting for login (shows line signals).
Something to test is if you set getty to local line, does it work then.
I use agetty so my command line is:
/sbin/getty --noreset -8L 115200 ttyS0 vt102
Regards,
Peter Hurley
> dmesg attached. I don't even know what to look for there, though.
>
>>
>> Regards,
>> Peter Hurley
>>
>>> # stty icanon </dev/ttyS1
>>>
>>> breaks line this (partial strace results included):
>>>
>>> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
>>> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
>>> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
>>> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
>>> ioctl(0, SNDCTL_TMR_STOP or SNDRV_TIMER_IOCTL_GINFO or TCSETSW,
>>> {B115200 opost -isig icanon -echo ...}) = 0
>>> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
>>> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
>>> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
>>> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
>>> write(2, "stty: ", 6stty: ) = 6
>>> write(2, "standard input: unable to perfor"..., 58standard input:
>>> unable to perform all requested operations) = 58
>>>
>>> IOW, the setting didn't stick. On the bad kernel, stty works just
>>> fine on ttyS0. If I switch to using console=ttyS0,115200, then stty
>>> works on ttyS1 and fails on ttyS0.
>>>
>>> I have no idea what's going on here. I have two apparently identical
>>> boxes. One of them has this problem and the other doesn't.
>>
>
>
>
On Wed, Apr 8, 2015 at 4:32 PM, Peter Hurley <[email protected]> wrote:
> On 04/08/2015 05:40 PM, Andy Lutomirski wrote:
>> On Wed, Apr 8, 2015 at 2:29 PM, Peter Hurley <[email protected]> wrote:
>>> Hi Andy,
>>>
>>> On 04/08/2015 05:17 PM, Andy Lutomirski wrote:
>>>> Something strange seems to have happened to my serial console setup.
>>>> I boot with console=ttyS1,115200n8 and I have a getty running on
>>>> /dev/ttyS1.
>>>>
>>>> On older kernels, or if I remove the console= boot parameter, then my
>>>> getty works fine. On 3.19.3 with the console= parameter, something's
>>>> wrong with termios and I can't log in. Running:
>>>
>>> Thanks for the report.
>>> 1. Please attach your dmesg.
>>> 2. Is this behavior new to 3.19.3? (iow, what was the last version
>>> that you noticed didn't do this)
>>
>> I didn't have the problem before I reinstalled this box, upgraded from
>> 3.15 to 3.19.3, and updated by Dell iDRAC7 firmware. Booting into
>> 3.13-something does *not* fix the problem, so I'm not at all convinced
>> that the kernel version matters much. I'll try reverting the iDRAC7
>> thing, but I don't see why that would make any difference at all to
>> Linux.
>
> I think this is related to DRAC; maybe upgrading the firmware reset
> the Serial communication settings in the system bios?
>
The DRAC pretends to be a 16550, so I don't understand how it could
prevent Linux from reprogramming the line discipline. Also, if I
remove console=ttyS1,115200 from the kernel command line, it starts
working again.
> 1. What's your getty command line?
/sbin/getty -8 115200 ttyS1
> 2. Contents of /proc/tty/driver/serial when you think getty is running
> and waiting for login (shows line signals).
With getty running:
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:0 rx:0
1: uart:16550A port:000002F8 irq:3 tx:19828 rx:2 RTS|CTS|DTR
2: uart:unknown port:000003E8 irq:4
3: uart:unknown port:000002E8 irq:3
4: uart:unknown port:00000000 irq:0
(getty itself works fine)
When I type a username, I get:
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:0 rx:0
1: uart:16550A port:000002F8 irq:3 tx:19848 rx:10 RTS|CTS|DTR
2: uart:unknown port:000003E8 irq:4
3: uart:unknown port:000002E8 irq:3
4: uart:unknown port:00000000 irq:0
at that point, login is running, and it's login that doesn't work.
>
> Something to test is if you set getty to local line, does it work then.
> I use agetty so my command line is:
> /sbin/getty --noreset -8L 115200 ttyS0 vt102
I tried:
# /sbin/getty --noreset -8L 115200 ttyS1 vt102
it has exactly the same problem.
By adding a whole bunch of printks, I see that both ttyS0 and ttyS1
make it into uart_set_termios. But now it's time to home...
--Andy
>
> Regards,
> Peter Hurley
>
>
>> dmesg attached. I don't even know what to look for there, though.
>>
>>>
>>> Regards,
>>> Peter Hurley
>>>
>>>> # stty icanon </dev/ttyS1
>>>>
>>>> breaks line this (partial strace results included):
>>>>
>>>> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
>>>> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
>>>> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
>>>> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
>>>> ioctl(0, SNDCTL_TMR_STOP or SNDRV_TIMER_IOCTL_GINFO or TCSETSW,
>>>> {B115200 opost -isig icanon -echo ...}) = 0
>>>> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
>>>> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
>>>> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
>>>> TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
>>>> write(2, "stty: ", 6stty: ) = 6
>>>> write(2, "standard input: unable to perfor"..., 58standard input:
>>>> unable to perform all requested operations) = 58
>>>>
>>>> IOW, the setting didn't stick. On the bad kernel, stty works just
>>>> fine on ttyS0. If I switch to using console=ttyS0,115200, then stty
>>>> works on ttyS1 and fails on ttyS0.
>>>>
>>>> I have no idea what's going on here. I have two apparently identical
>>>> boxes. One of them has this problem and the other doesn't.
>>>
>>
>>
>>
>
--
Andy Lutomirski
AMA Capital Management, LLC
On Wed, Apr 8, 2015 at 5:45 PM, Andy Lutomirski <[email protected]> wrote:
> On Wed, Apr 8, 2015 at 4:32 PM, Peter Hurley <[email protected]> wrote:
>> On 04/08/2015 05:40 PM, Andy Lutomirski wrote:
>>> On Wed, Apr 8, 2015 at 2:29 PM, Peter Hurley <[email protected]> wrote:
>>>> Hi Andy,
>>>>
>>>> On 04/08/2015 05:17 PM, Andy Lutomirski wrote:
>>>>> Something strange seems to have happened to my serial console setup.
>>>>> I boot with console=ttyS1,115200n8 and I have a getty running on
>>>>> /dev/ttyS1.
>>>>>
>>>>> On older kernels, or if I remove the console= boot parameter, then my
>>>>> getty works fine. On 3.19.3 with the console= parameter, something's
>>>>> wrong with termios and I can't log in. Running:
>>>>
>>>> Thanks for the report.
>>>> 1. Please attach your dmesg.
>>>> 2. Is this behavior new to 3.19.3? (iow, what was the last version
>>>> that you noticed didn't do this)
>>>
>>> I didn't have the problem before I reinstalled this box, upgraded from
>>> 3.15 to 3.19.3, and updated by Dell iDRAC7 firmware. Booting into
>>> 3.13-something does *not* fix the problem, so I'm not at all convinced
>>> that the kernel version matters much. I'll try reverting the iDRAC7
>>> thing, but I don't see why that would make any difference at all to
>>> Linux.
>>
>> I think this is related to DRAC; maybe upgrading the firmware reset
>> the Serial communication settings in the system bios?
>>
>
> The DRAC pretends to be a 16550, so I don't understand how it could
> prevent Linux from reprogramming the line discipline. Also, if I
> remove console=ttyS1,115200 from the kernel command line, it starts
> working again.
>
>> 1. What's your getty command line?
>
> /sbin/getty -8 115200 ttyS1
>
>
>> 2. Contents of /proc/tty/driver/serial when you think getty is running
>> and waiting for login (shows line signals).
>
> With getty running:
>
> serinfo:1.0 driver revision:
> 0: uart:16550A port:000003F8 irq:4 tx:0 rx:0
> 1: uart:16550A port:000002F8 irq:3 tx:19828 rx:2 RTS|CTS|DTR
> 2: uart:unknown port:000003E8 irq:4
> 3: uart:unknown port:000002E8 irq:3
> 4: uart:unknown port:00000000 irq:0
>
> (getty itself works fine)
>
> When I type a username, I get:
>
> serinfo:1.0 driver revision:
> 0: uart:16550A port:000003F8 irq:4 tx:0 rx:0
> 1: uart:16550A port:000002F8 irq:3 tx:19848 rx:10 RTS|CTS|DTR
> 2: uart:unknown port:000003E8 irq:4
> 3: uart:unknown port:000002E8 irq:3
> 4: uart:unknown port:00000000 irq:0
>
> at that point, login is running, and it's login that doesn't work.
>
>>
>> Something to test is if you set getty to local line, does it work then.
>> I use agetty so my command line is:
>> /sbin/getty --noreset -8L 115200 ttyS0 vt102
>
> I tried:
>
> # /sbin/getty --noreset -8L 115200 ttyS1 vt102
>
> it has exactly the same problem.
>
> By adding a whole bunch of printks, I see that both ttyS0 and ttyS1
> make it into uart_set_termios. But now it's time to home...
OMFG I hate [insert long string of expletives] userspace bugs.
Some piece of crap user code regressed in some recent Ubuntu update
and left all the termios lock flags set on the console device,
presumably read from /proc/console.
So... false alarm, except that the kernel should maybe considering
disallowing such daft behavior or at least warning. Now I get to
figure out *which* userspace program regressed. I'm reasonably sure
it's either Plymouth or some horrendously buggy Debian/Ubuntu script
that controls it.
--Andy
On 04/08/2015 09:49 PM, Andy Lutomirski wrote:
> On Wed, Apr 8, 2015 at 5:45 PM, Andy Lutomirski <[email protected]> wrote:
>> On Wed, Apr 8, 2015 at 4:32 PM, Peter Hurley <[email protected]> wrote:
>>> On 04/08/2015 05:40 PM, Andy Lutomirski wrote:
>>>> On Wed, Apr 8, 2015 at 2:29 PM, Peter Hurley <[email protected]> wrote:
>>>>> Hi Andy,
>>>>>
>>>>> On 04/08/2015 05:17 PM, Andy Lutomirski wrote:
>>>>>> Something strange seems to have happened to my serial console setup.
>>>>>> I boot with console=ttyS1,115200n8 and I have a getty running on
>>>>>> /dev/ttyS1.
>>>>>>
>>>>>> On older kernels, or if I remove the console= boot parameter, then my
>>>>>> getty works fine. On 3.19.3 with the console= parameter, something's
>>>>>> wrong with termios and I can't log in. Running:
>>>>>
>>>>> Thanks for the report.
>>>>> 1. Please attach your dmesg.
>>>>> 2. Is this behavior new to 3.19.3? (iow, what was the last version
>>>>> that you noticed didn't do this)
>>>>
>>>> I didn't have the problem before I reinstalled this box, upgraded from
>>>> 3.15 to 3.19.3, and updated by Dell iDRAC7 firmware. Booting into
>>>> 3.13-something does *not* fix the problem, so I'm not at all convinced
>>>> that the kernel version matters much. I'll try reverting the iDRAC7
>>>> thing, but I don't see why that would make any difference at all to
>>>> Linux.
>>>
>>> I think this is related to DRAC; maybe upgrading the firmware reset
>>> the Serial communication settings in the system bios?
>>>
>>
>> The DRAC pretends to be a 16550, so I don't understand how it could
>> prevent Linux from reprogramming the line discipline. Also, if I
>> remove console=ttyS1,115200 from the kernel command line, it starts
>> working again.
I didn't realize from your initial report that input with getty was
working, otherwise I wouldn't have asked for the line settings.
>>> 1. What's your getty command line?
>>
>> /sbin/getty -8 115200 ttyS1
>>
>>
>>> 2. Contents of /proc/tty/driver/serial when you think getty is running
>>> and waiting for login (shows line signals).
>>
>> With getty running:
>>
>> serinfo:1.0 driver revision:
>> 0: uart:16550A port:000003F8 irq:4 tx:0 rx:0
>> 1: uart:16550A port:000002F8 irq:3 tx:19828 rx:2 RTS|CTS|DTR
>> 2: uart:unknown port:000003E8 irq:4
>> 3: uart:unknown port:000002E8 irq:3
>> 4: uart:unknown port:00000000 irq:0
>>
>> (getty itself works fine)
>>
>> When I type a username, I get:
>>
>> serinfo:1.0 driver revision:
>> 0: uart:16550A port:000003F8 irq:4 tx:0 rx:0
>> 1: uart:16550A port:000002F8 irq:3 tx:19848 rx:10 RTS|CTS|DTR
>> 2: uart:unknown port:000003E8 irq:4
>> 3: uart:unknown port:000002E8 irq:3
>> 4: uart:unknown port:00000000 irq:0
>>
>> at that point, login is running, and it's login that doesn't work.
>>
>>>
>>> Something to test is if you set getty to local line, does it work then.
>>> I use agetty so my command line is:
>>> /sbin/getty --noreset -8L 115200 ttyS0 vt102
>>
>> I tried:
>>
>> # /sbin/getty --noreset -8L 115200 ttyS1 vt102
>>
>> it has exactly the same problem.
>>
>> By adding a whole bunch of printks, I see that both ttyS0 and ttyS1
>> make it into uart_set_termios. But now it's time to home...
>
> OMFG I hate [insert long string of expletives] userspace bugs.
>
> Some piece of crap user code regressed in some recent Ubuntu update
> and left all the termios lock flags set on the console device,
> presumably read from /proc/console.
Either /dev/console or it found the console from
/sys/devices/virtual/tty/console/active.
I suspected the termios locking because that's really the only way
termios settings don't get set, but I couldn't imagine why login
would be flagging those. I hadn't considered that something would
leave them on for later processes.
> So... false alarm, except that the kernel should maybe considering
> disallowing such daft behavior or at least warning. Now I get to
> figure out *which* userspace program regressed. I'm reasonably sure
> it's either Plymouth or some horrendously buggy Debian/Ubuntu script
> that controls it.
Some weekend I'm going to package a NoPlymouth.
Regards,
Peter Hurley