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: <1397435291.19944.176.camel@shinybook.infradead.org>
Date:	Mon, 14 Apr 2014 00:28:13 +0000
From:	"Woodhouse, David" <david.woodhouse@...el.com>
To:	"stefani@...bold.net" <stefani@...bold.net>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jiang.liu@...ux.intel.com" <jiang.liu@...ux.intel.com>,
	"daniel.vetter@...ll.ch" <daniel.vetter@...ll.ch>,
	"Zanoni, Paulo R" <paulo.r.zanoni@...el.com>,
	"greg@...ah.com" <greg@...ah.com>
Subject: Re: X86: kexec issues with i915 in 3.14

On Sun, 2014-04-13 at 22:01 +0200, Stefani Seibold wrote:
> Rebooting my kernel vanilla kernel 3.14 will fail with tons of kernel
> log messages:
> 
> [    0.262754] IOMMU: Setting identity map for device 0000:00:1a.0 [0x7c45f000 - 0x7c46bfff]
> [    0.262780] IOMMU: Setting identity map for device 0000:00:14.0 [0x7c45f000 - 0x7c46bfff]
> [    0.262798] IOMMU: Prepare 0-16MiB unity mapping for LPC
> [    0.262807] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff]
> [    0.262948] PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
> [    0.262948] dmar: DRHD: handling fault status reg 3
> [    0.262951] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr ffffe000 
> DMAR:[fault reason 05] PTE Write access is not set

I'm inferring from the subject line that you mean kexec, not
"rebooting"?

It looks like a peripheral device is being left active and doing DMA by
the previous kernel, rather than being shut down. So as soon as the new
kernel resets the IOMMU mappings, that peripheral device is causing
faults.

We really ought to rate-limit the faults and isolate the offending
device before there are 21,000 of them. As discussed elsewhere recently,
we could do with a way to tell the PCI layer that it offended us but I
suppose we could at *least* stop the IOMMU from reporting faults for it.

Is this new behaviour? I'm not sure why this should have changed...

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (3437 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