Date: Mon, 8 Feb 2010 16:56:36 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: Tom McLaughlin <tmclaugh@sdf.lonestar.org>, freebsd-stable@freebsd.org Subject: Re: Recent MFC to 7 causes crash on VMware ESXi Message-ID: <20100208145636.GK9991@deviant.kiev.zoral.com.ua> In-Reply-To: <201002080949.00877.jhb@freebsd.org> References: <4B6B89E7.8030002@sdf.lonestar.org> <201002050827.53343.jhb@freebsd.org> <4B6DE364.8030509@sdf.lonestar.org> <201002080949.00877.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--9a9Vq1BJdYBEXpLG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Feb 08, 2010 at 09:49:00AM -0500, John Baldwin wrote:
> On Saturday 06 February 2010 4:47:16 pm Tom McLaughlin wrote:
> > John Baldwin wrote, On 02/05/2010 08:27 AM:
> > > On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote:
> > >> Hi all, a recent MFC to 7-STABLE has started to cause issues for my =
VMs
> > >> on VMware ESXi 3.5u4. After loading the mpt driver for the LSI disk
> > >> controller the VM just shuts off. The workaround is to change the d=
isk
> > >> controller to the BusLogic type. Still, it used to work up until la=
st
> > >> week. The change was made around January 26th and based on the comm=
its
> > >> that day I'm guessing it's either r203047 or r203073
> > >>
> > >> I have the same issue with both amd64 and i386 VMs. This affects HE=
AD
> > >> and 8-STABLE as well and first affected HEAD over the summer. (I ju=
st
> > >> worked around it and went about my business at the time. :-/) I've
> > >> attached a dmesg from a kernel before the problem and one from after=
it
> > >> started.
> > >=20
> > > What if you set 'hw.clfush_disable=3D1' from the loader?
> > >=20
> >=20
> > Yes, that corrected it on all my VMs. I've talked to people on ESXi 4
> > and they do not see the problem. I have yet to try 3.5u5 to see if this
> > is a non-issue. 3.5 will be supported for awhile longer from VMware.
> > I'm going to try upgrading the box during the week.
>=20
> I believe folks had to do this on HEAD/8.x as well. Perhaps we can=20
> automatically disable clflush if we are executing under VMware or Xen:
>=20
> Index: amd64/amd64/initcpu.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- amd64/amd64/initcpu.c (revision 203430)
> +++ amd64/amd64/initcpu.c (working copy)
> @@ -177,17 +177,16 @@
> if ((cpu_feature & CPUID_CLFSH) !=3D 0)
> cpu_clflush_line_size =3D ((cpu_procinfo >> 8) & 0xff) * 8;
> /*
> - * XXXKIB: (temporary) hack to work around traps generated when
> - * CLFLUSHing APIC registers window.
> + * XXXKIB: (temporary) hack to work around traps generated
> + * when CLFLUSHing APIC registers window under virtualization
> + * environments.
> */
> TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable);
> - if (cpu_vendor_id =3D=3D CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) =
&&
> - hw_clflush_disable =3D=3D -1)
> + if (vm_guest !=3D 0 /* VM_GUEST_NO */ && hw_clflush_disable =3D=3D -1)
> cpu_feature &=3D ~CPUID_CLFSH;
> /*
> * Allow to disable CLFLUSH feature manually by
> - * hw.clflush_disable tunable. This may help Xen guest on some AMD
> - * CPUs.
> + * hw.clflush_disable tunable.
> */
> if (hw_clflush_disable =3D=3D 1)
> cpu_feature &=3D ~CPUID_CLFSH;
> Index: i386/i386/initcpu.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- i386/i386/initcpu.c (revision 203430)
> +++ i386/i386/initcpu.c (working copy)
> @@ -724,17 +724,16 @@
> if ((cpu_feature & CPUID_CLFSH) !=3D 0)
> cpu_clflush_line_size =3D ((cpu_procinfo >> 8) & 0xff) * 8;
> /*
> - * XXXKIB: (temporary) hack to work around traps generated when
> - * CLFLUSHing APIC registers window.
> + * XXXKIB: (temporary) hack to work around traps generated
> + * when CLFLUSHing APIC registers window under virtualization
> + * environments.
> */
> TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable);
> - if (cpu_vendor_id =3D=3D CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) =
&&
> - hw_clflush_disable =3D=3D -1)
> + if (vm_guest !=3D 0 /* VM_GUEST_NO */ && hw_clflush_disable =3D=3D -1)
> cpu_feature &=3D ~CPUID_CLFSH;
> /*
> * Allow to disable CLFLUSH feature manually by
> - * hw.clflush_disable tunable. This may help Xen guest on some AMD
> - * CPUs.
> + * hw.clflush_disable tunable.
> */
> if (hw_clflush_disable =3D=3D 1)
> cpu_feature &=3D ~CPUID_CLFSH;
It might be better to "or" old condition, i.e. Intel without SS, and
new one, vm_guest !=3D 0, instead of replacing the old ?
--9a9Vq1BJdYBEXpLG
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
iEYEARECAAYFAktwJiMACgkQC3+MBN1Mb4jG2QCfS0vbigrnJVgk46/0kYhZxvPZ
618AoNtymKcvDduLyg47CkUGCeBxWx6o
=7Kcr
-----END PGP SIGNATURE-----
--9a9Vq1BJdYBEXpLG--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100208145636.GK9991>