Please attach the contents of /proc/cpuinfo and the boot kernel logs
for:
1. System booted with intel-microcode NOT installed.
2. System booted with intel-microcode installed (intel-microcode
requires a reboot to activate, so please install intel-microcode and
reboot to get this logs).
If you're
Ok. If you manage to reproduce it, please reopen and attach the
relevant info.
** Changed in: intel-microcode (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1452
The microcode update bundle (or collection, or package) contains a
number of microcode updates. That's the date in the package version
(20150121 in this case).
The release date of the collection of microcode updates is independent
of the date of a particular microcode update.
There are hundreds
nuary 21st, 2015...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh
--
You received this bug notification b
I am working on the updated package right now, and should upload it to
Debian unstable in a few hours at most.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1509764
Title:
Machine Check Exception wi
On Mon, 09 Nov 2015, Henrique de Moraes Holschuh wrote:
> I am working on the updated package right now, and should upload it to
> Debian unstable in a few hours at most.
The upload has been accepted into non-free unstable (Debian), it will be
pushed to the public Debian mirrors at th
This bug is filled against the wrong package, "intel-microcode" is only
related to CPU microcode, not to wireless card microcode, or drivers...
I do not know to which package this bug should be reassigned.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is su
Sorry, wrong lp bug number. The correct one is lp#1480349:
https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1480349
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1540969
Title:
package conte
This is up to the Ubuntu release managers to decide, there's potential
to regress things (and sometimes this is not the fault of the microcode
update: it can expose bugs just as easily as it can cause them).
That said, one must fix lp#1480359 in the target distribution before
uploading a backport
Does this bug affect thermald 1.3 ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1480349
Title:
thermald breaks frequency scaling in Xeon® E5-2687W v3 & E5-1650 v3
To manage notifications about th
There is no "thinks". It is very rare, but it has happened and we have
the bug reports in Ubuntu Debian to prove it. Chances are it will
happen again someday.
So, some added delay before migrating microcode updates to older LTS
branches is advised. If any regressions are reported during that add
Suggestions welcome. I do mean it as in "supply the suggested text
changes", btw.
Note that:
1. Information about the contents of a specific microcode update (i.e.
"what does this fix") are UNAVAILABLE, and there is nothing that we can
do about it. The README file explains this.
1a. someti
The gzipped CPIO archive at file position 0x2c00 is valid:
$ dd if=/tmp/initrd.img-4.2.0-16-generic.bak of=/tmp/initramfs.bin.gz bs=256
skip=44
$ zcat /tmp/initramfs.bin.gz | cpio -t -i >/dev/null
176985 blocks
And the first uncompressed CPIO archive at file position 0 is also
valid:
$ cat /tmp
Ok, there are no changes between 4.1 and 4.2 (actually, between 4.1 and
4.2.8) re. either the earlycpio or the initramfs loaders.
So, the problem lies elsewhere.
That said, since I bothered to research this:
EARLY cpio loader (lib/earlycpio.c, loads the microcode data): always
skips zero DWORDs
Debian bug #776431. Ubuntu bug lp#1480349.
For overclocking-related regressions, search overclocker forums.
And Intel has done a few microcode revision downgrades over the several
years of microcode updates, so we know something was not perfect in some
of those microcode updates, but other than
(note that launchpad is linking to the wrong bug reports, go to
https://bugs.debian.org for Debian bugs).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1540969
Title:
package contents is outdated
T
o bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.n
Chris Ng,
FWIW, there is a big chance that the issue you observed is ultimately
caused by thermald depending on weakly specified behavior that is known
to be processor-model-specific, and which we now know to be also
microcode-level specific.
Please refer to bug #1480349, and remove thermald from
This bug report should NOT be closed without direct verification by the
submitter.
The new microcode update distribution DOES contain microcode with a
revision of 0x29 or later for the Xeon 1200v3. This means it *CAN* cause
the regression reported in this bug report.
And the microcode update pack
Can you also check MSR_IA32_ENERGY_PERF_BIAS (MSR 0x1b0) ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1480349
Title:
Intel Microcode Breaks frequency scaling in Xeon® E5-2687W v3 &
E5-1650 v3
I wonder if these MSRs are set to the same contents in *all* cores?
Anyway, please look at this:
http://article.gmane.org/gmane.linux.power-
management.general/70615/match=msr_ia32_energy_perf_bias
"The assumption that BIOSes never want to have this register being set to
full performance (zero)
No, I think you can just go to that directory and type Make.
You can also use wrmsr (make sure to write to *all* cores).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1480349
Title:
Intel Microcode
oh, you *do* need a kernel source tarball, or a fresh clone from git if
you want to compile the tool.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1480349
Title:
Intel Microcode Breaks frequency sc
We don't deal with GPUs or generic ACPI in thinkpad-acpi-devel, just
with the thinkpad-acpi driver.
Please do this: remove the thinkpad-acpi driver (make it so it won't
autoload, maybe renaming it). Reboot. Test.
If the problem persists, we cannot help you in the thinkpad-acpi-devel.
If the pro
Please make sure you are running the latest UEFI firmware from Lenovo.
I didn't check this, but there might be a newer one:
Your CPU microcode is outdated. Intel microcode updates fix a lot more
than just CPU microcode, they can also workaround or fix some issues
with other circuits inside the pr
[ 9.420491] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x28
[ 9.420914] microcode: CPU0 updated to revision 0x29, date = 2013-06-12
This IS the latest microcode available for signature 0x206a7, pf 0x2, at
least to the general public.
Maybe you're confusing the date of that particular microcode
Bug state set to invalid.
In the future, if you need newer microcode, please file a bug on the
intel-microcode package requesting a backport, etc.
However, please note that there is currently no newer public microcode
update for your processor (signature 0x206a7, pf 0x02) than the one you
already
I am the Debian upstream for both packages (intel-microcode and iucode-
tool), and upstream author for iucode-tool.
Thank you for the kind comments on iucode-tool :-)
As for intel-microcode, you guys are dealing with an outdated package
version. The new one in Debian addresses the Haswell microc
You will want the newer intel-microcode packages, then. This means a
resync with Debian is highly advised.
Exactly due to the issue brought to the front by the Intel Haswell
microcode update that disabled TSX, Debian has switched to enforcing
that automated microcode updates be done only through
FYI: fixed upstream (in Debian) through the mandatory use of early
microcode on all automated updates.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1370352
Title:
[Feature] Intel new CPU microcode
On Thu, 04 Dec 2014, Dimitri John Ledkov wrote:
> On 3 December 2014 at 11:30, Henrique de Moraes Holschuh
> <1388...@bugs.launchpad.net> wrote:
> > I am the Debian upstream for both packages (intel-microcode and iucode-
> > tool), and upstream author for iucode-tool.
&
On Wed, 30 Apr 2014, Steve Langasek wrote:
> Accepted intel-microcode into precise-proposed. The package will build
> now and be available at http://launchpad.net/ubuntu/+source/intel-
> microcode/0.20140122-p-1ubuntu1 in a few hours, and then in the
> -proposed repository.
Updates to the 0-series
standards-version to 3.9.5
-- Henrique de Moraes Holschuh Tue, 12 Aug 2014
08:22:07 -0300
** Affects: iucode-tool (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https
This update to iucode-tool works around a bug in all versions of the
Linux kernel that support Early Microcode Updates.
The kernel will fail to correctly align a memory buffer that is used to
update the microcode of the system processor, violating the
architectural requirements described in the In
On Mon, 18 Nov 2013, vlee wrote:
> Several of the Intel microcode files that are shipped in intel-
> microcode_1.20130906.1ubuntu2 differ from the original source.
iucode-tool is specifically engineered to not be able to modify microcode,
not even its metadata.
> $ tar -xJf intel-microcode_1.2013
here on purpose and read the
package changelog looking for hints:
intel-microcode (1.20120606.v2.2) unstable; urgency=medium
* initramfs: work around initramfs-tools bug #688794.
Use "_" in place of "+-." for the initramfs script name. This works
around a PANIC duri
On Wed, 17 Sep 2014, Felix Geyer wrote:
> Please revert the 2.20140913.1ubuntu1 upload.
>
> After loading the new microcode lots of processes die with
> [ 43.611507] traps: systemd[1] trap invalid opcode ip:7f844f84a7ab
> sp:7fff2ccf7e28 error:0 in libpthread-2.19.so[7f844f839000+18000]
> [ 4
On Wed, 17 Sep 2014, Felix Geyer wrote:
> Both "yes" and "early" work fine.
Thank you. That helps immensely!
At least now we have an easy possible workaround: blacklist a few cpuids in
the package postinst from a runtime update, or drop runtime update entirely
and always require a reboot.
> How
On Wed, 17 Sep 2014, Felix Geyer wrote:
> It looks like this is the microcode update that disables TSX where it is
> broken. The hle flag is removed from cpuinfo flags (see attached cpuinfo
> files).
I thought as much.
Also, let me guess: if you update in IUCODE_TOOL_INITRAMFS=yes, the "hle"
fla
For your information:
Thread on LKML (Linux kernel), related to this problem:
https://lkml.org/lkml/2014/9/18/218
Debian bug, requesting that glibc add a blacklist to disable use of HLE and
RTM in libpthread to protect users running outdated processor microcode:
https://bugs.debian.org/cgi-bin/b
** Bug watch added: Debian Bug tracker #762195
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1370352
Title:
[Feature] Intel new CPU microco
On Tue, 17 Jun 2014, Grant Slater wrote:
> TEST CASE:
> 1. Package update.
> 2. Package update triggers update-initramfs
> 3. ucode loads/applied as expected. (on reboot)
> 4. No locks-ups or other unexpected hardware issues after load.
>
> VERIFICATION DONE
> 1. Package update installed as expect
On Wed, 19 Dec 2012, J Cord wrote:
> I can find the amd64-microcode package is now available for ubuntu 13.04
> but does not seem to be available in or for ubuntu 12.04 is there a
> package coming to ubuntu 12.04 ? Dated December 18, 2012. The link to
> the download page appears to be a dead link
On Wed, 19 Dec 2012, J Cord wrote:
> Is it possible to use the package from ubuntu 13.04 , save it, and then
> apply that package to ubuntu 12.04.1 LTS ? ( I have tried many times to
I think so. You can always download the Ubuntu source package (or the
Debian source package, it is the same) an
Your BIOS/EFI seems to be severely broken, it looks like it did not update
the microcode on all cores, just on the first two...
If you apply a microcode update from within Linux, does it update all cores
to the same microcode?
> Motherboard and BIOS information:
>
> Motherboard : MSI model FM2
* debian/control: conflicts with microcode.ctl (<< 1.18~0)
microcode.ctl (1.18~0+nmu1) is a transitional package.
-- Henrique de Moraes Holschuh Sun, 02 Sep 2012
17:46:39 -0300
intel-microcode (1.20120606.5) unstable; urgency=low
* debian/copyright: correct statement.
* debian/contro
gelog entries for 1.17-13.2 and 1.17-13.1 (closes: #687835)
Missing changelog entries wreak havok with the BTS version tracking,
this is not simply a cosmetic fix.
-- Henrique de Moraes Holschuh Sun, 16 Sep 2012
11:01:15 -0300
microcode.ctl (1.18~0+nmu1) unstable; urgency=low
You need the new-generation intel-microcode package (versions 1.* and
above).
Please refer to LP: #1054979.
You will still get firmware-loader errors if no microcode updates for
your specific processor are available. This is how it is supposed to
work for Intel processors ATM.
--
You received
It must be run as root, and /usr/share/misc must be in a partition that
is not marked read-only.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/940568
Title:
update-intel-microcode crashed with IOErr
The module must not be removed. Microcode updates are ephemeral and
will be lost should your computer need to reset the processor for any
reason (typical ones are: new core being brought online, suspend to RAM,
suspend to disk).
If none of these situations apply to you, you can remove the module
On Sat, 29 Sep 2012, Fabrice Coutadeur wrote:
> And thanks for your interest in Ubuntu! As we are past feature freeze,
> you need to follow the FFe process, attaching the files described at
> https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_upstream_versions,
> befote the packa
extra. All AMD-based X86 boxes should install this package
* debian/control: update package description
-- Henrique de Moraes Holschuh Mon, 09 Jul 2012
21:50:35 -0300
amd64-microcode (1.20120117-1) unstable; urgency=low
* Update ABI (first component of package version) to 1, to match
Preliminary packages are in Ubuntu. RequestSync filed (LP: #1032410)
to get a version that works automatically in Ubuntu.
This bug can be closed...
** Package changed: ubuntu => amd64-microcode (Ubuntu)
** Changed in: amd64-microcode (Ubuntu)
Status: Confirmed => Fix Released
--
You r
Holschuh Sun, 29 Jul 2012
10:06:35 -0300
iucode-tool (0.8.1-1) unstable; urgency=low
* New upstream release
+ inform user with an error message if cpuid driver is missing, and
--scan-system was requested
+ manpage updates
-- Henrique de Moraes Holschuh Tue, 24 Jul 2012
11:53:05
The AMD64 microcode updates do not depend at all on any kernel 3.4
patches. Don't mix issues, please.
Anyway, I am a Debian Developer, so the Precise backport will have to be
handled by an Ubuntu developer. The package should be trivial to
backport (actually, it probably works as-is).
** Tags ad
to be selected by --scan-system on a box with unsupported
processors (e.g. non-Intel)
+ Update README: Intel has some microcode update information in
some public processor specification update documents
-- Henrique de Moraes Holschuh Sun, 26 Aug 2012
18:38:54 -0300
** Affects
the Debian maintainer.
* README.Debian: mention module-init-tools, not just kmod. This is useful
when backporting to Debian Squeeze
* debian/control: add Vcs-* fields
-- Henrique de Moraes Holschuh Fri, 14 Sep 2012
15:39:37 -0300
** Affects: amd64-microcode (Ubuntu)
Importance
On Mon, 18 Jun 2012, Christopher wrote:
> I'm having the same issue with 12.10, but not 12.04. Both are AMD, the
> former 64 bit and the latter 32 bit.
Packages are waiting to be accepted in Debian, and after some time will
reach ubuntu.
--
"One disk to rule them all, One disk to find them. On
workaround until the packaging is done and tested:
1. get the microcode from www.amd64.org, Do validate the gpg signature, do not
use the microcode if the signature is invalid!
2. unpack and install the bin files to /lib/firmware/amd-ucode
3. use /etc/modules to load the microcode module on boot
Assignee: (unassigned) => Henrique de Moraes Holschuh (hmh)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/706650
Title:
[need-packaging] AMD microcode update
To manage notifications about t
More details: the solution is composed of a common package that does the
microcode loading (and has the initramfs helpers, plus a script that
will, when the time comes, be able to set things up so that the kernel
or bootloader can load the microcode early); an intel-only package that
contains the i
No, it was not silenced... there's a bug in intel-microcode which
disables early microcode updates by default. I will upload a fixed
version to Debian shortly, which will migrate to Ubuntu in a few days.
So, intel-microcode will soon restart complaining about the lack of
prepend_earlyinitramfs()
intel-microcode requires initramfs-tools 0.113 to generate an early
initramfs for kernel 3.9 and later.
It will fall back to standard initramfs support if
prepend_earlyinitramfs() is not supported by initramfs-tools.
So, this bug should be a feature request for initramfs-tools to sync to
the late
On Thu, 17 Feb 2011, Forlong wrote:
> Unmuting via the mute button does work on my T61
Yes, it was dumbed down.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Val
On Fri, 14 Feb 2020, Steve Beattie wrote:
> The reason I ask is that every communication I've had with Intel has
> indicated that late loading is risky and should not be used. The reason
Well, it is risky, it is actively discouraged, and regular users are
NEVER expected to come anywhere close to l
The packages updated a few minutes ago to Debian unstable (which still
need a few hours to be installed into the archive, autobuilt, etc) are
based on the *REVISED* release.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.
(uploaded, not updated).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2077080
Title:
upstream release 20240813 was updated without version bump
To manage notifications about this bug go to:
https:
** Changed in: autotools-dev (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1743051
Title:
package autotools-dev 20150820.1 failed to install/upgrade: le paq
inish and ship the next iucode_tool version, which can detect "late-
loading allowed" metadata Intel introduced sometime ago, and create
/lib/firmware entries only for those.
Any thoughts on this ?
--
Henrique de Moraes Holschuh
--
You received this bug notification because you
101 - 169 of 169 matches
Mail list logo
