linux-kernel - Re: lockup when C1E and high-resolution timers enabled

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:	Sun, 14 Jun 2015 15:54:06 +0800
From:	Daniel J Blueman <daniel@...ra.org>
To:	Christoph Fritz <chf.fritz@...glemail.com>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: lockup when C1E and high-resolution timers enabled

On 14 June 2015 at 12:39, Christoph Fritz <chf.fritz@...glemail.com> wrote:
> On Sun, 2015-06-14 at 11:13 +0800, Daniel J Blueman wrote:
>> On Sunday, June 14, 2015 at 4:00:06 AM UTC+8, Christoph Fritz wrote:
>> > Hi,
>> >
>> >  on following computer configuration, I do get hard lockup under heavy
>> > IO-Load (using rsync):
>> >
>> >  - CONFIG_HIGH_RES_TIMERS=y
>> >  - CPU: AMD FX(tm)-8350 Eight-Core Processor (family 0x15 model 0x2)
>> >  - Motherboard: 'GA-970A-UD3P (rev. 1.0)' AMD 970/SB950
>> >  - BIOS: C1E enabled (on 'GA-970A-UD3P' there is no disable option)
>> >  - Kernels: 4.1.0-rc6, 4.0.x, 3.16.x
>> >
>> > Tests:
>> >  - add kernel parameter "idle=halt" -> system runs fine
>> >  - disable CONFIG_HIGH_RES_TIMERS -> system runs fine
>> >  - change motherboard and disable C1E -> system runs fine
>> >  - change CPU to AMD Phenom II X6 Processor -> system runs fine
>> [..]
>>
>> C1E disconnects HyperTransport links when all cores enter C1 (halt)
>> for a period of time; this is all at the platform level, so isn't due
>> to the kernel. The AMD AGESA code which controls the setup of this
>> mechanism is updated in the F2g BIOS:
>> http://www.gigabyte.com/products/product-page.aspx?pid=4717#bios
>>
>> Did you try both BIOS releases with defaults?
>
> Yes, rechecked both versions: Same bad behaviour.
>
>> If still issues, also try with the current family 10h microcode from
>> http://www.amd64.org/microcode/amd-ucode-latest.tar.bz2
>
> Don't you mean family 15h for 'AMD FX(tm)-8350' ?
>
> already using latest microcode:

As a workaround, you can probably just disable message triggered C1E
(see the BKDG p399 [1]):

val=0x$(setpci -s 00:18.4 0xd4.l) # read D18F3xD4
val=$((val &~(1 << 13))) # clear bit13 (MTC1eEn)
setpci -d 1022:1604 0xd4.l=$(printf %x $val) # write back

The chipset setup and behaviour is quite complex, so it's likely
Gigabyte haven't done their homework. The alternative is coreboot of
course.

Thanks,
  Daniel

[1] http://support.amd.com/TechDocs/42301_15h_Mod_00h-0Fh_BKDG.pdf
-- 
Daniel J Blueman
--
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/