I have an operating system that is hardly modified from this: https://github.com/arjun024/mkeykernel. In fact for testing, I am using EXACTLY that. It is only a few hundred lines! Sadly, it keeps crashing with the following: VCPU0: Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT).
Virtualbox 5.1.18
AmdFX 8350 CPU
I have modified a few settings; most don't seem to have an effect on anything but I notice a change in behavior whenever I modify the Enable VT-x/AMD-V option. Whenever this option is enabled, the operating system crashes IMMEDIATELY upon, boot, with this error. Whenever it is disabled, we get the error above. I've heard that this triple_fault may (in the past?) have been occurring ONLY on AMD FX CPU's, so for brevity I have included the log file only for when this option is disabled; if anyone wants the other one please let me know.
300 Line operating system: Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT)
-
- Posts: 3
- Joined: 27. Jul 2017, 18:50
300 Line operating system: Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT)
- Attachments
-
- brief.log
- (15.08 KiB) Downloaded 76 times
Last edited by socratis on 27. Jul 2017, 19:48, edited 1 time in total.
Reason: Fixed obfuscated URLs.
Reason: Fixed obfuscated URLs.
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: 300 Line operating system: Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT)
Partial logs are not of use. Please zip and attach complete logs only.
Triple fault exceptions are AFAIK always caused by bad code in the VM, e.g. attempts to execute an illegal or privileged instruction, often when VT-x is not enabled (VT-x mode traps a greater range of bad behaviours than software traps can).
Triple fault exceptions are AFAIK always caused by bad code in the VM, e.g. attempts to execute an illegal or privileged instruction, often when VT-x is not enabled (VT-x mode traps a greater range of bad behaviours than software traps can).
-
- Posts: 3
- Joined: 27. Jul 2017, 18:50
Re: 300 Line operating system: Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT)
Hmm, thank you.
(Perhaps I'll contact the author if I can find something on github.)
Can you possibly recommend and tools I could use to try to isolate this problem?
(Perhaps I'll contact the author if I can find something on github.)
Can you possibly recommend and tools I could use to try to isolate this problem?
- Attachments
-
- VBox.log.zip
- (35.65 KiB) Downloaded 68 times
-
- Site Moderator
- Posts: 34369
- Joined: 6. Sep 2008, 22:55
- Primary OS: Linux other
- VBox Version: OSE self-compiled
- Guest OSses: *NIX
Re: 300 Line operating system: Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT)
I seriously doubt that you will ever get the kernel to load with only 4MB of memory assigned to the guest.RamSize <integer> = 0x0000000000400000 (4 194 304, 4 MB)
-
- Posts: 3
- Joined: 27. Jul 2017, 18:50
Re: 300 Line operating system: Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT)
Incrementally increasing the memory up to 512 has no effect on the behavior.
Also, if I failed to mention this earlier, the system runs just fine under QEMU. I'm ready to start commenting out lines and seeing which line actually triggers the fault.
I found I can avoid this condition in several ways. One, after I initialize the PICS is to simply never re-enable interrupts as doing so appears to have to potential to crash the thing immediately. The other one is to never enable any of the IRQ lines with the first operational code. The second one is if I comment out sti, and never enable interrupts. I seem to be sending the operational codes to the pics AFTER I enable interrupts, should I not do that for some reason? So I guess this question becomes is.. why does this crash the moment I enable interrupts? Is there some error in initialization? Again the source code was avialable from a link the first post, and while I would be happy to dice out the IRQ stuff, there is so little of the other stuff I'm not sure restricting information would be helpful. Thanks.
Also, if I failed to mention this earlier, the system runs just fine under QEMU. I'm ready to start commenting out lines and seeing which line actually triggers the fault.
I found I can avoid this condition in several ways. One, after I initialize the PICS is to simply never re-enable interrupts as doing so appears to have to potential to crash the thing immediately. The other one is to never enable any of the IRQ lines with the first operational code. The second one is if I comment out sti, and never enable interrupts. I seem to be sending the operational codes to the pics AFTER I enable interrupts, should I not do that for some reason? So I guess this question becomes is.. why does this crash the moment I enable interrupts? Is there some error in initialization? Again the source code was avialable from a link the first post, and while I would be happy to dice out the IRQ stuff, there is so little of the other stuff I'm not sure restricting information would be helpful. Thanks.
Last edited by vegetarian-stoat on 29. Jul 2017, 10:07, edited 1 time in total.
Re: 300 Line operating system: Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT)
The author (developer) makes no claims or statements whatsoever that this can be run in a virtualised environment, only in an emulated environment (QEMU) for which he gives directions.
Perhaps ask him if it is possible, and if so "How?". Personally, I doubt if he has tested that scenario yet, or he would probably have said so in his blog.
Perhaps ask him if it is possible, and if so "How?". Personally, I doubt if he has tested that scenario yet, or he would probably have said so in his blog.
-
- Oracle Corporation
- Posts: 2973
- Joined: 19. Dec 2007, 15:45
- Primary OS: MS Windows 7
- VBox Version: PUEL
- Guest OSses: Any and all
- Contact:
Re: 300 Line operating system: Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT)
That means very little. Does it also run on VMware? Hyper-V? Real hardware?vegetarian-stoat wrote:Also, if I failed to mention this earlier, the system runs just fine under QEMU.
Think about it. You have interrupts enabled and then you start reprogramming the interrupt controller? Does that sound like a good idea to you? It sounds like a recipe for disaster to me.I seem to be sending the operational codes to the pics AFTER I enable interrupts, should I not do that for some reason?
Re: 300 Line operating system: Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT)
Line 983 of the logs:
0:00:04.230734 CPUM: 0010:001002ff eb fe jmp -002h (0001002ffh)
This indicates the faulting instruction. The jmp instruction is jumping back 2 bytes, and the processor isn't happy about it.
Look for a jmp instruction at 0x2ff (relative to the code start that) loops to itself, eg:
The problem could be before or immediately following this instruction.
If memory is getting initialized at this point (page tables, etc.) memory may not be in the expected state.
The second question you'll have to answer is, why did the software attempt to execute an infinite loop?
Has everything else been done, or is this a 'panic' scenario?
0:00:04.230734 CPUM: 0010:001002ff eb fe jmp -002h (0001002ffh)
This indicates the faulting instruction. The jmp instruction is jumping back 2 bytes, and the processor isn't happy about it.
Look for a jmp instruction at 0x2ff (relative to the code start that) loops to itself, eg:
Code: Select all
WAIT_FOREVER:
JMP WAIT_FOREVER:
If memory is getting initialized at this point (page tables, etc.) memory may not be in the expected state.
The second question you'll have to answer is, why did the software attempt to execute an infinite loop?
Has everything else been done, or is this a 'panic' scenario?
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: 300 Line operating system: Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT)
Given that it's a triple fault (i.e. there are two faults before the one which stopped the VM), I would think that the reported fault address is inside one of the previous fault handlers, in which case the infinite loop would be normal. The original fault remains a mystery.