On Wed 2019-02-13 09:31:54, Steven Rostedt wrote:
> On Wed, 13 Feb 2019 22:00:04 +0800
> xiang xiao wrote:
> > Here is a sample output with this patch:
> > [ 10.991426] virtio_rpmsg_bus virtio1: rpmsg host is online
> > [ 10.991443] remoteproc remoteproc1: registered virtio1 (type 7)
> > [ 1
On (02/13/19 09:31), Steven Rostedt wrote:
> > Without this patch:
> > [ 10.991426] virtio_rpmsg_bus virtio1: rpmsg host is online
> > [ 10.991443] remoteproc remoteproc1: registered virtio1 (type 7)
> > [ 10.991450] remoteproc remoteproc1: remote processor
> > f921.toppwr:sen-rproc is no
On Wed, Feb 13, 2019 at 10:31 PM Steven Rostedt wrote:
>
> On Wed, 13 Feb 2019 22:00:04 +0800
> xiang xiao wrote:
>
> > On Wed, Feb 13, 2019 at 9:47 PM Steven Rostedt wrote:
> > >
> > > On Wed, 13 Feb 2019 14:19:01 +0800
> > > xiang xiao wrote:
> > >
> > > > On Wed, Feb 13, 2019 at 3:46 AM Stev
On Wed, 13 Feb 2019 22:00:04 +0800
xiang xiao wrote:
> On Wed, Feb 13, 2019 at 9:47 PM Steven Rostedt wrote:
> >
> > On Wed, 13 Feb 2019 14:19:01 +0800
> > xiang xiao wrote:
> >
> > > On Wed, Feb 13, 2019 at 3:46 AM Steven Rostedt
> > > wrote:
> > > >
> > > > On Wed, 13 Feb 2019 02:11:05
On Wed, Feb 13, 2019 at 9:47 PM Steven Rostedt wrote:
>
> On Wed, 13 Feb 2019 14:19:01 +0800
> xiang xiao wrote:
>
> > On Wed, Feb 13, 2019 at 3:46 AM Steven Rostedt wrote:
> > >
> > > On Wed, 13 Feb 2019 02:11:05 +0800
> > > Xiang Xiao wrote:
> > >
> > > > Because log may already add the times
On Wed, Feb 13, 2019 at 9:19 PM Petr Mladek wrote:
>
> On Wed 2019-02-13 14:19:01, xiang xiao wrote:
> > On Wed, Feb 13, 2019 at 3:46 AM Steven Rostedt wrote:
> > >
> > > On Wed, 13 Feb 2019 02:11:05 +0800
> > > Xiang Xiao wrote:
> > >
> > > > Because log may already add the timestamp sometime
>
On Wed, 13 Feb 2019 14:19:01 +0800
xiang xiao wrote:
> On Wed, Feb 13, 2019 at 3:46 AM Steven Rostedt wrote:
> >
> > On Wed, 13 Feb 2019 02:11:05 +0800
> > Xiang Xiao wrote:
> >
> > > Because log may already add the timestamp sometime
> >
> > Can you be a bit more detailed on this. When and
On Wed 2019-02-13 14:19:01, xiang xiao wrote:
> On Wed, Feb 13, 2019 at 3:46 AM Steven Rostedt wrote:
> >
> > On Wed, 13 Feb 2019 02:11:05 +0800
> > Xiang Xiao wrote:
> >
> > > Because log may already add the timestamp sometime
> >
> > Can you be a bit more detailed on this. When and where does t
On Wed, Feb 13, 2019 at 4:08 PM Sergey Senozhatsky
wrote:
>
> On (02/13/19 15:14), xiang xiao wrote:
> >
> > But how can I precisely control timestamp on/off per message
> > through sysfs node?
> >
>
> Hmm. I don't know how many kernel printk-s you have and how often
> do you write to kmsg.
It de
On (02/13/19 15:14), xiang xiao wrote:
>
> But how can I precisely control timestamp on/off per message
> through sysfs node?
>
Hmm. I don't know how many kernel printk-s you have and how often
do you write to kmsg. I was thinking about something like this:
echo 0 > /...printk.../time
But how can I precisely control timestamp on/off per message through sysfs node?
On Wed, Feb 13, 2019 at 2:38 PM Sergey Senozhatsky
wrote:
>
> On (02/13/19 15:29), Sergey Senozhatsky wrote:
> >
> > cat /sys/module/printk/parameters/time ?
> ^
> cat / echo
>
> Works both ways.
>
> -ss
On (02/13/19 15:29), Sergey Senozhatsky wrote:
>
> cat /sys/module/printk/parameters/time ?
^
cat / echo
Works both ways.
-ss
On (02/13/19 14:19), xiang xiao wrote:
> Here is my case:
> 1.A small MCU(Cortex M4) in SoC run RTOS
> 2.RTOS append timestamp to log for the accurate timing
> 3.RTOS send log to Linux kernel when buffer exceed the threshold
> 4.Kernel call printk to dump the received buffer
> So I want that printk
On Wed, Feb 13, 2019 at 8:48 AM Sergey Senozhatsky
wrote:
>
> On (02/13/19 02:11), Xiang Xiao wrote:
> >
> > Because log may already add the timestamp sometime
> >
>
> We have module_param(printk_time) which enables/disables
> timestamps. And a .config option. And a kernel boot param.
> Why would
On Wed, Feb 13, 2019 at 3:46 AM Steven Rostedt wrote:
>
> On Wed, 13 Feb 2019 02:11:05 +0800
> Xiang Xiao wrote:
>
> > Because log may already add the timestamp sometime
>
> Can you be a bit more detailed on this. When and where does this
> happen?
Here is my case:
1.A small MCU(Cortex M4) in So
On (02/13/19 02:11), Xiang Xiao wrote:
>
> Because log may already add the timestamp sometime
>
We have module_param(printk_time) which enables/disables
timestamps. And a .config option. And a kernel boot param.
Why would you want KERN_NOTIME?
-ss
On Wed, 13 Feb 2019 02:11:05 +0800
Xiang Xiao wrote:
> Because log may already add the timestamp sometime
Can you be a bit more detailed on this. When and where does this
happen? If anything, I would probably prefer that we export whether
time is being printed, and have the caller not print time
Because log may already add the timestamp sometime
Signed-off-by: Xiang Xiao
---
include/linux/kern_levels.h | 2 ++
include/linux/printk.h | 1 +
kernel/printk/printk.c | 7 ++-
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/linux/kern_levels.h b/include/lin
18 matches
Mail list logo
