When I run MDART routing protocol tcl script in NS 2.35, it says:
When configured, ns found the right version of tclsh in /usr/bin/tclsh8.6
but it doesn't seem to be there anymore, so ns will fall back on running the first tclsh in your path. The wrong version of tclsh may break the test suites. Reconfigure and rebuild ns if this is a problem.
num_nodes is set 16
INITIALIZE THE LIST xListHead
channel.cc:sendUp - Calc highestAntennaZ_ and distCST_
highestAntennaZ_ = 1.5, distCST_ = 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0
SORTING LISTS ...DONE!
Segmentation fault (core dumped)
And the simulation end time supposely end at 205s but when run the animation, the simulation end at 8s. Why is that? Thanks
ns found the right version of tclsh in /usr/bin/tclsh8.6
but it doesn't seem to be there anymore
tcl8.6 : You are supposed to use the "ns-2.35 tcl8.5.10" : It doesn't change version or location. (Unless you move ns-allinone-2.35). The external tcl8.6 can change with e.g. an update. And later versions tend to be missing some files, e.g. in Debian / Ubuntu.
Example https://drive.google.com/file/d/0B7S255p3kFXNVVlxR0ZNRGVORjQ/view?usp=sharing
$ tar xvf ns-allinone-2.35_gcc5.tar.gz ## 2014 - 2017 update
$ cd ns-allinone-2.35/
$ export CC=gcc-4.8 CXX=g++-4.8 && ./install
Segmentation fault
MDART cannot be used with a contemporary OS. The latest that worked was an Ubuntu 18.04.4 updated 16 months ago. Please see my tests https://drive.google.com/drive/folders/1si2jA3lc-23lubVHb3tFbIAXfnhRfg5O?usp=sharing ..... CentOS 8 fails, Ubuntu 20.04 fails. Etc. "2021 OS" fails.
EDIT : Further tests revealed that an updated Ubuntu 18.04 failed : The latest Ubuntu version for MDART is 16.04 .
NOTE 1: The Ubuntu 16.04 nam package is corrupt. Please use https://drive.google.com/file/d/0B7S255p3kFXNdmxzSmRzaVRWb28/view?usp=sharing → nam_1.15-10-ubuntu14_amd64.deb
NOTE 2: The Ubuntu 16.04 ns command : sudo apt install ns2
NOTE 3: Building ns-allinone-2.35/ → Four cases of random Tk errors after the latest Ubuntu updates. Possible solutions: Use ns-allinone-2.35_2021.tar.xz https://drive.google.com/file/d/167cP7hPnJGiNL3rK4Mxnh_-0t7_S8FTL/view?usp=sharing with Tcl, Tk updated to version 8.5.17 .... And there are three options for extra gcc/g++ compilers to try out https://drive.google.com/drive/folders/1xVEATaYAwqvseBzYxKDzJoZ4-Hc_XOJm?usp=sharing
export CC=gcc447 CXX=g++447 && ./install ## can also be used with ns-allinone-2.35 version 2011
export CC=gcc48 CXX=g++48 && ./install
export CC=gcc54 CXX=g++54 && ./install
Simulation time : The setting is maximum time. Example : The setting set val(end) 1006.0 will run about 6 seconds and end the output text with : 1000 simulation seconds ....... Time is relative. ns2 was developed in the 90th when processors were very slow Pentium 1 / Pentium 2 . ... And different protocols behave different with simulation time.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I would like to set up AMD Radeon for Deep Learning on Ubuntu. The main libraries for my work are keras and pytorch. I followed strictly on ROCm installation guideline here but failed at the 3rd step with the command sudo apt install rocm-dkms. Error messages were shown as follows.
Setting up dkms (2.8.1-5ubuntu1) ...
Setting up hip-rocclr (4.0.20496.5685.40000-23) ...
Setting up rock-dkms (1:4.0-23) ...
Loading new amdgpu-4.0-23 DKMS files...
Building for 5.8.0-41-generic
Building for architecture x86_64
Building initial module for 5.8.0-41-generic
Error! Bad return status for module build on kernel: 5.8.0-41-generic (x86_64)
Consult /var/lib/dkms/amdgpu/4.0-23/build/make.log for more information.
dpkg: error processing package rock-dkms (--configure):
installed rock-dkms package post-installation script subprocess returned error
exit status 10
Setting up g++-9 (9.3.0-17ubuntu1~20.04) ...
Setting up g++ (4:9.3.0-1ubuntu2) ...
update-alternatives: using /usr/bin/g++ to provide /usr/bin/c++ (c++) in auto mo
de
Setting up build-essential (12.8ubuntu1.1) ...
dpkg: dependency problems prevent configuration of rocm-dkms:
rocm-dkms depends on rock-dkms; however:
Package rock-dkms is not configured yet.
dpkg: error processing package rocm-dkms (--configure):
dependency problems - leaving unconfigured
Setting up gcc-multilib (4:9.3.0-1ubuntu2) ...
No apport report written because the error message indicates its a followup erro
r from a previous failure.
Setting up g++-9-multilib (9.3.0-17ubuntu1~20.04) ...
Setting up g++-multilib (4:9.3.0-1ubuntu2) ...
Processing triggers for sgml-base (1.29.1) ...
Setting up x11proto-dev (2019.2-1ubuntu1) ...
Setting up libxau-dev:amd64 (1:1.0.9-0ubuntu1) ...
Processing triggers for libc-bin (2.31-0ubuntu9.2) ...
Processing triggers for man-db (2.9.1-1) ...
Setting up libxdmcp-dev:amd64 (1:1.1.3-0ubuntu1) ...
Setting up x11proto-core-dev (2019.2-1ubuntu1) ...
Setting up libxcb1-dev:amd64 (1.14-2) ...
Setting up libx11-dev:amd64 (2:1.6.9-2ubuntu1.1) ...
Setting up libglx-dev:amd64 (1.3.2-1~ubuntu0.20.04.1) ...
Setting up libgl-dev:amd64 (1.3.2-1~ubuntu0.20.04.1) ...
Setting up mesa-common-dev:amd64 (20.2.6-0ubuntu0.20.04.1) ...
Setting up rocm-opencl-dev (3.6Beta-17-g875c1f8-rocm-rel-4.0-23) ...
Settin XT g up rocm-clang-ocl (0.5.0.64-rocm-rel-4.0-23-50fb51a) ...
Setting up rocm-utils (4.0.0.40000-23) ...
Setting up rocm-dev (4.0.0.40000-23) ...
Processing triggers for libc-bin (2.31-0ubuntu9.2) ...
Errors were encountered while processing:
rock-dkms
rocm-dkms
E: Sub-process /usr/bin/dpkg returned an error code (1)
My kernel version is 5.8.0-41-generic. My VGA card is Gigabyte Radeon RX6900 XT. My CPU is AMD Ryzen 9 3900 XT. I tried several solutions suggested in previous posts but it did not solve my problem. May I have your suggestions to fix this.
I've been having the same issue as well. The only way I found to fix it is to roll back to the 5.6.0-1042-oem kernel. The AMD drivers don't seem to support any kernel past this one.
Edit: This is also a way to get the amdgpupro drivers to install without a problem.
WARNING: I'm writing all this after the fact and i might have missed a step or something along the way. Please be very careful especially with trying to remove kernels and when working in your boot directory. If you're uncomfortable with the idea of wrecking your system you can always set grub's default selection which is a lot safer than removing an initramfs.
Here's how I got RocM working
sudo apt install linux-image-5.6.0-1042-oem linux-headers-5.6.0-1042-oem && reboot
Make sure you boot into the 5.6 kernel by accessing the Ubuntu advanced options in grub.
sudo apt remove linux-image-5.8.0-41-generic linux-headers-5.8.0-41-generic && sudo apt autoremove && reboot
Again you'll have to reboot into 5.6 through the advanced options. (Hold the shift key after BIOS finishes loading to get the Ubuntu Advanced Options menu.) After you're back in it's a good idea to set your headers and image as held back because a kernel update will most likely break RocM.
sudo apt-mark hold linux-image-generic linux-headers-generic
Now we're going to try and flush out the 5.8 kernel. Start by flushing out the temporary files.
sudo rm -rv ${TMPDIR:-/var/tmp}/mkinitramfs-*
Now list all of the kernels installed.
dpkg -l | tail -n +6 | grep -E 'linux-image-[0-9]+'
And try to remove the 5.8 kernel. Do this for any kernel you have above the 5.6 one we installed.
sudo update-initramfs -d -k 5.8.0-41-generic
Now the initramfs, Systemmap, and config are still present in the boot dir so we need to clear those out to get grub working properly again.
cd /boot/
sudo rm vmlinuz-5.8.0-41-generic System.map-5.8.0-41-generic config-5.8.0-41-generic
Now you should be finally ready to update grub
sudo update-grub && reboot
Now when you load back in you should be able to install RocM
sudo apt install rocm-dkms
As per the official notes in this link, AMD ROCm platform is designed to support Ubuntu 20.04.1 (5.4 and 5.6-oem) and 18.04.5 (Kernel 5.4).
So kernel version 5.8 is not supported. However, downgrading is an option but instead of rushing to that, you can simply boot into an older version of kernel.
Try following steps:
Restart your computer,
Wait for the grub menu to open (how to open grub menu: link).
Select advanced options for ubuntu
Select an alternate kernal from the list shown.
My SikuliX script run on Windows10. However, under Linux (Debian 7.11), the script only opens my application and refuses to continue to execute the remaining script. I tried running on SikuliX versions 1.1.4 and 2.0.1.
Gives an error message:
“[Error] App.isRunning: '[ps, -p, -1]' Process exited with an error: 1
(Exit value: 1)”
Please tell me what is the matter here and is it possible to fix this error?
System Information:
Debian OS 7.11
/usr/local/share/OpenCV/java/libopencv_java320.so
/opt/opencv/opencv-3.2.0/build/lib/libopencv_java320.so
I have java -version installed:
openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
Here is my script:
uc = App("/opt/UniversalReader/UniversalReader-v3.9.22_x64")
uc.open()
if not uc.isRunning(10): # wait max 10 seconds
exit(1)
wait(0.3)
mTL = find("Iconuc.png") # find top left.
mBEx = find("PrimerBtn.png")
hover(mBEx.getCenter().click())
while not exists("Listofexamples.png"):
sleep(5)
click("findTestDatabtn.png")
for x in findAll("Closebtn.png"):
sleep(1)
click("Closebtn.png")
click("Closebtn.png")
click("Closebtn.png")
mClbtn = find("CloseBtnPanel.png")
click(mClbtn)
while not exists("WinClose.png"):
sleep(5)
click("NoBtn.png")
mExitBtn = mTL.nearby(1000).right().find("ExitBtn.png") # find top right
click(mExitBtn)
while not exists("WinExit.png"):
sleep(5)
click("NoBtn.png")
This is RaiMan from SikuliX - sorry for the delay (you already asked on Launchpad).
Apparently the feature App.isRunning() does not work on Linux as expected. So I take it as a bug.
You should wait for your app to be ready in another way.
You might e.g. check visually or by looking for a text on the screen.
DraftSight 2017SP1 Linux (beta) worked on Fedora 24. It fails after upgrading to Fedora 26. Running it from the command line so you can see the low-level errors,
/opt/dassault-systemes/DraftSight/Linux/DraftSight
Qt: Session management error: None of the authentication protocols specified are supported
Could not parse stylesheet of object 0x238a050
Could not parse stylesheet of object 0x238a050
In the graphics environment you see the usual start screens, then error pop-ups which offer to report the error and then close the application when clicked. One says that error-reporting is not available.
Similarly with 2017SP3 and 2018SP0. Fedora updates are current as of today.
This system is an Intel core i3. lspci reports "Intel Corp Xeon E3-1200 v3/4th Gen core processor Integrated Graphics Controller (rev 06)"
2018SP0 does work once an Nvidia GT710 card and the nvidia driver module are installed. It does not work with the nouveau driver module and the same card.
Does anybody have any insight as to the cause? A regression in Fedora, or a latent bug in DraftSight, or anything else?
Knowing whether it works with Fedora 26 and AMD graphics might be very helpful.
Edit March 2018
Doesn't work but differently on a system with AMD R5 230. No "Could not parse" errors, not anything else on the terminal window, but Draftsight starts up with the display all wrong and then locks up. Clicking the "X" gets to "the program is not responding".
Also worth noting that this isn't a Wayland issue. Systems are running Cinnamon and lightdm, so it's good old X.
Also a work-around, if performance is unimportant. (And it probably isn't, with Gen 4 Intel Graphics). Run it as a "remote" application on localhost, on a system with Intel graphics.
$ ssh -X 127.0.0.1
password:
Last login: Wed Mar ...
-bash-4.4$ /opt/dassault-systemes/DraftSight/Linux/DraftSight
(success)
Further update Fedora 29, DraftSight 2018SP3
New wrinkles for Nvidia, Cinnamon as above
Needs invocation
LD_PRELOAD=/usr/lib64/libfreetype.so.6 /opt/dassault-systemes/DraftSight/Linux/DraftSight
otherwise fails with /lib64/libfontconfig.so.1 lookup error FT_DOne_MM_Var
Also kernel 4.20 plus NVidia 390.87 fails to build. There's a patched NVidia installer that does work at if_not_false_then_true site.
Also does not install a .desktop file into /usr/share/applications
I had similar problems when I updated Fedora 24 to 25. The parse stylesheet messages still show up but I can run draftsight from an Xorg session, (not Wayland), using the nouveau drivers but only under root privileges using sudo .
You might try the following script:
sudo DISPLAY=$DISPLAY vblank_mode=1 /opt/dassault-systemes/DraftSight/Linux/DraftSight
I can only get DraftSight to run as root under Fedora 27, 4.18.16-100.fc27.x86_64. I have installed a VM with Ubuntu, and it runs fine, without elevated privileges.
I am trying to execute a TCL script through Ubuntu console,
Example test script exeuction in Console
tcl Main.tcl -file xxxx -test xxxx | tee test.log
It was throwing an error message without executing my script max size for a Tcl value (2147483647 bytes) exceeded
My Machine TCL Version
% puts $tcl_version
8.6
My Machine TCL Platform
% parray tcl_platform
tcl_platform(byteOrder) = littleEndian
tcl_platform(machine) = x86_64
tcl_platform(os) = Linux
tcl_platform(osVersion) = 3.13.0-32-generic
tcl_platform(pathSeparator) = :
tcl_platform(platform) = unix
tcl_platform(pointerSize) = 8
tcl_platform(threaded) = 1
tcl_platform(user) = vkosuri
tcl_platform(wordSize) = 8
But it was running fine with other Ubuntu machine without giving any error message
Other Machine TCL Version
% puts $tcl_version
8.4
Other Machine TCL Platform
% parray tcl_platform
tcl_platform(byteOrder) = littleEndian
tcl_platform(machine) = x86_64
tcl_platform(os) = Linux
tcl_platform(osVersion) = 2.6.28-19-generic
tcl_platform(platform) = unix
tcl_platform(threaded) = 1
tcl_platform(user) = vkosuri
tcl_platform(wordSize) = 8
Could someone explain what went wrong with my machine.
Thanks
Malli
That looks exactly like you might be hitting a limit on the size of memory block that can be allocated in one piece. The 2GB limit on 64-bit platforms is a long-standing bug (assigned to me!) that can't be fixed without utterly destroying the ABI, which is why it's not been fixed yet. When you hit the limit, Tcl fails. It doesn't always fail catastrophically — that depends partially on what sort of context it has for recovery at the C level at the point when the problem is hit — but it most certainly can just keel over.
Since this is a known issue, your best bet would be if you can find a workaround. Can you process your data a bit at a time instead of in one massive chunk? (We'd need to see more of your code to make specific suggestions, of course.)
The problem was freeTDS package on Ubuntu http://www.freetds.org/
1st Approach
The queries are working well with freeTDS == 0.63, but my Ubuntu has freeTDS 0.93, now i downgraded freeTDS 0.93 to 0.63, it is working fine.
freeTds 0.63 source
ftp://ftp.freetds.org/pub/freetds/old/0.63/freetds-0.63.tar.gz
Setting up SQL Server connection on my Ubuntu Box
Required libraries/programs
tclodbc >= v2.5.1
unixODBC >= v2.2.11
freeTDS == 0.63
Configuration
Edit /etc/odbcinst.ini and include the following section:
Description = SQL Server 2005
Driver Driver = /usr/lib/odbc/libtdsodbc.so
2nd Approach
Copy libtdsodbc.so to /usr/lib/odbc/
I have placed libtdsodbc.so in my Google drive, you can download
https://drive.google.com/open?id=0B_cUPwVRE2oUXzIzX0NNSG1VZ1E&authuser=0
Hope it will work.
Thanks
Malli
Recently a colleague needed to use NVML to query device information, so I downloaded the Tesla development kit 3.304.5 and copied the file nvml.h to /usr/include. To test, I compiled the example code in tdk_3.304.5/nvml/example and it worked fine.
Over a weekend, something changed in the system (I cannot determine what was changed and I am not the only one with access to the machine) and now any code that uses nvml.h, such as the example code, fails with the following error:
Failed to initialize NVML:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
WARNING:
You should always run with libnvidia-ml.so that is installed with your NVIDIA Display Driver. By default it's installed in /usr/lib and /usr/lib64. libnvidia-ml.so in TDK package is a stub library that is attached only for build purposes (e.g. machine that you build your application doesn't have to have Display Driver installed).
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
However, I can still run nvidia-smi and read information about my K20m's state, and as far as I am aware nvidia-smi is just a set of calls to nvml.h. The error message I receive is somewhat cryptic, but I believe it is telling me that the nvidia-ml.so file needs to match the Tesla driver that I have installed on my system. Just to ensure everything is correct, I re-downloaded CUDA 5.0 and installed the driver, CUDA runtime, and the test files. I am certain that the nvidia-ml.so file matches the driver (both are 304.54) so I am quite confused as to what could be going wrong. I can compile and run the test code with nvcc as well as run my own CUDA code, as long as it doesn't include nvml.h.
Has anyone encountered this error or have any thoughts on rectifying the issue?
$ ls -la /usr/lib/libnvidia-ml*
lrwxrwxrwx. 1 root root 17 Jul 19 10:08 /usr/lib/libnvidia-ml.so -> libnvidia-ml.so.1
lrwxrwxrwx. 1 root root 22 Jul 19 10:08 /usr/lib/libnvidia-ml.so.1 -> libnvidia-ml.so.304.54
-rwxr-xr-x. 1 root root 391872 Jul 19 10:08 /usr/lib/libnvidia-ml.so.304.54
$ ls -la /usr/lib64/libnvidia-ml*
lrwxrwxrwx. 1 root root 17 Jul 19 10:08 /usr/lib64/libnvidia-ml.so -> libnvidia-ml.so.1
lrwxrwxrwx. 1 root root 22 Jul 19 10:08 /usr/lib64/libnvidia-ml.so.1 -> libnvidia-ml.so.304.54
-rwxr-xr-x. 1 root root 394792 Jul 19 10:08 /usr/lib64/libnvidia-ml.so.304.54
$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module 304.54 Sat Sep 29 00:05:49 PDT 2012
GCC version: gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)
$ nvcc -V
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2012 NVIDIA Corporation
Built on Fri_Sep_21_17:28:58_PDT_2012
Cuda compilation tools, release 5.0, V0.2.1221
$ whereis nvml.h
nvml: /usr/include/nvml.h
$ ldd example
linux-vdso.so.1 => (0x00007fff2da66000)
libnvidia-ml.so.1 => /usr/lib64/libnvidia-ml.so.1 (0x00007f33ff6db000)
libc.so.6 => /lib64/libc.so.6 (0x000000300e400000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x000000300ec00000)
libdl.so.2 => /lib64/libdl.so.2 (0x000000300e800000)
/lib64/ld-linux-x86-64.so.2 (0x000000300e000000)
EDIT: The solution was to remove all extra instances of libnvidia-ml.so. For some reason there were a LOT of them.
$ sudo find / -name 'libnvidia-ml*'
/usr/lib/libnvidia-ml.so.304.54
/usr/lib/libnvidia-ml.so
/usr/lib/libnvidia-ml.so.1
/usr/opt/lib/libnvidia-ml.so
/usr/opt/lib/libnvidia-ml.so.1
/usr/opt/lib64/libnvidia-ml.so
/usr/opt/lib64/libnvidia-ml.so.1
/usr/opt/nvml/lib/libnvidia-ml.so
/usr/opt/nvml/lib/libnvidia-ml.so.1
/usr/opt/nvml/lib64/libnvidia-ml.so
/usr/opt/nvml/lib64/libnvidia-ml.so.1
/usr/lib64/libnvidia-ml.so.304.54
/usr/lib64/libnvidia-ml.so
/usr/lib64/libnvidia-ml.so.1
/lib/libnvidia-ml.so.old
/lib/libnvidia-ml.so.1
You are getting this error because the application that is trying to use nvml is loading the stub library that is located in:
...tdk_install_path/lib64/libnvidia-ml.so
instead of the one in:
/usr/lib64/libnvidia-ml.so
I was able to reproduce your error when I added the stub library path to my LD_LIBRARY_PATH environment variable. So that is one possible source of error, if someone added the path of the stub library that comes with the tdk distribution to your LD_LIBRARY_PATH environment variable, but probably not the only way this could happen. If someone in an unusual fashion copied the stub library to some system path, that might also be an issue.
You'll need to try and figure out why your system is loading that stub library in place of the correct one in /usr/lib64. Alternatively, for discovery purposes, you could try deleting all instances of the stub library anywhere on your system (leave the correct libraries in /usr/lib and /usr/lib64 alone), and you should be able to observe correct behavior.
I solved the problem this way on a GTX 1070 using windows 10 : go to device manager, select the GPU that is having a problem, disable the GPU and enable back.
I was having this same or similar issue with EWBF Cuda Miner for zCash.
Here is a way to automatically implement Pro7ech's answer (which worked for me) for WIN10:
Install WDK for Windows 10 if you don't already have it: This will give you the ability to use devcon.exe which allows manipulation of devices via batch scripts:
https://learn.microsoft.com/en-us/windows-hardware/drivers/download-the-wdk
You might also need the Windows SDK if you don't have visual studio with Desktop development with C++ workload:
https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk
To make things easier, you might want to add the installation path to your PATH environment variable:
https://www.howtogeek.com/118594/how-to-edit-your-system-path-for-easy-command-line-access/
Devcon.exe was installed here for me:
C:\Program Files (x86)\Windows Kits\10\Tools\x64
So now run this or similar in a cmd.exe prompt to get the device id:
devcon findall * | find /i "nvidia"
Here is what mine looks like:
C:\Users\Soenhay>devcon findall * | find /i "nvidia"
HDAUDIO\FUNC_01&VEN_10DE&DEV_0083&SUBSYS_38426674&REV_1001\5&1C277AD4&0&0001: NVIDIA High Definition Audio
SWD\MMDEVAPI\{0.0.0.00000000}.{574980C3-9747-42EF-A78C-4C304E070B81}: SAMSUNG (NVIDIA High Definition Audio)
ROOT\UNNAMED_DEVICE\0000 : NVIDIA Virtual Audio Device (Wave Extensible) (WDM)
PCI\VEN_10DE&DEV_1B81&SUBSYS_66743842&REV_A1\4&1F1337ch33s3&0&0000: NVIDIA GeForce GTX 1070
From that I see that my graphics device id is:
PCI\VEN_10DE&DEV_1B81&SUBSYS_66743842&REV_A1\4&1F1337ch33s3&0&0000
So I create a batch file with the following to disable and re-enable the driver:
devcon disable "#PCI\VEN_10DE&DEV_1B81&SUBSYS_66743842&REV_A1\4&1F1337ch33s3&0&0000"
devcon enable "#PCI\VEN_10DE&DEV_1B81&SUBSYS_66743842&REV_A1\4&1F1337ch33s3&0&0000"
Now, when I get the NVML error when starting the miner I just run this batch file and it fixes it. You could also just add those 2 lines to the beginning of your start.bat file to do this every time but I found that the error does not always happen every time I restart the miner time now.
References:
superuser post
devcon commands
devcon examples
No matching devices found.
NOTE:
The command should have the # symbol at the beginning of the device id.
The batch script should be run as administrator.
I have faced the same error.
Found a solutions is to run command:
nvidia-uninstall