Debian avvio lento e IOMMU

[Gimli[2BV!2B]]

No, dai, basta. Scegli se tenere il kernel Debian che ti mangia i famosi 15 secondi all'avvio, oppure crea un kernel personalizzato, lasciando però al loro posto tutte le impostazioni relative a 'sto benedetto IOMMU e usa tranquillamente i restanti giga e giga di RAM.

[Life bringer]

Guarda faccio ancora un paio di compilazioni di prova, come ultima risorsa scarico i sorgenti debian e ricompilo quelli... intanto ho fatto qualche prova, ho montato una vecchia 3dfx pci, dal computo dei 8256488k (il bios fa il computo in kb) i 128mb condivisi sono già rimossi. Rimuovendo ogni sorta di iommu si hanno problemi, compaiono nuovamente sfilze di:
nommu_map_single: overflow 226db3810+1536 of device mask ffffffff

Rimuovendo lo iommu aumenta la memoria, ora faccio ulteriori prove. A dopo

Update:
senza alcuna voce inerente lo iommu nel menu.lst: 8071064k stesso risultato con Iommu=noagp e Iommu=force
Iommu=noaperture: 8070652k
Iommu=off (con tutti i problemi di cui sopra, ergo pc inutilizzabile): 8136604k
Questo con il vanilla, ora ricomincio a smanettare...

Ho ricompilato il kernel tramite sorgenti debian e ho patchato il 2.6.28 al 29 rc5
Entrambi i test li ho condotti con questi parametri nel grub.lst: notsc noresume SELINUX_INIT=NO
Kernel debian leggermente modificato: 8048848k
Kernel RC rimuovendo initrd e altre modifiche piuttosto pesanti: 8046856k

Che bastino così poche modifiche (mi riferisco al primo caso) per perdere della memoria? Boh...

Modificando solo il delay della scheda scsi rimane: 8071064k

[McB]

A sto punto direi di lasciare il kernel modificato solo con il relay e buona notte.
Alla fine perdi un minimo di ram e via. Prima o poi la troveranno la soluzione.

[Life bringer]

Guarda stanotte ho fatto la prova del 9, ho installato ubuntu v9.04, la ram in ubuntu era ancora inferiore, su centos grossomodo la stessa di debian, mentre infine per sfizio ho installato windows xp pro e dal taskmanager la vedeva TUTTA!
Ormai ci rinuncio tengo il kernel levando il delay e buona notte

[McB]

Mi sto domandando se gli sviluppatori siano a conoscenza che in certi casi manchi ram al sistema.

[Life bringer]

Credo sia una "qualità" di linux, se modificando il kernel e paradossalmente alleggerendolo, si ha meno ram... boh mi viene da pensare che secondo come lo si configura, modulare o meno, questo impatti sulla ram disponibile, ma qui saliamo ad un livello per i quali faccio ipotesi probabilmente stupide, non sapendo come funziona il kernel di linux...

[McB]

Chissà. Magari hai ragione. Anch'io in questa materia sono molto ignorante.

[Gimli[2BV!2B]]

Ecco la situazione nelle mie macchine.

kwankey, Gentoo, Linux kwankey 2.6.28-gentoo-r2 #1 PREEMPT Sat Feb 21 19:56:25 CET 2009 i686 Unknown CPU Type AuthenticAMD GNU/Linux
Scheda video discreta, 1024 M di RAM, 1024 M rilevati.

gimli@kwankey ~ $ dmesg | grep Memory:
[    0.010000] Memory: 1031684k/1048512k available (4425k kernel code, 16128k reserved, 1798k data, 344k init, 139208k highmem)
gimli@kwankey ~ $ dmesg | grep Freeing\ unused
[    4.671478] Freeing unused kernel memory: 344k freed
kwankey ~ # lspci -vs 01:00.0
01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AQ [Radeon 9600] (prog-if 00 [VGA controller])
        Subsystem: PC Partner Limited Device 7c20
        Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16
        Memory at c0000000 (32-bit, prefetchable) [size=256M]
        I/O ports at d000 [size=256]
        Memory at e5000000 (32-bit, non-prefetchable) [size=64K]
        [virtual] Expansion ROM at e4000000 [disabled] [size=128K]
        Capabilities: [58] AGP version 2.0
        Capabilities: [50] Power Management version 2
        Kernel driver in use: radeonfb
gimli@kwankey ~ $ free
             total       used       free     shared    buffers     cached
Mem:       1032340      35516     996824          0       4376      15676
-/+ buffers/cache:      15464    1016876
Swap:      1060280          0    1060280

