From: Feng Tang <feng.tang@linux.alibaba.com>
To: Thomas Gleixner <tglx@kernel.org>
Cc: "David Hildenbrand (Arm)" <david@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Petr Mladek <pmladek@suse.com>,
Steven Rostedt <rostedt@goodmis.org>,
paulmck@kernel.org, Douglas Anderson <dianders@chromium.org>,
Peter Zijlstra <peterz@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
linux-kernel@vger.kernel.org,
Ard Biesheuvel <ardb+git@google.com>
Subject: Re: [PATCH v1] kernel: add a simple timer based software watchpoint
Date: Fri, 26 Jun 2026 10:57:03 +0800 [thread overview]
Message-ID: <aj3qf__MEokt-eMC@U-2FWC9VHC-2323.local> (raw)
In-Reply-To: <aj3cRtxNmWYW48Wf@U-2FWC9VHC-2323.local>
On Fri, Jun 26, 2026 at 09:56:22AM +0800, Feng Tang wrote:
> > > ability to do the virtual to physical address translation instantly to
> > > watch a _physical_ address. So I guess, not able to watchpoint a physical
> > > address may be common for HW debuggers (I could be very wrong).
> >
> > If the hardware debugger and the underlying CPU facility (ETM on ARM64
> > IIRC) does not support triggers on physical addresses and you already
> > concluded from other information that the problem is in the BIOS, then
> > tracing the kernel with it's virt/phys translation is not going to
> > work. You obviously have to use the BIOS translation which might be very
> > different, no?
Forgot to metion, the problem of BIOS was actually enabling some experimental
silicon feature, which it should not for this hardware, and then the BIOS
wasn't involved in the detail context of the issue.
Thanks,
Feng
>
> I didn't explain the issue clearly. The order for solving this issue was,
> we first used this method to halt (while (1) dead loop) the system when
> detecting the memory corruption, silicon engineers gathered hardware
> traces, then root caused it. Before that, we didn't know it's a BIOS issue,
> as the initial symptom was random user space "segmentation fault"
next prev parent reply other threads:[~2026-06-26 2:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-22 8:14 Feng Tang
2026-06-22 8:42 ` David Hildenbrand (Arm)
2026-06-22 10:53 ` Thomas Gleixner
2026-06-22 12:45 ` Feng Tang
2026-06-22 14:13 ` David Hildenbrand (Arm)
2026-06-23 8:26 ` Feng Tang
2026-06-24 9:04 ` Thomas Gleixner
2026-06-24 10:21 ` David Hildenbrand (Arm)
2026-06-24 11:16 ` Feng Tang
2026-06-24 11:12 ` Feng Tang
2026-06-25 21:30 ` Thomas Gleixner
2026-06-26 1:56 ` Feng Tang
2026-06-26 2:57 ` Feng Tang [this message]
2026-06-26 6:50 ` Feng Tang
2026-06-26 9:16 ` Thomas Gleixner
2026-06-26 14:33 ` Feng Tang
2026-06-26 15:31 ` Thomas Gleixner
2026-06-29 8:35 ` Feng Tang
2026-06-23 17:26 ` Julian Braha
2026-06-24 2:43 ` Feng Tang
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=aj3qf__MEokt-eMC@U-2FWC9VHC-2323.local \
--to=feng.tang@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=ardb+git@google.com \
--cc=david@kernel.org \
--cc=dianders@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=tglx@kernel.org \
--cc=vbabka@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
powered by JetHome