Date: Tue, 10 Nov 2009 08:47:36 +0900 From: Jun Kuriyama <kuriyama@FreeBSD.org> To: Ed Schouten <ed@80386.nl> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Jun Kuriyama <kuriyama@FreeBSD.org> Subject: Re: svn commit: r199067 - in head/sys: amd64/amd64 i386/i386 Message-ID: <7mbpjbgt0n.wl%kuriyama@s2factory.co.jp> In-Reply-To: <20091109225244.GB64905@hoeg.nl> References: <200911090254.nA92sG1G005921@svn.freebsd.org> <20091109225244.GB64905@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
At Mon, 9 Nov 2009 23:52:44 +0100,
ed@80386.nl wrote:
> * Jun Kuriyama <kuriyama@FreeBSD.org> wrote:
> > - Add hw.clflush_disable loader tunable to avoid panic (trap 9) at
> > map_invalidate_cache_range() even if CPU is not Intel.
> > - This tunable can be set to -1 (default), 0 and 1. -1 is same as
> > current behavior, which automatically disable CLFLUSH on Intel CPUs
> > without CPUID_SS (should be occured on Xen only). You can specify 1
> > when this panic happened on non-Intel CPUs (such as AMD's). Because
> > disabling CLFLUSH may reduce performance, you can try with setting 0
> > on Intel CPUs without SS to use CLFLUSH feature.
> >
> > Reviewed by: kib
> > Reported by: karl, kuriyama
> > Related to: kern/138863
>
> Unfortunately it seems to lock up my Intel Core 2 Duo boxes.
>
> Systems affected:
>
> - Apple MacBook3,1
> - Dell SC440
Thank you for your report!
(1) On MacBook, lock up occured on real hardware? Not on hypervisor?
(2) On both system, is there no problem before this commit?
--
Jun Kuriyama <kuriyama@FreeBSD.org> // FreeBSD Project
<kuriyama@s2factory.co.jp> // S2 Factory, Inc.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7mbpjbgt0n.wl%kuriyama>