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 0
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 3.18.0-rc
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 ke
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 is
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 alm
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.
I'
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
> t
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 t
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 we
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, co
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 mak
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 bot
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 Pau
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 p
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", an
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 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 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
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. Bug
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
http://www.youtube.com/
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 m
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 did
27 matches
Mail list logo
