From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C7A32285072 for ; Mon, 9 Mar 2026 17:27:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773077263; cv=none; b=eC0gqMDIRZiBhp9H2TFQIeMTd6uf+cCKFeBRy6fhCf8ilHh7DdDd0b96/8Ub3gyd7XQOEYmBCZRkTQ4HOds7kna9/fiqFTkm7gEv7Rr3IdAHsdDAdvB77txdBN316OBYv23UMruNv1NmVuhNWH5m6wSYDBfUPa67+Z4KHlxic/c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773077263; c=relaxed/simple; bh=D6vOzrUfUxGRl39AhuAsmPqUbwOzOY+xNTdDwRNq3qU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IMBChpK2LtnHZ6xF/SEUeegHb1b+aQDsYLscdpU3hiNyTNfwCG7jv9yZQQ1gqQz6orytYvx8ih4o5VfljjxIwvG3ZycE+WFaf9oiP2195/xXEGPfvleXSzjZ7XW8NELVkKnYZKXXpbZIy4oGalt6vNgmyVC7fAxVMlLEtS32RUY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=dcCtO3nl; arc=none smtp.client-ip=209.85.214.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dcCtO3nl" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2ae46fc8ec1so59041515ad.3 for ; Mon, 09 Mar 2026 10:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773077262; x=1773682062; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=nezdDOkBXnIOMjD4Tthu6LYbtu4WMDL/OCtUkkPr37k=; b=dcCtO3nlRHMpLaT54eLvs6djqbvRhDPyKDtXKrD8ebVxW5Mp7ZSUNBqUlVI4OzPgkN d8akPKEyqk8MuGsmfEXAu7D8bVXoyTJNLriRVXTK5hGSabSZfQgjfuoFApQT8R5Mt3lX qj6G+1GHMBNexhnq6Qh+tWGTqa/0aNbN9Ac/oWLV+UEVGI9LxiHpwNXPFW750t+peLj9 m0a5pE0lzEzr/zrx3BUZrEmAWDPJWHjYn2Q/F5n33WmPI/M7MUYJMmIW09H7efug+RGe Fvypg7FtuhoCiiviy0PuKyvbEbf9ek54bqyysWpv/EUOOcEd+lmdDVD5WgT0zmuAK8DX JkIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773077262; x=1773682062; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nezdDOkBXnIOMjD4Tthu6LYbtu4WMDL/OCtUkkPr37k=; b=LP3t/V9j9fNTtsbSuqAWh2g6fzEt8hIDqXFnoAU3ouLeq2O+FmB8g5IeehtWKdRlqJ KH1vurlPYEMbzgYCOejEpgr77rIR+QXePSTi6iv+Oatq082S/1TBO18LSTdQLlU+Uemp XDAQWqF3kAJdwoq4QX2SjBXKaB2nmWbjqhp1pc165n+RSRZtUzd9L2IU2zAgHQai6zxn lrbQXAKIAAGtA0XzS/zMVIwM1xnSSbV5Old83ThVIepgbfTQrcyvuqXv+2Y8zWYP1X0s ELKc0dpO9W2uB8vG15EsTkMe6hoI61JVlYxbxTAm5d3JY3l41eiG/P5kLxPkApzquXt5 cXYQ== X-Forwarded-Encrypted: i=1; AJvYcCXOSDZbgnFXpE8wSxteejzYl+v/e5+TuM40pFFqx39eqXEql63Ofwrev1MW2lROaqptNdSMx4E0gp7aMNs=@vger.kernel.org X-Gm-Message-State: AOJu0Yxh3Y5JPIwKHBNTLe0iru9uwfbv7x4z5VDMJhWA9/TRxIa3ODeQ tIomgBzwTrPwpeOVOh+m8JM1mK+La42frBa9EzFpsMy2JLO8oogd4xox X-Gm-Gg: ATEYQzxRnI7xKV6c5dLhyZ/4kKp/5qlweB4cMLyR8jzjCugMYLT6HcWiDhcYhv1un6F XxuvUOiVDoO3beWVF3NkUo+C4S89RXDvssQzL4KAQL+8U2oJHvaZj5diVufZS3+2iQJynakBt3P g+Xzk9vFVjOniyHvMJqor6AgAobhWcxV2L7sODg4+2E5xo5pZvhxHCVCekVqhQNTUSxgvjNo2+E M/sqcWWZT7Fz3RvjxlCpU4L3fIG9iFA5DOj6nsGlHmnY0N4D6urUFazn7bhHRmcem3JOhiJrrEO Dw00T8+lhJhatj2tLA+KdkzFPTAYWoWH/QLJsbjpyEKyBZZH6TVAJWP26A1nVsFIICo+AnSr5Zx Msfq2bVW82077LO017lzQ0RS+KQpVpEGtduUx6GuFrH31ggh02LeB2o5/c86y5pJwXXgQrtc+Wl 9aDIE25HCPPhN38hurIbJxUgVOVfgE+BaII0lTinYMD2hS6ViL/OlpY6g3S5ybftCxy6GDgaAom 047VA== X-Received: by 2002:a17:903:2b0b:b0:2ae:5dba:c8c1 with SMTP id d9443c01a7336-2ae823677d9mr113542955ad.7.1773077262091; Mon, 09 Mar 2026 10:27:42 -0700 (PDT) Received: from fedora (p4582043-ipxg23101hodogaya.kanagawa.ocn.ne.jp. [153.205.170.43]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ae83f8b9e4sm116529645ad.64.2026.03.09.10.27.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Mar 2026 10:27:41 -0700 (PDT) Date: Tue, 10 Mar 2026 02:27:27 +0900 From: Shashank Balaji To: Tim Bird Cc: pmladek@suse.com, rostedt@goodmis.org, john.ogness@linuxtronix.de, senozhatsky@chromium.org, francesco@valla.it, geert@linux-m68k.org, linux-embedded@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] printk: fix zero-valued printk timestamps in early boot Message-ID: References: <39b09edb-8998-4ebd-a564-7d594434a981@bird.org> <20260210234741.3262320-1-tim.bird@sony.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260210234741.3262320-1-tim.bird@sony.com> Hi Tim, Tested-by: Shashank Balaji ...on top of rc3 on an AMD Ryzen 7 4800H laptop. This patch conflicts with these commits with trivial fixes: 032a730268a3 init/main.c: wrap long kernel cmdline when printing to logs 60325c27d3cf printk: Add execution context (task name/CPU) to printk_info 499f86de4f8c init/main: read bootconfig header with get_unaligned_le32() Comment below. On Tue, Feb 10, 2026 at 04:47:41PM -0700, Tim Bird wrote: > During early boot, printk timestamps are reported as zero before > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > index 1d765ad242b8..5afd31c3345c 100644 > --- a/kernel/printk/printk.c > +++ b/kernel/printk/printk.c > @@ -46,6 +46,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -75,6 +76,13 @@ EXPORT_SYMBOL(ignore_console_lock_warning); > > EXPORT_TRACEPOINT_SYMBOL_GPL(console); > > +#ifdef CONFIG_EARLY_PRINTK_TIMES > +cycles_t start_cycles; > +u64 start_ns; > +u32 early_mult, early_shift; > +u64 early_ts_offset; > +#endif > + > /* > * Low level drivers may need that to know if they can schedule in > * their unblank() callback or not. So let's export it. > @@ -639,7 +647,7 @@ static void append_char(char **pp, char *e, char c) > static ssize_t info_print_ext_header(char *buf, size_t size, > struct printk_info *info) > { > - u64 ts_usec = info->ts_nsec; > + u64 ts_usec = adjust_early_ts(info->ts_nsec); > char caller[20]; > #ifdef CONFIG_PRINTK_CALLER > u32 id = info->caller_id; > @@ -1352,7 +1360,11 @@ static size_t print_syslog(unsigned int level, char *buf) > > static size_t print_time(u64 ts, char *buf) > { > - unsigned long rem_nsec = do_div(ts, 1000000000); > + unsigned long rem_nsec; > + > + ts = adjust_early_ts(ts); > + > + rem_nsec = do_div(ts, 1000000000); > > return sprintf(buf, "[%5lu.%06lu]", > (unsigned long)ts, rem_nsec / 1000); > @@ -2242,6 +2254,8 @@ int vprintk_store(int facility, int level, > * timestamp with respect to the caller. > */ > ts_nsec = local_clock(); > + if (!ts_nsec) > + ts_nsec = early_cycles(); ts_nsec goes on to be stored in a struct printk_info's ts_nsec which is documented to be "timestamp in nanoseconds": /* * Meta information about each stored message. * * All fields are set by the printk code except for @seq, which is * set by the ringbuffer code. */ struct printk_info { u64 seq; /* sequence number */ u64 ts_nsec; /* timestamp in nanoseconds */ u16 text_len; /* length of text message */ u8 facility; /* syslog facility */ u8 flags:5; /* internal record flags */ u8 level:3; /* syslog level */ u32 caller_id; /* thread id or processor id */ #ifdef CONFIG_PRINTK_EXECUTION_CTX u32 caller_id2; /* caller_id complement */ /* name of the task that generated the message */ char comm[TASK_COMM_LEN]; #endif struct dev_printk_info dev_info; }; Since with this patch, ts_nsec can either be a timestamp in ns or a cycle count, the comment should be updated. Ideally, I'd like the member name to be changed as well to reflect the new semantic. I'm thinking ts_raw or ts_ns_or_cyc... naming is hard :) Thanks, Shashank