Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752018AbbHSGEo (ORCPT <rfc822;w@1wt.eu>);
	Wed, 19 Aug 2015 02:04:44 -0400
Received: from mail-la0-f66.google.com ([209.85.215.66]:35369 "EHLO
	mail-la0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751224AbbHSGEm (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 19 Aug 2015 02:04:42 -0400
MIME-Version: 1.0
In-Reply-To: <1439963634-12006-1-git-send-email-jiang.liu@linux.intel.com>
References: <alpine.DEB.2.11.1508182133010.3873@nanos>
	<1439963634-12006-1-git-send-email-jiang.liu@linux.intel.com>
Date: Wed, 19 Aug 2015 08:04:39 +0200
X-Google-Sender-Auth: 9F5jFjcjqhZmaFSzXT2It9_1bNo
Message-ID: <CAJZ5v0g7F+BRMzc9-uuxHAK896B-hoOJ5AW7M4jGpowVG+hujw@mail.gmail.com>
Subject: Re: [Patch v2] x86, ACPI, irq: Add a quirk to override SCI polarity
 for HyperV
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
        "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
        Nick Meier <nmeier@microsoft.com>,
        "Rafael J. Wysocki" <rjw@rjwysocki.net>,
        Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
        Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
        x86@kernel.org, ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 3126
Lines: 75

Hi,

On Wed, Aug 19, 2015 at 7:53 AM, Jiang Liu <jiang.liu@linux.intel.com> wrote:
> Nick Meier reported a regression with HyperV that "
>   After rebooting the VM, the following messages are logged in syslog
>   when trying to load the tulip driver:
>     tulip: Linux Tulip drivers version 1.1.15 (Feb 27, 2007)
>     tulip: 0000:00:0a.0: PCI INT A: failed to register GSI
>     tulip: Cannot enable tulip board #0, aborting
>     tulip: probe of 0000:00:0a.0 failed with error -16
>   Errors occur in 3.19.0 kernel
>   Works in 3.17 kernel.
> "
>
> According to the ACPI dump file posted by Nick at
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1440072
>
> The ACPI MADT table includes an interrupt source overridden entry for
> ACPI SCI:
> [236h 0566  1]                Subtable Type : 02 <Interrupt Source Override>
> [237h 0567  1]                       Length : 0A
> [238h 0568  1]                          Bus : 00
> [239h 0569  1]                       Source : 09
> [23Ah 0570  4]                    Interrupt : 00000009
> [23Eh 0574  2]        Flags (decoded below) : 000D
>                                    Polarity : 1
>                                Trigger Mode : 3
>
> And in DSDT table, we have _PRT method to define PCI interrupts, which
> eventually goes to:
>         Name (PRSA, ResourceTemplate ()
>         {
>             IRQ (Level, ActiveLow, Shared, )
>                 {3,4,5,7,9,10,11,12,14,15}
>         })
>         Name (PRSB, ResourceTemplate ()
>         {
>             IRQ (Level, ActiveLow, Shared, )
>                 {3,4,5,7,9,10,11,12,14,15}
>         })
>         Name (PRSC, ResourceTemplate ()
>         {
>             IRQ (Level, ActiveLow, Shared, )
>                 {3,4,5,7,9,10,11,12,14,15}
>         })
>         Name (PRSD, ResourceTemplate ()
>         {
>             IRQ (Level, ActiveLow, Shared, )
>                 {3,4,5,7,9,10,11,12,14,15}
>         })
>
> According to the MADT and DSDT tables above, IRQ 9 may be used for:
> 1) ACPI SCI in level, high mode
> 2) PCI legacy IRQ in level, low mode
> So there's a possible conflict in polarity setting for IRQ 9.
>
> Prior to commit cd68f6bd53cf ("x86, irq, acpi: Get rid of special
> handling of GSI for ACPI SCI"), ACPI SCI is handled specially and
> there's no check for conflicts between ACPI SCI and PCI legagy IRQ.
> And it seems that the HyperV hypervisor doesn't make use of the
> polarity configuration in IOAPIC entry, so it just works.

That likely means the previous behavior was the same as (or at least
analogous to) what happens on Windows which is what the firmware has
been tested against and that's why the bug in it has not been caught.
That in turn indicates that there may be more systems having this kind
of problems, possibly from other vendors too, so I'm wondering if we
can do something more generic than using a quirk here?

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/