From: Helge Deller <deller@gmx.de>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: "linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>
Subject: Re: invalid printk time during boot on PA-RISC
Date: Tue, 14 Jun 2016 23:23:35 +0200 [thread overview]
Message-ID: <576075D7.60602@gmx.de> (raw)
In-Reply-To: <alpine.LRH.2.02.1606141216510.29159@file01.intranet.prod.int.rdu2.redhat.com>
Hi Mikulas,
On 14.06.2016 18:20, Mikulas Patocka wrote:
> There is another bug: when you enable CONFIG_DEBUG_TIMEKEEPING, parisc
> boot gets stuck with these messages.
Nice catch!
> (but it is not caused by the patch
> 54b668009076caddbede8fde513ca2c982590bfe, because this bug happens even in
> kernel 4.6).
Seems to be a generic upstream problem.
Would be nice to know if it happens on x86_64 as well.
I tried this patch (copy&pasted):
diff --git a/arch/parisc/kernel/time.c b/arch/parisc/kernel/time.c
index 31ec99a..85e7bb7 100644
--- a/arch/parisc/kernel/time.c
+++ b/arch/parisc/kernel/time.c
@@ -217,9 +217,16 @@ static struct clocksource clocksource_cr16 = {
.rating = 300,
.read = read_cr16,
.mask = CLOCKSOURCE_MASK(BITS_PER_LONG),
+ .mult = 1000,
+ .shift = 12,
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
+struct clocksource * __init clocksource_default_clock(void)
+{
+ return &clocksource_cr16;
+}
+
int update_cr16_clocksource(void)
{
/* since the cr16 cycle counters are not synchronized across CPUs,
which gives:
[ 0.000000] clocksource: cr16: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 29863444473 ns
[ 0.000000] Console: colour dummy device 128x48
[ 0.012938] Calibrating delay loop... 63.07 BogoMIPS (lpj=315392)
[ 0.012938] pid_max: default: 32768 minimum: 301
[ 0.014235] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.014235] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.019359] Adjusting cr16 more than 11% (1000 vs -1967128576)
[ 0.019359] Brought up 1 CPUs
[ 0.020634] devtmpfs: initialized
[ 0.022716] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.022716] NET: Registered protocol family 16
Still puzzled...
Helge
> Mikulas
>
> [ 0.000000] Memory: 7201556K/7337984K available (4096K kernel code, 1419K rwdata, 883K rodata, 176K init, 2296K bss, 136428K reserved, 0K cma-reserved)
> [ 0.000000] virtual kernel memory layout:
> [ 0.000000] vmalloc : 0x0000000000008000 - 0x000000003f000000 (1007 MB)
> [ 0.000000] memory : 0x0000000040000000 - 0x0000004140000000 (266240 MB)
> [ 0.000000] .init : 0x0000000040100000 - 0x000000004012c000 ( 176 kB)
> [ 0.000000] .data : 0x000000004052c000 - 0x000000004076bb60 (2302 kB)
> [ 0.000000] .text : 0x000000004012c000 - 0x000000004052c000 (4096 kB)
> [ 0.000000] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=4, Nodes=8
> [ 0.000000] Hierarchical RCU implementation.
> [ 0.000000] Build-time adjustment of leaf fanout to 64.
> [ 0.000000] NR_IRQS:80
> [ 0.000000] clocksource: cr16: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
> [ 0.133333] WARNING: timekeeping: Cycle offset (40) is larger than allowed by the 'jiffies' clock's max_cycles value (10): time overflow danger
> [ 0.133333] timekeeping: Your kernel is sick, but tries to cope by capping time updates
> [ 0.133333] Console: colour dummy device 160x64
> [ 0.303333] WARNING: timekeeping: Cycle offset (51) is larger than allowed by the 'jiffies' clock's max_cycles value (10): time overflow danger
> [ 0.303333] timekeeping: Your kernel is sick, but tries to cope by capping time updates
> [ 0.423333] WARNING: timekeeping: Cycle offset (36) is larger than allowed by the 'jiffies' clock's max_cycles value (10): time overflow danger
> [ 0.423333] timekeeping: Your kernel is sick, but tries to cope by capping time updates
> [ 0.483333] WARNING: timekeeping: Cycle offset (18) is larger than allowed by the 'jiffies' clock's max_cycles value (10): time overflow danger
> [ 0.483333] timekeeping: Your kernel is sick, but tries to cope by capping time updates
> [ 0.653333] WARNING: timekeeping: Cycle offset (51) is larger than allowed by the 'jiffies' clock's max_cycles value (10): time overflow danger
> [ 0.653333] timekeeping: Your kernel is sick, but tries to cope by capping time updates
> [ 0.769999] WARNING: timekeeping: Cycle offset (35) is larger than allowed by the 'jiffies' clock's max_cycles value (10): time overflow danger
> [ 0.769999] timekeeping: Your kernel is sick, but tries to cope by capping time updates
> [ 0.943333] WARNING: timekeeping: Cycle offset (52) is larger than allowed by the 'jiffies' clock's max_cycles value (10): time overflow danger
> [ 0.943333] timekeeping: Your kernel is sick, but tries to cope by capping time updates
>
>
> On Wed, 1 Jun 2016, Helge Deller wrote:
>
>> * Mikulas Patocka <mpatocka@redhat.com>:
>>> Hi
>>>
>>> With the kernel 4.7-rc1, I get corrupted printk times when the machine
>>> boots. The kernel is compiled with "Show timing information on printks"
>>> (CONFIG_PRINTK_TIME) enabled. There are no other negative effects.
>>>
>>> Bisecting shows that it is caused by the patch
>>> 54b668009076caddbede8fde513ca2c982590bfe ("parisc: Add native
>>> high-resolution sched_clock() implementation").
>>>
>>> [ 0.000000] NR_IRQS:80
>>> [ 0.000000] clocksource: cr16: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
>>> [ 0.000000] Console: colour dummy device 160x64
>>> [ 90.122205] Calibrating delay loop... 1991.60 BogoMIPS (lpj=3317760)
>>> [ 90.224168] pid_max: default: 32768 minimum: 301
>>> ....
>>> [ 92.235878] 13. Crestone Peak Core RS-232 at 0xfffffff0f05e2000 [18] { 10, 0x0, 0x076, 0x000ad }
>>> [ 92.708000] Releasing cpu 1 now, hpa=fffffffffe781000
>>> [ 92.818803] FP[1] enabled: Rev 1 Model 20
>>> [ 2.917508] Releasing cpu 2 now, hpa=fffffffffe798000
>>> [ 0.196666] FP[2] enabled: Rev 1 Model 20
>>> [ 3.116794] Releasing cpu 3 now, hpa=fffffffffe799000
>>> [ 0.196666] FP[3] enabled: Rev 1 Model 20
>>> [ 3.296942] CPU(s): 4 out of 4 PA8900 (Shortfin) at 1000.000000 MHz online
>>> [ 3.447762] Setting cache flush threshold to 65536 kB
>>> [ 3.450548] Setting TLB flush threshold to 1020 kB
>>
>> Please try attached patch.
>>
>> It fixes the problem mostly for me, there is just one little glitch
>> left, which is that the lines "FP[x] enabled" will still print an
>> invalid time. I assume it's because when this text is printed, the
>> clock/interrupts for the just booted CPU aren't enabled yet.
>>
>> I'm not sure it's worth trying to fix that.
>> One could print out that info at a later time, or just disabled it.
>>
>> Helge
>>
>> [ 5.720014] Enabling PDC_PAT chassis codes support v0.05
>> [ 6.644542] Releasing cpu 1 now, hpa=fffffffffe781000
>> [ 0.196000] FP[1] enabled: Rev 1 Model 20
>> [ 7.088432] CPU(s): 2 out of 2 PA8800 (Mako) at 900.000000 MHz online
>>
>> -----------
>>
>> [PATCH] parisc: Fix printk time during boot
>>
>> Signed-off-by: Helge Deller <deller@gmx.de>
>>
>> diff --git a/arch/parisc/kernel/time.c b/arch/parisc/kernel/time.c
>> index 58dd680..31ec99a 100644
>> --- a/arch/parisc/kernel/time.c
>> +++ b/arch/parisc/kernel/time.c
>> @@ -309,11 +309,6 @@ void __init time_init(void)
>> clocks_calc_mult_shift(&cyc2ns_mul, &cyc2ns_shift, current_cr16_khz,
>> NSEC_PER_MSEC, 0);
>>
>> -#if defined(CONFIG_HAVE_UNSTABLE_SCHED_CLOCK) && defined(CONFIG_64BIT)
>> - /* At bootup only one 64bit CPU is online and cr16 is "stable" */
>> - set_sched_clock_stable();
>> -#endif
>> -
>> start_cpu_itimer(); /* get CPU 0 started */
>>
>> /* register at clocksource framework */
>>
prev parent reply other threads:[~2016-06-14 21:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-31 11:44 invalid printk time during boot on PA-RISC Mikulas Patocka
2016-06-01 21:12 ` Helge Deller
2016-06-01 21:36 ` Aaro Koskinen
2016-06-03 17:22 ` Helge Deller
2016-06-03 21:56 ` Aaro Koskinen
2016-06-06 16:51 ` Mikulas Patocka
2016-06-07 16:47 ` Helge Deller
2016-06-14 16:20 ` Mikulas Patocka
2016-06-14 21:23 ` Helge Deller [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=576075D7.60602@gmx.de \
--to=deller@gmx.de \
--cc=linux-parisc@vger.kernel.org \
--cc=mpatocka@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.