From xemacs-m  Sat Aug 16 00:00:35 1997
Received: from GS213.SP.CS.CMU.EDU (GS213.SP.CS.CMU.EDU [128.2.209.183])
	by xemacs.org (8.8.5/8.8.5) with SMTP id AAA28207
	for <xemacs-beta@xemacs.org>; Sat, 16 Aug 1997 00:00:35 -0500 (CDT)
Received: by GS213.SP.CS.CMU.EDU (AIX 3.2/UCB 5.64/4.03)
          id AA13424; Sat, 16 Aug 1997 01:00:35 -0400
Date: Sat, 16 Aug 1997 01:00:35 -0400
Message-Id: <9708160500.AA13424@GS213.SP.CS.CMU.EDU>
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="UAh28M8jWr/kSPkyKvt9i+MugLTOOQWiQ4ZNEVwa"
Content-Transfer-Encoding: 7bit
From: Darrell Kindred <dkindred@cmu.edu>
To: XEmacs Beta <xemacs-beta@xemacs.org>
Cc: Kyle Jones <kyle_jones@wonderworks.com>,
        "Karl M. Hegbloom" <karlheg@inetarena.com>
Subject: Re: assertion failed, file extents.c, line 845, foundp
Organization: Carnegie Mellon University School of Computer Science
In-Reply-To: <QQdcmg23246.199708132333@crystal.WonderWorks.COM>
References: <199708131917.MAA06735@bittersweet.inetarena.com>
	<QQdcmg23246.199708132333@crystal.WonderWorks.COM>
X-Mailer: VM 6.22 under 19.15 XEmacs Lucid


--UAh28M8jWr/kSPkyKvt9i+MugLTOOQWiQ4ZNEVwa
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi folks, sorry I've been away so long.

Kyle Jones writes:
 > [...] This definitely looks like the extents code bombing.
 > I'm willing to look at it, but I'm hoping someone is more
 > familiar with that pile of code than I am.

Short version:

   Don't bother--this isn't an XEmacs bug; it's a weird
   interaction between the AMD K5 and the linux kernel.
   If you compile your kernel for "processor type" 386
   rather than 486 or Pentium, the problem should go away.
   It might be worth making an XEmacs FAQ entry for this.

Long version:

  This is a bug that both Karl and I saw during the 19.15
  betas back in March.  I spent a long time hunting it back
  then, and eventually produced a simple test case that made
  it look a whole lot like a hardware bug in the AMD K5-Pr133, 
  which both Karl and I were using.  

  The behavior I was seeing was that sometimes when the
  processor did a string-move operation (like MOVSB), the
  destination data would not actually get written until
  a *very* long time later (probably the next context
  switch).  Meanwhile, reads of the destination address
  would show its old contents.  Needless to say, much
  hilarity ensues.  Under linux, memcpy() and its friends
  are usually implemented via these x86 string-move
  operations.  In XEmacs, the glitches were most often
  noticed as failures of this extents.c "foundp" assertion.

  After some more testing, I found that the bug always
  happened when the source and destination of the
  string-move were within the same 32-byte chunk of memory
  (L1 cache line), and that chunk of memory was in a physical
  page not currently mapped into the process's address
  space.

  Karl and I were both running Linux 2.0.something.
  I tested for the bug under Windows 95 and Linux
  2.1.something and wasn't able to reproduce it, so at that
  point I got somewhat less interested in tracking it further.
  Recently I installed a new 2.0.30 kernel that didn't
  exhibit the bug, but I had tried 2.0.30 earlier without
  success, so I figured there must be some kernel config
  option screwing things up.  Last night I figured out that
  if you build the kernel for "processor type" 486 or
  Pentium (and run on a K5), you get the bug, but if you
  build for 386, the bug seems to go away.  I haven't yet
  bothered to figure out exactly what aspect of building
  for 486/Pentium triggers the failure.

  I've attached a tar file containing a test program that 
  illustrates the bug.  Karl: can you try the test program
  with your current kernel, and then again after rebuilding
  for 386?

  I think it'd be a good idea to list this problem in the
  XEmacs FAQ, using something like my "short version"
  explanation above.

- Darrell



--UAh28M8jWr/kSPkyKvt9i+MugLTOOQWiQ4ZNEVwa
Content-Type: application/octet-stream
Content-Description: amd-k5-bug.tar.gz
Content-Disposition: attachment;
	filename="amd-bug.tar.gz"
Content-Transfer-Encoding: base64

