Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Borislav Petkov]

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Borislav Petkov]

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.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[H. Peter Anvin]

It's too old, that's the problem.

Gene Heskett  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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Gene Heskett]

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 
>> >
>> >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:  is up!
He who laughs last usually had to have joke explained.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Gene Heskett]

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:  is up!
World War Three can be averted by adherence to a strictly enforced dress 
code!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Andreas Herrmann]

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 
> >
> >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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[H. Peter Anvin]

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Gene Heskett]

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:  is up!
Biz is better.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Borislav Petkov]

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Henrique de Moraes Holschuh]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Borislav Petkov]

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Borislav Petkov]

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.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Henrique de Moraes Holschuh]

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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Borislav Petkov]

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.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Gene Heskett]

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.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[H. Peter Anvin]

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


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Andreas Herrmann]

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 boris.ostrov...@amd.com
 
 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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Gene Heskett]

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!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Gene Heskett]

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 boris.ostrov...@amd.com
 
 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.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[H. Peter Anvin]

It's too old, that's the problem.

Gene Heskett ghesk...@wdtv.com 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.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Boris Ostrovsky]

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 


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



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Gene Heskett]

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 
>
>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:  is up!
Some people's mouths work faster than their brains.  They say things they
haven't even thought of yet.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Andreas Herrmann]

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 
> >
> >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: 

(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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Henrique de Moraes Holschuh]

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 
> >
> >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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[H. Peter Anvin]

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Henrique de Moraes Holschuh]

On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
> Add valid patch size for family 16h processors
> 
> Signed-off-by: Boris Ostrovsky 

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Boris Ostrovsky]

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 


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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Andreas Herrmann]

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 


Acked-by: Andreas Herrmann 


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
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Andreas Herrmann]

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 boris.ostrov...@amd.com


Acked-by: Andreas Herrmann herrmann.der.u...@googlemail.com


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
 
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Boris Ostrovsky]

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 boris.ostrov...@amd.com


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

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Henrique de Moraes Holschuh]

On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
 Add valid patch size for family 16h processors
 
 Signed-off-by: Boris Ostrovsky boris.ostrov...@amd.com

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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[H. Peter Anvin]

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.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Henrique de Moraes Holschuh]

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 boris.ostrov...@amd.com
 
 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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Andreas Herrmann]

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 boris.ostrov...@amd.com
 
 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: sta...@vger.kernel.org

(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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Gene Heskett]

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 boris.ostrov...@amd.com

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.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, microcode, AMD: Add support for family 16h processors

[Boris Ostrovsky]

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 boris.ostrov...@amd.com


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



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/