This document is made available under the terms of the GNU Free Documentation License.
You should have received a copy with it. If not, it is available online at
http://www.fsf.org/licenses/fdl.html.
Linux funziona su macchine SMP (Symmetric Multi-Processors). Il supporto a SMP
è stato introdotto con il kernel versione 2.0, e da allora viene migliorato costantemente.
HOWTO manutenuto da Enkh Tumenbayar (
Se si vuol contribuire a questo HOWTO, preferirei un file diff per la versione SGML.
Se mi viene inviata un'email circa questo HOWTO, prego includere un
tag tipo [Linux SMP HOWTO]> nel campo Subject:> della propria
e-mail. Questo mi aiuta a ordinare automaticamente le mail (e si avrà una risposta più velocemente ;)>).
Questo HOWTO è un miglioramento di
Tutte le informazioni contenute in questo HOWTO sono fornite "così come sono". Tutte
le garanzie, espresse, implicite o statutarie, concernenti l'accuratezza delle
informazioni e dell'idoneità per ogni uso particolare sono con ciò
specificatamente smentite. Mentre ogni sforzo è stato fatto per assicurare
l'accuratezza delle informazioni contenute in questo HOWTO, l'autore non si assume
responsabilità per errori o omissioni, o per danni risultanti
l'uso delle informazioni contenute qui.
Si. I processi e i kernel-thread sono distribuiti tra i processori.
I thread in user-space no.
SMP è supportato nel 2.0 su sistemi hypersparc (SS20, etc.) e macchine Intel
486, Pentium o superiori le quali sono Intel conformi a MP1.1/1.4.
Il supporto SMP per macchine UltraSparc, SparcServer, Alpha e PowerPC è
disponibile dal 2.2.x.
Ecco, ho intenzione di hackerare MIPS-SMP appena ho una box SMP ...
(
La maggior parte delle distribuzioni non fornisce un kernel già pronto al SMP,
ciò significa che si dovrà farne uno da se. Se non si è ancora mai compilato
un proprio kernel, questo è un motivo per imparare come. La spiegazione
di come fare un nuovo kernel va oltre lo scopo di questo documento; fare riferimento
al Linux Kernel Howto per maggiori informazioni. (
Configurare il kernel e rispondere Y a CONFIG_SMP.
Se si usa LILO, è pratico avere entrambe le immagini dei kernel SMP e non-SMP
a disposizione. Editare /etc/lilo.conf per creare un'entrata
per un'altra immagine del kernel chiamata "linux-smp" o simile.
La prossima volta che si compila il kernel, quando si esegue un kernel SMP,
editare linux/Makefile e modificare "MAKE=make" in "MAKE=make -jN"
(dove N = numero di CPU + 1, o se si ha molta memoria o swap
si può usare solo "-j" senza un numero). Sentirsi liberi di sperimentare
con questo parametro.
Certamente si dovrebbe cronometrare quanto dura ogni compilazione :-)
Esempio:
Se si stesse utilizzando delle macchine Compaq conformi a MP occorerà impostare
il sistema operativo nelle impostazioni del BIOS a "Unix"
Nei kernel della serie 2.0 fino ma non incluso il 2.1.132, decommentare la riga
/usr/src/linux/Makefile>).
Nella versione 2.2, configurare il kernel e rispondere "yes" alla
domanda "Symmetric multi-processing support" (
Occorre ricompilare il proprio kernel e i moduli del kernel quando si passa alla
modalità SMP. Ricordare di eseguire make modules> e make
modules_install> (da
Se si prende un "module load error", probabilmente non si è ricompilato e/o
re-installati i propri moduli. Anche con alcuni kernel 2.2.x le persone hanno
riportato problemi quando modificando la compilazione dal SMP ritornando indietro
(all'uni-processore). Per correggere questo, salvare il proprio file .config, eseguire make
mrproper, restorare il proprio file .config, poi ricompilare il proprio
kernel (make dep, etc.) (
Ricap:
Nella serie 2.0,
Si deve ricompilare il proprio kernel e i moduli del kernel quando si passa a una
modalità SMP. Ricordare di eseguire make modules> e make
modules_install> e ricordare poi di eseguire lilo. Vedere le note di sopra circa
i possibili problemi di configurazione.
Typical output (dual PentiumII):
La versione del kernel Linux 2.2 ha la gestione dei segnali, interrupt e altri argomenti I/O con lock a granularità fine.
Il resto viene gradatamente migrato. Tutta la schedulazione è compatibile a SMP.
La versione del Kernel 2.3 (prossimo 2.4) ha realmente il lock a granularità fine. Nei kernel 2.3
l'uso del lock big kernel è praticamente scomparso, tutti i maggiori
sottosistemi del kernel Linux sono pienamente condotti a thread: networking, VFS, VM, IO,
block/page cache, scheduling, interrupt, segnali, etc. (
In breve, il 2.2 non utilizza l'hardware come fa il 2.4.
Prego riportare i bug a linux-smp@vger.kernel.org>.
Se si vogliono calcolare le prestazioni del proprio sistema SMP, si possono eseguire alcuni test fatti da
Cameron MacKinnon e disponibili a
Dare un'occhiata anche a quest'articolo di Bryant, Hartner, Qi e
Venkitachalam che compara i kernel 2.2 e 2.3/2.4 UP e SMP :
Se occorre chiederselo, probabilmente no. C. Polisher)
Questo dipende dall'applicazione, ma molto probabilmente no. SMP aggiunge
alcuni miglioramenti che una box con un uniprocessore più veloce non avrebbe
(
Grazie a
Per il 2.2.x,
A proposito, non è possibile monitorare precisamente la schedulazione del processore con xosview,
perché xosview stesso causa una perturbazione della schedulazione. (
E
L'hog di CPU è in esecuzione su una CPU. Quindi xosview si avvia
(sull'altra CPU) e inizia a mandare comandi a X, il quale
si avvia pure.
Dal momento che entrambi X e xosview hanno una più alta priorità del
hog di CPU, xosview sarà eseguito su una CPU e X sull'altra.
Poi xosview ferma l'esecuzione e si ha una CPU inattiva --> Linux
sposta l'hog di CPU sulla nuova CPU inattiva (X è ancora
in esecuzione sulla CPU dove prima era in esecuzione l'hog).
usare:
Con un kernel tipo 2.2, vedere anche il file
/usr/src/linux/Documentation/smp.txt> per istruzioni specifiche.
BTW, il fatto che vengono eseguiti compilatori multipli permette ad una macchina con sufficente
memoria di usare il tempo di CPU altrimenti perso durante i ritardi causati dagli I/O,
make MAKE="make -j 2" -j 2> in realtà aiuta anche su box con uniprocessore
(da
Nelle serrie 2.0, il risultato fornito dal comando time> è
falso. La somma utente+sistema è giusta *ma* la ripartizione del tempo tra utente e
sistema è falsa.
Più precisamente: "La spiegazione è, che tutto il tempo di cpu speso dai processori
tranne all'avvio è conteggiato come tempo di sistema. Se si tempifica un
programma, sommare il tempo utente al tempo di sistema, allora il conteggio sarà
quasi correto, eccetto anche l'inclusione del tempo di sistema che viene
correttamente conteggiata" (
Il bug è coretto nel kernel 2.2.
Sezione di
Solo POSIX Thread ci fornisce la condivisione di risorse in thread
come - specialmente - la memoria. Questa è la cosa che rende una macchina SMP
speciale, permettendo a molti processori di condividere la loro memoria. Per
usare entrambi (o più ;) processori di un SMP, usare una libreria kernel-thread.
Una buona libreria è la
Ci sono implementazioni di thread (e thread POSIX) che sono
a livello di applicazione, e non hanno i vantaggi del kernel-threading.
Quesi pacchetti thread tengono il threading in un singlolo processo,
quindi non hanno i vantaggi dell'SMP. Comunque, sono buoni per
molte applicazioni e su sistemi a processore singolo tendono di fatto a
eseguire più velocemente dei kernel-thread.
.
Comunque il multi-threading non è mai stato veramente popolare nel mondo UN*X.
Per alcuni motivi, le applicazioni richiedono processi multipli o
thread, di solito sono state scritte usando fork(). Perciò, quando si usa
l'approccio thread, uno incorre in problemi di incompatibilità (non
thread-ready) di librerie, compilatori, e debugger. GNU/Linux non fa
eccezione a questo. Fiduciosamente le prossime sezioni faranno un pò di
luce su cosa è attualmente possibile, e cosa no.
Le vecchie librerie C non sono thread-compatibili. E' molto importante che si
usi la GNU LibC (
C'è una ricchezza di linguaggi di programmazione disponibili per GNU/Linux,
e molti di loro possono essere fatti per usare thread in un modo o nell'altro
(alcuni linguaggi tipo Ada e Java hanno anche i thread come istruzioni primitive nel
linguaggio).
Questa sezione, comunque, descriverà al momento solo il C e il C++. Se si
ha esperienza in programmazione SMP con altri linguaggi, prego
renderlo noto.
GNU C e C++, così come i compilatori EGCS C e C++ lavorano con il
supporto ai thread dalla libreria standard C (
Guardare a
Molte utili informazioni possono essere trovate a
Guardare anche il
Si. Per i programmi, si dovrebbe guardare a:
Per quanto riguarda le librerie, ci sono:
Le routine BLAS Multithread non sono disponibili adesso, ma una libreria dual proc
è pianificata per il 1998-05-27, vedere
(
Linux non ha il pieno supporto per tutta la versione 1.4 di MPS.
L'esperienza ha mostrato che Linux di solito funziona meglio quando il BIOS è configurato per MP Spec. versione 1.1 se c'è un'opzione nel proprio BIOS di sistema. Non vedo perché la versione di MP Spec. dovrebbe importare a Linux, ma sarebbe un'esercizio interessante scoprire le differenze come presentato dalle tabelle del BIOS, per determinare perché Linux fallisce in alcuni casi con MP Spec. versione 1.4, e correggere Linux in modo che questo non abbia importanza.
Questo documento riassume le maggiori modifiche in MP spec. versione 1.4 e il loro stato di supporto in Linux.
L'hardware deve supportare una modalità di operazione in cui il sistema può cambiare facilmente alla modalità Symmetric I/O alla PIC o alla modalità Virtual-Wire. Quando il sistema operativo è pronto per cambiare all'operazione MP, esso scrive un 01H sul registro IMCR, se quel registro è implementato, e abilita l'entrata della tabella di redirezione APIC I/O. L'hardware non deve richiedere nessun'altra azione sulla parte del software per fare la transizione alla modalità Symmetric I/O.
Linux riconosce e supporta questa modalità di configurazione MP.
Per la compatibilità PC/AT, il processore di bootstrap deve supportare la compatibilità DOS esecuzione FPU e gestione delle eccezioni mentre funziona in una delle modalità PC/AT-compatibili. Questo significa che i segnali di errore virgola mobile dal BSP devono essere ruotati al segnale 13 di richiesta di interrupt, IRQ13, quando il sistema è in modalità PIC o virtual wire. Mentre i segnali di errore virgola mobile da un processore di applicazione non deve essere ruotato al IRQ13, i progettisti di piattaforme possono scegliere di connettere i due. Per esempio, connettendo il segnale di errore virgola mobile dal processore di applicazione all'IRQ13 può essere utile in caso di una piattaforma che supporta la scelta dinamica di BSP durante l'avvio.
In modalità simmetrica, un sistema conforme supporta solo unità a virgola mobile su chip, con segnalazione di errore attraverso interrupt vector 16. I sistemi operativi devono usare interrupt vector 16 per gestire le eccezioni di virgola mobile quando il sistema è in modalità simmetrica.
Linux non usa affatto l'interrupt di virgola mobile ad eccezione nei sistemi a processore genuine-i386 i quali non sono SMP-capable. [In questi sistemi, se essi cablano la FPU-exception-line nel modo PC/AT-compatibile, viene eseguito un controllo durante l'esecuzione per la disponibilità del #MF-exception. Se l'#MF-exception è disponibile, allora Linux gestisce questo interrupt se capita. (
Multiple APIC I/O sono supportate in Linux.
Questa tabella è resa opzionale nella versione 1.4 di MPS. Se la tabella non è presente, dovrebbe essere usata una delle configurazioni di default. Inoltre è stata aggiunta ad essa una sezione estesa per i nuovi tipi di entrate della tabella.
Linux supporta la Tabella di configurazione opzionale di MP e usa una configurazione di default se questa Tabella non è presente.
Linux tollera le entrate della tabella nella sezione estesa saltandole se non vengono trovate. I dati delle entrate della tabella estesa non sono usati.
Campi nuovi o modificati per la versione 1.4 di MP Spec.:
Sono definiti i tipi di entrata per System Address Space Mapping (mappatura dell'indirizzo di spazio di sistema), Bus Hierarchy Descriptor (descrittore gerarchico di bus), e Compatibility Bus Address Space Modifier (modificatore di indirizzo di spazio compatibilità bus).
Linux salta (non utilizza) queste entrate estese della tabella di configurazione di MP. Apparentemente questo non è critico a nessun sistema di trasporto.
Si. Gli attuali processori AMD Athlon MP supportano SMP con il chipset AMD 760MP. Ci sono diverse schede madri disponibili che dispongono di questo chipset, es. la Tyan, ASUS, etc. Athlon/SMP è supportato dai recenti kernel 2.4.x e anche dai vecchi kernel 2.2.x. (
Metterlo nella modalità conforme a MP1.1/1.4.
controllare "Configure Hardware" -> "View / Edit details" -> "Advanced mode"
(F7 penso) per l'opzione di configurazione "APIC mode" e impostarla a
"full Table mode". Questa è una raccomandazione ufficiale Compaq. (
(
(
Da
Da
Un kernel 2.0 (> 2.0.36) contiene la pacth MTRR la quale dovrebbe risolvere questo
problema (selezionare l'opzione "Handle buggy SMP BIOSes with bad MTRR setup" nel menù
"General setup").
Penso che la gestione di BIOS SMP bacati sia automatica negli ultimi kernel 2.2.
Alcune macchine IBM hanno MP1.4 bios block nell'EBDA, permesso ma non
supportato sotto i kernel 2.2.
C'è un vecchia box IBM basata sul 486SLC. Linux/SMP richiede il supporto FPU hardware.
No (secondo Alan
Prego vedere
Questo è un problema conosciuto con la gestione degli IRQ e i lunghi lock del kernel nelle
serie 2.0 dei kernel. Considerare l'aggiornamento agli ultimi kernel 2.2.
Da
Ci sono alcune correzioni del kernel nelle ultime serie 2.2.x che possono
correggere questo.
Il numero della CPU è assegnao dal produttore MB e non significa nulla. Ignorarlo.
(
(
Per riassumere l'articolo trovato nella documentazione ufficiale del kernel:
Dipende.
Ho trovao che non occorre mettere off IO-APIC se si è cambiato da MP 1.4 a 1.1. Apparentemente alcune schede basate su Xeon hanno bisogno di entrambe, ma non le schede ASUS CUV4X. Mettendo off il supporto a IO-APIC non necessariamente impone una probabile penalizzazione in minori prestazioni ai proprietari di ASUS. (
Alcune macchine IBM Netfinity avranno problemi di inizializzazione del controller SCSI integrato se è selezionato MPS 1.1. Ogni possibile LUB di ogni possibile dispositivo su ogni possibile bus sarà interrogato con un timeout. L'avvio avviene con un vano lungo tempo. (
Ci sono rapporti che sistemi con schede madri ASUS4X-DLS vanno bene con IO-APIC abilitato con MP 1.4.
Per schede madri CUV4X-D, disabilitando i controller IDE probabilmente si può avviare con MP 1.4 e APIC abilitato.
(
Probabilmente occorre aggiornare la propria versione di BIOS alla 1010.
Il chipset di Xeon (440GX) e la scheda madre relativa (supermicro S2DGE) che ho usato sono probabilmente (troppo ?) più affidabili e meglio supportati sotto Linux SMP che l'Athlon (AMD 760/760MP) semplicemente perché sono passati attraverso una più lunga sperimentazione.
La cache più grande dello Xeon (1mb sul dual 400 che si stà considerando) può dare un miglioramento delle prestazioni (e dato che non ho pianificato di eseguire su questo solo del singolo codice scientifico, non è probabilmente utile testare benchmark specificamente per il mio codice).
L'Athlon significativamente ha una frequenza di clock più alta (con la cache L2 full-speed L2 in Thunderbird, anche se solo 384kb) e più alta larghezza di banda di memoria con memorie PC2100 DDR che può aiutare molto.
Il costo non è chiarito fino al rilascio della scheda 760MP e delle memorie PC2100, ma sarà probabilmente ~$950 per avere due 1GHz 385km L2 Thunderbirds, scheda madre dual e 512mb di ECC PC2100 vs ~$750 per avere due 400MHz 1mb L2 Xeon, scheda madre dual e 512mb di ECC PC100. (
Provare gli ultimi kernel 2.2.x e le patch knfsd. Questo è
al momento sotto indagine. (
Se si stà usando kernel 2.2.11 o 2.2.12, prendere l'ultimo kernel. Per
esempio 2.2.13 ha un certo numero di correzioni a SMP. Diversa gente ha riportato
che questi kernel sono instabili per SMP. Questi stessi kernel possono avere problemi con NFS
e possono causare blocchi. Può essere utile usare anche una console seriale per catturare
i propri messaggi oops. (
Se il problema resta (e gli altri suggerimenti in questa lista non
aiutano altrimenti), allora si possono provare gli ultimi kernel 2.3. Essi hanno codice SMP/APIC più
verboso (e più robusto), e codice automatico di prevezione dei lock
hardware il quale produrrà significativi oops invece
di una silenziosa esposizione. (
(
(articolo di
Un buon mezzo per fare debug dei blocchi è di prelevare la patch ikd da
Andrea Arcangeli:
Ci sono diverse opzioni di debug, ma NON usare l'opzione
soft-lockup! Per le box più nuove,
impostare il debug del kernel poi attivare il NMI oopser.
Per verificare che l'NMI oopser stia funzionando, dopo aver avviato il
nuovo kernel,
/cat /proc/interrupts> e verificare di avere le
NMI. Quando la box si blocca, si dovrebbe ricevere un avviso.
Si può anche provare l'opzione %eip. Questa permette al kernel
di stampare alla console l'indirizzo %eip ogni volta che una funzione del kernel
viene chiamata. Quando la box si blocca, annotare la prima colonna
ordinata dalla seconda colonna poi cercare l'indirizzo nel file
System.map. Questo funziona solo in modalità console.
Notare anche che l'uso di una console seriale può facilitare assai
nel debug dei blocchi del kernel, non solo per i blocchi del kernel SMP !
Un messaggio tipo:
In questa sezione si troveranno alcune
>Da
Sicuramente si può sempre andare su Radio Shack (o simile) e prendere un'altra ventola.
Si può usate lm_sensors per monitorare la temperatura della CPU dei nuovi processori PII
e PIII. Questo può aiutare a determinare se la temperatura è un problema. (
Non comprare RAM economiche e non usare moduli misti di RAM sulla scheda madre
la quale è esigente su questo.
Specialmente le schede madri Tyan sono rinomate per essere esigenti sulla velocità della RAM.
Ci sono alcuni resoconti di RAM PC100 a 10ns vendute con
schede madri dove la CPU realmente ha bisogno di RAM a 8ns. (
Controllare /proc/cpuinfo> per vedere se le proprie CPU sono dello stesso livello.
...e anche se fosse stabile, NON overcloccatelo.
>Da
I kernel 2.0.x su sistemi a alte prestazioni fast ethernet hanno significanti
(e risaputi) problemi con una condizione di race/deadlock nella gestione degli interrupt di rete.
La soluzione è di prendere l'ultimo driver di sviluppo 100BT da
Se si ha un sistema che usa il chipset 440FX allora i propri problemi con i
blocchi sono possibilmente dovuti a l'errata documentata del chipset. Ecco
un riferimento
Riferimenti:
Intel 440FX PCIset 82441FX (PMC) e 82442FX (DBX) Aggiornamento delle specifiche.
pg. 13
Il problema può essere corretto con uno stratagemma nel BIOS (O una patch al kernel) e
in fatti David Wragg ha scritto una patch che è inclusa alla patch MTTR di Richard Gooch.
Per maggiori informazioni e correzioni vedere qui:
>Da
A volte, alcune schede non sono riconosciute o possono scatenare conflitti di IRQ.
Provare a mischiare le schede negli slot in diffrerenti modi e
possibilità spostandole in diversi IRQ.
Contributo di
Provare anche a impostare le opzioni di setup del BIOS tipo "MP 1.4 mode" o "route PCI
interrupts through IOAPIC", o a non impostare l'"OS Type" a DOS o
Novell (
Se avviene un blocco quando si prova ad accedere al floppy (per esempio
mentre l'audio è in esecuzione) si può dover editare drivers/pci/quirks.c
e impostare /int isa_dma_bridge_buggy = 1;>
Questo è un problema con il mio Dell WS400 dual PII/300, 2.2.x, SMP
(
Prego notare: Altre informazioni specifiche possono essere trovate attraverso
la lista di
(
Box Linux SMP aquistabili a più basso costo con processori di oggi giorno sono
sistemi dual Celeron. Un tale sistema non è ufficialmente possibile
secondo Intel. Meglio pensare alla seconda generazione di
Celeron, quelli con 128 Kb di cache L2.
C'è anche una scheda madre (ABIT BP6) che permette di avere inseriti due Celeron nel formato Socket
370 (
Bene, grazie.
E' impossibile. I processori Celeron hanno quasi le stesse caratteristiche dei
chip base dei Pentium II. Se si vuole più di 2 processori nel proprio
sistema, si dovrà cercare delle box Pentium Pro, Pentium II Xeon o Pentium
III (?) .
Un sistema che usa un processore "ripristinato" Celeron e un processore Pentium II
con lo stesso livello
Citando la pagina web
Le SparcStation 10 e SparcStation 20 sono macchine capaci del SMP e in accordo con
Un'importante dettaglio quando si pianifica di avere diversi moduli CPU nel proprio computer è di avere lo stesso tipo di moduli, non si può mischiare SuperSparc e HyperSparc per esempio, ma si può avere un numero dispari di CPU, per esempio 3. E' stato detto di essere in grado di eseguire moduli a diversa velocità di clock come scritto in questo articolo da AcesHardware , ma non posso testimoniarlo. (
(
Niente. Compilazione SMP usuale (vedere sopra). Al solito, fare attenzione, i moduli
sono specifici o per UP o SMP. Ricompilarli. (
(
Nessuno (veramente ? :-)
Per
Per
Una corsa ai dati accade quando i processi vogliono modificare una variabile condivisa
simultaneamente senza proteggere loro stessi dagli effetti dell'altro
processo.
Poniamo A una variabile condivisa. Poniamo P1 e P2 due processi che accedono a questa
variabile. Questi due processi stanno facendo la stessa seguente operazione:
"leggere A in una variabile tmp (locale al processo); eseguire tmp = tmp + 1 ; scrivere
tmp in A". Se la variabile A non è protetta da un lock, il risultato
dell'esecuzione potrebbe non corrispondere a quello che ci si aspetta. Per esempio, ecco
due esempi se non si esegue un lock su A:
Per evitare questo tipo di problemi, si usa un lock:
Questo è un inter-bloccaggio che accade quando due processi vogliono accedere
a variabili condivise reciprocamente bloccate. Per esempio, poniamo A e B due variabili bloccate
e P1 e P2 due processi:
In questo esempio, il problema è molto semplice. Ma si immagini cosa possa accadere
in 2 milioni di righe di codice (come il kernel linux) con centinaia
di lock. :-)
make config
time -v sh -c 'make dep ; make clean install modules modules_install'
make config # o menuconfig o xconfig
make dep
make clean
make bzImage # o qualsiasi altra cosa si voglia
# copiare l'immagine del kernel manualmente, poi eseguire LILO
# o make lilo
make modules
make modules_install
processor : 0
cpu : 686
model : 3
vendor_id : GenuineIntel
[...]
bogomips : 267.06
processor : 1
cpu : 686
model : 3
vendor_id : GenuineIntel
[...]
bogomips : 267.06
Il successo di questo progetto è di fare un sorgente compatibile e una versione funzionalmente
equivalente di pset (come definito da SGI - parzialmente rimosso dal
loro kernel IRIX 6.4) per Linux. Questo abilita gli utenti a determinare su quale
processore o insieme di processori può essere eseguito un processo. Possibili usi
includono il forzare thread su processori separati, sincronizzazione, sicurezza (una
CPU solo `root' ?) e probabilmente di più.
E' focalizzato intorno la syscall sysmp(). Questa funzione prende un numero di
parametri che determinano quale funzione è richiesta. Le funzioni
includono:
La risposta è molto semplice. Fondamentalmente ci sono 3
processi implicati:
# make [modules|zImage|bzImages] MAKE="make -jX"
dove X=massimo numero di processi.
ATTENZIONE: Questo non funziona per "make dep".
POWER MANAGEMENT SETUP.
ACPI: Disabled
POWER MANAGEMENT: Disabled
PM CONTROL by APM: No
Se le caratteristiche della gestione di energia sono attivate, possono capitare casuali blocchi del sistema.
APIC error interrupt on CPU#0, should never happen.
... APIC ESR0: 00000002
... APIC ESR1: 00000000
indica una 'ricezione di errore di checksum'. Questo non può essere causato da Linux in quanto
la parte di messaggi di checksum di APIC avviene completamente a livello hardware. Potrebbe essere
un hardware marginale. Finchè non si nota alcuna instabilità, questi non sono
problematici - i messaggi APIC sono riprovati fin tanto che non vengono rilasciati. (
SaCarde
Download/traduzioni/SMP-HOWTO.sgml
FontsInteractXServer
MAN
BootPrompt-HOWTO.sgml.txt
Configuring_mkinitcpio.txt
LinuxGazette-dic-2006-saha-it-old.html
LinuxGazette-dic-2006-saha-it.html
Network-boot-HOWTO.sgml.txt
Pine-Exchange.sgml.txt
SMP-HOWTO.sgml.txt
kernel-list-it.html
linked-list.txt
nomachineNXserver.html
wireless.txt
MAN
BootPrompt-HOWTO.sgml.txt
Configuring_mkinitcpio.txt
LinuxGazette-dic-2006-saha-it-old.html
LinuxGazette-dic-2006-saha-it.html
Network-boot-HOWTO.sgml.txt
Pine-Exchange.sgml.txt
SMP-HOWTO.sgml.txt
kernel-list-it.html
linked-list.txt
nomachineNXserver.html
wireless.txt