Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Windows › Windows XP Ram Limit
New Posts  All Forums:Forum Nav:

Windows XP Ram Limit - Page 6

post #51 of 100
What about the following scenario:
Fill the GPU VRam completely with - lets say texture data. Then fill it even more - the GPU needs to purge some of the loaded textures out of VRAM.
When it needs to access some of the textures that were loaded first - wouldn't it need to access textures from the "CPU's RAM" then?
Wouldn't it use DMA in such a case? <- Edit:not necessarily
I can't imagine that the CPU is responsible to shuffle those missing textures back into VRAM via Memory Mapped IO.
I would expect this to happen via DMA triggered by the GPU.

Edit: Found an interesting article:
http://www.songho.ca/opengl/gl_pbo.html

Seems like both is possible, loading textures via DMA and copying by CPU.
Unfortunately the conventional way to load textures seems to be the latter (by CPU). Therefore FillRateTest does not help us in benchmarking what we want (DMA). Maybe this could be benchmarked by using the PBO-technique described in the article.

Texture loading without PBO
The source is first loaded into the system memory, and then, copied from the system memory to an OpenGL texture object with glTexImage2D(). These 2 transfer processes (load and copy) are all performed by CPU.

Texture loading with PBO
On the contrary in the right side diagram, the image source can be directly loaded into a PBO, which is controlled by OpenGL. CPU still involves to load the source to the PBO, but, not for transferring the pixel data from a PBO to a texture object. Instead, GPU (OpenGL driver) manages copying data from a PBO to a texture object. This means OpenGL performs a DMA transfer operation without wasting CPU cycles. Further, OpenGL can schedule an asynchronous DMA transfer for later execution. Therefore, glTexImage2D() returns immediately, and CPU can perform something else without waiting the pixel transfer is done.

Do you think the demo application may help us to measure the impact of the HAL modification?
If you agree, I would benchmark this with the 3 configurations again.
Edited by achm3t - 3/21/14 at 9:58am
post #52 of 100
Hi peeps~

thanks for your help!

i'm working on win xp sp2 actually, not just for fun but cause firewire works best here for me and the system somehow is zippier than xp sp3.


i took usbport.sys from server 2003 sp2 and replaced
i patched my own ntkrnlpa.exe like this (searching for string and editing it, not looking for some offset):
Original : BB 00 00 10 00 33 FF 6A 07 8B F0
Modify To : BB 00 00 40 00 33 FF 6A 07 8B F0
I saw different suggestion here, but it seems it's namely for SP3 - can't find kondra's suggested numbers 75 1B at given offsets.

i also modified my boot.ini for alternate boot with alternate files: HAL of XP SP1 and patched ntkrnlpa.exe of my own SP2

i've read this paper: http://iknowu.dnsalias.com/files/public/Windows_XP_SP3_Remove_PAE_Limit/Windows_XP_Remove_PAE_Limit.htm
but still don't know how to patch my existing sp2 HAL to act server 2003 way - so I opted for SP1 HAL. Is there any shortcomings in using SP1 HAL instead of patching one's own version? kondra's suggestion "patch halmacpi.dll at offset 0x17813 from 74 17 to EB 17" doesn't work for me cause I find different numbers at that offset, proabably cause it's meant for SP3....
...so do I have to use /PAE switch in boot.ini when using XP SP1 HAL? or can I use modified SP3 HAL with xp sp2 as per instructions here? do i have to use /PAE then?


thaaaaaaaaanks smile.gif
post #53 of 100
Quote:
Originally Posted by kondra View Post

Absolutely correct! The noob (me) has not recognized that the USB problem only shows on USB 2.0 ports and not 3.0 ones. Good work!
I have tested usbport.sys from Windows 2003 Server with SP2 and it works great on my XP SP3.

