Re: [gentoo-user] Microcode updates for "old" Intel CPU's

[Mick]

On Monday, 8 January 2018 17:47:03 GMT Corbin Bird wrote:
> On 01/07/2018 02:46 PM, taii...@gmx.com wrote:
> > I have several sandy/ivybridge CPU's and I was wondering if anyone
> > knows as to if intel is releasing microcode updates for them.
> > 
> > It sure would be funny if intel wanted you to buy a new CPU to fix a
> > problem that was their fault to begin with.
> 
> Do you remember the x87 bugs discovered in the original i586 Pentiums?
> Never fixed.
> Still built into every Intel CPU.
> Intel does NOT replace "defective-by-design" hardware.
> Instead, every OS is required to "software emulate" the FPU.
> 
> Search for "errata-not-bug".
> Intel's term for their screw-ups in their CPUs.
> 
> Intel is only releasing patch code for the last five years of products.
> 
> And ... if you read up on the "e-mails" being posted ...
> ... It looks as if Intel is NOT going to fix this in future CPUs either.
> Instead, every OS will be required to "work-around-this".
> 
> Perhaps the reason "someone" tried to implicate this effects ALL CPU
> architectures?
> ( IBM RISC 6000, PowerPC, DEC Alpha, IBM System/390, Sun SPARC64, for
> example )
> 
> Intel did try to make their "patch" mandatory for AMD CPUs ( with NO
> disable switch ).
> Why?
> Think about it.
> 
> Corbin

So what affordable and available CPUs should one be looking into for a new 
desktop build?

Also, laptops?

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] microcode applied?

[Mick]

On Tuesday, 9 January 2018 00:15:03 GMT Peter Humphrey wrote:
> On Monday, 8 January 2018 10:29:41 GMT Max Zettlmeißl wrote:
> > > How do you build the microcode into the kernel? The only
> > > place I can see to do that in menuconfig is under Device Drivers;
> > > there's no such field under Firmware.
> > 
> > The Device Drivers section is exactly where the microcode is included.
> > CONFIG_EXTRA_FIRMWARE is the relevant symbol.
> 
> Right. So which of the 95 files under /lib/firmware/intel-ucode do I
> specify? That's in addition to the 14 files I have for my amdgpu.

There may be a cleverer way, but this is how I have been doing it.

Install sys-apps/iucode_tool.  Run:

# iucode_tool -S

It will report the microcode signature for your CPU.  For example, one of 
mine:

iucode_tool: system has processor(s) with signature 0x000106e5


(Re)emerge sys-firmware/intel-microcode and capture all its output.  Then 
search for the above signature, again from the same CPU, as an example, this 
matches:

intel-ucode/06-1e-05
signature: 0x106e5<==
flags: 0x13
revision:  0x07
date:  2013-08-20
size:  7168


Add the first line above in your CONFIG_EXTRA_FIRMWARE and rebuild your 
kernel.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] migrating to profile 17 for either ppc or ppc64

[Herminio Hernandez, Jr.]

I am curious to know has anyone moved their ppc or ppc64 over to profile
17? If so what were hurdles if any?

[gentoo-user] How do I customize x11-terms/xterm?

[Grant Taylor]

How do I customize the features that are compiled into x11-terms/xterm?

I have been playing with a customized version of Xterm outside of 
portage and I'd like to migrate my customizations to the copy of Xterm 
that is emerged as part of the system.


So far my customizations consist of a modified ./configure command to 
enable options that I want.


How do I replicate that via portage?

What would I need to do if I wanted to patch a source file?



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

[gentoo-user] Profile 17.0, PIE, USE="pic", C(XX)FLAGS "-fpic", "-fPIC"?

[Walter Dnes]

  If you execute...

grep ":pic " /usr/portage/profiles/use.local.desc

...you'll get multiple listings that mention...
- disable optimized assembly code that is not PIC friendly
- Force shared libraries to be built as PIC (this is slower)

  Question: does PIE imply pic/PIC?  I.e does a PIE build also require
