Add valid patch size for family 16h processors
Signed-off-by: Boris Ostrovsky <[email protected]>
---
arch/x86/kernel/microcode_amd.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/x86/kernel/microcode_amd.c b/arch/x86/kernel/microcode_amd.c
index 7720ff5..58790e8 100644
--- a/arch/x86/kernel/microcode_amd.c
+++ b/arch/x86/kernel/microcode_amd.c
@@ -190,6 +190,7 @@ static unsigned int verify_patch_size(int cpu, u32 patch_size,
#define F1XH_MPB_MAX_SIZE 2048
#define F14H_MPB_MAX_SIZE 1824
#define F15H_MPB_MAX_SIZE 4096
+#define F16H_MPB_MAX_SIZE 3458
switch (c->x86) {
case 0x14:
@@ -198,6 +199,9 @@ static unsigned int verify_patch_size(int cpu, u32 patch_size,
case 0x15:
max_size = F15H_MPB_MAX_SIZE;
break;
+ case 0x16:
+ max_size = F16H_MPB_MAX_SIZE;
+ break;
default:
max_size = F1XH_MPB_MAX_SIZE;
break;
--
1.7.10.4
On Thu, Nov 15, 2012 at 01:41:50PM -0500, Boris Ostrovsky wrote:
> Add valid patch size for family 16h processors
>
> Signed-off-by: Boris Ostrovsky <[email protected]>
Acked-by: Andreas Herrmann <[email protected]>
Thanks,
Andreas
> ---
> arch/x86/kernel/microcode_amd.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/x86/kernel/microcode_amd.c b/arch/x86/kernel/microcode_amd.c
> index 7720ff5..58790e8 100644
> --- a/arch/x86/kernel/microcode_amd.c
> +++ b/arch/x86/kernel/microcode_amd.c
> @@ -190,6 +190,7 @@ static unsigned int verify_patch_size(int cpu, u32 patch_size,
> #define F1XH_MPB_MAX_SIZE 2048
> #define F14H_MPB_MAX_SIZE 1824
> #define F15H_MPB_MAX_SIZE 4096
> +#define F16H_MPB_MAX_SIZE 3458
>
> switch (c->x86) {
> case 0x14:
> @@ -198,6 +199,9 @@ static unsigned int verify_patch_size(int cpu, u32 patch_size,
> case 0x15:
> max_size = F15H_MPB_MAX_SIZE;
> break;
> + case 0x16:
> + max_size = F16H_MPB_MAX_SIZE;
> + break;
> default:
> max_size = F1XH_MPB_MAX_SIZE;
> break;
> --
> 1.7.10.4
>
>
On 11/15/2012 03:45 PM, Henrique de Moraes Holschuh wrote:
> On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
>> Add valid patch size for family 16h processors
>>
>> Signed-off-by: Boris Ostrovsky <[email protected]>
>
> Is this something that needs to go to -stable ?
>
>> #define F1XH_MPB_MAX_SIZE 2048
>> #define F14H_MPB_MAX_SIZE 1824
>> #define F15H_MPB_MAX_SIZE 4096
>> +#define F16H_MPB_MAX_SIZE 3458
>>
>> switch (c->x86) {
>> case 0x14:
>> @@ -198,6 +199,9 @@ static unsigned int verify_patch_size(int cpu, u32 patch_size,
>> case 0x15:
>> max_size = F15H_MPB_MAX_SIZE;
>> break;
>> + case 0x16:
>> + max_size = F16H_MPB_MAX_SIZE;
>> + break;
>> default:
>> max_size = F1XH_MPB_MAX_SIZE;
>> break;
>
> Because it looks like without this patch, some valid microcode updates
> would be rejected by the kernel...
Right, patch loading will fail.
I wasn't sure whether stable would be appropriate since this is support
for new HW. OTOH since this would result in loss of functionality one
could consider this a bug.
-boris
On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
> Add valid patch size for family 16h processors
>
> Signed-off-by: Boris Ostrovsky <[email protected]>
Is this something that needs to go to -stable ?
> #define F1XH_MPB_MAX_SIZE 2048
> #define F14H_MPB_MAX_SIZE 1824
> #define F15H_MPB_MAX_SIZE 4096
> +#define F16H_MPB_MAX_SIZE 3458
>
> switch (c->x86) {
> case 0x14:
> @@ -198,6 +199,9 @@ static unsigned int verify_patch_size(int cpu, u32 patch_size,
> case 0x15:
> max_size = F15H_MPB_MAX_SIZE;
> break;
> + case 0x16:
> + max_size = F16H_MPB_MAX_SIZE;
> + break;
> default:
> max_size = F1XH_MPB_MAX_SIZE;
> break;
Because it looks like without this patch, some valid microcode updates
would be rejected by the kernel...
--
"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 Holschuh
On 11/15/2012 01:26 PM, Boris Ostrovsky wrote:
>>
>> Because it looks like without this patch, some valid microcode updates
>> would be rejected by the kernel...
>
> Right, patch loading will fail.
>
> I wasn't sure whether stable would be appropriate since this is support
> for new HW. OTOH since this would result in loss of functionality one
> could consider this a bug.
>
I already promoted it and will push it into -tip as soon as it passes my
smoke tests.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
> On 11/15/2012 03:45 PM, Henrique de Moraes Holschuh wrote:
> >On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
> >>Add valid patch size for family 16h processors
> >>
> >>Signed-off-by: Boris Ostrovsky <[email protected]>
> >
> >Is this something that needs to go to -stable ?
> >
> >> #define F1XH_MPB_MAX_SIZE 2048
> >> #define F14H_MPB_MAX_SIZE 1824
> >> #define F15H_MPB_MAX_SIZE 4096
> >>+#define F16H_MPB_MAX_SIZE 3458
> >>
> >> switch (c->x86) {
> >> case 0x14:
> >>@@ -198,6 +199,9 @@ static unsigned int verify_patch_size(int cpu, u32 patch_size,
> >> case 0x15:
> >> max_size = F15H_MPB_MAX_SIZE;
> >> break;
> >>+ case 0x16:
> >>+ max_size = F16H_MPB_MAX_SIZE;
> >>+ break;
> >> default:
> >> max_size = F1XH_MPB_MAX_SIZE;
> >> break;
> >
> >Because it looks like without this patch, some valid microcode updates
> >would be rejected by the kernel...
>
> Right, patch loading will fail.
>
> I wasn't sure whether stable would be appropriate since this is
> support for new HW. OTOH since this would result in loss of
> functionality one could consider this a bug.
It is quite a good enough reason to propose a patch to -stable, yes. This
is no "theoretical" bug, it will hit users when AMD issues any microcode
updates for family 16h processors. The fact that the patch is obviously
safe and correct is also a plus, and every distro will want it anyway.
BTW, you might want to propose a forward-looking change that uses a more
conservative size for the "default" case in verify_patch_size(), one which
would be less likely to cause trouble with future families. As a separate
patch, of course.
--
"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 Holschuh
On Thu, Nov 15, 2012 at 04:26:28PM -0500, Boris Ostrovsky wrote:
>
>
> On 11/15/2012 03:45 PM, Henrique de Moraes Holschuh wrote:
> >On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
> >>Add valid patch size for family 16h processors
> >>
> >>Signed-off-by: Boris Ostrovsky <[email protected]>
> >
> >Is this something that needs to go to -stable ?
> >
> >> #define F1XH_MPB_MAX_SIZE 2048
> >> #define F14H_MPB_MAX_SIZE 1824
> >> #define F15H_MPB_MAX_SIZE 4096
> >>+#define F16H_MPB_MAX_SIZE 3458
> >>
> >> switch (c->x86) {
> >> case 0x14:
> >>@@ -198,6 +199,9 @@ static unsigned int verify_patch_size(int cpu, u32 patch_size,
> >> case 0x15:
> >> max_size = F15H_MPB_MAX_SIZE;
> >> break;
> >>+ case 0x16:
> >>+ max_size = F16H_MPB_MAX_SIZE;
> >>+ break;
> >> default:
> >> max_size = F1XH_MPB_MAX_SIZE;
> >> break;
> >
> >Because it looks like without this patch, some valid microcode updates
> >would be rejected by the kernel...
>
> Right, patch loading will fail.
>
> I wasn't sure whether stable would be appropriate since this is
> support for new HW. OTOH since this would result in loss of
> functionality one could consider this a bug.
Yes, it seems that a
Cc: <[email protected]>
(at least for 3.2, 3.4, 3.6)
can't hurt to ensure that most recent kernel releases properly handle
ucode updates for family 16h CPUs (whenever they come out).
Andreas
Commit-ID: 59e0b603b429d7fe654f5c7ea82f2ac7b427504c
Gitweb: http://git.kernel.org/tip/59e0b603b429d7fe654f5c7ea82f2ac7b427504c
Author: Boris Ostrovsky <[email protected]>
AuthorDate: Thu, 15 Nov 2012 13:41:50 -0500
Committer: H. Peter Anvin <[email protected]>
CommitDate: Thu, 15 Nov 2012 13:06:07 -0800
x86, microcode, AMD: Add support for family 16h processors
Add valid patch size for family 16h processors.
[ hpa: promoting to urgent/stable since it is hw enabling and trivial ]
Signed-off-by: Boris Ostrovsky <[email protected]>
Acked-by: Andreas Herrmann <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: H. Peter Anvin <[email protected]>
Cc: <[email protected]>
---
arch/x86/kernel/microcode_amd.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/x86/kernel/microcode_amd.c b/arch/x86/kernel/microcode_amd.c
index b3e67ba..efdec7c 100644
--- a/arch/x86/kernel/microcode_amd.c
+++ b/arch/x86/kernel/microcode_amd.c
@@ -190,6 +190,7 @@ static unsigned int verify_patch_size(int cpu, u32 patch_size,
#define F1XH_MPB_MAX_SIZE 2048
#define F14H_MPB_MAX_SIZE 1824
#define F15H_MPB_MAX_SIZE 4096
+#define F16H_MPB_MAX_SIZE 3458
switch (c->x86) {
case 0x14:
@@ -198,6 +199,9 @@ static unsigned int verify_patch_size(int cpu, u32 patch_size,
case 0x15:
max_size = F15H_MPB_MAX_SIZE;
break;
+ case 0x16:
+ max_size = F16H_MPB_MAX_SIZE;
+ break;
default:
max_size = F1XH_MPB_MAX_SIZE;
break;
On Thursday 15 November 2012, Henrique de Moraes Holschuh wrote:
>On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
>> Add valid patch size for family 16h processors
>>
>> Signed-off-by: Boris Ostrovsky <[email protected]>
>
>Is this something that needs to go to -stable ?
IMO, and if I had an oar in this water, yes. Its been missing since the
Intel folks started playing with it a couple years back up the log. I
have the amd_ucode files in my /lib/firmware tree,
root@coyote:/opt/os9# ls -l /lib/firmware/amd-ucode/
total 76
-rw-r--r-- 1 root root 642 2012-01-17 11:50 INSTALL
-rw-r--r-- 1 root root 9987 2012-01-17 11:50 LICENSE
-rw-r--r-- 1 root root 12404 2012-01-17 11:50 microcode_amd.bin
-rw-r--r-- 1 root root 1526 2012-01-17 11:50 microcode_amd.bin.README
-rw-r--r-- 1 root root 2644 2012-01-17 11:50 microcode_amd_fam15h.bin
-rw-r--r-- 1 root root 510 2012-01-17 11:50
microcode_amd_fam15h.bin.README
-rw-r--r-- 1 root root 2012 2009-01-20 04:48 microcode_amd.phenom-V83
-rw-r--r-- 1 root root 15020 2012-01-17 11:50 microcode_amd_solaris.bin
-rw-r--r-- 1 root root 1685 2012-01-17 11:50
microcode_amd_solaris.bin.README
-rw-r--r-- 1 root root 6227 2012-01-17 11:50 README
but I can't recall the last time I saw the code sign in during dmesg.
Old, slow 4 core phenom here. AMD was forgotten about when the loading
of it was moved from the kernel options to /etc/init.d/microcode. For
an AMD user, that was not a show stopper, but it wasn't a Good Thing(TM)
either.
>
>> #define F1XH_MPB_MAX_SIZE 2048
>> #define F14H_MPB_MAX_SIZE 1824
>> #define F15H_MPB_MAX_SIZE 4096
>>
>> +#define F16H_MPB_MAX_SIZE 3458
>>
>> switch (c->x86) {
>>
>> case 0x14:
>> @@ -198,6 +199,9 @@ static unsigned int verify_patch_size(int cpu, u32
>> patch_size,
>>
>> case 0x15:
>> max_size = F15H_MPB_MAX_SIZE;
>> break;
>>
>> + case 0x16:
>> + max_size = F16H_MPB_MAX_SIZE;
>> + break;
>>
>> default:
>> max_size = F1XH_MPB_MAX_SIZE;
>> break;
>
>Because it looks like without this patch, some valid microcode updates
>would be rejected by the kernel...
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
Some people's mouths work faster than their brains. They say things they
haven't even thought of yet.
On 11/15/2012 06:01 PM, Gene Heskett wrote:
> On Thursday 15 November 2012, Henrique de Moraes Holschuh wrote:
>> On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
>>> Add valid patch size for family 16h processors
>>>
>>> Signed-off-by: Boris Ostrovsky <[email protected]>
>>
>> Is this something that needs to go to -stable ?
>
> IMO, and if I had an oar in this water, yes. Its been missing since the
> Intel folks started playing with it a couple years back up the log. I
> have the amd_ucode files in my /lib/firmware tree,
>
> root@coyote:/opt/os9# ls -l /lib/firmware/amd-ucode/
> total 76
> -rw-r--r-- 1 root root 642 2012-01-17 11:50 INSTALL
> -rw-r--r-- 1 root root 9987 2012-01-17 11:50 LICENSE
> -rw-r--r-- 1 root root 12404 2012-01-17 11:50 microcode_amd.bin
> -rw-r--r-- 1 root root 1526 2012-01-17 11:50 microcode_amd.bin.README
> -rw-r--r-- 1 root root 2644 2012-01-17 11:50 microcode_amd_fam15h.bin
> -rw-r--r-- 1 root root 510 2012-01-17 11:50
> microcode_amd_fam15h.bin.README
> -rw-r--r-- 1 root root 2012 2009-01-20 04:48 microcode_amd.phenom-V83
> -rw-r--r-- 1 root root 15020 2012-01-17 11:50 microcode_amd_solaris.bin
> -rw-r--r-- 1 root root 1685 2012-01-17 11:50
> microcode_amd_solaris.bin.README
> -rw-r--r-- 1 root root 6227 2012-01-17 11:50 README
>
> but I can't recall the last time I saw the code sign in during dmesg.
> Old, slow 4 core phenom here. AMD was forgotten about when the loading
> of it was moved from the kernel options to /etc/init.d/microcode. For
> an AMD user, that was not a show stopper, but it wasn't a Good Thing(TM)
> either.
One possibility is that BIOS already incorporated all patches (which
typically is the case) and so the driver doesn't have to do anything.
-boris
>
>>
>>> #define F1XH_MPB_MAX_SIZE 2048
>>> #define F14H_MPB_MAX_SIZE 1824
>>> #define F15H_MPB_MAX_SIZE 4096
>>>
>>> +#define F16H_MPB_MAX_SIZE 3458
>>>
>>> switch (c->x86) {
>>>
>>> case 0x14:
>>> @@ -198,6 +199,9 @@ static unsigned int verify_patch_size(int cpu, u32
>>> patch_size,
>>>
>>> case 0x15:
>>> max_size = F15H_MPB_MAX_SIZE;
>>> break;
>>>
>>> + case 0x16:
>>> + max_size = F16H_MPB_MAX_SIZE;
>>> + break;
>>>
>>> default:
>>> max_size = F1XH_MPB_MAX_SIZE;
>>> break;
>>
>> Because it looks like without this patch, some valid microcode updates
>> would be rejected by the kernel...
>
>
> Cheers, Gene
>
On Thu, Nov 15, 2012 at 06:35:17PM -0500, Boris Ostrovsky wrote:
> One possibility is that BIOS already incorporated all patches (which
> typically is the case) and so the driver doesn't have to do anything.
/proc/cpuinfo contains ucode version and the processor's f/m/s, which
is enough information to tell us whether your old phenom needs ucode
patching.
Thanks.
--
Regards/Gruss,
Boris.
On Sat, 17 Nov 2012, Borislav Petkov wrote:
> On Thu, Nov 15, 2012 at 06:35:17PM -0500, Boris Ostrovsky wrote:
> > One possibility is that BIOS already incorporated all patches (which
> > typically is the case) and so the driver doesn't have to do anything.
>
> /proc/cpuinfo contains ucode version and the processor's f/m/s, which
> is enough information to tell us whether your old phenom needs ucode
> patching.
Maybe, however F/M/S information is incomplete, not to mention trying to
rebuild the proper processor signature from it is anything but
forward-proof. For Intel, it is also useless, you also need the processor
flags...
If /proc/cpuinfo is to be useful for microcode purposes, it should add a
microcode signature line, with CPUID(1).EAX, and on Intel processors, also a
second parameter with the processor flags mask (I don't know if AMD needs
something else other than CPUID(1).EAX).
--
"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 Holschuh
On Sat, Nov 17, 2012 at 01:29:19PM -0200, Henrique de Moraes Holschuh wrote:
> On Sat, 17 Nov 2012, Borislav Petkov wrote:
> > On Thu, Nov 15, 2012 at 06:35:17PM -0500, Boris Ostrovsky wrote:
> > > One possibility is that BIOS already incorporated all patches (which
> > > typically is the case) and so the driver doesn't have to do anything.
> >
> > /proc/cpuinfo contains ucode version and the processor's f/m/s, which
> > is enough information to tell us whether your old phenom needs ucode
> > patching.
>
> Maybe, however F/M/S information is incomplete, not to mention trying to
> rebuild the proper processor signature from it is anything but
> forward-proof. For Intel, it is also useless, you also need the processor
> flags...
>
> If /proc/cpuinfo is to be useful for microcode purposes, it should add a
> microcode signature line, with CPUID(1).EAX, and on Intel processors, also a
> second parameter with the processor flags mask (I don't know if AMD needs
> something else other than CPUID(1).EAX).
I was speaking only about that particular case of Gene's AMD CPU.
--
Regards/Gruss,
Boris.
On Saturday 17 November 2012, Borislav Petkov wrote:
>On Thu, Nov 15, 2012 at 06:35:17PM -0500, Boris Ostrovsky wrote:
>> One possibility is that BIOS already incorporated all patches (which
>> typically is the case) and so the driver doesn't have to do anything.
>
>/proc/cpuinfo contains ucode version and the processor's f/m/s, which
>is enough information to tell us whether your old phenom needs ucode
>patching.
>
>Thanks.
Well, in my case that returns 4 stanza's of this:
processor : 3
vendor_id : AuthenticAMD
cpu family : 16
model : 2
model name : AMD Phenom(tm) 9550 Quad-Core Processor
stepping : 3
cpu MHz : 2210.462
cache size : 512 KB
physical id : 0
siblings : 4
core id : 3
cpu cores : 4
apicid : 3
initial apicid : 3
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb
rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc extd_apicid pni monitor
cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse
3dnowprefetch osvw ibs
bogomips : 4420.70
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
And I don't see anything there that looks like a 'patch level'.
The ucode obviously can, which is what counts in this game of horseshoes.
Perhaps something in that very long 'flags' string?
Thanks Borislav.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
Biz is better.
On 11/17/2012 10:34 AM, Gene Heskett wrote:>
> And I don't see anything there that looks like a 'patch level'.
> The ucode obviously can, which is what counts in this game of horseshoes.
> Perhaps something in that very long 'flags' string?
>
What kernel version is this?
-hpa
On Thu, Nov 15, 2012 at 06:01:22PM -0500, Gene Heskett wrote:
> On Thursday 15 November 2012, Henrique de Moraes Holschuh wrote:
> >On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
> >> Add valid patch size for family 16h processors
> >>
> >> Signed-off-by: Boris Ostrovsky <[email protected]>
> >
> >Is this something that needs to go to -stable ?
>
> IMO, and if I had an oar in this water, yes. Its been missing since the
> Intel folks started playing with it a couple years back up the log. I
> have the amd_ucode files in my /lib/firmware tree,
>
> root@coyote:/opt/os9# ls -l /lib/firmware/amd-ucode/
> total 76
> -rw-r--r-- 1 root root 642 2012-01-17 11:50 INSTALL
> -rw-r--r-- 1 root root 9987 2012-01-17 11:50 LICENSE
> -rw-r--r-- 1 root root 12404 2012-01-17 11:50 microcode_amd.bin
> -rw-r--r-- 1 root root 1526 2012-01-17 11:50 microcode_amd.bin.README
> -rw-r--r-- 1 root root 2644 2012-01-17 11:50 microcode_amd_fam15h.bin
> -rw-r--r-- 1 root root 510 2012-01-17 11:50
> microcode_amd_fam15h.bin.README
> -rw-r--r-- 1 root root 2012 2009-01-20 04:48 microcode_amd.phenom-V83
> -rw-r--r-- 1 root root 15020 2012-01-17 11:50 microcode_amd_solaris.bin
> -rw-r--r-- 1 root root 1685 2012-01-17 11:50
> microcode_amd_solaris.bin.README
> -rw-r--r-- 1 root root 6227 2012-01-17 11:50 README
>
> but I can't recall the last time I saw the code sign in during dmesg.
Is the microcode module actually loaded on your system?
If yes,
is CONFIG_MICROCODE_AMD set?
If yes, please provide dmesg.
If not, please load manually (modprobe microcode) and what's your
distro?
Thanks,
Andreas
On Saturday 17 November 2012, H. Peter Anvin wrote:
>On 11/17/2012 10:34 AM, Gene Heskett wrote:>
>
>> And I don't see anything there that looks like a 'patch level'.
>> The ucode obviously can, which is what counts in this game of
>> horseshoes. Perhaps something in that very long 'flags' string?
>
>What kernel version is this?
>
> -hpa
# uname -a
Linux coyote 2.6.32-122-rtai #rtai SMP Tue Jul 27 12:44:07 CDT 2010 i686
GNU/Linux
This is a custom made rtai patched kernel used ATM by LinuxCNC (was emc),
built for driving machinery in the robot, lathe and milling machine
categories. With low latency motherboards such as the intel D525MW, it is
capable of running higher powered stepper motors at quite impressive speeds
as it can output, thru the std parport, step and dir signals every 20 to 25
microseconds.
That of course is not on this exact machine, but used in order to maintain
write it here and nfs it to the box running the lathe or milling machine
after doing "air" cuts on this machine to prove the code works. Same
ubuntu-10.04.4 LTS install on 4 boxes here.
The code carvers for LinuxCNC have working patched 3.4.xx kernels running
now, but have not yet assembled a new OS install CD release based on these
patches, with the possibly the Xenomai patchset for user threads will be
used for the Next Gen release of the install CD. That seems to be winning
the performance battle ATM.
Probably more than you wanted to know. I'm just explaining why the old
kernel version. Its all GPLed and can be pulled from links on the
wiki.linuxcnc.org site.
Thanks hpa.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
World War Three can be averted by adherence to a strictly enforced dress
code!
On Saturday 17 November 2012, Andreas Herrmann wrote:
>On Thu, Nov 15, 2012 at 06:01:22PM -0500, Gene Heskett wrote:
>> On Thursday 15 November 2012, Henrique de Moraes Holschuh wrote:
>> >On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
>> >> Add valid patch size for family 16h processors
>> >>
>> >> Signed-off-by: Boris Ostrovsky <[email protected]>
>> >
>> >Is this something that needs to go to -stable ?
>>
>> IMO, and if I had an oar in this water, yes. Its been missing since
>> the Intel folks started playing with it a couple years back up the
>> log. I have the amd_ucode files in my /lib/firmware tree,
>>
>> root@coyote:/opt/os9# ls -l /lib/firmware/amd-ucode/
>> total 76
>> -rw-r--r-- 1 root root 642 2012-01-17 11:50 INSTALL
>> -rw-r--r-- 1 root root 9987 2012-01-17 11:50 LICENSE
>> -rw-r--r-- 1 root root 12404 2012-01-17 11:50 microcode_amd.bin
>> -rw-r--r-- 1 root root 1526 2012-01-17 11:50 microcode_amd.bin.README
>> -rw-r--r-- 1 root root 2644 2012-01-17 11:50 microcode_amd_fam15h.bin
>> -rw-r--r-- 1 root root 510 2012-01-17 11:50
>> microcode_amd_fam15h.bin.README
>> -rw-r--r-- 1 root root 2012 2009-01-20 04:48 microcode_amd.phenom-V83
>> -rw-r--r-- 1 root root 15020 2012-01-17 11:50 microcode_amd_solaris.bin
>> -rw-r--r-- 1 root root 1685 2012-01-17 11:50
>> microcode_amd_solaris.bin.README
>> -rw-r--r-- 1 root root 6227 2012-01-17 11:50 README
>>
>> but I can't recall the last time I saw the code sign in during dmesg.
>
>Is the microcode module actually loaded on your system?
>If yes,
> is CONFIG_MICROCODE_AMD set?
> If yes, please provide dmesg.
No clue, I didn't build it.
>If not, please load manually (modprobe microcode) and what's your
>distro?
I did, it worked and I have now put it in rc.local for the next reboot.
root@coyote:/var/spool/mail# cat /etc/issue
Ubuntu 10.04.4 LTS \n \l
Thank you Andreas.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
He who laughs last usually had to have joke explained.
It's too old, that's the problem.
Gene Heskett <[email protected]> wrote:
>On Saturday 17 November 2012, H. Peter Anvin wrote:
>>On 11/17/2012 10:34 AM, Gene Heskett wrote:>
>>
>>> And I don't see anything there that looks like a 'patch level'.
>>> The ucode obviously can, which is what counts in this game of
>>> horseshoes. Perhaps something in that very long 'flags' string?
>>
>>What kernel version is this?
>>
>> -hpa
>
># uname -a
>Linux coyote 2.6.32-122-rtai #rtai SMP Tue Jul 27 12:44:07 CDT 2010
>i686
>GNU/Linux
>
>This is a custom made rtai patched kernel used ATM by LinuxCNC (was
>emc),
>built for driving machinery in the robot, lathe and milling machine
>categories. With low latency motherboards such as the intel D525MW, it
>is
>capable of running higher powered stepper motors at quite impressive
>speeds
>as it can output, thru the std parport, step and dir signals every 20
>to 25
>microseconds.
>
>That of course is not on this exact machine, but used in order to
>maintain
>write it here and nfs it to the box running the lathe or milling
>machine
>after doing "air" cuts on this machine to prove the code works. Same
>ubuntu-10.04.4 LTS install on 4 boxes here.
>
>The code carvers for LinuxCNC have working patched 3.4.xx kernels
>running
>now, but have not yet assembled a new OS install CD release based on
>these
>patches, with the possibly the Xenomai patchset for user threads will
>be
>used for the Next Gen release of the install CD. That seems to be
>winning
>the performance battle ATM.
>
>Probably more than you wanted to know. I'm just explaining why the old
>
>kernel version. Its all GPLed and can be pulled from links on the
>wiki.linuxcnc.org site.
>
>Thanks hpa.
>
>Cheers, Gene
--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
On Sat, Nov 17, 2012 at 03:11:12PM -0500, Gene Heskett wrote:
> I did, it worked and I have now put it in rc.local for the next reboot.
You can always install msr-tools on your box and do as root:
# rdmsr 0x8b
to get the current microcode revision.
--
Regards/Gruss,
Boris.
Commit-ID: 36c46ca4f322a7bf89aad5462a3a1f61713edce7
Gitweb: http://git.kernel.org/tip/36c46ca4f322a7bf89aad5462a3a1f61713edce7
Author: Boris Ostrovsky <[email protected]>
AuthorDate: Thu, 15 Nov 2012 13:41:50 -0500
Committer: H. Peter Anvin <[email protected]>
CommitDate: Tue, 20 Nov 2012 22:23:28 -0800
x86, microcode, AMD: Add support for family 16h processors
Add valid patch size for family 16h processors.
[ hpa: promoting to urgent/stable since it is hw enabling and trivial ]
Signed-off-by: Boris Ostrovsky <[email protected]>
Acked-by: Andreas Herrmann <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: H. Peter Anvin <[email protected]>
Cc: <[email protected]>
---
arch/x86/kernel/microcode_amd.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/x86/kernel/microcode_amd.c b/arch/x86/kernel/microcode_amd.c
index b3e67ba..efdec7c 100644
--- a/arch/x86/kernel/microcode_amd.c
+++ b/arch/x86/kernel/microcode_amd.c
@@ -190,6 +190,7 @@ static unsigned int verify_patch_size(int cpu, u32 patch_size,
#define F1XH_MPB_MAX_SIZE 2048
#define F14H_MPB_MAX_SIZE 1824
#define F15H_MPB_MAX_SIZE 4096
+#define F16H_MPB_MAX_SIZE 3458
switch (c->x86) {
case 0x14:
@@ -198,6 +199,9 @@ static unsigned int verify_patch_size(int cpu, u32 patch_size,
case 0x15:
max_size = F15H_MPB_MAX_SIZE;
break;
+ case 0x16:
+ max_size = F16H_MPB_MAX_SIZE;
+ break;
default:
max_size = F1XH_MPB_MAX_SIZE;
break;