VirtualBox

Ticket #2341 (closed defect: fixed)

Opened 6 years ago

Last modified 4 years ago

FreeBSD 7.0-RELEASE sigreturn eflags => fixed in SVN

Reported by: fzzzt Owned by:
Priority: major Component: VMM
Version: VirtualBox 2.1.2 Keywords:
Cc: Guest type: BSD
Host type: Windows

Description

This bug is still here...worse than before according to my tests. It's easily reproducible by building world, but decreasing kern.hz doesn't seem to get rid of it anymore.

Attachments

VBox - Copy.log Download (52.2 KB) - added by fzzzt 6 years ago.
Log
vbox-freebsd.png Download (58.4 KB) - added by essdeeay 6 years ago.
Screenshot
VBox.log Download (77.0 KB) - added by fzzzt 5 years ago.
New log file

Change History

Changed 6 years ago by fzzzt

Log

comment:1 Changed 6 years ago by essdeeay

I can also confirm this bug. It is present in VirtualBox 1.x with FreeBSD 6.2 (see #1530).

VIRTUALBOX: 2.0.2 HOST: Vista Home Premium SP1 (with all Windows Updates) GUEST: FreeBSD 7.0-RELEASE

Just a screenshot to add.

Is any contributor able to comment on this issue? It seems very prevalent from all the posts about it.

Steve :)

Changed 6 years ago by essdeeay

Screenshot

comment:2 Changed 6 years ago by frank

  • Status changed from new to closed
  • Resolution set to duplicate