USE="pic" and CFLAGS/CXXFLAGS="-fpic -fPIC"?  If so, is there a way to
disable PIE in profile 17.0?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] single core athlon?

[Walter Dnes]

On Mon, Jan 08, 2018 at 08:44:04PM -0600, R0b0t1 wrote

> I was under the impression that disabling SMP on single core systems
> could lead to a performance increase, but wasn't necessary.

  Quote from the "Help" in "make menuconfig" from the CONFIG_SMP item:


This enables support for systems with more than one CPU. If you have
a system with only one CPU, say N. If you have a system with more
than one CPU, say Y.

If you say N here, the kernel will run on uni- and multiprocessor
machines, but will use only one CPU of a multiprocessor machine. If
you say Y here, the kernel will run on many, but not all,
uniprocessor machines. On a uniprocessor machine, the kernel
will run faster if you say N here.


> Is the deciding factor actually processor family? And - there are GCC
> versions or distributions that have already dropped support for x86_64
> processors? I'd only read about 32 bit families being dropped.

  I think you're misunderstanding me.  This is not about dropping x86_64
support.  Rather, the earliest "Athlon" models came out *BEFORE* AMD
introduced 64-bit support, and therefore support only 32-bit mode.
Similarly Intel Pentium3 cpus support only 32-bit mode.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

[gentoo-user] Re: single core athlon?

[Grant Edwards]

On 2018-01-08,  
 wrote:

> Does any body know if it's possible to set up gentoo on a single core
> 64 bit athlon, old socket 754?

Yes, it's possible.

Here's an recent writeup on installing Gentoo on a IBM PS/1 133MHz 486
with 64MB of RAM:

https://github.com/yeokm1/gentoo-on-486

-- 
Grant

[gentoo-user] Re: Will profile 17.0 break 3rd party binaries?

[Grant Edwards]

On 2017-12-05, Grant Edwards  wrote:
> On 2017-12-05, Ian Zimmerman  wrote:
>> On 2017-12-05 00:05, Holger Hoffstätte wrote:
>>
>>> > There are a number of third-party binary executables that I use
>>> > regularly on my Gentoo systems.
>>> > [...]
>>> > Is switching to the new 17.0 profile likely to break them?
>>> 
>>> Good question. I've been using a pie-enabled gcc 7.2 for months
>>> before the 17.0 profile switch and both acroread and skype (the
>>> new one) still work, so chances are your stuff will too.
>>
>> Years ago when I used acroread I found it quite irritating that it
>> came with its own bundled gtk and pretty much everything else.  If
>> it's still that way it's probably the reason why it is unaffected
>> by the change.
>>
>> I don't know if Grant's binaries are of similar persuasion.
>
> No, they depend on the host environment for all libraries that are
> not unique to the application: libc, libstdc++, Qt, gtk, xml,
> crypto, ssl, etc.

FWIW, I finished rebuilding world w/ 17.0 over the weekend, and it
looks like my third-party binaries all work the same as they did
before.  That's what I expected based on my understanding of the PIE
change: it didn't change the ABI or the way dynamic library linkage
worked.

I did have to grab the qtwebkit:4 ebuild out of the attic, but that's
apparently still working too.

-- 
Grant Edwards   grant.b.edwardsYow! Of course, you
  at   UNDERSTAND about the PLAIDS
  gmail.comin the SPIN CYCLE --

Re: [gentoo-user] microcode applied?

[Rich Freeman]

On Sun, Jan 7, 2018 at 11:42 PM,   wrote:
> You really can't fix it completely in
> software on either brand, at best you are counting on code to protect code
> from a hardware on intel, and  more mild but still dangerous design issues
> on both.

As far as I can tell from the various emails/postings you can actually
fix this entirely in software on AMD, though it might be better solved
with a combination of microcode and software.

Variant 3 doesn't impact AMD.

