linux-mips
[Top] [All Lists]

Re: [patch] linux 2.4.5: Make __dbe_table available to modules

To: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Subject: Re: [patch] linux 2.4.5: Make __dbe_table available to modules
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Thu, 23 Aug 2001 17:46:57 +0200 (MET DST)
Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com
In-reply-to: <3B84E796.EF5E5F39@niisi.msk.ru>
Organization: Technical University of Gdansk
Sender: owner-linux-mips@oss.sgi.com
On Thu, 23 Aug 2001, Gleb O. Raiko wrote:

> Acknowledge. It's used to indicate current transaction has been
> processed successfully. If you are interested in details, I would
> suggest you read a MIPS hardware manual, for example, IDT's one.

 I see if I can find a suitable onein my archive.  I have an IDT CD-ROM,
but it's quite new -- dated 1997 -- and it lacks a lot of earlier stuff.
There is an R5k hw manual there, though, I think.  Too bad they got rid of
end of line stuff -- there is only ~140MB of space consumed on the CD so
there would be much room for reference docs for older parts...

> The most intriguing feature is:
> "Write transactions terminated by BusError* do not require the assertion
> of Ack*. BusError* can be asserted at at any time the processor is
> looking for Ack* to be asserted, up to and including the cycle in which
> the memory system does signal Ack*."

 Interesting.  So bus errors on write transactions seem to be somehow
supported from the hardware's point of view.  But software can't determine
the type of a bus cycle that triggered an error.  E.g. if you expect a
load instruction to trigger a bus error in some cases and you indeed get
one, you can't tell if the error was due to this instruction or due to a
write cycle triggered by some antecedent code.  I think that's the reason
of the suggestion of not using this kind of reporting -- if you limit bus
errors to read/fetch transactions in the ISA definition, you get rid of
this ambiguity. 

> I consider external signaling of write failures may be useful for kernel
> debugging purposes. I agree it's hard (or even impossible) to achieve
> proper behaviour on write failures for user space. There is a small
> chance to kill another process, for example, write transactions may
> delay due to write buffer. So, the kernel may only print something.

 Or, more severly and importantly, a write-back cache.  We provide such
diagnostics but it's dubious for writes.  You are right, it might be
useful for debugging in some cases, though.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


<Prev in Thread] Current Thread [Next in Thread>