On Wed 2008-01-23 13:36:12, Steven Rostedt wrote:
>
>
> On Wed, 23 Jan 2008, Pavel Machek wrote:
> >
> > Could try_to_wakeup use trylock, and only avoid wakeup if lock is
> > already held?
> > Pavel
>
> I could imagine a lot of missed wakeups
On Wed 2008-01-23 13:36:12, Steven Rostedt wrote:
On Wed, 23 Jan 2008, Pavel Machek wrote:
Could try_to_wakeup use trylock, and only avoid wakeup if lock is
already held?
Pavel
I could imagine a lot of missed wakeups caused by
On Wed, 23 Jan 2008, Pavel Machek wrote:
>
> Could try_to_wakeup use trylock, and only avoid wakeup if lock is
> already held?
> Pavel
I could imagine a lot of missed wakeups caused by that.
-- Steve
--
To unsubscribe from this list: send
Hi!
> I thought that one could place a printk anywhere without worrying.
> But it seems that it is not wise to place a printk where the runqueue
> lock is held.
>
> I just spent two hours debugging why some of my code was locking up,
> to find that the lockup was caused by some debugging
Hi!
I thought that one could place a printk anywhere without worrying.
But it seems that it is not wise to place a printk where the runqueue
lock is held.
I just spent two hours debugging why some of my code was locking up,
to find that the lockup was caused by some debugging printk's that
On Wed, 23 Jan 2008, Pavel Machek wrote:
Could try_to_wakeup use trylock, and only avoid wakeup if lock is
already held?
Pavel
I could imagine a lot of missed wakeups caused by that.
-- Steve
--
To unsubscribe from this list: send the
On Fri, 18 Jan 2008, Jan Kiszka wrote:
> Steven Rostedt wrote:
> ...
> > @@ -978,7 +980,13 @@ void release_console_sem(void)
> > console_locked = 0;
> > up(_sem);
>
> Hmm, just looking at this fragment: Doesn't up() include the risk of
> running onto the runqueue lock as well?
In
On Fri, 18 Jan 2008, Jan Kiszka wrote:
> Steven Rostedt wrote:
>
> > @@ -978,7 +980,13 @@ void release_console_sem(void)
> > console_locked = 0;
> > up(_sem);
>
> Hmm, just looking at this fragment: Doesn't up() include the risk of
> running onto the runqueue lock as well?
Very
Steven Rostedt wrote:
...
> @@ -978,7 +980,13 @@ void release_console_sem(void)
> console_locked = 0;
> up(_sem);
Hmm, just looking at this fragment: Doesn't up() include the risk of
running onto the runqueue lock as well?
> spin_unlock_irqrestore(_lock, flags);
> - if
On Fri, 18 Jan 2008, Jiri Kosina wrote:
>
> If this patch is going to be merged, you should perhaps adjust the comment
> introduced by the above mentioned commit, so that it reflects the new
> behavior.
Thanks for pointing this out. Updated patch below:
-- Steve
=
I thought that one
On Thu, 17 Jan 2008, Steven Rostedt wrote:
> Thinking that it was locking up on my code I went looking down the wrong
> path. I finally found (after examining an NMI dump) that the lockup
> happened because printk was trying to wakeup the klogd daemon, which
> caused a deadlock when the
On Fri, 18 Jan 2008, Jiri Kosina wrote:
If this patch is going to be merged, you should perhaps adjust the comment
introduced by the above mentioned commit, so that it reflects the new
behavior.
Thanks for pointing this out. Updated patch below:
-- Steve
=
I thought that one could
On Thu, 17 Jan 2008, Steven Rostedt wrote:
Thinking that it was locking up on my code I went looking down the wrong
path. I finally found (after examining an NMI dump) that the lockup
happened because printk was trying to wakeup the klogd daemon, which
caused a deadlock when the
On Fri, 18 Jan 2008, Jan Kiszka wrote:
Steven Rostedt wrote:
@@ -978,7 +980,13 @@ void release_console_sem(void)
console_locked = 0;
up(console_sem);
Hmm, just looking at this fragment: Doesn't up() include the risk of
running onto the runqueue lock as well?
Very little
Steven Rostedt wrote:
...
@@ -978,7 +980,13 @@ void release_console_sem(void)
console_locked = 0;
up(console_sem);
Hmm, just looking at this fragment: Doesn't up() include the risk of
running onto the runqueue lock as well?
spin_unlock_irqrestore(logbuf_lock, flags);
-
On Fri, 18 Jan 2008, Jan Kiszka wrote:
Steven Rostedt wrote:
...
@@ -978,7 +980,13 @@ void release_console_sem(void)
console_locked = 0;
up(console_sem);
Hmm, just looking at this fragment: Doesn't up() include the risk of
running onto the runqueue lock as well?
In theory
On Thu, 17 Jan 2008, Andrew Morton wrote:
>
> A "well-known" problem which few know about ;)
And now I feel less ignorant.
>
> Anyway you should be developing with all debug options enabled and that
> includes NMI watchdog so there.
hehe, I did have NMI on the whole time. It's that I also had
On Thu, 17 Jan 2008, Linus Torvalds wrote:
> IOW, I think this should be
>
> if (raw_irqs_disabled_flags(flags) && wake_klogd)
> wake_up_klogd();
>
> Of course, not all architectures seem to suport that thing (it's currently
> only used by the CONFIG_TRACE_IRQFLAGS config
On Thu, 17 Jan 2008, Steven Rostedt wrote:
>
> Calling printk with interrupts disabled should only be done for
> emergencies and debugging anyway.
Agreed, I think this is sane.
> And with this patch, my code ran fine ;-)
Patch looks fine, but I'm saddened:
> + /*
> + * If we try to
On Thu, 17 Jan 2008 20:04:27 -0500 (EST)
Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> I thought that one could place a printk anywhere without worrying.
> But it seems that it is not wise to place a printk where the runqueue
> lock is held.
>
> I just spent two hours debugging why some of my
I thought that one could place a printk anywhere without worrying.
But it seems that it is not wise to place a printk where the runqueue
lock is held.
I just spent two hours debugging why some of my code was locking up,
to find that the lockup was caused by some debugging printk's that
I had in
I thought that one could place a printk anywhere without worrying.
But it seems that it is not wise to place a printk where the runqueue
lock is held.
I just spent two hours debugging why some of my code was locking up,
to find that the lockup was caused by some debugging printk's that
I had in
On Thu, 17 Jan 2008 20:04:27 -0500 (EST)
Steven Rostedt [EMAIL PROTECTED] wrote:
I thought that one could place a printk anywhere without worrying.
But it seems that it is not wise to place a printk where the runqueue
lock is held.
I just spent two hours debugging why some of my code was
On Thu, 17 Jan 2008, Steven Rostedt wrote:
Calling printk with interrupts disabled should only be done for
emergencies and debugging anyway.
Agreed, I think this is sane.
And with this patch, my code ran fine ;-)
Patch looks fine, but I'm saddened:
+ /*
+ * If we try to wake
On Thu, 17 Jan 2008, Linus Torvalds wrote:
IOW, I think this should be
if (raw_irqs_disabled_flags(flags) wake_klogd)
wake_up_klogd();
Of course, not all architectures seem to suport that thing (it's currently
only used by the CONFIG_TRACE_IRQFLAGS config option).
On Thu, 17 Jan 2008, Andrew Morton wrote:
A well-known problem which few know about ;)
And now I feel less ignorant.
Anyway you should be developing with all debug options enabled and that
includes NMI watchdog so there.
hehe, I did have NMI on the whole time. It's that I also had
26 matches
Mail list logo
