linux-kernel - Re: DMAR error messages after 'shutdown -r'.

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

Date:	Wed, 16 Mar 2016 18:46:08 +0100
From:	Joerg Roedel <joro@...tes.org>
To:	Valdis.Kletnieks@...edu
Cc:	Hans de Goede <hdegoede@...hat.com>, Tejun Heo <tj@...nel.org>,
	iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	linux-ide@...r.kernel.org
Subject: Re: DMAR error messages after 'shutdown -r'.

On Mon, Mar 07, 2016 at 04:41:57PM -0500, Valdis.Kletnieks@...edu wrote:
> 
> lspci says:
> 00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
> 
> Not sure why I only see it on reboots - that means that when powering up, the kernel
> gets handed a device config it likes, but when rebooting, something is leaving the
> device in a config the kernel doesn't want to see.

Okay, so the BIOS defines one RMRR entry:

	DMAR: RMRR base: 0x000000cdb11000 end: 0x000000cdb30fff

But the device-scope doesn't seem to match any existing devices in your
system. At least no device gets the RMRR mappings later on.

That doesn't really matter, as the the fault-address of 0xcdacd000 is
outside of the defined RMRR range anyway.

Looking at the fault-address as system physical, is would be in this
range of system memory:

	BIOS-e820: [mem 0x00000000cd99b000-0x00000000ce3a0fff] reserved

Which is reserved for BIOS use. This looks very much like a missing RMRR
entry for that range, that has the sata controler in its device scope.

	Joerg