[TOPIC UFFICIALE] Problema riavvio durante chiamate

[71kikko71]

Originariamente inviato da 71kikko71
ciao, come faccio a postare il log che ho fatto? graziel

Fatto, questo .

Grazie.

Gli errori in questo logcat sono 4:


1) 10-21 03:26:05.365: E/PowerManagerService(324): Excessive delay setting brightness: 221ms, mask=2

2) 10-21 03:26:09.419: E/Trace(2104): error opening trace file: No such file or directory (2)

3) 10-21 03:26:13.935: E/audio_hw_primary(127): Entering IN_CALL state, in_call=0

4) 10-21 03:26:13.958: E/audio_hw_primary(127): Opening modem PCMs
: E/(): Device disconnected


al 4 errore il device si è riavviato.

Dal primo errore, 'E/PowerManagerService(324): Excessive delay setting brightness: 221ms, mask=2', al quarto -quando il telefono si è riavviato - sono passati 8 secondi.
Il riavvio si è verificato con il tag 'audio_hw_primary', che è un LOG_TAG definito nel sorgente android audio_hw.c, introdotto dalla rel. 4.0.3 in avanti.
E' possibile che il quarto errore sia però solo una conseguenza dello stato di errore propagato dal punto 1, ovvero un eccessivo tempo di attesa nell'impostare la luminosità dello schermo.

Il Sensore di prossimità è comunque il principale responsabile. Nella sezione modding del Galaxy Nexus di questo forum è presente una rom che nativamente ne disabilità qualsiasi funzionalità e chiaramente il Galaxy Nexus non si riavvia più durante le telefonate

Gli errori che mi hai gentilmente postato sono inoltre raccolti in un bug aperto sul prodotto Android 4.1.1 direttamente a Google (Issue 37485 - android - Galaxy Nexus reboot itself after new call start (only sometimes) 4.1.1 (JRO03C) - Android - An Open Handset Alliance Project - Google Project Hosting),

solo che -attualmente- lo stato del bug è ancora in 'Open' e non è stato assegnato a nessuna area di sviluppo...

Domanda banale: puoi provare a riprodurre il riavvio ma con le impostazioni di luminosità del display manuale e non automatica, per vedere se si riproduce? (Impostazioni->Display->).
Se poi nel test mantieni ancora il logcat aperto e lo ri-posti, possiamo capire se ricompare l'errore dell'excessive delay setting brightness in concomitanza con l'errore audio_hw_primary.

Grazie della risposta, io non uso la luminosità automatica ma sempre manuale, ho ricontrollato ed è così. In questa fase di riavvio, che avrò fino a quando non toglierò la batteria ho provato con l'applicazione proximity finder e anche con quella in esecuzione il cellulare crasha.


Inviato dal mio Galaxy Nexus usando Androidiani App

[71kikko71]

In questa fase di riavvio, dimenticavo di dire che se uso le cuffie a telefonare, non si riavvia, appena le estraggo crasha!


Inviato dal mio Galaxy Nexus usando Androidiani App

[HalphaZ]

Sto cercando di capire: l'errore parla di un eccessivo tempo per impostare la luminosità, ma non parla di sensori.
Da profano del codice Android, direi che si tratta più di un problema al sistema di gestione delle luminosità che un problema al sensore. Cioè se il sensore non funzionasse rimarrebbe bloccato su un certo valore e lo schermo rimarrebbe acceso o spento. Ma da come si legge dell'errore pare che sia un problema dell'attuatore più che del sensore.
Da profano, sicuramente ne sai di più tu :-)

[HalphaZ]

Sto cercando di capire: l'errore parla di un eccessivo tempo per impostare la luminosità, ma non parla di sensori.
Da profano del codice Android, direi che si tratta più di un problema al sistema di gestione delle luminosità che un problema al sensore. Cioè se il sensore non funzionasse rimarrebbe bloccato su un certo valore e lo schermo rimarrebbe acceso o spento. Ma da come si legge dell'errore pare che sia un problema dell'attuatore più che del sensore.
Da profano, sicuramente ne sai di più tu :-)

L'ultima frase ha un periodo infelice...
Volevo direi che a me da profano sembra così; ma certamente tu pare ne sappia di più.

[skyrun]

