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 c
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 t
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
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?
I
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?
V
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, 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 cou
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 try_to_
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 m
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 opti
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 w
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 co
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 t
13 matches
Mail list logo
