ATI (Italiano)
From ArchWiki
i18n |
---|
English |
简体中文 |
Italiano |
Introduzione
I possessori di schede video ATI hanno due possibilità per ciò che riguarda i driver da utilizzare: se non siete sicuri di quali driver utilizzare, provate prima di tutto quelli open-source, poichè generalmente soddisfano le esigenze più basilari e provocano in generale meno problemi.
I driver proprietari supportano AIGLX. Per utilizzare dei composite manager come Compiz potete ora usare sia i driver liberi che quelli proprietari. Oggi come oggi, le prestazioni dei driver open non sono paragonabili a quelle raggiungibili con i driver proprietari. Oltretutto, con i driver open manca ancora il supporto all'uscita TV, al doppio collegamento DVI, ed eventualmente ulteriori funzionalità. Dall'altro canto, ha un migliore supporto al dual-head.
Driver Open-Source
Ci sono due differenti driver open-source, xf86-video-ati
e xf86-video-radeonhd
.
xf86-video-ati
(versione 6.12.x) funziona con quasi tutte le schede video ATI, ma le schede più recenti tendono ad avere meno funzionalità implementate. I chip fino alla serie R5XX (grossomodo fino alla ATI X1950) sono pienamente supportati, in maniera stabile, e hanno il pieno supporto all'accelerazione 2D e 3D. I chip della serie R600 e R700 non hanno ancora (Aprile 2009) il supporto al 3D. Una lista comprensiva dei chipset supportati la si può trovare alla pagina [1].
xf86-video-radeonhd
è un driver sviluppato da Novell con le specifiche rese pubbliche da AMD per chip R500 e successivi. Inizialmente doveva rappresentare una rottura dal driver xf86-video-ati, ma allo stato attuale gran parte del codice risulta in comune. Supporta RandR 1.2 e rappresenta più che altro solo un driver in fase di sviluppo.
Installazione e Configurazione
Nota: Se avete in precedenza installato i driver proprietari, assicuratevi di rimuovere i pacchetti catalyst
e catalyst-utils
.
Per installare xf86-video-ati
:
pacman -S xf86-video-ati libgl
Per installare xf86-video-radeonhd
:
pacman -S xf86-video-radeonhd libgl
Modificate il vostro xorg.conf, aggiungendo o assicurandovi di avere le righe seguenti nelle rispettive sezioni.
Section "Module" Load "glx" Load "dri" Load "drm" EndSection
Sezione Device per xf86-video-ati
:
Section "Device" Identifier "name" # your alias Driver "radeon" Option "XAANoOffscreenPixmaps" "true" #needed for aiglx EndSection
Sezione Device per xf86-video-radeonhd
:
Section "Device" Identifier "name" # your alias Driver "radeonhd" Option "XAANoOffscreenPixmaps" "true" #needed for aiglx EndSection
Section "DRI" Group "video" Mode 0666 EndSection
Usando questo driver, assicuratevi di non avere il pacchetto catalyst-utils
installato, ma usate libgl-dri
al suo posto. Altrimenti, avrete sul sistema il file libGL.so
sbagliato, il che impedirà il corretto funzionamento del direct rendering.
Settaggi per aumentare le Prestazioni
Le seguenti opzioni vanno messe nella sezione Device:
Di default, i driver open-source funzionano alla velocità AGP 1x. È in generale consigliabile e sicuro modificare questa impostazione. Se notate peggioramenti di prestazioni, provate a diminuire il valore od a eliminare del tutto la riga.
Option "AGPMode" "4"
ColorTiling è un opzione assolutamente sicura da abilitare, e si suppone che sia abilitata di default. Molti utenti hanno rilevato miglioramenti nelle prestazioni, quando questa opzione è abilitata nello xorg.conf.
Option "ColorTiling" "on"
Architettura di accellerazione; questa opzione funzionerà solo sulle schede più nuove: se abilitando questa opzione, non riuscite più ad avviare X, ovviamente rimuovetela.
Option "AccelMethod" "EXA"
Page Flip è un opzione che è generalmente sicura. Dovrebbe essere usata sopratutto con le schede più vecchie, poichè abilitando questa verrà disabilitata EXA. Con i driver più recenti si può però utilizzarla insieme con EXA.
Option "EnablePageFlip" "on"
Quest'ultima opzione abiliterà la cosiddetta "fastwrite" della porta AGP. Questa opzione può causare problemi, quindi preparatevi a rimuoverla nel caso non riusciate ad avviare il server X.
Option "AGPFastWrite" "yes"
Fare riferimento alla manpage per ulteriori opzioni di configurazione.
Un tool molto utile da provare è driconf. Questo tool vi permetterà di modificare una serie di settaggi, come il vsync, il filtro anisotropico, la compressione delle texture, ecc. Usando questo tool è inoltre possibile "disabilitare il Low Impact fallback", cosa necessaria ad alcuni programmi (es. Google Earth).
TV out
Da Agosto 2007, c'è il supporto all'uscita TV per la maggior parte delle schede Radeon con uscita TV integrata.
È un supporto in qualche maniera limitato poichè non sempre funziona l'autorilevamento dell'output, e per adesso solo la modalità NTSC funziona (?)
Ecco come si deve procedere:
Innanzitutto, controllate che abbiate un'uscita S-Video: il comando xrandr
dovrebbe restituirvi a terminale qualcosa di simile a:
Screen 0: minimum 320x200, current 1024x768, maximum 1280x1200 ... S-video disconnected (normal left inverted right x axis y axis)
Adesso, sarà necessario dire a Xorg che la TV è attualmente connessa (lo è, vero?)
xrandr --output S-video --set load_detection 1
Impostiamo lo standard TV da utilizzare:
xrandr --output S-video --set tv_standard ntsc
Aggiungiamo una modalità di utilizzo per esso (per adesso è supportata solo la risoluzione 800x600)
xrandr --addmode S-video 800x600
Impostiamo ad esempio, il tutto con la modalità 'clone':
xrandr --output S-video --same-as VGA-0
Tutto a posto fino ad ora. Adesso vediamo di visualizzare il tutto sulla TV:
xrandr --output S-video --mode 800x600
Dovremmo a questo punto vedere una versione 800x600 del nostro desktop sulla TV.
Per disabilitare l'output, usiamo il comando
xrandr --output S-video --off
Inoltre, potreste notare che un video verrà riprodotto sul monitor ma non sulla TV. Dove l'output di Xv è riprodotto, è controllato dall'attributo XV_CRTC. Per mandare l'output alla TV, usiamo il comando
xvattr -a XV_CRTC -v 1
Per tornare al monitor, cambiamo l'ultimo valore con 0
. Inoltre, il valore -1
è utilizzato per lo switch automatico nei sistemi dualhead.
Driver Proprietari ATI Catalyst
Precedentemente conosciuti come fglrx, ATI ha rinominato i suoi driver proprietari per Linux, ora chiamati Catalyst. Oggigiorno, solo il nome del pacchetto ha effettivamente cambiato nome, mentre il nome del modulo del kernel ha mantenuto il suo nome originale 'fglrx', dunque qualsiasi riferimento da qui in poi a 'fglrx' è un riferimento al modulo del kernel, e non al pacchetto.
Schede Supportate
Vedere le note di rilascio ATI Catalyst 9.4 (Linux) per una lista delle schede supportate da questa versione dei driver. A partire dalla versione 9.4 sono supportate solo schede con chip R600 e successivi, mentre per schede meno recenti rimangono disponibili i driver catalyst precedenti o i driver liberi.
Installazione
Dal rilascio di Xorg 7, Arch ha fornito dei pacchetti precompilati dei driver Catalyst nel repository extra
. Se usate uno dei kernel forniti nei repository core o extra, il processo di installazione è molto semplice; se invece utilizzate un kernel personalizzato, sarà necessario eseguire degli ulteriori passi.
Stock Kernel
kernel26
Per installare i driver ATI fglrx per il pacchetto kernel26
, sarà necessario installare il pacchetto catalyst
.
# pacman -S catalyst
Questo contiene solo il modulo del kernel, ma installa inoltre anche il pacchetto catalyst-utils
come dipendenza. Quest'ultimo pacchetto è indipendente dal kernel in uso, e fornisce le librerie e le utility per Xorg, incluso il file personalizzato ATI libGL.os
.
Kernel Personalizzati
Per installare il pacchetto catalyst per un kernel personalizzato, sarà necessario compilarsi il proprio pacchetto catalyst-$kernel
contenente il modulo del kernel compilato nello specifico per il vostro kernel.
Se non avete padronanza o esperienza nella creazione di pacchetti, date un'occhiata alla pagina ABS del wiki innanzitutto, così che possiate arrivare più velocemente al risultato.
Procurarsi il PKGBUILD
Procuratevi il PKGBUILD
e il file catalyst.install
da CVS o da ABS. Perciò, o
- Aprite il link http://archlinux.org/packages/search/?q=catalyst , selezionate la vostra architettura, quindi cliccate su "View SVN Entries" per trovarli
oppure
- Eseguite il comando
abs
da utente root e localizzate i file nella cartella/var/abs/extra/catalyst
.
Modificare il PKGBUILD e costruirsi il pacchetto
Andranno fatte tre modifiche:
Primo, cambiate
pkgname=catalyst
in
pkgname=catalyst-NOME_KERNEL
dove NOME_KERNEL è qualsiasi nome voi abbiate scelto per il vostro kernel (es custom, mm, ilmigliorkerneldisempre)
Secondo, togliete kernel26
dalla lista delle dipendenze.
Terzo, cambiate
_kernver=${_kernel_version}-ARCH
to
_kernver=`uname -r`
(o inserite direttamente l'output del comando uname -r se avete il vostro kernel personalizzato già in esecuzione)
Infine, potrete compilare ed installare il pacchetto. (makepkg -i
o makepkg
seguito da un pacman -A nomepacchetto.pkg.tar.gz
)
Note
- Se utilizzate abitualmente più di un kernel proveniente dai repository, allora installate i moduli catalyst per ognuno di essi. Non andranno in conflitto fra di loro.
- Nessuna modifica andrà fatta al pacchetto
catalyst-utils
, il quale è completamente kernel-indipendente. Tutto ciò di cui avete bisogno è compilare il modulo del kernel.
Installatore ATI/AMD
Usare questo metodo causerà probabilmente conflitti di file con una molteplicità di pacchetti di pacman, e comporteranno probabilmente alcuni fallimenti di esecuzione del server X. I pacchetti disponibili tramite pacman sono configurati nello specifico per Arch Linux e dunque si consiglia caldamente di utilizzare quelli.
Se avete tentato un'installazione manuale dal file di installazione ufficiale, e vi siete resi conto che non funziona più nulla, dovreste poter riuscire a recuperare la situazione eseguendo lo script di disinstallazione che dovrebbe essere in /usr/share/ati - eseguitelo e poi provate ad installare i pacchetti catalyst tramite pacman.
SE dovete installare tramite lo script di installazione ufficiale, per qualche arcana ragione, i passi seguenti potrebbero funzionare per voi:
- Scaricate l'installer dei driver AMD/ATI
- Rendetelo eseguibile
- Installate il pacchetto mesa
# pacman -S mesa
- Installate se non lo avete già fatto, Xorg
- Controllate di avere tutti i requisiti per eseguire correttamente l'installer, i quali sono elencati sul loro sito
# pacman -Q | grep NameOfPackage
- Utilizzate aticonfig come descritto più avanti nel wiki, per aggiornare il vostro xorg.conf
- Aggiungete la sezione ModulesPath nello xorg.conf in maniera che punti al modulo fglrx.so se necessario
Configurazione
ATI fornisce l'utility aticonfig
per modificare uno xorg.conf
esistente e configurare in pratica qualsiasi aspetto della scheda ATI in vostro possesso. Per una lista completa delle opzioni di questo tool, eseguite:
$ aticonfig --help
Se non avete ancora un file xorg.conf, eseguite il seguente comando per generarne uno di base:
# Xorg -configure
La via più semplice per usare aticonfig
in maniera da adattare il vostro file xorg.conf
è visualizzato alla fine dell'output che si ottiene eseguendo aticonfig
senza passargli nessun parametro:
Esempi: 1. Configurare i driver fglrx per la prima volta. Single head : aticonfig --initial --input=/etc/X11/xorg.conf Dual head : aticonfig --initial=dual-head --screen-layout=above Questo comando genererà una configurazione dual head con il secondo screen posto al di sopra del primo.
Adattate semplicemente uno dei due esempi in base alle vostre necessità.
Attenzione: Controllate il file xorg.conf generato prima di andare a sostituirlo al file /etc/X11/xorg.conf e partire senza freni col comando startx o con un bel riavvio del sistema. Altrimenti, potreste probabilmente ottenere una schermata bloccata del server X e potreste non riuscire ad utilizzare più il vostro sistema. Può capitare infatti che lo xorg.conf generato con i passi appena descritti non sia corretto. Se volete, potete confrontare il file da voi generato con uno dei file Xorg.conf di esempio elencati sulla pagina wiki dedicata a Xorg.
Assicuratevi inoltre di avere la linea "DefaultDepth 24" nella vostra sezione "Screen" e che ci sia la sezione "DRI" con al suo interno l'opzione "Mode 666". Il driver fglrx necessità di queste opzioni per funzionare correttamente, ma generalmente i file prodotti con i passi precedentemente descritti non le hanno. Senza queste righe, potreste ottenere una schermata nera che non dà risposta ai comandi dopo il riavvio. Comunque, date che molte delle opzioni sono oramai automaticamente impostate nelle versioni più recenti di Xorg, è verosimile che non ci sia bisogno di scrivere poi moltissime opzioni manualmente nello xorg.conf, anzi, può essere che a volte alcune sezioni presenti in quel file siano ridondanti\di troppo.
Ecco un esempio di file xorg.conf minimale e funzionante.
Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "Files" RgbPath "/usr/share/X11/rgb" ModulePath "/usr/lib/xorg/modules" FontPath "/usr/share/fonts/misc" FontPath "/usr/share/fonts/100dpi:unscaled" FontPath "/usr/share/fonts/75dpi:unscaled" FontPath "/usr/share/fonts/TTF" FontPath "/usr/share/fonts/Type1" EndSection Section "Module" Load "extmod" Load "dbe" Load "xtrap" Load "record" Load "dri" Load "glx" Load "GLcore" Load "freetype" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/input/mice" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor Model" EndSection Section "Device" Identifier "Card0" Driver "fglrx" VendorName "ATI Technologies Inc" BoardName "Radeon Mobility X1400" BusID "PCI:1:0:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection Section "DRI" Mode 0666 EndSection
Infine, potete eseguire Xorg col comando startx
e verificare che l'accelerazione hardware sia attivata col comando seguente (da eseguire in un terminale):
$ glxinfo | grep direct
Se viene restituita la riga "direct rendering: yes" avete fatto tutto correttamente! Se invece il comando "glxinfo" non viene riconosciuto, potreste aver bisogno di installare il pacchetto mesa.
Nota: Nelle recenti versioni di Xorg, i percorsi delle librerie sono cambiati. Così, a volte il file libGL.so non è correttamente caricato, anche se risulta installato. Non dimenticate di controllare questa cosa se i vostri programmi GL non funzionano. Leggete la sezione "Risoluzione dei Problemi" per maggiori dettagli.
Risoluzione dei Problemi
Corruzione dei "checkerbox" nei programmi OpenGL
Questo problema è stato risolto con i driver Catalyst 8.9.
Programmi OpenGL come blender eseguiti in finestra, mostrano una corruzione nei "checkerbox". Questo problema può essere risolto usando l'impostazione "Virtual Display" con un ampiezza multipla di 64, maggiore della vostra attuale risoluzione, ad esempio di 1664 invece di 1600 per la larghezza:
Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Depth 24 Virtual 1664 1200 EndSubSection EndSection
Schermate nere e blocco del sistema / fase di stallo dopo riavvio o startx
Questo problema è stato riportato da alcuni utenti. Procuratevi un LiveCD (anche il cd di installazione di Arch va bene).
- Riavviate il sistema e bootate dal CD.
- Montate la vostra partizione di sistema, e leggete /var/log/Xorg.0.log (col comando less o simili).
- Cercate le linee che partono con "(EE)" le quali contengono eventuali messaggi di errore.
- Vedete se riuscite a risolvere il problema con le informazioni contenute in quei messaggi di errore.
- Fate riferimento alla sezione "Configurazione" di questa pagina, e assicuratevi di avere la voce "DefaultDepth 24" nell'apposita sezione dello xorg.conf.
- Riavviate il sistema per testare se il problema è stato risolto.
- Se non avete avuto fortuna, provate a rimpiazzare "fglrx" con "radeon", e riavviate. I driver open dovrebbero almeno permettervi di inizializzare correttamente il server X, anche se probabilmente senza accelerazione.
Risoluzione errata nel gestore login
Se la risoluzione del vostro gestore login è ad esempio 1600x1200 mentre voi desiderate la 1280x1024, potete sistemare il problema usando il file di configurazione xorg.conf (le versioni più nuove di X usando i driver open in teoria non necessitano più dello xorg.conf, quindi se non ne avege uno dovrete crearlo). Nella sezione "Screen" aggiungete delle righe relative alle risoluzioni:
Section "Screen" Identifier "aticonfig-Screen[0]-0" Device "aticonfig-Device[0]-0" Monitor "aticonfig-Monitor[0]-0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Modes "1280x1024" "2048x1536"#<-add this line to change the default login screen resolution EndSubSection EndSection
Il primo argomento della linea Modes è la risoluzione che verrà usata di default, la seconda è la massima risoluzione supportata dal vostro monitor. Ciò è necessario per far si che possiate selezionare diverse risoluzioni ad esempio nel pannello grafico di selezione presente in GNOME o in KDE.
KDM non si riavvia dopo un logout
Se state usando i driver proprietari Catalyst e vi ritrovate davanti a una console (vc/1) invece della consueta schermata di login di KDM, potreste dover istruire KDM di riavviare il server X dopo un logout:
$ sudo nano /usr/share/config/kdm/kdmrc
Decommentate la seguente riga (sotto la sezione [X-:*-Core] ):
TerminateServer=True
KDM dovrebbe ora riapparire correttamente dopo un logout da KDE.
Il Direct Rendering non funziona
Avete problemi nel far funzionare il direct rendering? eseguite innanzitutto
$ LIBGL_DEBUG=verbose glxinfo > /dev/null
in una console. Proprio all'inizio dell'output, il comando vi restituirà quale bell'errore vi impedisce di ottenere l'accelerazione.
Ecco alcuni errori comuni, e le loro rispettive soluzioni:
libGL error: XF86DRIQueryDirectRenderingCapable returned false
- Assicuratevi di aver caricato i moduli AGP corretti per il vostro chipset prima che venga caricato il modulo fglrx. Per determinare quali sono i moduli AGP corretti per il vostro pc, eseguite
hwdetect --show-agp
, quindi assicuratevi di inserire tutti i moduli che sono stati elencati, nell'array MODULES nell'rc.conf, ovviamente prima di fglrx.
libGL error: failed to open DRM: Operation not permitted libGL error: reverting to (slow) indirect rendering
- Per questo errore, assicuratevi di avere la seguente sezione nel vostro
xorg.conf
, da qualche parte:
Section "DRI" Mode 0666 EndSection
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri//fglrx_dri.so libGL error: dlopen /usr/lib/xorg/modules/dri//fglrx_dri.so failed (/usr/lib/xorg/modules/dri//fglrx_dri.so: cannot open shared object file: No such file or directory) libGL error: unable to find driver: fglrx_dri.so
- Qualcosa non è stato installato correttamente. Se i percorsi nell'errore sono
/usr/X11R6/lib/modules/dri/fglrx_dri.so
, provate innanzitutto a effettuare un completo logout dal sistema, per poi riloggarvi. Se usate un login grafico (gdm, kdm, xdm, slim ecc) assicuratevi che il file /etc/profile venga correttamente caricato ad ogni login. Ciò è solitamente fatto mediante l'inserimento nel file~/.xsession
oppure in~/.xinitrc
della rigasource /etc/profile
, ma in base al gestore del login che utilizzate, potrebbe essere necessario inserirla anche in altri file.
- Se i percorsi nel messaggio di errore sono invece,
/usr/lib/xorg/modules/dri/fglrx_dri.so
, allora qualcosa non è stato installato correttamente. Provate a reinstallare il pacchettocatalyst-utils
.
fglrx: libGL version undetermined - OpenGL module is using glapi fallback
- Questo errore può essere causato dal fatto di avere multiple versioni del file
libGL.so
nel vostro sistema. Eseguite i comandi
$ sudo updatedb $ locate libGL.so
Dovrebbe così esservi restituito a terminale l'ubicazione dei file, ad esempio:
$ locate libGL.so /usr/lib/libGL.so /usr/lib/libGL.so.1 /usr/lib/libGL.so.1.2 $
Queesti sono gli unici 3 file che dovreste avere sul vostro sistema. Se ne avete di più, (ad esempio /usr/X11R6/lib/libGL.so.1.2
), provate a rimuoverli. Ciò dovrebbe risolvere il vostro problema.
Potreste infine non avere nessun errore che indichi la presenza di un problema. Se usate Xorg 7, assicuratevi di non avere questi file nel vostro sistema:
/usr/X11R6/lib/libGL.so.1.2 /usr/X11R6/lib/libGL.so.1
Problemi con sospensione/ibernazione
Il video fallisce l'entrata in sospensione/ibernazione
Se fglrx
restituisce un errore nel tentativo di sospendere il sistema tramite gli appositi script, una soluzione potrebbe essere quella di aggiungere la linea seguente alla sezione "Device" nello /etc/X11/xorg.conf
, la quale dovrebbe permettere al modulo fglrx di entrare in modalità sospensione.
Option "UseInternalAGPGart" "no"
Il video fallisce nella riesumazione dalla sospensione
Il driver proprietario ATI catalyst non può riesumare se il framebuffer risulta attivato. Per disabilitare il framebuffer, aggiungete vga=0 alle opzioni da passare al kernel nel file /boot/grub/menu.lst
, ad esempio:
# (0) Arch Linux title Arch Linux root (hd0,0) kernel /vmlinuz26 root=/dev/sda3 resume=/dev/sda2 ro vga=0 initrd /kernel26.img
Il sistema 'freeza'/si blocca
- Per prevenire blocchi del sistema, provate ad aggiungere le righe seguenti alla sezione "Device" del vostro
xorg.conf
, dove avete configurato i driver proprietari:
Option "UseInternalAGPGART" "no" Option "KernelModuleParm" "agplock=0" # AGP locked user pages: disabled
Nota: Queste opzioni non sono più necessarie, visto che a partire dalla versione 8.24.18 ATI ha rimosso il supporto interno all' AGP GART dai driver.
- In maniera simile, è noto che anche i driver del framebuffer
radeonfb
in passato hanno causato problemi di questo tipo. Se il vostro kernel ha il supporto radeonfb compilato internamente, potreste provare ad utilizzare un kernel differente per vedere se ciò può aiutare.
Conflitti Hardware
Le schede Radeon usae in combinazione con alcune versione dei chipset nForce3 (es, nForce 3 250gb) non possono sfruttare l'accelerazione hardware. Oggigiorno, la causa di questo problema è ancora sconosciuta, ma alcune fonti indicano la possibilità di avere l'accelerazione attivando prima Windows con i driver di nVIDIA per poi riavviare il sistema. Questo può essere verificato in una console di root, col comando:
dmesg | grep agp
Se ottenete un messaggio simile a questo (usando un sistema basato su nForce3)
agpgart: Detected AGP bridge 0 agpgart: Setting up Nforce3 AGP. agpgart: aperture base > 4G
e se usando quest'altro comando...
tail -n 100 /var/log/Xorg.0.log | grep agp
...ottenete un messaggio simile a:
(EE) fglrx(0): [agp] unable to acquire AGP, error "xf86_ENODEV"
Allora avete questo bug.
Alcune altre fonti indicano come in certe situazioni, fare un downgrade del BIOS della scheda madre potrebbe aiutare, ma ciò non è verificato in tutti i casi. Inoltre, un downgrade del BIOS può nei casi più estremi rendere il vostro hardware della ferraglia inutilizzabile, quindi state attenti a quello che fate.
Vedere il big su bugzilla http://bugzilla.kernel.org/show_bug.cgi?id=6350 per maggiori informazioni e potenziali soluzioni.
Portatili Compaq Presario
Anche dopo aver installato i driver e modificato la configurazione come richiesto, alcuni portatili (ad es. Presario R4000 con Xpress 200M) presentano la classica schermata nera.
Il problema sembra essere la dimensione della memoria non correttamente rilevata dal kernel (anche se avete 128M lspci -v mostrerà sempre 256M). Cambiare l'impostazione del BIOS così che utilizzi l'opzione "SidePort+UMA" e 128M di memoria video più altri 128M presi dal sistema sembra far funzionare il tutto correttamente.
Potrebbe essere un BUG nel BIOS o nel codice PCI del kernel Linux.
Blocchi temporanei durante la riproduzione video
Se avete dei blocchi temporanei, da pochi secondi a qualche minuto durante la riproduzione di video con mplayer, controllate /var/log/messages.log per la presenza di errori come:
Nov 28 18:31:56 pandemonium [<c01c64a6>] ? proc_get_sb+0xc6/0x160 Nov 28 18:31:56 pandemonium [<c01c64a6>] ? proc_get_sb+0xc6/0x160 Nov 28 18:31:56 pandemonium [<f8bc628c>] ? ip_firegl_ioctl+0x1c/0x30 [fglrx] Nov 28 18:31:56 pandemonium [<c01c64a6>] ? proc_get_sb+0xc6/0x160 Nov 28 18:31:56 pandemonium [<c0197038>] ? vfs_ioctl+0x78/0x90 Nov 28 18:31:56 pandemonium [<c01970b7>] ? do_vfs_ioctl+0x67/0x2f0 Nov 28 18:31:56 pandemonium [<c01973a6>] ? sys_ioctl+0x66/0x70 Nov 28 18:31:56 pandemonium [<c0103ef3>] ? sysenter_do_call+0x12/0x33 Nov 28 18:31:56 pandemonium [<c01c64a6>] ? proc_get_sb+0xc6/0x160 Nov 28 18:31:56 pandemonium =======================
Aggiungete l'opzione nopat alla riga del kernel nel file /boot/grub/menu.lst e riavviate, dovreste risolvere il problema.
Risorse Esterne
Maggiori informazioni potete trovarle qui