I posted the following Call Trace at Kernel bugzilla, but
nobody replied so I'm posting here. This is not reproducible. It happened
when watching a Youtube video.
https://bugzilla.kernel.org/show_bug.cgi?id=99441
My system stalled (no keyboard, no mouse) and I got this:
Jun 5
I posted the following Call Trace at Kernel bugzilla, but
nobody replied so I'm posting here. This is not reproducible. It happened
when watching a Youtube video.
https://bugzilla.kernel.org/show_bug.cgi?id=99441
My system stalled (no keyboard, no mouse) and I got this:
Jun 5
On Thu, 4 Dec 2014 09:47:53 -0800
Linus Torvalds wrote:
> Ok. Can you make sure to really beat on that kernel, just to make sure
> there's nothing else hiding?
Yes, I'll keep torturing this kernel. If I find something, I'll
report here, but so far, no problem at all.
--
Linux
On Thu, 4 Dec 2014 17:52:08 +0100
Frederic Weisbecker wrote:
> And this bug has been fixed upstream with:
>
> _ nohz: nohz full depends on irq work self IPI support
> _ x86: Tell irq work about self IPI support
> _ irq_work: Force raised irq work to run on irq work interrupt
>
On Wed, 3 Dec 2014 07:22:44 -0800
Linus Torvalds wrote:
> Anyway, Dâniel, if you restart the bisection today, start it one
> kernel earlier: re-test the last 'bad' kernel too. So start with
> reconfirming that the c9b88e958182 kernel was bad (that *might* be as
> easy as just checking your old
On Wed, 3 Dec 2014 07:22:44 -0800
Linus Torvalds torva...@linux-foundation.org wrote:
Anyway, Dâniel, if you restart the bisection today, start it one
kernel earlier: re-test the last 'bad' kernel too. So start with
reconfirming that the c9b88e958182 kernel was bad (that *might* be as
easy as
On Thu, 4 Dec 2014 17:52:08 +0100
Frederic Weisbecker fweis...@gmail.com wrote:
And this bug has been fixed upstream with:
_ nohz: nohz full depends on irq work self IPI support
_ x86: Tell irq work about self IPI support
_ irq_work: Force raised irq work to run on irq work
On Thu, 4 Dec 2014 09:47:53 -0800
Linus Torvalds torva...@linux-foundation.org wrote:
Ok. Can you make sure to really beat on that kernel, just to make sure
there's nothing else hiding?
Yes, I'll keep torturing this kernel. If I find something, I'll
report here, but so far, no problem
On Tue, 2 Dec 2014 20:14:52 -0800
Linus Torvalds wrote:
> What is *really* suspicious is a series of "git bisect good" with no
> "bad"s anywhere. Which is exactly what we see at the end of the
> bisect.
>
> So might I ask you to try starting from this point again (this is why
> the bisect log
On Tue, 2 Dec 2014 14:10:33 -0800
Linus Torvalds wrote:
> There's 13k+ commits in between 3.16 and 3.17, so a full bisect should
> be around 15 test-points. But judging by the timing of your emails,
> you can generally reproduce this relatively quickly..
Ok Linus and Paul, it took me
On Tue, 2 Dec 2014 14:10:31 -0800
"Paul E. McKenney" wrote:
> Thank you!!!
;)
> Was this as difficult to trigger as the version with the Kconfig hack
> that used CONFIG_PREEMPT=y and CONFIG_TREE_PREEMPT_RCU=n?
Yes. I had to try many times until I got the call trace.
On Tue, 2 Dec 2014 14:10:33 -0800
Linus Torvalds wrote:
> So it appears that you can recreate this much more quickly than DaveJ
> can recreate his issue.
>
> The two issues may be entirely unrelated, but the it is certainly
> quite possible that they have some relation to each other, and the
>
On Tue, 2 Dec 2014 12:56:36 -0800
"Paul E. McKenney" wrote:
> And I left out a step. Let's make sure that my preempt_disabled() hack
> to CONFIG_TREE_PREEMPT_RCU=y has the same effect as the Kconfig hack
> that allowed CONFIG_PREEMPT=y and CONFIG_TREE_PREEMPT_RCU=n. Could you
> please try out
On Tue, 2 Dec 2014 11:11:43 -0800
"Paul E. McKenney" wrote:
> OK. I need to know exactly what version of the Linux kernel you are
> using. 3.18-rc7? (I am not too worried about exactly which version
> you are using as long as I know which version it is.)
Ok, I stopped bisecting and
On Tue, 2 Dec 2014 10:42:02 -0800
"Paul E. McKenney" wrote:
> I was actually suggesting something a bit different. Instead of bisecting
> by release, bisect by code. The procedure is as follows:
>
> 1.I figure out some reliable way of making RCU allow preemption to
> be disabled for
On Tue, 2 Dec 2014 10:09:47 -0800
"Paul E. McKenney" wrote:
> To Linus's point, I guess I could look at the RCU CPU stall warning. ;-)
>
> Summary: Not seeing something that would loop for 21 seconds.
> Dâniel, if you let this run, does it hit a second RCU CPU stall
> warning, or does it just
On Tue, 2 Dec 2014 09:08:53 -0800
Linus Torvalds wrote:
> So just to verify:
>
> Without CONFIG_PREEMPT, things work well for you?
Yes.
> But with CONFIG_PREEMPT, you are able to create the rcu_sched stalls
> both with and without CONFIG_TREE_PREEMPT_RCU?
>
> Correct?
Yes,
On Tue, 2 Dec 2014 09:04:07 -0800
"Paul E. McKenney" wrote:
> Is it harder to reproduce with CONFIG_PREEMPT=y and CONFIG_TREE_PREEMPT_RCU=n?
Yes, it's much harder! :)
> If it is a -lot- harder to reproduce, it might be worth bisecting among
> the RCU read-side critical sections. If
On Tue, 2 Dec 2014 16:40:37 +0800
Lai Jiangshan wrote:
> It is needed at lest for testing.
>
> CONFIG_TREE_PREEMPT_RCU=y with CONFIG_PREEMPT=n is needed for testing too.
>
> Please enable them (or enable them under CONFIG_RCU_TRACE=y)
Lai, sorry but I didn't understand. Do you mean
On Mon, 1 Dec 2014 15:08:13 -0800
"Paul E. McKenney" wrote:
> Well, this turned out to be way simpler than I expected. Passes
> light rcutorture testing. Sometimes you get lucky...
Linus, Paul and others, I finally got a call trace with
only CONFIG_TREE_PREEMPT_RCU *disabled* using
On Mon, 1 Dec 2014 15:08:13 -0800
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
Well, this turned out to be way simpler than I expected. Passes
light rcutorture testing. Sometimes you get lucky...
Linus, Paul and others, I finally got a call trace with
only
On Tue, 2 Dec 2014 16:40:37 +0800
Lai Jiangshan la...@cn.fujitsu.com wrote:
It is needed at lest for testing.
CONFIG_TREE_PREEMPT_RCU=y with CONFIG_PREEMPT=n is needed for testing too.
Please enable them (or enable them under CONFIG_RCU_TRACE=y)
Lai, sorry but I didn't understand.
On Tue, 2 Dec 2014 09:04:07 -0800
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
Is it harder to reproduce with CONFIG_PREEMPT=y and CONFIG_TREE_PREEMPT_RCU=n?
Yes, it's much harder! :)
If it is a -lot- harder to reproduce, it might be worth bisecting among
the RCU read-side
On Tue, 2 Dec 2014 09:08:53 -0800
Linus Torvalds torva...@linux-foundation.org wrote:
So just to verify:
Without CONFIG_PREEMPT, things work well for you?
Yes.
But with CONFIG_PREEMPT, you are able to create the rcu_sched stalls
both with and without CONFIG_TREE_PREEMPT_RCU?
On Tue, 2 Dec 2014 10:09:47 -0800
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
To Linus's point, I guess I could look at the RCU CPU stall warning. ;-)
Summary: Not seeing something that would loop for 21 seconds.
Dâniel, if you let this run, does it hit a second RCU CPU stall
On Tue, 2 Dec 2014 10:42:02 -0800
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
I was actually suggesting something a bit different. Instead of bisecting
by release, bisect by code. The procedure is as follows:
1.I figure out some reliable way of making RCU allow preemption to
On Tue, 2 Dec 2014 11:11:43 -0800
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
OK. I need to know exactly what version of the Linux kernel you are
using. 3.18-rc7? (I am not too worried about exactly which version
you are using as long as I know which version it is.)
Ok, I
On Tue, 2 Dec 2014 12:56:36 -0800
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
And I left out a step. Let's make sure that my preempt_disabled() hack
to CONFIG_TREE_PREEMPT_RCU=y has the same effect as the Kconfig hack
that allowed CONFIG_PREEMPT=y and CONFIG_TREE_PREEMPT_RCU=n. Could
On Tue, 2 Dec 2014 14:10:33 -0800
Linus Torvalds torva...@linux-foundation.org wrote:
So it appears that you can recreate this much more quickly than DaveJ
can recreate his issue.
The two issues may be entirely unrelated, but the it is certainly
quite possible that they have some relation
On Tue, 2 Dec 2014 14:10:31 -0800
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
Thank you!!!
;)
Was this as difficult to trigger as the version with the Kconfig hack
that used CONFIG_PREEMPT=y and CONFIG_TREE_PREEMPT_RCU=n?
Yes. I had to try many times until I got the
On Tue, 2 Dec 2014 14:10:33 -0800
Linus Torvalds torva...@linux-foundation.org wrote:
There's 13k+ commits in between 3.16 and 3.17, so a full bisect should
be around 15 test-points. But judging by the timing of your emails,
you can generally reproduce this relatively quickly..
Ok
On Tue, 2 Dec 2014 20:14:52 -0800
Linus Torvalds torva...@linux-foundation.org wrote:
What is *really* suspicious is a series of git bisect good with no
bads anywhere. Which is exactly what we see at the end of the
bisect.
So might I ask you to try starting from this point again (this is
On Mon, 1 Dec 2014 11:14:31 -0800
"Paul E. McKenney" wrote:
> If it would help to have !CONFIG_TREE_PREEMPT_RCU with CONFIG_PREEMPT=y,
> please let me know and I will create a patch that forces this.
> (Not mainline material, but if it helps with debug...)
Hi Paul. Please, I'd like the
On Mon, 1 Dec 2014 11:14:31 -0800
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
If it would help to have !CONFIG_TREE_PREEMPT_RCU with CONFIG_PREEMPT=y,
please let me know and I will create a patch that forces this.
(Not mainline material, but if it helps with debug...)
Hi Paul.
On Sun, 30 Nov 2014 16:21:19 -0800
Linus Torvalds wrote:
> Maybe you'll have to turn off RCU_CPU_STALL_VERBOSE first.
>
> Although I think you should be able to just edit the .config file,
> delete the like that says
>
> CONFIG_TREE_PREEMPT_RCU=y
>
> and then just do a "make oldconfig",
On Sun, 30 Nov 2014 12:45:31 -0800
Linus Torvalds wrote:
> Yours looks very different. Dave (and Sasha Levin) have reported
> rcy_preempt stalls too, but it's not clear it's the same issue.
>
> In case yours is repeatable (you seem to say it is), can you try it
> without TREE_PREEMPT_RCU?
On Sun, 30 Nov 2014 12:45:31 -0800
Linus Torvalds torva...@linux-foundation.org wrote:
Yours looks very different. Dave (and Sasha Levin) have reported
rcy_preempt stalls too, but it's not clear it's the same issue.
In case yours is repeatable (you seem to say it is), can you try it
without
On Sun, 30 Nov 2014 16:21:19 -0800
Linus Torvalds torva...@linux-foundation.org wrote:
Maybe you'll have to turn off RCU_CPU_STALL_VERBOSE first.
Although I think you should be able to just edit the .config file,
delete the like that says
CONFIG_TREE_PREEMPT_RCU=y
and then just do
On Thu, 27 Nov 2014 17:56:37 -0500
Dave Jones wrote:
> Agreed.
>
> Currently leaving 3.16 running. 21hrs so far.
Dave, I think I reported this bug in this bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=85941
Just posting in case the call trace helps...
In my
On Thu, 27 Nov 2014 17:56:37 -0500
Dave Jones da...@redhat.com wrote:
Agreed.
Currently leaving 3.16 running. 21hrs so far.
Dave, I think I reported this bug in this bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=85941
Just posting in case the call trace helps...
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
On Mon, 13 Oct 2014 13:35:04 -0400
Dave Jones da...@redhat.com 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
On Mon, 15 Jul 2013 17:01:35 +0200
Frederic Weisbecker wrote:
> On Mon, Jul 15, 2013 at 11:51:18AM -0300, Dâniel Fraga wrote:
> > The problem is that when we use the new Full dynticks option
> > form kernel 3.10.0, the load will go high, always above 1. Bug?
>
> You me
On Mon, 15 Jul 2013 16:25:59 +0200
Frederic Weisbecker wrote:
> Hi,
>
> Sorry I'm missing the description of the issue. Could you please
> repaste it?
>
> Thanks!
The problem is that when we use the new Full dynticks option
form kernel 3.10.0, the load will go high, always above 1.
On Fri, 12 Jul 2013 08:52:27 +0200
Heinz Diehl wrote:
> This describes exactly what I have encountered, and "tickless idle"
> fixed it for me, too. So I'll second that.
Thanks for the confirmation. I hope Ingo Molnar fixes it.
--
Linux 3.10.0: Unicycling Gorilla
On Fri, 12 Jul 2013 08:52:27 +0200
Heinz Diehl h...@fancy-poultry.org wrote:
This describes exactly what I have encountered, and tickless idle
fixed it for me, too. So I'll second that.
Thanks for the confirmation. I hope Ingo Molnar fixes it.
--
Linux 3.10.0: Unicycling Gorilla
On Mon, 15 Jul 2013 16:25:59 +0200
Frederic Weisbecker fweis...@gmail.com wrote:
Hi,
Sorry I'm missing the description of the issue. Could you please
repaste it?
Thanks!
The problem is that when we use the new Full dynticks option
form kernel 3.10.0, the load will go high, always
On Mon, 15 Jul 2013 17:01:35 +0200
Frederic Weisbecker fweis...@gmail.com wrote:
On Mon, Jul 15, 2013 at 11:51:18AM -0300, Dâniel Fraga wrote:
The problem is that when we use the new Full dynticks option
form kernel 3.10.0, the load will go high, always above 1. Bug?
You mean
I upgraded to kernel 3.10.0 and decided to try the new "Full
dynticks system (tickless)" option, but now the system load is always
at 1 or above.
Using the previous "Idle dynticks system (tickless idle)" solves
the problem, so it seems the new Full dynticks code is causing this.
I upgraded to kernel 3.10.0 and decided to try the new Full
dynticks system (tickless) option, but now the system load is always
at 1 or above.
Using the previous Idle dynticks system (tickless idle) solves
the problem, so it seems the new Full dynticks code is causing this.
I read today on kerneltrap the following:
http://kerneltrap.org/Linux/Avoiding_Blobs
and I notice that people have a misconception about how the
user space tuner proposed by Markus Rechberger works.
I've been using Markus' code for a long time and he's the only
one that
I read today on kerneltrap the following:
http://kerneltrap.org/Linux/Avoiding_Blobs
and I notice that people have a misconception about how the
user space tuner proposed by Markus Rechberger works.
I've been using Markus' code for a long time and he's the only
one that
Well, I'd like to see Linus' opinion about this, because while
programmers keep discussing this, users are waiting forever... so if
Markus has a concrete and better solution, why don't use it?
And as far as I know, Markus is the programmer who is most
interested in this code. I
Well, I'd like to see Linus' opinion about this, because while
programmers keep discussing this, users are waiting forever... so if
Markus has a concrete and better solution, why don't use it?
And as far as I know, Markus is the programmer who is most
interested in this code. I
54 matches
Mail list logo
