On Thu, 30 Apr 2009, Bruno Girin wrote:
> Zlotan, I just tried Kees's suggestion but it looks like the files in
> /proc don't generate any event that can be captured with inotifywait. It
> works on standard files but not on the ones we're interested in. I
Only a few sysfs attributes have poll/sele
The IBM-style ThinkPad volume control is a digital mixer to control the
volume of the **built-in** speakers and headphones. Newer Lenovo models
(past the T60 second generation) don't have it, instead, they have just
a hardware MUTE engine.
It is impossible to deactivate the hardware mixer unless
First, please read my post on bug #355300 to know about the hardware
volume control and digital volume knob details.
Let's start with a key fact: the thinkpad-acpi driver does NOT support
any sort of OSD notification events for brightness and volume right now.
All that was done for OSD was done by
Well, the problem is that you do not have three volume *keys* in your
ThinkPad, you have three volume control buttons that are tied to a
specific piece of hardware and functionality.
What IBM and the early Lenovo ThinkPads give you is the equivalent of a
volume knob for the headphone and internal
(sorry for the double post)
--
Thinkpad Z61m: volume controls control both main and hardware mixer
https://bugs.launchpad.net/bugs/355300
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubun
BTW: Windows and Linux supports the ThinkPad flawlessly as long as
Ubuntu is messing with those volume keys.
In fact, the "volume buttons drive the main mixer" is exactly how
Windows DOES NOT behave. That has already been said in this bug report,
but apparently some people didn't pay attention.
BTW: Windows and Linux supports the ThinkPad flawlessly as long as Ubuntu is
NOT messing with those volume keys.
'
In fact, the "volume buttons drive the main mixer" is exactly how Windows DOES
NOT behave. That has already been said in this bug report, but apparently some
people didn't pay atte
This is just a reminder that any OSD-related concerns are to be made on
bug #357673, please. There is information on that bug report that is not
duplicated here.
--
Thinkpad Z61m: volume controls control both main and hardware mixer
https://bugs.launchpad.net/bugs/355300
You received this bug not
Just to get one point clear and across.
The problem is not how the ThinkPad works (because you cannot change it,
and it works just like that in Windows anyway).
It is that the O.S. is failing utterly to convey information to the
users in a way that lets them gently (or not) correct their expectat
Actually, what is needed is proper OSD based on passive notifications
_FOR_ OSD (and NOT a hideous hack based on keypress notifications like
what exists right now for thinkpad brightness OSD).
Don't make a mistake of believing that there exists OSD support in the
current scenario. There is none. I
Ah, I forgot the *obvious*:
Make sure EHCI-HCD *and* UHCI-HCD are running properly, or the USB bus
won't work, and obviously the device won't be there even if it is
enabled.
--
Ericsson F3507g (0bdb:1900) - does not display in NetworkManager, tho USB ACM
devices are registered
https://bugs.laun
The thinkpad-acpi upstream maintainer here.
If the module does not show up in lsusb (run as *root*), it is blocked
by the thinkpad firmware (powered down).
It will be powered down by the firmware if *any* of the following
conditions are met:
1. Set to hidden, radio blocked or something like that
On Mon, 10 Aug 2009, Aristid Breitkreuz wrote:
> I can confirm the muting issue on my T500 running Ubuntu 9.04. Volume
> up/down and brightness up/down work as expected, though.
The T500 is an entirely different beast, and whatever afflict it has no
bearing with this bug which is related to ACPI-b
On Sun, 26 Jul 2009, Johannes Hessellund wrote:
> The brightness notofication bug is resolved upstream now. Also see bug
> #372874.
>
> http://cgit.freedesktop.org/~dkukawka/hal/commit/?id=d792a792846f9632edfdea3651a74fcd24b2ead7
It was about time. Good news.
> Brightness notifications on Think
On Sun, 28 Mar 2010, sten wrote:
> ahh, I see. So the "ThinkPad Console Audio Control" is a mixer in the
> ThinkPad firmware, and that's why it works on older ACPI Thinkpads?
Yes. And right now, it only works right on the older thinkpads. It is
*not* limited to ACPI thinkpads, it can work on mu
On Sun, 15 Nov 2009, Matt Zimmerman wrote:
> On Sun, Nov 15, 2009 at 05:13:53PM -0000, Henrique de Moraes Holschuh wrote:
> > Oh yes, I am going to change kernel code because your tool scared your
> > users senseless for a LOG_WARN message. Forget it.
>
> I don't kno
On Sun, 18 Apr 2010, Alex Chekholko wrote:
> How do we get it integrated upstream? The latest kernel source does not
> yet have this patch: http://git.kernel.org/?p=linux/kernel/git/next
> /linux-
> next.git;a=blob_plain;f=drivers/platform/x86/thinkpad_acpi.c;hb=HEAD
I will need to fix a few thin
Backports for several *upstream* kernels are available at:
http://repo.or.cz/w/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
(the git:// url is somewhere on that web page).
It is easier to work based on those than what is in -next or mainline.
The only active release/* branches are:
1. The one for
On Mon, 07 Jun 2010, Vladimir Skubriev wrote:
> Excusme, i am not understand by reading this bug wrotes: when it will be
> fixed ?
When you get a new Ubuntu kernel with the thinkpad-acpi driver which is in
2.6.35-rc, or the latest thinkpad-acpi driver backports in ibm-acpi.sf.net.
I hope some Ubu
On Mon, 07 Jun 2010, Vladimir Skubriev wrote:
> ubuntu running, but sometimes it hangs up for example 1 in two hours.
This is not related to thinkpad-acpi, so this bug will not help you.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grin
On Sat, 27 Mar 2010, Steve Langasek wrote:
> I'm happy to report that a test kernel package provided to me by Stefan
> Bader now gives the following in /dev/sndstat:
>
> Card config:
> HDA Intel at 0xee24 irq 17
> ThinkPad Console Audio Control at EC reg 0x30, fw 79HT50WW-1.07
>
> [...]
>
>
On Thu, 18 Mar 2010, Pete Graner wrote:
> On Thu, Mar 18, 2010 at 08:12:54AM +, Mark Shuttleworth wrote:
> > On 17/03/10 22:22, Steve Langasek wrote:
> > > Pinging the kernel team - is this thinkpad driver backport going to
> > > happen for 10.04?
> > >
> > > ** Changed in: linux (Ubuntu Lucid)
On Mon, 26 Oct 2009, Fabio Marzocca wrote:
> thank you for your work.
> Just to confirm on my X31 I don't have notifications for audio and backlight
> (Karmic 2.6.31-14)
Audio (alsa mixer) is not ready yet. Backlight is in 2.6.32, you can ask
the Ubuntu kernel team to backport it, but it *does*
On Sat, 10 Oct 2009, Nick Bauermeister wrote:
> Sorry, I meant "is nominated". There doesn't seem to be a lot of
> attention to the issue anymore.
Quite the opposite! Backlight has been fixed properly and will be in
2.6.32. The code to support the backlight events is also usable to report
volume
@Steve:
The kernel driver will not be changed.
--
thinkpad_acpi: WARNING: sysfs attribute hotkey_enable is deprecated and will be
removed. Hotkey reporting is always enabled
https://bugs.launchpad.net/bugs/430361
You received this bug notification because you are a member of Ubuntu
Bugs, which
Oh yes, I am going to change kernel code because your tool scared your
users senseless for a LOG_WARN message. Forget it.
LOG_WARN is of LOWER severity than KERN_ERR, which is also somewhat
common, and in no way means the kernel is unstable. At most it means a
driver encountered an error conditio
So, according to Intel, the probable cause for 0x406e3 and 0x506e3
processors to fail loading the microcode update *early* is an
incompatibility when you update from a very old microcode release in
BIOS/UEFI (BIOS has a revision older/smaller than 0x80) to the newer
microcode updates.
This informa
According to Intel, this bug has been fixed in the microcode updates
released in the 20210608 package.
HOWEVER one must go from BIOS to the newest microcode update directly,
using kernel early updates. This is how it is supposed to happen by
default in Debian (and, AFAIK, Ubuntu nowadays) so it s
The new microcode update from 20201110 has rev 0x40 for this microcode,
can you check if it improves the situation?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1900149
Title:
Microcode update caus
I have just uploaded intel-microcode 3.20180807a.2. to Debian, which
does distribute 0x206c2.
All other microcodes cited on this bug report have been properly
distributed by Debian, and presumably by Ubuntu. As far as I am
concerned, this bug is either fixed-upstream (in Debian), or more-
informa
Setting to incomplete, since the fact that spectre, ssb and l1tf
mitigations are expensive (and utterly so for some workloads) is well
documented and well known, and there is nothing we can suggest unless we
know the under-the-hood details of the affected workload.
** Changed in: intel-microcode (
@pragyan:
Confirmed by @nanook on #18 that the problem still exists on the Linux
microcode package 20180807a.
Also, by the bug report date, this issue has existed in the relevant
microcode updates for a while: it is not a recent regression.
** Summary changed:
- intel-microcode when installed o
For 0x206c2:
Refer to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907402
0x206c2 is missing *from the Debian and Ubuntu packages* on purpose, but
we could ship it if Intel explicitly tells us it is not going to
permanently disable a box that has a very old BIOS with the blacklisted
SINIT ACM
** Changed in: intel-microcode (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1795594
Title:
Microcode for 206C2 Westmere EP is missing
To manage notificatio
On Tue, 09 Oct 2018, pragyansri.pa...@intel.com wrote:
> Confirmed information from microcode team:
>
> 206F2 – Westmere-EX Rev 0x3B shows as OK for OS load. The prior one marked
> as Production was 0x39 and mark as NOT_FOR_OS.
> 206C2 – Westmere-EP Rev 0x1F and 0x1E shows as OK for OS load and
For the record:
Now that Microsoft started distributing the recent batch of Intel
microcode updates, there are reports everywhere from Windows 10 users,
that the Microcode updates do break i7-6850K over-clocking. As
expected, really.
The recommended action is to demand a firmware update from the
On Mon, 24 Sep 2018, Robert Dinse wrote:
> Not sure why that would be as expected, Intel specifically sold the
> 'K' part to have unlocked multiplier. Any firmware upgrades ought to retain
> the features people paid for.
Well, it was reported to happen on Linux, and it is the sort of issue
that i
@pragyan:
Ubuntu is shipping the same microcode updates as Debian, so I can answer
that.
The current version of intel-microcode in Debian and Ubuntu ships what
is inside Intel's 20180807a "Linux microcode" package as far as the
Intel x86-64 processors are concerned.
For the i7-6850K (sig: 0x406f
Looks like I should add:
As far as I know, Ubuntu Artful is now unsupported, so users of Ubuntu
Artful must ensure they switched to Ubuntu Bionic Beaver *or* manually
update their intel-microcode package to the one in Bionic Beaver for
them to have microcode 0xb2e.
I am not sure this will fix
On Wed, 26 Sep 2018, pragyansri.pa...@intel.com wrote:
> Do you have any reported issues with Ubuntu Bionic Beaver that ships with
> Intel's latest OS loadable microcode package 20180807a?
I am not sure. We need an overclocker with an i7-6850K to test it and
be explicit about it, since this bug
@nanook:
What we need explicit testing for is this: does the latest version of
the intel-microcode package which is present in the latest Ubuntu
(Cosmic Cuttlefish *or* up-to-date Bionic Beaver/18.04.01 LTS *or* up-
to-date Xenial LTS 16.04.01) disables overclocking on the i7-6850K ?
To test this
>From reports elsewhere in the Internet, made by Microsoft Windows users
with KB4100347 installed. Behavior in Linux might be slightly different.
* Several motherboard vendors affected (at least ASUS, EVGA);
* Motherboards based on X99 with overclocking features available through vendor
UEFI/BIOS
FWIW, since I am a completely neutral party (Debian maintainer), here
are some points that may help the Ubuntu teams make a decision:
1. Hypervisors must not (and don't) allow a guest to supply microcode
updates, they're blocked at the WRMSR handler. This is required
behavior, because it is trivi
On Thu, 22 Mar 2018, Dimitri John Ledkov wrote:
> but it may need to be more smart; e.g. check the new microcode revisions
> vs currently loaded; to see if there was an update to microcode for this
> system, actually
That would be why I did not do it in the Debian package (yet). It is
hard to mak
On Mon, 26 Mar 2018, Dimitri John Ledkov wrote:
> Something like:
>
> [[ `iucode_tool -s $(sudo iucode_tool --scan-system=2 2>&1 | sed
> 's/.*\(0x.*\)$/\1/') -l /lib/firmware/intel-ucode/ | sed -n 's/.* rev
> \(0x\),.*/\1/p'` -eq `sudo cat
> /sys/devices/system/cpu/cpu0/microcode/version` ]] |
Already in Debian unstable.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1769043
Title:
intel-microcode: update to 20180425 drop
To manage notifications about this bug go to:
https://bugs.launchpa
This is likely better done in Debian.
That said, dpkg-statoverride seems like a possible layer to extend. It
is responsible for updating the owner and permission of files installed
by packages, after all. Extending it to deal with capabilities, or for
that matter POSIX ACLs and Linux extended at
For the record: systems with firmware outdated enough to actually hit
this microcode update issue *most likely* have several other critical
security issues in their Intel platform, not just in the processor.
The outdated firmware not only blocks you from updating the processor
microcode (thus seve
For model 78 stepping 3 processors, look here:
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-
Files/issues/31
To put it bluntly: update your system firmware. If no such update is
available, pressure the system vendor into releasing one. For now,
that's the only available fix. T
/bugs/1913866
>
> Title:
> intel-microcode 20201118 bump request
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1913866/+subscriptions
>
--
Henrique de Moraes Holschuh
--
You received this bug notific
You are advised to keep the microcode for skylake D0 and R0 locked at
revision 0xd6 using a microcode revision override when backporting
3.2028.1.
That is signatures 0x406e3 and 0x506e3. Override to revision 0xd6.
Otherwise, systems with old microcode (lower than 0x80) can hang.
--
You rece
Debian will also issue such an update, but we have both "works" and
"fails" reports of 0x506e3.
We're waiting for some more data re. 0x806eX and 0x906eX, but the
situation there is far less clear.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
On Wed, 10 Jun 2020, Andrea C wrote:
> CPU family: 6
> Model: 142
> Model name: Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz
> Stepping:12
>
> microcode: sig=0x806ec, pf=0x80, revision=0xca
>
> The first sign
I see. I will keep that in mind for the future, I thought you guys were
doing late-loading triggering *only* inside the initramfs, and not
during the update...
Well, blacklisting it from late-loading is a no-brainer. I will do that
too for Debian, although Debian never late-loads automatically.
Well, now we need more testing to know if it works or not, since it is
kinda expected that some microcode updates would object *heavily* to
late-load but work just fine from the early-initramfs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
This has been reported to be fixed on very similar processors (with the
same microcode signature as yours) in the 20200609 microcode updates,
could you test them?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.n
~ Two years later... :-)
Intel does not keep their microcode guidance docs up-to-date, a new one
is issued when they deem it necessary, and they're related to a specific
issue being addressed.
The processor specification updates are still as opaque as always, and
are slowly getting even harder to
Arnaud, there were some revisions of that security update. Could you
retry with the newest? If it still hangs, please check if one of the
open bug reports matches your processor model and report there.
Otherwise, please open a new report and add your processor model to the
bug title, and in the
That's enough, it confirms that the bug is *fixed*.
Thank you
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1855784
Title:
Intel Microcode 3.20191115.1ubuntu0.16.04.2 still hangs on warm reboot
w
Fixed by upstream 20200609 release.
** Changed in: intel-microcode (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1855784
Title:
Intel Microcode 3.2
Debian bug report:
https://bugs.debian.org/962757
Facts from debian bug report:
Hang only on rev 0xd6 (20200609), works with previous revisions (including rev.
0xca). Since the bug doesn't always trigger, maybe rev 0xd6 made it easier to
trigger.
** Bug watch added: Debian Bug tracker #962757
atter, a new version of Asus
firmware) will be more compatible.
Until then, you will depend on Asus issuing bios/uefi updates (and you
have to apply them to get the fixes).
--
Henrique de Moraes Holschuh
--
You received this bug notification because you are a member of Ubuntu
Bugs, whi
Hello,
Release 20190618 is out, and has these updates.
I uploaded it to Debian unstable a few hours agoand we will issue it as
a security update as well soon.
I imagine Ubuntu will do the same.
--
Henrique de Moraes Holschuh
--
You received this bug notification because you are a member
Can you give us the with-old-microcode and with-new-microcode contents
of /proc/cpuinfo, please?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1781806
Title:
With intel-microcode 3.20180425.1, Xorg
I am afraid you need to disclose a _lot_ more information about your
workload for us to even have an idea how you'd hit such an extreme
slowdown effect...
Also, what mitigation modes have you enabled in the kernel, etc.
--
You received this bug notification because you are a member of Ubuntu
Bug
I believe this is fixed in the latest version of intel-microcode
available on every still-supported branch of Ubuntu...
Can you confirm and close the report, please?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchp
Basically, *you* need to know if:
1. your workload does a LOT of syscalls (kernel entries from userspace)
OR
2. your workload does a LOT of VMEXITs (runs on a VM) OR
3. uses Intel SGX (you're on your own in that case, go talk to Intel).
Which are directly impacted by the microcode and/or kernel
For guidance on how to set kernel parameters:
https://wiki.ubuntu.com/Kernel/KernelBootParameters
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1789719
Title:
severe performance issue after intel-mi
20180807 has license problems, and cannot be distributed at the moment.
Debian is waiting for Intel to address the matter. I assume Canonical
will do the same.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.ne
Hardware limitation. Family 0xf cannot, and will never be supported for
microcode updates.
The one complaining is the kernel, not amd64-microcode itself.
** Changed in: amd64-microcode (Ubuntu)
Status: New => Confirmed
** Changed in: amd64-microcode (Ubuntu)
Status: Confirmed =>
Marked as invalid because there isn't a "working as designed" state.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1686635
Title:
amd64-microcode family 0xf not supported
To manage notifications ab
Actually, it is not hard to bypass a boot-killer microcode update issue.
Just add the "dis_ucode_ldr" parameter to the kernel command line.
To make it trivial, add that to a "safe mode" grub menu entry...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is sub
On Tue, 29 Aug 2017, Robie Basak wrote:
> Regression report in bug 1713532. Please could someone familiar with
> these microcode updates take a look?
First, we should check for the possibility of a kernel or userspace
issue that is getting in the way of the bluetooth firmware loading when
a microc
Robert, you have a -K part, which officially "doesn't forbid"
overclocking as far as I know, and this is the only reason I have not
immediately closed this bug as invalid.
It looks like now you get to find out if that means Intel *supports*
overclocking or not on -K processors, instead of just pas
(for the record: this bug should be set to "won't fix", as in "**can't**
fix", but I don't have the required permission to set the "won't fix"
state on the bug report).
It might be fixed by Intel in a future microcode update, but unless
someone tests this and tell us about it, we won't even know a
@sdeziel:
Please confirm that the i7-7500U has issues resuming from S3 *only* when
intel-microcode 20180108 is installed.
Also, just to be sure, please attach the contents of /proc/cpuinfo both
with the microcode that breaks sleep, and with whatever earlier
microcode that works fine.
If at all p
Guys, could you please notify me (Debian upstream for intel-microcode)
of such issues in the future?
I will now have to re-upload to Debian with a high priority and
changelog, and coordinate uploads to Debian stable... and it was pure
luck that I noticed this bug.
If it is a matter of embargoed s
On Sat, 17 Aug 2013, dino99 wrote:
> Hopes that report get more attention :
> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1079605
It is a trivial backport of the changes between Debian initramfs-tools
v0.112 and v0.113. But someone from Canonical will have to do it.
--
"One
intel-microcode requires that a new initramfs is built upon install.
Like anything else that would need to add new drivers to the initramfs,
etc.
This requires special support on live media (i.e. the live media MUST
have a rewriteable /boot partition which its bootloader will use, and
must not hav
FWIW, here are some points to consider when implementing this:
1. A multi-processor system may contain processors that differ in
stepping, or for other reasons (e.g. ARM big.LITTLE). This *is* quite
common on x86 servers and workstations. So, you might have more than
one processor model to list.
(BTW: if reporting microcode revision in hexadecimal, it should be
prefixed with 0x for clarity).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1444682
Title:
Software properties gtk implies my cpu
>From your kernel log, we have this:
microcode: AMD CPU family 0xf not supported
This means your processor simply does not support microcode updates
through the operating system. This is not a bug in the amd64-microcode
package: your system is working as designed by AMD.
I will close this bug rep
There were several bugs in the AMD microcode loader, which were fixed
(AFAIK, anyway) on later kernel stable updates from kernel.org. They
could easily explain the boot failure with the low-latency kernel.
I am not sure if these fixes were incorporated on Ubuntu's 15.10 kernel
updates or not. I
Bug tagged as incomplete due to its age and the high chances that it was
fixed by a kernel update (the bug is not in the amd64-microcode package,
but rather on the kernel driver).
Please retag it confirmed after re-testing on an up-to-date Ubuntu 15.10
kernel.
--
You received this bug notificati
The flashing capslock LED is a kernel-has-crashed (aka "OOPS")
indicator. It certainly looks like a bug in the microcode loader.
For the record: It is possible to bypass the microcode loader. That
would allow you to test that it is indeed the microcode loader, or to
fix the system if you did not
1. I need the contents of:
cat /proc/cpuinfo
dmesg | grep microcode
dmesg | head -n 100
please attach the output of the above commands to this bug report.
2. Please describe in detail what you mean by "not working".
--
You received this bug notification because you are a member of Ubun
It is an empty package as designed. This is a transitional package,
microcode.ctl is no more.
Please refer to the intel-microcode package's documentation.
Thank you.
** Changed in: microcode.ctl (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a mem
Please update all still-supported Ubuntu releases to iucode-tool v1.5.2
+ CVE-2017-0357 patch, or preferably to iucode-tool v2.1.1.
Updating to iucode-tool v2.1.1 will fix:
* CVE-2017-0357 - fixed in v2.1.1
* Incorrect handling of mixed-stepping systems (one of the two processor
steppings *would
Does this bug still exist in an up-to-date kernel?
It is not an issue in intel-microcode, but rather a kernel defect. It
has to be fixed by an updated kernel (and likely it has already been
fixed)...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscri
*** This bug is a duplicate of bug 1608933 ***
https://bugs.launchpad.net/bugs/1608933
** This bug has been marked a duplicate of bug 1608933
package intel-microcode 3.20151106.1 failed to install/upgrade: subprocess
installed post-removal script returned error exit status 1
--
You recei
rnel is
not going to repeat the message for every "CPU" unless they happen to
need different microcode, which is not true for your machine.
Please check /proc/cpuinfo output: it should list the updated microcode
revision for all cores.
--
Henrique de Moraes Holschuh
--
You received th
Very likely fixed by the new upload from Debian (version 1.2.3-1 and
later).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/945305
Title:
trackballs crashed with SIGABRT in __assert_fail_base()
To m
Relevant information:
I have uploaded to Debian yesterday, and it has already been auto-
migrated to Ubuntu Artful Aardvark, the newest intel-microcode release
(base date: 20170707).
This new upstream release fixes the hyper-threading issue (as well as
several other undisclosed issues) on Skylake
Rob, are things working for you now? Can we close this bug report?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1662097
Title:
lenovo t500 kernel hangs with flashing caps lock LED after installing
Ok, I "closed" it by tagging it "invalid", since we don't know what
really happened to that kernel (so "fixed" wouldn't really be correct).
Thanks.
** Changed in: intel-microcode (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs
This is a Kabilake system, the intel-microcode does not support it as of
20161104 or 20170511 (upcoming release, to be uploaded in the next few
days).
Please ensure your BIOS/UEFI is up-to-date, latest known-to-be-available
microcode is revision 0x58, so it is not impossible that there are
availab
Public bug reported:
I have fixed a major usability bug in iucode-tool 1.5.2, which dates
back to iucode-tool 1.2.
Without this fix, mixed-stepping hardware configurations are not
supported automatically, and require manual configuration.
Mixed-stepping configurations are somewhat common on Xeon
> update-initramfs: deferring update (trigger activated)
> cp: cannot create regular file '/cdrom/casper/initrd.gz.new': No such file
> or directory
Read-only boot media is (currently?) unsupportable by anything that
needs to update the initramfs... such as intel-microcode.
I have no idea what
Looks like a duplicate...
intel-microcode cannot work on read-only live media: it needs to update
the initramfs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1637886
Title:
package intel-microcode
Well, a couple points.
1. Never attempt to update microcode from inside a VM. It is supposed
to fail in the first place (not with a crash, though). Do it on the host
/hyper-visor/dom0.
2. The processors showing an issue are too different, and running
microcode updates that have been in the field
1 - 100 of 168 matches
Mail list logo
