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
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 middle of the output:
[sched_delayed] ^a4CE: hpet increased min_delta_ns
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 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.
:-)
We don't want
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 middle of the output:
[sched_delayed] ^a4CE: hpet increased min_delta_ns
Andrew,
You want to pull this patch?
Thanks,
-- Steve
On Wed, 24 Sep 2014 17:20:19 +0200
Markus Trippelsdorf mar...@trippelsdorf.de wrote:
commit 458df9fd hardcodes printk_deferred() to KERN_WARNING and inserts
the string [sched_delayed] before the actual message.
However it doesn't take
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
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.
>
>
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
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
On Sat, 20 Sep 2014 07:12:24 +0200
Jan Kara j...@suse.cz 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
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 to remove that
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 make
On Sat, 20 Sep 2014 09:10:47 -0700
Joe Perches j...@perches.com 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
On 2014.09.20 at 11:32 -0400, Steven Rostedt wrote:
On Sat, 20 Sep 2014 07:12:24 +0200
Jan Kara j...@suse.cz 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 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 Sat, Sep 20, 2014 at 12:30:01PM -0400, Steven Rostedt wrote:
On Sat, 20 Sep 2014 09:10:47 -0700
Joe Perches j...@perches.com 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
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
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
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
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 know that?
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
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
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, 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 Wed, 17 Sep 2014 16:18:16 +0200
Peter Zijlstra pet...@infradead.org 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
On Wed, Sep 17, 2014 at 10:22:55AM -0400, Steven Rostedt wrote:
On Wed, 17 Sep 2014 16:18:16 +0200
Peter Zijlstra pet...@infradead.org 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
On Thu, 18 Sep 2014 00:36:33 +0200
Peter Zijlstra pet...@infradead.org 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 pet...@infradead.org wrote:
By not calling console_unlock() the messages will be 'delayed', as
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
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
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] "
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
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
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.
> >
>
>
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
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
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
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 middle of the output:
[sched_delayed] ^a4CE: hpet increased min_delta_ns
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 middle of the output:
[sched_delayed] ^a4CE: hpet increased min_delta_ns
On Tue, 16 Sep 2014 16:42:52 +0200
Markus Trippelsdorf mar...@trippelsdorf.de 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
On 2014.09.16 at 11:13 -0400, Steven Rostedt wrote:
On Tue, 16 Sep 2014 16:42:52 +0200
Markus Trippelsdorf mar...@trippelsdorf.de wrote:
commit 458df9fd hardcodes printk_deferred() to KERN_WARNING and inserts
the string [sched_delayed] before the actual message.
However it doesn't take
On Tue, 16 Sep 2014 17:20:46 +0200
Markus Trippelsdorf mar...@trippelsdorf.de 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
On 2014.09.16 at 15:14 -0400, Steven Rostedt wrote:
On Tue, 16 Sep 2014 17:20:46 +0200
Markus Trippelsdorf mar...@trippelsdorf.de 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.
On Tue, 16 Sep 2014 21:17:40 +0200
Markus Trippelsdorf mar...@trippelsdorf.de wrote:
On 2014.09.16 at 15:14 -0400, Steven Rostedt wrote:
On Tue, 16 Sep 2014 17:20:46 +0200
Markus Trippelsdorf mar...@trippelsdorf.de wrote:
On 2014.09.16 at 11:13 -0400, Steven Rostedt wrote
I'll leave
On Tue 16-09-14 11:13:31, Steven Rostedt wrote:
On Tue, 16 Sep 2014 16:42:52 +0200
Markus Trippelsdorf mar...@trippelsdorf.de 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
On Tue, 16 Sep 2014 22:35:10 +0200
Jan Kara j...@suse.cz wrote:
On Tue 16-09-14 11:13:31, Steven Rostedt wrote:
On Tue, 16 Sep 2014 16:42:52 +0200
Markus Trippelsdorf mar...@trippelsdorf.de wrote:
commit 458df9fd hardcodes printk_deferred() to KERN_WARNING and inserts
the string
On Tue 16-09-14 17:07:09, Steven Rostedt wrote:
On Tue, 16 Sep 2014 22:35:10 +0200
Jan Kara j...@suse.cz wrote:
On Tue 16-09-14 11:13:31, Steven Rostedt wrote:
On Tue, 16 Sep 2014 16:42:52 +0200
Markus Trippelsdorf mar...@trippelsdorf.de wrote:
commit 458df9fd hardcodes
On Tue, 16 Sep 2014 23:22:50 +0200
Jan Kara j...@suse.cz 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
52 matches
Mail list logo
