linux-kernel - [regression, bisected] fails to boot on Dell Optiplex 760 with VT-d enabled

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-next>] [day] [month] [year] [list]

Message-ID: <4A89CB52.4030008@debian.org>
Date:	Tue, 18 Aug 2009 00:27:46 +0300
From:	Faidon Liambotis <paravoid@...ian.org>
To:	linux-kernel@...r.kernel.org
CC:	Suresh Siddha <suresh.b.siddha@...el.com>,
	Weidong Han <weidong.han@...el.com>,
	David Woodhouse <David.Woodhouse@...el.com>,
	iommu@...ts.linux-foundation.org, allen.m.kay@...el.com,
	fenghua.yu@...el.com
Subject: [regression, bisected] fails to boot on Dell Optiplex 760 with VT-d
 enabled

I am experiencin a bug on an Dell Optiplex 760 with a configuration that
has an Intel Core2 Q9550 CPU and with an up-to-date BIOS, version A03.

When "VT for Direct I/O" is enabled in the BIOS, v2.6.30 boots and works
perfectly, while v2.6.31-rc1..rc6 fail (both of them x86-64).

More specifically, I get an endless loop of printing the following
messages in
the screen:
        DMAR: [DMA Read] Request device [ff:1f.7] fault addr
              fffffffffffff000
        DMAR: [fault reason 255] Unknown
and the boot process doesn't move on from there.

I ran git bisect good v2.6.30/bad v2.6.31-rc1 and I was pointed to the
following commit:
	937582382c71b75b29fbb92615629494e1a05ac0
	x86, intr-remap: enable interrupt remapping early

I have no idea if VT-d is functioning on v2.6.30; I just had the option
enabled in the BIOS and noticed the problem when I tried to upgrade to
2.6.31-rcX.

I've read a similar bug report against a Mandriva kernel and another
VT-d related bug for the same hardware against Xen and in both threads
they were finger-pointing the BIOS.

I'm not sure if that's the case but, even if it is, I'd expect the
system to boot, like previous versions did, perhaps printing a warning
about VT-d functionality.

Thanks,
Faidon
--
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/