Failed to access perfctr msr linux

Arch Linux

You are not logged in.

#1 2013-04-25 19:43:31

kernel error on QEMU VM boot: Failed to access perfctr msr

I’ve been encountering this error on boot:

The system works well for months, but still — I’d like to know what’s causing this error and how to get rid of it.

#2 2013-05-28 18:19:55

Re: kernel error on QEMU VM boot: Failed to access perfctr msr

+1 found this on a KVM install

#3 2013-05-28 18:36:33

Re: kernel error on QEMU VM boot: Failed to access perfctr msr

No problems here. the command line you’re using to start the VM seems quite relevant here.

#4 2013-05-28 18:49:15

Re: kernel error on QEMU VM boot: Failed to access perfctr msr

just using virt-manager here with all default settings nothing special, anything you’d recommend?

#5 2013-05-28 20:04:04

Re: kernel error on QEMU VM boot: Failed to access perfctr msr

I’d like to know what’s causing this error

It’s not an error, it says that the CPU doesn’t support performance counters.

AFAIK Linux doesn’t use them for anything but NMI watchdog and if you aren’t going to do PMU-based software profiling on the guest system you don’t need them too.

and how to get rid of it.

It seems that some people tried to implement PMU in qemu-kvm; I’d start here. Or just ignore it.

BTW, if you don’t need PMU but still want some watchdog, QEMU can emulate one.

Last edited by mich41 (2013-05-28 20:16:58)

Источник

Arch Linux в Qemu: не удалось получить доступ к ошибке perfctr msr

В последнее время я получил файл Arch Linux (march build) iso через bittorrent.

Я попытался запустить его на виртуальной машине, но он попадает только на главный экран (на экране, где вы выбираете, что вы хотите сделать), как показано ниже:

Но когда я выбираю первый вариант, он показывает черный экран, который никуда не годится. Опция «Информация об оборудовании», похоже, работает, но она не в моих интеллектуальных способностях, поэтому я проигнорировал ее.

Затем я попробовал qemu с простой командой qemu-system-x86_64 ./location to file . Он показывает немного другое изображение:

При выборе x64-86 я получаю ошибки:

Я пользователь Ubuntu, поэтому я ничего не получаю, но первая ошибка, кажется, следующая:

Я получаю это сообщение (не удалось получить доступ к perctr msr) при загрузке с работающей гостевой Arch в Virtualbox. Эта проблема обсуждалась на форуме Arch (ссылка ниже) и, по-видимому, связана с функцией cpu, которая не существует в системе, дающей сообщение об ошибке, но эта функция неважна, поэтому сообщение может быть проигнорировано.

В последнем посте:

endle Member Зарегистрирован: 2013-07-07 Сообщений: 1

Re: ошибка ядра при загрузке QEMU VM: не удалось получить доступ к perfctr msr mich41 wrote:

Возможно, что-то несвязанное, возможно, загрузка без «тишины» покажет, что именно происходит, прежде чем оно зависает.

Спасибо! После загрузки без «тишины» я обнаружил, где проблема.

Источник

Cannot get access to MSRs. Please check permissions to the MSRs #373

Comments

nournadar commented Feb 4, 2021

My users keep getting cannot get access to MSRs. Please check permissions to the MSRs when I run «likwid-perfctr -g CACHES -m ls»
although I ran sudo modprobe msr but I somehow cannot run that command without sudo
I need normal users to be able to run this without sudo.

The text was updated successfully, but these errors were encountered:

TomTheBear commented Feb 4, 2021

Your description is quite short, so here are some guesses:

• Your systems run with Secure-Boot enabled. Deactivate it and try again.
• You use a pretty recent kernel version which disables write to MSRs. LIKWID commonly checks for read and write, so if writes fail, the whole check fails.
• After sudo modprobe msr , do you see /dev/cpu/*/msr files? ( ls -la /dev/cpu/*/msr )
• You installed LIKWID on an NFS file system which does not allow suid-root binaries

Otherwise, please supply your installation procedure and your changes to the confik.mk file.

nournadar commented Feb 4, 2021 •

Secure boot is not enabled

kernel version is: Linux 4.15.0-135-generic

I can see the msr files (this is a sample):

• It is installed on an NFS shared system and working on some servers without sudo while others not

TomTheBear commented Feb 4, 2021

When I remember correctly, NFSv4 (your /opt mountpoint) does not allow suid-root binaries.

You could try this:

LIKWID searches for the access daemon in PATH and with this setup, it should find the local one before the one on NFS. You can verify which daemon it uses when running with -V 3 :

nournadar commented Feb 4, 2021

I did the previous its still not working
as far as I know NFS4 supports suid-root binaries .. its already working on 2 of my other servers with similar config but different OS versions

TomTheBear commented Feb 4, 2021

Does likwid-accessD report anything in syslog? Who owns likwid-accessD on the NFS? How are the permissions? Which OS? Which version works, which not? The mount options are the same for both OS versions? As you tried the proposed way, what was the output when running with -V 3 ? Did it find the right access daemon?

