From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
To: Paul Mackerras <paulus@cs.anu.edu.au>, brad@pht.com
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: 601 vs head.S
Date: Sun, 21 Feb 1999 22:13:53 +0100 [thread overview]
Message-ID: <99022122261100.00321@ns1102.munich.netsurf.de> (raw)
In-Reply-To: 199902211059.VAA01518@tango.anu.edu.au
[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]
Am Sun, 21 Feb 1999 schrieb Paul Mackerras:
>Brad Midgley <brad@pht.com> wrote:
>
>> my quest is for a kernel that boots both on the 7200 and the imac. help me
>
>Found it... had to take out the 2 nop's in hash_page this time. Vger
>(cvs) and samba (rsync) have the fix, if you want a precompiled
>kernel, try ftp://ftp.linuxppc.org/linuxppc/kernel/powermac/test/vmlinux.
Ugh, a workaround again. As somebody will break that again for sure, I thought
a little bit about it and came up with the appended patch. An (possible?)
explanation is included. I tried it with 0-7 nop's at the old position after
the found_slot label and it always worked. I even did remove the SYNC here and
it still worked. For this final patch I left the SYNC in, cause I don't know
what it is good for. It is against Cort's 990216 vger snapshot, tested on my
7200/75.
Franz.
--- head.S-org Wed Feb 17 06:59:32 1999
+++ head.S Sun Feb 21 22:20:49 1999
@@ -1361,13 +1361,6 @@
found_slot:
stw r6,4(r3)
SYNC
-/*
- * These nop's seem to be necessary to avoid getting a machine
- * check on the rfi on 601 processors.
- */
- nop
- nop
-
#else /* __SMP__ */
/*
* Between the tlbie above and updating the hash table entry below,
@@ -1441,7 +1434,22 @@
lwz r21,GPR21(r21)
SYNC
rfi
-
+
+/*
+ * These 8 nop's are here to avoid lockup of the 601 on the previous rfi
+ * instruction. They make sure that rfi gets a different cache sector than
+ * the following hash_page_out code and thus the rfi instruction is not
+ * prefetched by not-taken branch instructions in the hash_page code.
+ */
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+
hash_page_out:
#ifdef __SMP__
lis r2,hash_table_lock@ha
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: linux-final.head.S.patch --]
[-- Type: text/english; name="linux-final.head.S.patch", Size: 832 bytes --]
--- head.S-org Wed Feb 17 06:59:32 1999
+++ head.S Sun Feb 21 22:20:49 1999
@@ -1361,13 +1361,6 @@
found_slot:
stw r6,4(r3)
SYNC
-/*
- * These nop's seem to be necessary to avoid getting a machine
- * check on the rfi on 601 processors.
- */
- nop
- nop
-
#else /* __SMP__ */
/*
* Between the tlbie above and updating the hash table entry below,
@@ -1441,7 +1434,22 @@
lwz r21,GPR21(r21)
SYNC
rfi
-
+
+/*
+ * These 8 nop's are here to avoid lockup of the 601 on the previous rfi
+ * instruction. They make sure that rfi gets a different cache sector than
+ * the following hash_page_out code and thus the rfi instruction is not
+ * prefetched by not-taken branch instructions in the hash_page code.
+ */
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+
hash_page_out:
#ifdef __SMP__
lis r2,hash_table_lock@ha
next prev parent reply other threads:[~1999-02-21 21:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-02-20 23:16 601 vs head.S Brad Midgley
1999-02-21 10:59 ` Paul Mackerras
1999-02-21 21:13 ` Franz Sirl [this message]
1999-02-21 12:51 ` Benjamin Herrenschmidt
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=99022122261100.00321@ns1102.munich.netsurf.de \
--to=franz.sirl-kernel@lauterbach.com \
--cc=brad@pht.com \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=paulus@cs.anu.edu.au \
/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.