linux-kernel - Regression in intel_idle on Avaton/Rangely Mohon Peak board

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]

Date:	Tue, 1 Apr 2014 14:16:40 -0400
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	Len Brown <len.brown@...el.com>
CC:	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Arne Bockholdt <linux-kernel@...kholdt.com>,
	Jiang Liu <jiang.liu@...ux.intel.com>, <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Regression in intel_idle on Avaton/Rangely Mohon Peak board

Hi Len,

I've got an eval board with a 1.7GHz Avaton/C2000 that hangs at boot
shortly after the idle driver registration -- typically 1/2 dozen
dmesg lines later, around rtc init, or net stack init.

It may be that this early board/early bios makes it a non-issue for
mainline, but I figured I'd better mention it anyway.

Problem starts with commit v3.12-rc4-32-gfab04b2208dd
("intel_idle: Support Intel Atom Processor C2000 Product Family").

Even though a bisect leads here, this commit shouldn't be considered
in isolation however, since it depends on these earlier v3.12 commits:

commit v3.12-rc2-1-geba682a5aeb6
   "intel_idle: shrink states tables"

commit v3.12-rc2-2-g9d046ccb9808
   "intel_idle: mark states tables with __initdata tag"

..and then these v3.13 subsequent fixups;

commit v3.13-rc1-1-g22e580d07f65
   "intel_idle: Fixed C6 state on Avoton/Rangeley processors"

commit v3.13-rc7-1-gba0dc81ed5d9
   "Revert "intel_idle: mark states tables with __initdata tag""

commit v3.13-rc7-2-g88390996c95b
   "intel_idle: close avn_cstates array with correct marker"

However, even with all these present in v3.13-final, the board
still does the same thing as the bisected fab 04 commit.  Same
for v3.14-final and today's linux-next -- i.e. the regression
remains uninterrupted.

The interesting part is that a nearly identical board, but with
different (newer/faster) CPU and newer BIOS doesn't have the hang.

Hardware details:

board: intel Mohon Peak CRB GA-95PEV ALPHA2  rev0.3
BIOS: EDVLCRB1.86B.0010.R00.1303272109  03/27/2013
CPU (dmidecode):
        Family: Pentium 4
        ID: D0 06 04 00 FF FB EB 9F
        Signature: Type 0, Family 6, Model 77, Stepping 0
        Version: Genuine Intel(R) CPU   4000  @ 1.70GHz

The same board that doesn't hang, for comparison, has:

BIOS: EDVLCRB1.86B.0017.R00.1305271414  05/27/2013
CPU: (dmidecode):
        Family: Pentium 4
        ID: D0 06 04 00 FF FB EB 9F
        Signature: Type 0, Family 6, Model 77, Stepping 0
        Version: Genuine Intel(R) CPU   4000  @ 2.40GHz

Since it appears only the clock multiplier has changed, I'm
guessing we've hit a bug in the earlier BIOS.  These boards
don't have flash capable BIOS AFAICT -- looks like the little
trap-door socket style that houses a removable chip?

I have the full dmidecode files, dmesg from 3.11-distro kernel,
lspci, and /proc/cpuinfo from both boards, if that is needed.

Paul.
--
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/