Andrew,
You want to pull this patch?
Thanks,
-- Steve
On Wed, 24 Sep 2014 17:20:19 +0200
Markus Trippelsdorf wrote:
> commit 458df9fd hardcodes printk_deferred() to KERN_WARNING and inserts
> the string "[sched_delayed] " before the actual message.
> However it doesn't take into account the
On Sat 20-09-14 17:47:33, Peter Zijlstra wrote:
> On Sat, Sep 20, 2014 at 07:12:24AM +0200, Jan Kara wrote:
> > On Thu 18-09-14 19:34:14, Peter Zijlstra wrote:
> > > On Wed, Sep 17, 2014 at 08:31:35PM -0400, Steven Rostedt wrote:
> > > > I totally didn't get what you wrote.
> > >
> > > :-)
> > >
On Sat, Sep 20, 2014 at 12:30:01PM -0400, Steven Rostedt wrote:
> On Sat, 20 Sep 2014 09:10:47 -0700
> Joe Perches wrote:
>
> > On Sat, 2014-09-20 at 17:47 +0200, Peter Zijlstra wrote:
> > > On a whole, printk() is entirely useless for debugging these days, its
> > > far too fragile/unreliable to
On Sat, Sep 20, 2014 at 09:10:47AM -0700, Joe Perches wrote:
> On Sat, 2014-09-20 at 17:47 +0200, Peter Zijlstra wrote:
> > On a whole, printk() is entirely useless for debugging these days, its
> > far too fragile/unreliable to be taken seriously so I really don't care
> > on that point either.
>
On 2014.09.20 at 11:32 -0400, Steven Rostedt wrote:
> On Sat, 20 Sep 2014 07:12:24 +0200
> Jan Kara wrote:
>
> > On Thu 18-09-14 19:34:14, Peter Zijlstra wrote:
> > > On Wed, Sep 17, 2014 at 08:31:35PM -0400, Steven Rostedt wrote:
> > > > I totally didn't get what you wrote.
> > >
> > > :-)
> >
On Sat, 20 Sep 2014 09:10:47 -0700
Joe Perches wrote:
> On Sat, 2014-09-20 at 17:47 +0200, Peter Zijlstra wrote:
> > On a whole, printk() is entirely useless for debugging these days, its
> > far too fragile/unreliable to be taken seriously so I really don't care
> > on that point either.
>
> Th
On Sat, 2014-09-20 at 17:47 +0200, Peter Zijlstra wrote:
> On a whole, printk() is entirely useless for debugging these days, its
> far too fragile/unreliable to be taken seriously so I really don't care
> on that point either.
That's unfortunate.
Care to enumerate the issues that you believe mak
On Sat, Sep 20, 2014 at 07:12:24AM +0200, Jan Kara wrote:
> On Thu 18-09-14 19:34:14, Peter Zijlstra wrote:
> > On Wed, Sep 17, 2014 at 08:31:35PM -0400, Steven Rostedt wrote:
> > > I totally didn't get what you wrote.
> >
> > :-)
> >
> > > We don't want to know if it got delayed, then the patch
On Sat, 20 Sep 2014 07:12:24 +0200
Jan Kara wrote:
> On Thu 18-09-14 19:34:14, Peter Zijlstra wrote:
> > On Wed, Sep 17, 2014 at 08:31:35PM -0400, Steven Rostedt wrote:
> > > I totally didn't get what you wrote.
> >
> > :-)
> >
> > > We don't want to know if it got delayed, then the patch to re
On Thu 18-09-14 19:34:14, Peter Zijlstra wrote:
> On Wed, Sep 17, 2014 at 08:31:35PM -0400, Steven Rostedt wrote:
> > I totally didn't get what you wrote.
>
> :-)
>
> > We don't want to know if it got delayed, then the patch to remove that
> > print seems correct.
>
> Why would you not want to k
On Wed, Sep 17, 2014 at 08:31:35PM -0400, Steven Rostedt wrote:
> I totally didn't get what you wrote.
:-)
> We don't want to know if it got delayed, then the patch to remove that
> print seems correct.
Why would you not want to know that? Also was that the actual argument?
Lemme go check the ea
On Thu, 18 Sep 2014 00:36:33 +0200
Peter Zijlstra wrote:
> On Wed, Sep 17, 2014 at 10:22:55AM -0400, Steven Rostedt wrote:
> > On Wed, 17 Sep 2014 16:18:16 +0200
> > Peter Zijlstra wrote:
>
> > > By not calling console_unlock() the messages will be 'delayed', as in,
> > > we'll not call console
On Wed, Sep 17, 2014 at 10:22:55AM -0400, Steven Rostedt wrote:
> On Wed, 17 Sep 2014 16:18:16 +0200
> Peter Zijlstra wrote:
> > By not calling console_unlock() the messages will be 'delayed', as in,
> > we'll not call console->write() and we'll not see them, etc..
> >
> > So some form of [delay
On Wed, 17 Sep 2014 16:18:16 +0200
Peter Zijlstra wrote:
> On Tue, Sep 16, 2014 at 05:33:28PM -0400, Steven Rostedt wrote:
>
> > > printk_deffered() will be in order with other printks after your commit
> > > 458df9fd4815b47809875d57f42e16401674b621. Just printing to console itself
> > > will
On Tue, Sep 16, 2014 at 05:33:28PM -0400, Steven Rostedt wrote:
> > printk_deffered() will be in order with other printks after your commit
> > 458df9fd4815b47809875d57f42e16401674b621. Just printing to console itself
> > will be delayed to the next timer interrupt. Or am I missing something?
>
On Tue, 16 Sep 2014 23:22:50 +0200
Jan Kara wrote:
> > For the most part it's a blocking write. Yeah, if another CPU is
> > writing, it wont be a blocking write, but it usually is, I know I
> > depend on it (when I'm debugging, I usually don't have contention
> > between CPUs). The important part
On Tue 16-09-14 17:07:09, Steven Rostedt wrote:
> On Tue, 16 Sep 2014 22:35:10 +0200
> Jan Kara wrote:
>
> > On Tue 16-09-14 11:13:31, Steven Rostedt wrote:
> > > On Tue, 16 Sep 2014 16:42:52 +0200
> > > Markus Trippelsdorf wrote:
> > >
> > > > commit 458df9fd hardcodes printk_deferred() to KER
On Tue, 16 Sep 2014 22:35:10 +0200
Jan Kara wrote:
> On Tue 16-09-14 11:13:31, Steven Rostedt wrote:
> > On Tue, 16 Sep 2014 16:42:52 +0200
> > Markus Trippelsdorf wrote:
> >
> > > commit 458df9fd hardcodes printk_deferred() to KERN_WARNING and inserts
> > > the string "[sched_delayed] " before
On Tue 16-09-14 11:13:31, Steven Rostedt wrote:
> On Tue, 16 Sep 2014 16:42:52 +0200
> Markus Trippelsdorf wrote:
>
> > commit 458df9fd hardcodes printk_deferred() to KERN_WARNING and inserts
> > the string "[sched_delayed] " before the actual message.
> > However it doesn't take into account the
On Tue, 16 Sep 2014 21:17:40 +0200
Markus Trippelsdorf wrote:
> On 2014.09.16 at 15:14 -0400, Steven Rostedt wrote:
> > On Tue, 16 Sep 2014 17:20:46 +0200
> > Markus Trippelsdorf wrote:
> >
> > > On 2014.09.16 at 11:13 -0400, Steven Rostedt wrote
> > > I'll leave it to you. This is just a cosme
On 2014.09.16 at 15:14 -0400, Steven Rostedt wrote:
> On Tue, 16 Sep 2014 17:20:46 +0200
> Markus Trippelsdorf wrote:
>
> > On 2014.09.16 at 11:13 -0400, Steven Rostedt wrote
> > I'll leave it to you. This is just a cosmetic issue, so there's no need
> > to fix this immediately.
> >
>
> Actuall
On Tue, 16 Sep 2014 17:20:46 +0200
Markus Trippelsdorf wrote:
> On 2014.09.16 at 11:13 -0400, Steven Rostedt wrote
> I'll leave it to you. This is just a cosmetic issue, so there's no need
> to fix this immediately.
>
Actually the fix is much simpler (I had to wait for the drugs to wear
off bef
On 2014.09.16 at 11:13 -0400, Steven Rostedt wrote:
> On Tue, 16 Sep 2014 16:42:52 +0200
> Markus Trippelsdorf wrote:
>
> > commit 458df9fd hardcodes printk_deferred() to KERN_WARNING and inserts
> > the string "[sched_delayed] " before the actual message.
> > However it doesn't take into account
On Tue, 16 Sep 2014 16:42:52 +0200
Markus Trippelsdorf wrote:
> commit 458df9fd hardcodes printk_deferred() to KERN_WARNING and inserts
> the string "[sched_delayed] " before the actual message.
> However it doesn't take into account the KERN_* prefix of the message,
> that now ends up in the mid
24 matches
Mail list logo
