On Wed 2008-01-23 12:25:09, Mathieu Desnoyers wrote:
> * Daniel Walker ([EMAIL PROTECTED]) wrote:
> >
> > On Wed, 2008-01-23 at 11:02 -0500, Steven Rostedt wrote:
> >
> > > + if (!irqs_disabled() && wake_klogd)
> > > wake_up_klogd();
> >
> > This causes a regression .. When printk is c
On Wed 2008-01-23 12:27:12, Steven Rostedt wrote:
>
> On Wed, 23 Jan 2008, Daniel Walker wrote:
>
> >
> > On Wed, 2008-01-23 at 11:02 -0500, Steven Rostedt wrote:
> >
> > > + if (!irqs_disabled() && wake_klogd)
> > > wake_up_klogd();
> >
> > This causes a regression .. When printk is ca
On Wed, 2008-01-23 at 10:50 -0800, Daniel Walker wrote:
> On Wed, 2008-01-23 at 13:43 -0500, Steven Rostedt wrote:
> > On Wed, 23 Jan 2008, Daniel Walker wrote:
> >
> > >
> > > On Wed, 2008-01-23 at 13:18 -0500, Steven Rostedt wrote:
> > >
> > > > The wakeup hook in schedule is when we find out t
On Wed, 2008-01-23 at 13:43 -0500, Steven Rostedt wrote:
> On Wed, 23 Jan 2008, Daniel Walker wrote:
>
> >
> > On Wed, 2008-01-23 at 13:18 -0500, Steven Rostedt wrote:
> >
> > > The wakeup hook in schedule is when we find out that we hit our max. I
> > > could postpone that somehow, but that woul
On Wed, 23 Jan 2008, Daniel Walker wrote:
>
> On Wed, 2008-01-23 at 13:18 -0500, Steven Rostedt wrote:
>
> > The wakeup hook in schedule is when we find out that we hit our max. I
> > could postpone that somehow, but that would require more glue code than I
> > would like to add.
>
> Which hook s
On Wed, 2008-01-23 at 13:18 -0500, Steven Rostedt wrote:
> The wakeup hook in schedule is when we find out that we hit our max. I
> could postpone that somehow, but that would require more glue code than I
> would like to add.
Which hook specifically ?
> As for -rt, we've disabled printk for co
On Wed, 23 Jan 2008, Daniel Walker wrote:
>
> > if (wake_klogd && !runqueue_is_locked())
> > wake_up_klogd();
> >
> > This probably is the cleanest solution since it simply prevents the
> > deadlock from occurring.
>
> Do you really need to call it with the runqueue lock held .. T
Mathieu Desnoyers wrote:
> Can we change this for :
> if (!(irqs_disabled() && !oops_in_progress) && wake_klogd)
> wake_up_klogd();
!oops_in_progress is already inside wake_up_klogd().
Also, I think you'd want that first '!' inside the parens.
I've been working on a system to handle deferred d
> if (wake_klogd && !runqueue_is_locked())
> wake_up_klogd();
>
> This probably is the cleanest solution since it simply prevents the
> deadlock from occurring.
Do you really need to call it with the runqueue lock held .. There are
other issue with the calls at that level.. F
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
>
> On Wed, 23 Jan 2008, Daniel Walker wrote:
>
> >
> > On Wed, 2008-01-23 at 11:02 -0500, Steven Rostedt wrote:
> >
> > > + if (!irqs_disabled() && wake_klogd)
> > > wake_up_klogd();
> >
> > This causes a regression .. When printk is called d
* Daniel Walker ([EMAIL PROTECTED]) wrote:
>
> On Wed, 2008-01-23 at 11:02 -0500, Steven Rostedt wrote:
>
> > + if (!irqs_disabled() && wake_klogd)
> > wake_up_klogd();
>
> This causes a regression .. When printk is called during an OOPS in
> kernels without this change then the OO
On Wed, 23 Jan 2008, Daniel Walker wrote:
>
> On Wed, 2008-01-23 at 11:02 -0500, Steven Rostedt wrote:
>
> > + if (!irqs_disabled() && wake_klogd)
> > wake_up_klogd();
>
> This causes a regression .. When printk is called during an OOPS in
> kernels without this change then the OOPS
On Wed, 2008-01-23 at 11:02 -0500, Steven Rostedt wrote:
> + if (!irqs_disabled() && wake_klogd)
> wake_up_klogd();
This causes a regression .. When printk is called during an OOPS in
kernels without this change then the OOPS will get logged, since the
logging process (klogd) i
13 matches
Mail list logo
