VirtualBox

Ticket #2341 (closed defect: fixed)

Opened 10 years ago

Last modified 9 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 10 years ago.
Log
vbox-freebsd.png Download (58.4 KB) - added by essdeeay 10 years ago.
Screenshot
VBox.log Download (77.0 KB) - added by fzzzt 10 years ago.
New log file

Change History

Changed 10 years ago by fzzzt

Log

comment:1 Changed 10 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 10 years ago by essdeeay

Screenshot

comment:2 Changed 10 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 10 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 10 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 10 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 10 years ago by sandervl73

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

comment:7 in reply to: ↑ 6 Changed 10 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 10 years ago by fzzzt

New log file

comment:8 follow-up: ↓ 9 Changed 10 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 10 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 10 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 10 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 10 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 10 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 10 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 10 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 10 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 10 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 10 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 10 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 10 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 10 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 10 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 10 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 10 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 10 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 10 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