For the sake of completeness we have to do the following on XP SP3:
- patch ntkrpamp.exe at offset 0x1B2A51 from 75 1B to 90 90
- patch ntkrpamp.exe at offset 0x15DF1A from 75 1B to 90 90
- correct the checksum of ntkrpamp.exe with LordPE
- patch halmacpi.dll at offset 0x17813 from 74 17 to EB 17
- correct the checksum of halmacpi.dll with LordPE
- to replace the original files by the patched ones we have to do the following:
- rename the file "C:\Windows\Driver Cache\i386\driver.cab" to "driver.cab_"
- rename the file "C:\Windows\Driver Cache\i386\sp3.cab" to "sp3.cab_"
- rename the file "C:\Windows\system32\ntkrnlpa.exe" to "ntkrnlpa.exe_"
- cancel the "Windows File Protection" message box and choose "Yes"
- copy the patched file ntkrpamp.exe to "C:\Windows\system32\ntkrnlpa.exe"
- cancel the "Windows File Protection" message box and choose "Yes"
- rename the file "C:\Windows\system32\hal.dll" to "hal.dll_"
- copy the patched file halmacpi.dll to "C:\Windows\system32\hal.dll"
- rename the file "C:\Windows\system32\drivers\usbport.sys" to "usbport.sys_"
- copy usbport.sys from Windows Sever 2003 SP2 to "C:\Windows\system32\drivers\usbport.sys"
- rename the file "C:\Windows\Driver Cache\i386\driver.cab_" to "driver.cab"
- rename the file "C:\Windows\Driver Cache\i386\sp3.cab_" to "sp3.cab"
- reboot

Hint: The german and english versions of halmacpi.dll and usbport.sys are the same. Only ntkrpamp.exe has minimal differences.

@friendship7: Much respect for very good reversing skills!

Thanks to all involved!

" - patch ntkrpamp.exe at offset 0x15DF1A from 75 1B to 90 90 " <- in my ntkrnlpa.exe 5.1.2600.6419 it is not 75 1B.

