On 2015/5/13 22:26, Jiri Kosina wrote:
> On Wed, 13 May 2015, 王龙 wrote:
>
>> Hi all,
>>
>> In kernel before 3.19, when trigger_all_cpu_backtrace() is called on x86,
>> it will trigger an NMI on each CPU and call show_regs(). But this can lead
>> to a hard lock up if the NMI comes in on another pr
On 2015/5/13 22:22, Steven Rostedt wrote:
> On Wed, 13 May 2015 22:14:54 +0800
> "王龙" wrote:
>
>
>> context. But how do we fix this problem in older version of kernel(eg, 3.10
>> stable)?
>> The 3.10 stable has no "switch printk routine" and "seq_buf" infrastructures.
>>
>> Could anyone give m
On Wed, 13 May 2015, 王龙 wrote:
> Hi all,
>
> In kernel before 3.19, when trigger_all_cpu_backtrace() is called on x86,
> it will trigger an NMI on each CPU and call show_regs(). But this can lead
> to a hard lock up if the NMI comes in on another printk().
>
> The commit a9edc88093287183ac934be
Hi all,
In kernel before 3.19, when trigger_all_cpu_backtrace() is called on x86,
it will trigger an NMI on each CPU and call show_regs(). But this can lead
to a hard lock up if the NMI comes in on another printk().
The commit a9edc88093287183ac934be44f295f183b2c62dd (x86/nmi: Perform a safe
NM
On Wed, 13 May 2015 22:14:54 +0800
"王龙" wrote:
> context. But how do we fix this problem in older version of kernel(eg, 3.10
> stable)?
> The 3.10 stable has no "switch printk routine" and "seq_buf" infrastructures.
>
> Could anyone give me some ideas?
>
Backport the necessary patches.
--
5 matches
Mail list logo