Re: [Kgdb-bugreport] [PATCH] attempt fix up breakpoint on reenter to KGDB

Sergei Shtylyov wrote: If there are no objections, I will commit the following patch. Sorry for the belated objections. :- Signed-off-by: Jason Wessel [EMAIL PROTECTED] Index: linux-2.6.21.1/kernel/kgdb.c === ---

Re: [Kgdb-bugreport] [PATCH] attempt fix up breakpoint on reenter to KGDB

Hello, I wrote: If there are no objections, I will commit the following patch. -- This patch fixes some corner cases where KGDB will silently hang or kill the system, if a user accidentally tries to source step into a spin_unlock() call or source step in on a macro containing

Re: [Kgdb-bugreport] [PATCH] attempt fix up breakpoint on reenter to KGDB

Hello. Jason Wessel wrote: If not can you provide me with a test case to see the problem? Well, for example, with 2.6.18-rt7 kernel, stepping into smp_processor_id() was blowing away U-Boot (!) on my PPC board (even in PREEMPT_DESKTOP mode)... On x86, stepping past preempt_disable()

Re: [Kgdb-bugreport] [PATCH] attempt fix up breakpoint on reenter to KGDB

Sergei Shtylyov wrote: [Sat May 19 2007, 02:54:00PM EDT] Jason Wessel wrote: This patch is committed in the linux2_6_21_uprev branch across: core-lite.patch core.patch i386-lite.patch x86_64-lite.patch BTW, what's the reason we *still* have both

Re: [Kgdb-bugreport] [PATCH] attempt fix up breakpoint on reenter to KGDB

Jason Wessel wrote: This patch is committed in the linux2_6_21_uprev branch across: core-lite.patch core.patch i386-lite.patch x86_64-lite.patch BTW, what's the reason we *still* have both {core|i386|ia64|powerpc|x86_64}-lite.patch and core{core|i386|ia64|powerpc|x86_64}.patch? Why not

Re: [Kgdb-bugreport] [PATCH] attempt fix up breakpoint on reenter to KGDB

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Wessel wrote: If there are no objections, I will commit the following patch. Sounds great to me; avoiding spin locks() is a hassle. Ever noticed a problem with kgdb surviving a weekend of non-use? I hit a breakpoint on Saturday and hoped to

Re: [Kgdb-bugreport] [PATCH] attempt fix up breakpoint on reenter to KGDB

Pete/Piet Delaney wrote: Sounds great to me; avoiding spin locks() is a hassle. Ever noticed a problem with kgdb surviving a weekend of non-use? I hit a breakpoint on Saturday and hoped to continue looking at it today but the kgdb-stub, as usual, got out of phase and I had to re-do the test

Re: [Kgdb-bugreport] [PATCH] attempt fix up breakpoint on reenter to KGDB

Sergei Shtylyov wrote: Jason Wessel wrote: This patch fixes some corner cases where KGDB will silently hang or kill the system, if a user accidentally tries to source step into a spin_unlock() call or source step in on a macro containing smp_processor_id(). The use of raw_smp_processor_id

Re: [Kgdb-bugreport] [PATCH] attempt fix up breakpoint on reenter to KGDB

Sergei Shtylyov wrote: Hello. Jason Wessel wrote: If not can you provide me with a test case to see the problem? Well, for example, with 2.6.18-rt7 kernel, stepping into smp_processor_id() was blowing away U-Boot (!) on my PPC board (even in PREEMPT_DESKTOP mode)... On x86, stepping

Re: [Kgdb-bugreport] [PATCH] attempt fix up breakpoint on reenter to KGDB

Jason Wessel wrote: This patch fixes some corner cases where KGDB will silently hang or kill the system, if a user accidentally tries to source step into a spin_unlock() call or source step in on a macro containing smp_processor_id(). The use of raw_smp_processor_id is desired in