There are some calls to ExVerifySuite(x):
Code:
PAGE:0049CF88 loc_49CF88:                             ; CODE XREF: IoDeleteSymbolicLink(x)+4Ej
PAGE:0049CF88                 call    _ObIsLUIDDeviceMapsEnabled@0 ; ObIsLUIDDeviceMapsEnabled()
PAGE:0049CF8D                 test    eax, eax
PAGE:0049CF8F                 jnz     short loc_49CFA2
PAGE:0049CF91                 push    4
PAGE:0049CF93                 call    _ExVerifySuite@4 ; ExVerifySuite(x)
PAGE:0049CF98                 cmp     al, 1
PAGE:0049CF9A                 jnz     short loc_49CFA2
PAGE:0049CF9C                 push    ebx
PAGE:0049CF9D                 call    _IopDeleteSessionSymLinks@4 ; IopDeleteSessionSymLinks(x)
Code:
PAGELK:0057550D loc_57550D:                             ; CODE XREF: MmAddPhysicalMemoryEx(x,x,x)+BEj
PAGELK:0057550D                 cmp     ebx, ecx
PAGELK:0057550F                 jnb     short loc_5754EC
PAGELK:00575511                 push    7
PAGELK:00575513                 call    _ExVerifySuite@4 ; ExVerifySuite(x)
PAGELK:00575518                 cmp     al, 1
PAGELK:0057551A                 jnz     short loc_575523
PAGELK:0057551C                 mov     eax, 1000000h
PAGELK:00575521                 jmp     short loc_575544
PAGELK:00575523 ; ═════════════════════════════════════════════════════════════
PAGELK:00575523
PAGELK:00575523 loc_575523:                             ; CODE XREF: MmAddPhysicalMemoryEx(x,x,x)+D8j
PAGELK:00575523                 cmp     _MmProductType, 690057h
PAGELK:0057552D                 jz      short loc_57553F
PAGELK:0057552F                 push    1
PAGELK:00575531                 call    _ExVerifySuite@4 ; ExVerifySuite(x)
PAGELK:00575536                 cmp     al, 1
PAGELK:00575538                 mov     eax, 800000h
PAGELK:0057553D                 jz      short loc_575544
PAGELK:0057553F
PAGELK:0057553F loc_57553F:                             ; CODE XREF: MmAddPhysicalMemoryEx(x,x,x)+EBj
PAGELK:0057553F                 mov     eax, 100000h
PAGELK:00575544
PAGELK:00575544 loc_575544:                             ; CODE XREF: MmAddPhysicalMemoryEx(x,x,x)+DFj
PAGELK:00575544                                         ; MmAddPhysicalMemoryEx(x,x,x)+FBj
PAGELK:00575544                 mov     ecx, _MmNumberOfPhysicalPages
PAGELK:0057554A                 lea     edx, [ecx+esi]
PAGELK:0057554D                 cmp     edx, eax
PAGELK:0057554F                 jbe     short loc_57555B
PAGELK:00575551                 sub     eax, ecx
PAGELK:00575553                 mov     esi, eax
PAGELK:00575555                 lea     eax, [esi+ebx]
PAGELK:00575558                 mov     [ebp+arg_8], eax
Code:
PAGELK:0057A4E9 loc_57A4E9:                             ; CODE XREF: MmCreateMirror()+21j
PAGELK:0057A4E9                 push    7
PAGELK:0057A4EB                 call    _ExVerifySuite@4 ; ExVerifySuite(x)
PAGELK:0057A4F0                 cmp     al, 1
PAGELK:0057A4F2                 jz      short loc_57A515
PAGELK:0057A4F4                 cmp     _MmProductType, 690057h
PAGELK:0057A4FE                 jz      short loc_57A50B
PAGELK:0057A500                 push    1
PAGELK:0057A502                 call    _ExVerifySuite@4 ; ExVerifySuite(x)
PAGELK:0057A507                 cmp     al, 1
PAGELK:0057A509                 jz      short loc_57A515
PAGELK:0057A50B
PAGELK:0057A50B loc_57A50B:                             ; CODE XREF: MmCreateMirror()+42j
PAGELK:0057A50B                 mov     eax, 0C000026Ah
PAGELK:0057A510                 jmp     loc_57A93A
Code:
INIT:005D182E sub_5D182E      proc near               ; CODE XREF: MmInitSystem(x,x)+753p
INIT:005D182E
INIT:005D182E var_C           = dword ptr -0Ch
INIT:005D182E var_8           = dword ptr -8
INIT:005D182E var_4           = dword ptr -4
INIT:005D182E
INIT:005D182E                 mov     edi, edi
INIT:005D1830                 push    ebp
INIT:005D1831                 mov     ebp, esp
INIT:005D1833                 sub     esp, 0Ch
INIT:005D1836                 push    ebx
INIT:005D1837                 push    esi
INIT:005D1838                 push    edi
INIT:005D1839                 mov     ebx, 100000h
INIT:005D183E                 xor     edi, edi
INIT:005D1840                 push    7
INIT:005D1842                 mov     esi, eax
INIT:005D1844                 mov     [ebp+var_4], ebx
INIT:005D1847                 mov     [ebp+var_8], edi
INIT:005D184A                 call    _ExVerifySuite@4 ; ExVerifySuite(x)
INIT:005D184F                 cmp     al, 1
INIT:005D1851                 jnz     short loc_5D186E
INIT:005D1853                 cmp     [esi+64h], edi
INIT:005D1856                 jnz     short loc_5D1861
INIT:005D1858                 mov     [ebp+var_4], 1000000h
INIT:005D185F                 jmp     short loc_5D18A5
INIT:005D1861 ; ═════════════════════════════════════════════════════════════
INIT:005D1861
INIT:005D1861 loc_5D1861:                             ; CODE XREF: sub_5D182E+28j
INIT:005D1861                 mov     eax, 400000h
INIT:005D1866                 mov     [ebp+var_4], eax
INIT:005D1869                 mov     [ebp+var_8], eax
INIT:005D186C                 jmp     short loc_5D18A5
INIT:005D186E ; ═════════════════════════════════════════════════════════════
INIT:005D186E
INIT:005D186E loc_5D186E:                             ; CODE XREF: sub_5D182E+23j
INIT:005D186E                 cmp     ds:_MmProductType, 690057h
INIT:005D1878                 jz      short loc_5D188E
INIT:005D187A                 push    1
INIT:005D187C                 call    _ExVerifySuite@4 ; ExVerifySuite(x)
INIT:005D1881                 cmp     al, 1
INIT:005D1883                 jnz     short loc_5D188E
INIT:005D1885                 mov     [ebp+var_4], 800000h
INIT:005D188C                 jmp     short loc_5D18A5
INIT:005D188E ; ═════════════════════════════════════════════════════════════
INIT:005D188E
INIT:005D188E loc_5D188E:                             ; CODE XREF: sub_5D182E+4Aj
INIT:005D188E                                         ; sub_5D182E+55j
INIT:005D188E                 push    0Ah
INIT:005D1890                 call    _ExVerifySuite@4 ; ExVerifySuite(x)
INIT:005D1895                 cmp     al, 1
INIT:005D1897                 jnz     short loc_5D18A2
INIT:005D1899                 mov     [ebp+var_4], 80000h
INIT:005D18A0                 jmp     short loc_5D18A5
INIT:005D18A2 ; ═════════════════════════════════════════════════════════════
Code:
INIT:005D95F4 ; __stdcall PsLocateSystemDll(x)
INIT:005D95F4 _PsLocateSystemDll@4 proc near          ; CODE XREF: ExApplyCodePatch(x,x)+11Bp
INIT:005D95F4                                         ; IoInitSystem(x)+777p
INIT:005D95F4
INIT:005D95F4 var_30          = dword ptr -30h
INIT:005D95F4 var_2C          = dword ptr -2Ch
INIT:005D95F4 var_28          = dword ptr -28h
INIT:005D95F4 var_24          = dword ptr -24h
INIT:005D95F4 var_20          = dword ptr -20h
INIT:005D95F4 var_1C          = dword ptr -1Ch
INIT:005D95F4 var_18          = dword ptr -18h
INIT:005D95F4 var_10          = dword ptr -10h
INIT:005D95F4 var_C           = dword ptr -0Ch
INIT:005D95F4 var_8           = dword ptr -8
INIT:005D95F4 var_4           = dword ptr -4
INIT:005D95F4 arg_0           = byte ptr  8
INIT:005D95F4
INIT:005D95F4                 mov     edi, edi
INIT:005D95F6                 push    ebp
INIT:005D95F7                 mov     ebp, esp
INIT:005D95F9                 sub     esp, 30h
INIT:005D95FC                 push    6
INIT:005D95FE                 call    _ExVerifySuite@4 ; ExVerifySuite(x)
INIT:005D9603                 test    al, al
INIT:005D9605                 jz      short loc_5D9617
INIT:005D9607                 test    ds:_PsEmbeddedNTMask, 1
INIT:005D960E                 jz      short loc_5D9617
INIT:005D9610                 xor     eax, eax
INIT:005D9612                 jmp     locret_5D97F1
So which should be changed to NOPs?
Edited by roytam1 - 4/10/14 at 12:58am
post #54 of 100
BTW I got a crash today.
The changes are ntkrnlpa: INIT:005D1883, PAGELK:0057551A, hal: 0x17813
I use /hal= and /kernel= switch for loading modified files. (bluescreenview shows original files)

