BeagleBone Black gefriert

Question

Wir entwickeln gerade eine Anwendung für BeagleBone Black (unter Verwendung der Standard-Angstrom-Distribution). Unter GDB (von Netbeans aus der Ferne gesteuert) läuft es eine ganze Weile (5-10 Minuten), aber zu einem relativ zufälligen Zeitpunkt wird es eingefroren - die Heartbeat-LEDs hören auf zu flackern und ein kompletter Neustart ist erforderlich.

Eine Möglichkeit ist, dass es einfach die Anzahl der (USB-) Geräte ist, die dies verursachen. Wir sind über eine FTDI-Verbindung mit meinem Entwicklungs-PC verbunden (es gibt eine Client-Anwendung, die mit meinem BBB-Server kommuniziert). Es gibt einen 4-Wege-FTDI-Hub mit mehreren Geräten (3 derzeit), eine weitere einzelne FTDI-Verbindung mit einem anderen Bit Hardware angeschlossen. Auch zwei I2C-Geräte. Plus Maus und Tastatur.

Natürlich habe ich keine Beweise außer Hörensagen, dass es USB ist, das das Problem verursacht. Meine Software verursacht keine Signale, die Protokolldatei sagt mir sehr wenig mehr. Ich habe die Systemüberwachungsanwendung ausgeführt, um zu sehen, ob ich Speicher lecke, aber es scheint sich gut zu benehmen und stabil zu sein (obwohl CPU schleichte). Ich würde gerne einen Weg finden, dem, was scheitert, auf den Grund zu gehen, und würde mich über Hilfe freuen.

Answer 1

Schließlich ist die Unterseite des Kaninchen-Loch:

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

Es scheint, dass es ein Problem in der TI Silizium ist, insbesondere die Interrupt-Controller, die eine „geplapper“ bewirkt Interrupt abzufeuern wenn der USB überlastet wird. Dies führt zu einem versuchten Reset des Hosts und die Anwendung stirbt entsprechend. Dies erklärt, warum das Problem sowohl in Angrstrom als auch in Debian existiert - es ist kein Stapel/Treiber-Problem, sondern ein Problem mit dem TI-Chip. Autsch! Wir werden wahrscheinlich deshalb BBB als unsere Plattform der Wahl fallen lassen müssen.

Die Ausgabe von der Debug-seriellen Konsole bestätigt dies der Fall für unsere Anwendung zu sein:

_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

Es sieht also so aus, als würde man eine Maus in einen USB-Hub stecken und das Festhalten auf einer BBB kann dieses Problem verursachen, wenn andere Geräte auf dem Hub IO ausführen. Ein Kollege informiert mich, dass es auch Probleme mit solchen Dingen auf Raspberry Pi gibt. Nachdem die Maus ausgesteckt war, lief die Software über eine Stunde lang, ohne zu frieren. Beim Einstecken wurde nach etwa 10 Minuten eingefroren. Entfernen der Maus, läuft wieder, und es ist seit einer halben Stunde wieder ohne Problem.