4GB vs 32bit

Sziasztok! Hátha itt tud valaki érdemlegeset is mondani.. Vettem egy új gépet ... ööö
Alaplap: Abit IB9
CPU: Intel E6320
Ram: 4x 1GB Corsair

Ez a lényeg .. meg az hogy az XP 3.25GB -ram látja a cuccost, több fórumon meg goooglen próbálkoztam, sok sok okosságot mondtak meg olvastam kezdve a a boot.ini /PAE /3G kapcsolóival és különféle BIOS trükközésekkel akkor is 3.25GB a ram áááááááá
A 64 bites Debianom meg persze annak látja ami 4GB-nak!!!!

Van valami megoldás hogy az XP is annyinak lássa a ramot amennyi ???????

Hozzászólások

32bites winnel a 4GB ram az felejős, ha 64bites cpu-d van ha nem. A win ennyire képes.

szerk.: windows -> x86_64-es

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.

debian 4.0 - linux-2.6.22-rc5-wifi0

Tudtommal pont ez az oka a 64-bitnek, mert a max megcimezhető memória 32-bites ramkezeléssel max 4G-körül van, ez van. 64-biten ez a max mmórai valami brutálisan sok (nincs kedvem kiszámolni)

a pci-os eszközök valahol 4gb környékén dolgoznak, emiatt nem lehet azt a területet haszálni, linux alatt ezt átlapolással, meg az mtrr-ek állítgatásával oldják meg.

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.

debian 4.0 - linux-2.6.22-rc5-wifi0

Azért használom ill használnám az a "32bit -es fost" mert a 64bit -es XP eléggé gánya munka, a 64bit-es Vista pedig feszt szarik az nvidia meghajtójára, mivel nekem a win csak játékra kell így amíg nem lessznek normális 64 bites drv-k addig szívnom kell ?

Win 32bit never use 4GB ram ????????

Ezzel nem vagy egyedül a win 99%-a az mebereknek csak játékra kell. Arra elég a 3,xxGb-szerintem. Aki nem csak játszik annak van linux/bsd is. Pl aa haverom csak win alá ír programokat (mivel programozó) és ha teheti lőször lin alá ír mert egy nagyságrenddel stabilabb. De ha win-specifikus akkor nincs mit tenni. Neem is érdekes a win-es asztalom. van 2 ikon egy heroes-3 és egy morrowind. Nem is kell másra nekem. Sőt már azt is elhatároztam, hogy, lekapom a win-t mert a h3-megy wine-vel, a morrowind nem, ezért maradt.
ja cedega-val megy az MW de elhatároztam a linuxos embeektől nem csórelünk. Má$ oprendsztereknél nincs ilyen elhatározásom.

Szeretem a sokatmondó win-es hibaüzeneteket :D
Végzetes hiba kérem lépjen kapcsolatba a remdszergazdával (ok az n vagyok nem lesz nehéz)
hibalista:
Végzetes hiba (bölcs lettem és vigan nyomom a reset gombot, ja és esembe jut a billi fiú anyukájának a foglalkozása.)

Ezt találtam (korrekt a leírás?)

Virtuális memóriacím

Virtuális memóriáról már mindannyian hallottunk. De mi az a virtuális memóriacím? Nyílván köze van a virtuális memóriához, nem? Nos, igen is, meg nem is. Mindjárt látni fogjuk, hogy miről is van szó.
A Windows XP egy úgynevezett virtuális memóriacím táblán keresztül éri el a memóriát. Közvetlenül soha nem képes - és ez így is van jól - bármiféle címet elérni, mindig virtuális memóriacímeken keresztül olvas és ír.
Ebbe a virtuális táblába beletartozik minden memória, ami a számítógépen található, beleértve a fizikai memóriát, a virtuális memóriát , a videokártya memóriáját, és minden olyan eszköz, periféria memóriáját, melyen található valamennyi fizikai RAM. És itt jön a probléma. Ugyanis - a 32 bites operációs rendszer korlátaiból adódóan - csak egy ilyen virtuális memóriacím tábla létezik, és ebbe bele kell férnie az összes, a számítógépben található és használni kívánt memóriának is.
Tehát van összesen 32 bitnyi memóriacímünk, melynek címei 0x00000000-0xFFFFFFFF-ig terjedhetnek.

De nézzük meg, hogy hogyan is néz ez ki a valóságban.

