crash di knotify4

Ciao,

prima cosa serve sapere se si tratta di versione devel o milestone2 (scusa ma scriverlo è più veloce rispetto a che vada a rileggere i tuoi post precedenti, inoltre in ogni caso potresti avere diverse installazioni. Poi quando avrò tempo aggiungerò un campo per specificarlo nel forum).

Poi, se e quando ci sono dei crash la metodologia universale consiste nel vedere il backtrace. Normalmente se dici che è andato in crash knotify dovrebbe essere perché hai visto comparire una finestra che serve apposta per generare il backtrace e che fornisce dettagliate spiegazioni e istruzioni in merito. Questo (o questi) backtrace dovrebbe poi essere allegato qua o inviato a reports <at> openmamba.org. Sempre a questo indirizzo sarebbe utile ricevere un report del sistema data la tipologia del problema che descrivi. Grazie.

Dev’essere un problema legato al driver snd_via82xx. Mi puoi copiare ciò che restituisce il seguente comando dato da un terminale?

cat /proc/asound/cards

Grazie.

Anzi, proverei ad editare da root il file /etc/asound.conf e scommentare le due righe:

#buffer_size 4096

in modo che diventino:

buffer_size 4096

Riferimenti:

http://alsa.opensrc.org/DmixPlugin (fai un find di ‘snd-via82xx’ nella pagina)

http://us.generation-nt.com/answer/alsa-dmix-via82xx-limitations-help-173577871.html

Eventualmente se non cambia niente prova anche sostituendo 4096 con 2048.

Altra cosa: i pacchetti di alsa sul tuo computer provengono dal repository milestone2-makedist, questo sarebbe meglio disabilitarlo per gli aggiornamenti automatici in quanto contiene pacchetti in lavorazione e potenzialmente instabili. Niente in contrario invece se vuoi abilitare milestone2-kernel-next.

Altra cosa 2: se quanto sopra non funziona ti chiedo anche l’output del seguente comando:

alsaplayer -d dmix

Ciao e auguri,

il comando alsaplayer -d dmix dovrebbe restituire varie righe di informazioni utili, non so perché il tuo output sia solo di due righe. Prova a chiudere il browser e qualunque cosa che possa usare il suono prima di lanciare il comando.

Sto cercando la soluzione corretta del problema ma nel peggiore dei casi lanciando:

sudo update-alternatives --config asound.conf

e selezionando il numero corrispondente a /etc/asound.conf.dummy disattivi il mixing dei suoni di alsa e non dovresti più avere i crash ma così solo un’applicazione alla volta potrà emettere suoni, quindi non è un granché come soluzione ma magari riesci a usare meglio il sistema nel frattempo.

Riguardo alla domanda sul syslog, non so se vorresti avere il vecchio syslog di cui syslog-ng è una versione più recente e comunemente diffusa. Se è giusto quello che ho capito, la risposta è che in openmamba l’unica versione mantenuta è syslog-ng e che non sono noti motivi per cui bisognerebbe mantenere anche il vecchio syslog.

I suoni di kde escono tramite il plugin dmix e i backtrace che mi hai mandato mostrano che il crash avviene in questo plugin. Che il problema non si verifichi disattivando i suoni di kde non mi stupisce ma la causa del problema pare essere nel basso a livello di alsa, dove si stava indagando.

Application: KDialog (kdialog), signal: Aborted

[KCrash Handler]

#6  0x4321dfa7 in raise () from /lib/libc.so.6

#7  0x4321fa82 in abort () from /lib/libc.so.6

#8  0xafd91a6b in snd_pcm_dmix_close () from /usr/lib/libasound.so.2

...

Comunque se in passato il sistema funzionava correttamente potrebbe essere il caso di retrocedere i pacchetti di alsa in quanto tu dovresti avere installate le versioni che provengono dal repository milestone2-makedist che, se non mi confondo con un’altra segnalazione, avevi attivo.

L’operazione si effettua con un comando del genere:

sudo smart install libalsa-1.0.25 alsa-utils-1.0.25 libalsa-plugins-1.0.25

Altrimenti come workaround puoi configurare il sistema del suono di kde per usare un dispositivo di riproduzione hardware diverso da “System default (recommended)”, ma ovviamente questo è un workaround mentre la soluzione del problema per me rimane quella per la quale stavo scrivendo fino al post precedente ma che non so come risolvere senza ulteriori informazioni o senza poterci lavorare direttamente.

Sulla milestone2 i file di log di sistema sono come configurati in /etc/syslog-ng.conf. Puoi agire su questa configurazione per personalizzare i file come preferisci e se ricavi una soluzione migliore e più ordinata non solo per i tuoi gusti possiamo poi anche integrarla upstream.

Ciao,

per retrocedere i pacchetti puoi guardare nel canale milestone2-makedist e fare a mano in quanto non mi pare che ci sia una procedura automatica.