On Thu, Mar 3, 2016 at 11:26 PM, Rasmus Villemoes
<li...@rasmusvillemoes.dk> wrote:
> On 4 March 2016 at 01:17, Andy Lutomirski <l...@amacapital.net> wrote:
>> On Thu, Mar 3, 2016 at 2:58 PM, Rasmus Villemoes
>> <li...@rasmusvillemoes.dk> wrote:
>>> Looking up the vvar mapping and dumping its contents sometimes results
>>> in a soft lockup. On 4.5-rc6+ (master from earlier today) it seems to be
>>> a little harder to trigger than on the 4.2something Ubuntu kernel I
>>> first saw it on, but in both cases it's easy to reproduce (10s of
>>> iterations at most) by running the below program in a loop.
>>>
>>
>> I can't reproduce this. Do you have a .config or some other hint?
>
> 4.2 config below, the 4.5 one is made from that with make olddefconfig.
>
>> Can you also give me the contents of
>> /sys/devices/system/clocksource/clocksource0/current_clocksource
>
> $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> tsc
>
>> the output from 'dmesg |grep -i hpet'?
>
> $ dmesg | grep -i hpet
> [ 0.000000] ACPI: HPET 0x00000000C8FE6238 000038 (v01 DELL CBX3
> 01072009 AMI. 00000005)
> [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
> [ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles:
> 0xffffffff, max_idle_ns: 133484882848 ns
> [ 0.000000] hpet clockevent registered
> [ 0.034922] DMAR-IR: HPET id 0 under DRHD base 0xfed91000
> [ 0.181862] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0
> [ 0.181865] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
> [ 0.183894] clocksource: Switched to clocksource hpet
> [ 0.597484] rtc_cmos 00:02: alarms up to one month, y3k, 242 bytes
> nvram, hpet irqs
>
>
>> And is this in a VM or on a native boot?
>
> It's on a Dell precision M2800 laptop (8 core, core-i7).
This presumably means that your HPET is unusually crappy.
An upcoming mitigation in 4.6 should prevent you from observing this
problem on your laptop:
commit bd902c536298830e4d126dcf6491b46d3f1bf96e
Author: Andy Lutomirski <l...@kernel.org>
Date: Tue Dec 29 20:12:24 2015 -0800
x86/vdso: Disallow vvar access to vclock IO for never-used vclocks
Thomas, I still think we should consider just deleting the HPET vclock
code and accept the syscall overhead on systems that are stuck using
HPET. If fast syscalls are available (which should include every
system with HPET, unless there are some 32-bit AMD systems lying
around), then the overhead in a syscall is *tiny* compared to the code
of the HPET read itself.
--Andy