hal.dll hal.dll+8bc7 0x806e6000 0x80706d80 0x00020d80 0x47f3693d 2/4/2008 19:08:45
NDIS.sys NDIS.sys+19530 0xf6d82000 0xf6dae980 0x0002c980 0x48025d03 14/4/2008 03:20:35
ntoskrnl.exe ntoskrnl.exe+79d30 0x804d8000 0x806e6000 0x0020e000 0x51d4d90f 4/7/2013 10:08:15
post #55 of 100
hello from xp sp3 with 16G visible ram!
got hal and kernel readymade from one link in this thread
must admit it works nice, nothing strange happening. usb is also ok, i'm using that file from server 2003 sp2

the only thing i noticed is that windows update security packages (at least 4 of them) overwrite the kernel, so u have to restore patched one again, but then those updates become undone too and get offered again at the update site smile.gif
post #56 of 100
Quote:
Originally Posted by nightdagger View Post

Even though you don't need the 4GB of RAM unless you are a graphics designer or something, it would be cool to have and would give you bragging rights

You guys must not do much with your computers i have 16gb, the max i have used at one time is about 10gb.

post #57 of 100
I got another BSoD now.

Code:
READ_ADDRESS:  f7b22000

CURRENT_IRQL:  2

FAULTING_IP:
hal!HalpMovntiCopyBuffer+f
806eebc7 8b06            mov     eax,dword ptr [esi]

CUSTOMER_CRASH_COUNT:  2

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  taskmgr.exe

LAST_CONTROL_TRANSFER:  from 806ea404 to 806eebc7

