Skylake just turned into a DUD for me: No BMI ?!?

Hello,

I just saw somebody on slashdot mention this:

"
From the errata:

Executing CPUID with EAX = 7 and ECX = 0 may return EBX with bits [3] and
[8] set, incorrectly indicating the presence of BMI1 and BMI2 instruction
set extensions.

Attempting to use instructions from the BMI1 or BMI2 instruction set
extensions will result in a #UD exception.
"

http://www.intel.com/content/dam/www...pec-update.pdf

This seems very bad to me.

Without BMI Skylake would not be worth it to me ! =D

Must have BMI support.

I may have to skip Skylake or wait for steppings to fix it, but it says: NO
FIX !?

Wow... strange...

Good idea to check errate before deciding on what processor to get from now
on ! =D

Bye,
Skybuck =D

On Thu, 20 Aug 2015 04:34:06 +0200, "Skybuck Flying"
Gave us:

Hello,

I just saw somebody on slashdot mention this:

"
From the errata:

Executing CPUID with EAX = 7 and ECX = 0 may return EBX with bits [3] and
[8] set, incorrectly indicating the presence of BMI1 and BMI2 instruction
set extensions.

Attempting to use instructions from the BMI1 or BMI2 instruction set
extensions will result in a #UD exception.
"

http://www.intel.com/content/dam/www...pec-update.pdf

This seems very bad to me.

Without BMI Skylake would not be worth it to me ! =D

Must have BMI support.

I may have to skip Skylake or wait for steppings to fix it, but it says: NO
FIX !?

Wow... strange...

Good idea to check errate before deciding on what processor to get from now
on ! =D

Bye,
Skybuck =D

Would have been nice if your parents had waited for stepping instead
of failing to flush you.

on 20/08/2015, DecadentLinuxUserNumeroUno supposed :
On Thu, 20 Aug 2015 04:34:06 +0200, "Skybuck Flying"
Gave us:

Hello,

I just saw somebody on slashdot mention this:

"
From the errata:

Executing CPUID with EAX = 7 and ECX = 0 may return EBX with bits [3] and
[8] set, incorrectly indicating the presence of BMI1 and BMI2 instruction
set extensions.

Attempting to use instructions from the BMI1 or BMI2 instruction set
extensions will result in a #UD exception.
"

http://www.intel.com/content/dam/www...pec-update.pdf

This seems very bad to me.

Without BMI Skylake would not be worth it to me ! =D

Must have BMI support.

I may have to skip Skylake or wait for steppings to fix it, but it says: NO
FIX !?

Wow... strange...

Good idea to check errate before deciding on what processor to get from now
on ! =D

Bye,
Skybuck =D

Would have been nice if your parents had waited for stepping instead
of failing to flush you.

It would be nicer if you didn't repost his ****.

On 2015-08-19 22:34, Skybuck Flying wrote:

Hello,

I just saw somebody on slashdot mention this:

"
From the errata:

Executing CPUID with EAX = 7 and ECX = 0 may return EBX with bits [3]
and [8] set, incorrectly indicating the presence of BMI1 and BMI2
instruction set extensions.

Attempting to use instructions from the BMI1 or BMI2 instruction set
extensions will result in a #UD exception.
"

http://www.intel.com/content/dam/www...pec-update.pdf

This seems very bad to me.

Without BMI Skylake would not be worth it to me ! =D

Must have BMI support.

I may have to skip Skylake or wait for steppings to fix it, but it says:
NO FIX !?

Wow... strange...

Jesus, so many bugs! First time I read an Intel CPU errata, are their
CPUs all so damn buggy? I'm also waiting for the Tock...

--
! _\|/_ Sylvain /
! (o o) Member-+-David-Suzuki-Fdn/EFF/Red+Cross/Planetary-Society-+-
oO-( )-Oo Mister Worf, show these children the airlock -Picard

B00ze wrote:
On 2015-08-19 22:34, Skybuck Flying wrote:

Hello,

I just saw somebody on slashdot mention this:

"
From the errata:

Executing CPUID with EAX = 7 and ECX = 0 may return EBX with bits [3]
and [8] set, incorrectly indicating the presence of BMI1 and BMI2
instruction set extensions.

Attempting to use instructions from the BMI1 or BMI2 instruction set
extensions will result in a #UD exception.
"

