On Wed, Apr 8, 2015 at 5:45 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Wed, Apr 8, 2015 at 4:32 PM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote: >> On 04/08/2015 05:40 PM, Andy Lutomirski wrote: >>> On Wed, Apr 8, 2015 at 2:29 PM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
