Hi,
On Fri, Apr 18, 2014 at 10:17 AM, Doug Anderson diand...@chromium.org wrote:
In (efe2f29 kgdboc,kdb: Allow kdb to work on a non open console port)
support was added to directly use the write_char functions when
doing kdb over a non-open console port. This is great, but it ends up
newlines.
Add similar code in kdb so we don't get things like:
[0]kdb
[0]kdb
[0]kdb
Signed-off-by: Doug Anderson diand...@chromium.org
---
kernel/debug/kdb/kdb_io.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
Hi,
On Mon, Oct 29, 2018 at 11:08 AM Douglas Anderson wrote:
>
> Right now serial drivers process sysrq keys deep in their character
> receiving code. This means that they've already grabbed their
> port->lock spinlock. This can end up getting in the way if we've go
> to do serial stuff
Hi,
On Wed, Oct 31, 2018 at 4:59 AM Daniel Thompson
wrote:
>
> On Tue, Oct 30, 2018 at 01:53:34PM -0700, Douglas Anderson wrote:
> > Typing 'btc' on kdb doing all sorts of fail. Sometimes it would
> > crash, sometimes display nothing, and sometimes hang.
> >
> > Bisect tracked this down to the
Hi,
On Tue, Oct 30, 2018 at 4:56 AM Daniel Thompson
wrote:
>
> On Mon, Oct 29, 2018 at 11:07:00AM -0700, Douglas Anderson wrote:
> > Looking back, this is pretty much two series squashed that could be
> > treated indepdently. The first is a serial series and the second is a
> > kgdb series.
>
>
Hi,
On Wed, Oct 31, 2018 at 11:40 AM Daniel Thompson
wrote:
>
> On Tue, Oct 30, 2018 at 03:18:43PM -0700, Douglas Anderson wrote:
> > diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
> > index f3cadda45f07..9a3f952de6ed 100644
> > --- a/kernel/debug/debug_core.c
> > +++
Daniel,
On Tue, Oct 30, 2018 at 2:42 AM Daniel Thompson
wrote:
>
> On Mon, Oct 29, 2018 at 11:07:06AM -0700, Douglas Anderson wrote:
> > In kgdb_roundup_cpus() we've got code that looks like:
> > local_irq_enable();
> > smp_call_function(kgdb_call_nmi_hook, NULL, 0);
> >
Hi,
On Tue, Oct 30, 2018 at 4:46 AM Daniel Thompson
wrote:
>
> On Mon, Oct 29, 2018 at 11:07:07AM -0700, Douglas Anderson wrote:
> > The function kgdb_roundup_cpus() was passed a parameter that was
> > documented as:
> >
> > > the flags that will be used when restoring the interrupts. There is
>
Hi,
On Wed, Nov 7, 2018 at 4:30 AM Daniel Thompson
wrote:
>
> On Tue, Nov 06, 2018 at 05:00:28PM -0800, Douglas Anderson wrote:
> > If you have a CPU that fails to round up and then run 'btc' you'll end
> > up crashing in kdb becaue we dereferenced NULL. Let's add a check.
> > It's wise to also
Hi,
On Sat, Nov 3, 2018 at 3:45 AM Daniel Thompson
wrote:
>
> On Wed, Oct 31, 2018 at 02:41:14PM -0700, Doug Anderson wrote:
> > > As mentioned in another part of the thread we can also add robustness
> > > by skipping a cpu where csd->flags != 0 (and adding an approp
Hi,
On Wed, Nov 7, 2018 at 3:59 AM Daniel Thompson
wrote:
>
> On Tue, Nov 06, 2018 at 05:00:27PM -0800, Douglas Anderson wrote:
> > If we're using the default implementation of kgdb_roundup_cpus() that
> > uses smp_call_function_single_async() we can end up hanging
> > kgdb_roundup_cpus() if we
Hi,
On Fri, Dec 7, 2018 at 9:42 AM Catalin Marinas wrote:
>
> On Tue, Dec 04, 2018 at 07:38:24PM -0800, Douglas Anderson wrote:
> > Douglas Anderson (4):
> > kgdb: Remove irq flags from roundup
> > kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()
> > kgdb: Don't round
Hi,
On Mon, Dec 3, 2018 at 7:57 AM Daniel Thompson
wrote:
>
> On Tue, Nov 27, 2018 at 09:38:37AM -0800, Douglas Anderson wrote:
> > When I had lockdep turned on and dropped into kgdb I got a nice splat
> > on my system. Specifically it hit:
> > DEBUG_LOCKS_WARN_ON(current->hardirq_context)
>
Hi,
On Mon, Nov 26, 2018 at 9:39 PM kbuild test robot wrote:
>
> Hi Douglas,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on kgdb/kgdb-next]
> [also build test ERROR on v4.20-rc4 next-20181126]
> [if your patch is applied to the wrong git tree, please drop us
Hi,
On Wed, Nov 14, 2018 at 2:07 PM Will Deacon wrote:
>
> > +void __weak kgdb_call_nmi_hook(void *ignored)
> > +{
> > + kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
> > +}
>
> I suppose you could pass the cpu as an argument, but it doesn't really
> matter.
I probably won't
Hi,
On Tue, Dec 18, 2018 at 9:05 AM Daniel Thompson
wrote:
>
> On Sun, Dec 09, 2018 at 06:36:49PM -0800, Douglas Anderson wrote:
> > Ever since commit 5516fd7b92a7 ("debug: prevent entering debug mode on
> > panic/exception.") (yes, years ago) my kgdb workflow has been broken.
> > On Chrome OS
Hi,
On Wed, Mar 27, 2019 at 6:17 AM qiaochong wrote:
>
> KGDB_call_nmi_hook is called by other cpu through smp call.
> MIPS smp call is processed in ipi irq handler and regs is saved in
> handle_int.
> So kgdb_call_nmi_hook get regs by get_irq_regs and regs will be passed
> to kgdb_cpu_enter.
Hi,
On Tue, Mar 19, 2019 at 4:25 AM Daniel Thompson
wrote:
>
> On Mon, Mar 18, 2019 at 01:47:40PM -0700, Douglas Anderson wrote:
> > These two new exported functions will be used in a future patch by
> > kdb_ftdump() to quickly skip all but the last few trace entries.
> >
> > Suggested-by:
Hi,
On Fri, Mar 15, 2019 at 11:41 AM Steven Rostedt wrote:
>
> On Fri, 15 Mar 2019 10:45:28 -0700
> Douglas Anderson wrote:
>
>
> > Changes in v3:
> > - Optimize counting as per Steven Rostedt.
> > - Down to 1 patch since patch #1 from v2 landed.
> >
> > kernel/trace/trace_kdb.c | 38
Hi,
On Fri, Mar 15, 2019 at 1:12 PM Steven Rostedt wrote:
>
> On Fri, 15 Mar 2019 12:55:31 -0700
> Doug Anderson wrote:
>
> > >
> > > Actually, you can add a function in trace.c that exposes
> > > get_total_entries:
> > >
> > >
Hi,
On Fri, Mar 15, 2019 at 2:08 PM Steven Rostedt wrote:
> > > The get_total_entries() is the faster approach to get the count, but in
> > > either case, the count should end up the same.
> >
> > If you're OK with going back to the super slow mechanism in v1 I can
> > do that and we can be
Hi,
On Mon, Feb 11, 2019 at 11:58 AM Dave Martin wrote:
>
> On Mon, Feb 11, 2019 at 09:27:11AM -0800, Doug Anderson wrote:
> > Hi,
> >
> > On Mon, Feb 4, 2019 at 4:31 AM Dave Martin wrote:
> > >
> > > On Fri, Feb 01, 2019 at 01:38:05PM -0800, Doug And
Hi,
On Mon, Feb 4, 2019 at 5:12 AM Mark Rutland wrote:
>
> On Fri, Feb 01, 2019 at 01:38:05PM -0800, Doug Anderson wrote:
> > Hi,
>
> Hi Doug,
>
> > I was wondering if anyone out there has given any thought to
> > annotating the ARM64 IRQ handling in such a way t
Hi,
On Mon, Feb 4, 2019 at 4:31 AM Dave Martin wrote:
>
> On Fri, Feb 01, 2019 at 01:38:05PM -0800, Doug Anderson wrote:
> > Hi,
> >
> > I was wondering if anyone out there has given any thought to
> > annotating the ARM64 IRQ handling in such a way that we coul
Hi,
On Mon, May 6, 2019 at 5:50 AM Dan Carpenter wrote:
>
> The "whichcpu" comes from argv[3]. The cpu_online() macro looks up the
> cpu in a bitmap of online cpus, but if the value is too high then it
> could read beyond the end of the bitmap and possibly Oops.
>
> Fixes: 5d5314d6795f ("kdb:
Hi,
On Tue, Mar 19, 2019 at 10:12 AM Douglas Anderson wrote:
>
> The things skipped by kdb's "ftdump" command when you pass it a
> parameter has always been entries, not lines. The difference usually
> doesn't matter but when the trace buffer has multi-line entries (like
> a stack dump) it can
Hi,
On Wed, Jul 31, 2019 at 7:24 AM Jan Kiszka wrote:
>
> On 31.07.19 01:40, Douglas Anderson wrote:
> > Some systems (like Chrome OS) may use "split debug" for kernel
> > modules. That means that the debug symbols are in a different file
> > than the main elf file. Let's handle that by also
Jason / Daniel,
On Wed, Jul 31, 2019 at 11:38 AM Douglas Anderson wrote:
>
> In kdb when you do 'btc' (back trace on CPU) it doesn't necessarily
> give you the right info. Specifically on many architectures
> (including arm64, where I tested) you can't dump the stack of a
> "running" process
Hi,
On Wed, Jul 31, 2019 at 5:57 AM Will Deacon wrote:
>
> Hi Doug,
>
> On Tue, Jul 30, 2019 at 03:18:00PM -0700, Douglas Anderson wrote:
> > diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
> > index 43119922341f..b666210fbc75 100644
> > --- a/arch/arm64/kernel/kgdb.c
> > +++
Hi,
On Thu, Oct 10, 2019 at 9:38 AM Doug Anderson wrote:
>
> Hi,
>
> On Thu, Oct 10, 2019 at 8:07 AM Daniel Thompson
> wrote:
> > > Reading through other control flows of the various backtrace commands,
> > > it looks like it is intentional to leave the cu
Hi,
On Thu, Nov 14, 2019 at 2:51 AM Daniel Thompson
wrote:
>
> On Sat, Nov 09, 2019 at 11:16:40AM -0800, Douglas Anderson wrote:
> > As of commit 2277b492582d ("kdb: Fix stack crawling on 'running' CPUs
> > that aren't the master") we no longer need any special case for doing
> > stack dumps on
Hi,
On Mon, Oct 21, 2019 at 3:11 AM Daniel Thompson
wrote:
>
> Recent versions of gcc (reported on gcc-7.4) issue array subscript
> warnings for builds where SMP is not enabled.
>
> kernel/debug/debug_core.c: In function 'kdb_dump_stack_on_cpu':
> kernel/debug/debug_core.c:452:17: warning: array
Hi,
On Mon, Oct 14, 2019 at 9:28 AM Daniel Thompson
wrote:
>
> Hi Doug
>
> On Fri, Oct 11, 2019 at 12:41:31AM +0800, kbuild test robot wrote:
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/danielt/linux.git
> > kgdb/for-next
> > head: 2277b492582d5525244519f60da6f9daea5ef41a
> >
Hi,
On Mon, Oct 14, 2019 at 8:46 AM Daniel Thompson
wrote:
>
> Currently if sequences such as "\ehelp\r" are delivered to the console then
> the h gets eaten by the escape handling code. Since pressing escape
> becomes something of a nervous twitch for vi users (and that escape doesn't
> have
Hi,
On Mon, Oct 14, 2019 at 8:46 AM Daniel Thompson
wrote:
>
> Currently if an escape timer is interrupted by a character from a
> different input source then the new character is discarded and the
> function returns '\e' (which will be discarded by the level above).
> It is hard to see why this
Hi,
On Mon, Oct 14, 2019 at 8:46 AM Daniel Thompson
wrote:
>
> @@ -91,12 +92,17 @@ kdb_bt1(struct task_struct *p, unsigned long mask,
> kdb_ps1(p);
> kdb_show_stack(p, NULL);
> if (btaprompt) {
> - kdb_getstr(buffer, sizeof(buffer),
> -
Hi,
On Fri, Aug 30, 2019 at 7:52 AM Daniel Thompson
wrote:
>
> On Wed, Jul 31, 2019 at 11:37:32AM -0700, Douglas Anderson wrote:
> > In kdb when you do 'btc' (back trace on CPU) it doesn't necessarily
> > give you the right info. Specifically on many architectures
> > (including arm64, where I
Hi,
On Mon, Oct 7, 2019 at 6:55 AM Daniel Thompson
wrote:
>
> On Wed, Sep 25, 2019 at 01:02:19PM -0700, Douglas Anderson wrote:
> >
> > I noticed that when I did "btc " and the CPU I passed in hadn't
> > rounded up that I'd crash. I was going to copy the same fix from
> > commit 162bc7f5afd7
Hi,
On Thu, Oct 10, 2019 at 8:07 AM Daniel Thompson
wrote:
> > Reading through other control flows of the various backtrace commands,
> > it looks like it is intentional to leave the current task changed when
> > you explicitly do an action on that task (or a CPU).
> >
> > Actually, though, it
Hi,
On Tue, Oct 8, 2019 at 6:21 AM Daniel Thompson
wrote:
>
> Currently kdb_read_get_key() contains complex control flow that, on
> close inspection, turns out to be unnecessary. In particular:
>
> 1. It is impossible to enter the branch conditioned on (escape_delay == 1)
>except when the
Hi,
On Tue, Oct 8, 2019 at 6:21 AM Daniel Thompson
wrote:
>
> Currently if an escape timer is interrupted by a character from a
> different input source then the new character is discarded and the
> function returns '\e' (which will be discarded by the level above).
> It is hard to see why this
Hi,
On Tue, Oct 8, 2019 at 6:21 AM Daniel Thompson
wrote:
>
> kdb_read() contains special case logic to force it exit after reading
> a single character. We can remove all the special case logic by directly
> calling the function to read a single character instead. This also
> allows us to tidy
Hi,
On Tue, Oct 8, 2019 at 6:21 AM Daniel Thompson
wrote:
>
> Currently if sequences such as "\ehelp\r" are delivered to the console then
> the h gets eaten by the escape handling code. Since pressing escape
> becomes something of a nervous twitch for vi users (and that escape doesn't
> have
Hi,
On Tue, Oct 8, 2019 at 6:21 AM Daniel Thompson
wrote:
>
> kdb_read_get_key() has extremely complex break/continue control flow
> managed by state variables and is very hard to review or modify. In
> particular the way the escape sequence handling interacts with the
> general control flow is
Hi,
On Wed, Oct 9, 2019 at 2:30 AM Daniel Thompson
wrote:
>
> > > @@ -183,17 +186,7 @@ static int kdb_read_get_key(char *buffer, size_t
> > > bufsize)
> > > * function. It is not reentrant - it relies on the fact
> > > * that while kdb is running on only one "master debug" cpu.
> >
Hi,
On Thu, Feb 13, 2020 at 7:06 AM Daniel Thompson
wrote:
>
> Currently the code to manage the kdb history buffer uses strncpy() to
> copy strings to/and from the history and exhibits the classic "but
> nobody ever told me that strncpy() doesn't always terminate strings"
> bug. Modern gcc
Hi,
On Thu, Feb 13, 2020 at 8:42 AM Daniel Thompson
wrote:
>
> Currently the PROMPT variable could be abused to provoke the printf()
> machinery to read outside the current stack frame. Normally this
> doesn't matter becaues md is already a much better tool for reading
> from memory.
>
> However
Hi,
On Wed, Feb 5, 2020 at 9:30 AM Daniel Thompson
wrote:
>
> On Tue, Feb 04, 2020 at 02:12:25PM -0800, Douglas Anderson wrote:
> > In commit bbfceba15f8d ("kdb: Get rid of confusing diag msg from "rd"
> > if current task has no regs") I tried to clean things up by using "if"
> > instead of
Hi,
On Thu, Feb 6, 2020 at 3:58 AM Daniel Thompson
wrote:
>
> On Wed, Feb 05, 2020 at 10:01:17AM -0800, Doug Anderson wrote:
> > Hi,
> >
> > On Wed, Feb 5, 2020 at 9:30 AM Daniel Thompson
> > wrote:
> > >
> > > On Tue, Feb 04, 2020 at 02:12:25PM
Hi
On Sat, Nov 9, 2019 at 11:17 AM Douglas Anderson wrote:
>
> This started out as just a follow-up to Daniel's post [1]. I wanted
> to stop implicitly changing the current task in kdb. ...but, of
> course, everywhere you look in kdb there are things to cleanup, so
> this gets a few misc
Hi,
On Fri, Apr 10, 2020 at 4:56 PM kbuild test robot wrote:
>
> Hi Douglas,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on arm64/for-next/core]
> [also build test ERROR on tty/tty-testing v5.6 next-20200410]
> [cannot apply to kgdb/kgdb-next]
> [if your patch is
Hi,
On Mon, Apr 27, 2020 at 9:36 AM Daniel Thompson
wrote:
>
> On Tue, Apr 21, 2020 at 02:14:44PM -0700, Douglas Anderson wrote:
> > We want to enable kgdb to debug the early parts of the kernel.
> > Unfortunately kgdb normally is a client of the tty API in the kernel
> > and serial drivers
Hi,
On Fri, Apr 24, 2020 at 1:15 AM Sumit Garg wrote:
>
> Implement the read() function in the early console driver. With
> recently added earlycon_kgdboc feature, this allows you to use kgdb
> to debug fairly early into the system boot.
>
> We only bother implementing this if polling is enabled
ompson
> ---
>
> Notes:
> v2: Simplified, more robust, runs earlier, still has Doug's
> recent patchset as a prerequisite. What's not to like?
>
> More specifically, based on feedback from Doug Anderson, I
> have replaced the initial hacky implementation with a
Hi,
On Thu, Apr 30, 2020 at 8:49 AM Daniel Thompson
wrote:
>
> On Tue, Apr 28, 2020 at 02:13:44PM -0700, Douglas Anderson wrote:
> > Using kgdb requires at least some level of architecture-level
> > initialization. If nothing else, it relies on the architecture to
> > pass breakpoints / crashes
Hi,
On Fri, Apr 24, 2020 at 4:11 AM Sumit Garg wrote:
>
> With pseudo NMIs support available its possible to configure SGIs to be
> triggered as pseudo NMIs running in NMI context. And kernel features
> such as kgdb relies on NMI support to round up CPUs which are stuck in
> hard lockup state
Hi,
On Fri, Apr 24, 2020 at 4:11 AM Sumit Garg wrote:
>
> arm64 platforms with GICv3 or later supports pseudo NMIs which can be
> leveraged to round up CPUs which are stuck in hard lockup state with
> interrupts disabled that wouldn't be possible with a normal IPI.
>
> So instead switch to round
Hi,
On Mon, May 11, 2020 at 7:59 AM Will Deacon wrote:
>
> Hi Doug,
>
> On Tue, Apr 28, 2020 at 02:13:45PM -0700, Douglas Anderson wrote:
> > diff --git a/arch/arm64/kernel/debug-monitors.c
> > b/arch/arm64/kernel/debug-monitors.c
> > index 48222a4760c2..59c353dfc8e9 100644
> > ---
Hi,
On Tue, May 12, 2020 at 12:36 AM Will Deacon wrote:
>
> On Mon, May 11, 2020 at 03:45:02PM -0700, Doug Anderson wrote:
> > On Mon, May 11, 2020 at 7:59 AM Will Deacon wrote:
> > > On Tue, Apr 28, 2020 at 02:13:45PM -0700, Douglas Anderson wrote:
> > > > dif
Hi,
On Thu, May 7, 2020 at 1:09 PM Douglas Anderson wrote:
>
> In order to make early kgdb work properly we need early_brk64() to be
> able to call into it. This is as easy as adding a call into
> call_break_hook() just like we do later in the normal brk_handler().
>
> Once we do this we can
Hi,
On Tue, May 12, 2020 at 11:17 PM Will Deacon wrote:
>
> Hey Doug,
>
> On Tue, May 12, 2020 at 08:27:50AM -0700, Doug Anderson wrote:
> > On Tue, May 12, 2020 at 12:36 AM Will Deacon wrote:
> > > On Mon, May 11, 2020 at 03:45:02PM -0700, Doug Anderson wrote:
> &
Hi,
On Sun, May 10, 2020 at 7:18 PM Wei Li wrote:
>
> 'KDBFLAGS' is an internal variable of kdb, it is combined by 'KDBDEBUG'
> and state flags. But the user can define an environment variable named
> 'KDBFLAGS' too, so let's make it undefinable to avoid confusion.
>
> Signed-off-by: Wei Li
>
Hi,
On Fri, May 15, 2020 at 9:36 AM Sergey Senozhatsky
wrote:
>
> On (20/05/15 17:32), Sumit Garg wrote:
> > > Can I please have some context what problem does this solve?
> >
> > You can find the problem description here [1] which leads to this fix.
>
> [..]
>
> > [1]
Hi,
On Thu, May 14, 2020 at 9:21 AM Daniel Thompson
wrote:
>
> On Thu, May 07, 2020 at 01:08:38PM -0700, Douglas Anderson wrote:
> >
> >
> > My first attempt was to try to get the existing "ekgdboc" to work
> > earlier. I tried that for a bit until I realized that it needed to
> > work at the
Hi,
On Mon, Mar 16, 2020 at 7:43 AM Dmitry Safonov wrote:
>
> Print the stack trace with KERN_EMERG - it should be always visible.
>
> Playing with console_loglevel is a bad idea as there may be more
> messages printed than wanted. Also the stack trace might be not printed
> at all if printk()
Hi,
On Thu, May 7, 2020 at 4:07 AM Jason Yan wrote:
>
> Fix the following coccicheck warning:
>
> include/linux/kgdb.h:301:54-55: WARNING: return of 0/1 in function
> 'kgdb_nmi_poll_knock' with return type bool
>
> Signed-off-by: Jason Yan
> ---
> include/linux/kgdb.h | 2 +-
> 1 file changed,
Hi,
On Mon, May 4, 2020 at 4:53 AM Daniel Thompson
wrote:
>
> On Fri, May 01, 2020 at 10:36:14AM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, May 1, 2020 at 6:32 AM Daniel Thompson
> > wrote:
> > >
> > > On Fri, May 01, 2020 at 12:49:43PM +
Hi,
On Wed, May 6, 2020 at 8:17 AM Andy Shevchenko
wrote:
>
> Kernel doc does not understand POD variables to be referred to.
>
> .../debug_core.c:73: warning: cannot understand function prototype:
> 'int kgdb_connected; '
>
> Convert kernel doc to pure comment.
>
>
Hi,
On Wed, May 6, 2020 at 9:42 AM Daniel Thompson
wrote:
>
> Currently there is a small window where a badly timed migration could
> cause in_dbg_master() to spuriously return true. Specifically if we
> migrate to a new core after reading the processor id and the previous
> core takes a
Hi,
On Tue, Mar 3, 2020 at 12:52 PM Doug Anderson wrote:
>
> Hi,
>
> On Thu, Feb 13, 2020 at 7:06 AM Daniel Thompson
> wrote:
> >
> > Currently the code to manage the kdb history buffer uses strncpy() to
> > copy strings to/and from the history and exhibits the
Hi,
On Fri, May 1, 2020 at 4:49 AM Daniel Thompson
wrote:
>
> On Thu, Apr 30, 2020 at 09:59:09AM -0700, Douglas Anderson wrote:
> > The original implementation of kgdboc_earlycon included a comment
> > about how it was impossible to get notified about the boot console
> > going away without
Hi,
On Fri, May 1, 2020 at 6:32 AM Daniel Thompson
wrote:
>
> On Fri, May 01, 2020 at 12:49:43PM +0100, Daniel Thompson wrote:
> > On Thu, Apr 30, 2020 at 09:59:09AM -0700, Douglas Anderson wrote:
> > > The original implementation of kgdboc_earlycon included a comment
> > > about how it was
Hi,
On Thu, Apr 30, 2020 at 9:47 AM Doug Anderson wrote:
>
> Hi,
>
> On Thu, Apr 30, 2020 at 9:18 AM Daniel Thompson
> wrote:
> >
> > Currently there is no guarantee that an earlycon will be initialized
> > before kgdboc tries to adopt it. Almost the o
Hi,
On Mon, Aug 17, 2020 at 5:27 AM Sumit Garg wrote:
>
> Thanks for your suggestion, irq_work_schedule() looked even better
> without any overhead, see below:
>
> diff --git a/include/linux/irq_work.h b/include/linux/irq_work.h
> index 3082378..1eade89 100644
> --- a/include/linux/irq_work.h
>
Hi,
On Mon, Aug 17, 2020 at 7:08 AM Sumit Garg wrote:
>
> On Fri, 14 Aug 2020 at 20:27, Doug Anderson wrote:
> >
> > Hi,
> >
> > On Fri, Aug 14, 2020 at 12:24 AM Sumit Garg wrote:
> > >
> > > + Peter (author of irq_work.c)
> > >
Hi,
On Sun, Sep 27, 2020 at 2:16 PM Daniel Thompson
wrote:
>
> Currently kgdb honours the kprobe blocklist but doesn't place its own
> trap handling code on the list. Add labels to discourage attempting to
> use kgdb to debug itself.
>
> Not every functions that executes from the trap handler
Hi,
On Mon, Sep 14, 2020 at 6:02 AM Daniel Thompson
wrote:
>
> Currently kgdb honours the kprobe blocklist but doesn't place its own
> trap handling code on the list. Add labels to discourage attempting to
> use kgdb to debug itself.
>
> Not every functions that executes from the trap handler
Hi,
On Mon, Sep 14, 2020 at 6:02 AM Daniel Thompson
wrote:
>
> During debug trap execution we expect dbg_deactivate_sw_breakpoints()
> to be paired with an dbg_activate_sw_breakpoint(). Currently although
> the calls are paired correctly they are needlessly smeared across three
> different
Hi,
On Wed, Sep 9, 2020 at 7:18 AM Daniel Thompson
wrote:
>
> Currently using forward search doesn't handle multi-line strings correctly.
> The search routine replaces line breaks with \0 during the search and, for
> regular searches ("help | grep Common\n"), there is code after the line
> has
Hi,
On Tue, May 19, 2020 at 3:41 AM Daniel Thompson
wrote:
>
> On Thu, May 07, 2020 at 03:53:58PM -0700, Douglas Anderson wrote:
> > At times when I'm using kgdb I see a splat on my console about
> > suspicious RCU usage. I managed to come up with a case that could
> > reproduce this that
Hi,
On Tue, Sep 15, 2020 at 6:45 AM Daniel Thompson
wrote:
>
> On Mon, Sep 14, 2020 at 05:13:28PM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Mon, Sep 14, 2020 at 6:02 AM Daniel Thompson
> > wrote:
> > >
> > > During debug trap e
Hi,
On Mon, Jul 20, 2020 at 1:13 AM Daniel Thompson
wrote:
>
> On Fri, Jul 17, 2020 at 03:39:58PM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Jul 16, 2020 at 8:20 AM Daniel Thompson
> > wrote:
> > >
> > > Currently kgdb honours the kprob
Hi,
On Mon, Jul 20, 2020 at 1:08 AM Daniel Thompson
wrote:
>
> On Fri, Jul 17, 2020 at 03:39:51PM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Jul 16, 2020 at 8:20 AM Daniel Thompson
> > wrote:
> > >
> > > If we are running in a part of the
Hi,
On Tue, Aug 11, 2020 at 7:58 AM Greg Kroah-Hartman
wrote:
>
> On Tue, Aug 11, 2020 at 07:59:24PM +0530, Sumit Garg wrote:
> > Hi Greg,
> >
> > Thanks for your comments.
> >
> > On Tue, 11 Aug 2020 at 19:27, Greg Kroah-Hartman
> > wrote:
> > >
> > > On Tue, Aug 11, 2020 at 07:20:26PM +0530,
Hi,
On Mon, Aug 10, 2020 at 5:32 AM Akash Asthana wrote:
>
> Hi Doug,
>
> On 8/7/2020 10:49 AM, Douglas Anderson wrote:
> > The commit e42d6c3ec0c7 ("serial: qcom_geni_serial: Make kgdb work
> > even if UART isn't console") worked pretty well and I've been doing a
> > lot of debugging with it.
Hi,
On Wed, Aug 12, 2020 at 7:53 AM Sumit Garg wrote:
>
> Hi Doug,
>
> On Tue, 11 Aug 2020 at 22:46, Doug Anderson wrote:
> >
> > Hi,
> >
> > On Tue, Aug 11, 2020 at 7:58 AM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Tue, Aug 11,
Hi,
On Wed, Aug 12, 2020 at 8:27 AM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Aug 12, 2020 at 7:53 AM Sumit Garg wrote:
> >
> > Hi Doug,
> >
> > On Tue, 11 Aug 2020 at 22:46, Doug Anderson wrote:
> > >
> > > Hi,
> > >
> &
Hi,
On Tue, Jul 21, 2020 at 5:11 AM Sumit Garg wrote:
>
> Add NMI framework APIs in serial core which can be leveraged by serial
> drivers to have NMI driven serial transfers. These APIs are kept under
> CONFIG_CONSOLE_POLL as currently kgdb initializing uart in polling mode
> is the only known
Hi,
On Tue, Jul 21, 2020 at 5:10 AM Sumit Garg wrote:
>
> In a future patch we will add support to the serial core to make it
> possible to trigger a magic sysrq from an NMI context. Prepare for this
> by marking some sysrq actions as NMI safe. Safe actions will be allowed
> to run from NMI
Hi,
On Tue, Jul 21, 2020 at 5:11 AM Sumit Garg wrote:
>
> Allow serial device interrupt to be requested as an NMI during
> initialization in polling mode. If the irqchip doesn't support serial
> device interrupt as an NMI then fallback to it being as a normal IRQ.
>
> Currently this NMI aware
Hi,
On Thu, Aug 13, 2020 at 7:19 AM Sumit Garg wrote:
>
> On Thu, 13 Aug 2020 at 05:29, Doug Anderson wrote:
> >
> > Hi,
> >
> > On Tue, Jul 21, 2020 at 5:11 AM Sumit Garg wrote:
> > >
> > > Add NMI framework APIs in serial core which can be leve
Hi,
On Thu, Aug 13, 2020 at 2:25 AM Sumit Garg wrote:
>
> > One other idea occurred to me that's maybe simpler. You could in
> > theory just poll the serial port periodically to accomplish. It would
> > actually probably even work to call the normal serial port interrupt
> > routine from any
Hi,
On Tue, Jun 30, 2020 at 10:49 AM Dan Carpenter wrote:
>
> Hello Sumit Garg,
>
> This is a semi-automatic email about new static checker warnings.
>
> The patch 5946d1f5b309: "kdb: Switch to use safer dbg_io_ops over
> console APIs" from Jun 4, 2020, leads to the following Smatch
> complaint:
Hi,
On Fri, Jul 10, 2020 at 12:03 PM Evan Green wrote:
>
> On Fri, Jul 10, 2020 at 11:19 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Fri, Jul 10, 2020 at 10:39 AM Evan Green wrote:
> > >
> > > On Fri, Jun 26, 2020 at 1:01 PM Douglas Anderso
Hi,
On Fri, Jul 10, 2020 at 10:39 AM Evan Green wrote:
>
> On Fri, Jun 26, 2020 at 1:01 PM Douglas Anderson
> wrote:
> >
> > The geni serial driver had the rather sketchy hack in it where it
> > would adjust the number of bytes per RX FIFO word from 4 down to 1 if
> > it detected that
Hi,
On Fri, Jul 10, 2020 at 10:46 AM Evan Green wrote:
>
> On Fri, Jun 26, 2020 at 1:01 PM Douglas Anderson
> wrote:
> >
> > The geni serial driver had a rule that we'd only use 1 byte per FIFO
> > word for the TX FIFO if we were being used for the serial console.
> > This is ugly and a bit of
Hi,
On Tue, Jun 30, 2020 at 1:30 AM Cengiz Can wrote:
>
> `kdb_msg_write` operates on a global `struct kgdb_io *` called
> `dbg_io_ops`.
>
> It's initialized in `debug_core.c` and checked throughout the debug
> flow.
>
> There's a null check in `kdb_msg_write` which triggers static analyzers
>
Hi,
On Tue, Jun 30, 2020 at 8:05 AM Daniel Thompson
wrote:
>
> On Mon, Jun 29, 2020 at 02:03:52PM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Mon, Jun 29, 2020 at 10:15 AM Daniel Thompson
> > wrote:
> > >
> > > Currently kgdb_re
Hi,
On Mon, Jun 29, 2020 at 1:50 PM Cengiz Can wrote:
>
> `kdb_msg_write` operates on a global `struct kgdb_io *` called
> `dbg_io_ops`.
>
> It's initialized in `debug_core.c` and checked throughout the debug
> flow.
>
> There's a null check in `kdb_msg_write` which triggers static analyzers
>
Hi,
On Mon, Jun 29, 2020 at 10:15 AM Daniel Thompson
wrote:
>
> Currently kgdb_register_callbacks() and kgdb_unregister_callbacks()
> are called outside the scope of the kgdb_registration_lock. This
> allows them to race with each other. This could do all sorts of crazy
> things up to and
1 - 100 of 256 matches
Mail list logo
