BeagleBone Black si blocca

Question

Attualmente stiamo sviluppando un'applicazione per BeagleBone Black (utilizzando la distri standard Angstrom). Funziona abbastanza felicemente per un po '(5-10 minuti) sotto GDB (controllato da Netbeans da remoto) ma in un momento temporale relativamente casuale si blocca - i LED del battito cardiaco smettono di lampeggiare e si richiede un riavvio completo.

Una possibilità è che è semplicemente il numero di dispositivi (USB) che sta causando questo. Siamo collegati da un collegamento seriale FTDI al mio PC di sviluppo (c'è un'applicazione client che comunica con il mio server BBB). C'è un hub FTDI a 4 vie con più dispositivi (3 al momento) su questo, un'ulteriore singola connessione FTDI con un altro bit di hardware collegato. Inoltre, due dispositivi I2C. Più mouse e tastiera.

Ovviamente non ho altre prove se non la presenza di USB che causa il problema. Il mio software non causa alcun segnale, il file di registro mi dice molto di più. Ho eseguito l'applicazione di monitoraggio del sistema per vedere se sto perdendo memoria, ma sembra ben educata e stabile (anche se la CPU ha fatto creep up). Mi piacerebbe trovare un modo per arrivare al fondo di ciò che sta fallendo, e apprezzerei un po 'di assistenza.

Answer 1

Infine, il fondo del coniglio buche:

http://e2e.ti.com/support/arm/sitara_arm/f/791/t/308549

Sembrerebbe che c'è un problema nel silicio TI, in particolare il controllo delle interruzioni, che provoca una "balbettio" interrupt al fuoco quando l'USB diventa eccessivamente occupato. Ciò causa un tentativo di reset dell'host e l'applicazione muore corrispondentemente. Questo spiega perché il problema esiste sia in Angrstrom che in Debian - non è affatto un problema di stack/driver, ma un problema con il chip TI. Ahia! Probabilmente dovremo abbandonare BBB come nostra piattaforma d'elezione per questo motivo.

L'uscita dalla console seriale di debug conferma che questo sia il caso per la nostra applicazione:

_handle_irq+0x39/0x58) 
[ 466.343796] [<c0008551>] (omap3_intc_handle_irq+0x39/0x58) from [<c045b95b>] 
(__irq_svc+0x3b/0x5c) 
[ 466.359334] Exception stack(0xd2759cf8 to 0xd2759d40) 
[ 466.368332] 9ce0:              00000000 c0849ac0 
[ 466.382735] 9d00: 00000000 00000000 c07a2080 00000000 d2758000 00000002 d2759db0 00000003 
[ 466.397178] 9d20: c0812610 d2758000 b405025a d2759d40 c0031241 c0030f4e 40000133 ffffffff 
[ 466.411686] [<c045b95b>] (__irq_svc+0x3b/0x5c) from [<c0030f4e>] (__do_softirq+0x46/0x174) 
[ 466.426346] [<c0030f4e>] (__do_softirq+0x46/0x174) from [<c0031241>] (irq_exit+0x29/0x50) 
[ 466.440833] [<c0031241>] (irq_exit+0x29/0x50) from [<c000c8cf>] (handle_IRQ+0x3f/0x5c) 
[ 466.454864] [<c000c8cf>] (handle_IRQ+0x3f/0x5c) from [<c0008551>]  (omap3_intc_handle_irq+0x39/0x58) 
[ 466.470777] [<c0008551>] (omap3_intc_handle_irq+0x39/0x58) from [<c045b95b>](__irq_svc+0x3b/0x5c) 
[ 466.486319] Exception stack(0xd2759db0 to 0xd2759df8) 
[ 466.495351] 9da0:          00000002 00000000 00007d00 00000000 
[ 466.509782] 9dc0: c07c81d0 c07c81d0 c07c75dc 00007d02 0000007d 00000003 c0812610 de5f4b40 
[ 466.524147] 9de0: 00000100 d2759df8 c0025b2d c0025bea 00000133 ffffffff 
[ 466.536019] [<c045b95b>] (__irq_svc+0x3b/0x5c) from [<c0025bea>] (omap3_noncore_dpll_set_rate+0x1f2/0x330) 
[ 466.553005] [<c0025bea>] (omap3_noncore_dpll_set_rate+0x1f2/0x330) from [<c0383273>] (clk_change_rate+0x1b/0x52) 
[ 466.570813] [<c0383273>] (clk_change_rate+0x1b/0x52) from [<c03832fb>] (clk_set_rate+0x51/0x72) 
[ 466.586199] [<c03832fb>] (clk_set_rate+0x51/0x72) from [<c034ba29>] (cpu0_set_target+0xf9/0x198) 
[ 466.601754] [<c034ba29>] (cpu0_set_target+0xf9/0x198) from [<c0348c5d>] (__cpufreq_driver_target+0x4d/0x70) 
[ 466.618890] [<c0348c5d>] (__cpufreq_driver_target+0x4d/0x70) from [<c034b33b>] (dbs_check_cpu+0x123/0x134) 
[ 466.635897] [<c034b33b>] (dbs_check_cpu+0x123/0x134) from [<c034ad31>] (od_dbs_timer+0x4d/0xb0) 
[ 466.651283] [<c034ad31>] (od_dbs_timer+0x4d/0xb0) from [<c003c8c5>] (process_one_work+0x1b5/0x2c0) 
[ 466.667088] [<c003c8c5>] (process_one_work+0x1b5/0x2c0) from [<c003cca3>] (worker_thread+0x19b/0x258) 
[ 466.683355] [<c003cca3>] (worker_thread+0x19b/0x258) from [<c003fb8f>] (kthread+0x67/0x74) 
[ 466.698026] [<c003fb8f>] (kthread+0x67/0x74) from [<c000c0dd>] (ret_from_fork+0x11/0x34) 
[ 466.712148] drm_kms_helper: panic occurred, switching back to text console 
[ 407.924892] CAUTION: musb: Babble Interrupt Occurred 
[ 407.965570] CAUTION: musb: Babble Interrupt Occurred 
[ 408.026994] gadget: high-speed config #1: Multifunction with RNDIS 
[ 413.918684] musb_g_ep0_irq 710: SetupEnd came in a wrong ep0stage wait 

Answer 2

Quindi sembra che collegare un mouse a un hub USB e attaccarlo su un BBB possa causare questo problema se ci sono altri dispositivi sull'hub che fanno IO. Un collega mi informa che ci sono problemi con cose del genere anche su Raspberry Pi. Dopo aver scollegato il mouse, il software ha funzionato per oltre un'ora senza blocco. Ricollegandolo, c'era un congelamento dopo circa 10 minuti. Rimozione del mouse, esecuzione di nuovo, e sta andando ancora per mezz'ora senza alcun problema.