Update: Problema risolto. Spero.
Sono 48 ore che lo ho ripreso dall'assistenza. Finora nessun riavvio. Ho fatto/ricevuto parecchie telefonate. Anche usando il numero verde del mio operatore. Mi sono sorbito tutte le info nei vari settori...
Utilizzo normale, nè vivavoce né auricolare. Luminosità in automatico.
Partito con la 4.0.4, da un giorno e 1/2 è alla 4.1.2.
L'INTERVENTO (SPERO) RISOLUTIVO È STATA LA SOSTITUZIONE DELLA SCHEDA LOGICA (La main board, credo).
Sostituita anche la batteria, ma non credo sia quella la causa (anche considerando altre esperinenze condivise qui).

Credo che adesso sia come gli altri nexus in circolazione. Sicuramente ora ho una componentistica meno attuale della C8, più vecchia, ma fa il suo dovere.

Vedere mio post precedente.
Ribadisco la mia opinione, personale e da prendere come tale: non è il sensore il problema, ma è come questo viene gestito. Forse incompatibilità tra componenti.

M.

[frank17next]

Allora è probabile che lo stesso errore di delay eccessivo sul set del brightness sia anch'esso una conseguenza del freeze + restart, che al livello di quell'errore è già in essere (potrebbe addirittura essere innocuo nel contesto del restart).
Oppure un errore del genere denota un timeout nell'attesa di un valore, che non arriva (dal sensore?), ma dopo che logga quell'errore, passano 8 secondi in cui il sistema riesce tranquillamente a popolare il logcat, si presuppone che la condizione anomala che causa il restart non è ancora acquisita.

Rimane però l'errore con tag audio_hw_primary, che poi è l'ultimo errore loggato dal sistema prima del restart.

A questo punto poniamo i riflettori sugli errori Entering IN_CALL state, in_call=0 e Opening modem PCMs.

Consultando i sorgenti ICS di Android, in particolare audio_hw.c (presa dai sorgenti ics del 'crespo', in nexus s, ma è uguale anche per gnexus)

si trova quell'errore, che viene loggato da questa funzione: 'start_call' (ma come, 'avvia chiamata'? Allora il sistema da lì è praticamente bloccato... per lo meno lo è la scrittura del log...):

static int start_call(struct tuna_audio_device *adev)
{
    LOGE("Opening modem PCMs");

    pcm_config_vx.rate = adev->wb_amr ? VX_WB_SAMPLING_RATE : VX_NB_SAMPLING_RATE;

    /* Open modem PCM channels */
    if (adev->pcm_modem_dl == NULL) {
        adev->pcm_modem_dl = pcm_open(0, PORT_MODEM, PCM_OUT, &pcm_config_vx);
        if (!pcm_is_ready(adev->pcm_modem_dl)) {
            LOGE("cannot open PCM modem DL stream: %s", pcm_get_error(adev->pcm_modem_dl));
            goto err_open_dl;
        }
    }

    if (adev->pcm_modem_ul == NULL) {
        adev->pcm_modem_ul = pcm_open(0, PORT_MODEM, PCM_IN, &pcm_config_vx);
        if (!pcm_is_ready(adev->pcm_modem_ul)) {
            LOGE("cannot open PCM modem UL stream: %s", pcm_get_error(adev->pcm_modem_ul));
            goto err_open_ul;
        }
    }

    pcm_start(adev->pcm_modem_dl);
    pcm_start(adev->pcm_modem_ul);

    return 0;

err_open_ul:
    pcm_close(adev->pcm_modem_ul);
    adev->pcm_modem_ul = NULL;
err_open_dl:
    pcm_close(adev->pcm_modem_dl);
    adev->pcm_modem_dl = NULL;

    return -ENOMEM;
}

Il fatto è che l'ultimo errore loggato riguarda PCM (Pulse-code modulation), che -fondamentalmente- è il modo in cui il modulo radio dello smartphone comunica.

La questione diventa:
Come più volte riferito da moltissimi utenti, ci troviamo di fronte ad un errore completamente hw e questi errori intercettati sono semplici conseguenze di un malfunzionamento a monte di natura hw, che il log di sistema, a quel livello, non riesce a loggare nel logcat
E' però curioso notare che l'errore sul PCM, l'ultimo che viene scritto, non abbia a che vedere con il sensore di prossimità.

- avete provato a telefonare con dialer di terze parti, di cui il play store è pieno?

[frank17next]

Update: Problema risolto. Spero.

