est itself and OS default stuff (using Centos 7.3) so before test
run cpu is mostly idle.
Problem description:
Observed kernel message "INFO: rcu_preempt detected stalls on CPUs/tasks"
while running strss-ng test.
Setup:
==
kernel: 4.13.0-rc7
Arch: arm64
Board:
On 05.11.2016 23:38, Gabriel C wrote:
Hello ,
I've tested 4.9-rcX and Linus git tree and have on this box the following
messages :
.
Nov 05 20:26:40 zwerg kernel: INFO: rcu_preempt detected stalls on CPUs/tasks:
Nov 05 20:26:40 zwerg kernel: Tasks blocked on level-0 rcu
Hello ,
I've tested 4.9-rcX and Linus git tree and have on this box the following
messages :
.
Nov 05 20:26:40 zwerg kernel: INFO: rcu_preempt detected stalls on CPUs/tasks:
Nov 05 20:26:40 zwerg kernel: Tasks blocked on level-0 rcu_node (CPUs
0-15): P0
Nov 05 20:26:40
t
on test machine: qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -m 360M
caused below changes:
[ 115.824398] INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 115.826472] All QSes seen, last rcu_preempt kthread activity 105002
(-184454--289456), jiffies_till_next_fqs=3, root -&
| 2 |
++++
[6.040069] usb usb1: SerialNumber: dummy_hcd.0
[6.041207] hub 1-0:1.0: USB hub found
[6.041745] hub 1-0:1.0: 1 port detected
[ 106.049840] INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 106.053605] Task dump for CPU 1:
[ 106.054024] k
14, 2014 at 10:35:10PM
>>>>>>>>>>>>>>>>> > > > >>>>>>> > >>> > > -0400, Sasha Levin wrote:
>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>> > >>>> > >>
14 02:39 PM, Paul E. McKenney wrote:
> > > >>>>>>> > >>> > > On Tue, Oct 14, 2014 at 10:35:10PM -0400, Sasha Levin
> > > >>>>>>> > >>> > > wrote:
> > > >>>>>>>>&g
The stack dumps are pretty much different with every trace.
I just got a "double trace" for the first time, maybe it'll help:
[ 5887.980026] INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 5887.980028] INFO: rcu_sched detected stalls on CPUs/tasks:
[ 5887.980029]
[ 5887.980030]
[
On Tue, Oct 14, 2014 at 10:35:10PM -0400, Sasha Levin
> > >>>>>>> > >>> > > wrote:
> > >>>>>>>>> > >>>> > >> On 10/13/2014 01:35 PM, Dave Jones wrote:
> > >>&g
>>>>> > >>>> > >> On 10/13/2014 01:35 PM, Dave Jones wrote:
> >>>>>>>>>>> > >>>>> > >>> oday in "rcu stall while fuzzing" news:
> >>>>>>>>>>> > &
On Mon, 13 Oct 2014 13:35:04 -0400
Dave Jones wrote:
> Today in "rcu stall while fuzzing" news:
My bug report seems to be related with this topic:
Regression: kernel 3.17 halts sometimes (with Call trace)
https://bugzilla.kernel.org/show_bug.cgi?id=85941
Could somone take a lo
, 2014 at 10:35:10PM -0400, Sasha Levin wrote:
> >>>> > >> On 10/13/2014 01:35 PM, Dave Jones wrote:
> >>>>> > >>> oday in "rcu stall while fuzzing" news:
> >>>>> > >>>
> >>>>> > >>&
gt;> On 10/13/2014 01:35 PM, Dave Jones wrote:
>>>>> > >>> oday in "rcu stall while fuzzing" news:
>>>>> > >>>
>>>>> > >>> INFO: rcu_preempt detected stalls on CPUs/tasks:
>>>>> > >>>
On Thu, Oct 23, 2014 at 11:13:04PM +0200, Oleg Nesterov wrote:
> On 10/23, Paul E. McKenney wrote:
> >
> > Your code, your rules. ;-)
>
> Heh, no. I do not trust my (perverted) taste, I never-never
> argue with cosmetic issues ;)
>
> Cough... and at the same time I have a small nit.
;-) ;-) ;-)
On 10/23, Paul E. McKenney wrote:
>
> Your code, your rules. ;-)
Heh, no. I do not trust my (perverted) taste, I never-never
argue with cosmetic issues ;)
Cough... and at the same time I have a small nit.
> But given this structure, why not use a for() loop replace the
> "goto retry" with an in
On Thu, Oct 23, 2014 at 04:28:16PM -0400, Dave Jones wrote:
> On Thu, Oct 23, 2014 at 12:52:21PM -0700, Paul E. McKenney wrote:
> > On Thu, Oct 23, 2014 at 03:37:59PM -0400, Dave Jones wrote:
> > > On Thu, Oct 23, 2014 at 12:28:07PM -0700, Paul E. McKenney wrote:
> > >
> > > > > > This one w
On Thu, Oct 23, 2014 at 12:52:21PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 23, 2014 at 03:37:59PM -0400, Dave Jones wrote:
> > On Thu, Oct 23, 2014 at 12:28:07PM -0700, Paul E. McKenney wrote:
> >
> > > > > This one will require more looking. But did you do something like
> > > > >
On Thu, Oct 23, 2014 at 09:53:37PM +0200, Oleg Nesterov wrote:
> On 10/23, Paul E. McKenney wrote:
> >
> > OK, so making each pass through the loop a separate RCU read-side critical
> > section might be considered to be suppressing notification of an error
> > condition?
>
> I agree, this change p
uot; news:
> >>>
> >>> INFO: rcu_preempt detected stalls on CPUs/tasks:
> >>> Tasks blocked on level-0 rcu_node (CPUs 0-3): P766 P646
> >>> Tasks blocked on level-0 rcu_node (CPUs 0-3): P766 P646
> >>> (detected by 0, t=6502 jiffie
On 10/23, Paul E. McKenney wrote:
>
> OK, so making each pass through the loop a separate RCU read-side critical
> section might be considered to be suppressing notification of an error
> condition?
I agree, this change probably makes sense anyway. Personally I'd prefer
the version below (somehow
On Thu, Oct 23, 2014 at 03:37:59PM -0400, Dave Jones wrote:
> On Thu, Oct 23, 2014 at 12:28:07PM -0700, Paul E. McKenney wrote:
>
> > > > This one will require more looking. But did you do something like
> > > > create a pair of mutually recursive symlinks or something? ;-)
> > >
> > > I'
On Thu, Oct 23, 2014 at 09:13:19PM +0200, Oleg Nesterov wrote:
> On 10/23, Paul E. McKenney wrote:
> >
> > On Mon, Oct 13, 2014 at 01:35:04PM -0400, Dave Jones wrote:
> > > Today in "rcu stall while fuzzing" news:
> > >
> > > INFO: rcu_preempt
On Thu, Oct 23, 2014 at 12:28:07PM -0700, Paul E. McKenney wrote:
> > > This one will require more looking. But did you do something like
> > > create a pair of mutually recursive symlinks or something? ;-)
> >
> > I'm not 100% sure, but this may have been on a box that I was running
>
On Thu, Oct 23, 2014 at 02:40:18PM -0400, Dave Jones wrote:
> On Thu, Oct 23, 2014 at 11:32:32AM -0700, Paul E. McKenney wrote:
>
> > > trinity-c225R running task13448 646 32295 0x
> > > 880161ccfb28 0002 880161ccfe10 88000bf85e00
> > > 001d
On 10/23, Paul E. McKenney wrote:
>
> On Mon, Oct 13, 2014 at 01:35:04PM -0400, Dave Jones wrote:
> > Today in "rcu stall while fuzzing" news:
> >
> > INFO: rcu_preempt detected stalls on CPUs/tasks:
> > Tasks blocked on level-0 rcu_node (CPUs 0-3): P7
On 10/23/2014 02:39 PM, Paul E. McKenney wrote:
> On Tue, Oct 14, 2014 at 10:35:10PM -0400, Sasha Levin wrote:
>> On 10/13/2014 01:35 PM, Dave Jones wrote:
>>> oday in "rcu stall while fuzzing" news:
>>>
>>> INFO: rcu_preempt detected stalls on CPUs/ta
On Tue, Oct 14, 2014 at 10:35:10PM -0400, Sasha Levin wrote:
> On 10/13/2014 01:35 PM, Dave Jones wrote:
> > oday in "rcu stall while fuzzing" news:
> >
> > INFO: rcu_preempt detected stalls on CPUs/tasks:
> > Tasks blocked on level-0 rcu_node (CPUs 0-3
On Thu, Oct 23, 2014 at 11:32:32AM -0700, Paul E. McKenney wrote:
> > trinity-c225R running task13448 646 32295 0x
> > 880161ccfb28 0002 880161ccfe10 88000bf85e00
> > 001d4100 0003 880161ccffd8 001d4100
> > 880
On Mon, Oct 13, 2014 at 01:35:04PM -0400, Dave Jones wrote:
> Today in "rcu stall while fuzzing" news:
>
> INFO: rcu_preempt detected stalls on CPUs/tasks:
> Tasks blocked on level-0 rcu_node (CPUs 0-3): P766 P646
> Tasks blocked on level-0 rcu_n
On 10/13/2014 01:35 PM, Dave Jones wrote:
> oday in "rcu stall while fuzzing" news:
>
> INFO: rcu_preempt detected stalls on CPUs/tasks:
> Tasks blocked on level-0 rcu_node (CPUs 0-3): P766 P646
> Tasks blocked on level-0 rcu_node (CPUs 0-3): P766 P646
>
Today in "rcu stall while fuzzing" news:
INFO: rcu_preempt detected stalls on CPUs/tasks:
Tasks blocked on level-0 rcu_node (CPUs 0-3): P766 P646
Tasks blocked on level-0 rcu_node (CPUs 0-3): P766 P646
(detected by 0, t=6502 jiffies, g=75434, c=75433, q=0)
tr
On 09/30/2012 04:59 AM, Fengguang Wu wrote:
On Sun, Sep 30, 2012 at 01:32:46PM +0200, Avi Kivity wrote:
On 09/30/2012 01:23 PM, Fengguang Wu wrote:
On Sun, Sep 30, 2012 at 01:10:55PM +0200, Avi Kivity wrote:
On 09/28/2012 05:35 AM, Paul E. McKenney wrote:
On Thu, Sep 27, 2012 at 12:40:44PM +0
2-inn-42322-2012-09-27-10-43-56-3.6.0-rc7-bisect2-00078-g593d100-21:[
6.491696] Switching to clocksource tsc
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-47-03-3.6.0-rc7-bisect2-00078-g593d100-21:[
4.745749] Switching to clocksource hpet
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-47-03-3.6.0-rc7-bis
On 09/30/2012 01:23 PM, Fengguang Wu wrote:
> On Sun, Sep 30, 2012 at 01:10:55PM +0200, Avi Kivity wrote:
>> On 09/28/2012 05:35 AM, Paul E. McKenney wrote:
>> > On Thu, Sep 27, 2012 at 12:40:44PM +0800, Fengguang Wu wrote:
>> >> On Wed, Sep 26, 2012 at 09:28:50PM -0700, Paul E. McKenney wrote:
>>
On 09/30/2012 01:18 PM, Fengguang Wu wrote:
> On Sun, Sep 30, 2012 at 01:10:55PM +0200, Avi Kivity wrote:
>> On 09/28/2012 05:35 AM, Paul E. McKenney wrote:
>> > On Thu, Sep 27, 2012 at 12:40:44PM +0800, Fengguang Wu wrote:
>> >> On Wed, Sep 26, 2012 at 09:28:50PM -0700, Paul E. McKenney wrote:
>>
On Sun, Sep 30, 2012 at 01:10:55PM +0200, Avi Kivity wrote:
> On 09/28/2012 05:35 AM, Paul E. McKenney wrote:
> > On Thu, Sep 27, 2012 at 12:40:44PM +0800, Fengguang Wu wrote:
> >> On Wed, Sep 26, 2012 at 09:28:50PM -0700, Paul E. McKenney wrote:
> >> > On Thu, Sep 27, 2012 at 10:54:00AM +0800, Fen
On 09/28/2012 05:35 AM, Paul E. McKenney wrote:
> On Thu, Sep 27, 2012 at 12:40:44PM +0800, Fengguang Wu wrote:
>> On Wed, Sep 26, 2012 at 09:28:50PM -0700, Paul E. McKenney wrote:
>> > On Thu, Sep 27, 2012 at 10:54:00AM +0800, Fengguang Wu wrote:
>> > > On Wed, Sep 26, 2012 at 09:45:43AM -0700, Pa
r packet performance
> > > > > testing. Version: 2.74
> > > > > [ 12.435439] atkbd: probe of serio0 rejects match -19
> > > > > [ 111.700160] INFO: rcu_preempt detected stalls on CPUs/tasks: { 1}
> > > > > (detected by 0, t=10002
stall problem:
> > >
> > > [ 12.035785] pktgen: Packet Generator for packet performance testing.
> > > Version: 2.74
> > > [ 12.435439] atkbd: probe of serio0 rejects match -19
> > > [ 111.700160] INFO: rcu_preempt detected stalls on CPUs/tasks: { 1
-19
> [ 111.700160] INFO: rcu_preempt detected stalls on CPUs/tasks: { 1}
> (detected by 0, t=10002 jiffies)
> [ 111.700171] Pid: 0, comm: swapper/0 Not tainted 3.6.0-rc5-4-gda10491 #1
> [ 111.700178] Call Trace:
> [ 111.700475] [] rcu_check_callbacks+0x544/0x570
> [ 11
On 08/07/2012 06:24 PM, Sasha Levin wrote:
> On 08/07/2012 07:40 AM, John Stultz wrote:
>> On 08/06/2012 11:28 AM, Sasha Levin wrote:
>>> On 08/06/2012 08:20 PM, John Stultz wrote:
On 08/06/2012 10:21 AM, John Stultz wrote:
> On 08/05/2012 09:55 AM, Sasha Levin wrote:
>> On 07/30/2012
On 08/07/2012 07:40 AM, John Stultz wrote:
> On 08/06/2012 11:28 AM, Sasha Levin wrote:
>> On 08/06/2012 08:20 PM, John Stultz wrote:
>>> On 08/06/2012 10:21 AM, John Stultz wrote:
On 08/05/2012 09:55 AM, Sasha Levin wrote:
> On 07/30/2012 03:17 PM, Avi Kivity wrote:
>> Possible causes
On 08/06/2012 11:28 AM, Sasha Levin wrote:
On 08/06/2012 08:20 PM, John Stultz wrote:
On 08/06/2012 10:21 AM, John Stultz wrote:
On 08/05/2012 09:55 AM, Sasha Levin wrote:
On 07/30/2012 03:17 PM, Avi Kivity wrote:
Possible causes:
- the APIC calibration in the guest failed, so it is progra
On 08/07/2012 04:35 AM, Sasha Levin wrote:
> On 08/06/2012 10:31 PM, John Stultz wrote:
>> On 08/06/2012 11:28 AM, Sasha Levin wrote:
>>> On 08/06/2012 08:20 PM, John Stultz wrote:
On 08/06/2012 10:21 AM, John Stultz wrote:
> On 08/05/2012 09:55 AM, Sasha Levin wrote:
>> On 07/30/2012
On 08/06/2012 10:31 PM, John Stultz wrote:
> On 08/06/2012 11:28 AM, Sasha Levin wrote:
>> On 08/06/2012 08:20 PM, John Stultz wrote:
>>> On 08/06/2012 10:21 AM, John Stultz wrote:
On 08/05/2012 09:55 AM, Sasha Levin wrote:
> On 07/30/2012 03:17 PM, Avi Kivity wrote:
>> Possible causes
On 08/06/2012 11:28 AM, Sasha Levin wrote:
On 08/06/2012 08:20 PM, John Stultz wrote:
On 08/06/2012 10:21 AM, John Stultz wrote:
On 08/05/2012 09:55 AM, Sasha Levin wrote:
On 07/30/2012 03:17 PM, Avi Kivity wrote:
Possible causes:
- the APIC calibration in the guest failed, so it is progra
On 08/06/2012 07:21 PM, John Stultz wrote:
> On 08/05/2012 09:55 AM, Sasha Levin wrote:
>> On 07/30/2012 03:17 PM, Avi Kivity wrote:
>>> Possible causes:
>>> - the APIC calibration in the guest failed, so it is programming too
>>> low values into the timer
>>> - it actually needs 1 us wakeups a
On 08/06/2012 08:20 PM, John Stultz wrote:
> On 08/06/2012 10:21 AM, John Stultz wrote:
>> On 08/05/2012 09:55 AM, Sasha Levin wrote:
>>> On 07/30/2012 03:17 PM, Avi Kivity wrote:
Possible causes:
- the APIC calibration in the guest failed, so it is programming too
low values into
On 08/06/2012 10:21 AM, John Stultz wrote:
On 08/05/2012 09:55 AM, Sasha Levin wrote:
On 07/30/2012 03:17 PM, Avi Kivity wrote:
Possible causes:
- the APIC calibration in the guest failed, so it is programming too
low values into the timer
- it actually needs 1 us wakeups and then can't kee
On 08/06/2012 10:21 AM, John Stultz wrote:
On 08/05/2012 09:55 AM, Sasha Levin wrote:
On 07/30/2012 03:17 PM, Avi Kivity wrote:
Possible causes:
- the APIC calibration in the guest failed, so it is programming too
low values into the timer
- it actually needs 1 us wakeups and then can't kee
On 08/05/2012 09:55 AM, Sasha Levin wrote:
On 07/30/2012 03:17 PM, Avi Kivity wrote:
Possible causes:
- the APIC calibration in the guest failed, so it is programming too
low values into the timer
- it actually needs 1 us wakeups and then can't keep up (esp. as kvm
interrupt injection is slo
On 07/30/2012 03:17 PM, Avi Kivity wrote:
> Possible causes:
> - the APIC calibration in the guest failed, so it is programming too
> low values into the timer
> - it actually needs 1 us wakeups and then can't keep up (esp. as kvm
> interrupt injection is slowing it down)
>
> You can try to find
On 07/30/2012 03:43 PM, Sasha Levin wrote:
>
>> Then work backwards to see the last place it is
>> programmed (APIC_TMICT/APIC_TDCR).
>
> This looks like what you're looking for:
>
> kvm_apic: apic_write APIC_TMICT = 0x3e
>>
>> What about APIC_TMICT? Might be configure
On 07/30/2012 11:33 AM, Avi Kivity wrote:
> On 07/30/2012 12:13 PM, Sasha Levin wrote:
>>
>> Yup, looks like it. kvm_stats is something like this:
>>
>> kvm_entry142104033 939393
>> kvm_exit 142104004 939390
>>>
On 07/30/2012 12:13 PM, Sasha Levin wrote:
>
> Yup, looks like it. kvm_stats is something like this:
>
> kvm_entry142104033 939393
> kvm_exit 142104004 939390
> kvm_apic 847
On 07/30/2012 07:36 AM, Avi Kivity wrote:
> On 07/30/2012 12:05 AM, Sasha Levin wrote:
>> On 07/29/2012 02:48 PM, Avi Kivity wrote:
>>> On 07/27/2012 02:27 PM, Sasha Levin wrote:
On 07/26/2012 01:42 PM, Avi Kivity wrote:
> On 07/24/2012 08:10 PM, Sasha Levin wrote:
>> [ 215.026612] NM
On 07/30/2012 12:05 AM, Sasha Levin wrote:
> On 07/29/2012 02:48 PM, Avi Kivity wrote:
> > On 07/27/2012 02:27 PM, Sasha Levin wrote:
> >> On 07/26/2012 01:42 PM, Avi Kivity wrote:
> >>> On 07/24/2012 08:10 PM, Sasha Levin wrote:
> [ 215.026612] NMI backtrace for cpu 1
> [ 215.026612] C
On 07/29/2012 02:48 PM, Avi Kivity wrote:
> On 07/27/2012 02:27 PM, Sasha Levin wrote:
>> On 07/26/2012 01:42 PM, Avi Kivity wrote:
>>> On 07/24/2012 08:10 PM, Sasha Levin wrote:
[ 215.026612] NMI backtrace for cpu 1
[ 215.026612] CPU 1
[ 215.026612] Pid: 2395, comm: pageattr-test
On 07/27/2012 02:27 PM, Sasha Levin wrote:
> On 07/26/2012 01:42 PM, Avi Kivity wrote:
>> On 07/24/2012 08:10 PM, Sasha Levin wrote:
>>> [ 215.026612] NMI backtrace for cpu 1
>>> [ 215.026612] CPU 1
>>> [ 215.026612] Pid: 2395, comm: pageattr-test Tainted: GW
>>> 3.5.0-sasha-01644-g8
On 07/26/2012 01:42 PM, Avi Kivity wrote:
> On 07/24/2012 08:10 PM, Sasha Levin wrote:
>> [ 215.026612] NMI backtrace for cpu 1
>> [ 215.026612] CPU 1
>> [ 215.026612] Pid: 2395, comm: pageattr-test Tainted: GW
>> 3.5.0-sasha-01644-g824681b #267
>> [ 215.026612] RIP: 0010:[] []
>>
On 07/24/2012 08:10 PM, Sasha Levin wrote:
> [ 215.026612] NMI backtrace for cpu 1
> [ 215.026612] CPU 1
> [ 215.026612] Pid: 2395, comm: pageattr-test Tainted: GW
> 3.5.0-sasha-01644-g824681b #267
> [ 215.026612] RIP: 0010:[] []
> native_write_msr_safe+0xa/0x10
> [ 215.026612] R
On 07/26/2012 05:16 AM, Sasha Levin wrote:
> On 07/25/2012 10:36 AM, Michael Wang wrote:
>> On 07/25/2012 01:10 AM, Sasha Levin wrote:
>>> Hi all,
>>>
>>> I was fuzzing with trinity inside a KVM tools guest, on the current 3.6,
>>> and stumbled on the following:
>>
>> Hi, Sasha
>>
>> I'm currently
nks,
Michael Wang
>
> (Note that it also happens on -next).
>
> [ 215.034674] INFO: rcu_preempt detected stalls on CPUs/tasks:
> [ 215.035641]1: (0 ticks this GP) idle=3f5/141/0 drain=0
> . timer=18446744073709551615
> [ 215.035641]
the issue still exist.
Regards,
Michael Wang
>
> (Note that it also happens on -next).
>
> [ 215.034674] INFO: rcu_preempt detected stalls on CPUs/tasks:
> [ 215.035641]1: (0 ticks this GP) idle=3f5/141/0 drain=0
> . timer=18446744073709551615
> [
On 07/24/2012 07:40 PM, Paul E. McKenney wrote:
> The interrupt flag is zero, so interrupts are disabled. So my question
> to you is "Why did do_pageattr_test() or one of the functions it called
> disable interrupts for more than one hundred thousand jiffies?"
>
> I can't see where it is disablin
On Tue, Jul 24, 2012 at 07:10:49PM +0200, Sasha Levin wrote:
> Hi all,
>
> I was fuzzing with trinity inside a KVM tools guest, on the current 3.6, and
> stumbled on the following:
>
> (Note that it also happens on -next).
>
> [ 215.034674] INFO: rcu_preempt detec
Hi all,
I was fuzzing with trinity inside a KVM tools guest, on the current 3.6, and
stumbled on the following:
(Note that it also happens on -next).
[ 215.034674] INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 215.035641] 1: (0 ticks this GP) idle=3f5/141/0 drain=0 .
timer
67 matches
Mail list logo
