After r41859 installation in vmware (6.5) does not work.
Log:
(ntoskrnl\kd\kdio.c:220)
-----------------------------------------------------
(ntoskrnl\kd\kdio.c:221) ReactOS 0.4-SVN (Build 20090711-r41859)
(ntoskrnl\kd\kdio.c:222) Command Line: NOGUIBOOT DEBUGPORT=COM1
NOGUIBOOT DEBUGPORT=COM1
(ntoskrnl\kd\kdio.c:223) ARC Paths: multi(0)disk(0)cdrom(159) \
multi(0)disk(0)cdrom(159) \reactos\
Used memory 523828Kb
(ntoskrnl\mm\mminit.c:183) Start End Type
(ntoskrnl\mm\mminit.c:184) 0x80000000 - 0x80E00000 Boot Image Mapping
Region
(ntoskrnl\mm\mminit.c:187) 0x80E00000 - 0x81100000 PFN Database region
(ntoskrnl\mm\mminit.c:190) 0x81100000 - 0x87500000 Non paged pool region
(ntoskrnl\mm\mminit.c:193) 0x87500000 - 0x8D900000 Paged pool region
(ARM³::INIT:504) 0xB0000000 - 0xB0300000 Shadow PFN Database
(ARM³::INIT:509) 0xB0300000 - 0xB1318000 ARM Non Paged Pool
(ARM³::INIT:583) 0xF3400000 - 0xF8BF8000 System PTE Space
(ARM³::INIT:586) 0xF8BF8000 - 0xFFBE0000 Non Paged Pool
Expansion PTE Space
(ARM³::POOL:265) Out of NP Pool
(ARM³::POOL:393) Start of of initial frame
(ARM³::POOL:332) End of initial frame
[7hEntered debugger on last-chance exception (Exception Code:
0xc0000005) (Page Fault)
Memory at 0x00000000 could not be written: Page not present.
kdb:> bt
Eip:
<b0309000>
Frames:
<00000000>
kdb:>
--
WBR,
Dmitry Chapyshev
hyperion(a)svn.reactos.org wrote:
> Author: hyperion
> Date: Thu Jul 9 00:32:50 2009
> New Revision: 41815
This should fix the bug exposed by ARM3 and hackfixed by hto (see
#4663). I was in a hurry when I committed and I forgot to thank Stefan
for providing the regression test that was fundamental to fixing both
this issue and the previous PSEH2 bug
On the other hand, this PSEH bug has locked up our buildbot for a
considerable amount of time. I have no intention to promote hacking or
hiding bugs, on the other hand though, the longer we run without debug
buildbot, the more regressions and other problems are potentially going
unnoticed. This was my major concern over so called MDL probe or as we now
know - PSEH2 bug issue.
I decided to make this as a separate post, though it's a follow up to
the previous one.
I would like to set, officially, a couple of simple code hacking
rules, which are going to apply immediately for the NTOSKRNL module,
and to other modules after discussion/acceptance. They apply only to
committers (which commit their own or someone else's patches).
1. If you change someone's code, and believe it's a correct change -
go ahead and commit.
2. If you need to add a hack to someone's code, and:
2.1. you want to either hack or revert the offending commit which
breaks booting: This is allowed only after 24hrs after trying to
contact the author / posting to the ros-dev mailing list about the
problem.
2.2. you want to either hack or revert the offending commit which
contains a certain regression but doesn't cause important
consequences like inability to install the OS, or major loss of
functionality: This is allowed only from permission of author of the
code which you want to hack or, as alternative, from my permission.
I think this way we can get some order into the coming commits flow,
which is hard to track.
Also, please comment on this, so that we can alter those rules and
maybe accept them for all modules.
Thanks for understanding,
Aleksey Bragin.
This looks hackish
It also breaks the log as you're potentially returning something different from what the log states
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of cgutman(a)svn.reactos.org
Sent: 06 July 2009 08:54
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [cgutman] 41783: - Fix return value of tdiGetMibForIfEntity so it doesn't return a failure status on success
Author: cgutman
Date: Mon Jul 6 11:54:28 2009
New Revision: 41783
URL: http://svn.reactos.org/svn/reactos?rev=41783&view=rev
Log:
- Fix return value of tdiGetMibForIfEntity so it doesn't return a failure status on success
Modified:
trunk/reactos/dll/win32/iphlpapi/ifenum_reactos.c
Modified: trunk/reactos/dll/win32/iphlpapi/ifenum_reactos.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/iphlpapi/ifenum_…
==============================================================================
--- trunk/reactos/dll/win32/iphlpapi/ifenum_reactos.c [iso-8859-1] (original)
+++ trunk/reactos/dll/win32/iphlpapi/ifenum_reactos.c [iso-8859-1] Mon Jul 6 11:54:28 2009
@@ -280,7 +280,7 @@
entry->ent.if_descr);
TRACE("} status %08x\n",status);
- return status;
+ return STATUS_SUCCESS;
}
NTSTATUS tdiGetEntityIDSet( HANDLE tcpFile,
Uhm, why hack the kernel again? Testing on the buildbot was fixed to
accept this, so there is no urge. I was just trying to help RPG to
find the issue, along with vmware/vbox video drivers regression, due
to a MmMapIoSpace(128Mb) call.
Please read the next email.
WBR,
Aleksey.
On Jul 6, 2009, at 10:28 PM, dgorbachev(a)svn.reactos.org wrote:
> Author: dgorbachev
> Date: Mon Jul 6 22:28:11 2009
> New Revision: 41788
>
> URL: http://svn.reactos.org/svn/reactos?rev=41788&view=rev
> Log:
> "Fix" MDL PROBE FAILED! bug #4663.
jimtabor(a)svn.reactos.org schrieb:
> Author: jimtabor
> Date: Sun Jul 5 06:21:35 2009
> New Revision: 41776
>
> URL: http://svn.reactos.org/svn/reactos?rev=41776&view=rev
> Log:
> - Implement the client shutdown procedure. Tested with wine user32 msg undocumented 0x3B tests. Wine tests: msg: 6175 tests executed (0 marked as todo, 937 failures), 5 skipped.
> - Add missing end session types.
> - Reference: winproc.c WM_CLIENTSHUTDOWN http://wiki.winprog.org/wiki/Windows_messages
>
> [...]
>
> + List = IntWinListChildren(pWindow);
>
Oh, how I loathe this function.
It walks through the chain of windows to count them, allocates a buffer
from paged pool. Walks through the chain again, fills the buffer with
the windows' handles and returns the buffer so that the calling function
can walk through the buffer and use the handles to query the pointers to
the windows again. And this all happens while holding the global user lock.
Hint: you can remove 11 lines of code and change 2 lines and get the
same result, only faster.
Regards,
Timo
On Fri, Jul 3, 2009 at 5:53 AM, <dchapyshev(a)svn.reactos.org> wrote:
> - if (-1 == (int) Res || ! Res)
> - {
> - return Res;
> + if (-1 == (int) Res || !Res)
> + {
> + return FALSE;
I know you didn't write the check and were just changing the return
values but as a matter of style could we do something like
if (((int) Res || !Res) == -1)
or would the extra parens mess up the order of operations? Not a big
deal, its just easier on my eyes.
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
I think we all agree that the process of filling out a changelog is a task
we would rather avoid.
Collibri has made some efforts to alleviate this and despite getting some
good results we're also seeing a lot of information which isn't changelog
oriented. This now leaves us with a new problem of having to manually go
through data output from Collibri's tool and reformat it.
This is arguably more time consuming than the original method and isn't
working for us in its current form.
The current problem with this method is that a commit log is not a changelog
and getting something which can be classed as a changelog from this without
human intervention is an impossible task. There are also some people who
would rather write their own changelog instead of allowing a tool to
generate it for you.
The problem as I see it is two fold :
- Commit messages generally contain cryptic message, humour, idioms
and frustration
- Patches can spread over a wide range of modules making it
difficult to insert them into the correct position in the changelog.
A possible solution to this is to wrap up a changelog in XML elements. Such
a commit log would be as follows :
............................................................................
..........................
- Stop mixing unicode and ANSI strings
- Don't dereference NULL pointers
<changelog>
<notepad>Converted the application to Unicode</notepad>
<user32>Fixed a crash highlighted via adobe acrobat</user32>
</changelog>
............................................................................
..........................
This will allow anyone who wants to have a changelog autogenerated at
release time to take advantage and anyone who wants to do their own to
ignore it.
The problem with this method lies in getting the XML tags correct.
Anyone have any other ideas?
Ged.
Sorry for not deleting the post content:/
Back to sysreg... i`d issue a deadline, like 24-48h and until then i`d lock
the trunk. If this issue is not fixed until the deadline, offending revision
should be reverted and trunk unfrozen.
I can only hope we arent getting many regressions in the meantime.
Hi all,
As talked with Aleksey i would want to let you knwo that revision r41685 is
broken, in my real hardware, at least.
This is the log i get, im sorry to say i cannot give you more details
(backtraces, disasm´s, and so, since even kb does not work after the crash.
(ntoskrnl/kd/kdio.c:221) ReactOS 0.4-SVN (Build 20090629-r41685)
(ntoskrnl/kd/kdio.c:222) Command Line: NOGUIBOOT DEBUGPORT=COM1 NOGUIBOOT
DEBUGPORT=COM1
(ntoskrnl/kd/kdio.c:223) ARC Paths: multi(0)disk(0)cdrom(159) \
multi(0)disk(0)cdrom(159) \reactos\
Used memory 327284Kb
(ntoskrnl/mm/mminit.c:224) Start End Type
(ntoskrnl/mm/mminit.c:225) 0x80000000 - 0x80800000 Undefined region
(ntoskrnl/mm/mminit.c:228) 0x80800000 - 0x80E00000 FreeLDR Kernel
mapping region
(ntoskrnl/mm/mminit.c:231) 0x80E00000 - 0x80FE0000 PFN Database region
(ntoskrnl/mm/mminit.c:238) 0x80FE0000 - 0x873E0000 Non paged pool
region
(ntoskrnl/mm/mminit.c:241) 0x873E0000 - 0x8D7E0000 Paged pool region
(ARM³::INIT:340) System PTE count has been tuned to 22000 (90112000 bytes)
(ARM³::INIT:445) NP Pool has been tuned to: 10584064 bytes and 130072576
bytes
(ARM³::INIT:490) System PTE VA starts at: F3000000
(ARM³::INIT:491) NP Expansion VA begins at: F89EC000 and ends at: FFBE0000
(ARM³::INIT:507) PFN DB VA begins at: B0000000 and ends at: B01E0000
(ARM³::INIT:510) PFN DB PA PFN begins at: 1000
(ARM³::INIT:511) NP VA begins at: B01E0000 and ends at: B0BF8000
(ARM³::INIT:514) NP PA PFN begins at: 11e0
(ARM³::SYSPTE:341) System PTE space for 1 starting at: C03E27B4 and ending
at: C03FEF78
Assertion '(MmNumberOfSystemPtes - OldCount) <= 1000' failed at ARM³::INIT
line 652
Entered debugger on embedded INT3 at 0x0008:0x808bfcf6.
kdb:>
On Wed, Jun 24, 2009 at 10:43 PM, <tkreuzer(a)svn.reactos.org> wrote:
> - user32_winetest sysparams: before: 634 executed / 235 failures, after:
> 1093 executed, 11 failures
>
Very impressive.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and that is
an idea whose time has come." - Victor Hugo