http://www.intel.com/content/dam/www...pec-update.pdf


This seems very bad to me.

Without BMI Skylake would not be worth it to me ! =D

Must have BMI support.

I may have to skip Skylake or wait for steppings to fix it, but it says:
NO FIX !?

Wow... strange...

Jesus, so many bugs! First time I read an Intel CPU errata, are their
CPUs all so damn buggy? I'm also waiting for the Tock...


Yes, bugs are normal. Each processor has around
100 errata, many with workarounds and a label in
the appropriate doc that says "Won't Fix". Meaning
if later revisions of the processor are released,
the bugs stay in.

This is why processors have Microcode caches and
a Microcode loader in both the BIOS and in the OS.

Some bugs remain unpatched, but are classed
as "non-critical". For example, there was an
AMD processor with an FPU "noise floor" issue.
If you emitted enough back to back FPU instructions,
it would cause a corruption of some part of the
CPU. But the justification was, that modern
compilers did not produce sequences of the
required length. A person could, using assembler
code, craft an executable to tickle the bug, but
to what effect ? Why would you do that ? So that
one remains unfixed and unpatched. Until the next
processor design, where you'll have fresh new bugs.

And how this works, is the "test program" for
a processor, can last well past the launch date
of the part. So if a processor is released
for sale Jan 2015, some staff at the processor
company might finish their last test case Jan 2016
or Jan 2017. Where I worked, we did similar things,
ran the "critical" test cases first, and testing
stretched well past release. In my department,
30% of manpower went into test. Whether that
was money well spent, could be debated.

Paul

On 2015-08-20 22:19, Paul wrote:

Jesus, so many bugs! First time I read an Intel CPU errata, are their
CPUs all so damn buggy? I'm also waiting for the Tock...

Yes, bugs are normal. Each processor has around
100 errata, many with workarounds and a label in

This is my first look at CPU bugs, before yesterday I always thought
CPUs were mostly bug-free - I mean, Intel has been making CPUs
processing the same instructions for so long, you'd think that by now
they would have bullet-proof QA (on the other hand, the things are so
complex, it's probably impossible to QA a CPU thoroughly).

the appropriate doc that says "Won't Fix". Meaning
if later revisions of the processor are released,
the bugs stay in.

Hopefully the worst ones are fixed by the next processor, e.g. Kaby Lake
in this case.

This is why processors have Microcode caches and
a Microcode loader in both the BIOS and in the OS.

Ah yes, the Microcode, I wondered what it was for. How efficient is it
compared to hard-coded code? Also, Windows 7 has no idea about SkyLake.
I've seen only one update on Win7 that mentioned Microcode, and with MS
pushing W10, I would be surprised if they supported Skylake fixes from
the O/S on W7. Motherboard manufacturers on the other hand, will...

Some bugs remain unpatched, but are classed
as "non-critical". For example, there was an
AMD processor with an FPU "noise floor" issue.
If you emitted enough back to back FPU instructions,
it would cause a corruption of some part of the
CPU. But the justification was, that modern
compilers did not produce sequences of the
required length. A person could, using assembler
code, craft an executable to tickle the bug, but
to what effect ? Why would you do that ? So that
one remains unfixed and unpatched. Until the next
processor design, where you'll have fresh new bugs.

The only bug I knew of was the division bug on the original Pentium CPUs
that made the news. That AMD bug sounds nasty, what if you do push
enough FPU instructions in a row? Mathy programs could be affected, or
demo writers could hit it; sounds bad not to fix something like this...

And how this works, is the "test program" for
a processor, can last well past the launch date
of the part. So if a processor is released
for sale Jan 2015, some staff at the processor
company might finish their last test case Jan 2016
or Jan 2017. Where I worked, we did similar things,
ran the "critical" test cases first, and testing
stretched well past release. In my department,
30% of manpower went into test. Whether that
was money well spent, could be debated.

QA is very important, in my eyes. I don't care to see a cost analysis,
if I buy something and it bugs on me, and the company that makes the
product marks it as "No Fix" I am very displeased...

Thanks for the info!
Best Regards,

--
! _\|/_ Sylvain /
! (o o) Member-+-David-Suzuki-Fdn/EFF/Red+Cross/Planetary-Society-+-
oO-( )-Oo "Au contraire, mon capitaine! HEEE'S BAAAACK!!!" -Q