You are not logged in.
My problem usually results in black screen, not in BSOD. Unfortunately, i still can't fix it.
Are there any users who were able to do a successful AMD R7 260x setup with Catalyst drivers? The report sheet contains some mentions about this GPU. How can i find that people?
Based on http://wiki.x.org/wiki/RadeonFeature/ , it looks like R7 260(x) is a Sea Islands card (Bonaire), like my R9 290 (Hawaii).
Assuming your passthrough is set up propely in terms of VGA arbitration, perhaps your video issue is the same device-reset failure.
In my case, the OS loads, but the desktop is black. I can tell the desktop is actually alive by enabling Narrator: press win+u, and press space when the voice says "hear text read out loud". I seem to recall even being able to open Catalyst Control Center.
If that's what's happening to you, the workaround is to shut down the guest, suspend and resume the host, then start the guest again. You'll have to do this every time the guest restarts for any reason.
The spreadsheet entries for R7-260(x) include notes to reboot the host for guest reboot to work, but suspend/resume should have the same effect.
Last edited by DanaGoyette (2014-09-17 18:05:38)
Offline
Arakatak wrote:My problem usually results in black screen, not in BSOD. Unfortunately, i still can't fix it.
Are there any users who were able to do a successful AMD R7 260x setup with Catalyst drivers? The report sheet contains some mentions about this GPU. How can i find that people?
Based on http://wiki.x.org/wiki/RadeonFeature/ , it looks like R7 260(x) is a Sea Islands card (Bonaire), like my R9 290 (Hawaii).
I was researching that too, if anyone can confirm that the HD7790 has the reset problem, it might be affordable enough that I could pick one up for testing.
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
I was researching that too, if anyone can confirm that the HD7790 has the reset problem, it might be affordable enough that I could pick one up for testing.
Yes, the HD7790 has the reset problem.
My card is :
http://www.sapphiretech.com/presentatio … id=1&leg=0
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Bonaire XT [Radeon HD 7790/8770 / R9 260 OEM] (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited / Sapphire Technology Radeon HD 7790 Dual-X OC
Flags: bus master, fast devsel, latency 0, IRQ 51
Memory at c0000000 (64-bit, prefetchable) [size=256M]
Memory at d0000000 (64-bit, prefetchable) [size=8M]
I/O ports at e000 [size=256]
Memory at f6100000 (32-bit, non-prefetchable) [size=256K]
Expansion ROM at f6140000 [disabled] [size=128K]
Capabilities: [48] Vendor Specific Information: Len=08 <?>
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
Capabilities: [150] Advanced Error Reporting
Capabilities: [270] #19
Capabilities: [2b0] Address Translation Service (ATS)
Capabilities: [2c0] #13
Capabilities: [2d0] #1b
Kernel driver in use: vfio-pci
Kernel modules: radeon
Offline
I was researching that too, if anyone can confirm that the HD7790 has the reset problem, it might be affordable enough that I could pick one up for testing.
Yes, the HD7790 has the reset problem.
Ok, I'll try to keep an eye out for a cheap one on ebay
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
I am not sure what the reset problem ppls talk about R9. I had success with Sapphire Radeon R9 270 Dual-X OC 2GB DDR5 256Bit, but i recall having some issues with the audio part complaining about a power state, and i think it worked when was assigned with a secondary port explicitly for the audio. So anybody willing to try something like this:
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \
-device vfio-pci,host=01:00.0,addr=00.0,multifunction=on,bus=root.1,x-vga=on \
-device ioh3420,bus=pcie.0,addr=1c.1,multifunction=on,port=2,chassis=2,id=root.2 \
-device vfio-pci,host=01:00.1,addr=00.1,multifunction=on,bus=root.2 \
Ofc with the host=...0X:00.0/1 part changed if necessary. To test if its the same problem i had, copy-paste the qemu command line in a terminal, and if its the same problem upon first run it gives no error message, but only upon shutdown and next subsequent vm start, only then it complains something related to the power state of the audio address. Sry cant recall the exact msg. But i think the above approach might just solve that, again, if its the same problem. Best of luck.
Last edited by noobman (2014-09-18 03:01:02)
Offline
I am not sure what the reset problem ppls talk about R9. I had success with Sapphire Radeon R9 270 Dual-X OC 2GB DDR5 256Bit, but i recall having some issues with the audio part complaining about a power state, and i think it worked when was assigned with a secondary port explicitly for the audio. So anybody willing to try something like this:
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \ -device vfio-pci,host=01:00.0,addr=00.0,multifunction=on,bus=root.1,x-vga=on \ -device ioh3420,bus=pcie.0,addr=1c.1,multifunction=on,port=2,chassis=2,id=root.2 \ -device vfio-pci,host=01:00.1,addr=00.1,multifunction=on,bus=root.2 \
Ofc with the host=...0x:00.x part changed if necessary. To test if its the same problem i had, copy-paste the qemu command line in a terminal, and if its the same problem upon first run it gives no error message, but only upon shutdown and next subsequent vm start, only then it complains something about something related to the power state of the audio address. Sry cant recall the exact msg. But i think the above approach might just solve that, again, if its the same problem. Best of luck.
As I understand it, the reset problem prevents users with these cards from even rebooting the VM without going through contortions with host suspend/resume or reboot.
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
As I understand it, the reset problem prevents users with these cards from even rebooting the VM without going through contortions with host suspend/resume or reboot.
Dunno, what others had tbh. I just described my own experience. The error message i had was upon follow-up attempt of starting the vm, and was something like "stuck in suspend" or "stuck in D3" or something like that, and was pointing not to the video of 00.0, but was instead pointing to the ...00.1 which was the audio. I first tried passing only the video card, that particular message was gone but i still had problems with the driver instalation in guest. When i passed both like that, with different port for the audio, then it stopped throwing errors upon subsequent start(s) and also drivers installed right away. Again just to be clear, that just my eperience and may not fix the others issues, i just thought its worth mentioning and maybe somebody can give it a try.
Edit: Oh i didnt meant the user would suspend/resume the vm, no that was just qemu complaining when the vm was re-started. It would restart the vm, it would just throw that error message right before starting. I mean just like those messages of "iommu group not viable" etc. Tho this time somebody needs to see that exact message, so has to copy-paste in terminal otherwise it would be missed because qemu just keeps going after it.
Edit2: Also i think the reason warning is not there at first vm start (after a host boot), maybe because the passed card is just being initialized first time. Only at subseqent vm starts the warning appears, as if the previous improper reset left the device in a bad power state. This is how it looks like at least. Again, just to say, this is my experience, not necesarily what others have. Anyway my issue was gone with that allocation of secondary port for audio. Maybe that way it results in guest doing two resets, one distinct for each device. Or maybe the driver just expects the audio to be in a port right near. No clue why it worked like that.
Last edited by noobman (2014-09-18 03:45:53)
Offline
I am not sure what the reset problem ppls talk about R9. I had success with Sapphire Radeon R9 270 Dual-X OC 2GB DDR5 256Bit, ...
The R9 270 is not a Sea Islands card. See http://xorg.freedesktop.org/wiki/Radeon … etingnames
Southern Islands:
CAPE VERDE, PITCAIRN, TAHITI, OLAND, HAINAN
HD7750 - HD7970, R9 270, R9-280, R7 240, R7 250
Sea Islands:
BONAIRE, KABINI, KAVERI, HAWAII
HD7790, R7 260, R9 290
Offline
Bummer. I could report success wtih the R9 270 and with R7 240 which i'm using now, too bad its beyond the point. But another idea, if issues reflect on host, could you check $dmesg | grep -i hotplug if it reports back something like hotplug for pcie and pci. Cant guess something else about why host would be in trouble.
Offline
Bummer. I could report success wtih the R9 270 and with R7 240 which i'm using now, too bad its beyond the point. But another idea, if issues reflect on host, could you check $dmesg | grep -i hotplug if it reports back something like hotplug for pcie and pci. Cant guess something else about why host would be in trouble.
qemu? kernel? mobo? parameters?
just to see if I'm missing something. I can0t passthrough my r9 270
Offline
qemu? kernel? mobo? parameters? just to see if I'm missing something. I can0t passthrough my r9 270
I edited the spreadsheet posted by mr noctavian, the R9 270 config is on row no 276. Cpu i7-4790 and no intel graphics bs (disabled in bios), just 2 plain cards instead. Really no patches of any sort, stock kernel, and the module loading as i described a few posts before. The grub cmd line still needs intel_iommu=on and pci-stub.ids=.... but otherwise the modules are loaded via /etc/modules-load.d/... one module per line of conf file, and options if needed via the other folder, but in case of Z97 chipset i think should need no special options.
Kernels can work starting with 3.13 but recommending up to date 3.17-rc5 (or at least rc3). If you are using latest this might not be the case, but otherwise for older kernel and stuff, can use cli $ ll /sys/kernel/iommu_groups/1/devices/ and play with the 2 cards slot combination to make sure the iommu group with the passed gpu is clean and does not contain other devices.
About R9 270 i had that issue i also described a few posts above, with qemu complaining/warning "stuck in D3", which dissapeared when putting the hdmi audio on secondary ioh3420 port. You could also describe your configuration.
Last edited by noobman (2014-09-19 00:21:49)
Offline
So... just happened to get an update for Nvidia 344.11... Code 43 again
I have no words...
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
just installed new nvidia driver 344.11 and got error code 43 (((
Last edited by slis (2014-09-19 04:31:01)
Offline
So... just happened to get an update for Nvidia 344.11... Code 43 again
I have no words...
Lol, you guys should just be grateful you got your cards working - why try to update?
Haven't read this for a bit (my nvidia failure killed my enthusiasm somewhat), but great to see that spreadsheet with results - well done whoever did it.
Offline
So... just happened to get an update for Nvidia 344.11... Code 43 again
I have no words...
Silly nVidia I'm glad I bought AMD R9
Offline
Bummer. I could report success wtih the R9 270 and with R7 240 which i'm using now, too bad its beyond the point. But another idea, if issues reflect on host, could you check $dmesg | grep -i hotplug if it reports back something like hotplug for pcie and pci. Cant guess something else about why host would be in trouble.
would it be too much of a trouble to ask you some more details on r7 240?
some points of special interest (r7 240 as passed gpu, not host one):
- any problems with it so far? reboots or anything else
- vendor/model/memory?
- does it support UEFI boot (just firmware check would be enough in fact)?
Offline
I was researching that too, if anyone can confirm that the HD7790 has the reset problem, it might be affordable enough that I could pick one up for testing.
Yes, the HD7790 has the reset problem.
My card is :
http://www.sapphiretech.com/presentatio … id=1&leg=0
Does the Sapphire card have an EFI BIOS?
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
would it be too much of a trouble to ask you some more details on r7 240?
some points of special interest (r7 240 as passed gpu, not host one): [...]
Ups i am very sry i think that was innacurate from my part, R7 240 was host card. Anyway I tried to do a "quickie" passthrough now to see how it is, and i got lots errors like these:
[...]VFIO 0000:03:00.0 BAR 0 mmap unsupported. Performance may be slow
[...]vfio_bar_read(,0x9080, 4) failed: Device or resource busy" and "vfio_bar_write(,0x9084, 0xffffff, 4) failed: Device or resource busy
[...]vfio_bar_write(,0x9084, 0xffffff, 4) failed: Device or resource busy
[dmesg:]
[ 57.855348] systemd-journald[183]: /dev/kmsg buffer overrun, some messages lost.
[ 57.855359] vfio-pci 0000:03:00.0: BAR 0: can't reserve [mem 0xd0000000-0xdfffffff 64bit pref]
[ 57.857534] vfio-pci 0000:03:00.0: BAR 0: can't reserve [mem 0xd0000000-0xdfffffff 64bit pref]
Sry have not investigated any further. Maybe i was doing something wrong. And/or this mobo i have (dx79to) has bios revisions which are total crap, all of them.
On this system i pass the nvidia and i dont do driver updates. On the other system with Z97 chipset the R9 270 is passed and i could say i am happier with that instead, costed ~50% less and benchmarks ~20% better, tho this is a subjective opinion.
Last edited by noobman (2014-09-19 14:38:40)
Offline
So... just happened to get an update for Nvidia 344.11... Code 43 again
I have no words...
Then it looks like they are doing this on purpose? Couldnt be a coincidence could it?
Offline
would it be too much of a trouble to ask you some more details on r7 240?
some points of special interest (r7 240 as passed gpu, not host one):
- any problems with it so far? reboots or anything else
- vendor/model/memory?
- does it support UEFI boot (just firmware check would be enough in fact)?
I have an HD8570 OEM card, which I think is effectively the same as the r7 240. It works well for me, no reset problem. It does report NoSoftRst-, which makes the vfio code attempting to reset the device on release not activate, even though PM reset itself doesn't seem to do anything. That just means if the VM is stopped rather than doing a clean shutdown, the last image on the screen remains (for now). The OEM card is not the highest quality, a little noisy, but I found that the fanless CoolViva Z1 can take care of that problem if you've got the room. Yes, the OEM HD8570 supports UEFI.
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
@aw, noobman:
thanks for the info.
sinny wrote:would it be too much of a trouble to ask you some more details on r7 240?
some points of special interest (r7 240 as passed gpu, not host one):
- any problems with it so far? reboots or anything else
- vendor/model/memory?
- does it support UEFI boot (just firmware check would be enough in fact)?I have an HD8570 OEM card, which I think is effectively the same as the r7 240. It works well for me, no reset problem. It does report NoSoftRst-, which makes the vfio code attempting to reset the device on release not activate, even though PM reset itself doesn't seem to do anything. That just means if the VM is stopped rather than doing a clean shutdown, the last image on the screen remains (for now). The OEM card is not the highest quality, a little noisy, but I found that the fanless CoolViva Z1 can take care of that problem if you've got the room. Yes, the OEM HD8570 supports UEFI.
well, seems like i'll have to bet a bit and blindly try r7 240 of some vendor (no 8570 at my place at all)
was initially looking at nvidia cards, but all this driver absurd (not to mention that i never had success trying to passthrough gt 430)... "nvidia, .uck you!" (c) linus
Offline
@aw, noobman:
thanks for the info.aw wrote:sinny wrote:would it be too much of a trouble to ask you some more details on r7 240?
some points of special interest (r7 240 as passed gpu, not host one):
- any problems with it so far? reboots or anything else
- vendor/model/memory?
- does it support UEFI boot (just firmware check would be enough in fact)?I have an HD8570 OEM card, which I think is effectively the same as the r7 240. It works well for me, no reset problem. It does report NoSoftRst-, which makes the vfio code attempting to reset the device on release not activate, even though PM reset itself doesn't seem to do anything. That just means if the VM is stopped rather than doing a clean shutdown, the last image on the screen remains (for now). The OEM card is not the highest quality, a little noisy, but I found that the fanless CoolViva Z1 can take care of that problem if you've got the room. Yes, the OEM HD8570 supports UEFI.
well, seems like i'll have to bet a bit and blindly try r7 240 of some vendor (no 8570 at my place at all)
was initially looking at nvidia cards, but all this driver absurd (not to mention that i never had success trying to passthrough gt 430)... "nvidia, .uck you!" (c) linus
Don't forget you can download ROMs from the TechPowerUp database and test them for UEFI support. This can at least provide some indication of which vendor to pick.
EDIT: to save you the trouble, there are only 3 ROMs listed for the R7 240 and only the VTX3D includes EFI support. That's certainly not definitive of the other vendors though.
Last edited by aw (2014-09-19 16:09:49)
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
anickname wrote:I was researching that too, if anyone can confirm that the HD7790 has the reset problem, it might be affordable enough that I could pick one up for testing.
Yes, the HD7790 has the reset problem.
My card is :
http://www.sapphiretech.com/presentatio … id=1&leg=0Does the Sapphire card have an EFI BIOS?
No EFI BIOS.
See :
https://www.sendspace.com/file/2mjmw8
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Bonaire XT [Radeon HD 7790/8770 / R9 260 OEM] (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited / Sapphire Technology Radeon HD 7790 Dual-X OC
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 51
Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M]
Region 2: Memory at d0000000 (64-bit, prefetchable) [size=8M]
Region 4: I/O ports at e000 [size=256]
Region 5: Memory at f6100000 (32-bit, non-prefetchable) [size=256K]
Expansion ROM at f6140000 [disabled] [size=128K]
Capabilities: [48] Vendor Specific Information: Len=08 <?>
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported-
RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee00718 Data: 0000
Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
Capabilities: [150 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover+ Timeout+ NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [270 v1] #19
Capabilities: [2b0 v1] Address Translation Service (ATS)
ATSCap: Invalidate Queue Depth: 00
ATSCtl: Enable-, Smallest Translation Unit: 00
Capabilities: [2c0 v1] #13
Capabilities: [2d0 v1] #1b
Kernel driver in use: vfio-pci
Kernel modules: radeon
Last edited by anickname (2014-09-19 19:25:43)
Offline
So... just happened to get an update for Nvidia 344.11... Code 43 again
I have no words...
"bluebird" reported on oftc/#qemu that 344.11 is now checking hyper-v extensions, so if you remove all those hv-foo cpu parameters and leave kvm=off, 344.11 works. I've confirmed this on my VM. Unfortunately some of those hypver-v extensions are fairly useful and have shown to help performance, so NVIDIA appears to be intentionally crippling GeForce, possibly to make Quadro appear to be a better choice for a VM (as if official support isn't enough). NVIDIA already seems to disable MSI on GeForce, so it's not the first time GeForce has been intentionally crippled to boost the professional cards.
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
Hello,
I have been trying to get this VGA Passthrough to work now for some time but seems like I am stuck now
When I try to start the VM will it open in a QEMU window and the terminal will say:
qemu-system-x86_64: vfio: Cannot reset device 0000:01:00.1, no available reset mechanism.
qemu-system-x86_64: vfio: Cannot reset device 0000:01:00.0, no available reset mechanism.
qemu-system-x86_64: vfio: Cannot reset device 0000:01:00.1, no available reset mechanism.
qemu-system-x86_64: vfio: Cannot reset device 0000:01:00.0, no available reset mechanism.
cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.9.3-030903-generic root=UUID=8c0763f7-e4c0-4b58-80e3-6db2416ea751 ro quiet splash intel_iommu=on vfio_iommu_type1.allow_unsafe_interrupts=1
lspci -nn | grep NVIDIA
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104 [GeForce GTX 760] [10de:1187] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GK104 HDMI Audio Controller [10de:0e0a] (rev a1)
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK106 [GeForce GTX 660] [10de:11c0] (rev a1)
02:00.1 Audio device [0403]: NVIDIA Corporation GK106 HDMI Audio Controller [10de:0e0b] (rev a1)
dmesg | grep pci-stub
[ 0.500541] pci-stub: add 10DE:1187 sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[ 0.500549] pci-stub 0000:01:00.0: claimed by stub
[ 0.500556] pci-stub: add 10DE:0E0A sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[ 0.500559] pci-stub 0000:01:00.1: claimed by stub
Any help would be greatly appreciated
Offline