STACK_TEXT:  
f78aae18 806ea404 8a2a7ffe f7b21ffe 00000002 hal!HalpMovntiCopyBuffer+0xf
f78aae38 806eb295 f7b21ffe 8c063cc0 00000002 hal!HalpCopyBufferMap+0xb6
f78aae84 806ea62e 879845a0 883883e8 01063c9c hal!HalpMapTransfer+0x179
f78aaed4 806ea85c 8799d750 00000000 8c063c9c hal!HalpAllocateAdapterCallback+0xa2
f78aaefc 806eada2 029845a0 8c19520c 0000002d hal!IoFreeMapRegisters+0xce
f78aaf24 f6d9b5c5 879845a0 8c063ccc 00000001 hal!HalPutScatterGatherList+0xac
f78aaf3c f6d97be4 87986f20 87986000 00000000 NDIS!ndisMFreeSGList+0x25
f78aaf54 a7cf7364 8799d850 87d804e0 00000000 NDIS!ndisMSendCompleteX+0x34
WARNING: Stack unwind information not available. Following frames may be wrong.
f78aaf78 a7cf7e17 87d804e0 8795a2cc 80541b40 Rtenicxp+0x1c364
f78aaf9c a7cf2588 87986000 8799d850 87987030 Rtenicxp+0x1ce17
f78aafb4 f6d9ae99 87986000 87831268 ffdff9c0 Rtenicxp+0x17588
f78aafcc 80546f9f 87987044 87987030 00000000 NDIS!ndisMDpcX+0x21
f78aaff4 80546b0b aa2ea6cc 00000000 00000000 nt!KiRetireDpcList+0x61
f78aaff8 aa2ea6cc 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2b
80546b0b 00000000 00000009 0081850f bb830000 0xaa2ea6cc


STACK_COMMAND:  kb

FOLLOWUP_IP:
Rtenicxp+1c364
a7cf7364 ??              ???

SYMBOL_STACK_INDEX:  8

SYMBOL_NAME:  Rtenicxp+1c364

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Rtenicxp

IMAGE_NAME:  Rtenicxp.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  52cbad18

FAILURE_BUCKET_ID:  0xA_Rtenicxp+1c364

BUCKET_ID:  0xA_Rtenicxp+1c364
 
 

Probably caused by : Rtenicxp.sys ( Rtenicxp+1c364 )
post #58 of 100
So a quote from msfn:
Quote:
Originally Posted by Acheron 
I have also tried to manually patch the files using dencorso's method. It resulted in the boot process getting stuck.

Searching further I found the Chinese XP64G patch. I assumed it was only for Chinese or English systems, but it also seems to work just fine with other localized kernel files. The patch does not alter the ntoskrnl file directly, but creates a copy and adds a separate boot entry.

Comparing the differences between methods I found that the Chinese patch also modifies the following bytes in hal.dll at 0x1DCFF:
Code:
10 68 00 00 00 01 53 C7 05 C4 32 02 80 40 00 00 00 BE 00 00 01
to:
Code:
30 68 FF FF FF FF 53 C7 05 C4 32 02 80 00 40 00 00 BE 00 00 03

and this fixes the issue above. wink.gif
post #59 of 100
Hi!

I noticed that under patched kernel / hal DV capture does not work - camera is seen, transport buttons work but there is no video and nothing gets captured. Do you have such issues as well?
also Quantum LTO utilities don't pass tape recording tests with unknown host bus adapter error. anyway, ntbackup seems to work fine still.

here i've put hal and kernel from XP SP3 with all updates applied (and I guess there won't be any more because support is discontinued): http://www.sendspace.com/filegroup/j3XsHZOlWz%2FNhNXbO%2BQbrw
anyone up to patching em?

where did you find chinese patch, roytam1?
now there is a selection of patches that can be done. which one to use?
i wonder if there is a patch that doesn't double buffer for 64bit memory addresses capable pci devices.
post #60 of 100
for USB Video device, you need replacing usbvideo.sys with one from windows server 2003 SP2.

I have patched files and with latest USB drivers from Windows Server 2003 SP2 included as an archive.
https://mega.co.nz/#!DN8iTDqR!zfXyghUUrHkAl6oCPTmq4dhqcYTcI8hFUtr6TsXlKvM

without double buffering, cross border access will fail and lead to BSoD like in post #57.
Edited by roytam1 - 4/15/14 at 3:24am
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Windows
Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Windows › Windows XP Ram Limit