[SOLVED] nuova -current e virtualbox. problema opengl (intel

[ZeroUno]

Ciao.

Ho una slackware current e su questa uso virtualbox.

Quando è uscito il recente aggiornamento massiccio ci sono andato cauto. Prevedendo problemi con virtualbox (visto che ad ogni cambio kernel va ricompilato il modulo) ho installato solo il kernel, quindi ho ricompilato il modulo (che ho dovuto patchare per farlo funzionare per kernel 4), ho riavviato e mi sono assicurato che virtualbox funzionasse correttamente.
Sono stato qualche giorno così e non ho avuto problemi di sorta.
Nel frattempo ho seguito i bug report che si sono susseguiti sulle schede grafiche intel (che ho) sul nuovo X, e quando tutto è stato fixato mi sono deciso a fare il resto degli aggiornamenti.

Da allora quando starto una macchina virtualbox, tempo un minuto massimo e il sistema panica. Purtroppo si limita a lampeggiare la spia del caps lock (non ho le spie del numlock e blockscreen quindi non saprei dire se lampeggerebbero) e non da nessun messaggio; probabilmente in console dà qualche messaggio del panic ma non è possibile leggerlo visto che sono sotto X.

Finalmente dopo qualche giorno oggi ho trovato tempo per approfondire.
Sospettando un problema con X ho provato ad avviarlo da riga di comando senza fargli avviare l'interfaccia grafica
VBoxManage --nologo startvm XP --headless
e anche quà panicava.

Notare che panica molto prima di caricare il driver video di windows, quindi non può essere un conflitto dell'accellerazione grafica, anzi, a volte non arriva nemmeno a cominciare il boot del S.O.

Ho provato ad avviarlo allora da console, cioè senza aprire per niente X.
Parte.
Riesco anche a collegarmi da remoto, quindi arriva a caricare la rete e tutti i servizi.

Bene, ora starto X (a vm running), tempo un minuto e il sistema ri panica.
Quindi X centra per forza.

Disattivo gli effetti desktop (opengl) di kde e finalmente tutto funziona.
Ora ho la macchina virtuale correttamente startata, con la gui, ma ho gli effetti grafici di kde disabilitati.

Negli ultimi aggiornamenti (che ho installati) ci sono tra gli altri i pacchetti:
mesa-10.6.5-x86_64-1
xf86-video-intel-git_20150824_3e07681-x86_64-1

.
.
purtoppo proprio mentre scrivevo questo post, con 20 minuti abbondanti che le VM erano up/running ed effetti opengl disabilitati, il sistema ha ripanicato.

Inutile dire che sui log non c'è assolutamente nulla perchè il sistema non fa in tempo a scrivere nulla.


Che posso fare?

edit:
aggiungo che da quando ho aggiornato X, all'avvio ottengo

vboxclient.png (10.98 KiB) Visto 4307 volte

edit2:
Il fatto che gli effetti desktop di kde con opengl non siano running non toglie il fatto che opengl è comunque configurato in X, e come una applicazione che lo usa si apre il sistema crasha. Per esempio ho provato aprendo glxgear e tempo qualche secondo ha crashato.
Nota (se può essere utile): si tratta di un portatile con connesso un monitor esterno, quindi uso due schermi. Il panic avviene sia che mi trovo su uno schermo sia sull'altro (considerando che prima ha chrashato anche quando era lanciato da cmd line e quindi senza la gui aperta).

[ponce]

non uso virtualbox quindi posso contribuire con un aiuto molto limitato: l'unica cosa che mi viene a mente (non so se hai gia' provato) e' tentare di forzare UXA per l'accelerazione.

da root

Codice: Seleziona tutto

cat >> /etc/X11/xorg.conf.d/20-intel.conf << "EOF"
Section "Device"
        Identifier "Intel Graphics"
        Driver "intel"
        Option "AccelMethod" "uxa"
EndSection
EOF

poi riavvia X.

