BeagleBone DMTimer2 unexpected stop after one or more days
@pdp7 ci sta già lavorando.
Dal 9/6/2020.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
we encounter DMTimer2 unexpected stop in am335x after run 1 or more days, we indeed seen gp_timer in /proc/interrupts never increase any more;
we have try beagleBoard github kernel version 4.4.113/4.4.155 with our own rootfs in Beagebone Black board and our custom board, the situation is the same, Eventhought i don't make any change in kernel source.
This timer is initialized for clockevent in omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop); //arch/arm/mach-omap2/timer.c
below is the related call stack：
omap3_gptimer_timer_init(void) =>
__omap_sync32k_timer_init(2, "timer_sys_ck", NULL,
1, "timer_sys_ck", "ti,timer-alwon", true); =>
omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
after DMTimer2 unexpected stop, those things happen:
1、gp_timer in /proc/interrupts NEVER increases
2、get time form date cmd may goback some minues or seconds
3、user apps no longer output debug log in console， it seems the scheduler of kernel do not work correctly.
but shell in console work fine, network ping is also work fine.
4、cpu load of threads in top cmd are all 0%
By the way, i checked after situation come out, ST bit of the DMTimer2's TCLR is 1 (that is Start timer)
But If i stop DMTimer2 manually in console shell by cmd: devmem 0x48040038 32 0x0
then i can reproduced the 1/2/3 situation mentioned above， but hung while i type cmd top in console shell.
So i think DMTimer2 of my AM335x is not work correctly after run one or more days.
We also try to comment out __omap_dm_timer_override_errata() in omap2_gp_clockevent_init(), this force to enable OMAP_TIMER_ERRATA_I103_I767, but the kernel can't bootup at all.
we also posted this problem in TI community at https://e2e.ti.com/support/processors/f/791/t/796508
- Lingua principale
- C
- Stelle
- 812
- Fork
- 582
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di beagleboard/linux
-
Greybus fetch firmware request incorrect signatureForse di nuovo libera @Ayush1325 l’ha presa 345 giorni fa e non c’è nessuna pull request aperta. Aperta
beagleboard/linux#295 · 1 assegnatario ·
-
MikroBus and Beagle CapesForse di nuovo libera @Ayush1325 l’ha presa 412 giorni fa e non c’è nessuna pull request aperta. Apertaupstream
beagleboard/linux#292 · 1 assegnatario ·
-
ITE mainlineApertaupstream
Difficoltà 5/5 Più di una settimana Idoneità per principianti 20/100
beagleboard/linux#291 · 2 commenti ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 48/100
beagleboard/linux#290 · 4 commenti ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
beagleboard/linux#284 · 1 commento ·
Tutte le issue di beagleboard/linux
Issue simili
-
Add c++23 mapping to nvccApertafeature request
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 86/100
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
FujiNetWIFI/fujinet-firmware#1730 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
-
[openssl] update to 3.6.5Apertacategory:port-update
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 2 giorni