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: <Pine.LNX.4.64.0710191300530.32497@iabervon.org>
Date:	Fri, 19 Oct 2007 13:42:00 -0400 (EDT)
From:	Daniel Barkalow <barkalow@...ervon.org>
To:	David Miller <davem@...emloft.net>
cc:	Shane.Huang@....com, 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

On Thu, 18 Oct 2007, David Miller wrote:

> 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.

And the same SATA controller could show up behind a different northbridge. 
It would be unfortunate to hit the same device bug independantly on each 
system and work around it by doing something that won't help the next 
user.

> 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.

Have we gotten around to having a device quirk for this? I bet it won't be 
too long before we see a system where the SATA controller doesn't work 
with INTX disabled and the ethernet controller doesn't work with it 
enabled, since we've seen devices with each of these bugs.

	-Daniel
*This .sig left intentionally blank*
-
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/