Bug 247153
| Summary: | emulators/virtualbox-ose-kmod System crash on VM resume after system upgrade | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | rkoberman | ||||
| Component: | kern | Assignee: | Mark Johnston <markj> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | CC: | markj | ||||
| Priority: | --- | ||||||
| Version: | 12.1-STABLE | ||||||
| Hardware: | amd64 | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
|
Description
rkoberman
2020-06-10 21:59:27 UTC
First, I did get the working revision VERY wrong. The good version was 361412. The failing one was 3861980. Sorry! After further testing, there is no problem with r361412. I had made an error in my rollback and, after correcting it, the VM runs normally. I then updated again today and confirmed the failure. Tomorrow I will start bisecting kernels and try to track down the exact revision that triggers the crash. I have now tracked the crash to r361350, "Provide separate accounting for user-wired pages." Revert this commit and everything works. With this commit, the system crashes when I start my Windows7 VM. All backtraces are essentially identical to the one in the initial report. A bit more detail on the trigger. If the VM is in a "Saved" state, the crash happens immediately after the image is loaded and started. If the VM is "Powered off", the system boots up until it does its second window resize. The initial window is the console window at 640x480. As soon as the system boot starts, it resizes to 800x600 for the splash screen and the animated Wind7 logo. After a few seconds, it expands to the size I have set for the running system, about 1480x816. At that time, the system panics. Any ideas?Much as I hate to admit it, I do need my Windows system regularly. (In reply to rkoberman from comment #2) I take it you have not rebuilt the virtualbox kernel modules? That is, you are using whatever modules that were installed by pkg? (In reply to Mark Johnston from comment #3) And a follow-up question: how much RAM does the system have, and how much do you give to the VM? (In reply to Mark Johnston from comment #4) Never mind, I managed to reproduce it on head. It looks like my change exposed an error-handling bug in the virtualbox kernel code. As a workaround, please try increasing vm.max_wired to the value hw.physmem / 4096 before starting the VM. (In reply to Mark Johnston from comment #4) The system has 8G and the VM is allowed 4G. Wow, that's a lot of wired memory, but that did the trick! VM now runs fine. Let me know if I can test any patch. Since this bumps FreeBSD_version, this commit requires a full rebuild of userland at 3.5+ hours on my 9 year old system; 2.5 just to build the LLVM stuff. At least I'll only need one more full rebuild to get up to date. I may start letting the system build use the full LLVM from ports to make this sort of thing less painful! Thanks so much for the VERY quick response! Awesome! Created attachment 215559 [details]
proposed patch
Thanks. Could you try the attached patch? It is only necessary to recompile the kernel, no need to rebuild world or any ports. This is true for the original commit too, __FreeBSD_version bump notwithstanding.
Patch applied & kernel rebuilt. No problems at all. My VMs now are starting properly. Thanks so much for such a quick response and fix. Once committed, feel free to close the ticket. (In reply to rkoberman from comment #9) Thanks. To be clear, did you test with the vm.max_wired reverted to the default value? (In reply to rkoberman from comment #9) Yes. Saw no point in testing with the huge max_wired. (In reply to rkoberman from comment #11) Great, thanks again. Sorry for the delay. I haven't forgotten about this, I will try to get a fix committed soon. Mark, Has this been resolved? If not, any hope? (In reply to rkoberman from comment #14) Not yet, sorry. I posted a patch to simply increase the default vm_max_user_wired value, which I aim to get into 12.2. I'll also try to fix virtualbox to avoid panicking the kernel if it hits the limit/ I ended up committing a patch to increase the default user-wired memory limit, which effectively works around the problem for "reasonable" VM configurations. It was merged to 12.2. I also have a patch to virtualbox to avoid crashing when the limit is hit which I'll submit this week. The virtualbox patch was committed to ports as r549922. |
