linux-kernel - Re: console issue since 3.6, console=ttyS1 hangs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 18 Oct 2016 14:29:30 -0500
From:   Nathan Zimmer <nzimmer@....com>
To:     Sean Young <sean@...s.org>
Cc:     Nathan Zimmer <nzimmer@....com>, linux-kernel@...r.kernel.org,
        linux-serial@...r.kernel.org, gregkh@...uxfoundation.org,
        alan@...ux.intel.com
Subject: Re: console issue since 3.6, console=ttyS1 hangs

On Tue, Oct 18, 2016 at 07:05:18PM +0100, Sean Young wrote:
> On Tue, Oct 18, 2016 at 11:40:04AM -0500, Nathan Zimmer wrote:
> > 3.7.0
> > cat /sys/bus/pnp/drivers/serial/*/resources
> > state = active
> > io 0x2f8-0x2ff
> > irq 12
> > dma disabled
> > 
> > 3.6.0
> > :~ # cat /sys/bus/pnp/drivers/serial/*/resources
> > cat: /sys/bus/pnp/drivers/serial/*/resources: No such file or directory
> 
> irq 12 for ttyS1? That should be irq 3. The bios is putting bogus information
> in pnp. Maybe there is rubbish in the bios setup or maybe it's fixed in a 
> newer bios update.
> 
> So before this change, the kernel would assume irq 3. After this change,
> the kernel first uses the information in pnp to see where the serial
> port is. It gets told that it's irq 12 and presumably it runs into all
> sorts of problems then. If memory serves that's the irq for the ps/2 mouse.
> 
> The interesting bit is in 3.6.0:
> 
> setserial
> /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
> 
> becomes in 3.7.0:
> 
> setserial
> /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 12
> 
> You should be able to set the right irq with setserial, but obviously
> that doesn't help you if it fails in early boot. It's not immediately
> obvious to me what can be done in the kernel for this. Maybe the dmesg
> output could inspire, thanks.
> 
> 
> Sean

Yea the changing irq seemed weird to me too but I couldn't manage a guess to why.

Here are the dmesgs.

Nate


View attachment "dmesg_3.6.0" of type "text/plain" (99632 bytes)

View attachment "dmesg_3.7.0" of type "text/plain" (97323 bytes)