linux-kernel - Re: [PATCH] 8250: option 'force

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, 26 Jul 2016 13:42:13 +0200
From:	Max Staudt <mstaudt@...e.de>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] 8250: option 'force_polling' for buggy IRQs

On 07/25/2016 07:47 PM, Greg KH wrote:
> On Mon, Jul 25, 2016 at 07:36:15PM +0200, Max Staudt wrote:
>> Some serial ports may not emit IRQs properly, or there may be a defect
>> in their routing on the motherboard.
>>
>> This patch allows these ports to be used anyway (or until a better
>> workaround is known for a specific platform), though with no guarantees.
>>
>> If you have such a buggy UART, boot Linux with 8250.force_polling=1 .
> 
> Ick, don't add new module parameters if at all possible.

I agree, I'd rather not add a parameter either, but...

- It's a hardware issue
- It needs to be handled at boot time
- It can't be auto-detected (AFAIK)

The idea is that this parameter allows for a workaround until someone comes
up with a workaround or autodetection (if ever). And it can be used to
debug future buggy hardware.

>> It is essentially the kernel level version of:
>>
>>   setserial /dev/ttySn irq 0
> 
> Why can't you just do this instead?

Because it's too late by the time we reach userspace.

In case of "console=ttyS0" the decision to use polling needs to happen before
ttyS0 is opened from userspace, as the system will otherwise hang for up to
30 seconds at a time. Input is mostly dropped, thus I can't even use BREAK+B
to force reboot it.

As it stands now, I can't even boot the system with "rdinit=/bin/bash".
The force_polling option makes the system somewhat usable, albeit the serial
output is very slow.

Curiously, the kernel's printk() is as fast as it should be. It's just
userspace that is slow. Any idea why that is the case?

The kbuild test bot spotted a mistake, I'll send a new patch.

Thanks,

Max