Regarding variant 2:
https://lkml.org/lkml/2018/1/4/742
(which seems to be down right now, so I'll also post:)
https://webcache.googleusercontent.com/search?q=cache:i47fyooNn4UJ:https://lkml.org/lkml/2018/1/4/742+=1=en=clnk=us

Regarding variant 1, I suspect this could be fixed with a call to
something like CPUID, though that probably will impact performance a
bit in critical code, and it probably could also be fixed by tossing
in some instructions to manipulate either speculative execution or the
cache (such as forcing the CPU to fetch both possible target addresses
into the cache to make it impossible to tell which branch was
followed).  Using LFENCE (which is what Intel recommends) apparently
requires an MSR setting or maybe a microcode update.  I haven't
actually tested CPUID on the released spectre exploit code, but I have
confirmed that LFENCE doesn't fix it at all without the microcode/MSR
fix.  The main advantage of microcode updates would be that you could
probably reduce the complexity of the software fix and maybe improve
performance.  Not speculatively executing something will always have
some performance hit, but it could be minimal.

There is also an AMD microcode update floating around (which Gentoo
just deployed), and I can't figure out what it actually does, because
AMD hasn't said a word about it.  I can't imagine that anybody other
than AMD wrote it, so I assume it went through back channels (Suse was
the first to come out with it).  Suse says that it disables branch
prediction, and everybody else seems to be going with that description
(though the upstream kernel team hasn't accepted the change).
Obviously it can't completely disable branch prediction without
clobbering performance so it is a mystery as to when it actually does
disable it.  I haven't deployed the kernel patch to load it yet so I
haven't had a chance to test the spectre variant 1 code with it.

There is also a lot of discussion on lkml about the right fix.  We
might very well end up seeing both AMD- and Intel-specific fixes with
conditional logic.  The two vendors don't really seem to be
coordinating on this.  Intel is pushing patches that apparently don't
work on AMD, or aren't necessary on AMD.  AMD for its part hasn't been
pushing much in public at all, but has made a few list posts, and they
have that mystery microcode update.

I suspect that that Linux will either adopt conditional AMD vs Intel
code, or will force a compromise that works on both.  I have no idea
what that will end up being.  Once that happens I wouldn't be
surprised if we see GCC adopt a fix to apply the software side of that
automatically.

-- 
Rich

Re: [gentoo-user] single core athlon?

[R0b0t1]

On Mon, Jan 8, 2018 at 4:43 PM, Walter Dnes  wrote:
>   There are "athlons" and then there are "athlons".  Check the gcc page
> https://gcc.gnu.org/onlinedocs/gcc-6.4.0/gcc/x86-Options.html#x86-Options
> for an idea of what's what.  You need at least the "k8" version.  The
> ultimate way to find out is to download the amd64 minimal install ISO
> https://wiki.gentoo.org/wiki/Handbook:AMD64/Full/Installation#Obtain_the_media
> and try to boot off it.
>

I was under the impression that disabling SMP on single core systems
could lead to a performance increase, but wasn't necessary.

Is the deciding factor actually processor family? And - there are GCC
versions or distributions that have already dropped support for x86_64
processors? I'd only read about 32 bit families being dropped.

Re: [gentoo-user] single core athlon?

[Walter Dnes]

On Mon, Jan 08, 2018 at 04:15:57AM +0100, mad.scientist.at.la...@tutanota.com 
wrote
> Does any body know if it's possible to set up gentoo on a single core
> 64 bit athlon, old socket 754?  I tried another distro and it said
> it didn't support non-smp 64 bit.  If not i'll have to put some 32
> bit os on it.  I'm planning to use it mostly for a local boot server
> for os installs or possibly firewall, maybe eventual honey pot since
> it is low energy usage.  I know it's not supported by current BSD
> or windows.  Thanks.

  There are "athlons" and then there are "athlons".  Check the gcc page
https://gcc.gnu.org/onlinedocs/gcc-6.4.0/gcc/x86-Options.html#x86-Options
for an idea of what's what.  You need at least the "k8" version.  The
ultimate way to find out is to download the amd64 minimal install ISO
https://wiki.gentoo.org/wiki/Handbook:AMD64/Full/Installation#Obtain_the_media
and try to boot off it.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] single core athlon?

[Dale]

Alan McKinnon wrote:
> I have one of those under my desk at home. Finally switched it off for
> the last time about 2 months ago.
>
> So yes, you can run 64 bit Gentoo on it just fine. Make the
> appropriate changes in make.conf and away you go.
>
> Just because distro X does not support cpu Y in mode Z does not mean
> that the compiler doesn't support it.
>
> On Mon, Jan 8, 2018 at 5:15 AM,  > wrote:
>
> Does any body know if it's possible to set up gentoo on a single
> core 64 bit athlon, old socket 754?  I tried another distro and it
> said it didn't support non-smp 64 bit.  If not i'll have to put
> some 32 bit os on it.  I'm planning to use it mostly for a local
> boot server for os installs or possibly firewall, maybe eventual
> honey pot since it is low energy usage.   I know it's not
> supported by current BSD or windows.  Thanks.
>
> mad.scientist.at.large (a good madscientist)
> -- 
>
>
>
>
> -- 
> Alan McKinnon
> alan dot mckinnon at gmail dot com


If one were to boot a sysrescue image/disk/DVD, wouldn't that show
whether Gentoo would work or not, since it is based off of Gentoo?  If
so, that would be a fast way to know for sure. 

Dale

:-)  :-) 

