patch disabling use of PSE on Atom CPUs with a certain erratum

Previous thread: "do_IRQ: 0.89 No irq handler for vector (irq -1)" by Dave Airlie on Thursday, October 7, 2010 - 1:55 am. (19 messages)

Next thread: [PATCH] ARM: allow, but warn, when issuing ioremap() on RAM by Felipe Contreras on Thursday, October 7, 2010 - 2:44 am. (94 messages)
From: Jan Beulich
Date: Thursday, October 7, 2010 - 2:12 am

In commit 7a0fc404ae663776e96db43879a0fa24fec1fa3a you
disable use of PSE, but I wonder how this can take any effect on
64-bit CPUs, as they use large pages during early boot already.
Those pages, when use of PSE gets disabled, will get broken up
into 4k pages in phys_pmd_init(), thus actually increasing the
chances that you hit the erratum.

What am I missing?

Jan

--

From: H. Peter Anvin
Date: Thursday, October 7, 2010 - 6:46 am

Those Atoms don't have 64-bit support.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--

From: Jan Beulich
Date: Thursday, October 7, 2010 - 7:01 am

That's different from what I found looking around on the web.

Jan

--

From: H. Peter Anvin
Date: Thursday, October 7, 2010 - 7:08 am

Do tell...

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--

From: Jan Beulich
Date: Thursday, October 7, 2010 - 7:52 am

E.g.

http://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors

in particular the Atom 230 and Atom 330 (which to my reading match
the spec updates for the 200 and 300 series, which in turn exhibit
the erratum in question).

Jan

--

From: H. Peter Anvin
Date: Thursday, October 7, 2010 - 8:10 am

You're right... I misremembered.  The question is what to do at this
point, since we're already in trouble.  A possible failure on startup
seems better than a state in which we could get data corruption at
almost any time.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--

From: Jan Beulich
Date: Thursday, October 7, 2010 - 8:29 am

The only possible (afaict) way to address this would be to check for
the erratum in the boot code, and establish 4k page mappings from
the beginning. That's likely going to be ugly though.

The main reason I was asking was not so much to trigger a code
change, but to understand the implications (since both the comment
in the code and the changeset comment don't really hint at this
leaving a problem open for 64-bit), to some degree to understand
whether e.g. Xen would also need such a workaround (if anyone
cares to run Xen on Atoms).

Jan

--

From: H. Peter Anvin
Date: Thursday, October 7, 2010 - 8:32 am

Well, I guess we could do on 64 bits what we do on 32 bits, and always
use 4K pages for the initial bootstrap, to then be coalesced if PSE is

Well, keep in mind that the right thing really is to get the microcode
update into the CPU early... i.e. in the BIOS, or in a pinch, from the
bootloader -- but before the kernel runs.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--

From: Yuhong Bao
Date: Monday, October 18, 2010 - 4:23 pm

So which vendors have released BIOS updates?
Good thing 64-bit was limited to the desktop Atoms in this generation.

Yuhong Bao
 		 	   		  --

Previous thread: "do_IRQ: 0.89 No irq handler for vector (irq -1)" by Dave Airlie on Thursday, October 7, 2010 - 1:55 am. (19 messages)

Next thread: [PATCH] ARM: allow, but warn, when issuing ioremap() on RAM by Felipe Contreras on Thursday, October 7, 2010 - 2:44 am. (94 messages)