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
19 matches
Mail list logo