La scheda video segnala 64K di non-prefetchable.

Conto della memoria:
1.048.512k RAM utilizzabile - 16128k reserved = 1.032.384k -> 44k di scarto su free.
1.048.512k / 1024(k/M) = 1.023,9375M -> praticamente perfetto.

phoenix, Debian Sid, Linux phoenix 2.6.25.3-phoenix #2 Sun May 11 15:13:56 CEST 2008 i686 GNU/Linux
Scheda video integrata priva di memoria video, 512 M di RAM, 495 M rilevati.

root@phoenix:~# dmesg | grep Memory:
Memory: 498800k/506752k available (1816k kernel code, 7452k reserved, 809k data, 176k init, 0k highmem)
root@phoenix:~# dmesg | grep Freeing\ unused
Freeing unused kernel memory: 176k freed
root@phoenix:~# lspci -vs 01:00.0
01:00.0 VGA compatible controller: VIA Technologies, Inc. CN700/P4M800 Pro/P4M800 CE/VN800 [S3 UniChrome Pro] (rev 01) (prog-if 00 [VGA controller])
        Subsystem: VIA Technologies, Inc. CN700/P4M800 Pro/P4M800 CE/VN800 [S3 UniChrome Pro]
        Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 10
        Memory at f4000000 (32-bit, prefetchable) [size=64M]
        Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
        Capabilities: [60] Power Management version 2
        Capabilities: [70] AGP version 3.0
root@phoenix:~# free
             total       used       free     shared    buffers     cached
Mem:        499084     493136       5948          0      13500     357608
-/+ buffers/cache:     122028     377056
Swap:       465844         28     465816

l'lspci permette di rintracciare i 16 mega spariti: sono riservati alla scheda video.

Conto della memoria:
506.752k RAM utilizzabile - 7.452k reserved = 499.300k -> 216k di scarto su free.
506.752k / 1024(k/M) = 494,875 M
494,875 M + 16 M scheda video non prefetchable = 510,875 M -> 1M e rotti mancano al conto...

altarf, Debian Experimental, Linux altarf 2.6.28.7-altarf #1 PREEMPT Sat Feb 21 15:18:33 CET 2009 i686 GNU/Linux
Scheda video integrata nVidia GO, 1024 M di RAM, 1023 M rilevati.

root@altarf:~# dmesg | grep Memory:
[    0.000000] Memory: 1032488k/1047424k available (3265k kernel code, 14108k reserved, 1220k data, 276k init, 138120k highmem)
root@altarf:~# dmesg | grep Freeing\ unused
[    5.603877] Freeing unused kernel memory: 276k freed
root@altarf:~# lspci -vs 01:00.0
01:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce Go 6200/6400] (rev a1) (prog-if 00 [VGA controller])
        Subsystem: Sony Corporation Device 81c2
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at a0000000 (32-bit, non-prefetchable) [size=16M]
        Memory at c0000000 (64-bit, prefetchable) [size=256M]
        Memory at 90000000 (64-bit, non-prefetchable) [size=16M]
        [virtual] Expansion ROM at 91000000 [disabled] [size=128K]
        Capabilities: [60] Power Management version 2
        Capabilities: [68] MSI: Mask- 64bit+ Count=1/1 Enable-
        Capabilities: [78] Express Endpoint, MSI 00
        Capabilities: [100] Virtual Channel <?>
        Capabilities: [128] Power Budgeting <?>
        Kernel driver in use: nvidia
        Kernel modules: nvidia
root@altarf:~# free
             total       used       free     shared    buffers     cached
Mem:       1033140     724024     309116          0      46892     317732
-/+ buffers/cache:     359400     673740
Swap:       995988          0     995988

Qui ci si avvicina ad una situazione simile alla tua, con schede video evolute che usano accessi preferenziali alla RAM per sopperire alla poca memoria fisica, inizio ad avere dei dubbi su quel che succede... direi che la memoria indicizzata a 64 bit è quella GO, la RAM video fisica ammonta 64 Mb, all'avvio del driver con Xorg ne riserva altri 64 nella RAM arrivando ai 128 indicati dal pannello nVidia, i 16M non prefetchable a 32 e 64 bit non so che fine fanno...

Conto della memoria:
1.047.424k RAM utilizzabile - 14.108k reserved = 1.033.316k -> 828k di scarto su free.
1.047.424k / 1024(k/M) = 1.022,875M -> 1M e rotti non so che fine fanno...

