From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756955AbcG1Sxs (ORCPT ); Thu, 28 Jul 2016 14:53:48 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:46105 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755469AbcG1Sxp (ORCPT ); Thu, 28 Jul 2016 14:53:45 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Max Staudt Cc: "Theodore Ts'o" , One Thousand Gnomes , Greg KH , linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org References: <1469468175-15704-1-git-send-email-mstaudt@suse.de> <20160725174712.GA5752@kroah.com> <20160726150856.GA15676@kroah.com> <20160727130923.4c20524b@lxorguk.ukuu.org.uk> <2b140616-c210-e754-a854-cd6a5675277d@suse.de> <20160727133348.GB20032@thunk.org> Date: Thu, 28 Jul 2016 13:40:29 -0500 In-Reply-To: (Max Staudt's message of "Thu, 28 Jul 2016 11:59:20 +0200") Message-ID: <87mvl1hahu.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1bSqR1-0007tJ-4Y;;;mid=<87mvl1hahu.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=67.3.204.119;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/mCgFsLoRT0lnnqRguUNbf5br8kr3OaSk= X-SA-Exim-Connect-IP: 67.3.204.119 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4997] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Max Staudt X-Spam-Relay-Country: X-Spam-Timing: total 1288 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 14 (1.1%), b_tie_ro: 14 (1.1%), parse: 0.83 (0.1%), extract_message_metadata: 12 (0.9%), get_uri_detail_list: 1.40 (0.1%), tests_pri_-1000: 4.9 (0.4%), tests_pri_-950: 1.17 (0.1%), tests_pri_-900: 1.01 (0.1%), tests_pri_-400: 21 (1.6%), check_bayes: 19 (1.5%), b_tokenize: 6 (0.4%), b_tok_get_all: 7 (0.5%), b_comp_prob: 2.2 (0.2%), b_tok_touch_all: 2.7 (0.2%), b_finish: 0.67 (0.1%), tests_pri_0: 1226 (95.2%), check_dkim_signature: 0.54 (0.0%), check_dkim_adsp: 3.1 (0.2%), tests_pri_500: 4.3 (0.3%), poll_dns_idle: 0.15 (0.0%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] 8250: option 'force_polling' for buggy IRQs X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Max Staudt writes: > On 07/27/2016 03:33 PM, Theodore Ts'o wrote: > >> I wonder if it would just be simpler to make it be a CONFIG option >> which causes the irq value to zero in arch/x86/include/asm/serial.h? > > Alan hit the nail on the head in his reply to your email: I can't set the IRQ in > the system configuration. The other option is to compile a custom kernel for this > system, but that's exactly what I'd like to avoid. > > My motivation for this patch is to have a boot time option that allows *any* > kernel to boot on this broken hardware. This allows for console boot on a broken > machine even when the machine has never been used in serial console mode before, > and thus the hardware bug has not been discovered before either. *Scratches my head* There is already generic handling for this (that triggers polling) in the irq code if an irq is screaming. I am assuming the problem is that your irq never fires? Serial consoles are already polled for output. So nothing should care until userspace starts, and the full serial driver initializes. Hmm. The irq code already has handling for some of these situations, and if that handling is not sufficient I suspect we could pretty easily extend it for this case. For irqs that are screaming we disable them and then poll them. There there are the "irqfixup" and "irqpoll" command line options that when an irq is received the code tries all of the irq handlers. So I suspect either "irqfixup" or "irqpoll" would handle this for you. If not I am certain a small tweak to some of that code would work. That should be enough to get a system booted for debugging purposes, which is the point here. At which point you can dig in figure out what is wrong and get the problem design fixed. Eric