Messages in this thread | | | From | Romain Izard <> | Date | Tue, 7 Mar 2017 16:05:10 +0100 | Subject | Re: Warning on boot on SAMA5D2 with Linux 4.11-rc1 |
| |
2017-03-06 12:28 GMT+01:00 Romain Izard <romain.izard.pro@gmail.com>: > > While looking for another issue, I tried Linux 4.11-rc1 on a SAMA5D2 Xplained > board. The boot log contains the following warning: > > [ 0.100000] ------------[ cut here ]------------ > [ 0.100000] WARNING: CPU: 0 PID: 1 at > ../kernel/time/sched_clock.c:180 sched_clock_register+0x44/0x1e4 > [ 0.100000] CPU: 0 PID: 1 Comm: swapper Not tainted 4.11.0-rc1+ #3 > [ 0.100000] Hardware name: Atmel SAMA5 > [ 0.100000] [<c010c494>] (unwind_backtrace) from [<c010a558>] > (show_stack+0x10/0x14) > [ 0.100000] [<c010a558>] (show_stack) from [<c0115654>] (__warn+0xe0/0xf8) > [ 0.100000] [<c0115654>] (__warn) from [<c011571c>] > (warn_slowpath_null+0x20/0x28) > [ 0.100000] [<c011571c>] (warn_slowpath_null) from [<c090b0d0>] > (sched_clock_register+0x44/0x1e4) > [ 0.100000] [<c090b0d0>] (sched_clock_register) from [<c091fb98>] > (tcb_clksrc_init+0x1ac/0x360) > [ 0.100000] [<c091fb98>] (tcb_clksrc_init) from [<c0900d8c>] > (do_one_initcall+0xb4/0x15c) > [ 0.100000] [<c0900d8c>] (do_one_initcall) from [<c0900f68>] > (kernel_init_freeable+0x134/0x1c4) > [ 0.100000] [<c0900f68>] (kernel_init_freeable) from [<c06bfc64>] > (kernel_init+0x8/0x10c) > [ 0.100000] [<c06bfc64>] (kernel_init) from [<c0107318>] > (ret_from_fork+0x14/0x3c) > [ 0.100000] ---[ end trace 7ce9be9d7cf6f800 ]--- > [ 0.100012] sched_clock: 32 bits at 10MHz, resolution 96ns, wraps > every 206986376143ns > > This is related to the following commit: > 7b9f1d16e6d1 clocksource/drivers/tcb_clksrc: Use 32 bit tcb as sched_clock > > When we call sched_clock_register from tcb_clksrc_init from > arch_initcall, we are too late as sched expects all the candidates for > its clock to be registered before interrupts are enabled. This warning > does not prevent the tcb clock from being used. >
After some more use with 4.11-rc1, I also noticed that the timestamp for printk rolls over to 0 after only 413s. Reverting the aforementioned commit fixes it.
-- Romain Izard
| |