Am 28.10.2014 um 11:50 schrieb Paul Gideon Dann:
> On 27 October 2014 09:55, Christian Hesse wrote:
>
>> Damjan Georgievski on Thu, 2014/10/23 19:40:
>>> On 12 October 2014 14:28, Thomas Bächler wrote:
Intel released a new microcode update that disables an instruction on
Haswell CPUs.
El 28/10/2014 11:50, "Paul Gideon Dann" escribió:
>
> Question: how do microcode updates interact with waking the machine from
> sleep? I've added the microcode update as an initrd, and it updated fine
> when I rebooted. However, having since suspended and woken my machine, the
> kernel log shows
On 27 October 2014 09:55, Christian Hesse wrote:
> Damjan Georgievski on Thu, 2014/10/23 19:40:
> > On 12 October 2014 14:28, Thomas Bächler wrote:
> > > Intel released a new microcode update that disables an instruction on
> > > Haswell CPUs. However, Linux doesn't handle this very well and in
Damjan Georgievski on Thu, 2014/10/23 19:40:
> On 12 October 2014 14:28, Thomas Bächler wrote:
> > Intel released a new microcode update that disables an instruction on
> > Haswell CPUs. However, Linux doesn't handle this very well and in
> > combination with our glibc version, this essentially c
I got the same output as Jody
dmesg | grep microcod
[0.00] CPU0 microcode updated early to revision 0xa4, date = 2010-10-02
[0.497666] microcode: CPU0 sig=0x6fd, pf=0x80, revision=0xa4
[0.497679] microcode: CPU1 sig=0x6fd, pf=0x80, revision=0xa3
[0.497799] microcode: Microcode
Just to clarify:
No action required for AMD cpu.
AMD FX-8120
Correct?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
To remove any doubts, just take a look at /proc/cpuinfo. With 4 cores
and 8 threads, I have 8 entries in there. The "processor" is ranging
from 0 to 7 (aka threads) while "core id" (aka cores) from 0 to 3. If
you grep it, it will (kinda) give you the thread-core mapping.
% grep "processor\|core id
On Thu, Oct 23, 2014 at 6:53 PM, Neitsab wrote:
My guess is it's because of hyperthreading: my CPU has 2 physical
cores but kernel detects 4 CPUs; however only "real"/physical cores
get the microcode update, so two (0 and 2) out of the four detected.
Thanks for the info. I had a feeling it
On 2014-10-23 00:45 (UTC+2) Genes Lists wrote:
On 10/23/2014 06:34 PM, Jody Allen wrote:
...
> Is anyone only having one core updated? I get this:
> > dmesg | grep microcode
> [0.00] CPU0 microcode updated early to revision 0x29, date =
> 2013-06-12
> [0.344194] microcode: CPU0 s
On 10/23/2014 06:34 PM, Jody Allen wrote:
...
Is anyone only having one core updated? I get this:
> dmesg | grep microcode
[0.00] CPU0 microcode updated early to revision 0x29, date =
2013-06-12
[0.344194] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x29
[0.344203] microcode
On Thu, Oct 23, 2014 at 4:59 PM, Mike Cloaked
wrote:
On Thu, Oct 23, 2014 at 9:42 PM, Thomas Bächler
wrote:
Am 23.10.2014 um 21:58 schrieb Mike Cloaked:
> Oct 23 15:41:56 localhost kernel: CPU0 microcode updated early to
revision
> 0x1b, date = 2014-05-29
>
> Does this mean that the qu
For refind: This is resolved.
As per: https://bbs.archlinux.org/viewtopic.php?pid=1468931#p1468931
Summary:
There are 2 methods:
(a) Add the initrd=.. to the refind_linux.conf file.
(b) If using stanza in refind.conf then
add initrd=
Both methods work it seems. I
On Thu, Oct 23, 2014 at 9:42 PM, Thomas Bächler
wrote:
> Am 23.10.2014 um 21:58 schrieb Mike Cloaked:
> > Oct 23 15:41:56 localhost kernel: CPU0 microcode updated early to
> revision
> > 0x1b, date = 2014-05-29
> >
> > Does this mean that the quoted early update has used the wrong file from
> an
Am 23.10.2014 um 21:58 schrieb Mike Cloaked:
> Oct 23 15:41:56 localhost kernel: CPU0 microcode updated early to revision
> 0x1b, date = 2014-05-29
>
> Does this mean that the quoted early update has used the wrong file from an
> earlier date than current, or does this journal log line confirm cor
On Thu, Oct 23, 2014 at 4:55 PM, Thomas Bächler
wrote:
>
> A 2 minute Google search indicates that refind merely appends the initrd
> as a kernel command line option (initrd=) - refind, like gummiboot, is
> merely an EFI bootmanager and not a bootloader and thus relies on the
> kernel's EFIstub f
On 12 October 2014 14:28, Thomas Bächler wrote:
> Intel released a new microcode update that disables an instruction on
> Haswell CPUs. However, Linux doesn't handle this very well and in
> combination with our glibc version, this essentially crashes your system.
>
> The solution is to use the "ne
Le 23/10/2014 02:01, Marko Hauptvogel a écrit :
> Referring to the comments from october 16th on the ck kernel package
> page [0] and the config of said package [1], your version of the ck
> kernel has not yet been configured to do early microcode updates. But
> this should follow be fixed soon as
Am 21.10.2014 um 11:36 schrieb Mike Cloaked:
> On Mon, Oct 20, 2014 at 5:44 PM, Thomas Bächler
> wrote:
>
>>
>> These changes have been done precisely to avoid these problems, the
>> first link and its responses summarize the situation pretty well.
>>
>>
> The file at https://www.kernel.org/doc/D
On Thu, Oct 23, 2014 at 1:01 AM, Marko Hauptvogel <
marko.hauptvo...@googlemail.com> wrote:
> Referring to the comments from october 16th on the ck kernel package
> page [0] and the config of said package [1], your version of the ck
> kernel has not yet been configured to do early microcode update
Referring to the comments from october 16th on the ck kernel package
page [0] and the config of said package [1], your version of the ck
kernel has not yet been configured to do early microcode updates. But
this should follow be fixed soon as the v20140913 microcode package hit
[extra] today. Try t
Le 21/10/2014, Mike Cloaked a écrit:
> There are suggested
> methods to implement early microcode loading for the other main bootloaders
> in the arch wiki, but until now for refind it seems not to have been
> verified to work. It would be nice to see verification that early microcode
> loading has
On Mon, Oct 20, 2014 at 5:44 PM, Thomas Bächler
wrote:
>
> These changes have been done precisely to avoid these problems, the
> first link and its responses summarize the situation pretty well.
>
>
The file at https://www.kernel.org/doc/Documentation/x86/early-microcode.txt
gives a method that s
Am 19.10.2014 um 19:54 schrieb Mike Cloaked:
> On Sat, Oct 18, 2014 at 10:06 PM, Genes Lists wrote:
>
>>
>> For info - I have tried to get it working in refind and failed. I added a
>> second initrd line in the boot stanza in refind.conf. But the firmware was
>> not updated.
>>
>> I added to refi
On Sat, Oct 18, 2014 at 10:06 PM, Genes Lists wrote:
>
> For info - I have tried to get it working in refind and failed. I added a
> second initrd line in the boot stanza in refind.conf. But the firmware was
> not updated.
>
> I added to refind sourceforge report[1], perhaps Rod will respond.
>
>
For info - I have tried to get it working in refind and failed. I added
a second initrd line in the boot stanza in refind.conf. But the firmware
was not updated.
I added to refind sourceforge report[1], perhaps Rod will respond.
[1] https://sourceforge.net/p/refind/discussion/general/thread/
On Sun, Oct 12, 2014 at 9:16 PM, Mauro Santos
wrote:
>
> I'm replying here as (obviously) I don't have posting rights at arch-dev :)
>
> From what I've been able to understand [1-3], for grub (legacy and
> grub2) it should work by using multiple initrd lines or like this:
>
> initrd /path/to/ucod
On 12-10-2014 18:27, Thomas Bächler wrote:
> Am 12.10.2014 um 16:52 schrieb Christian Hesse:
>> Successfully tested with grub (1:2.02.beta2-4). You need something like this
>> in grub.cfg:
>>
>> echo'Loading Intel ucode update and initial ramdisk ...'
>> initrd /intel-ucode.img
27 matches
Mail list logo
