Decoding an oops

Decoding an oops

[Francis M]

[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]

[Not subscribed to LKML so please Cc: me on replies if any]

Hello,

I've hit an oops in an Ubuntu 19.04 Server VirtualBox VM, running
Ubuntu's hacked-up version of (I think) 5.2.18, that's proving
difficult to fully capture.

Am in the process of trying to get the system back to a state where I
can boot into it cleanly and investigate further.

Alas a simple enabling of DHCPv6 in netplan's config for a single
network interface followed by "netplan apply && reboot" is what
triggered this oops and has bricked the VM. Copying over the VM's disc
images to a KVM host for further investigation but that'll annoyingly
take hours...

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.

Cheekily adding Linus to the Cc: on the off-chance; have admired your
opcode/register state demystifying skills from afar for many years.
Apologies in advance.

Failing that... I'll post back in few hours once I've been able to
grab the full oops.

Cheers,
Francis

[-- Attachment #2: ubuntu-5.x-oops-cropped.jpg --]
[-- Type: image/jpeg, Size: 189205 bytes --]

Re: Decoding an oops

[Linus Torvalds]

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).

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.

See

     https://en.wikipedia.org/wiki/VESA_BIOS_Extensions#Linux_video_mode_numbers

for more commentary.

That *might* work, and get you more of the dump.

              Linus

Re: Decoding an oops

[Francis M]

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