From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755800AbcGZLmL (ORCPT ); Tue, 26 Jul 2016 07:42:11 -0400 Received: from mx2.suse.de ([195.135.220.15]:37570 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753229AbcGZLmI (ORCPT ); Tue, 26 Jul 2016 07:42:08 -0400 Subject: Re: [PATCH] 8250: option 'force_polling' for buggy IRQs To: Greg KH References: <1469468175-15704-1-git-send-email-mstaudt@suse.de> <20160725174712.GA5752@kroah.com> Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org From: Max Staudt Message-ID: Date: Tue, 26 Jul 2016 13:42:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: <20160725174712.GA5752@kroah.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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