linux-kernel - Re: tsc timer related problems/questions

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, 9 Sep 2007 17:49:35 +0100
From:	Arjan van de Ven <arjan@...radead.org>
To:	Dennis Lubert <plasmahh@....net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: tsc timer related problems/questions

On Sun, 09 Sep 2007 18:31:45 +0200
Dennis Lubert <plasmahh@....net> wrote:

Hi,

> 
> [105771.523771] BUG: soft lockup detected on CPU#1!
> [105771.527869]
> [105771.527871] Call Trace:
> [105771.536079]  <IRQ>  [<ffffffff802619cc>] _spin_lock+0x9/0xb
> [105771.540294]  [<ffffffff802a6f9d>] softlockup_tick+0xd2/0xe7
> [105771.544359]  [<ffffffff8024bcbb>] run_local_timers+0x13/0x15
> [105771.548541]  [<ffffffff80289fc1>] update_process_times+0x4c/0x79
> [105771.552737]  [<ffffffff80270327>] smp_local_timer_interrupt
> +0x34/0x54
> [105771.556934]  [<ffffffff80270834>]
> smp_apic_timer_interrupt+0x51/0x68 [105771.561022]
> [<ffffffff80268121>] default_idle+0x0/0x42 [105771.565199]
> [<ffffffff8025cce6>] apic_timer_interrupt+0x66/0x70 [105771.569386]
> <EOI>  [<ffffffff8026814e>] default_idle+0x2d/0x42 [105771.573597]
> [<ffffffff80247929>] enter_idle+0x22/0x24 [105771.577665]
> [<ffffffff80247a92>] cpu_idle+0x5a/0x79 [105771.581838]
> [<ffffffff806bc5f7>] start_secondary+0x474/0x483
> 
> Question: Is this a known bug already or should further investigation
> take place?

this needs further investigation but note that this one can have many
different causes; this kind of oops trace often is also found for
certain types of BIOS bugs. (which makes it really painful to debug)

> 
> - Using Kernels from 2.6.21 on (random sampled) we experience that the
> TSC isn't used per default anymore (we usually set the nopmtimer
> option at boot for a while now). Looking briefly at the 2.6.23-rc5
> code shows that in the function where the check is done whether the
> tsc is stable the only code path where a "is stable" result could be
> returned is one where the vendor of the CPU is detected as Intel.
> Instead a much slower timesource (10ms instead of a few us
> resolution, same for getting the time at all) is used which is
> totally unusable for us (Within 10ms so much things happen).

Please consider enabling the HPET in your bios; while it's not as fast
as the tsc, it does provide the accuracy you want.
> 
> Question: Why are only Intel CPUs considered as stable? Could there be
> implemented a more sophisticated heuristic, that actually does some
> tests for tsc stability?

on AMD multi-socket systems, afaik the tsc is not synchronized between
packages. On Intel the tsc is derived from the FSB which is shared
between the packages.


HPET is central to the system and solves all the issues, but is a tad
slower to access than the tsc.
-
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/