On Wed, Feb 21, 2018 at 01:39:52PM -0800, Linus Torvalds wrote:
> which are actually about the crash. The rest is almost entirely useless.
>
> Do I know what the corrent answer is? No.
Ok, I hear ya. I finally have some time to poke at this. So here's a new
splat, see below. Incremental diff at t
Josh Poimboeuf writes:
> On Thu, Feb 22, 2018 at 10:42:52AM -0800, Linus Torvalds wrote:
>> So what we could perhaps do is:
>>
>> - make console_verbose() actually reset things to at least LOGLEVEL_DEBUG
>>
>> - make sure the *default* loglevel be LOGLEVEL_WARNING
>>
>> - now you can use p
On Thu, Feb 22, 2018 at 10:42:52AM -0800, Linus Torvalds wrote:
> So what we could perhaps do is:
>
> - make console_verbose() actually reset things to at least LOGLEVEL_DEBUG
>
> - make sure the *default* loglevel be LOGLEVEL_WARNING
>
> - now you can use pr_debug() in the oops code to prin
On Thu, Feb 22, 2018 at 1:23 AM, Peter Zijlstra wrote:
>
> So being one to only use machines that have a serial line this does not
> really affect me; but it would appear to me that it might make sense to
> try and reverse the entire dump.
In theory yes. But while you mention the buffering proble
On Wed, Feb 21, 2018 at 01:39:52PM -0800, Linus Torvalds wrote:
> showing with a hung kernel. And most of the above is actually
> completely useless. Those are the *usermode* registers it shows, not
> the kernel registers at the time of the crash (the final rip/rsp/code
> lines are for the actual k
On Wed, Feb 21, 2018 at 9:54 AM, Borislav Petkov wrote:
>
> Ok, lemme run it by Linus too as he probably stares at this part of the
> output a *lot* :-)
Less than I used to, since there are others who are pretty good at
decoding them, but yes...
> Anyway, here's a 64-bit splat. I'm basically dum
On Wed, Feb 21, 2018 at 10:15:53AM +0100, Ingo Molnar wrote:
> That looks really useful!
Ok, lemme run it by Linus too as he probably stares at this part of the
output a *lot* :-)
Combined patch at the end. I'll split it later.
@Linus: also, pls have a look at
https://lkml.kernel.org/r/201802192
* Borislav Petkov wrote:
> On Tue, Feb 20, 2018 at 01:29:56PM -0600, Josh Poimboeuf wrote:
> > > Maybe this series already has this side-effect, but I'd really love to
> > > see oopses show the code bytes for each kernel entry, not just the
> > > innermode one. We already dump full regs includi
On Tue, Feb 20, 2018 at 01:29:56PM -0600, Josh Poimboeuf wrote:
> > Maybe this series already has this side-effect, but I'd really love to
> > see oopses show the code bytes for each kernel entry, not just the
> > innermode one. We already dump full regs including RIP -- adding
> > Code: should be
On Tue, Feb 20, 2018 at 07:14:00PM +, Andy Lutomirski wrote:
> On Mon, Feb 19, 2018 at 8:28 PM, Borislav Petkov wrote:
> > From: Borislav Petkov
> >
> > Hi,
> >
> > so I've been thinking about doing this for a while now: be able to dump
> > the opcode bytes around the user rIP just like we do
On Mon, Feb 19, 2018 at 8:28 PM, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Hi,
>
> so I've been thinking about doing this for a while now: be able to dump
> the opcode bytes around the user rIP just like we do for kernel faults.
>
> Why?
>
> See patch 5's commit message. That's why I've
From: Borislav Petkov
Hi,
so I've been thinking about doing this for a while now: be able to dump
the opcode bytes around the user rIP just like we do for kernel faults.
Why?
See patch 5's commit message. That's why I've marked it RFC.
The rest is cleanups: we're copying the opcodes byte-by-b
12 matches
Mail list logo
