Created attachment 226641 [details] bisect log Hardware: Linksys WRT1900ACS (shelby) For an almost identical model see WRT1900AC v2 (cobra) [1] Symptoms: Up to printing [ 1.312411] armada38x-rtc f10a3800.rtc: setting system clock to 2016-07-26 20:44:00 UTC (1469565840) all seems as it should. After that going by the times printed on the serial console the boot is more than twice as fast as expected. Dmesg shows the expected times while going by wrist watch it takes an order of magnitude longer than expected to boot. Once booted the device is sort of functional. Known workaround: Reverting commit 12549e27c63c61d76bb059bfafce0a4ee05c7e90 makes later commits usable for me. [1] ./arch/arm/boot/dts/armada-385-linksys-cobra.dts
With current master and reverted 12549e2 I see new an error: [ 0.000003] sched_clock: 32 bits at 25MHz, resolution 40ns, wraps every 85899345900ns [ 0.000009] clocksource: armada_370_xp_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 76450417870 ns [ 0.000020] Failed to initialize '/soc/internal-regs/timer@20300': -1065749268 [ 0.000122] Calibrating delay loop (skipped), value calculated using timer frequency..
(In reply to Ralph Sennhauser from comment #0) > Created attachment 226641 [details] > bisect log > > Hardware: > > Linksys WRT1900ACS (shelby) > > For an almost identical model see WRT1900AC v2 (cobra) [1] > > Symptoms: > > Up to printing > [ 1.312411] armada38x-rtc f10a3800.rtc: setting system clock to > 2016-07-26 20:44:00 UTC (1469565840) > all seems as it should. > > After that going by the times printed on the serial console the boot is > more than twice as fast as expected. Dmesg shows the expected times while > going by wrist watch it takes an order of magnitude longer than expected to > boot. Once booted the device is sort of functional. > > Known workaround: > > Reverting commit 12549e27c63c61d76bb059bfafce0a4ee05c7e90 makes later > commits usable for me. > Can you please send mail to lkml on this? (Cc'ing Daniel Lezcano <daniel.lezcano@linaro.org> ).
(In reply to john stultz from comment #2) > Can you please send mail to lkml on this? (Cc'ing Daniel Lezcano > <daniel.lezcano@linaro.org> ). Done
There are a couple of error in this report. One related to a nit in the error handling at init time and another one not investigated yet. Does the tested kernel version have commit 1d661bf5327a2c059ec967f850e89362e637f4e6 ?
(In reply to Daniel Lezcano from comment #4) > There are a couple of error in this report. > > One related to a nit in the error handling at init time and another one not > investigated yet. > Non of the good versions had shown the init error for timer@20300, doesn't mean it wasn't lurking in the dark to be uncovered by your changes. > Does the tested kernel version have commit > 1d661bf5327a2c059ec967f850e89362e637f4e6 ? Yes, at least some of the tested version contain commit 1d661bf5327a2c059ec967f850e89362e637f4e6. See bisect log for which I tested good/bad.
Just tested recent 0cbbc422 Merge tag 'xfs-rmap-for-linus-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs No reverts this time, same behaviour as described in Comment 0. No error printed for initializing timer@20300 either. If you believe the timer@20300 issue is a real separate issue I will file another bug. To me it looks like the suggested workaround simply isn't valid.
Hi Ralph, can you test the following patch ? https://lkml.org/lkml/2016/8/10/33 Thanks !
Hi Daniel, Tested: v4.8-rc2: bad v4.8-rc2 + https://lkml.org/lkml/diff/2016/8/10/33/1: good Feel free to add my Tested-by and close this bug once the fix hits Linus tree. Thanks Ralph PS: updating the version field with actual tags which exhibit the issue as not to confuse anyone what is meant by v4.7+
From Daniel: fix is in tip/timers/urgent