Why do you have to be this way? I gave you a link to 3 PDFs and our
own Wiki that explain these functions. Did you even read them?
Don't be an asshole just for fun.
Best regards,
Alex Ionescu
On Sun, Jul 3, 2011 at 1:11 AM, <tkreuzer(a)svn.reactos.org> wrote:
> Author: tkreuzer
> Date: Sat Jul 2 23:11:06 2011
> New Revision: 52507
>
> URL: http://svn.reactos.org/svn/reactos?rev=52507&view=rev
> Log:
> [NTOSKNRL]
> - Change an ASSERT to a KeBugCheck, since the assertion can fail for any invalid memory access and this is not an internal Mm failure.
> - Remove 2 cases, that "Should NEVER happen on ARM3!!!", but can very well happen.
> - Do NOT make the code cleaner, by releasing the PFN lock in the same function that acquires it, but keep it 2 functions down. This is because it *SHOULD* be that way, since some internal undocumented functions, that we do not implement but that are (theoretically) called from here, also do release the PFN lock. Thanks Alex for explaining this.
>
> Modified:
> trunk/reactos/ntoskrnl/mm/ARM3/pagfault.c
>
> Modified: trunk/reactos/ntoskrnl/mm/ARM3/pagfault.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/pagfault.…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/mm/ARM3/pagfault.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/mm/ARM3/pagfault.c [iso-8859-1] Sat Jul 2 23:11:06 2011
> @@ -583,10 +583,19 @@
> }
>
> //
> - // The PTE must be invalid, but not totally blank
> + // The PTE must be invalid
> //
> ASSERT(TempPte.u.Hard.Valid == 0);
> - ASSERT(TempPte.u.Long != 0);
> +
> + /* Check if the PTE is completely empty */
> + if (TempPte.u.Long == 0)
> + {
> + KeBugCheckEx(PAGE_FAULT_IN_NONPAGED_AREA,
> + (ULONG_PTR)Address,
> + StoreInstruction,
> + (ULONG_PTR)TrapInformation,
> + 2);
> + }
>
> //
> // No prototype, transition or page file software PTEs in ARM3 yet
> @@ -727,11 +736,6 @@
> // Writing to a read-only page (the stuff ARM3 works with is write,
> // so again, moot point).
> //
> - if (StoreInstruction)
> - {
> - DPRINT1("Should NEVER happen on ARM3!!!\n");
> - return STATUS_ACCESS_VIOLATION;
> - }
>
> //
> // Otherwise, the PDE was probably invalid, and all is good now
> @@ -776,11 +780,6 @@
> // Writing to a read-only page (the stuff ARM3 works with is write,
> // so again, moot point.
> //
> - if (StoreInstruction)
> - {
> - DPRINT1("Should NEVER happen on ARM3!!!\n");
> - return STATUS_ACCESS_VIOLATION;
> - }
>
> /* Release the working set */
> MiUnlockWorkingSet(CurrentThread, WorkingSet);
>
>
>
Hello,
Last thursday of this month is quite close, 30th of June, 20:00 UTC
I'm awaiting you all for the monthly status meeting. Colin said that
our private irc server is going to be ready by that date, so if
that's still true, Colin - could you please provide details for those
who don't remember where to connect?
Proposed agenda is:
1. New release of ReactOS
2. Website work status
3. GSoC status
4. Developers status.
With the best regards,
Aleksey Bragin.
I'm definitely not sure that the header[1] added to all converted files was absolute necessity.
AFAIK, that's SVN logs purpose...
Unless someone has a real justification to such line?
Many files even don't have a translator copyright but this line... Weird!
[1]: /* UTF-8 Conversion: Elton Chung aka MfldElton <elton328(a)gmail.com> (June, 2011) */
Hi Erik,
The NDK is for *undocumented* types. These flags are documented.
--
Best regards,
Alex Ionescu
On 2011-06-26, at 7:29 AM, ekohl(a)svn.reactos.org wrote:
> CM_RESOURCE_INTERRUPT_LEVEL_SENSITIVE
Hello,
as all of you could notice, I committed the LDR rewrite recently. I
tried to get rid of as much regressions as possible (any rewrite
should introduce improvements of course, rewrites are not done to
introduce regressions, however there is no rewrite without some
particulars problems).
So, dear developers, I need your help. Gabriel did a very nice work
and bugzilled all kinds of problems which new LDR introduced. Here is
the meta-bug:
http://www.reactos.org/bugzilla/show_bug.cgi?id=6346
Please look into the bugs, check something and add your findings to
bugzilla. The new LDR code is perfectly organized, very well
documented, so most of those bugs should be quite simple to fix, but
my time is not infinite, so I'm asking for collaboration. I'm always
available via IRC for any questions about the new code, so feel free
to ask.
Put away your usual stuff for an hour or for a day and look into
those. It would help greatly and motivate me to finish other parts of
the rewrite quicker.
Thanks,
Aleksey Bragin.
Hi sir_richard and welcome back!
Just to make sure you know, it seems this commit introduces a regression, ros hangs while loading ndis.sys, see testbot logs:
http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/1342/s…
I've filed http://www.reactos.org/bugzilla/show_bug.cgi?id=6292
Could you please take a look?
Thanks.
> Date: Sun, 5 Jun 2011 20:48:34 +0000
> To: ros-diffs(a)reactos.org
> From: sir_richard(a)svn.reactos.org
> Subject: [ros-diffs] [sir_richard] 52098: [FREELDR]: Some ARM architectures do not necessarily have CS0_BASE at 0x00000000, for example, most Ti OMAP Platforms have DDR at 0x80000000. The current FreeLDR algorithms wou...
>
> Author: sir_richard
> Date: Sun Jun 5 20:48:34 2011
> New Revision: 52098
>
> URL: http://svn.reactos.org/svn/reactos?rev=52098&view=rev
> Log:
> [FREELDR]: Some ARM architectures do not necessarily have CS0_BASE at 0x00000000, for example, most Ti OMAP Platforms have DDR at 0x80000000. The current FreeLDR algorithms would build FreeLDR "page entries" for every page from 0 to 0x7FFF0000 and mark it as unusable, then build the actual valid entries from 0x80000000 -> end of RAM, thus resulting in large memory consumption (and in the bloat of the PFN database later once NTOS loads) and boot time. Therefore, the algorithm is changed to start the PFN database at the lowest valid RAM page described by the Firemware descriptors, and entries therefore will be offset. This means a 128MB embedded system no longer appears to have 2048+128MB of RAM worth of PFN entries.
> NOTE: Windows does not do this, opting instead to force manufacturers/use pull-up resistors/reconfigure the ARM Bus to map RAM at 0x00000000. For wider portability, I believe it makes more sense to simply do this "trick" in the boot loader.
>
> Modified:
> trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c
> trunk/reactos/boot/freeldr/freeldr/mm/meminit.c
>
Hi,
I'd like to change the Vtbl based architecture of freeldr into a normal
function call system.
Currently we have stuff like
#define MachHwDetect() MachVtbl.HwDetect()
MachVtbl.HwDetect = PcHwDetect;
This is IHO simply useless, since these functions don't change. I
suggest simply renaming PcHwDetect to MachHwDetect and do that will all
of those and get rid of the MachVtbl.
Any objections?
Regards,
Timo