[lkml]   [2009]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [tip:core/debug] debug lockups: Improve lockup detection

* Andrew Morton <> wrote:

> On Sun, 2 Aug 2009 21:26:57 +0200 Ingo Molnar <> wrote:
> > > I think this just broke all non-x86 non-sparc SMP architectures.
> >
> > Yeah - it 'broke' them in the sense of them not having a working
> > trigger_all_cpu_backtrace() implementation to begin with.
> c'mon. It broke them in the sense that sysrq-l went from "works"
> to "doesn't work".

You are right (i broke it with my patch) but the thing is, sysrq-l
almost useless currently: it uses schedule_work() which assumes a
mostly working system with full irqs and scheduling working fine.
Now, i dont need sysrq-l on mostly working systems.

So the 'breakage' is of something that was largely useless: and now
you put the onus of implementing it for _all_ architectures (which i
dont use) on me?

If that's the requirement then i'll have to keep this as a local
debug hack and not do an upstream solution - i dont have the
resources to do it for all ~10 SMP architectures.

sysrq-l has been messed up really and now that messup limits the
adoption of the much more useful solution? I didnt make this thing
up, i tried to use it on a locked up system and wondered why it
emits nothing and why it uses a separate facility instead of an
existing trigger-backtraces facility (which the spinlock-debug code

> It would take months for the relevant arch maintainers to even
> find out about this, after which they're left with dud kernels out
> in the field.
> It's better to break the build or to emit warnings than to
> silently and secretly break their stuff.

But that warning will bounce the ball back to me, wont it? My patch
will be blamed for 'breaking' those architectures, right?


 \ /
  Last update: 2009-08-02 22:45    [W:0.049 / U:26.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site