From owner-freebsd-current Fri Apr 19 13:15:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA28711 for current-outgoing; Fri, 19 Apr 1996 13:15:28 -0700 (PDT) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA28706 for ; Fri, 19 Apr 1996 13:15:24 -0700 (PDT) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0uAMaJ-0003xGC; Fri, 19 Apr 96 13:15 PDT Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id UAA00726; Fri, 19 Apr 1996 20:15:12 GMT X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Terry Lambert cc: kuku@gilberto.physik.rwth-aachen.de (Christoph P. Kukulies), freebsd-current@freefall.freebsd.org Subject: Re: gzipped executables In-reply-to: Your message of "Fri, 19 Apr 1996 12:27:10 MST." <199604191927.MAA08783@phaeton.artisoft.com> Date: Fri, 19 Apr 1996 20:15:11 +0000 Message-ID: <724.829944911@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry, come up with a patch, or stop this nonsense. there is no self-modifying code involved... Christph: No I'm sorry I don't have time. It shouldn't be that hard though, if you have cvs try to find out when it broke, that would help a lot. Poul-Henning > > Is anyone working on fixing the broken gzip executable feature in > > -current? > > It's a cache interaction. Pentium caches are written back inside > the cache queue depth, whereas pre-Pentium processors have > immutable cache queues. > > It can be fixed by incorporating 32 NOP's (until the next processor > revision, anyway), in part of the code. > > This is a kludge, but, of course, it works... of such ugly working > things are permanent warts grown. > > Alternately, it can be caused by faulty writeback/invalidate hardware > on an external L2 cache. Needless to say, I don't have any hardware > with broken L2 cache interaction, so I couldn't test even a kludge > if that's where it's falling down on you. Typically, binvd'ing > the cache line range impacted immediately following a load and > again immediately following a buffer decompression would *probably* > fix the problem. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so.