A képzeletbeli gépünkön 1GB fizikai memória, egy 128MB-s videokártya, és egyéb elhanyagolható méretű memóriát tartalmazó periféria található, melyeket az egyszerűség kedvéért nem részletezek. A virtuális memóriacím tábla így néz ki (angol elnevezéseket használok, mivel csak angol XP-t használok):

Graphics Controller
Memory Range E8000000-EFFFFFFF (ez épp 128MB)

System Board
Memory Range 00000000-3FFFFFFF (ez épp 1GB)

Ezeket az értékeket könnyen leellenőrizhetjük a Hardverkezelőben, ha megnézzük az eszköz Resources fülét. A legtöbbször több részletben van lefoglalva az eszköznek a virtuális memóriacím, tehát valószínűleg több bejegyzést fogunk látni.

Azt hiszem ezzel eddig nincs is probléma, rengeteg szabad virtuális memóriacímünk marad a bővítésre. De mi történik akkor, amikor a számítógépünkben valóban megtalálható 4GB fizikai memória, és mellette még egy 512MB memóriával rendelkező videokártya? Nos, vizsgáljuk meg.

Windowsunk lefoglalja a virtuális táblából az 512MB területet a videokártyának (és persze minden más eszköznek is foglal, amennyiben szükséges), majd megpróbál 4GB-t lefoglalni a fizikai RAM-nak, de hoppá, itt jön a probléma, annyi már nincs. Mit tehet ilyenkor? Lefoglalja az összes maradék helyet, mely - ez esetben - 3,5GB.
Tehát, annak ellenére, hogy gépünk fizikailag 4GB memóriát tartalmaz, csak 3,5GB lesz elérhető a rendszer számára, a maradék elvész. Ez nem ugyanaz, mintha a rendszer lefoglalna egy részt a fizikai memóriából a videokártyának, egyszerűen nem is tud róla, hogy létezik az a maradék memóriarész. Persze ez a mi szempontunkból lényegtelen.

Ez az egész így néz ki:

Graphics Controller
Memory Range D0000000-EFFFFFFF (ez épp 512MB)

System Board
Memory Range 00000000-CFFFFFFF
Memory Range F0000000-FFFFFFFF (a kettő együtt 3,5GB)

elvileg látja, csak a pae-t be kell kapcsolni

CONFIG_X86_PAE=y
CONFIG_X86_CMPXCHG64=y
CONFIG_HIGHMEM64G=y
CONFIG_RESOURCES_64BIT=y

ezek kellenek neki, szeintem több régebbi server is van ami 4GB+ ramot haszál és 32bites

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.

debian 4.0 - linux-2.6.22-rc5-wifi0

Hogy ez mit jelent pontosan abban tudnátok segíteni?

"Windows NT 4.0 Memory Support. With Microsoft Windows NT 4.0 Workstation and Server operating systems, the maximum amount of physical memory supported is 4 GB. The maximum amount of virtual memory is 2 GB.

With Windows NT 4.0 Server, Enterprise Edition, the /3GB switch was first added to Boot.ini.

Application Memory Tuning. This capability allows memory-intensive applications to utilize up to 50 percent more virtual memory on Intel-based computers. Application memory tuning provides more of the computer's virtual memory to applications by providing less virtual memory to the operating system.

Application Changes. No APIs are required to support application memory tuning. However, it would be ineffective to automatically provide every application with a 3-GB address space.

Executables that can use the 3-GB address space are required to have the bit IMAGE_FILE_LARGE_ADDRESS_AWARE set in their image header. If you are the developer of the executable, you can specify a linker flag (/LARGEADDRESSAWARE).

To set this bit, you must use Microsoft Visual Studio Version 6.0 or later and the Editbin.exe utility, which has the ability to modify the image header (/LARGEADDRESSAWARE) flag. For more information on setting this flag, see the Microsoft Visual Studio documentation.

Some manufacturers preconfigure their applications to use application memory tuning, making it unnecessary for you to make this change. For more information, see your application documentation and contact your application vendor to determine whether they support Large Address Awareness or whether you can enable it in their application.

Physical Address Extension. PAE is an Intel-provided memory address extension that enables support of up to 64 GB of physical memory for applications running on most 32-bit (IA-32) Intel Pentium Pro and later platforms. Support for PAE is provided under Windows 2000 and 32-bit versions of Windows XP and Windows Server 2003. 64-bit versions of Windows do not support PAE.

PAE allows the most recent IA-32 processors to expand the number of bits that can be used to address physical memory from 32 bits to 36 bits through support in the host operating system for applications using the Address Windowing Extensions (AWE) application programming interface (API). For information about the AWE API, see the Base Services section of the Platform SDK."