Tesla xenctrlext.unix_error Device or resource is busy

olivierlambert

Note that PCI passthrough will be entirely exposed in XO with XCP-ng 8.3, no need for the CLI anymore

kuznetcoff777

@olivierlambert
After restart VM it began to show the same error, just like hide list is empty. If any way to check this hide list?

May 22 11:10:57 xcp kernel: [86647.738094] pciback 0000:05:00.0: timed out waiting for pending transaction; performing function level reset anyway
May 22 11:10:58 xcp kernel: [86648.986119] pciback 0000:05:00.0: not ready 1023ms after FLR; waiting
May 22 11:10:59 xcp kernel: [86650.042116] pciback 0000:05:00.0: not ready 2047ms after FLR; waiting
May 22 11:11:02 xcp kernel: [86652.346147] pciback 0000:05:00.0: not ready 4095ms after FLR; waiting
May 22 11:11:06 xcp kernel: [86656.698127] pciback 0000:05:00.0: not ready 8191ms after FLR; waiting
May 22 11:11:14 xcp kernel: [86665.146149] pciback 0000:05:00.0: not ready 16383ms after FLR; waiting
...
May 22 11:12:08 xcp kernel: [86718.394184] pciback 0000:05:00.0: not ready 65535ms after FLR; giving up

olivierlambert

Maybe this will ring a bell to anyone around here?

kuznetcoff777

Can someone please delete Solved sign? Cause problem still persists...
If any way to check what is in hide list?

olivierlambert

Put back as unresolved

kuznetcoff777

[11:12 xcp ~]# dmesg | grep pciback
[    0.000000] Command line: root=LABEL=root-apezjy ro nolvm hpet=disable rd.auto console=hvc0 console=tty0 quiet vga=785 splash plymouth.ignore-serial-consoles xen-pciback.hide=(0000:05:00.0)
[    3.313418] Kernel command line: root=LABEL=root-apezjy ro nolvm hpet=disable rd.auto console=hvc0 console=tty0 quiet vga=785 splash plymouth.ignore-serial-consoles xen-pciback.hide=(0000:05:00.0)

[20:49 xcp ~]# lspci -s 0000:05:00.0 -v
05:00.0 3D controller: NVIDIA Corporation TU104GL [Tesla T4] (rev ff) (prog-if ff)
        !!! Unknown header type 7f
        Kernel driver in use: pciback

Seems to be that it was on boot in exception and now it is still in. But VM cannot get it...

olivierlambert

You are only hidding one PCI address. In your dom0, with a lspci command, double check if you have other Nvidia references

kuznetcoff777

Yep, only one, cause one tesla onboard, no any other video devices (maybe it is a problem)

[20:53 xcp ~]# lspci | grep -i nvidia
05:00.0 3D controller: NVIDIA Corporation TU104GL [Tesla T4] (rev ff)

seanmcg182

For anyone who finds this in the future, I ran into a similar issue today when passing through a LSI Card,
Coincidentally on Address 05:00.0, also coincidentally on a Supermicro Board (mine is X10DRH-CT, OPs was a X8DA8)
I was originally writing a comment here to see if a solution had ever been found, but while taking/marking up screenshots of my Motherboards System Block Diagram, I discovered my problem...

Human Error of course.

Long story short, I added a PCI to 2xM.2 card, and in my BIOS, I bifurcated the wrong CPU/PCI Port.

Instead of Bifurcating the M.2 Card, I accidentally Bifurcated the LSI Card, which caused the Unknown Header Error AND since there was an unknown header, the VM Would throw the "Device or Resource is busy" error when trying to start.

Correcting the Bifurcation fixed the issue in my case.

Not sure if that was the issue in OPs case, but this might help someone else who stumbles across this

poddingue

@seanmcg182 's post might be the answer to the original question, two years late.
Your lspci -s 0000:05:00.0 -v at post 8 shows (rev ff) and !!! Unknown header type 7f, which is the same pair he had, and in his case it came from bifurcating the wrong PCIe port in the BIOS rather than from anything XCP-ng was doing.
He says the unknown header is what then produced the device or resource busy error on VM start, which is the error you opened with.
I don't know whether your board exposes bifurcation the way his X10DRH-CT does, so it might not transfer at all.
@kuznetcoff777 if that machine is still around, it'd be worth a look either way.