Closed Sarisan closed 2 months ago
I think the dxg print may not be related to why the PCI devices cannot be accessed. Would need to look at logs of what's happening on the host:
/logs
Hello! Could you please provide more logs to help us better diagnose your issue?
To collect WSL logs, download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:
Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1
The scipt will output the path of the log file once done.
Once completed please upload the output files to this Github issue.
Click here for more info on logging
Thank you!
I am getting the same dmesg dgx print error on Windows Server 2022, version 21H2 build 203487.1364. It is the last entry after Ubuntu install and occurs after every invocation of nvidia-smi (post installing CUDA 12 with a GPU). The nvidia-smi command returns: Failed to initialize NVML: GPU access blocked by the operating system Failed to properly shut down NVML: GPU access blocked by the operating system
This Event looks relevant: Failed to map guest I/O buffer for read access with status 0xC00000A1. Device name = C:\Users\Administrator\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\ext4.vhdx
Log Name: Microsoft-Windows-Hyper-V-StorageVSP-Admin
Source: Microsoft-Windows-Hyper-V-StorageVSP
Date: 12/22/2022 9:36:05 AM
Event ID: 7
Task Category: None
Level: Error
Keywords:
User: NT VIRTUAL MACHINE\B1BEBEFC-AB0B-403F-82C4-96968F5306CB
Computer: WIN-3UDMJ4TFN2C
Description:
Failed to map guest I/O buffer for read access with status 0xC00000A1. Device name = C:\Users\Administrator\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\ext4.vhdx
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Hyper-V-StorageVSP" Guid="{10b3d268-9782-49a4-aacc-a93c5482cb6f}" />
<EventID>7</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2022-12-22T17:36:05.1060509Z" />
<EventRecordID>3</EventRecordID>
<Correlation />
<Execution ProcessID="11204" ThreadID="10076" />
<Channel>Microsoft-Windows-Hyper-V-StorageVSP-Admin</Channel>
<Computer>WIN-3UDMJ4TFN2C</Computer>
<Security UserID="S-1-5-83-1-2982067964-1077914379-2526463106-3406189455" />
</System>
<EventData>
<Data Name="DeviceName">C:\Users\Administrator\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\ext4.vhdx</Data>
<Data Name="Status">3221225633</Data>
</EventData>
</Event>
Hello, i have probably the same problem This is my wsl collect WslLogs-2023-03-07_19-11-24.zip
i have also a Journal.txt ubuntu journalog I can do another test.
Hello Last Errors journalctl -p err -n 5 Mar 10 13:43:38 DESKTOP-71NRFPV kernel: misc dxg: dxgk: dxgglobal_acquire_channel_lock: Failed to acquire global channel lock Mar 10 13:55:40 DESKTOP-71NRFPV kernel: misc dxg: dxgk: dxgglobal_acquire_channel_lock: Failed to acquire global channel lock Mar 10 13:55:41 DESKTOP-71NRFPV gnome-session-binary[11450]: Unrecoverable failure in required component org.gnome.Shell.desktop Mar 10 14:00:14 DESKTOP-71NRFPV kernel: misc dxg: dxgk: dxgglobal_acquire_channel_lock: Failed to acquire global channel lock Mar 10 14:00:14 DESKTOP-71NRFPV gnome-session-binary[11843]: Unrecoverable failure in required component org.gnome.Shell.desktop a@DESKTOP-71NRFPV:~$
Journal trace of last connexion Trace.txt
We also saw this issue popping off for #10357. Consider the relevant parts of kernel driver:
down_read(&dxgglobal->channel_lock);
if (dxgglobal->channel.channel == NULL) {
DXG_ERR("Failed to acquire global channel lock");
return -ENODEV;
} else {
return 0;
}
It seems like dxgglobal->channel.channel
. This means we don't even have a dxgkrnl IPC channel from Hyper-V.
But it actually makes sense, here's why:
And so there is no VMBus communication whatsoever without the virtual PCIE device. We also observed the same thing with @dfisk.
Windows Version
Microsoft Windows [Version 10.0.22631.3593]
WSL Version
2.1.5.0
Are you using WSL 1 or WSL 2?
Kernel Version
5.15.146.1-2
Distro Version
Debian GNU/Linux trixie/sid
Other Software
No response
Repro Steps
Just run WSL like usual
Expected Behavior
To see no errors
Actual Behavior
Spam of "Failed to acquire global channel lock" messages
Diagnostic Logs
I see the same behavior with the default kernel version either