Reboots uns cpu stalls

[chris_g]

Hi,

ich bin seit kurzem besitzer eine SkyTV Ulitmate IV. Der läuft auf einem kleinen ARM (Minix X7 mini) unter Ubuntu 14.04

Code: [Auswählen]

$ uname -a
Linux LINUXIUMONE 3.0.36+ #1 SMP PREEMPT Sat Feb 15 20:54:36 EST 2014 armv7l armv7l armv7l GNU/Linux
Das System läuft eigentlich stabil (2 Wochen am stück ohne Probleme). Aber sobald ich entweder vdr oder tvheadend darauf laufen lasse und der Stick (der immer angesteckt war) in betrieb geht sehe ich nach ein paar Stunden einen unmotivierten reboot, meist ohne syslog einträge. Manchmal sieht man aber vorher auch was dort:

Code: [Auswählen]

Dec 11 03:26:24 LINUXIUMONE kernel: [10006.194348] INFO: rcu_bh_state detected stalls on CPUs/tasks: { 2} (detected by 3, t=6002 jiffies)
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.194484] Backtrace for cpu 3 (current):
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.194573] [<c043b954>] (unwind_backtrace+0x0/0xe0) from [<c043ae84>] (smp_send_all_cpu_backtrace+0x5c/0xd8)
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.194664] [<c043ae84>] (smp_send_all_cpu_backtrace+0x5c/0xd8) from [<c04aa734>] (__rcu_pending+0x208/0x37c)
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.194748] [<c04aa734>] (__rcu_pending+0x208/0x37c) from [<c04ab62c>] (rcu_check_callbacks+0x108/0x158)
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.194837] [<c04ab62c>] (rcu_check_callbacks+0x108/0x158) from [<c0475eb8>] (update_process_times+0x38/0x4c)
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.194922] [<c0475eb8>] (update_process_times+0x38/0x4c) from [<c0491a88>] (tick_sched_timer+0x90/0xc8)
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.195008] [<c0491a88>] (tick_sched_timer+0x90/0xc8) from [<c04878d8>] (__run_hrtimer+0x170/0x288)
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.195086] [<c04878d8>] (__run_hrtimer+0x170/0x288) from [<c0488580>] (hrtimer_interrupt+0x124/0x28c)
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.195164] [<c0488580>] (hrtimer_interrupt+0x124/0x28c) from [<c045358c>] (rk_timer_clockevent_interrupt+0x4c/0x58)
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.195256] [<c045358c>] (rk_timer_clockevent_interrupt+0x4c/0x58) from [<c04a5b20>] (handle_irq_event_percpu+0xb0/0x274)
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.195343] [<c04a5b20>] (handle_irq_event_percpu+0xb0/0x274) from [<c04a5d20>] (handle_irq_event+0x3c/0x5c)
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.195421] [<c04a5d20>] (handle_irq_event+0x3c/0x5c) from [<c04a7f54>] (handle_fasteoi_irq+0xc8/0x114)
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.195497] [<c04a7f54>] (handle_fasteoi_irq+0xc8/0x114) from [<c04a547c>] (generic_handle_irq+0x28/0x3c)
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.195587] [<c04a547c>] (generic_handle_irq+0x28/0x3c) from [<c0431078>] (asm_do_IRQ+0x78/0xb8)
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.195664] [<c0431078>] (asm_do_IRQ+0x78/0xb8) from [<c04362c8>] (__irq_svc+0x48/0xe0)
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.195717] Exception stack(0xec879f50 to 0xec879f98)
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.195762] 9f40:                                     ec879f98 00000000 bc6b9e1a 00000919
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.195828] 9f60: bbd3af92 00000919 000003ff feb3cfff 00000000 413fc090 00000003 00000000
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.195888] 9f80: 00000006 ec879f98 c048c1e8 c044ab74 900f0013 ffffffff
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.195955] [<c04362c8>] (__irq_svc+0x48/0xe0) from [<c044ab74>] (rk30_idle+0x44/0x74)
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.196035] [<c044ab74>] (rk30_idle+0x44/0x74) from [<c0779ed4>] (cpuidle_idle_call+0x14c/0x250)
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.196114] [<c0779ed4>] (cpuidle_idle_call+0x14c/0x250) from [<c0437500>] (cpu_idle+0x84/0xe8)
Dec 11 03:26:24 LINUXIUMONE kernel: [10006.196189] [<c0437500>] (cpu_idle+0x84/0xe8) from [<6095d9b4>] (0x6095d9b4)

Was könnte das sein? Was kann man tun?

Beste Grüsse,
Chris

[Sundtek]

Das ist wohl ein Linux Bug bei dem System, sollte wohl an die Linux Kernel Mailingliste geschickt werden.

Du kannst überprüfen ob der Linux CPU Scheduler auf ondemand gesetzt ist.
Wir haben schon Systeme gesehen wo das dynamische heruntertakten des CPUs interrupt Probleme bereitet hat, ein Workaround könnte sein den CPU Scheduler auf performance umzustellen.

/opt/bin/mediaclient --cpucheck

Was zeigt das an bei Dir?

Optional kannst du auch noch versuchen den Transfermodus auf isochronous umzustellen

/opt/bin/mediaclient --transfermode=iso -d /dev/dvb/adapter0/frontend0

(bulk ist default, --transfermode=bulk stelt es wieder zurück, der Modus wird auf dem Gerät abgespeichert)
Der Fehler kann natürlich eventuell elektronischem Ursprungs sein (z.B zu wenig Strom verfügbar für USB und der Fehler ist eine Auswirkung davon), oder wirklich nur ein Software Bug.
Der Tuner benötigt zwischen 250-350 mA (ich hab's jetzt nicht nachgemessen), die Stromversorgung ist ausschliesslich für den LNB zuständig, sprich je stromsparender der LNB ist desto eher kannst du den Tuner sogar ohne Netzteil betreiben.

[chris_g]

OK. fester Prozessortakt scheint das Problem zu umgehen. Gibt es eine detailiertere Erklärung dazu was da passiert, wenn das System neu startet?

Vielleicht würde das den Kernel-Developern helfen, das Problem einzugrenzen und auszumerzen...

[Sundtek]

Ich denke deine Backlogs können dort eventuell weiterhelfen. Es kann aber auch ein Folgefehler von wahllos überschriebenem Arbeitsspeicher sein.

Egal wie man's dreht der Treiber kann direkt kein System zum Absturz bringen da dieser ja nur eine Applikation ist. Sprich wenn unser Treiber ein Problem hat dann beeinflusst es nur den Treiber und nicht das gesamte System.
Sollte nun aber so ein Systemfehler ausgelöst werden dann hat die genutzte Linux Version einen Fehler.