From owner-freebsd-hackers Tue Sep 7 3:12:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 720BF14EFE; Tue, 7 Sep 1999 03:12:23 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 81C091CA8; Tue, 7 Sep 1999 18:10:14 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Wilko Bulte Cc: green@FreeBSD.ORG (Brian F. Feldman), aa8vb@ipass.net, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: K6 Write Combining & FreeBSD In-reply-to: Your message of "Mon, 06 Sep 1999 23:49:55 +0200." <199909062149.XAA03624@yedi.iaf.nl> Date: Tue, 07 Sep 1999 18:10:14 +0800 From: Peter Wemm Message-Id: <19990907101014.81C091CA8@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wilko Bulte wrote: > As Brian F. Feldman wrote ... > > On Sun, 5 Sep 1999, Randall Hopper wrote: > > > > > Mike Smith: > > > |> Also, I wonder if you've seen/heard of an MTRR patch for 3.2-RELEASE > > > | > > > |You could try to backport the two sets of commits I just made to the > > > |-stable branch, but you might be better off moving to -stable or to > > > |3.3-RELEASE. > > > > > > Ok, I might try that. From Brian's message, it sounds like he's made som e > > > commits for MTRR. Would I need those as well (or are your commits the wo rk > > > he spoke of). > > > > It may be worth specifying that k6_mem.c should be disabled in RELENG_3 pen ding > > further investigation of problems with the MTRR interfeace (i.e. that it ca n > > corrupt other memory...) For now, it's unsafe. > > Maybe I'm missing the point here, but as a AMD user I'm interested anyway: > 'should be disabled', does that mean one has to 'hand hack' to disable it? > Stable being -stable I'd have guessed it should be disabled by default > if it is not 100% working like it should. Uncomment the files.i386 line that adds k6_mem.c back to the build and it will be reactivated. The problem is that it's been implicated as causing severe kernel (malloc and zone allocator) corruption when it's actually used, eg: when firing up XFree86 3.9.16. The code is quite harmless when it's dormant though :-), but whem XFree86 4.0 gets released, it will cause RELENG_3 machines to die all over the place, which we don't need. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message