linux-kernel - Re: IOMMU+DMAR causing NMIs-s

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: <alpine.LRH.2.20.1607132258001.30020@math.ut.ee>
Date:	Thu, 14 Jul 2016 00:52:02 +0300 (EEST)
From:	Meelis Roos <mroos@...ux.ee>
To:	Linda Knippers <linda.knippers@....com>
cc:	Alex Williamson <alex.williamson@...hat.com>,
	Joerg Roedel <joro@...tes.org>,
	David Woodhouse <dwmw2@...radead.org>,
	iommu@...ts.linux-foundation.org,
	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: IOMMU+DMAR causing NMIs-s

> >> Thanks. So device 00:1e.0 is a PCI-bridge which has some 32-bit
> >> PCI-devices behind it. One of these devices tries to read address
> >> 0xb000, which is blocked by the IOMMU and causes the fault seen in the
> >> screen-shot. The fault also causes a PCI-error which is then reported
> >> through the NMI, causing your kernel panic.
> >>
> >> So the 32bit PCI devices behind the bridge are:
> >>
> >> 01:03.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] ES1000 (rev 02) (prog-if 00 [VGA controller])
> >> 01:04.0 System peripheral: Compaq Computer Corporation Integrated Lights Out Controller (rev 03)
> >> 01:04.2 System peripheral: Compaq Computer Corporation Integrated Lights Out  Processor (rev 03)
> >> 01:04.4 USB controller: Hewlett-Packard Company Integrated Lights-Out Standard Virtual USB Controller (prog-if 00 [UHCI])
> >> 01:04.6 IPMI SMIC interface: Hewlett-Packard Company Integrated Lights-Out Standard KCS Interface (prog-if 01)
> >>
> >> Can you try to disable this 'Lights Out' processor? Maybe it is causing
> >> the issues. On the other side, the radeon driver for the ATI card is
> >> also know for causing faults from time to time. Can you capture the
> >> kernel messages right before a crash too?
> > 
> > IIRC, blacklisting the hpwdt module can defuse those NMIs and might
> > help us see more of the actual DMAR faults.  Blacklist in modprobe.d
> > and rebuild initrd. Thanks,
> > 
> > Alex
> > 
> > PS - never assume BIOS release notes are actually complete
> 
> I agree. I'd do the BIOS update and also make sure the iLO FW is current.

OK, updates to the latest BIOS, CPU microcode revison is now 0x1b 
instead of 0x19. ILO2 fw is already the latest.

The NMI-s still happen.

Disabled hpwdt. Now most boots are fine, only one hung with radeon 
loading:

http://kodu.ut.ee/~mroos/boot-radeon-1.png 

Vusal patterns also remind me that all the previous hangs were before 
radeon mode change - once radeon changes the mode, it already works.

-- 
Meelis Roos (mroos@...ux.ee)