Re: [gentoo-user] Re: AMD microcode updates - where are they?!
grep fam /proc/cpuinfo -> 21 = 15h -> 22 = 16h
Re: [gentoo-user] Re: AMD microcode updates - where are they?!
> > $ dmesg | grep -i micro > > [0.622441] [drm] Loading ARUBA Microcode > > [5.763242] [drm] Loading hainan Microcode > > [6.653025] microcode: CPU0: patch_level=0x06001119 > > [6.657962] microcode: CPU1: patch_level=0x06001119 > > [6.658890] microcode: CPU2: patch_level=0x06001119 > > [6.659881] microcode: CPU3: patch_level=0x06001119 > > [6.661136] microcode: Microcode Update Driver: v2.2. > > I have a similar experience: > > [0.659996] microcode: CPU0: patch_level=0x01c8 > [0.660001] microcode: CPU1: patch_level=0x01c8 > [0.660006] microcode: CPU2: patch_level=0x01c8 > [0.660011] microcode: CPU3: patch_level=0x01c8 > [0.660029] microcode: Microcode Update Driver: v2.2. > [7.853509] [drm] Loading RS780 Microcode > > I have a 10h generation processor, and I also build in microcode_amd.bin > with the kernel. > Piledriver gets the early message barcelona/fam10h doesnt; # dmesg | grep microc [1.663099] microcode: microcode updated early to new patch_level=0x06000852 [1.664161] microcode: CPU0: patch_level=0x06000852 [1.665147] microcode: CPU1: patch_level=0x06000852 [1.666135] microcode: CPU2: patch_level=0x06000852 [1.667119] microcode: CPU3: patch_level=0x06000852 [1.668034] microcode: CPU4: patch_level=0x06000852 [1.668955] microcode: CPU5: patch_level=0x06000852 [1.670060] microcode: CPU6: patch_level=0x06000852 [1.670985] microcode: CPU7: patch_level=0x06000852 [1.672012] microcode: Microcode Update Driver: v2.2. # dmesg | grep microc [1.700378] microcode: CPU0: patch_level=0x01c8 [1.700435] microcode: CPU1: patch_level=0x01c8 [1.700488] microcode: CPU2: patch_level=0x01c8 [1.700543] microcode: CPU3: patch_level=0x01c8 [1.700684] microcode: Microcode Update Driver: v2.2. microcode_amd.bin hasn't changed since at least January 2018, so maybe there hasnt been any updates for the recent CPU vulnerabilities. Assuming the numbering is sequential its odd that the APU is at 0x06001119 but the latest from linux-firmware is only 0x01c8. Are you sure the APU is not fam16h ?
Re: [gentoo-user] Re: escape from i3lock
On Fri, 2019-07-12 at 09:01 -0700, Ian Zimmerman wrote: > On 2019-07-11 21:28, Nuno Silva wrote: > > > vlock -n -a > > Does vlock work from an XWindow session? Or would I have to use it > on > top of whatever I do to lock the XWindow session - > xscreensaver/i3lock > etc? > > (I browsed to the vlock README page on github but it doesn't answer > this > question.) > vlock -a is supposed to lock all virtual consoles. The -n makes it create a new vt, so it'll work even from within a running X session and it seems to block the ability to switch back to the X session until the system is unlocked. But -n also requires root privileges. Might also want to throw in a -s to temporarily disable alt-sysrq. This can basically take the place of your current screen locker and does a better job than even xscreensaver of locking out the system. signature.asc Description: This is a digitally signed message part
[gentoo-user] Re: AMD microcode updates - where are they?!
On 2019-07-12 13:18, Mick wrote: > $ dmesg | grep -i micro > [0.622441] [drm] Loading ARUBA Microcode > [5.763242] [drm] Loading hainan Microcode > [6.653025] microcode: CPU0: patch_level=0x06001119 > [6.657962] microcode: CPU1: patch_level=0x06001119 > [6.658890] microcode: CPU2: patch_level=0x06001119 > [6.659881] microcode: CPU3: patch_level=0x06001119 > [6.661136] microcode: Microcode Update Driver: v2.2. I have a similar experience: [0.659996] microcode: CPU0: patch_level=0x01c8 [0.660001] microcode: CPU1: patch_level=0x01c8 [0.660006] microcode: CPU2: patch_level=0x01c8 [0.660011] microcode: CPU3: patch_level=0x01c8 [0.660029] microcode: Microcode Update Driver: v2.2. [7.853509] [drm] Loading RS780 Microcode I have a 10h generation processor, and I also build in microcode_amd.bin with the kernel. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: [gentoo-user] Re: escape from i3lock
I think it can only be started from a VT. But what's the problem? I have an xsession going, plus tmux, plus perhaps something else going in one or more VT All I have to do is call vlock -a from a virtual terminal. Now to access any terminal VT or xsession - you have to unlock this VT first. But I can still access my box remotely through SSH Il Ven 12 Lug 2019, 18:01 Ian Zimmerman ha scritto: > On 2019-07-11 21:28, Nuno Silva wrote: > > > vlock -n -a > > Does vlock work from an XWindow session? Or would I have to use it on > top of whatever I do to lock the XWindow session - xscreensaver/i3lock > etc? > > (I browsed to the vlock README page on github but it doesn't answer this > question.) > > -- > Please don't Cc: me privately on mailing lists and Usenet, > if you also post the followup to the list or newsgroup. > To reply privately _only_ on Usenet and on broken lists > which rewrite From, fetch the TXT record for no-use.mooo.com. > >
[gentoo-user] Re: escape from i3lock
On 2019-07-11 21:28, Nuno Silva wrote: > vlock -n -a Does vlock work from an XWindow session? Or would I have to use it on top of whatever I do to lock the XWindow session - xscreensaver/i3lock etc? (I browsed to the vlock README page on github but it doesn't answer this question.) -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: [gentoo-user] Re: 2 months into an 8-month computation.
On Fri, 2019-07-12 at 07:18 +0300, Nikos Chantziaras wrote:
> On 11/07/2019 20:59, Alan Grimes wrote:
> > 'ey, I have the 2.3 months into an 8-month computation blues...
> > [...]
> > So basically all gentoo updates will have to be done at the end of
> > this
> > run, I'm not really sure when, sometime in the December-January
> > timeframe.
>
> I guess you should have written your code in a way that can store
> current state so that it can resume. Failing that, you could have
> used a
> VM that can save ("suspend") the guest state so that you can resume
> later.
>
> Food for thought for the future, I guess :-)
>
>
If he wants to live dangerously he could try sys-process/criu...
Probably would want to spin up another instance of the computation and
test with that and make sure it works correctly first.
LMP
signature.asc
Description: This is a digitally signed message part
[gentoo-user] Re: conditional sysctl tweaks?
On 2019-07-12 07:12, Nikos Chantziaras wrote: > > What is the cleanest way to handle the situation when a new sysctl knob > > is introduced by a kernel release and I want to use it, but I also have > > older kernels around? > > What's the point of that? What's that? :-) -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: [gentoo-user] Upgrading to Qt 5.12.4 makes some applications invisible
On Mon, 8 Jul 2019 02:41:01 +0300 Nikos Chantziaras wrote: > Qt was upgraded from 5.12.3 to 5.12.4 and as a result some > applications (Clementine and qBittorrent) become invisible when you > minimize them and then restore them. They only become visible again > when you resize their window, and resizing the window is very slow. > > This does not affect most applications. Dolphin, Kate/Kwrite, System > Settings, SMPlayer, etc, all work fine. > > Rebuilding Clementine and qBittorrent didn't fix it. Rebuilding > kde-frameworks and kde-plasma didn't fix it. > > Have anyone else encountered this? Yes, I can confirm this behaviour with Clementine. I thought it was more Plasma video instability, I'm glad it's not! Robin -- -- Robin Atwood. "Ship me somewheres east of Suez, where the best is like the worst, Where there ain't no Ten Commandments an' a man can raise a thirst" from "Mandalay" by Rudyard Kipling -- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
[gentoo-user] AMD microcode updates - where are they?!
I'm looking at dmesg output which on my Intel CPUS of various vintages shows "microcode updated early ..." but two different AMD APUs of mine do not show the same, despite AMD apparently releasing microcode updates going back to 2011: https://www.bleepingcomputer.com/news/hardware/amd-releases-spectre-v2-microcode-updates-for-cpus-going-back-to-2011/ I have observed OEMs for laptop MoBos rarely if ever bother to release a UEFI/ BIOS firmware update past 1-2 years from launch of their products, while desktop OEMs may keep releasing updates for 3-5 years. Since there are no OEM MoBo firmware releases and I see no "microcode updated early ..." message in dmesg, I thought of checking with other Gentoo users if I'm doing something wrong, or if this is a common observation for AMD CPU/ APUs? PS. I include the microcode in the kernel, for both my Intel and AMD systems, rather than use an initramfs; e.g. CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd_fam15h.bin ..." PPS. This is all shown on one of the AMD APUs, way down during the booting process: $ dmesg | grep -i micro [0.622441] [drm] Loading ARUBA Microcode [5.763242] [drm] Loading hainan Microcode [6.653025] microcode: CPU0: patch_level=0x06001119 [6.657962] microcode: CPU1: patch_level=0x06001119 [6.658890] microcode: CPU2: patch_level=0x06001119 [6.659881] microcode: CPU3: patch_level=0x06001119 [6.661136] microcode: Microcode Update Driver: v2.2. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: escape from i3lock
I've been using vlock -a for years ... it works. Il giorno ven 12 lug 2019 alle ore 03:18 Laurence Perkins < lperk...@openeye.net> ha scritto: > > > So the solution is to just use "xscreensaver" by jwz. Which can be > > configured to just blank the screen etc. as wanted by the op. See > > also > > the FAQ: https://www.jwz.org/xscreensaver/faq.html > > > > HTH, > > -dnh > > > > Except I use xscreensaver myself and it in no way prevents VT switch, > which is what the OP was hoping to find a way to do if and only if the > screen is locked. Programs that grab input still don't get to block > combos that are processed by the X server before they even get to the > program's input queue any more than grabbing input will block the alt- > sysrq kernel-level interrupt keys. > > Disabling VT switch by the X server and then setting up some other way > to trigger a switch that will be blocked by whatever screen locking > program the OP wishes to use is the best solution I can think of. chvt > would be the program to call. Whether he wants it to be a keyboard > shortcut handled by his DE or some other trigger method is a matter of > taste. > > LMP >