tieni di conto comunque che, da quel poco di esperienza che ho avuto in passato con virtualbox, mi sembra che rimanga sempre leggermente indietro rispetto ai kernel/X recenti e mi e' capitato spesso che avesse bisogno di patch.

metti insieme a questo che il driver intel in current per l'accelerazione usa SNA di default (scelta degli sviluppatori intel) che e' un codice, a detta di qualcuno, ancora non completamente testato o almeno non quanto UXA.

insomma, IMHO non userei virtualbox su una macchina con kernel/software bleeding edge: infatti ho smesso di usarlo tanto tempo fa, prima ancora che diventasse Oracle, e sono passato felicemente a qemu con kvm e virt-manager.

Ah, non se se si applica al tuo caso, ma qui al lavoro, dove ho una macchina desktop con una scheda grafica integrata intel, ho avuto dei kernel panic anch'io pero' col kernel 4.2, non con quello di default in Slackware.

[ZeroUno]

No, non ho provato niente perchè fondamentalmente non ci capisco molto di accelerazione e solo oggi mi sono messo a fare prove più serie e collegare l'accelerazione con il crash.

Ho messo quel parametro che mi hai detto ma non risolve.

C'è modo di capire una applicazione che cosa sta facendo/tentando di fare lato X?
Purtroppo il sistema panica prima che possa scrivere nulla e non sono riuscito ad attivare il coredump lato kernel (su solaris quando il sistema panica si fa un dump della ram in modo che poi al reboot posso capire che è successo).


Quello che sto cercando di capire è perchè mi ha panicato pure quando la macchina virtuale è accesa ma lanciata solo come demone (ma questo lo devo riverificare), cioè a schermo non c'è niente; quindi il legame con l'interfaccia non è stretto.


edit: Per la storia del kernel, come dicevo, ho volutamente installato gli aggiornamenti non tutti insieme ma separati, prima il kernel (di cui mi sono mantenuto il backup del vecchio), proprio perchè se avessi avuto problemi mi sarei impazzito di meno a capire la componente che dava fastidio; ho tenuto in testing il nuovo kernel con vbox per qualche giorno e non ho avuto problemi.

[ZeroUno]

Per ora ho trovato un compromesso che sembra stia funzionando, in attesa di trovare una soluzione.

Visto che con il pc non ci devo giocare, ho disabilitato completamente opengl
Section "Module"
Disable "glx"
EndSection

Per gli effetti desktop ho settato XRender che è sufficiente per la maggior parte di quello che devo fare e non mi crasha più l'host

[ponce]

forse questo c'entra qualcosa

https://www.linuxquestions.org/question ... ost5418017

[ZeroUno]

Domani magari provo a downgradare il kernel (me lo ero salvato in previsione), solo che come dicevo con il kernel 4.1.6 e X vecchio funzionava, ma è una prova che va fatta. Purtroppo X non l'ho salvato.

[ponce]

non credo che tu possa usare il kernel vecchio: dovrai compilarci i moduli di virtualbox e dubito che tu lo possa fare se il kernel e' stato compilato con glibc/gcc diversi (cosi' e' per la vecchia versione).
se lo vuoi usare su current credo che tu debba necessariamente compilartene una vecchia versione da te: li' suggeriscono la 3.18.16, potresti usarla col config della 3.18.11.

comunque, a quello che ho capito, il problema che e' riportato li' e' relativo ad un aggiornamento del kernel (anche patch per kernel piu' vecchi) che ha rotto qualcosa in virtualbox e per cui ci vorrebero dei fix per quest'ultimo (non per il kernel), solo che, come al solito con virtualbox (e, come spiegavo, e' il motivo per cui lo evito come la peste) tardano ad arrivare.

[ZeroUno]

Recuperare i moduli vecchi non sarebbe stato un problema, solo che visto che con kernel 4 ormai funzionava ho cancellato il backup del kernel precedente.

