can't boot ReactOS live Cd #115

Closed
jeditobe opened this Issue Oct 8, 2016 · 17 comments

Projects

None yet

3 participants

@jeditobe
jeditobe commented Oct 8, 2016

can't boot ReactOS live Cd

all details including debug logs are here
https://jira.reactos.org/browse/CORE-8803

looks like a bug in copy/v86

@jeditobe
jeditobe commented Oct 8, 2016 edited

livecd-72944-dbg

WARNING:  HvpWriteLog at sdk/lib/cmlib/hivewrt.c:29 is UNIMPLEMENTED!
(ntoskrnl/mm/ARM3/sysldr.c:176) Loading: \SystemRoot\System32\ftfd.dll at F824F000 with 11c pages
(drivers/filesystems/cdfs/fsctl.c:608) CDFS: IRP_MN_VERIFY_VOLUME
(drivers/filesystems/cdfs/fsctl.c:499) Device object B10B9B18  Device to verify B10BB038
(drivers/filesystems/cdfs/fsctl.c:508) Same volume!

*** Assertion failed: (KiVdmTrap(TrapFrame)) == FALSE
***   Source File: /srv/buildbot/Build_GCCLin_x86/build/ntoskrnl/ke/i386/traphdlr.c, line 1302

Break repeatedly, break Once, Ignore, terminate Process or terminate Thread (boipt)? 
kdb:> bt
Execute '.cxr F824D9A4' to dump context
�[7h�
Entered debugger on embedded INT3 at 0x0008:0x809414be.
kdb:> bt
Eip:
<NTOSKRNL.EXE:1414bf (:0 (DbgBreakPoint))>
Frames:
<NTOSKRNL.EXE:125a40 (ntoskrnl/ke/i386/traphdlr.c:1302 (KiTrap0EHandler))>
<NTOSKRNL.EXE:36ac (:0 (KiTrap0E))>
<NTOSKRNL.EXE:2924 (:0 (Ki386SetupAndExitToV86Mode))>
<f000e2c3>
Couldn't access memory at 0xF000FF57!
kdb:> 
@copy
Owner
copy commented Oct 11, 2016

I can confirm this bug.

@copy copy added the bug label Oct 11, 2016
@jeditobe

I this bug hard to fix? ReactOS team could work on it together with you!
Join us in mail-list or irc-chat

@copy copy self-assigned this Oct 31, 2016
@copy
Owner
copy commented Nov 11, 2016

@jeditobe I'm looking into this issue, it's hard to say right now.

Could you provide a cdrom image with more debugging enabled? I'm especially interested in cdrom/ide/atapi. It looks like some interrupts are being missed.

@jeditobe

ok, i will try.

@jeditobe

https://yadi.sk/d/sgwp3ZFvzKa37 - livecd-r73357-Uniata-debug
uniata is a driver for IDE\SATA devices

@jeditobe

If this is not enough, please join our irc chat and ask the developers to help you.

https://webchat.freenode.net/
#reactos and #reactos-dev rooms

@jeditobe

https://yadi.sk/d/5brp7-gMzKyYR - livecd-73358-atapi-cdfs-scsiport-debug.iso

@copy
Owner
copy commented Nov 27, 2016

If this is not enough, please join our irc chat and ask the developers to help you.

https://webchat.freenode.net/
#reactos and #reactos-dev rooms

Thanks for the offer, I will certainly use it if I need help. For now, I believe the issue is closely related to the emulator. Thanks for the images, too!

@copy copy added a commit that referenced this issue Nov 28, 2016
@copy Check non-conforming cs correctly, #115 4e287a4
@copy copy added a commit that referenced this issue Nov 28, 2016
@copy Fix sample rate for reactos, #115 f43ed23
@copy
Owner
copy commented Nov 28, 2016

I've found and fixed the issue, you can try it online now. It takes rather long to boot (about 15 minutes) and there are still a few issues related to disk controller emulation, but overall it works quite nicely.

I'll upload an image (with fast boot) to the website at a later point, for now feel free to test and let me know if you still encounter any bugs.

@copy copy closed this Nov 28, 2016
@jeditobe
jeditobe commented Nov 28, 2016 edited

Yes, i confirm, it is working, but it took for me around 25m to boot to desctop.

Thanx a lot for help!!

hope, you will fix soon few issues related to disk controller emulation.

@jeditobe

Our devs want to have some explanation about recent fixes:

The last commit shows that something looks wrong in our ps/2 driver, then!! The first one seems a bit strange. It would be interesting to know exactly why it's needed. jedi-to-be, could you please ask those guys why this is needed?

@copy
Owner
copy commented Dec 3, 2016

The last commit shows that something looks wrong in our ps/2 driver, then!!

Yep, this is probably a bug, the sample rate is set to 0.

The first one seems a bit strange. It would be interesting to know exactly why it's needed. jedi-to-be, could you please ask those guys why this is needed?

I debugged this in detail, here's a log: https://copy.sh/temp/reactos-v86.log

  1. There's a system call: int 0x30 start (line 1)
  2. Then it switches to vm86 mode (line 13)
  3. Then it makes a bios call (int 0x10, something related to graphics) (line 14). I think this is Ke386CallBios
  4. The bios makes some page faults and protection faults, which are fine
  5. Then the bios returns using iret (line 78)
  6. Then a weird thing happens: React OS tries to make this iret: mode=prot/32 paging=1 vm=0 iopl=0 cpl=3 if=1 cs:eip=0x000B:0x80802929 flgs=0x286 ss:esp=0x0023:0x00011FFE ssize=1. It's weird, because it jumps to code in kernel space but puts the cpu in user mode and the stack is the stack from vm86 mode.
  7. It immediately page faults and the assertion in the page fault handler fails

The fix causes the iret in step 6. to fail immediately, and then everything is fine. Hope this helps.

By the way, if you experience random faults while testing reactos, this is caused by random disk reads failing. I'm still looking into this.

@paulsapps

Seems strange this bug is marked closed! Nice work @copy

@jeditobe
jeditobe commented Dec 5, 2016

Timo Kreuzer:

The IRET is supposed to return in v86 mode, to the trapoline code, and then execute the BOP instruction, which would then exit to the kernel's fault handler in protected mode. Making the IRET fail is a hack.

HBelusca:

But then, who is wrong there? Does the CPU emulation of v86JS have a bug, or do we have a bug in our v86 code?

Timo Kreuzer:

The bug is in the emulator. It should stay in v86 mode and resume execution at the BOP.

@copy
Owner
copy commented Dec 5, 2016

The IRET is supposed to return in v86 mode, to the trapoline code, and then execute the BOP instruction, which would then exit to the kernel's fault handler in protected mode. Making the IRET fail is a hack.

The bug is in the emulator. It should stay in v86 mode and resume execution at the BOP.

There's no hack, everything is implemented according to Intel's manuals.

The first iret (from the bios) is supposed to cause a protection fault because iopl < 3. Note that the emulator doesn't support VME, which might be relevant here.

The second iret (from React OS) causes a protection fault because it's invalid: The CS dpl is 0, but the rpl is 3 and it's marked non-conforming. The iret also makes no sense for other reasons (for example, the stack is also invalid).

I would suggest you to check the behaviour in other emulators. Currently the observable behaviour seems to be the same in this emulator and QEMU (modulo the IDE bug, which I haven't fixed yet).

@jeditobe If this discussion goes on, could you provide me a JIRA account so we can discuss this more directly?

@jeditobe
jeditobe commented Dec 6, 2016

@copy
Just register here https://www.reactos.org/user/register than wait 30 minutes and use the same login and password for jira

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment