(fwd) K6 Issues

(fwd) K6 Issues

[Joern Rennecke]

Path: cygnus.co.uk!hose.news.pipex.net!pipex!rill.news.pipex.net!pipex!join.news.pipex.net!pipex!server1.netnews.ja.net!lyra.csx.cam.ac.uk!Cabal.CESspool!bofh.vszbr.cz!nntprelay.mathworks.com!howland.erols.net!infeed1.internetmci.com!newsfeed.internetmci.com!204.238.120.130!jump.net!jumpnet.com!news
From: Donovan Ready 
Newsgroups: comp.os.linux.hardware
Subject: K6 Issues
Date: Fri, 29 Aug 1997 13:38:07 -0500
Organization: Lindsay Computer Systems
Lines: 49
Message-ID: 
NNTP-Posting-Host: 207.8.14.7
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.01GoldC-Caldera (X11; I; Linux 2.0.29 i586)
Xref: cygnus.co.uk comp.os.linux.hardware:14797

We initiated a problem report to AMD last week on the kernel compile
failures per the 'burnit' script.

AMD sent this response:

========================================================================
From: lee.little@amd.com
To: lcs@jumpnet.com
Subject: RE: AMD K6 Bug

Response for Email Questions Regarding Linux Re-compile Issue and If It
Affects Other Environments

AMD recently received reports from a limited number of users having
intermittent problems while running core re-compiles of the Linux
shareware operating system. Our systems engineering group has duplicated
the observation and determined that it is related to a previously known
erratum. Full technical details of this erratum are documented in
section 2.6.2 of the AMD-K6 MMX Enhanced Processor Revision Guide posted
on our website, www.amd.com. Due to the long list of rare conditions
necessary for this erratum to occur, the issue does not effect general
users in a DOS or Windows environment. It appears to be limited to
special cases as in the Linux kernal re-compile.

Users that feel they are being affected by this problem, should contact
AMD_s support line at (408) 749-3060 and ask for Dan Hingle or Glenn
Garcia.

========================================================================

We did so. AMD's Tech support _and_ one of our Linux customers report
that gcc and g++ use self-modifying code to optimize some functions, and
this is a definate no-no, according to the erratum. 

We have been told of a patch at 
http://www.false.com/security/linux-stack, but the site is still down as
of 13:30 CDT.

If the compile passes, however, you will have a stable kernel. The
signal 11 and stack faults will stop the compile, of course, but the
thought of 'silent' failures is much less fearsome now. In the meantime,
it remains to be seen which camp will make changes. AMD told us that the
problem _would_ be addressed in a future stepping of the K6.

-- 

Donovan Ready,
Lindsay Computer Systems
http://www.jumpnet.com/~lcs

--
J"orn Rennecke

Re: (fwd) K6 Issues

[Joern Rennecke]

> > We did so. AMD's Tech support _and_ one of our Linux customers report
> > that gcc and g++ use self-modifying code to optimize some functions, and
> > this is a definate no-no, according to the erratum. 
> 
> The only self-modifying code I am aware of is trampolines.  Do you know
> any more about this?

I could get to the web site with the patch over the weekend.  It turns out
that this is a patch to make the stack in general unexecutable, and add
some ways to make it executable egain, including an option to detect gcc's
trampolines.

I can see how this can 'fix' the bug for the first trampoline a program
executes, since there will be exception handling to make the stack executable,
which will separate the writing of the trampoline from its actual execution;
however, this is a lot mor processing than seems necessary to merely avoid
the hardware bug for this first trampoline, and for all subsequent
trampolines, the stack will already be writable, hence the bug could still
manifest itself.

IMHO a better workaround for the hardware bug for trampolines is to add
some extra (conditional) code to TRAMPOLINE_TEMPLATE in i386.h

Re: (fwd) K6 Issues

[Joern Rennecke]

> The only self-modifying code I am aware of is trampolines.  Do you know
> any more about this?

Unfortunately, no.  I couldn't access the web site with the suggested
workaround either.

The AMD web page is up, and I can read their document with xpdf.
It looks to me like self-modifying code will work as long the modification
of the code is sufficiently separated from the execution; putting a jump to
a subroutine with 8 dummy instructions (I'm not sure if nops a are good
enough, but there are lots of insn combinations without a net effect on
register state) after the actual trampoline initialization should probably
qualify.

Re: (fwd) K6 Issues

[meissner]

| > We did so. AMD's Tech support _and_ one of our Linux customers report
| > that gcc and g++ use self-modifying code to optimize some functions, and
| > this is a definate no-no, according to the erratum. 
| 
| The only self-modifying code I am aware of is trampolines.  Do you know
| any more about this?

See the discussion in the Linux Kernel mailing list.  Basically signal delivery
also uses self modifying code (and I think gdb also), in addition to
trampolines.