- Add a missing device node flag to legacy reported devices to avoid an assertion failure during installation
- The fact that this was exposed by a change in device node linking order terrifies me
svn path=/trunk/; revision=55926
- assert PDE ref count consistency everywhere
- fix the fix(tm) : after reference decrement, the maximum must not be reached
svn path=/trunk/; revision=55925
- Clean up code, fix memory leaks, check returns codes, add asserts
- Use root device handle which is is prerequisite for usb hub support
[USBLIB]
- Fix root hub handle checks
- Add more code for hub support
svn path=/trunk/; revision=55923
- Fix linking of device children to respect the enumeration order instead of linking in reverse enumeration order
- PCI cards (and other devices) now enumerate in the correct order
svn path=/trunk/; revision=55912
- Don't modify PCI configuration in AddDevice function
[USBEHCI]
- Don't halt the controller while the BIOS still has control of it
svn path=/trunk/; revision=55910
- Change MmDereferencePage to MmReleasePageMemoryConsumer to do proper page usage tracking
- Remove an unnecessary reference and dereference
svn path=/trunk/; revision=55897
- Fix formatting FAT or NTFS volumes into EXT2 by defining ZAP_BOOTBLOCK and fixing a bug in zap_sector()
[USETUP]
- Enable ext2 as an option in setup
- Formatting and building file copy list works but setup stalls shortly after starting to copy files (NewCC on)
svn path=/trunk/; revision=55896
- Fix several locking issues to better fit with RosMm
- Page out is critical as we use it now (shutdown) so force address space locking
- Fix an address space lock leak for VM regions
- Quiet some debugging and enable/change some other
- Still some lingering issues in page out exist which seem to be related to zefklop's PDE ref counting stuff and a weird one where we fault on the PFN database
- Besides the aforementioned issues, NewCC is surprisingly solid. I was able to boot to 3rd stage without a problem and run some apps.
svn path=/trunk/; revision=55895
1) MiCheckVirtualAddress should be called *after* determining if the PTE is a Demand Zero PTE. This is because when memory is allocated with MEM_RESERVE, and then MEM_COMMIT is called later, the VAD does not have the MemCommit flag set to TRUE. As such, MiCheckVirtualAddress returns MM_NOACCESS for the VAD (even though one is found) and the demand zero fault results in an access violation. Double-checked with Windows and this is the right behavior.
2) MiCheckVirtualAddress now supports non-commited reserve VADs (ie: trying to access MEM_RESERVE memory). It used to ASSERT, now it returns MM_NOACCESS so an access violation is raised. Before change #1, this would also happen if MEM_COMMIT was later performed on the ranges, but this is now fixed.
3) When calling MiResolveDemandZeroFault, we should not make the PDE a demand zero PDE. This is senseless. The whole point is that the PDE does exist, and MiInitializePfn needs it to keep track of the page table allocation. Removed the nonsensical line of code which performed cleard the PDE during a demand-zero fault.
I am able to boot to 3rd stage with these changes, so I have seen no regressions. Additionally, with these changes, the as-of-yet-uncommitted VAD-based Virtual Memory code completes 1st stage setup successfully, instead of instantly crashing on boot.
svn path=/trunk/; revision=55894
* The default build will continue to include all the localizations, but you can set it otherwise through a cmake variable (I18N_LANG) at configure time.
* Brought to you by Team Localization (Kamil Hornicek and Amine Khaldi) ;)
svn path=/trunk/; revision=55891
Disable tests that would hit asserts due to current work on VM. Requested functionality is missing and will be for some time.
svn path=/trunk/; revision=55888
[NTOS]: Do a more stringent check to refuse COPY_ON_WRITE flag sent through NtAllocateVirtualMemory.
[NTOS]: For VM-based Memory Areas, acquire and then release the process working set lock while inserting the VAD, to simulate what the VAD-based Virtual Memory behavior will look like.
[NTOS]: Disable paging for VM-based Memory Areas since this will not be supported with VADs.
[KERNEL32]: CopyLoop was requesting 2 zero bits when calling NtAllocateVirtualMemory. Not sure if this was really the intent or not, but both the new as well as the old NtAllocateVirtualMemory do not support this (the new one will ASSERT). Since this functionality never worked, request 0 bits instead to avoid hitting the ASSERT.
Any problems with what the VAD system will introduce should be revealed by now. From this build until the one which will have the VAD-based system in place, no further VM-related issues should crop up.
svn path=/trunk/; revision=55885
