#2341 closed defect (fixed)
FreeBSD 7.0-RELEASE sigreturn eflags => fixed in SVN
Reported by: | fzzzt | Owned by: | |
---|---|---|---|
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 (3)
Change History (29)
by , 16 years ago
Attachment: | VBox - Copy.log added |
---|
comment:1 by , 16 years ago
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 :)
comment:2 by , 16 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
So no need to open a duplicate (of #1530).
follow-up: 4 comment:3 by , 16 years ago
Resolution: | duplicate |
---|---|
Status: | closed → reopened |
comment:4 by , 16 years ago
Component: | other → VMM |
---|
comment:5 by , 16 years ago
Summary: | FreeBSD 7.0-RELEASE sigreturn eflags → FreeBSD 7.0-RELEASE sigreturn eflags -> fixed in SVN |
---|
Should be fixed now. Try with the upcoming 2.1.2.
follow-up: 7 comment:6 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:7 by , 16 years ago
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.
follow-up: 9 comment:8 by , 16 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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 by , 16 years ago
Oops, not sure if I should've reopened this or started a new one for 2.1.2...
comment:10 by , 16 years ago
Summary: | FreeBSD 7.0-RELEASE sigreturn eflags -> fixed in SVN → FreeBSD 7.0-RELEASE sigreturn eflags |
---|---|
Version: | VirtualBox 2.0.2 → VirtualBox 2.1.2 |
Reopen is fine. There's apparently another similar bug left.
follow-up: 12 comment:11 by , 16 years ago
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 by , 16 years ago
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
follow-up: 14 comment:13 by , 16 years ago
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.
follow-up: 15 comment:14 by , 16 years ago
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 by , 16 years ago
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 by , 16 years ago
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!
follow-up: 19 comment:17 by , 16 years ago
Please provide more testing to the suggested patch, otherwise, w/o better feedback we cannot make reasonable decisions on applicability of suggested fix!
follow-up: 24 comment:18 by , 16 years ago
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.
follow-up: 20 comment:19 by , 16 years ago
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
follow-up: 22 comment:20 by , 16 years ago
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 by , 16 years ago
I applied the patch in do_interrupt_protected(), and have built the kernel 3 times now with no problems.
follow-up: 23 comment:22 by , 16 years ago
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 by , 16 years ago
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 by , 16 years ago
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 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Summary: | FreeBSD 7.0-RELEASE sigreturn eflags → FreeBSD 7.0-RELEASE sigreturn eflags => fixed in SVN |
comment:26 by , 16 years ago
Thanks to everybody who participated in testing - you did important work here.
Log