H4sIAJ8z9TMAA+0Ya2/TSLBfs79icAO12zixHSdpm6ZQ0XJCtDpEK51OFEWuvUmW+BH5URJB
//vNrp9BQHUotDrO88HZncfOzM7OzG4sz1HnPfUmmXa2fhWAqQ0GPdgC3dD6/Bdg0DfFbwYa
QL876Bldva8PAPl6Wn8Ler/MogokUWyFAFvOnPlOSJ3v8d1H/4+CVcb/wprTCXPpxnXomtY3
ze/H3xyYefy13kDH+JuGYW6BtnFLvgH/8/i/fHV+8scljECdgvqnAepfluvil4ZhEIKKmxMz
m7w9e3eOPAsauoQgwyHggYlpFBPCv+W0ITdlzqxAHK7UDAvPngG1ZwFIV2eXV/D25PLy7FRS
4MuXKvrVyetzRBOSSRWLtgPSaMovXyqAX2GuAmoAzRcVBlIMS7FZiZ0d8iVSw6bUp6EVU/Vj
4s/huMpuu9TykbVzw/xO6IE6yaklV0XpY8duE1DJ/9wxe9M67sl/w+Q5n+V/t2vy/DcNvc7/
h4Bt5ttu4lA4imKHBe3ZMVlDuezmKxyb+pa7jouZR1PMBDQCQJcxDX1gfgzj8TiKwziYD8k2
FAJW5HUQzfypau73hSj1HTaprJn4DNULkoNtyadw8ffb16eYvvGCObJCSl6pSE6sHqiUeBbz
Za7dCqd2C+wZRngXx7fvPyjkM+GHjlM9FnlWbM9oNBS4zm7GGoU2VjtRH/ZAWxrajdaCXQfL
wBrW0oaw2xGihVzKNyx0uNQfmeV0YjE3CWmEC2lDItCfZthzQeamwvEIDAU+k8aaBVYcMFmY
r39QhqSxZkhJNDiRNPgY9nChoRjboIoxaZTujrjuBgZLlmU38KcKV/cUTBihWQppcLOwZmdE
ru4bRPSsRAujOWU8xtiOx/h7G7jYO1yKE1nygtvIvfavY4k0EAAO+W77AQRJvEhivo05XjqV
cs2AqpWWdFki0FCl5LSXUktyGH4i/vGoF4QriW/RHVA3orlRkwUetXgi44HCvtYCKcEjjOeY
Ok+u/ZQf9yMLBK5iewsZVbdABBQdVbjH5f7BEWBNS6HwvCTv7YkVxQZXhJ7wjcq5M4uknI7e
EO4VSHi6R08d7vpIWz5dchvSAebHhFPcYoBnC39s/KAbrVReZEkL+PFXhA9iJBzJcWqJSmXk
nNLpGooq52Q+y6RQVc5ceqSk5zqH/Gyn7q8FIPc2SmybRtEh/LS3P+nov/AzPQ7c6vRLlyyW
i7w9xhgOCR6Xxy7cG4JK/6/c2DarA3Nl0PvB+69nlu8/QxP9f9Af1P3/IWD7SSeJQnHhFbf7
bVB3VXHR5wPSjOJgMQ78cZYA2Hd03skn+DiQmzw1EWMOIR0e4Vg76OdTbEKmQkqurPWmsgwK
ZsYF9/UDQ4yFFC8czY/I0mR7YgFMSi6HODlHtZCoilFRVaNVFFNPltr5ZZYv2PwoSrxowbzl
NZ/D8THsK2VBbjTXaleDpzzonPtr/7N17soScUdEgWhWKwQ8R+lDUSkeO773QSX/1x5Gm9TB
7//9H7z/jYGR5b8x0E3+/u8ZZrfO/4eAe/JfNG68aPHrLT8W7z/ACFvwEIjIYr3d1nviDgSk
6PMgAVxLnKfIduQbpKmWctizUA5CR5Y0SdlDhBxaviPreI/M7hR31eWuJa4SMy2bD8X0sXfu
94BK/r87Ozm9OPsFOu7Lf7OrF/nf7fH+3zXN+v+/B4GrAJOR2nORp/GMRfz/rRbmOvZOJ4Ad
z5pT4J10p01eT2AVJBBRCpa/guLtIoGL7/Ooxak7txSmQYxLUb5Sm5CrbFEu50UQ45vPtpMQ
At9d4eMXX5FJxPwpLunAycUpvOlh3gf8mYAWfWLxDCxyzvxkCXMa+tTFtZgbC3ujwKOwU3LH
qwXdgQB1c18sH7r7fbRAhVMrDKnrwps0hiDn0XxhR23bS9rUSfAJcJJMud/6wcGgLi811FBD
DTXUUEMNNdRQQw01/E7wDyZip2AAKAAA

--UAh28M8jWr/kSPkyKvt9i+MugLTOOQWiQ4ZNEVwa--

