From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1PexKl-0006Hp-4Y for garchives@archives.gentoo.org; Mon, 17 Jan 2011 22:13:55 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8CE4DE081B for ; Mon, 17 Jan 2011 22:13:54 +0000 (UTC) Received: from mail-ew0-f53.google.com (mail-ew0-f53.google.com [209.85.215.53]) by pigeon.gentoo.org (Postfix) with ESMTP id BB379E08F7 for ; Mon, 17 Jan 2011 21:59:28 +0000 (UTC) Received: by ewy6 with SMTP id 6so3383667ewy.40 for ; Mon, 17 Jan 2011 13:59:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Dyk9GlvzVzfDWog8at+n0pwI9NImG8KtYy2v0UeAvq4=; b=aCVkH8uvJySPmrQXgwAJzOGYwV3SghOJYj5abXO/WIdwmIUreM0p/ydQoBMPtbd2Ct VjDwZHGIxQ2hbU3mHJ407Dp082tDgBhVEOXnbOPR+5zso11Y5xgCKDMzOT2jD7Vj3i6e XnXAVRSFrl08Epqq0K0MNoRkgPIMB+WsFxeEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=OKe/ApRtzP14nQWv0U0Jt6uoLLc/upPuP3TBeJysaz0vu29XH22jpiyaUkecrbD9IA mmW5Znbtn1GBsWRnAxbHVBZjzv645acOHWL3IvD+WJOApzl3p5iTHJwXvkIDHXQqydiA Jq7bkO9JV+i0NgqRBliW71QPF25t7Kmg0bzaI= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.14.127.136 with SMTP id d8mr3868828eei.23.1295301567083; Mon, 17 Jan 2011 13:59:27 -0800 (PST) Received: by 10.14.37.141 with HTTP; Mon, 17 Jan 2011 13:59:26 -0800 (PST) Received: by 10.14.37.141 with HTTP; Mon, 17 Jan 2011 13:59:26 -0800 (PST) In-Reply-To: <4d34ab51.815bdf0a.4d62.ffffcd2e@mx.google.com> References: <20110117172148.GD5748@solfire> <20110117191904.GM5748@solfire> <4d34ab51.815bdf0a.4d62.ffffcd2e@mx.google.com> Date: Mon, 17 Jan 2011 16:59:26 -0500 Message-ID: Subject: Re: [gentoo-user] Microcode update AMD From: Jason Weisberger To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=90e6ba5bb913c88cd2049a11e5a1 X-Archives-Salt: 516f760b-699b-46ae-96a2-5ee0aafb93a7 X-Archives-Hash: 39f7027925a674e455abbb93c2d82ed5 --90e6ba5bb913c88cd2049a11e5a1 Content-Type: text/plain; charset=ISO-8859-1 The word "probably" implies that you have no idea what the statistics were on getting a perfectly good core were or why they disabled entire batches of cores based on an error from one. You are just overdriving your point. If he doesn't want to enable updation of microcode, it won't hurt anything. If it was functioning fine before, it will also be fine without an update. There is nothing wrong with keeping the version of code that is stable for you. It isn't stupid, its a good rule of thumb. If it isn't broken, don't fix it. On Jan 17, 2011 4:15 PM, "Volker Armin Hemmann" wrote: > On Monday 17 January 2011 15:13:54 Jason Weisberger wrote: >> As he said in the previous message, there are almost never changelogs for >> microcode updates. >> >> I do, however, have to disagree with *never* disabling microcode updates. >> If I recall properly, the AMD Phenom II 720 was able to be unlocked to 4 >> cores via a misconfiguration that enabled it with ACC. AMD later corrected >> this issue with a microcode update. True, some motherboards worked around >> that fix a different way, but if you had a first gen board with ACC support >> you *had* to have the old microcode for it to work. The update killed your >> free core :) > > a 'free core' that is probably broken in mysterious and hard to find but > nonetheless very dangerous ways. Thanks. > > --90e6ba5bb913c88cd2049a11e5a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

The word "probably" implies that you have no idea what the sta= tistics were on getting a perfectly good core were or why they disabled ent= ire batches of cores based on an error from one.=A0

You are just overdriving your point.=A0 If he doesn't want to enable= updation of microcode, it won't hurt anything.=A0 If it was functionin= g fine before, it will also be fine without an update.=A0 There is nothing = wrong with keeping the version of code that is stable for you.=A0 It isn= 9;t stupid, its a good rule of thumb.=A0 If it isn't broken, don't = fix it.

On Jan 17, 2011 4:15 PM, "Volker Armin Hemm= ann" <volkerarmin@goo= glemail.com> wrote:
> On Monday 17 Januar= y 2011 15:13:54 Jason Weisberger wrote:
>> As he said in the previous message, there are almost never changel= ogs for
>> microcode updates.
>>
>> I do, howev= er, have to disagree with *never* disabling microcode updates.
>> = If I recall properly, the AMD Phenom II 720 was able to be unlocked to 4 >> cores via a misconfiguration that enabled it with ACC. AMD later = corrected
>> this issue with a microcode update. True, some mothe= rboards worked around
>> that fix a different way, but if you had = a first gen board with ACC support
>> you *had* to have the old microcode for it to work. The update ki= lled your
>> free core :)
>
> a 'free core' t= hat is probably broken in mysterious and hard to find but
> nonethel= ess very dangerous ways. Thanks.
>
>
--90e6ba5bb913c88cd2049a11e5a1--