It's a i7-6500U. Sorry, typo.

Oh, that's no good. I tested with a m3-6Y30 and i3-6100T, which are Skylake as well.
Microcode has been updated from revision 0x74 to 0x84 (m3) and 0x39 to 0x8a (i3) for me.

Logs should contain something like this:

microcode: microcode updated early to revision 0x8a, date = 2016-04-06
microcode: CPU0 sig=0x506e3, pf=0x2, revision=0x8a

Booting without microcode update you should see the second line at lease. What does it look like for you?

[ 1.465137] microcode: CPU0 sig=0x406e3, pf=0x80, revision=0x49
[ 1.465150] microcode: CPU1 sig=0x406e3, pf=0x80, revision=0x49
[ 1.465169] microcode: CPU2 sig=0x406e3, pf=0x80, revision=0x49
[ 1.465189] microcode: CPU3 sig=0x406e3, pf=0x80, revision=0x49
[ 1.465240] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

Works fine on my Haswell E3-1231v3, though:

[ 0.060929] microcode: CPU3 microcode updated early to revision 0x20, date = 2016-03-16
[ 0.194344] microcode: CPU0 sig=0x306c3, pf=0x2, revision=0x20

Also tracking a similar regression in Debian.

Cross-bugtracker URL:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828819

Relevant details on the Debian side:
Processor: i7-6500U, sig. 0x406e3.
Original microcode: 0x6A.
dmidecode available in Debian's bug report.

It looks like pf=0x80 might be relevant.

It looks like microcode being loaded from FIT (secure) is *not* relevant (microcode with odd revision in arch linux report -- loaded from FIT, microcode with even revision in Debian report -- uploaded through WRMSR).

@Christian Hesse (eworm):

It would be helpful to know the "pf" of the two processors that updated fine, please...

Intel(R) Core(TM) i3-6100T CPU @ 3.20GHz:
microcode: microcode updated early to revision 0x8a, date = 2016-04-06
microcode: CPU0 sig=0x506e3, pf=0x2, revision=0x8a

Intel(R) Core(TM) m3-6Y30 CPU @ 0.90GHz:
microcode: microcode updated early to revision 0x8a, date = 2016-04-06
microcode: CPU0 sig=0x406e3, pf=0x80, revision=0x8a

Thanks. We still have too few data points, but so far:

Only sig=0x406e3, pf=0x80, rev < 0x74 seems affected by the regression.

Peter, what system do you own? Is it a "Tuxedo InfinityBook 13v2"?

I have read the bug report over at Debian and, in fact, it is. I'm not sure about the v2:

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: TUXEDO
Product Name: Skylake Platform
Version: 0.1
Family: Skylake System

Just for your reference, I'm using Lenovo ThinkPad X1 Yoga with the following data:
[ 0.125467] smpboot: CPU0: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz (family: 0x6, model: 0x4e, stepping: 0x3)
[ 0.739403] microcode: CPU0 sig=0x406e3, pf=0x80, revision=0x88

@Tatsuyuki Ishi: does your Thinkpad X1 update to microcode 0x8a without issues?

@Peter: if you are feeling adventurous, you might want to run BIOS BITS on that laptop and check what it complains about (http://www.biosbits.org)... who knows, maybe if you tell BITS to fix all hardware initialization and boot with microcode 0x8a (you will need to have the microcode.dat file from Intel "on hand" to feed BITS), it will work...

@hmh: sorry for the slow reply, I'm also suffering from this issue.

Given Tatsuyuki-san's data point, the problem is not related to a big skip on revisions, or to a minimum revision. The m3-6y30 has absolutely the same microcode signature (same sig and pf), and updated fine. None of the i7-6500U in this report managed to update, regardless of the microcode version they were running at the time of the update.

Does anyone have an i7-6500U that actually updated fine?

Given Tatsuyuki-san's data point, the problem is not related to a big skip on revisions, or to a minimum revision. The m3-6y30 has absolutely the same microcode signature (same sig and pf), and updated fine. None of the i7-6500U in this report managed to update, regardless of the microcode version they were running at the time of the update.

Does anyone have an i7-6500U that actually updated fine?

Given Tatsuyuki-san's data point, the problem is not related to a big skip on revisions, or to a minimum revision. The m3-6y30 has absolutely the same microcode signature (same sig and pf), and updated fine. None of the i7-6500U in this report managed to update, regardless of the microcode version they were running at the time of the update.

Does anyone have an i7-6500U that actually updated fine?

(From Debian bug report):
ASUS UX305CA-AS (processor M3-6Y30) fails to update (BIOS 205 - microcodes rev 0x74).
BIOS 300 is reported to work, however since that BIOS has microcode 0x8a, it simply means the microcode is already current and no update is attempted.

It becomes even more mysterious... My m3-6Y30 (inside a Lenovo Yoga 700-11) works just fine...

Yes, it only happens to sig=0x406e3, pf=0x80 so far, but it doesn't always happen and it is not related to the previous version of the microcode, so it clearly depends on something else: probably either some low-level BIOS component, or PCH firmware level. Might also depend on some system setting (SGX/TXT, TSX, GPU, or power-management related for example).

I've worked around this in Debian by removing the microcode for signature 0x406E3 from the distribution, given that the only available workaround for users hit by the issue is to update to a firmware that has microcode rev. 0x8a or newer in the first place (thus rendering the microcode update useless, anyway). This change will propagate to Ubuntu eventually.

I plan to revert this change the next time this microcode gets updated by Intel, in hope that they fixed the underlying issue.

Arch might want to do the same as I did for Debian. Either use "iucode_tool -s !0x406e3" to generate the initramfs and /lib/firmware/intel-ucode, or, alternatively, do not ship /lib/firmware/intel-ucode/06-4e-03 nor allow it to be added to the early initramfs cpio archive.

Note: the removal of this microcode is going to affect Skylake-U K-1 processors as collateral damage. The K-1 stepping is a lot less broken than the Skylake-U/Y D-1 and might not object to the microcode update, but we have no reports in Debian, Arch or Fedora from owners of such processors to know (Skylake-U K-1 processors report signature=0x406e3, pf=0x40).

Going the same way... Just uploaded intel-ucode 20160607-2 to [testing].
Anybody wants to confirm that the issue is "fixed"?
(Well, it is worked around for now... Let's wait for Intel and their next microcode release.)

Issue has indeed been "fixed".