linux-kernel - Re: [patch] PCI: disable MSI on more ATI NorthBridges

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]

Message-Id: <20071018.044611.21595530.davem@davemloft.net>
Date:	Thu, 18 Oct 2007 04:46:11 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	Shane.Huang@....com
Cc:	gregkh@...e.de, htejun@...il.com, linux-kernel@...r.kernel.org,
	linux-pci@...ey.karlin.mff.cuni.cz, Henry.Su@....com,
	Libin.Yang@....com
Subject: Re: [patch] PCI: disable MSI on more ATI NorthBridges

From: "Shane Huang" <Shane.Huang@....com>
Date: Thu, 18 Oct 2007 18:37:59 +0800

> Hi Miller:
> 
> Thank you for your response.
> 
> The reason why MSIs of these northbridges do not work is still under
> further debug, we are NOT able to tell its hardware issue or software
> issue at this  time. But enablement of them will lead to the OS
> installation failure in many distributions like openSUSE, Ubuntu etc:
> https://bugzilla.novell.com/show_bug.cgi?id=302016
> 
> So we have to disable them firstly before we find out the root cause,
> maybe they are just workarounds.

This logic seems backwards, to me.  "shoot first, ask questions later"
To me this it not how to approach this problem.

Once you turn MSI off, there is next to no incentive to fix the
problem because users aren't running into it any longer.

The only two devices in that bug report which should be using MSI
would be the SATA controller and the broadcom ethernet NIC.  And by
the failed bootup logs provided by the user the problem is clearly
with the SATA controller.

One common problem we're finding is that some devices have a hardware
bug where setting INTX_DISABLE in the PCI COMMAND register masks MSI
interrupts too.

I mention this because the user in that report mentions that the
kernel upgrade causes the failure, and one thing we started doing not
too long ago was to set the INTX_DISABLE bit when MSI is enabled for a
device.

So maybe this SATA controller has this problem too.  It is easy to
test, simply comment out all of the pci_intx() function calls in
drivers/pci/msi.c and perform a test boot with MSI enabled.

I would rather you approach analysis of these kinds of MSI bugs in
this manner, instead of disabling MSI wholesale.  Because with the
latter approach it is nearly guarenteed that the real reason will only
be discovered with an extremely low priority.

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