>>> On 22.09.16 at 17:04, wrote:
> On 9/22/2016 10:26 PM, Jan Beulich wrote:
But please also answer the earlier question, which you did strip
>> from your reply:
>>
> >>> Which btw raises another question: Why are you in polling mode in
> >>> the first place? Do you have a U
On 9/22/2016 10:26 PM, Jan Beulich wrote:
But please also answer the earlier question, which you did strip
>> from your reply:
>>
>>> Which btw raises another question: Why are you in polling mode in
>>> the first place? Do you have a UART without working interrupt?
>
> I found there was no int
>>> On 22.09.16 at 16:18, wrote:
> On 9/21/2016 5:25 PM, Jan Beulich wrote:
> On 21.09.16 at 03:54, wrote:
>>> On 2016年09月20日 23:36, Jan Beulich wrote:
> The precondition of process_pending_softirq() working in the debug key
>> handler is that timer interrupt arrives on time and nmi_t
On 9/21/2016 5:25 PM, Jan Beulich wrote:
On 21.09.16 at 03:54, wrote:
On 2016年09月20日 23:36, Jan Beulich wrote:
The precondition of process_pending_softirq() working in the debug key
handler is that timer interrupt arrives on time and nmi_timer_fn() can
run to update nmi_timer_ticks before w
>>> On 21.09.16 at 03:54, wrote:
> On 2016年09月20日 23:36, Jan Beulich wrote:
>>> The precondition of process_pending_softirq() working in the debug key
>>> > handler is that timer interrupt arrives on time and nmi_timer_fn() can
>>> > run to update nmi_timer_ticks before watchdog timeout.
>> Precon
On 2016年09月20日 23:36, Jan Beulich wrote:
>> The precondition of process_pending_softirq() working in the debug key
>> > handler is that timer interrupt arrives on time and nmi_timer_fn() can
>> > run to update nmi_timer_ticks before watchdog timeout.
> Precondition?
Process_pending_softirq() in de
>>> On 20.09.16 at 16:52, wrote:
> On 9/19/2016 10:46 PM, Jan Beulich wrote:
Well, without a clear understanding of why the issue occurs (for
>> which I need to refer you back to the questionable stack dump)
>> I'm hesitant to agree to this step, yet ...
>>> >
>>> > After some resea
On 9/19/2016 10:46 PM, Jan Beulich wrote:
Well, without a clear understanding of why the issue occurs (for
>> which I need to refer you back to the questionable stack dump)
>> I'm hesitant to agree to this step, yet ...
>
> After some researches, I found do_invalid_op() on the stack dump is
> ca
>>> On 19.09.16 at 15:57, wrote:
>
> On 9/15/2016 10:32 PM, Jan Beulich wrote:
> On 15.09.16 at 16:16, wrote:
>>> On 9/13/2016 11:25 PM, Jan Beulich wrote:
Wait - what is do_invalid_op() doing on the stack? I don't think it
belongs there, and hence I wonder whether the keypress
>>
On 9/15/2016 10:32 PM, Jan Beulich wrote:
On 15.09.16 at 16:16, wrote:
On 9/13/2016 11:25 PM, Jan Beulich wrote:
Wait - what is do_invalid_op() doing on the stack? I don't think it
belongs there, and hence I wonder whether the keypress
happened after some already fatal event (in which case a
>>> On 15.09.16 at 16:16, wrote:
> On 9/13/2016 11:25 PM, Jan Beulich wrote:
>> Wait - what is do_invalid_op() doing on the stack? I don't think it
>> belongs there, and hence I wonder whether the keypress
>> happened after some already fatal event (in which case all bets
>> are off anyway).
>
>
On 9/13/2016 11:25 PM, Jan Beulich wrote:
Wait - what is do_invalid_op() doing on the stack? I don't think it
belongs there, and hence I wonder whether the keypress
happened after some already fatal event (in which case all bets
are off anyway).
Not clear why do_invalid_op() on the stack. There
>>> On 13.09.16 at 16:56, wrote:
Seems like mistakenly dropped xen-devel in my earlier reply; re-added.
> On 9/13/2016 5:02 PM, Jan Beulich wrote:
> On 13.09.16 at 09:12, wrote:
>>> On a machine with a mount of cpus, dump_timerq() lasts several seconds
>>> which may exceed watchdog timeout
13 matches
Mail list logo