So no need to open a duplicate (of #1530).

comment:3 follow-up: ↓ 4 Changed 6 years ago by essdeeay

  • Status changed from closed to reopened
  • Resolution duplicate deleted

I'm sorry Frank - I know you closed this because of a duplicate, but #1530 refers to version 1.6.0 (presumably not being developed any more), whereas this refers to version 2.0.2.

Can you mark #1530 as a duplicate of this one instead please?

comment:4 in reply to: ↑ 3 Changed 6 years ago by frank

  • Component changed from other to VMM

Replying to essdeeay:

Can you mark #1530 as a duplicate of this one instead please?

Done.

comment:5 Changed 5 years ago by sandervl73

  • Summary changed from FreeBSD 7.0-RELEASE sigreturn eflags to FreeBSD 7.0-RELEASE sigreturn eflags -> fixed in SVN

Should be fixed now. Try with the upcoming 2.1.2.

comment:6 follow-up: ↓ 7 Changed 5 years ago by sandervl73

  • Status changed from reopened to closed
  • Resolution set to fixed

comment:7 in reply to: ↑ 6 Changed 5 years ago by jdjennings

Replying to sandervl73:

The problem still exists. Running VirtualBox 2.1.2, FreeBSD 7.1 as a guest. run "make buildkernel", got "sigreturn: eflags = 0x80286" and the make is hung with a zombie subprocess.

Changed 5 years ago by fzzzt

New log file

comment:8 follow-up: ↓ 9 Changed 5 years ago by fzzzt

  • Status changed from closed to reopened
  • Resolution fixed deleted

Alas, the sigreturn gods have not favored 2.1.2. I just installed a stock 7.0 with no tweaks and got "sigreturn: eflags = 0x80213" while running "portsnap extract". I'm going to try some kern.hz changes and disabling ACPI and see if that helps. Sorry guys. :(

comment:9 in reply to: ↑ 8 Changed 5 years ago by fzzzt

Oops, not sure if I should've reopened this or started a new one for 2.1.2...

comment:10 Changed 5 years ago by sandervl73

  • Version changed from VirtualBox 2.0.2 to VirtualBox 2.1.2
  • Summary changed from FreeBSD 7.0-RELEASE sigreturn eflags -> fixed in SVN to FreeBSD 7.0-RELEASE sigreturn eflags

Reopen is fine. There's apparently another similar bug left.

comment:11 follow-up: ↓ 12 Changed 5 years ago by stargrave

There was a 6.2 kernel patch posted on #458 which got around this issue. It woudn't apply on 7.0, but after mearging it by hand it worked fine. Here is an updated patch tested on 7.0 and 7.1:

--- machdep.c.orig      2009-01-15 10:36:32.000000000 +0000
+++ machdep.c   2009-01-15 10:38:44.000000000 +0000
@@ -1014,10 +1014,24 @@
                 * corrupted by the signal handler without us knowing.
                 * Corruption of the PSL_RF bit at worst causes one more or
                 * one less debugger trap, so allowing it is fairly harmless.
+                 * Virtualbox occasionally sets PSL_VIF on its own, so clear
+                 * it if we see it and it's the only invalid flag.
                 */
+
+#define PSL_FLAGS "\x10\26ID\25VIP\24VIF\23AC\22VM\21RF\17NT\16IOPL2\15IOPL1\14V\13D\12I\11T\10N\7Z\5AF\2PF\1C"
+
                if (!EFL_SECURE(eflags & ~PSL_RF, regs->tf_eflags & ~PSL_RF)) {
-                       printf("sigreturn: eflags = 0x%x\n", eflags);
-                       return (EINVAL);
+                       int invalid = ((eflags & ~PSL_RF)^(regs->tf_eflags & ~PSL_RF))
+                           & ~PSL_USERCHANGE;
+                       printf("sigreturn: eflags = 0x%b, tf_eflags = 0x%b; invalid: 0x%b\n",
+                           eflags, PSL_FLAGS, regs->tf_eflags, PSL_FLAGS,
+                           invalid, PSL_FLAGS);
+                       if (invalid == PSL_VIF) {
+                               printf("Clearing invalid PSL_VIF from eflags and continuing\n");
+                               eflags &= ~PSL_VIF;
+                       } else
+                               return (EINVAL);
+ 
                }

                /*

to apply this patch:

# cd /usr/src/sys/i386/i386
# patch < path_to_patch

recompile the kernel and reboot.

In my observation sigreturn happened most often when running on an amd64 host, where freebsd guest was completely unusable. On i386 host it occurred less often. In both cases the host OS was OpenSolaris and no VT.

Hope this helps.

comment:12 in reply to: ↑ 11 Changed 5 years ago by enexy

Replying to stargrave:

There was a 6.2 kernel patch posted on #458 which got around this issue. It woudn't apply on 7.0, but after mearging it by hand it worked fine. Here is an updated patch tested on 7.0 and 7.1:

.............

In my observation sigreturn happened most often when running on an amd64 host, where freebsd guest was completely unusable. On i386 host it occurred less often. In both cases the host OS was OpenSolaris and no VT.

Hope this helps.

Greetings!

This isn't working on OpenSUSE+VirtualBox 2.1.2 / Debian + Virtualbox 2.1.2. In both cases we're facing sigreturn at FreeBSD 7.1

comment:13 follow-up: ↓ 14 Changed 5 years ago by ni81036

It's unclear what's real reason of this bug, and I cannot reproduce it any longer locally (although I used to). Try to apply following patch to the VirtualBox: replace env->eflags &= ~(TF_MASK | VM_MASK | RF_MASK | NT_MASK); with env->eflags &= ~(TF_MASK | VM_MASK | VIF_MASK | VIP_MASK | RF_MASK | NT_MASK); at the very bottom of do_interrupt_protected() in src/recompiler_new/target-i386/op_helper.c

And report back if it fixes or improves your situation.

comment:14 in reply to: ↑ 13 ; follow-up: ↓ 15 Changed 5 years ago by lekanteto

Replying to ni81036:

replace env->eflags &= ~(TF_MASK | VM_MASK | RF_MASK | NT_MASK); with env->eflags &= ~(TF_MASK | VM_MASK | VIF_MASK | VIP_MASK | RF_MASK | NT_MASK); at the very bottom of do_interrupt_protected() in src/recompiler_new/target-i386/op_helper.c

And report back if it fixes or improves your situation.

This seems to fix the problem for me. I compiled the FreeBSD kernel twice without getting any incorrect eflags.

comment:15 in reply to: ↑ 14 Changed 5 years ago by lutierigb

Replying to lekanteto: ...

This seems to fix the problem for me. I compiled the FreeBSD kernel twice without getting any incorrect eflags.

I have disabled VT-x/AMD-V and enabled ACPI and I compiled the FreeBSD kernel and world once without any eflags.

comment:16 Changed 5 years ago by lutierigb

Yes. I wasn't lying about the compiling process. But right now I got an eflags error when trying to install the world. I'm applying the patch right now and report what will happen!

comment:17 follow-up: ↓ 19 Changed 5 years ago by ni81036

Please provide more testing to the suggested patch, otherwise, w/o better feedback we cannot make reasonable decisions on applicability of suggested fix!

comment:18 follow-up: ↓ 24 Changed 5 years ago by lutierigb

I have the source code, I have applied the patch but after compiled I don't have the VirtualBox binary. Is that because I'm compiling without QT?

I just need this question answered, after that I will be able to provide a better feedback.

comment:19 in reply to: ↑ 17 ; follow-up: ↓ 20 Changed 5 years ago by lekanteto

Replying to ni81036:

Please provide more testing to the suggested patch, otherwise, w/o better feedback we cannot make reasonable decisions on applicability of suggested fix!

I applied your fix in do_interrupt_protected() and I have not had any problems since. Please let me know if I can do more to help.

Stefan

comment:20 in reply to: ↑ 19 ; follow-up: ↓ 22 Changed 5 years ago by ni81036

Replying to lekanteto:

Replying to ni81036:

Please provide more testing to the suggested patch, otherwise, w/o better feedback we cannot make reasonable decisions on applicability of suggested fix!

I applied your fix in do_interrupt_protected() and I have not had any problems since. Please let me know if I can do more to help.

Stefan

Depending on host OS - replace all VBoxREM*.* from standard 2.1.4 binaries with ones from the version you just have built. It should be enough.

comment:21 Changed 5 years ago by jdjennings

I applied the patch in do_interrupt_protected(), and have built the kernel 3 times now with no problems.

comment:22 in reply to: ↑ 20 ; follow-up: ↓ 23 Changed 5 years ago by lekanteto

Replying to ni81036:

Replying to lekanteto:

Replying to ni81036:

Please provide more testing to the suggested patch, otherwise, w/o better feedback we cannot make reasonable decisions on applicability of suggested fix!

I applied your fix in do_interrupt_protected() and I have not had any problems since. Please let me know if I can do more to help.

Stefan

Depending on host OS - replace all VBoxREM*.* from standard 2.1.4 binaries with ones from the version you just have built. It should be enough.

This might be a misunderstanding. I have already been using the binaries that I had build. With those binaries, FreeBSD runs fine as a host OS.

comment:23 in reply to: ↑ 22 Changed 5 years ago by lekanteto

Replying to lekanteto:

Replying to ni81036:

Replying to lekanteto:

Replying to ni81036:

Please provide more testing to the suggested patch, otherwise, w/o better feedback we cannot make reasonable decisions on applicability of suggested fix!

I applied your fix in do_interrupt_protected() and I have not had any problems since. Please let me know if I can do more to help.

Stefan

Depending on host OS - replace all VBoxREM*.* from standard 2.1.4 binaries with ones from the version you just have built. It should be enough.

This might be a misunderstanding. I have already been using the binaries that I had build. With those binaries, FreeBSD runs fine as a host OS.

I meant guest OS ;-)

comment:24 in reply to: ↑ 18 Changed 5 years ago by lutierigb

Replying to lutierigb:

I have the source code, I have applied the patch but after compiled I don't have the VirtualBox binary. Is that because I'm compiling without QT?

I just need this question answered, after that I will be able to provide a better feedback.

After a while installing QT on my system I now have the VirtualBox compiled with the suggested patch applied. I have compiled the whole world and kernel, and installed as well so far there is no signs of eflags. Seems that really fix this issue.

Thank you. If there is any thing that I can do to help, please let me know.

comment:25 Changed 5 years ago by ni81036

  • Status changed from reopened to closed
  • Resolution set to fixed
  • Summary changed from FreeBSD 7.0-RELEASE sigreturn eflags to FreeBSD 7.0-RELEASE sigreturn eflags => fixed in SVN

comment:26 Changed 5 years ago by ni81036

Thanks to everybody who participated in testing - you did important work here.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use