public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: "Luis R. Rodriguez" <mcgrof@gmail.com>,
	linux kernel <linux-kernel@vger.kernel.org>,
	"H. Peter Anvin" <hpa@kernel.org>,
	Ivan Seskar <Seskar@winlab.rutgers.edu>,
	jfm3 <jfm3@winlab.rutgers.edu>, Sujith <m.sujith@gmail.com>
Subject: Re: Bug on 2.6.26 - x86 VIA Nehemiah CentaurHauls processor cannot boot
Date: Tue, 22 Jul 2008 09:54:56 -0400	[thread overview]
Message-ID: <4885E6B0.3060504@zytor.com> (raw)
In-Reply-To: <20080722134601.GA21977@elte.hu>

Ingo Molnar wrote:
>>
>> We can't "printk and panic" because we never get that far in the 
>> kernel proper, for obvious reasons: the code is quite littered with 
>> these buggers.
> 
> hm. How about to default to a safe NOP all the way up to where we can 
> fix up alternatives and install a different NOP. (which we could also 
> test first via intentionally jumping on it and catching any exception 
> via a special exception handler)
> 

I don't really think that's realistic, especially if gcc starts using 
these instructions (which it really *should*.)

You can make the same argument for every non-i386 instruction (heck, 
even every non-8086 instruction), and it quickly gets unworkable.

Since it is extremely likely that the set of processors affected is now 
bounded, I think it's just a matter of identifying the relevant CPUID 
info.  As far as I know, only VIA is affected.

What is worse is that there are a number of "virtual processors" out 
there which are, in effect, separate implementations of the x86 
architecture, but don't actually identify as anything else.  Several of 
them have broken nopl implementations, but identify as processors which 
are known good in this department.  Again, nothing unique to nopl about 
this, but it's a generic problem.

	-hpa

  reply	other threads:[~2008-07-22 13:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-21 13:14 Bug on 2.6.26 - x86 VIA Nehemiah CentaurHauls processor cannot boot Luis R. Rodriguez
2008-07-21 13:23 ` H. Peter Anvin
2008-07-21 14:01   ` Luis R. Rodriguez
2008-07-21 23:24     ` H. Peter Anvin
2008-07-22  4:47       ` Luis R. Rodriguez
2008-07-22 13:10         ` H. Peter Anvin
2008-07-22 17:10         ` Jeff Garzik
2008-07-22 18:21           ` H. Peter Anvin
2008-07-22 18:33             ` Jeff Garzik
2008-07-22 18:41               ` H. Peter Anvin
2008-07-22 23:28                 ` Jeff Garzik
2008-07-23  0:31                   ` H. Peter Anvin
2008-07-22 13:14       ` Ingo Molnar
2008-07-22 13:24         ` H. Peter Anvin
2008-07-22 13:46           ` Ingo Molnar
2008-07-22 13:54             ` H. Peter Anvin [this message]
2008-07-26 18:31           ` Andi Kleen
2008-07-26 18:35             ` H. Peter Anvin
2008-07-26 18:44               ` Andi Kleen

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=4885E6B0.3060504@zytor.com \
    --to=hpa@zytor.com \
    --cc=Seskar@winlab.rutgers.edu \
    --cc=hpa@kernel.org \
    --cc=jfm3@winlab.rutgers.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.sujith@gmail.com \
    --cc=mcgrof@gmail.com \
    --cc=mingo@elte.hu \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox