On Mon, 7 Oct 2019 at 20:38, Linus Torvalds <torva...@linux-foundation.org> wrote: > > On Mon, Oct 7, 2019 at 7:58 AM Francis M <fmc...@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
