From: Robin Gilks <robin.gilks@tait.co.nz>
To: Pantelis Antoniou <panto@intracom.gr>
Cc: ppc embedded list <linuxppc-embedded@ozlabs.org>
Subject: Re: 8xx bus monitoring
Date: Tue, 01 Feb 2005 10:49:21 +1300 [thread overview]
Message-ID: <41FEA7E1.3060204@tait.co.nz> (raw)
In-Reply-To: <41FDD9A3.9040604@intracom.gr>
Pantelis Antoniou wrote:
>>>
>>> You get a machine check exception.
>>>
>>> It's pretty obvious then :)
>>>
>>
>> Using a 2.4.22 based kernel, as far as I can see a machine check
>> should be trapped (its only allowed to cause a reset in the reboot
>> code I think). Assuming I got it right and it really is trapped, how
>> come I always get a reset:-((
>>
>> Any pointers to the code that does setup for causing an exception
>> (rather than reset) would be appreciated.
>>
>
> Check the MSR register at the time of the access.
> Is RI set? If not instead of an exception you get a reset...
I don't understand this - the whole point is that an exception occurs
asynchronously and therefore I don't know where the access it, except of
course I don't get an exception!!!
Where (insert name of source file in kernel tree) is RI set in MSR (or
should be set but is missing from the kernel I'm using) so as to ensure
that an exception occurs and how does the kernel distinguish a bus
monitor timeout from other causes.
If the kernel (or the MPC8xx) is not capable of this then I guess I'll
just have to fix the hardware :-((
--
Robin Gilks
Senior Design Engineer Phone: (+64)(3) 357 1569
Tait Electronics Fax : (+64)(3) 359 4632
PO Box 1645 Christchurch Email : robin.gilks@tait.co.nz
New Zealand
=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================
prev parent reply other threads:[~2005-01-31 21:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-26 2:31 8xx bus monitoring Robin Gilks
2005-01-26 7:06 ` Pantelis Antoniou
2005-01-30 22:15 ` Robin Gilks
2005-01-31 7:09 ` Pantelis Antoniou
2005-01-31 21:49 ` Robin Gilks [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41FEA7E1.3060204@tait.co.nz \
--to=robin.gilks@tait.co.nz \
--cc=linuxppc-embedded@ozlabs.org \
--cc=panto@intracom.gr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.