Hi Alexander,
Sorry for the really slow response on this...
On 02/06/09 17:31, Alexander Stein wrote:
I'm experiencing several illegal instruction errors during execution of some
programs. Using a BDM debugger I got until the parsing of the exception stack
inside trap_c() (arch/m68knommu/kernel/traps.c) where I stumbled.
The exception vector is extracted as followed:
switch ((fp->ptregs.vector)>> 2)
The reference manual for Coldfire 5208 chapter 3.3.3.1 describe the following:
SSP Format(bits 31-28), FS[3:2](bits 27, 26), Vector(bits 25:18), FS[1:0]
(bits 17, 16), Status Register (bits 15-0)
SSP + 0x4 Prgram Counter (bits 31-0)
In my opinion the vector extraction is wrong, because the vector is defined
with 12 Bits in size (see include/asm-m68knommu/ptrace.h) including the Fault
Status bits at each end of those 12 bits. By just shifting 2 bits to the
right you will still have FS[3:2] at the upper end of ptregs.vector resulting
in a wrong exception vector, if a bit is set in FS[3:2]
So I think the vector extraction has to be changed to something like that:
switch (((fp->ptregs.vector)>> 2)& 0xff)
Yes, you are absolutely correct.
With that change (at every occurrence) I get at least a bus error instead (the
kernel want to execute at address 0xffffffff, but that's another problem) of
illegal instruction, which seems to be a default exception handler.
I used uClinux-dist-20080808, but I noticed this lines of code didn't change
in uClinux-dist-20090520 and even linux-2.6. AFAIK the exception stack is the
same on Coldfire 5484 (V4e core with MMU).
Yes, I am pretty sure it is the same on all.
Attached is the patch I propose to push up-stream to fix this.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
[PATCH] m68knommu: mask of vector bits in exception word properly
The vector field of the processors exception frame actually contains
both the vector exception number and fault status field bits.
The exception processing code was not correctly masking out the
fault status field bits before switching on the vector number.
The default case was catching the bad check, but we are reporting
the wrong kind of exception in some cases.
Problem reported by alexander.st...@systec-electronic.com.
Signed-off-by: Greg Ungerer <g...@uclinux.org>
---
arch/m68knommu/kernel/traps.c | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/m68knommu/kernel/traps.c b/arch/m68knommu/kernel/traps.c
index e8b813d..a768008 100644
--- a/arch/m68knommu/kernel/traps.c
+++ b/arch/m68knommu/kernel/traps.c
@@ -179,14 +179,16 @@ static void __show_stack(struct task_struct *task, unsigned long *stack)
void bad_super_trap(struct frame *fp)
{
+ int vector = (fp->ptregs.vector >> 2) & 0xff;
+
console_verbose();
- if (fp->ptregs.vector < 4 * ARRAY_SIZE(vec_names))
+ if (vector < ARRAY_SIZE(vec_names))
printk (KERN_WARNING "*** %s *** FORMAT=%X\n",
- vec_names[(fp->ptregs.vector) >> 2],
+ vec_names[vector],
fp->ptregs.format);
else
printk (KERN_WARNING "*** Exception %d *** FORMAT=%X\n",
- (fp->ptregs.vector) >> 2,
+ vector,
fp->ptregs.format);
printk (KERN_WARNING "Current process id is %d\n", current->pid);
die_if_kernel("BAD KERNEL TRAP", &fp->ptregs, 0);
@@ -195,10 +197,11 @@ void bad_super_trap(struct frame *fp)
asmlinkage void trap_c(struct frame *fp)
{
int sig;
+ int vector = (fp->ptregs.vector >> 2) & 0xff;
siginfo_t info;
if (fp->ptregs.sr & PS_S) {
- if ((fp->ptregs.vector >> 2) == VEC_TRACE) {
+ if (vector == VEC_TRACE) {
/* traced a trapping instruction */
} else
bad_super_trap(fp);
@@ -206,7 +209,7 @@ asmlinkage void trap_c(struct frame *fp)
}
/* send the appropriate signal to the user program */
- switch ((fp->ptregs.vector) >> 2) {
+ switch (vector) {
case VEC_ADDRERR:
info.si_code = BUS_ADRALN;
sig = SIGBUS;
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
