linux-kernel - Re: intel-iommu: CONFIG

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: <20080508164504.GA20080@linux.intel.com>
Date:	Thu, 8 May 2008 09:45:04 -0700
From:	mark gross <mgross@...ux.intel.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Gabriel C <nix.or.die@...glemail.com>,
	linux-kernel@...r.kernel.org, ashok.raj@...el.com,
	shaohua.li@...el.com, anil.s.keshavamurthy@...el.com,
	jbarnes@...tuousgeek.org, linux-pci@...ey.karlin.mff.cuni.cz
Subject: Re: intel-iommu: CONFIG_DMAR*=y kills my box

On Thu, May 08, 2008 at 07:43:01AM -0700, mark gross wrote:
> On Tue, May 06, 2008 at 01:15:54PM -0700, Andrew Morton wrote:
> > On Wed, 30 Apr 2008 01:04:45 +0200
> > Gabriel C <nix.or.die@...glemail.com> wrote:
> > >
> > 
> > > > I think your bios is goofy / unprepared to support IOMMU / VT-d and
> > > > doing strange things with enumerated a parallel port on a PCIE bus with
> > > > VTD is turned on...
> > > 
> > > I will contact ASUS peoples about the BIOS but it has for sure VT-d support and it is enabled.
> > 
> > So..  what happened here?  It seems like a pretty fatal problem, and
> > personally I don't think that contacting vendors about BIOS upgrades is a
> > suitable general solution.  It would be much better to find a kernel-based
> > fix or workaround?
> >
> 
> I just got some expert advice on this issue.  I will try again and look
> for a problem with the iommu code getting executed before the USB / PCI
> bus is fully initialized.
> 
> also, I just realized that I was attempting to reproduce the failure on
> the MM tree, and re-reading the report I see its on the linux-next tree.
> 
> I'm retesting it this am.
>

linux-next works fine on my system :(  with intel-iommu on.

root@...sdv1:~# lspci
00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 02)
00:03.0 Communication controller: Intel Corporation 82G33/G31/P35/P31 Express MEI Controller (rev 02)
00:03.2 IDE interface: Intel Corporation 82G33/G31/P35/P31 Express PT IDER Controller (rev 02)
00:03.3 Serial controller: Intel Corporation 82G33/G31/P35/P31 Express Serial KT Controller (rev 02)
00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92) 00:1f.0 ISA bridge: Intel Corporation Unknown device 2910 (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
00:1f.5 IDE interface: Intel Corporation 82801I (ICH9 Family) 2 port SATA IDE Controller (rev 02)

Gabriel,

The idea that perhaps something changed in the boot order, resulting in
the DMAR initialization code getting executed before all of the PCI
stuff is set up makes sense, but I don't have a good way of testing it
at the moment. I'm going to try a few more config options (like building
everything as modules instead of mostly built-ins)

--mgross


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