nournadar commented Feb 7, 2021 •

Cannot find anything in syslog I am not sure who owns it on NFS how do I check this? I am currently comparing four servers, two working with ubuntu 16.04, one with ub16.04 not working and ub18 server not working as well .. all have identical mount options I am getting this with -V 3 on the server that is not working

TomTheBear commented Feb 8, 2021

Cannot find anything in syslog: Please recompile LIKWID with DEBUG=true in config.mk and try again. The accessdaemon should print UID and EUID of itself into syslog. I am not sure who owns it on NFS how do I check this? ls -la

on a client system.

Most systems I develop on use Ubuntu as well. Is there maybe a glibc update and you compiled LIKWID with a more recent glibc and try to run it now on installations with «old» glibc ? Can you try local distinct installations instead of one on the network FS?

You can try to execute likwid-accesD manually. It shouldn’t do anything (waiting for connects for a few seconds and exit) but maybe it throws a segfault or another error. If the error is ‘no such file or directoy’, it usually means that likwid-accessD just failed to start.

TomTheBear commented Feb 23, 2021

nournadar commented Mar 1, 2021

I recompiled locally (No NFS share) — added the debug=true part in config.mk

Still getting the same errors

• I am getting this in syslog now

TomTheBear commented Mar 2, 2021

So the access daemon segfaults after the connection is established. Can you run the access daemon alone without LIKWID? Just call /usr/sbin/likwid-accessD , wait until it returns and check the syslog whether there are any messages like exiting due to timeout . This helps me to localize the problematic part.
Are all CPU IDs consecutively numbered? In your output of ls /dev/cpu/*/msr , I see only 15 files with a lot of missing IDs. And I have this comment in the likwid-accessD source: NOTICE: This assumes consecutive processor Ids! Output of /proc/cpuinfo attached as file would help.
The Intel E5-2650 has 8 cores. Does the machine only have a single socket or multi socket? Is SMT enabled?

nournadar commented Mar 2, 2021

I tried to run the access daemon alone and I am getting a timeout as you suggested

This machine has 2 sockets and 8 cores per socket
ls /dev/cpu/*/msr

TomTheBear commented Mar 3, 2021

This looks all fine. All MSR files are present. It might be the PCI devices but debugging the access daemon is hard as it demonizes itself for security reasons. I was not able to use GDB on access daemon as it forks itself twice while GDB follows only one child.

I created a test for you to dig down where the problem in the daemon is. The attached tarball consists of an extracted access-daemon and a client. The description what to do is in the README file or if you type make usage . You will need gdb to debug the issue and run it as root!
test-daemon-sandyep.zip

nournadar commented Mar 3, 2021 •

I am not sure if I am doing this correctly
I followed your steps but I am getting errors when I start the daemon
Do I need to load something before this ? should I put this dir in a specific location?
So sorry for my lack of knowledge in this area.

TomTheBear commented Mar 3, 2021

You configured all parts succesfully. You started only the daemon with make start_daemon but didn’t execute the other two parts.

You need three different shells (windows, tabs, however you call it), one of them with root permissions ( sudo bash ), and all in the test-daemon-sandyep folder. Use this order:
Shell Window 1:
make start_daemon
Shell Window 2 (with root permissions):
make start_debugger
Shell Window 3:
make start_client

nournadar commented Mar 4, 2021

I did exactly that and I am getting this in the debugger tab:

when I run gdb and typ bt or backtrace I get no stack
How do I proceed ?

TomTheBear commented Mar 4, 2021

That’s unfortunate. I tried to make it as convenient as possible for you.

You need the PID of the access-daemon executable, so after make start_daemon , try a pidof access-daemon to get it and start the debugger like this:
gdb —command=server.gdb -p ACCESS_DAEMON_PID
Afterwards proceed to make start_client

nournadar commented Mar 7, 2021

Is this what we’re looking for?
On the first machine I keep getting this

So the below I did on another non-working machine which is a broadwell with 2 sockets and 14 cores/socket

TomTheBear commented Mar 8, 2021

In the first case, the daemon was already running and you tried it again. The daemon creates a socket file (/tmp/likwid-123456) and this file already exists. Wait until it vanishes (around 30 seconds) or delete it yourself and try again.

In the second case, there is no segfault in the daemon. The reason is that the test daemon is tailored for Intel SandyBridge and doesn’t even know the register/device list for Broadwell. I could update the daemon but we should figure it out on SandyBridge first.

nournadar commented Mar 8, 2021

So I deleted the temp file on the sandybridge and re-ran the above
This is what I am getting in the debugger:

TomTheBear commented Mar 13, 2021

This output looks right. But there is no error, no segfault or anything, that’s unexpected. I’ll send you a new test daemon.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

[linux41] Kernel panic at i686 #14

Comments

philmmanjaro commented Jun 25, 2015

Beginning with linux41 on i686 boot up crashes — kernel panic :

The text was updated successfully, but these errors were encountered:

philmmanjaro commented Jun 25, 2015

