-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
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
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
Update arch/ppc KGDB implementation:
- merge the begginning of trap-to-signal table containing the more or less
standard traps for all CPU families;
- make the instruction access trap generate SIGSEGV just like its data access
counterpart;
- add some traps specific to Freescale E200/E500,
If there are no objections, I'd like to apply this patch as it fixes a
critical gap when using source stepping that calls a low level
singlestep that steps the boundary from the kernel to the user space.
It is particularly bad when this corner case kills init as you get an
unexpected reboot.
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
Get rid of *all* the remains of the arch/ppc specific KGDB implementation.
Signed-off-by: Sergey Shtylyov [EMAIL PROTECTED]
---
The patch is against the top of KGDB patchset in the linux_2_6_21_uprev branch.
arch/ppc/amiga/config.c |6 --
arch/ppc/platforms/4xx/taishan.c
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
Jason Wessel wrote:
This patch is to fix another corner case where kgdb can pass a single
step trap to user space which was intended for the kernel. Now a
source level next which single steps over an iret instruction will
cause KGDB to continue and print an error to the console, vs the
