As Peter Wemm wrote ... > Wilko Bulte wrote: > > As Brian F. Feldman wrote ... > > > On Sun, 5 Sep 1999, Randall Hopper wrote: > > > ... > > > 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.
Which I really don't need ;-) But: i386/i386/initcpu.c standard i386/i386/k6_mem.c standard in # $FreeBSD: src/sys/i386/conf/files.i386,v 1.220.2.12 1999/08/31 01:19:12 msmith and yedi#dmesg|grep -i mt K6-family MTRR support enabled (2 registers) in yedi#uname -a FreeBSD yedi.iaf.nl 3.3-RC FreeBSD 3.3-RC #0: Mon Sep 6 19:59:25 CEST 1999 I must have missed my system went from 3.2-STABLE to 3.3_RC with the last cvsup/buildworld/installworld. The question remains whether I should comment the k6_mem.c in files.i386 Wilko (confused...) -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