Comunque è risolto.
Non so bene quali dei due eventi sia stato il risolutivo ma:
1) ho aggiornato virtualbox: la versione 4.3.30 a differenza della 4.3.24 supporta meglio il kernel 4; infatti per ricompilare i moduli non li ho dovuti patchare e negli script rc è stata modificata una regex per aggiungere il riconoscimento del kernel 4.
2) pochi minuti dopo la fine della ricompilazione di virtualbox, prima di riavviare il pc, è uscito l'aggiornamento del pacchetto mesa, passando da 10.6.5 a 10.6.6, aggiornando di fatto il componente che causava il fault.

Ora ho due vm attive di cui una con windows aero; ho gli effetti kde con opengl 3.1 attivi e glxgear che sta un pezzo su un monitor e un pezzo su un altro, e non ha ancora panicato.


L'aggiornamento di vbox supporta meglio il kernel 4 quindi è molto probabile che sia risolutivo, ma è anche vero che prima di aggiornare X funzionava bene con il kernel 4, quindi l'idea che l'upgrade di mesa abbia risolto non mi abbandona.
Nota che tra le varie prove successive ho anche provato a downgradare mesa da 10.6.5 a 10.6.4 senza risolvere.

[ponce]

ipotizzo che il problema sia stato risolto dall'aggiornamento di virtualbox, ma l'importante e' che sia risolto a prescindere.
comunque tieni di conto che, come dicevo, usando virtualbox con un sistema bleeding-edge potrebbe facilmente ripresentarsi qualcosa di simile.

[ZeroUno]

Non saprei..
Da quando ho installato VirtualBox (prima usavo VMware, che in realtà avevo preferito continuare ad usare visto che ce l'ho sui sistemi di produzione) anche lui ha fatto parecchi aggiornamenti, quindi gli è stato dietro all'aggiornamento di X.
Non vedo perché un problema simile non potrebbe presentarsi con kvm. Mi risulta che anche su quello devi ricompilare i moduli ad ogni aggiornamento del kernel.

E comunque non mi risulta che slackware sia tantissimo bleeding-edge.
A parte questo aggiornamento grosso non ce ne sono stati tanti altri.

[ponce]

Non saprei..
Da quando ho installato VirtualBox (prima usavo VMware, che in realtà avevo preferito continuare ad usare visto che ce l'ho sui sistemi di produzione) anche lui ha fatto parecchi aggiornamenti, quindi gli è stato dietro all'aggiornamento di X.
Non vedo perché un problema simile non potrebbe presentarsi con kvm. Mi risulta che anche su quello devi ricompilare i moduli ad ogni aggiornamento del kernel.

si, ma la compilazione avviene insieme a quella del kernel, perche' i moduli fanno gia' parte di linux da parecchi anni, non deve essere fatto a parte (come per virtualbox).
lo sviluppo di kvm, cosi' come ad esempio quello dei cgroups (usati da LXC), avviene insieme al kernel non e' una cosa fatta da terze parti e testata in seguito allo sviluppo di linux sopra allo stesso.
credo che il discorso sarebbe molto diverso se Oracle rilasciasse tutto open source e Linus decidesse di integrarli ma, visti i precedenti, non credo proprio che succedera' mai.

E comunque non mi risulta che slackware sia tantissimo bleeding-edge.
A parte questo aggiornamento grosso non ce ne sono stati tanti altri.

beh, in current ci sono spesso aggiornamenti alle ultimissime release di alcuni software (gcc e glibc su tutti, ma anche X, ecc.) e li' vengono fuori le magagne.
qemu (e kvm) non mi hanno MAI dato problemi in seguito agli aggiornamenti, a differenza di virtualbox, che ho abbandonato per quel motivo: non mi e' possibile utilizzare un software se non posso aggiornare current per mesi perche' poi non girerebbe.
comunque a usare virtualbox su slackware stable non ci sono grossi problemi, il discorso che faccio vale ovviamente solo per current.