Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753950AbdGSNjt (ORCPT ); Wed, 19 Jul 2017 09:39:49 -0400 Received: from mail7.pr.hu ([87.242.0.7]:54569 "EHLO mail7.pr.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753364AbdGSNjq (ORCPT ); Wed, 19 Jul 2017 09:39:46 -0400 To: lkml From: Boszormenyi Zoltan Subject: ACPI: IRQ x override to edge, high Message-ID: Date: Wed, 19 Jul 2017 15:39:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "prspamd3.pr.hu", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi, on two different Intel based POS machines where UARTs are crucial, I see such messages (4.11.7 now, seen with older kernels, too): [ 0.919239] ACPI: IRQ 4 override to edge, high [ 0.919334] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active) [ 0.919697] ACPI: IRQ 3 override to edge, high [ 0.919784] pnp 00:03: Plug and Play ACPI device, IDs PNP0501 (active) [ 0.920154] ACPI: IRQ 11 override to edge, high [ 0.920247] pnp 00:04: Plug and Play ACPI device, IDs PNP0501 (active) [ 0.920449] pnp 00:05: Plug and Play ACPI device, IDs PNP0501 (disabled) [ 0.920811] ACPI: IRQ 5 override to edge, high [ 0.920908] pnp 00:06: Plug and Play ACPI device, IDs PNP0501 (active) [ 0.921272] ACPI: IRQ 6 override to edge, high [ 0.921363] pnp 00:07: Plug and Play ACPI device, IDs PNP0501 (active) [...] Content analysis details: (2.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.2 ALL_TRUSTED Passed through trusted hosts only via SMTP 3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100% [score: 1.0000] 0.2 BAYES_999 BODY: Bayes spam probability is 99.9 to 100% [score: 1.0000] -1.3 AWL AWL: Adjusted score from AWL reputation of From: address X-Scan-Signature: 48655851012a525c67c379fb6cc9c196 X-Spam-Tracer: backend.mail.pr.hu 2.2 20170719133941Z Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1111 Lines: 25 Hi, on two different Intel based POS machines where UARTs are crucial, I see such messages (4.11.7 now, seen with older kernels, too): [ 0.919239] ACPI: IRQ 4 override to edge, high [ 0.919334] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active) [ 0.919697] ACPI: IRQ 3 override to edge, high [ 0.919784] pnp 00:03: Plug and Play ACPI device, IDs PNP0501 (active) [ 0.920154] ACPI: IRQ 11 override to edge, high [ 0.920247] pnp 00:04: Plug and Play ACPI device, IDs PNP0501 (active) [ 0.920449] pnp 00:05: Plug and Play ACPI device, IDs PNP0501 (disabled) [ 0.920811] ACPI: IRQ 5 override to edge, high [ 0.920908] pnp 00:06: Plug and Play ACPI device, IDs PNP0501 (active) [ 0.921272] ACPI: IRQ 6 override to edge, high [ 0.921363] pnp 00:07: Plug and Play ACPI device, IDs PNP0501 (active) It seems that the PnP and the ACPI tables are inconsistent and ACPI wins. Because of this, the UART IRQs don't work, write() or tcdrain() stalls. Is there a kernel parameter that convinces the Linux ACPI to avoid touching the PnP IRQs? Thanks in advance, Zolt?n B?sz?rm?nyi