* Re: 64bit port
[not found] ` <7gei4f$qsh$1@palladium.transmeta.com>
@ 1999-05-01 9:59 ` David Miller
0 siblings, 0 replies; 2+ messages in thread
From: David Miller @ 1999-05-01 9:59 UTC (permalink / raw)
To: hpa; +Cc: linux-kernel
From: hpa@transmeta.com (H. Peter Anvin)
Date: 1 May 1999 09:39:27 GMT
I think that was only UltraSPARC I.
Not true.
All currently shipping UltraSparc's have at least one of the two
64-bit lockup bugs. On the Ultra-I the user can do it no matter where
the text section is mapped, this is why Solaris doesn't offer 64-bit
installation by default on the < 250Mhz Ultra-I's which are the chips
affected by this first bug.
All UltraSparc chips (to my knowledge) are effected by the second hw
bug, which can only be triggered if the user can execute code in the
top of low 2GB of the 64-bit address space (it involves doing a PC
relative call which over/under-flows the program counter across the
64-bit top/bottom addresses, while doing an access into the VA space
hole in the delay slot, or something like this, I don't know the exact
trigger sequence yet). This is why Solaris-7 does not allow 64-bit
userspace to map anything in these areas in 64-bit mode, which as a
side-effect makes the medium-low code model close to useless.
When Jakub and I get the 64-bit userland bootstrapped, I'll start
running crashme to learn what the exact instruction sequences are so
we have a chance at coding a more suitable workaround than what
Solaris has chosen.
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: 64bit port
[not found] <Pine.LNX.4.10.9905011108010.2314-100000@tahallah.demon.co.uk>
@ 1999-05-01 10:40 ` David Miller
0 siblings, 0 replies; 2+ messages in thread
From: David Miller @ 1999-05-01 10:40 UTC (permalink / raw)
To: alex.buell; +Cc: hpa, linux-kernel
Date: Sat, 1 May 1999 11:11:21 +0100 (GMT)
From: Alex Buell <alex.buell@tahallah.demon.co.uk>
Ie. on loading of a binary could quickly scan it for illegal
sequences and overwrite with NOPs, then execute it. Of course, this
doesn't cater for things that does J-I-T compilation & execution
though.
You roughly have described how we hope to work around it.
IRIX does something very similar to work around cpu lockup
bugs on early MIPS r4k parts.
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1999-05-01 9:56 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <E10dUur-0001vY-00@devel2.axiom.internal>
[not found] ` <7gei4f$qsh$1@palladium.transmeta.com>
1999-05-01 9:59 ` 64bit port David Miller
[not found] <Pine.LNX.4.10.9905011108010.2314-100000@tahallah.demon.co.uk>
1999-05-01 10:40 ` David Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox