On Sun, 09 Sep 2007 18:31:45 +0200
Dennis Lubert <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
