boot regressions

[Steven Edwards]

Hi,
I've not had a chance to dig in and see which changeset caused the
issue but since the recent bringup changes I can no longer use the
bootcd on Parallels.

-- 
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

[Alex Ionescu]

This was fixed for initial boot, but a problem still remains.

Basically now the ARM guys allocate PTEs from "free" memory. This  
works fine, but crashed once the mapping for the PFN database (page  
array) exceeded 4MB, because that required another PDE. To get a PDE,  
the system tried to allocate a PTE to describe it, and crashed (that's  
what you see now).

However, it's not a complete fix -- they didn't think of reboots.  
After a reboot, the 4KB area describing the PDE itself is full of  
"Dirty" data.

They need to clean that area in MmAllocEarlyPage, just like  
MmAllocPage does (MiZeroPage).

However zeroing will require hyperspace mappings, and I don't think  
those work early-on.

Your bigger problem is that 0xC0000000 (PDE_BASE) is only setup much  
later. On NT, it's setup as one of the first things, and that allows  
the kernel to

1) Map PDEs for the PFN Database from the free memory descriptor  
(which reactos kind of does now)
2) Map those PDEs into the PDE_BASE views (versus Hyperspace) (which  
reactos can't do, I think -- or maybe it can?)
3) Zero the PDEs (ReactOS can't do this because of #2)
4) Then later, it allocates PTEs for the PFN database based on the  
descriptors (ReactOS does this).

If you find a way to map & zero the PDEs, it'll work.

Alternatively, you can cheat. You know the PFN database will be at  
most describing 4GB of physical memory, which is a million entries in  
the database. Each PHYSICAL_PAGE structure is 20 bytes, so 20MB is the  
largest possible size of the PFN database on a 32-bit system.

Simply have FreeLDR setup the page tables for 24MB instead of 6MB like  
it does now.

Then you don't even need to allocate pages to hold the PFN database,  
and all your problems go away.

I'll be in California, Seattle, UK And then Toronto for the next 3  
weeks, so good luck.

On 15-Feb-08, at 6:52 PM, Steven Edwards wrote:

>   <crash.rtf> 
Best regards,
Alex Ionescu