https://bugs.freedesktop.org/show_bug.cgi?id=101946
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=101946
weden...@yandex.ru changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #29 from Robin ---
As I will pass on my R9 290 and switch to an RX 580, please let me know if you
need any extra information from either card before I no longer have the R9 290.
--
You are receiving this mail because:
You are the a
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #28 from Robin ---
(In reply to Luke A. Guest from comment #27)
> > FWIW I don't think any of these patches are relevant to you then.
>
> Not strictly true. As I said, Alex pointed me at this page to try his
> patches. I believe all
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #27 from Luke A. Guest ---
> FWIW I don't think any of these patches are relevant to you then.
Not strictly true. As I said, Alex pointed me at this page to try his patches.
I believe all this is connected. There are issues un/bindi
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #26 from Robin ---
(In reply to Luke A. Guest from comment #25)
> I have 2 AMD GPU's, R9 390 (host) and R9 380 (guest). I boot with the 380
> being passed over to vfio-pci. On exit the VM sets the 380 back to vfio-pci.
FWIW I don't
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #25 from Luke A. Guest ---
> Hi Luke, few questions. When booting the host, do you boot with amdgpu or
> vfio-pci bound to the GPU? After you've started a VM, did you bind back to
> amdgpu or did you stay on vfio-pci?
I have 2 AMD
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #24 from Robin ---
(In reply to Luke A. Guest from comment #22)
> I'd like to report a minor success. I've managed to boot into win8.1 twice
> in a row. I booted as normal through virt-manager, then shutdown from inside
> the guest,
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #23 from Luke A. Guest ---
Created attachment 133173
--> https://bugs.freedesktop.org/attachment.cgi?id=133173&action=edit
Script to rebind a device back to the vfio-pci driver
forgot to submit this.
--
You are receiving this ma
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #22 from Luke A. Guest ---
I'd like to report a minor success. I've managed to boot into win8.1 twice in a
row. I booted as normal through virt-manager, then shutdown from inside the
guest, then called a script:
#!/bin/sh
echo 1 >
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #21 from Luke A. Guest ---
Created attachment 133172
--> https://bugs.freedesktop.org/attachment.cgi?id=133172&action=edit
Test of above with R9 380 with Windows 8.1 and latest AMD drivers
Hi,
After being asked to try this by Ale
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #19 from Robin ---
I've found that my test cases only trigger the PCI drivers'
amdgpu_pci_remove and amdgpu_pci_probe functions.
Adding the new shutdown function call amdgpu_device_shutdown(adev); to the
amdgpu_pci_remove function d
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #20 from Robin ---
Created attachment 133132
--> https://bugs.freedesktop.org/attachment.cgi?id=133132&action=edit
Brute-force fix, resets sdma every init
After much trial and error, I've found this approach to work.
Every hw_init
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #18 from Robin ---
Created attachment 133127
--> https://bugs.freedesktop.org/attachment.cgi?id=133127&action=edit
Logging shutdown function
I've modified the patch to include info messages. The code path is never
executed in my t
https://bugs.freedesktop.org/show_bug.cgi?id=101946
Robin changed:
What|Removed |Added
Summary|Rebinding AMDGPU causes |Rebinding AMDGPU causes
|init
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #17 from Robin ---
I've tested:
- Disabling vfio-pci, no changes
- Disabling iommu support, no changes
- Booting with and without amdgpu blacklisted, no changes
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #16 from Robin ---
(In reply to Alex Deucher from comment #15)
> Are you using a patched qemu that attempts to do radeon device specific gpu
> reset? If so, does removing that code help? Next, are you sure pci config
> access is al
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #15 from Alex Deucher ---
Are you using a patched qemu that attempts to do radeon device specific gpu
reset? If so, does removing that code help? Next, are you sure pci config
access is allowed in your configuration? As I mentione
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #14 from Robin ---
Created attachment 133108
--> https://bugs.freedesktop.org/attachment.cgi?id=133108&action=edit
case3.sh
So, tinkering with the test script I've only been able to eliminate some
suspicions and invalidate my obse
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #13 from Robin ---
(In reply to Alex Deucher from comment #11)
> Note that the GPU reset in patch 3/2 requires access to pci config registers
> for the GPU which many hypervisors block, so you'd need to make sure that
> works for the
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #12 from Robin ---
Created attachment 133103
--> https://bugs.freedesktop.org/attachment.cgi?id=133103&action=edit
case2-rescan-amd.sh
In an attempt to make a second test case I've created a new script that
produced some noteworth
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #11 from Alex Deucher ---
Note that the GPU reset in patch 3/2 requires access to pci config registers
for the GPU which many hypervisors block, so you'd need to make sure that works
for the reset to work.
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #10 from Robin ---
Created attachment 133101
--> https://bugs.freedesktop.org/attachment.cgi?id=133101&action=edit
4.13rc2 ubuntu kern.log
Inspecting the output more closely there's a subtle difference in the error
produced.
Whil
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #9 from Robin ---
Created attachment 133100
--> https://bugs.freedesktop.org/attachment.cgi?id=133100&action=edit
kern.log for drm-next-4.14-wip with patch 3
Same issue with patch3.
I've attached the kern.log of one of the occasi
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #8 from Alex Deucher ---
Created attachment 133099
--> https://bugs.freedesktop.org/attachment.cgi?id=133099&action=edit
possible fix 3/2
Dos using this patch on top of the other two help?
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #7 from Robin ---
Created attachment 133098
--> https://bugs.freedesktop.org/attachment.cgi?id=133098&action=edit
kern.log for drm-next-4.14-wip
Building the drm-next-4.14-wip branch including both patches does not resolve
the iss
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #6 from Robin ---
Thanks for the quick patches! I'm working my way to your kernel branch to rule
out other changes fixing the issue. May take a little bit as I've not had to
build my own kernels before.
Anyway, going from 4.10 to th
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #5 from Alex Deucher ---
Created attachment 133075
--> https://bugs.freedesktop.org/attachment.cgi?id=133075&action=edit
possible fix 2/2
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #4 from Alex Deucher ---
Created attachment 133074
--> https://bugs.freedesktop.org/attachment.cgi?id=133074&action=edit
possible fix 1/2
Do the attached patches help (based on my drm-next-4.14-wip branch)?
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #3 from Robin ---
What I noticed from the kern.log is that it seems to try and skip init steps
the second time amdgpu loads. So perhaps the unbind doesn't do a clean enough
shutdown or there may be a bug in the init step skipping.
F
https://bugs.freedesktop.org/show_bug.cgi?id=101946
Robin changed:
What|Removed |Added
CC||bea...@oscp.info
Version|XOrg git
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #2 from Robin ---
Created attachment 133070
--> https://bugs.freedesktop.org/attachment.cgi?id=133070&action=edit
kern.log
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=101946
--- Comment #1 from Robin ---
Created attachment 133069
--> https://bugs.freedesktop.org/attachment.cgi?id=133069&action=edit
Script output
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=101946
Bug ID: 101946
Summary: Rebinding AMDGPU causes initialization errors [R9 290
/ 4.10 kernel]
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Li
34 matches
Mail list logo