La memoria non si perde, viene calcolata al netto di quelle porzioni non indicizzabili dal sistema (come la RAM donata alla scheda video).
Finché non si ha a che fare con periferiche che vanno a riservare RAM per le loro necessità il conto praticamente torna al k; nei miei pc, anche con periferiche particolari, non ci si discosta granché dal valore corretto.

Probabilmente avrò commesso imprecisioni, che sarei ben felice di comprendere se qualcuno interverrà, poi non ho a disposizione macchine a 64 bit o con IOMMU, quindi non sono in grado di analizzare la tua situazione.

[Life bringer]

L'intervento è decisamente illuminante, sulla wiki inglese c'è una spiegazione esauriente per quanto riguarda lo IOMMU link.
La domanda è, come mai la memoria disponibile aumenta (o meglio diminuisce) passando da un kernel all'altro, anzi anche solo ricompilando lo stesso con impostazioni differenti?

BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000cfee0000 (usable)
BIOS-e820: 00000000cfee0000 - 00000000cfee3000 (ACPI NVS)
BIOS-e820: 00000000cfee3000 - 00000000cfef0000 (ACPI data)
BIOS-e820: 00000000cfef0000 - 00000000cff00000 (reserved)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000228000000 (usable)
Memory: 8064196k/9043968k available (2263k kernel code, 191800k reserved, 1062k data, 388k init)

Debian-Server:~# free
             total       used       free     shared    buffers     cached
Mem:       8071068     666856    7404212          0        460     420588
-/+ buffers/cache:     245808    7825260
Swap:      1935824          0    1935824
Debian-Server:~#

Purtroppo, non so se hai inserito i size=xx manualmente o li fornisce il tuo kernel, purtroppo il mio non da questa indicazione.
Allego i messaggi loggati del kernel durante tutto l'avvio.

[Gimli[2BV!2B]]

Cominciamo dai dati che hai fornito.

Il BIOS riporta:
BIOS-e820: 0000000100000000 - 0000000228000000 (usable)
0x228000000 -> decimale -> 9.261.023.232B = 8,625G
Quindi partiamo male, mi sembrano un po' troppi.

Naturalmente i conti successivi sono basati sugli 8,6G, quindi non vanno...
Memory: 8064196k/9043968k available -> 9.043.968k = 8,625G

Sapendo che hai 8G partiamo da 8.388.608k

8.388.608k RAM nota - 191.800k reserved - 131.072k video = 8.065.736k -> siamo vicini al valore di free.
Probabilmente i 64M segnalati come persi dagli errori riportati nel primo post sono contenuti negli abbondanti 191.800k reserved.

Alla fine 'sto IOMMU, come hai visto, è un ri-mappatore di memoria, uno strato in più tra le periferiche e la memoria principale. Se è hardware è meglio.
La funzione fondamentale è la ri-mappatura degli indirizzi di memoria sopra i 4G per permettere alle periferiche a 32 bit di accedere a tutta la memoria. In assenza di uno IOMMU hardware questa funzione viene svolta d'ufficio dal sistema operativo e comporta delle piccole penalizzazioni.
Se disattivi lo IOMMU alcune periferiche potrebbero non funzionare (scheda di rete).
Francamente non so cosa combini il tuo BIOS. Non mi risulta che il tuo chipset (AMD 780G + SB700) abbia uno IOMMU hardware tra RAM e periferiche. Non hai AGP. Boh...

Mettiamola così, controlla se qualche kernel riesce a leggere decentemente la memoria disponibile, poi prova a fare i conti per vedere se sparisce qualcosa per strada; se non tornano i conti controlla anche l'lspci -v.

P.S. non ho capito cosa intendi con size=xx...

[Life bringer]

Si il computo è sbagliato alla base, durante il bios (spetta che feci foto con il cell) quando è impostata l'integrata rileva: 8256448K
Direi che la base da cui partire sia questa, su windows xp 64bit da taskmanager ne rileva: 8255XXX.

Mentre da free (-k) ne rileva: 8071068
Quindi la memoria mancante totale è 185380

Parlando di mb si parla di 185mb che, certo su 8gb sono una sciocchezza, però come valore non è indifferente. Il problema è che quello è il risultato migliore che sono riuscito ad ottenere, con kernel più nuovi la situazione peggiora, non parliamo di ubuntu che fa scendere la memoria disponibile sotto gli 8gb. risultato leggermente migliore con centos ma comunque inferiore a debian con kernel vanilla.

PS: Per size=xx intendo che nelle tue prove mettevi a fianco alla voce Memory xxx [size=xxmb] ma penso che non sia una feature del kernel ma una cosa che hai fatto manualmente