Re: [PATCH] printk: avoid prb_first_valid_seq() where possible

Hello John, Thank you for looking into this! Yes, I can confirm that your patch seems to have resolved the issue I'd reported. Thanks, Avila On Mon, Feb 8, 2021 at 1:21 AM John Ogness wrote: > > On 2021-02-08, Sergey Senozhatsky wrote: > > Can we please also ask the kernel test robot to test

Re: Issue in dmesg time with lockless ring buffer

indicates a potential issue in the code; do you think it's worth investigation? Thanks, Avila On Mon, Jan 25, 2021 at 4:00 PM J. Avila wrote: > > Hello, > > This dmesg uses /dev/kmsg; we've verified that we don't see this long > dmesg time when reading from syslog (via dmesg -S).

Re: Issue in dmesg time with lockless ring buffer

shell. Thanks, Avila On Mon, Jan 25, 2021 at 5:32 AM John Ogness wrote: > > On 2021-01-22, "J. Avila" wrote: > > When doing some internal testing on a 5.10.4 kernel, we found that the > > time taken for dmesg seemed to increase from the order of milliseconds >

Issue in dmesg time with lockless ring buffer

Hello, When doing some internal testing on a 5.10.4 kernel, we found that the time taken for dmesg seemed to increase from the order of milliseconds to the order of seconds when the dmesg size approached the ~1.2MB limit. After doing some digging, we found that by reverting all of the patches in

Re: Potential Issue in Tracing Ring Buffer

> > On Mon, Nov 30, 2020 at 09:48:46AM -0500, Steven Rostedt wrote: > > On Thu, 26 Nov 2020 13:26:13 -0500 > > Steven Rostedt wrote: > > > > > On Thu, 26 Nov 2020 06:52:45 +0100 > > > Greg KH wrote: > > > > > > >

Potential Issue in Tracing Ring Buffer

Hello, In the ftrace logs we've collected internally, we have found that there are situations where time seems to go backwards; this breaks userspace tools which expect time to always go forward in these logs. For example, in this snippet from a db845c running a 5.10-rc4 kernel[1] (thanks for