slacky.eu

A questo punto si può assumere che i driver legacy non funzionano correttamente sul tuo sistema, bloccando l'intero X quando si avviano.
Se non hai assoluto bisogno dei driver proprietari per avere prestazioni grafiche "piene" (programmi che necessitano di OpenGL 3 o 4, soprattutto) puoi sempre tornare ai driver opensource che funzionavano anche in precedenza.
Se non vado errato, ti dovrebbe bastare rimuovere il pacchetto fglrx e reinstallare mesa con un "upgradepkg --reinstall", per essere sicuri che non ci siano ancora in giro file provenienti dal driver proprietario.
Ricordati anche di togliere dalla blacklist il driver radeon (rimuovi il file che hai creato in /etc/modprobe.d) e di rimuovere i file di configurazione di X (/etc/X11/xorg.conf e /etc/X11/xorg.conf.d/*.conf) per permettere ad X di autoconfigurarsi correttamente.

Ho capito, quindi anche se mai dovessi riuscire a compilare il kernel current sarebbe comunque difficile far funzionare la scheda video con i driver della casa?
Mi è venuto un dubbio, io ho seguito alla lettera quel wiki e come dicevo dando xorgsetup e modificando inserendo soltanto fglrx su card0 la scheda video partiva, ma partiva usando radeon o fglrx?

Innanzitutto, la guida che hai seguito non menziona in alcun punto l'uso di xorgsetup perché incasina la vita se usi un driver proprietario.
Assodato questo, dagli output che hai riportato in precedenza quando X partiva è chiaro che fglrx non funzionava perché

1. fglrxinfo restituiva sempre un X error
2. non avendo posto in blacklist il modulo radeon, questo veniva caricato all'avvio impostando anche il KMS (quando cambia la risoluzione durante il boot è un chiaro sintomo di KMS attivo), impedendo al modulo fglrx di caricarsi correttamente

A questo punto, stanti le premesse espresse poc'anzi nel mio post precedente, secondo me ti conviene "ritornare all'ovile" del driver opensource e sperare che a breve AMD pubblichi una versione aggiornata dei driver legacy, prima di riprovare col driver proprietario.

Anche secondo me - se posso - ti conviene riportare tutto a default, lanciare X e magari postare il log, almeno si vede cosa carica coi driver open ed eventualmente si può tentare qualche "colpaccio".

Purtroppo quando i driver ATI - e non solo - entrano nella fase "legacy" bisogna farsi il segno della croce.

La prova del 9 sarebbe vedere se partono con slackware 13.37. Potresti fare un'immagine di slack 14 con clonezilla in modo da perdere il meno tempo possibile.

@DarkNeo: consolati un pochino sapendo che non sei solo

potrei provare a ricompilare mettendo il kernel 3.6.10 usando questo metodo di submax http://submax.altervista.org/index.php? ... pkg-en.php, magari sta volta ci riesco a fare un .config che non mi da kernel panic

È inutile che ti metti a ricompilare il kernel...
Innanzitutto i driver legacy supportano al massimo il kernel 3.4 (è riportato nella pagina del download) e, in secondo luogo, il tuo problema risiede nel "driver" X di fglrx, non nel kernel.
Dato che non sei l'unico ad avere questo problema è probabile che si tratti di un qualche difetto dei driver proprietari, quindi non puoi far altro che aspettare un'eventuale nuova versione corretta (improbabile, ma chissà, siam vicini a Natale...) tornando ad usare i driver opensource nel frattempo.

Ma a prescindere dai driver proprietari quel tool potrebbe aiutarmi a creare .config che mi eviterebbero kernel panic?

Assolutamente no. Quello che fa quel tool è solo compilare e pacchettizzare un kernel già configurato.
Se i kernel panic che ti preoccupano sono quelli elencati in questo thread, devi assicurararti (come ti hanno già detto, tra l'altro) di compilare anche il modulo per i controller SATA/PATA presenti sulla tua scheda madre, oltre ai moduli per i filesystem che ti interessano.
Se posso darti un suggerimento, riparti da un .config standard della distribuzione (quello del generic, per esempio) e da menuconfig cambia la configurazione in modo che il modulo per ext4 (se è il filesystem della tua root) sia compilato staticamente. Prova poi ad avviare questa immagine (che non dovrebbe necessitare di nessuna initrd) e, se il sistema parte, puoi poi procedere ad ulteriori potature (anche se non credo ne beneficerai enormemente).

Cioè? posso usare lo stesso configure del kernel di default di slacware 14 per mettere ad esempio il 3.6.10?
ulteriore domanda, ma avrei gli stessi problemi con la scheda grafica se dovessi installarli su ubuntu?

DarkNeo ha scritto:Cioè? posso usare lo stesso configure del kernel di default di slacware 14 per mettere ad esempio il 3.6.10?

Certo. Copia il .config di uno dei kernel di default con Slackware (li trovi sotto source/k) e ponilo nella directory dei sorgenti del nuovo kernel (mantenendo sempre come nome .config) e usa Se sono avvenuti cambiamenti "radicali" tra la versione alla quale il .config che hai copiato afferisce e quella che ti accingi a compilare ti verranno poste delle domande riguardanti le novità. Una volta terminate le domande potrai procedere con la compilazione tramite make oppure apportare altre modifiche tramite menuconfig/xconfig.
Come ti ho già detto, tuttavia, i driver legacy proprietari non compileranno mai su kernel più nuovi del 3.4, a meno di applicare alcune patch...

DarkNeo ha scritto:ulteriore domanda, ma avrei gli stessi problemi con la scheda grafica se dovessi installarli su ubuntu?

Ne avresti anche di più se usassi l'ultima versione di Ubuntu che, se non vado errato, usa Xorg 1.13 che non è supportato dai driver legacy, percui dovresti anche eseguire un downgrade del server X prima di poter provare i driver.
Ovviamente c'è chi ha già provveduto a preparare la pappa per tutti con un PPA apposito.

possibile che io li abbia nella directory kernels/huge.s/config?

Sul disco di installazione? Certo che è possibile.

quindi devo rinominare quel config in .config e spostarlo nel sorgente del kernel?

Sì