Administrace komentářů

Jak už řekl [michich], ta e820 mapa sdělená BIOSem vypadá OK.

Všimněte si, že north bridge prokládá úseky použitelné RAMky jinými úseky, do kterých jsou mapované různé IO funkce. A pokud správně koukám, v mapě zbyl i nějaký "vzduch". Takže kus použitelné RAMky přeteče přes 4 GB. Shodou okolností to podle mého odpovídá tomu poslednímu úseku, tj. 0,5 GB od 0x100000000 výše. Podle mého, pokud Vy kernelu nastavíte strop na 4 GB, tak oříznete tu oblast fyzického adresního prostoru CPU, co je hardwarem mapována nad 4 GB, takže zůstane nevyužita.

Dokumentace kernelu je sice v tomto bodě dost mlhavá, mluví obvykle o "system memory", takže není jasné, zda se mluví o RAMce nebo o "fyzickém adresním prostoru CPU" (adresa určená piny A0-A36 v patici procesoru). Podle mého z Vaší situace plyne, že kernelovým command-line argumentem mem=4G omezíte nikoli RAMku, ale fyzický adresní prostor.

Svého času jsem narazil na problém, že některé čipsety od Intelu, přestože podporují CPU s fyzickým adresním prostorem 36 bitů (ať už přes PAE nebo EM64T), mají z north bridge nadrátováno pouze 32 adresních bitů, takže de facto mrzačí fyzický adresní prostor CPU na 4 GB. Týká se to konkrétně jednoprocesorových čipsetů i915, i925 a i7221 (P4/LGA775). Tenhle problém se Vás netýká (C2D a i965 umí 36 bitů), což ostatně dokazuje i BIOSem sdělená mapa e820 - u výše uvedených čipsetů nepřekročí hranici 4 GB neboli 0x100000000.

Dostal jsem tehdy od výrobce motherboardu jakési postarší PDFko od Intelu, které je dnes už spíše archivní (rok 2004), nicméně je značeno "Intel Confidential" a nikde na webu jsem ho nevygoogloval, takže si nedovolím ho zveřejnit, přestože je v podstatě neškodné. Nicméně si troufnu alespoň típnout tuto tabulku, kde jsou hezky vidět různě velké kusy rezervovaného fyzického adresního prostoru:

tabulka

Podle údajů z té tabulky bych řekl, že 512 MB je zabráno převážně PCI a PCI-e config spacem. Řekl bych, že Váš čipset s adresním prostorem zachází ještě vcelku ohleduplně, s ohledem na to, že pro něj 4GB hranice nepředstavuje problém

Co s tím dál?

Pro mne z výše uvedeného plyne, že za tuto situaci možná nemůže hardware ani BIOS. (Přesto bych se zkusil podívat po novější verzi BIOSu, člověk nikdy neví. Může to mít nějakou vazbu na ACPI bugy při konfiguraci PCI apod.)

Kdo za to může: nevylučuji, že za to může kernelový ovladač nějakého PCI zařízení, který není 64bit ready, a šáhne v paměti někam, kam nemá. Nebo to teoreticky může být problém někde uvnitř nejintimnějších vnitřností Linuxu, v oblasti správy paměti a mapování PCI MMIO oblastí, PCI DMA apod. Tomu ale moc nevěřím... Nejsem natolik zběhlý v oblasti PCI, abych dokázal říct, jestli to může být třeba chybou hardwaru PCI periferie, která umí pouze 32bitovou adresaci DMA přenosů (přestože PCI i 32bitová už nějakou dobu umí 64bitovou adresaci, pomocí "dual address cycle"), zda vůbec Linux podporuje PCI DMA do "high memory" apod. Ona taky adresace PCI není 1:1 s adresací hostitele, opět je tam nějaké mapování, takže těžko říct, zda se tento druh chyby může uplatnit. Každopádně se zdá, že pokud kernelu vnutíte omezení na 64bitový fyzický adresní prostor, tak se mu hračky nerozkutálejí...

Pokud máte čas a náladu to trápit, zkusil bych možná:

- jiné 64b distro (Fedora/RedHat/Centos?)

- zkompilovat si svůj vlastní např. vanilkový kernel, ze kterého vyházíte všechny ovladače, kromě těch nejnutnějších: initial ramdisk, řadič disku tj. IDE, Intel SATA a AHCI, povinné filesystémy, další features potřebné pro danou distribuci.

Souhlasím, že by bylo dobře vědět, kde přesně se kernel při bootu zasekne. Je možné, že místo záseku poukáže až na druhotný problém, způsobený někde dřív, ale velmi často to odpovídá poměrně přesně.

Pokud si zkompilujete vanilkový kernel, a třeba se Vám s ním i nepodaří nabootovat distro (třeba ani nenamountuje root), pořád aspoň uvidíte, jestli se Vám v neomezeném 64b režimu na daném hardwaru dostal alespoň přes to místo, kde Vám Suse kernel zůstává viset. Taky by se dala zapnout konzola na sériovém portu a típnout boot log z toho vadného pokusu...

Že na tom Visty hlásí celé 4 GB RAM, to je podle mého v pořádku, a nevylučuje to binec v linuxovém kernelu (ať už původem od Suse nebo původem z vanilky) ani binec v ACPI BIOSu toho hardwaru.

BTW, zkuste taky kernel command-line parametr "irqpoll" - šance, že za to můžou IRQčka, je poměrně malá, ale za vyzkoušení nic nedáte.

Jinak verze 2.6.18.8 vypadá jako vcelku duševně zdravá, do halušek okolo dynamického tiku jí zbývá ještě dost času. Alespoň o vanilce to platilo.

Hmm... nechce se mi do toho moc zabředat, vidím tam klasicky přídavný paralelní IDE řadič JMicron (protože i965/ICH8 má už on-chip jenom 6x SATA) - ten jede přes AHCI ovladač, nebo je v tom kernelu backportovaný nový ATA subsystém (který prezentuje IDE zařízení do SCSI vrstvy)? Šálí mě zrak? Ten je ve vanilce až někde okolo 2.6.21, a byl kolem něho docela rámus, pokud se nepletu... Co se stane, když zkusíte provozovat /dev/sda přes nativní ovladač Intel SATA (nikoli AHCI - viz BIOS), a ten JMicron vykostíte z kernelu úplně, jak pata_jmicron tak ahci? Jasně, přijdete o druhý disk a CD-ROMku, ale jenom po dobu testování, a s hotovou instalací na bootovacím prvním disku to CDčko nutně nepotřebujete.