VHBA does not compile with kernel 6.11
This was fixed in vhba-module-20240917.
That does look more in line with other reports. To clarify - you do not only have vhba module loaded, but also have at least one cdemu-daemon instance running, and at least one virtual device created? Or not (i.e, just vhba module loaded, and nothing else). Also, do you have any other optical drives (internal or external) connected to the system? The number of in-flight number reported fordisk_events_workfn seems suspiciously high. I think this is related to kernel's continuous probing for device...
We've had couple of issue reports over years with suspend/hibernate (https://sourceforge.net/p/cdemu/bugs/91, https://github.com/cdemu/cdemu/issues/11), and I've seen couple of threads around the internet where vhba and cdemu were identified as culprit. I haven't been able to reproduce these locally, though. Suspend on my Fedora 40 notebook (6.10.4-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC) seems to work as expected. Although with caveat that the default suspend method here seems to be deep, while s2idle,...
We've had couple of issue reports with suspend/hibernate (https://sourceforge.net/p/cdemu/bugs/91, https://github.com/cdemu/cdemu/issues/11), and I've seen couple of threads around the internet where vhba and cdemu were identified as culprit. I haven't been able to reproduce these locally, though. Suspend on my Fedora 40 notebook (6.10.4-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC) seems to work as expected. Although with caveat that the default suspend method here seems to be deep, and s2idle, which...
Daemon: adjust error codes returned by read commands
Daemon: implement SEEK (10) command
Daemon: READ SUBCHANNEL command fixes