Ribadisco la mia opinione, personale e da prendere come tale: non è il sensore il problema, ma è come questo viene gestito. Forse incompatibilità tra componenti.

M.

E' molto probabile.

Chiaramente, con gli strumenti a nostra disposizione (consultare il logcat) è molto difficoltoso risalire alla reale causa. Dovremmo misurare il voltaggio della batteria, i condensatori, i valori che vengono scritti nei registri della cpu, quelli nella ram, ecc.. insomma andrebbe fatto un vero debug sull'hardware, cosa che possono fare solo nei laboratori samsung

[gigiogsr]

Ma non capisco noi o meglio voi comuni utilizzatori riuscite a diagnosticare dei bug ed eventuali cause e Samsung??? Vergogna dovrebbero risolvere e ribadisco richiamare i nostri Nexus per sistemarli....


Inviato dal mio Galaxy Nexus usando Androidiani App

[frank17next]

Ma non capisco noi o meglio voi comuni utilizzatori riuscite a diagnosticare dei bug ed eventuali cause e Samsung??? Vergogna dovrebbero risolvere e ribadisco richiamare i nostri Nexus per sistemarli....


Inviato dal mio Galaxy Nexus usando Androidiani App

Sicuramente.

La' dove noi possiamo arrivare, ci arriviamo e gratis, senza pretendere di risolverlo (o anche si, perchè no, se alla nostra portata), fermo restando che la pretesa della sostituzione deve esserci, come consumatori il prodotto deve funzionare. Punto.

La questione del richiamo da parte di Samsung è complessa, in quanto l'intera faccenda presenta delle discordanze e dei limiti di comprensione non indifferenti:
1) Il problema parrebbe hardware, tuttavia l'unica traccia/collocamento in rete che si ha è un bug aperto su Android! (Issue 37485 - android - Galaxy Nexus reboot itself after new call start (only sometimes) 4.1.1 (JRO03C) - Android - An Open Handset Alliance Project - Google Project Hosting , il 15 Settembre 2012, ancora in stato: unassigned).
Solo qui, chi gestisce i ticket dei bug Google, riesce a capire che è un problema che non riguarda Android 4.1.x, poichè questo sistema funziona perfettamente sui Galaxy Nexus il cui step di produzione sia diverso da C8. E non fornisce il problema sul Nexus S.
2) Samsung deve fare i conti con una partita difettosa di Galaxy Nexus, ci vuole tempo. moolto tempo. Si devono fare le riunioni, organizzare tavoli e tavoli di confronto, per scegliere che strategia adottare. La prima, sicuramente, è quella di prendere tempo e se lo sono presi. Galaxy Nexus mandati in assistenza da Agosto, ritornati 1, 2 e 3 volte semplicemente formattati o downgradati a 4.0.4 o con factory reset. Il problema continua, quindi -solo ad Ottobre- si iniziano a leggere le esperienze di qualche utente che ha ricevuto la sostituzione della scheda logica (eh, grazie che risolve, gli cambi l'intero hw interno). Per la cronaca, il proximity sensor non è sulla scheda logica

[skyrun]

E' molto probabile.

Chiaramente, con gli strumenti a nostra disposizione (consultare il logcat) è molto difficoltoso risalire alla reale causa. Dovremmo misurare il voltaggio della batteria, i condensatori, i valori che vengono scritti nei registri della cpu, quelli nella ram, ecc.. insomma andrebbe fatto un vero debug sull'hardware, cosa che possono fare solo nei laboratori samsung

Concordo.
Infatti anche se il telefono è piccolo nelle dimensioni, non significa che sia piccolo anche nella complessità.
Solo pochi anni fa costruire qualcosa di simile avrebbe coportato l'adozione di un mobile contenitore molto grande.
Ora è piccolo, ma la componentistica e le sue interazioni con il software restano estremamente complesse.
Per descriverle nei dettagli credo siano necessari parecchi raccoglitori A4 pieni di migliaia di pagine.

Hai ragione in pieno: una analisi approfondita richederebbe mezzi non da poco!
Peccato non abbiano una linea diretta al quale se non altro inviare dati. E magari averne.
Una sorta di "open souce hardware"...

Ti faccio i miei complimenti per la competenza e la chiarezza nelle esposizioni. Pur nn essendo io esperto a sufficienza da poterle seguire appieno.

M.