Bug 150571

Summary: Regression: commit 12549e2 clocksource/drivers/time-armada-370-xp: Convert init function to return error
Product: Timers Reporter: Ralph Sennhauser (ralph.sennhauser)
Component: OtherAssignee: john stultz (john.stultz)
Status: CLOSED CODE_FIX    
Severity: normal CC: daniel.lezcano
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: v4.8-rc1 v4.8-rc2 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: bisect log

Description Ralph Sennhauser 2016-07-28 07:40:58 UTC
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
Comment 1 Ralph Sennhauser 2016-07-28 14:43:11 UTC
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..
Comment 2 john stultz 2016-08-06 00:51:35 UTC
(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> ).
Comment 3 Ralph Sennhauser 2016-08-06 07:23:33 UTC
(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
Comment 4 Daniel Lezcano 2016-08-07 12:32:20 UTC
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 ?
Comment 5 Ralph Sennhauser 2016-08-07 12:59:30 UTC
(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.
Comment 6 Ralph Sennhauser 2016-08-07 16:18:04 UTC
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.
Comment 7 Daniel Lezcano 2016-08-15 10:17:13 UTC
Hi Ralph,

can you test the following patch ?

https://lkml.org/lkml/2016/8/10/33

Thanks !
Comment 8 Ralph Sennhauser 2016-08-15 16:22:47 UTC
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+
Comment 9 john stultz 2016-08-17 17:46:09 UTC
From Daniel: fix is in tip/timers/urgent