fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Thu Feb 1 01:30:59 2007
> New Revision: 25667
>
> URL: http://svn.reactos.org/svn/reactos?rev=25667&view=rev
> Log:
> - Comment out clearing of KeLoaderBlock (introduced by 25629), because it looks like someone is still calling IopLoadServiceModule() even after that point. 2nd stage boots with this change.
>
This does not fix the freeze/slowdown/issue I am seeing with the NT
scheduler disabled. I still can't boot to desktop.
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Thu Feb 1 01:30:59 2007
> New Revision: 25667
>
> URL: http://svn.reactos.org/svn/reactos?rev=25667&view=rev
> Log:
> - Comment out clearing of KeLoaderBlock (introduced by 25629), because it looks like someone is still calling IopLoadServiceModule() even after that point. 2nd stage boots with this change.
>
>
I still get a hang after pressing "Next" on the last 2nd stage setup
wizard page.
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
Hi,
A few weeks ago, I received an e-mail asking me to test Burn, my old
drawing-program for Dos, on ReactOS. However, I've lost that e-mail
somehow, so I'm hoping this mailinglist is the right place to send my
reply, as a substitute. The original e-mail was from someone
affiliated with ReactOS.
I used ReactOS 0.3-RELEASE (Build 20060827-r23747), running under Qemu.
A screenshot of how it went is included. ("Bad command or filename",
even though the command was valid). Burn works perfectly well under
DosBox.
Hope this was of any help whatsoever, and thanks for your
contributions to the world of open source.
Best regards,
Alexander Rødseth
> Can't really fix this, this is a side effect of
> the fact that NT checks that the initial boot
> process didn't die, and the fact that our setup
> code actually replaces the initial process.
It can be fixed on process level, not on the kernel level.
http://www.superheterodyne.net/reactos/freelist_remove_type.diff
This removes the redundant notion of .Flags.Type in freelist, and leaves only
the non-redundant MM_PHYSICAL_PAGE_BIOS. MM_PHYSICAL_PAGE_FREE is reported
when the page has a 0 reference count and MM_PHYSICAL_PAGE_USED is reported
when the reference count is nonzero.
A function, MmGetPageType is added to replace the old functionality.
Init memory being freed seems to cause a lot of grief. I'm going to see if
there's a way to decentralize how those pages are set up, given that the
method used to dispose of them is spread out too.
--
Discordant is the murmur at such treading down of lovely things while
god's most lordly gift to man is decency of mind. Call that man only
blest who has in sweet tranquility brought his life to close.
If only I could act as such, my hope is good.
-- Aeschylus' Agamemnon (translated by H. W. Smyth)
This patch makes ReferenceCount include MapCount so we don't get into the
quite common situation where the balance manager wants to expel a mapped
section. I've been seeing this error running quite a number of things and
recently even in the first stage installer.
Lightly tested, probably wrong as usual.
http://www.superheterodyne.net/reactos/fix_page_reference.diff
--
Discordant is the murmur at such treading down of lovely things while
god's most lordly gift to man is decency of mind. Call that man only
blest who has in sweet tranquility brought his life to close.
If only I could act as such, my hope is good.
-- Aeschylus' Agamemnon (translated by H. W. Smyth)
Hi!
Look at the cmd line options! It did display the debug printout for the devices.
Cool, Kick A$$, Rosxor! Alex!
James
(ntoskrnl/kd/kdio.c:193) -----------------------------------------------------
(ntoskrnl/kd/kdio.c:194) ReactOS 0.4-SVN (Build 20070126-r25642)
(ntoskrnl/kd/kdio.c:195) Command Line: DEBUGPORT=COM1 NOGUIBOOT SOS
(ntoskrnl/kd/kdio.c:199) ARC Paths: multi(0)disk(0)rdisk(0)partition(1) \
multi(0)disk(0)rdisk(0)partition(1) \ReactOS\
(ntoskrnl/ke/i386/cpu.c:514) Not handling AMD caches yet
Used memory 1015744Kb
(ntoskrnl/se/semgr.c:36) FIXME: SeAccessCheck has been HACKED to always grant access!
(ntoskrnl/se/semgr.c:37) FIXME: Please fix all the code that doesn't get proper rights!
(ntoskrnl/ke/i386/kiinit.c:43) Large Page support detected but not yet taken advantage of!
WARNING: HaliQuerySystemInformation at hal/halx86/generic/sysinfo.c:26 is UNIMPLEMENTED!
(ntoskrnl/ke/i386/patpge.c:62) Advanced Memory features detected but not yet taken advantage of.
(ntoskrnl/ke/i386/mtrr.c:24) Your machine supports MTRR but ReactOS doesn't yet.
(ntoskrnl/io/iomgr/driver.c:908) Driver 'buslogic.sys' load failed, status (c0000001)
(ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1
(ntoskrnl/ldr/loader.c:259) Could not open module file: \SystemRoot\system32\drivers\mpu401.sys
(Status 0xc0000034)
(ntoskrnl/ldr/loader.c:259) Could not open module file: \SystemRoot\system32\drivers\sndblst.sys
(Status 0xc0000034)
(ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 10001
(ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1
(ntoskrnl/vdm/vdmmain.c:42) VME detected but not yet supported
(lib/fslib/vfatlib/vfatlib.c:215) VfatChkdsk() unimplemented!
(ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1f01ff
(ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1f01ff
(ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1f01ff
(ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1f01ff
*** Fatal System Error: 0x0000001e
(0x80000003,0x81022F94,0x00000000,0x00000000)
<ntoskrnl.exe:2891 (ntoskrnl/ke/bug.c:1078 (KeBugCheckEx))>
<ntoskrnl.exe:86b66 (ntoskrnl/ke/i386/exp.c:995 (KiDispatchException))>
<ntoskrnl.exe:8913b (ntoskrnl/ke/i386/trap.s:681 (CommonDispatchException))>
<81022F95>