Re: [gentoo-user] microcode applied?

[Corbin Bird]

On 01/07/2018 09:24 PM, Adam Carter wrote:
> Does the absence of a "microcode updated" message in dmesg imply that
> the microcode was not updated?
>
> I believe my fam10/barcelona AMD CPU will use
> amd-ucode/microcode_amd.bin but there's no update message.
>
> I've checked the config against another system that works and cant see
> any errors. Is there a way to turn on debugging?

Sample "dmesg" output for a Fam15h AMD ( Kernel 4.9.xx ) :
> [   10.336395] microcode: microcode updated early to new
> patch_level=0x0600084f
> [   10.337132] microcode: CPU0: patch_level=0x0600084f
> [   10.337839] microcode: CPU1: patch_level=0x0600084f
> [   10.338631] microcode: CPU2: patch_level=0x0600084f
> [   10.342083] microcode: CPU3: patch_level=0x0600084f
> [   10.342756] microcode: CPU4: patch_level=0x0600084f
> [   10.343468] microcode: CPU5: patch_level=0x0600084f
> [   10.344117] microcode: CPU6: patch_level=0x0600084f
> [   10.344786] microcode: CPU7: patch_level=0x0600084f
> [   10.345615] microcode: Microcode Update Driver: v2.01
> , Peter Oruba
Output is very similar for Fam10h AMDs as well ( Phenom II x4 980 )

Re: [gentoo-user] Microcode updates for "old" Intel CPU's

[Corbin Bird]

On 01/07/2018 02:46 PM, taii...@gmx.com wrote:
> I have several sandy/ivybridge CPU's and I was wondering if anyone
> knows as to if intel is releasing microcode updates for them.
>
> It sure would be funny if intel wanted you to buy a new CPU to fix a
> problem that was their fault to begin with.
>
>
Do you remember the x87 bugs discovered in the original i586 Pentiums?
Never fixed.
Still built into every Intel CPU.
Intel does NOT replace "defective-by-design" hardware.
Instead, every OS is required to "software emulate" the FPU.

Search for "errata-not-bug".
Intel's term for their screw-ups in their CPUs.

Intel is only releasing patch code for the last five years of products.

And ... if you read up on the "e-mails" being posted ...
... It looks as if Intel is NOT going to fix this in future CPUs either.
Instead, every OS will be required to "work-around-this".

Perhaps the reason "someone" tried to implicate this effects ALL CPU
architectures?
( IBM RISC 6000, PowerPC, DEC Alpha, IBM System/390, Sun SPARC64, for
example )

Intel did try to make their "patch" mandatory for AMD CPUs ( with NO
disable switch ).
Why?
Think about it.

