- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I've installed Vtune 2022.1.0 for Linux on my machine :
OS : Ubuntu 18.04 LTS
Kernel : 5.4.0-94-generic
CPU : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz
And vtune-gui starts fine...but as soon as I choose "Configure Analysis", Vtune generates an Unrecoverable Exception and I cannot go further (unusable).
(Please see the Exception message in the file "crash_Info.txt" attached here)
All VTune Kernel messages (see "dmesg log" in the file "crash_info-dmesg.txt attached here) seems fine accept for the last one which should correspond to the generated Exception :
traps: vtune-gui[16990] trap int3 ip:55c3e7880128 sp:7ffeb04ab0f0 error:0 in vtune-gui[55c3e7572000+65ed000]
I believe that the Exception occurs as soon as VTune tries to probe the hardware to determine what capabilities it has in order to determine what analysis can be used.
How can I correct this problem ?
Am I missing some packages or have incompatible packages versions in my Ubuntu distribution ?
Or is there a BIOS switch that impairs VTune's hardware exploration ?
Or maybe some access permissions that need to be changed ?
Any help would be greatly appreciated since VTune is unusable for me because of this and I really need it
Best regards,
Bruno
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Bruno,
You are right, it seems that something went wrong in the process of hardware probing. I have an idea about what could be the cause, so could you please post output of
ls -la /dev
as a file here?
Please also try to launch VTune as root if possible, as a potential workaround.
BR,
Andrey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Andrey,
So nice of you to give me a hand, it's very much appreciated.
Here is the output of "ls -la /dev" in the attached file.
Also, I've already tried to launch VTune as root (sudo) without success...same problem.
Could it be some "security switches" (secure boot or other) in BIOS that prevents the Hardware Probing ?
Best regards and thanks again for your help,
Bruno
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I doubt this has anything to do with BIOS settings. I found a bug in the code that traverses /dev and can cause such an issue, but was only able to reproduce it by creating a symlink to an inaccessible subfolder there. The only suspicious entry in your case was "stlinkv2_14 -> sep5/s14", which looks obviously odd and was probably created by some other driver bug, but trying as root should have solved it.
On my system I could identify the problematic entry with this bash oneliner, maybe it would help finding a workaround on yours:
for f in /dev/*; do stat -L $f 1> /dev/null ; done
Anyway, a solid fix should be in the next release.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Andrey,
You're a genius
That did the trick and now Vtune works fine (even without sudo).
I would have struggled to find that
The "stlinkv2" entries in "/dev" are coming from an install of TrueStudio (STM) and are devices to connect to and debug an STM32Fx evaluation card.
It seem that one of the "/etc/udev/rules.d/" rule files for the creation of those nodes in "/dev" are somewhat screwed up.
And I will be correcting that permanently.
Thank you so much, you've made my day
Bruno
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Andrey,
Here is a little update that may help you to find and correct this bug.
In my "/etc/udev/rules.d", I had a "rule file" for STLink with the following rule which created the node entries in /dev :
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374b", \
MODE:="0666", \
SYMLINK+="stlinkv2-1_%n"
For some reason, when exploring "/sys/devices/virtual/", "udev" finds the "sep5" directory "/sys/devices/virtual/sep5" and decides that it matches this rule.
It thus creates the problematic node entry in "/dev".
My workaround is to add a rule specific to "sep5" in the rule file, to specifically skip over the STLink rule, such as :
SUBSYSTEM=="sep5", GOTO="skip_rule_for_sep5"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374b", \
MODE:="0666", \
SYMLINK+="stlinkv2-1_%n"
LABEL="skip_rule_for_sep5"
And this works fine...no more problematic node entry with symbolic links to "sep5 nodes".
Maybe this will help you or others
Best regards and thanks again,
Bruno
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Glad this helped.
But I must note that this rule does not seem to work as expected. I think it is meant to pick specific ttyUSB* devices and create symlinks to it, but instead it picks all character devices that appear in /dev and messes their access permissions, seeing how you have sda allowed for write for everyone. This can create a security gap on your host, so I believe your udev configuration best be revised.
BR,
Andrey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
This bug is resolved in the latest version of VTune i.e. 2022.2. As this issue is resolved, Can we discontinue monitoring this thread?
Regards,
Alekhya
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Bruno,
As we have not heard back from you, we will close this thread. If you need any further assistance, please post a new question as this thread will no longer be monitored by Intel.
Regards,
Alekhya
![](/skins/images/D3C0B914909A6564BBB97F4AD1ED1973/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page