On Mon, Apr 24, 2023 at 08:23:59AM -0700, Doug Anderson wrote:
> HPET system seems to have a single CPU in charge of processing the
> main NMI and then that single CPU is in charge of checking all the
> others. If that single CPU goes out to lunch then the system couldn't
> detect hard lockups.
>
On Mon, Jan 21, 2013 at 06:06:13PM +0100, Jan Kiszka wrote:
> This pokes into the log buffer of the debugged kernel, dumping it to the
> gdb console. Helping in case the target should or can no longer execute
> dmesg itself.
Very useful, as this got very painful when the log buffer was changed
a f
On Mon, Jan 21, 2013 at 06:06:10PM +0100, Jan Kiszka wrote:
> This is probably the most useful helper when debugging kernel modules:
> lx-symbols will first reload vmlinux. Then it searches recursively for
> *.ko files in the specified paths and the current directory. Finally it
> walks the kernel'
Jan Kiszka writes:
> From: Jan Kiszka
>
> This pokes into the log buffer of the debugged kernel, dumping it to the
> gdb console. Helping in case the target should or can no longer execute
> dmesg itself.
Thanks. That's very useful. I recently ran into this problem that
the new log buffer is a
On Mon, Dec 28, 2009 at 04:36:03PM -0600, Jason Wessel wrote:
> Andi Kleen wrote:
> > Jason Wessel writes:
> >
> > I remember going with kaos through all the code
> > outside kdb/ in his own patch and for nearly all hooks
> > outside we found some way to elimin
Jason Wessel writes:
I remember going with kaos through all the code
outside kdb/ in his own patch and for nearly all hooks
outside we found some way to eliminate them.
I think a lot of this is here too.
>
> +#ifdef CONFIG_KGDB_KDB
> +/* Like meminfo_proc_show() but without the locks a
On Thursday 05 October 2006 23:30, Piet Delaney wrote:
> On Thu, 2006-10-05 at 12:17 -0700, Tom Rini wrote:
> > On Thu, Oct 05, 2006 at 08:46:20AM -0700, George Anzinger wrote:
> > > Tom Rini wrote:
> > > >On Wed, Oct 04, 2006 at 08:42:04PM -0700, Piet Delaney wrote:
> > > >
> > > >
> > > >>Ton, Ge
On Thursday 31 August 2006 16:20, Tom Rini wrote:
> On Thu, Aug 31, 2006 at 04:07:15PM +0200, Andi Kleen wrote:
> > Piet Delaney <[EMAIL PROTECTED]> writes:
> > > >
> > > > ENOPATCH
> > >
> > > Opps.
> >
> > What an ugly pat
Piet Delaney <[EMAIL PROTECTED]> writes:
> >
> > ENOPATCH
>
> Opps.
What an ugly patch!
But it should be totally obsolete with the unwinder work Jan and me have been
doing recently which does this all properly. .18 isn't quite there
yet in all cases, but .19 will be hopefully.
-Andi
On Wednesday 21 June 2006 11:48, Milind Dumbare wrote:
> Hi All,
> Patch attached below replaces occurrences of checks of
> pidhash_init_done by checks of last_pid. I have tested it on i386 and
> x86_64 with both serial and ethernet. It works fine.
Ok if you got it working without changing t
> No, that one I suspect, but haven't had a chance to verify, can die.
Ok.
> The one we can't get rid of is our adding a flag for pidhash_init()
> being done. The problem is that many GDB front-ends (Eclipse) will
> always do an 'info threads' upon connect. But if they connect before
> pidhas
On Wed, Jun 14, 2006 at 04:47:58PM -0700, Tom Rini wrote:
> > Then all of our stuff should be #ifdef KGDB; while merging from 2.6.12
> > to 2.6.13 I recall it noticing a few of the #ifdef KGDB's had been
> > removed.
>
> Yes, there really shouldn't be any #ifdef KGDB's in the kernel tree and
> w
On Thursday 01 June 2006 00:35, Tom Rini wrote:
> On Wed, May 31, 2006 at 11:01:56PM +0200, Andi Kleen wrote:
> > On Wednesday 31 May 2006 17:03, Tom Rini wrote:
> > > On Wed, May 31, 2006 at 09:13:53AM +0200, Andi Kleen wrote:
> > >
> > > [snip]
> > >
On Wednesday 31 May 2006 17:03, Tom Rini wrote:
> On Wed, May 31, 2006 at 09:13:53AM +0200, Andi Kleen wrote:
>
> [snip]
>
> > Yes because you if modular works you don't need to build it in.
> >
> > Modular was working at some point on x86-64 for kdb and the o
> My bet is that in this case I was storing a LOT of
> data in the thread structure, so the space left for
> the stack was massively reduced.
Ok so it was your bug. Don't do that.
> Sure but the debugger environment must tolerate larger stacks.
No, Linux doesn't tolerate larger stacks.
> Bu
On Wednesday 31 May 2006 08:46, Piet Delaney wrote:
> On Wed, 2006-05-31 at 07:50 +0200, Andi Kleen wrote:
> > > Perhaps we should add a kgdb config menu option and #define
> > > CONFIG_16KSTACKS to double the stack size so the kernel can be
> > > debugged wi
> Perhaps we should add a kgdb config menu option and #define
> CONFIG_16KSTACKS to double the stack size so the kernel can be
> debugged with more context available. I'm currently using -O0 for
> the networking stack and -O1 for the rest of the kernel. Sounds like
> it would be helpful now for
17 matches
Mail list logo