Build was done with AMD-CPU and manjaro-tools r1411.9a00d6e-1.

philmmanjaro commented Jun 26, 2015

Maybe somebody might build linux41 on a different CPU and link me the packages, so I might test it on my machine .

Kirek commented Jun 26, 2015

philmmanjaro commented Jun 26, 2015

@Kirek, thx for building. Your build also crashes on my end on real hardware. If possible, can you check your build and mine from the repos, if those boot up on your end. Seems there is a regression with AMD CPUs and that kernel series, at least with i686.

Kirek commented Jun 26, 2015

rc8 from the repos works fine too

philmmanjaro commented Jun 26, 2015

Well, seems to be my CPU then. That means I have to wait until upstream will fix it .

Kirek commented Jul 1, 2015

Is this solved with 4.1.1 ?

philmmanjaro commented Jul 1, 2015

No, still there. I think that is why Arch is not updating their linux package to that series yet.

philmmanjaro commented Jul 11, 2015

So. still no good news from my end also 4.1.2 fails to boot on my CPU in i686. linux40 will be marked EOL with 4.0.9.

korrode commented Jul 12, 2015

This probably isn’t it, but have you checked that the initrd line for the Grub entry is indeed correct?

i.e.
initrd /boot/intel-ucode.img /boot/initramfs-4.1-i686.img

philmmanjaro commented Jul 12, 2015

Well, this one is correct:

Might check it without ucode to see .

philmmanjaro commented Jul 22, 2015

4.1.3 still doesn’t boot for me in i686.

philmmanjaro commented Jul 22, 2015

Testing with archiso has to wait a little .
Current Release: 2015.07.01
Included Kernel: 4.0.7

philmmanjaro commented Jul 23, 2015

However, I can boot the kernel in VirtualBox:

However, using more than one core will create the crash also.

philmmanjaro commented Jul 23, 2015

Here we go for the screenshots:

philmmanjaro commented Jul 23, 2015

Some of the text:

groeck commented Jul 24, 2015

The best way to get this fixed would be to bisect the problem.

philmmanjaro commented Jul 24, 2015

Well, this might take a while, as I’ve to find the entry first, if any 4.1-rcX boot up at all with this setting.

philmmanjaro commented Jul 24, 2015

I just tested 4.2-rc3 from arch.miffe.org. Same issue with more than one CPU core in i686. However it says: Failed to find cpu0 device node when booting up as single-core.

groeck commented Jul 24, 2015

On 07/23/2015 10:43 PM, Philip Müller wrote:

I just tested 4.2-rc3 from arch.miffe.org http://arch.miffe.org/i686/. Same issue with more than one CPU core in i686. However it says: Failed to find cpu0 device node when booting up as single-core.

The cpu node message is just noise.

philmmanjaro commented Jul 24, 2015

So, I just tested mainline 4.1-rc1 to 4.1-rc8 on a Xubuntu 15.04 VirtualBox install with two CPU cores enabled. Guess what, all kernels booted up. Also 4.2-rc3 booted just fine in that virtual machine. Might be configs then?

philmmanjaro commented Jul 24, 2015

I now compared our config against Ubuntus and against x86_64. Both boot somehow. Still don’t get which module is affected, though.

philmmanjaro commented Jul 24, 2015

Ok, seems to be a config issue. Using Ubuntus config made it boot on my machine. However it created a 1 GB package in size. Some of the differences made it boot after all. Also x86_64 boots. I’ll try to check now what blocks it on my end to boot on i686.

groeck commented Jul 24, 2015

On 07/24/2015 03:11 PM, Philip Müller wrote:

Ok, seems to be a config issue. Using Ubuntus config made it boot on my machine. However it created a 1 GB package in size. Some of the differences made it boot after all. Also x86_64 boots. I’ll try to check now what blocks it on my end to boot on i686.

Getting somewhere. Maybe it is just a change in configuration parameters.

Bisect with the original configuration might be useful, though,
to help understand what change is causing the problem with that configuration.

philmmanjaro commented Jul 24, 2015

Well, I still can’t pin-point which of these settings are needed. I assume it has something with CPU section to do. How should I Bisect?

groeck commented Jul 25, 2015

On 07/24/2015 04:31 PM, Philip Müller wrote:

Well, I still can’t pin-point which of these settings are needed. I assume it has something with CPU section to do. How should I Bisect?

Presumably you know a working kernel version. It should be a mainline kernel,
for example 4.0. You also know a broken kernel, for example 4.1.

Pick the latest kernel known to work and the earliest broken kernel
you can find. From a cloned mainline kernel tree, run

git bisect start

With the example above, that would be

git bisect start 4.1 4.0

Build the image with the resulting version, and test it.
If it is good, enter
git bisect good
otherwise enter
git bisect bad

After several iterations (around 12-14) it will (hopefully) tell you
the offending commit. Run «git bisect log» and post the results, and
«git bisect reset» to finish the bisect and clean up the tree.

Hope this helps, and that I understood your question correctly.

Источник