[prev in list] [next in list] [prev in thread] [next in thread] 

List:       uclinux-dev
Subject:    Re: [uClinux-dev] Exception processing in uClinux
From:       Bruce Paterson <bruce () tele-ip ! com>
Date:       2002-01-30 2:03:56
[Download RAW message or body]

> Mark Barton wrote:
> 
> For the 2.4 kernels look in kernel/panic.c
> 
> the alpha port  has an example of how to set this up.
> 
> arch/alpha/kernel/setup.c

> > Does anyone know the proper way to handle exception processing in
> > uClinux? Currently the kernel prints good debugging information to
> the

No this is not an answer, just another question :-)

My requirement:
To temporarily treat a bus error as OK for sensing whether a card is
plugged into
a VME rack or not. If no bus-error => access ok => card present.
If bus-error => no card... I need to know this but otherwise not a
problem for the system.
(it is not a page fault).
It is probably only necesary for a kernel driver to do this test, so
user mode is probably
not an issue.

On my 2.4.10 68360 system I have followed buserr from the interrupt
vector, to buserr in
arch/m68knommu/platform/68360/entry.S.  This saves state and calls
buserr_c with the stack
frame pointer as a parameter on the stack.
In arch/m68knommu/kernel/traps.c, buserr_c appears to default to
"die_if_kernel" since CPU32 is
not covered in the #define switch mess.

I can think of a number of approaches here, but what is my best way of
tackling this problem ?

1/ Add something to traps.c to cover my special case. Not sure what the
frame looks like or
whether I can determine much from it, but at worst I could use a global
flag to optionally
bypass the "die-if_kernel" and just set another global to tell my
original caller if we got
a buserr or not. I suspect this is not the nicest way !

2/ Do something within die_if_kernel. Possibly this ends up as an
exception handled by panic
and I take my specific action there, possibly by installing an exception
handler as above.
(yes I'm being very hand-waving here, but its more the frantic waving of
a drowning man rather
the airy waving of a salesman)

3/ Does some mechanism already exist and I just haven't looked in the
right place yet ?

4/ Temporarily install my own interrupt handler instead of buserr,
re-installing buserr
after the test is done.

5/ None of the above

Sorry if this question seems a bit vague. If anyone can provide me with
some more bearings 
so that I can ask a more specific question then that will help !

Cheers,
Bruce
-------------------------------------------------------------------------
This email and any files transmitted with it are confidential and
intended
solely for the use of the individual or entity to whom they are
addressed.
If you have received this email in error please notify the system
manager.

    /\\\/\\\/\\\    /   /    Bruce Paterson          VK3TJN
   /  \\\ \\\ \\\  /   /     Senior Design Engineer
  /   /\\\/\\\/\\\/   /      87 Peters Ave, Mulgrave, Vic, 3170
 /   /  \\\ \\\ \\\  /       PO Box 4112, Mulgrave, Vic, 3170, AUSTRALIA
/   /    \\\/\\\ \\\/        Ph: +61 3 8561 4232  Fax: +61 3 9560 9055
      Tele-IP Ltd.           Email: bruce@tele-ip.com    Icq: #32015991
                             WWW:   http://www.tele-ip.com
--------------------------------------------------------------------------
This message resent by the uclinux-dev@uclinux.org list server http://www.uClinux.org/
[prev in list] [next in list] [prev in thread] [next in thread]