From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@oss.sgi.com>, Harald Koerfgen <hkoerfg@web.de>,
Keith Owens <kaos@ocs.com.au>,
linux-mips@fnet.fr, linux-mips@oss.sgi.com
Subject: Re: [patch] linux 2.4.5: Make __dbe_table available to modules
Date: Thu, 23 Aug 2001 15:23:02 +0400 [thread overview]
Message-ID: <3B84E796.EF5E5F39@niisi.msk.ru> (raw)
In-Reply-To: Pine.GSO.3.96.1010814192820.5426B-100000@delta.ds2.pg.gda.pl
"Maciej W. Rozycki" wrote:
>
> On Mon, 13 Aug 2001, Gleb O. Raiko wrote:
>
> > DBE is treated as ACK* on write. Some HW design manuals advise to use
> > this fact even.
>
> And what is the use of ACK*?
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.
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*."
>
> Note that that the state of the CPU at the moment of a write is
> completely unrelated to the action that triggered the write. Therefore
> any reporting of a write failure is hardly useful -- possibly as a kind of
> an MCE only, i.e. report the event and kill the current process or panic
> if none.
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.
Regards,
Gleb.
next prev parent reply other threads:[~2001-08-23 11:31 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-13 13:38 [patch] linux 2.4.5: Make __dbe_table available to modules Maciej W. Rozycki
2001-08-13 15:50 ` Ralf Baechle
2001-08-13 16:24 ` Maciej W. Rozycki
2001-08-13 18:11 ` Gleb O. Raiko
2001-08-14 17:34 ` Maciej W. Rozycki
2001-08-23 11:23 ` Gleb O. Raiko [this message]
2001-08-23 15:46 ` Maciej W. Rozycki
2001-08-23 20:11 ` bus error by write transaction (RE: [patch] linux 2.4.5: Make __dbe_table available to modules) Hiroo Hayashi
2001-08-23 20:11 ` Hiroo Hayashi
2001-08-24 16:18 ` Maciej W. Rozycki
2001-08-27 16:49 ` Hiroo Hayashi
2001-08-27 16:49 ` Hiroo Hayashi
2001-08-20 13:57 ` [patch] linux 2.4.5: __dbe_table iteration #2 Maciej W. Rozycki
2001-08-23 1:49 ` Keith Owens
2001-08-23 16:52 ` Maciej W. Rozycki
2001-08-23 23:11 ` Keith Owens
2001-08-24 15:44 ` Maciej W. Rozycki
2001-08-27 3:09 ` Keith Owens
2001-08-27 6:20 ` Ralf Baechle
2001-08-24 15:49 ` Keith Owens
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=3B84E796.EF5E5F39@niisi.msk.ru \
--to=raiko@niisi.msk.ru \
--cc=hkoerfg@web.de \
--cc=kaos@ocs.com.au \
--cc=linux-mips@fnet.fr \
--cc=linux-mips@oss.sgi.com \
--cc=macro@ds2.pg.gda.pl \
--cc=ralf@oss.sgi.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox