Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754828AbbDICJI (ORCPT ); Wed, 8 Apr 2015 22:09:08 -0400 Received: from mail-qk0-f178.google.com ([209.85.220.178]:35530 "EHLO mail-qk0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754720AbbDICJC (ORCPT ); Wed, 8 Apr 2015 22:09:02 -0400 Message-ID: <5525DF3C.3070602@hurleysoftware.com> Date: Wed, 08 Apr 2015 22:09:00 -0400 From: Peter Hurley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Andy Lutomirski CC: "linux-kernel@vger.kernel.org" , Greg Kroah-Hartman , linux-serial@vger.kernel.org, Jiri Slaby , "Theodore Ts'o" Subject: Re: console=ttyS1 breaks ttyS1 termios and prevents me from logging in References: <55259DB1.4080104@hurleysoftware.com> <5525BA8D.8010708@hurleysoftware.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4393 Lines: 114 On 04/08/2015 09:49 PM, Andy Lutomirski wrote: > On Wed, Apr 8, 2015 at 5:45 PM, Andy Lutomirski wrote: >> On Wed, Apr 8, 2015 at 4:32 PM, Peter Hurley wrote: >>> On 04/08/2015 05:40 PM, Andy Lutomirski wrote: >>>> On Wed, Apr 8, 2015 at 2:29 PM, Peter Hurley 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 -- 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/