On (08/10/19 07:53), Thomas Gleixner wrote:
>
> Right now we have an implementation for serial only, but that already is
> useful. I nicely got (minimaly garbled) crash dumps out of an NMI
> handler. With the current mainline console code the machine just hung.
>
Thomas, any chance you can post
On Fri, Aug 9, 2019 at 8:16 AM Peter Zijlstra wrote:
> On Thu, Aug 08, 2019 at 12:07:28PM -0700, Linus Torvalds wrote:
> > End result: a DRAM buffer can work, but is not "reliable".
> > Particularly if you turn power on and off, data retention of DRAM is
> > iffy. But it's possible, at least in
On Fri, 9 Aug 2019, Linus Torvalds wrote:
> On Thu, Aug 8, 2019 at 11:14 PM Peter Zijlstra wrote:
> > Note that you can hook this into printk as a fake early serial device;
> > just have the serial device write to the DRAM buffer.
>
> No, you really really can't.
...
> Even the "early console"
On Fri, Aug 9, 2019 at 1:07 PM Thomas Gleixner wrote:
>
> I'm all for it. I just tried it out and the ratio was 3 out of 5 retained
> the data +/- a few bitflips with ~2 seconds power off. The other two were
> the laptop and that server machine which wipes everything.
Perfect. That actually says
On Fri, 9 Aug 2019, Linus Torvalds wrote:
> On Fri, Aug 9, 2019 at 4:15 AM Thomas Gleixner wrote:
> >
> > >
> > > But I don't know what a power-off-in-laptop scenario really looks like..
> >
> > That's random behaviour. It's hardware & BIOS & value add. What do you
> > expect?
> >
> > I tried on
On Fri, Aug 9, 2019 at 4:15 AM Thomas Gleixner wrote:
>
> >
> > But I don't know what a power-off-in-laptop scenario really looks like..
>
> That's random behaviour. It's hardware & BIOS & value add. What do you
> expect?
>
> I tried on a few machines. My laptop does not retain any useful
On Thu, Aug 8, 2019 at 11:14 PM Peter Zijlstra wrote:
>
> Note that you can hook this into printk as a fake early serial device;
> just have the serial device write to the DRAM buffer.
No, you really really can't.
Look, the whole point of that reboot buffer is that it works WHEN
NOTHING ELSE
On Thu, 8 Aug 2019, Linus Torvalds wrote:
> On Thu, Aug 8, 2019 at 5:48 PM Steven Rostedt wrote:
> >
> > I've never tried, but are you saying that even with the "10 second
> > hold" the laptop's DRAM may still have old data that is accessible?
>
> The power doesn't go off when you *start* the
On 2019-08-09, Peter Zijlstra wrote:
>> End result: a DRAM buffer can work, but is not "reliable".
>> Particularly if you turn power on and off, data retention of DRAM is
>> iffy. But it's possible, at least in theory.
>>
>> So I have a patch that implements a "stupid ring buffer" for thisa
>>
On Thu, Aug 08, 2019 at 12:07:28PM -0700, Linus Torvalds wrote:
> End result: a DRAM buffer can work, but is not "reliable".
> Particularly if you turn power on and off, data retention of DRAM is
> iffy. But it's possible, at least in theory.
>
> So I have a patch that implements a "stupid ring
On Thu, Aug 8, 2019 at 5:48 PM Steven Rostedt wrote:
>
> I've never tried, but are you saying that even with the "10 second
> hold" the laptop's DRAM may still have old data that is accessible?
The power doesn't go off when you *start* the 10s hold. It goes off
after ten seconds.
So power is
On Thu, 8 Aug 2019 17:21:09 -0700
Linus Torvalds wrote:
> But laptops don't have reset buttons. They have "press the power
> button for ten seconds, power turns off. Press it again, and power
> comes on" reset sequences.
I've never tried, but are you saying that even with the "10 second
hold"
On Thu, Aug 8, 2019 at 4:45 PM Steven Rostedt wrote:
>
> Could we possibly have a magic value in some location that if it is
> set, we know right away that the buffer here has data from the last
> reboot, and we read it out into a safe location before we start using
> it again?
Right now I don't
On Thu, 8 Aug 2019 16:33:20 -0700
Linus Torvalds wrote:
> To which the obvious solution is "just use a different buffer for the
> next boot". But that brings up the *second* big issue with a
> reboot-safe buffer: it can't just be anywhere. Not only do you have to
> have some way to find the old
On Thu, Aug 8, 2019 at 3:56 PM John Ogness wrote:
>
> On a side note, I'm not sure sure if we want kernel code to do the ASCII
> dump of the raw buffer. A userspace application grabbing from /dev/mem
> might be more desirable.
So there are two major issues here.
One obvious one is that the
On 2019-08-08, Linus Torvalds wrote:
>> 2. For the CONFIG_PPC_POWERNV powerpc platform, kernel log buffer
>>registration is no longer available because there is no longer
>>a single contigous block of memory to represent all of the
>>ringbuffer.
>
> So this is tangential, but I've
On Wed, Aug 7, 2019 at 3:27 PM John Ogness wrote:
>
> 2. For the CONFIG_PPC_POWERNV powerpc platform, kernel log buffer
>registration is no longer available because there is no longer
>a single contigous block of memory to represent all of the
>ringbuffer.
So this is tangential, but
This is a major change because the API (and underlying workings)
of the new ringbuffer are completely different than the previous
ringbuffer. Since there are several components of the printk
infrastructure that use the ringbuffer API (console, /dev/kmsg,
syslog, kmsg_dump), there are quite a few
18 matches
Mail list logo
