Re: Decoding an oops

[Francis M <fmcbra@gmail.com>]

On Mon, 7 Oct 2019 at 20:38, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, Oct 7, 2019 at 7:58 AM Francis M <fmcbra@gmail.com> wrote:
> >
> > Attached is a JPEG of what I've been able to capture from the console.
> > I'm guessing it's probably not enough to go on, but hoping someone
> > might have an 'ahh, that looks familiar' moment.
>
> That is an awkwardly small snippet and not showing any of the real
> oops state at all (the code/rip dump is actually the user space state
> at the time of the system call that then causes the problem).

I was pretty sure it'd turn out to be worthless, cheers for
confirming ;)

> Can you make your VM use a bigger terminal so that it shows more of
> the oops? Assuming your virtual environment supports the usual VESA
> VGA modes, it might be as easy as just booting with "vga=775" to get a
> 1280x1024 console.

I forgot about the old VGA mode parameters. Have had trouble
(read: zero luck) getting a high-res console for this VM from grub
through to kernel boot since it was provisioned, but I'll give the
above a shot once I've got the disc images safely backed up.

Have gleaned a small nugget more of stack which might help
down the road if this turns out to be VirtualBox-specific: I'm
reliably seeing "vbg_*" (drivers/virt/vboxguest/) stack frames
very early in the oops but they're scrolling way too fast for me
to snap a photo with my mobile. Maybe stack corruption,
maybe not. Pretty sure the VM is using mainline vboxguest.

Anyway, I'll try and glean as much info as I can with vga= and /
or delayed "printk()".

Should note in case the Oracle devs see this, this is a Win 10 Pro
host, 2019 Core i7, running VirtualBox 6.x. I'll haul this bug 'report'
upstream if further analysis points to vboxguest.

Cheers,
Francis