LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Daniel J Blueman <daniel.blueman@gmail.com>,
	Shaohua Li <shaohua.li@intel.com>,
	jamagallon@ono.com, tigran@aivazian.fsnet.co.uk,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: New format Intel microcode...
Date: Thu, 28 Jun 2007 18:23:26 -0400	[thread overview]
Message-ID: <468434DE.103@tmr.com> (raw)
In-Reply-To: <20070628152747.GA14519@one.firstfloor.org>

Andi Kleen wrote:
>> Slashdot carried an article this morning saying that an error in Intel 
>> microcode was being fixed. However, it listed only Windows related sites 
>>     
>
> That's a little misleading. Always dangerous getting your information
> from slashdot. Let's say Intel clarified some corner 
> cases in TLB flushing that have changed with Core2 and not everybody
> got that right. I wouldn't say it was a Intel bug though.
>
>   
Given that the Slashdot note was a pointer to Microsoft and echo of 
their statements of a firmware fix, and that same information is on the 
Microsoft site, I find it hard to find fault with them as a source for 
pointers and some context on why they might be useful. If Intel has 
released new microcode to address the issue, then it seems the code 
didn't function as desired, and it doesn't matter what you call it.
>> for the "fix" download. Is this the same TLB issue? And are these really 
>>     
>
> I think so.
>
>   
That was one question.
>> fixes for Windows to flush the TLB properly the way Linux does?
>>     
>
> On newer Linux 2.6 yes. On 2.4/x86-64 you would need in theory the microcode 
> update too.  (it'll probably show up at some point at the usual place 
> http://urbanmyth.org/microcode/).  Linux/i386 is always fine.
>
> But the problem is very obscure and you can likely ignore it too. If your 
> machine crashes it's very likely something else.
>   

I don't ignore anything I can fix. An ounce of prevention is worth a 
pound of cure. My systems don't currently crash, and that's the intended 
behavior.

I was mainly concerned with this being a new issue, and curious if 
Microsoft was calling an O/S bug a "microcode fix," given that the 
average Windows user doesn't know microcode from nanotech anyway. The 
non-answer from Arjan didn't answer either, and started by calling the 
report FUD, implying that Slashdot was wrong (not about this), and 
issuing so little answer and so much obfuscation that I thought he might 
be running for President. ;-)

I'd like the microcode update, some people elsewhere speculate that user 
level code could effect reliability if not security. I worry that an old 
2.4 kernel would be an issue, even in kvm, if that were the case.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979


  parent reply	other threads:[~2007-06-28 22:21 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-22 23:45 Daniel J Blueman
2007-03-23  0:43 ` Shaohua Li
2007-03-23  9:43   ` Marcel Holtmann
2007-03-23  9:03     ` Arjan van de Ven
2007-03-26  8:34       ` Marcel Holtmann
2007-03-26  8:52         ` Arjan van de Ven
2007-06-26 21:42   ` Daniel J Blueman
2007-06-26 23:29     ` Andi Kleen
2007-06-28 13:53       ` Bill Davidsen
2007-06-28 14:12         ` Arjan van de Ven
2007-06-28 15:48           ` Alex Riesen
2007-06-28 17:27           ` Chuck Ebbert
2007-06-28 17:29             ` Arjan van de Ven
2007-06-28 17:54             ` Daniel J Blueman
2007-06-28 15:27         ` Andi Kleen
2007-06-28 15:44           ` Chuck Ebbert
2007-06-28 22:55             ` Bill Davidsen
2007-06-28 22:23           ` Bill Davidsen [this message]
2007-06-28 22:30             ` Arjan van de Ven
2007-06-28 23:09             ` Andi Kleen
2007-07-02  8:56   ` Alex Riesen
2007-07-02 17:18     ` Arjan van de Ven
2007-07-02 18:22       ` Alex Riesen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=468434DE.103@tmr.com \
    --to=davidsen@tmr.com \
    --cc=andi@firstfloor.org \
    --cc=daniel.blueman@gmail.com \
    --cc=jamagallon@ono.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaohua.li@intel.com \
    --cc=tigran@aivazian.fsnet.co.uk \
    --subject='Re: New format Intel microcode...' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).