Greg, Thanks for looking over the patches. Those changes look OK.
- Jate S. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Ungerer Sent: Tuesday, May 06, 2008 11:19 PM To: uClinux development list Subject: Re: [uClinux-dev] [PATCH] bus error exception handling Hi Jate, Jate Sujjavanich wrote: > While debugging the dreaded "bad frame format", I realized that the > bus error handler for m68knommu/Coldfire could be improved. > > > > This patch adds more verbose output for a bus error on Coldfire. > > Signed-off-by: Jate Sujjavanich <[EMAIL PROTECTED]> > > > > I have not had a chance to test it, but I believe that the attached > similar patch could also be made to arch/m68knommu/kernel/traps.c for > the 2.6.x series kernel. Do you think the CONFIG_COLDFIRE's are even > needed? > > I noticed that in the 2.4 traps.c, there were a lot of ifdef's of code > for 680x0 processors. I have a feeling that these left over from m68k > during the original port. Could these be removed? I modified the 2.6.x patch a little so that it looks like: diff -Naurp /home/gerg/new-wave.2625/ORG.linux-2.6.25-rc1/arch/m68knommu/kernel/trap s.c traps.c --- /home/gerg/new-wave.2625/ORG.linux-2.6.25-rc1/arch/m68knommu/kernel/trap s.c2008-05-06 14:45:05.000000000 +1000 +++ traps.c 2008-05-07 13:14:22.000000000 +1000 @@ -86,6 +86,37 @@ void die_if_kernel(char *str, struct pt_ do_exit(SIGSEGV); } +#if defined(CONFIG_COLDFIRE) +static const char *accesserror_type[] = { + /* 0 */ "Not an access or address error nor an interrupted debug service routine", + /* 1 */ "Reserved", + /* 2 */ "Interrupt during a debug service routine for faults other than access errors", + /* 3 */ "Reserved", + /* 4 */ "Error on instruction fetch", + /* 5 */ "TLB miss on opword of instruction fetch", + /* 6 */ "TLB miss on extension word of instruction fetch", + /* 7 */ "IFP access error while executing in emulator mode", + /* 8 */ "Error on data write", + /* 9 */ "Error on attempted write to write-protected space", + /* 10 */ "TLB miss on data write", + /* 11 */ "Reserved", + /* 12 */ "Error on data read", + /* 13 */ "Attempted read, read-modify-write of protected space", + /* 14 */ "TLB miss on data read, or read-modify-write", + /* 15 */ "OEP access error while executing in emulator mode" +}; + +static void access_errorCF(struct frame *fp) { + unsigned int vector = fp->ptregs.vector; + unsigned int fs; + + fs = ((vector & 0x0c00) >> 8) | (vector & 0x0003); + printk(KERN_ERR "Access Error Exception %d: %s\n", fs, accesserror_type[fs]); + force_sig(SIGSEGV, current); +} +#endif /* CONFIG_COLDFIRE */ + asmlinkage void buserr_c(struct frame *fp) { /* Only set esp0 if coming from user mode */ @@ -96,6 +127,11 @@ asmlinkage void buserr_c(struct frame *f printk (KERN_DEBUG "*** Bus Error *** Format is %x\n", fp->ptregs.format); #endif +#if defined(CONFIG_COLDFIRE) + if (fp->ptregs.format == 4) + access_errorCF(fp); +#endif + die_if_kernel("bad frame format",&fp->ptregs,0); #if defined(DEBUG) printk(KERN_DEBUG "Unknown SIGSEGV - 4\n"); This conforms more closely to the kernel formatting guidelines. I simplified the accesserror_type() to simply report the error and let buserr_c() handle the die_if_kernel() as it did before too. Does that still look alright to you? Regards Greg ------------------------------------------------------------------------ Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing Corporation PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev ************************************************************************ ************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************ ************ _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