Corbin

Re: [gentoo-user] microcode applied?

[Peter Humphrey]

On Monday, 8 January 2018 10:29:41 GMT Max Zettlmeißl wrote:
> > How do you build the microcode into the kernel? The only
> > place I can see to do that in menuconfig is under Device Drivers;
> > there's no such field under Firmware.
> 
> The Device Drivers section is exactly where the microcode is included.
> CONFIG_EXTRA_FIRMWARE is the relevant symbol.

Right. So which of the 95 files under /lib/firmware/intel-ucode do I 
specify? That's in addition to the 14 files I have for my amdgpu.

-- 
Regards,
Peter.

Re: [gentoo-user] microcode applied?

[Mick]

On Monday, 8 January 2018 09:05:02 GMT Max Zettlmeißl wrote:
> It seems like there are no microcode updates for your specific CPU
> bundled in linux-firmware.

Only two out of three Intel boxen here report an early update of microcode in 
dmesg.  Even when they do, it is not certain the latest firmware has brought 
new code:

[0.00] microcode: microcode updated early to revision 0x7, date = 
2013-08-20

This date above puzzles me.  Is it that on this PC's CPU the Intel bugs cannot 
be ameliorated by the latest intel-ucode release, or is it that Intel have not 
bothered to release microcode revisions for all their products.

Running in the directory /lib/firmware/intel-ucode the following command:

iucode_tool -v --date-after=2017-01-01  --write-all-named-to=TEST .

spews out into TEST/ the microcode for this CPU:

s000106E5_m0013_r0007.fw

Therefore if microcode for my CPU was included in intel-ucode releases since 
2017-01-01, is this the same unchanged microcode being released since the date 
reported in dmesg of 2013-08-20?

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] microcode applied?

[Adam Carter]

On Mon, Jan 8, 2018 at 9:14 PM, Peter Humphrey 
wrote:

> On Monday, 8 January 2018 04:55:58 GMT Max Zettlmeißl wrote:
>
> > You can either use an initrd or build the microcode into your kernel
> > image. I prefer the latter.
>
> I'm confused now. How do you build the microcode into the kernel? The only
> place I can see to do that in menuconfig is under Device Drivers; there's
> no
> such field under Firmware.
>

Device Drivers -> Generic Driver Options -> Include in-kernel firmware
blobs in kernel binary

which is CONFIG_FIRMWARE_IN_KERNEL=y

Re: [gentoo-user] microcode applied?

[Max Zettlmeißl]

> How do you build the microcode into the kernel? The only
> place I can see to do that in menuconfig is under Device Drivers; there's no
> such field under Firmware.

The Device Drivers section is exactly where the microcode is included.
CONFIG_EXTRA_FIRMWARE is the relevant symbol.

Re: [gentoo-user] microcode applied?

[Peter Humphrey]

On Monday, 8 January 2018 04:55:58 GMT Max Zettlmeißl wrote:

> You can either use an initrd or build the microcode into your kernel
> image. I prefer the latter.

I'm confused now. How do you build the microcode into the kernel? The only 
place I can see to do that in menuconfig is under Device Drivers; there's no 
such field under Firmware.

-- 
Regards,
Peter.

Re: [gentoo-user] microcode applied?

[Max Zettlmeißl]

> Since I dont know where look up firmware version numbers i'm in the dark.

You can use MC Extractor to extract the metadata associated with the
AMD microcode updates.

The microcode_amd.bin which is part of
sys-kernel/linux-firmware-20180103-r1 contains the following microcode
updates:

CPUID   Version
00100F22 0183
00100F20 0184
00100F62 01C7
00100F43 01C8
00100F81 01D9
00100F80 01DA
00100F41 01DB
00100FA0 01DC
00200F31 0232
00300F10 0327
00500F10 0529
00500F20 05000119

According to your first message your CPU is likely to have either the
ID 00100F21 or the ID 00100F2A.
It seems like there are no microcode updates for your specific CPU
bundled in linux-firmware.