Debian avvio lento e IOMMU

[Life bringer]

Premetto che ho:
Athlon x2 be-2350
GA-MA78GM-S2H
Ram 8gb di cui 128mb condivisa
Adaptec 29160
Hd scsi 15krpm 137gb

Da quando ho montato gli 8gb, all'avvio ottengo questo messaggio:

Feb 17 22:00:13 Debian-Server kernel: [ 0.004000] Node 0: aperture @ 4000000 size 32 MB
Feb 17 22:00:13 Debian-Server kernel: [ 0.004000] Aperture pointing to e820 RAM. Ignoring.
Feb 17 22:00:13 Debian-Server kernel: [ 0.004000] No AGP bridge found
Feb 17 22:00:13 Debian-Server kernel: [ 0.004000] Your BIOS doesn't leave a aperture memory hole
Feb 17 22:00:13 Debian-Server kernel: [ 0.004000] Please enable the IOMMU option in the BIOS setup
Feb 17 22:00:13 Debian-Server kernel: [ 0.004000] This costs you 64 MB of RAM

Con il risultato che da risorse di sistema mi trovo, invece degli 8gb "solamente" 7,7gb. Ho provato a impostare il parametro iommu=off ma mi sono ritrovato con la rete non funzionante. In quel caso la ram "c'era tutta" esclusi i 128mb condivisi.

