linux-kernel - Re: 3.2.1 Unable to reset IRR messages on boot

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]

Date:	Wed, 25 Jan 2012 08:49:48 -0500
From:	Josh Boyer <jwboyer@...hat.com>
To:	Suresh Siddha <suresh.b.siddha@...el.com>
Cc:	yinghai@...nel.org, linux-kernel@...r.kernel.org,
	kernel-team@...oraproject.org, midgoon@...il.com
Subject: Re: 3.2.1 Unable to reset IRR messages on boot

On Tue, Jan 24, 2012 at 05:24:11PM -0800, Suresh Siddha wrote:
> On Tue, 2012-01-24 at 19:04 -0500, Josh Boyer wrote:
> > We've had a report [1] from users booting the 3.2.1 kernel and getting a
> > large number of KERN_ERR messages that look like:
> > 
> > [    0.020902] Unable to reset IRR for apic: 2, pin :0
> > [    0.020970] Unable to reset IRR for apic: 2, pin :1
> > [    0.021012] Unable to reset IRR for apic: 2, pin :2
> > [    0.021077] Unable to reset IRR for apic: 2, pin :3
> > [    0.021138] Unable to reset IRR for apic: 2, pin :4
> > [    0.021199] Unable to reset IRR for apic: 2, pin :5
> > [    0.021261] Unable to reset IRR for apic: 2, pin :6
> > [    0.021323] Unable to reset IRR for apic: 2, pin :7
> > 
> > Digging through git, it seems that error message was added to 3.2 with
> > commit 1e75b31d63.  The commit log mentions kdump, but I don't believe the
> > user is doing kexec/kdump of any kind.  It seems a normal yum update/reboot
> > and they hit this.
> > 
> > Are there any details the user can gather to help debug this, or has
> > anyone seen this before?
> > 
> 
> complete dmesg (which will have the platform, io-apic version info etc)
> will be useful.

Attached.  If you prefer it inline, let me know.

> If we are seeing this during a regular boot and for the all the RTE
> entries for a specific io-apic, most likely something is wrong with that
> io-apic (probably a bogus one listed by the bios?). We should be able to
> make the kernel code bit more smart to workaround this.

The reporter (now CC'd) confirmed it was a normal boot.

josh

View attachment "dmesg-ioapic" of type "text/plain" (96446 bytes)