Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754783AbbDIAqK (ORCPT ); Wed, 8 Apr 2015 20:46:10 -0400 Received: from mail-lb0-f175.google.com ([209.85.217.175]:34769 "EHLO mail-lb0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754594AbbDIAqG (ORCPT ); Wed, 8 Apr 2015 20:46:06 -0400 MIME-Version: 1.0 In-Reply-To: <5525BA8D.8010708@hurleysoftware.com> References: <55259DB1.4080104@hurleysoftware.com> <5525BA8D.8010708@hurleysoftware.com> From: Andy Lutomirski Date: Wed, 8 Apr 2015 17:45:44 -0700 Message-ID: Subject: Re: console=ttyS1 breaks ttyS1 termios and prevents me from logging in To: Peter Hurley Cc: "linux-kernel@vger.kernel.org" , Greg Kroah-Hartman , linux-serial@vger.kernel.org, Jiri Slaby , "Theodore Ts'o" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4472 Lines: 132 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. > 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 >>> >>>> 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 -- 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/