Qui (http://www.mjmwired.net/kernel/Documentation/x86_64/boot-options.txt) sono spiegate le varie voci, ma non riesco a capire quale dovrei impostare.

Il secondo problema è appunto una sorta di "avvio lento" ovvero sta svariati secondi a far nulla, salvo poi partire e avviarsi regolarmente, fornisco una schermata di bootchart che vale più di mille parole:

http://img407.imageshack.us/img407/7928/bootchartyu3.th.png (http://img407.imageshack.us/my.php?image=bootchartyu3.png)

Infine fornisco il syslog nel caso possa essere utile, grazie a chiunque mi aiuterà :D

syslog.txt (http://nemoitaly.gotdns.com/syslog.txt)

[Life bringer]

Up speranzoso :cry:

[ArtX]

ciao,
con iommu=off da bios non ti và la rete perchè il device non viene trovato, o viene rilevato dal kernel ma non riesce a connettersi?
Se propio non funziona sarebbe da vedere se si può evitare quel messaggio/controllo che penso sia del kernel, magari serve una configurazione apposita del kernel.
che kernel usi? quanto tempo ti resta quell'avviso?

[McB]

Ciao.

Googlando rapidamente sembra che la soluzione possa essere dare come parametro
iommu=memaper=3 o maggiore per farlo funzionare.

Per il boot lento purtroppo non ti so aiutare.

[Life bringer]

Vi ringrazio per la risposta, faccio un po' di prove e vi dico

[Gimli[2BV!2B]]

Stando alla configurazione del BIOS, l'unica voce che trovo lontanamente correlata con lo IOMMU è "Virtualization" in "Advanced BIOS features": hai provato ad attivarla?

Riguardo alle opzioni del kernel che potresti provare direi notsc e iommu=soft, da usare non contemporaneamente alla memaper già suggerita.

[Life bringer]

Ciao.

Googlando rapidamente sembra che la soluzione possa essere dare come parametro
iommu=memaper=3 o maggiore per farlo funzionare.

Per il boot lento purtroppo non ti so aiutare.

Con il settaggio che suggerisci, la ram "mangiata" aumenta a ben 256mb! invece dei normali 64mb, tanto che il messaggio varia in un:
This costs you 256 MB of RAM
Impostando il valore a 1, il valore di ram torna a 64mb

ciao,
con iommu=off da bios non ti và la rete perchè il device non viene trovato, o viene rilevato dal kernel ma non riesce a connettersi?
Se propio non funziona sarebbe da vedere se si può evitare quel messaggio/controllo che penso sia del kernel, magari serve una configurazione apposita del kernel.
che kernel usi? quanto tempo ti resta quell'avviso?

iommu lo posso purtroppo impostare solo dal menu.lst come dice Gimli ahime nel bios non c'è alcuna opzione. Con iommu=off la memoria sale, la scheda di rete viene riconosciuta dal kernel ma la rete non funziona in nessun modo. Leggendo grazie a google ho appurato che mettere iommu su off ha sempre dato problemi, a qualcuno alle periferiche usb a me a me invece alla scheda di rete. In compenso il messaggio al boot scompare.

Come kernel uso quello in Debian Squeeze v2.6.26-1-amd64.


Per Gimli[2BV!2B]: Quell'opzione è inerente alle ottimizzazioni presenti nel processore per le macchine virtuali, ho provato ad abilitarla ma non è successo nulla, visto che quella suggerita da Artx sembra peggiorare la situazione, colgo l'occasione per ringraziarvi nuovamente :)

Update: Con i settaggi di gimli l'avviso non compare più ma la ram disponibile continua ad essere 7,7gb

[McB]

Cercando avanti ho trovato pure iommu=noaperture
sicuramente fa sparire quel messaggio però non scrivono se avevano problemi che mancava ram al sistema.

[Life bringer]

Ho scaricato i sorgenti dell'ultimo kernel e sto guardando, ci sono delle nuove opzioni per lo iommu tipo:
IBM Calgary IOMMU support
AMD IOMMU support

Provo a ricompilare toccando poco, vediamo che ne esce fuori

[McB]

Avevo giusto letto e dimenticato di scrivere :doh: che ricompilando il kernel a dovere il problema si risolve stando a ciò che si legge in giro.

[Life bringer]

L'ultima volta che ho provato a compilare il kernel non partiva più niente, ora ho importato la configurazione e aggiunto giusto qualche spunta nelle ottimizzazioni, vediamo che ne viene fuori, grazie :D

[Life bringer]

Ok ho ricompilato il kernel, caricando il file .config del kernel originario...
Ho modificato giusto 2 opzioni (abilitato le ottimizzazioni per la mia cpu, abilitato il iammu for amd e cambiato il timer frequency) ho dato la compilazione, finita ora, faccio partire il sistema con il nuovo kernel e:
pci 0000:00:00.0: BAR3 can't allocate resource
Kernel panic - not syncing: VFS unable to mount root fs on unknown block(0,0)

Eppure non ho toccato nulla :muro:

[Life bringer]

Niente da fare, ho ricompilato il kernel, inglobando l'initrd, cambiando sempre le solite 2 voci, questo errore permane: pci 0000:00:00.0: BAR3 can't allocate resource, inoltre, la memoria disponibile CALA ulteriormente arrivando a 7,68gb.

Mentre ricompilando il kernel senza initrd impostando come monolitici il controller e il file system, durante il boot compaiono una sfilza di errori, fra l'altro non loggati nel file syslog. Il sistema sembra funzionare correttamente se non fosse che il dual core viene considerato monocore...

A questo punto mi affido nuovamente a voi...

[McB]

Ho cercato un pò avanti.
Questo errore deriva dal fatto che il kernel non riesce ad allocare o gestire(non ho ben capito) la memoria della scheda grafica. Però purtroppo non c'è traccia di una soluzione.
Ma hai provato a dare come parametro iommu=noaperture?

[Life bringer]

Ciao, si ho provato a darlo come parametro, a quel punto l'errore non compare più però la ram non aumenta, intanto do un altro aggiornamento, con il nuovo kernel, oltre al nuovo errore: pci 0000:00:00.0: BAR3 can't allocate resource ho notato che abilitando l'iommu per AMD non compare l'avviso durante il boot, nonostante questo compare nel log.
Ora provo a mandare una email a gigabyte...

[McB]

Speriamo ti diano una risposta che non so più che altro cercare.
Mi sembrava di capire su un sito francese(che io non so :D )che ricompilando il kernel gli funzionava. Probabilmente poi questi non hanno mai guardato quanta ram effettivamente il sistema vedeva.
Come ultima cosa che mi viene in mente è provare altre distro live per vedere se con queste funziona.

[Life bringer]

Si ho già pronto il cd di ubuntu, è una delle prove che volevo fare, sto compilando kernel a raffica appena finisce faccio uleriori prove, per l'altro errore hai qualche suggerimento?

[McB]

Con l'altro errore intendi il boot lento?
L'unica cosa che mi viene in mente è exim. Prima di fare una installazione minima lo avevo installato e quando me lo caricava il sistema si fermava un po' per poi continuare normalmente.

[Life bringer]

Forse l'avvio lento è causa di un timeout impostato nel kernel prima d'inizializzare l'hard disk scsi, aveva impostato 15 secondi di pausa, ora sto ricompilando il kernel con il settaggio modificato.
Per l'altro errore intendevo questo:
pci 0000:00:00.0: BAR3 can't allocate resource

Che riscontro solamente con il kernel scaricato da kernel.org e non quello nativo di debian. Intanto t'informo che ho provato ubuntu 7.10 ma da lo stesso messaggio per quanto riguarda lo iommu, ora ho masterizzato granular v1 e sto scaricando ubuntu 9.04 alpha4.
Concludo ringraziandoti per la pazienza e l'interessamento.

[McB]

Se noti dalla data di iscrizione a ieri non ho mai scritto ma solo seguito questo forum e ora dato che il lavoro è calato la sera dedico un po' più tempo al pc. Dato che ho imparato diverse cose dal forum mi sembra giusto aiutare se posso o almeno cercare di aiutare.

Per caso quella sfilza di errori erano simili a questo
pnp 00:09: mem resource (0xffb80000-0xffbfffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff)?

Secondo me potresti pure provare Fedora dato che è quella con maggiori novità.

[Life bringer]

allora ho nuovamente finito di compilare il kernel, il problema dell'avvio era dovuto a quella voce, infatti ora è NETTAMENTE più veloce, visto che non sussistono più quei tempi morti.

T'incollo alcune righe dello iommu più quelle dell'errore:

Checking aperture...
No AGP bridge found
Node 0: aperture @ 20000000 size 32 MB
Aperture pointing to e820 RAM. Ignoring.
Your BIOS doesn't leave a aperture memory hole
Please enable the IOMMU option in the BIOS setup
This costs you 64 MB of RAM
Mapping aperture over 65536 KB of RAM @ 20000000
PM: Registered nosave memory: 0000000020000000 - 0000000024000000
Memory: 8046296k/9043968k available (3043k kernel code, 787972k absent, 208736k reserved, 1396k data, 336k init)

Questo il famoso vecchio iommu malefico...
Per quanto riguarda l'altro errore di cui sono afflitto solo con l'ultimo kernel:

PCI: Using ACPI for IRQ routing
pci 0000:00:00.0: BAR 3: can't allocate resource
PCI-DMA: Disabling AGP.
PCI-DMA: aperture base @ 20000000 size 65536 KB
PCI-DMA: using GART IOMMU.
PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
pnp 00:0c: mem resource (0xd5400-0xd7fff) overlaps 0000:00:00.0 BAR 3 (0x0-0x1fffffff), disabling
pnp 00:0c: mem resource (0xf0000-0xf7fff) overlaps 0000:00:00.0 BAR 3 (0x0-0x1fffffff), disabling
pnp 00:0c: mem resource (0xf8000-0xfbfff) overlaps 0000:00:00.0 BAR 3 (0x0-0x1fffffff), disabling
pnp 00:0c: mem resource (0xfc000-0xfffff) overlaps 0000:00:00.0 BAR 3 (0x0-0x1fffffff), disabling
pnp 00:0c: mem resource (0x0-0x9ffff) overlaps 0000:00:00.0 BAR 3 (0x0-0x1fffffff), disabling
pnp 00:0c: mem resource (0x100000-0xcfedffff) overlaps 0000:00:00.0 BAR 3 (0x0-0x1fffffff), disabling

Sembra anch'esso collegato allo iommu di cui sopra... :muro:
Ho provato a googlare ma non mi pare di aver trovato soluzioni, ora metto in download anche fedora.

[Life bringer]

doppio sorry

[McB]

Ti posto qua direttamente la risposta di linus.
Da quello che ho capito io questi errori sono fasulli. in realtà la memoria viene utilizzata. Però se qualcuno che mastica meglio l'inglese potesse tradurre l'ultima parte che non capisco se c'è da fare qualcosa o meno per tentare di eliminare questo errore.


Ok, the more I look at this, the more interesting it gets.

In particular, this:

...
ACPI: bus type pnp registered
pnp 00:08: mem resource (0xfec00000-0xfec00fff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
pnp 00:08: mem resource (0xfee00000-0xfee00fff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
pnp 00:09: mem resource (0xffb80000-0xffbfffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
pnp 00:09: mem resource (0xfff00000-0xffffffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
pnp 00:0b: mem resource (0xe0000000-0xefffffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
pnp 00:0c: mem resource (0xfec00000-0xffffffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
pnp: PnP ACPI: found 13 devices
ACPI: ACPI bus type pnp unregistered
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
pci 0000:00:00.0: BAR 3: can't allocate resource
...

there's a few things to note here:

- the resource at 0000:00:00.0 BAR 3 is totally bogus.

We know it's totally bogus because you actually have other resources in
the 0xf....... range, and they work fine. It's also likely to be
totally bogus because it so happens that the end-point of 0xffffffff is
commonly something that the BIOS leaves as a "I sized this resource",
because that's how resources are sized (you write all ones into them
and look what you can read back).

But your lspci -vxx output clearly shows that (a) MEM is enabled in
the command word, and yes, the BAR register at 0x18 does indeed have
value 0xe0000000. So it's just the length that is really bogus.

- pnp clearly sees that bogus resource at 0xe0000000-0xffffffff

- BUT: the "can't allocate resource" thing is from
pcibios_allocate_resources(), and means that the request_resource()
failed _despite_ the fact that you hadn't reserved the e820 resources
yet with the new patch.

The thing that seems to save you is that we've already allocated something
in that region. There's a few things there, like:

fee00000-fee00fff : Local APIC

but that particular one is actually reserved much later, so that doesn't
explain it. I think that what happens is that we have allocated the _bus_
resources earlier in "pcibios_allocate_bus_resources()", and that means
that we already have these resources:

fe700000-fe7fffff : PCI Bus 0000:01
fe800000-fe8fffff : PCI Bus 0000:02
fe900000-fe9fffff : PCI Bus 0000:03
fea00000-feafffff : PCI Bus 0000:04
feb00000-febfffff : PCI Bus 0000:05

in the resource tree, and that in turn means that when we try to allocate
the bogus MCFG resource, it fails.

Which is good - it mustn't succeed.

What _broke_ for you is that the horrible patch that got reverted said
that "if we recognize this as an MCFG resource, we will _always_ try to
insert it", so it fundamentally broke the whole resource tree, because it
force-inserted that totally crap resource.

Now, the thing that worries me a bit is that I wonder how common this kind
of crap is. And in particular, I wonder how often we've been saved from
horrible issues like this by the fact that we've inserted the e820
resources first. Of course - it can work both ways - sometimes it saves
us, and sometimes it just causes more problems (eg when we then
re-allocate the resource successfully somewhere else).

Linus

[Life bringer]

Decisamente si usa un linguaggio tecnico che va oltre le mie limitate conoscenze, per quanto riguarda il messaggio di Linus.

Comincio dalle buone nuove, impostando prima a 5secondi e poi a 0 il valore di timeout per la scheda scsi nel kernel il boot time si è ridotto drasticamente, tanto che arriva a 17 secondi totali.

Rimane il problema del iommu, ho trovato casualmente qualcosa che può essere utile: http://www.osrevolution.netsons.org/2008/12/01/linux-amd64-x86_64-agp-nvidia-iommu-black-screen/

Ora gli lascio un messaggio sul blog e vediamo un momento, prima di fare quella modifica però, faccio una copia di backup dei sorgenti, come mi sono accorto di questa cosa? Perchè ho notato che nel kernel non si riesce a disabilitare l'agp gart, così ho iniziato a cercare...

[McB]

Veramente strano che non puoi disabilitare l'agp gart sopratutto perchè lui nel blog lo fa. Fammi sapere poi se trovi una soluzione.
Potresti provare a ricompilare quello che stai usando.

[Life bringer]

Ho fatto una cosa, ho ricompilato 2 volte il kernel, intendo dire, una modificando giusto 2 cose rispetto al config originale, l'altro modificando qualcosa di più, disabilitando l'initrd ecc. Tu intendevi fare questa cosa?
Inoltre mi ha risposto la gigabyte, ora leggo.

Edit, chissà perchè mi aspettavo questa risposta:
Thank you for your kindly mail and inquiry. About the issue you mentioned, due to standard PC architecture, a certain amount of memory is reserved for system usage and therefore the actual memory size is less than the stated amount, so basically the situation you described is normal.

At last, if you still have any further question to this issue or suggestion about our products/service, please do not hesitate to contact with us. If you have any issue different from original, make sure you issue a new form in order to get proper assistance and it may be response faster as well. We will try our best to help you resolve the problem ASAP.

:rolleyes:

[McB]

Normale che il sistema mi faccia vedere meno ram di quella che ho effetivamente?
A me pare normale che il sistema me ne usi di più ma non che non la vede tutta. Vabbè tra l'altro una risposta abbastanza scontata direi.

Comunque mi sono spiegato male. Intendevo dire di provare a ricompilare dai sorgenti presente nei repository di debian per vedere se con quelli puoi disabilitare l'agp gart. Che da quanto ho capito hai scaricato l'ultimo kernel vanilla no?

[Life bringer]

Si una risposta molto scontata, però, sinceramente non capisco, top dice:
Mem: 8070652k total
Phpsysinfo: 7.70 GB
Bios 8256mb+128mb

La mia conclusione è che imho in effetti questo maledetto gart rubi della ram, la prova ne è che con iommu=off la ram aumenta, senza dubbio la prossima mb che comprerò non sarà gigabyte, sarà stata la prima e l'ultima.

Detto questo, sinceramente non sono riuscito a trovare i sorgenti del kernel di debian, so solo che usa la versione 2.6.26-1-amd64 la domanda è, posso scaricarli da kernel.org? O la versione debian può essere diversa, con patch e modifiche? Infine, leggendo il blog del tizio che ha avuto problemi, anche lui vedo che imposta l'agp come modulo, però con possibilità di disabilitarlo, invece questa è la situazione che si presenta a me:

http://img13.imageshack.us/img13/2559/agp2ug8.jpg
http://img21.imageshack.us/img21/8259/agp1kv7.jpg

Google aiuta pochino, purtroppo, nella lingua di albione mi sembra di aver capito che per disabilitare l'agp bisogna prima disattivare altri moduli del kernel, ma non viene specificato quali.

[Gimli[2BV!2B]]

Riguardo ai moduli e alle sezioni non deselezionabili, apri l'help (ultimo "pulsante" a destra). Vi troverai varie cosette, tra cui le dipendenze dirette (ciò che occorre attivare per poter visualizzare/selezionare) ed inverse (ciò che impedisce la deselezione).

Nel 2.6.28 e rotti che ho sotto mano, riguardo all'Intel 440LX/BX/GX, che blocca il padre /dev/agpgart, trovo riportato:
Selected by: FB_I810 && HAS_IOMEM && FB && EXPERIMENTAL && PCI && X86_32 || FB_INTEL && HAS_IOMEM && FB && EXPERIMENTAL && PCI && X86

Ipotizzerei che la tua situazione ricada in FB_INTEL && HAS_IOMEM && FB && EXPERIMENTAL && PCI && X86: proverei quindi a fare ordine nella sezione dei framebuffer per rendere disattivabile l'agpgart.
Entra in Support for frame buffer devices (poco sotto l'agpgart) e togli quel che non ti serve, in particolare tutti gli Intel.

Riguardo alla versione Debian del kernel, l'ultima versione disponibile è la 2.6.26-13; i sorgenti patchati sono nel pacchetto linux-source-2.6.26, la config del kernel che hai installato è il file /boot/config-`uname -r`.

Nelle mie tre macchine Debian uso senza problemi kernel vanilla da Kernel.org.

[Life bringer]

Ti ringrazio, oltre ad aver imparato una cosa nuova sono riuscito a disabilitare il gart, ora faccio una prova di compilazione, grazie ancora :)

[Life bringer]

Cose... che non saprei come definire...
Ho disabilitato OGNI TIPO DI IOMMU, amd, classico e ibm calgary, ebbene? L'avviso all'avio compare ugualmente :muro:
Inserendo una qualsiasi opzione riguardante l'iommu nel menu.lst comporta una sfilza di errori impressionanti, con crash prima di giungere al server X. Sia che imposti iommu=off o iommu=noaperture. Questo con i kernel modificati, sia pesantemente che importando il file config e modificando solo il tempo d'attesa del controller scsi.
Ora... ho visto che è uscita una sub-version del kernel la 7 e inoltre ho scaricato i sorgenti di quella usata da debian. Sto compilando la nuova versione e quella originaria cambiando sempre le solite robe.
Ma la notizia più importante è che premendo ctrl+f1 nel bios si attiva una sorta di modalità avanzata, fra le quali, indovinate un po'?! Esatto c'è un'opzione che potrebbe proprio fare al caso di cui sopra. L'opzione in questione è:
IGX Configuration > Frame buffer location
Ma ora viene il bello o dovrei dire il brutto, impostando l'opzione come Below 4G, tutto funziona regolarmente tranne i problemi di cui sopra, impostando Above 4G, il sistema si pianta, in modo molto pesante, glitcher grafici e blocco totale. Ora, non è un problema di ram perchè con below funziona tutto senza problemi, ho eseguito vari cicli di memtest con 0 errori, con above invece si corrompe la grafica e si riavvia il sistema in 5 secondi circa. Non so se dare la colpa alla mb, come penso o al memory controller del processore, inoltre credo che quell'opzione serva per allocare la memoria condivisa, sopra i 4gb o sotto, ma sinceramente non ne sono sicuro. La prossima prova che farò, sarà spostare la scheda video da questo pc a quello, vedendo se disabilitando l'integrata il problema di sto iommu malefico si risolve o no. Sto anche scaricando centos, una distro da "server" vediamo se il problema dello iommu c'è anche con quella :muro:

[Life bringer]

Ultimo aggiornamento e poi vado a dormire, sono riuscito ad eliminare il messaggio, rimuovendo ogni sorta di gart e iommu, però la memoria disponibile è sempre la solita... mi viene da pensare, che possa essere normale a questo punto, ho notato che forzando ad off lo iommu compare una sfilza di questi errori:
Feb 21 08:03:08 Debian-Server kernel: [ 16.564987] nommu_map_single: overflow 226db3810+1536 of device mask ffffffff

Ora al più presto farò la prova spostando la scheda video e disabilitando l'integrata. Non so più che pensare, già vedere che il "taskmanager" mi rileva 7.7gb mentre top sfora gli 8gb mi manda in confusione, qui ci vuole qualche esperto che sappia quella roba del 1024 invece di 1000 :sofico:

[Gimli[2BV!2B]]

Per un semplice ed affidabile specchietto della memoria usa free -m, consulta la relativa man free per capire per bene l'output.

Oltre alla prova sulla scheda video, potresti vedere che succede con l'ultimo kernel rc, visto che ormai dentro ci sono circa un mese di novità e, come già riportato, gli sviluppatori sono a conoscenza di problemi relativi a queste parti del kernel.

Alla fine, se hai risolto la lentezza di avvio e 'sto problema dello IOMMU non fa altro che mangiarti lo 0,78% della RAM, dai, puoi sopravvivere senza, o no? Oppure se ti impunti su qualcosa devi riuscirci, come il sottoscritto...

[Life bringer]

Ovviamente figurati, circa 200mb di ram su 8gb sono una bazzecola, ma come hai suggerito tu la prendo più come una "questione di principio". Poi come dicevo prima magari è normale così, nel senso, è normale che mi veda 8048320kb di ram... stasera farò qualche prova. Fra l'altro ho notato come l'ultimo kernel sia affetto da qualche bug in più rispetto a quello fornito da debian, ho notato un paio di errori durante il boot e mettendoli su google si capisce che sono bug riconosciuti, ora provo a cercare la RC, grazie.
Edit: come RC posso scaricare questa: 2.6.29-rc5?

[Gimli[2BV!2B]]

200mb persi? Ma non erano 64? (lo 0,78 era sui 64)
A questi poi si aggiungevano i 128 usati dalla scheda video integrata, o sbaglio?

Il kernel che ti ho suggerito è il release candidate(prepatch) vanilla (http://www.kernel.org/kdist/fragments/stable_prepatch.html), al momento, appunto, 2.6.29-rc5 (http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.29-rc5.bz2).

[McB]

Io resto del idea che non sia normale che manchino quei 200 mb. Secondo me è più un bug del kernel oppure del bios.

Almeno te puoi cercare di risolvere sto problema senza rischiare di sputtanare tutto. Io per non vedere più un errore in fase di boot del controller raid che non incideva minimamente sul sistema a forza di seguire vari consigli ho perso 400 gb. il bello che poi alla fine bastava blacklistare un modulo :stordita: :doh:

[Life bringer]

A questo punto inizio anche io a pensare che sia "normale"
sono 128 condivisi, che vanno tolti agli 8256 che vede il bios, andiamo a 8128.
Risorse di sistema e phpsysinfo (http://nemoitaly.gotdns.com/phpsysinfo) ne rilevano 7.7gb anzi meno ancora 7.68 ora, top ne rileva 8048320k, free con il settaggio -m ne rileva 7859, a questo punto chi ci capisce qualcosa è bravo :sofico:

[McB]

Beh dai. Top e free sono molto vicini come risultato. E già un buon segno :D

[Life bringer]

Mo spacco tutto...
Se carico il kernel di debian, memoria libera con free -m: 7881
Se carico qualche kernel da me ricompilato, la memoria SCENDE!
Tanto per dire, se carico la stessa versione ricompilata rimuovendo il delay, mettendo come processore: Athlon k8, invece di lasciare le ottimizzazioni generiche e rimuovendo il supporto a Selinux la memoria scende a 7859.
Le opzioni menu lst sono le solite: iommu=noaperture notsc noresume SELINUX_INIT=NO

Con la versione nuova del kernel (non la rc) peggio che andar di notte, alla fine prendiamo per buoni questi 7881? E tanti saluti?

[McB]

Se non ti da fastidio avere 22 mb di memoria in meno terrei quelli compilati da te che almeno hai un boot veloce. Probabile che ci sia qualche patch debian che modifichi qualcosa.

[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 :sofico:

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... :sofico:

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 :D

[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 (http://en.wikipedia.org/wiki/IOMMU).
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