https://bugzilla.kernel.org/show_bug.cgi?id=90741
Julien Isorce (julien.iso...@gmail.com) changed:
What|Removed |Added
CC||julien.iso...@gma
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #79 from Maarten Lankhorst ---
Yeah all patches are obsolete except attachment 166571 and the posting read
patches..
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #78 from Dieter Nützel ---
(In reply to Gustaw Smolarczyk from comment #77)
> No pauses after I applied attachment 166571 [details] and "drm/radeon: do a
> posting read in si_set_irq" from posting-read branch on top of v3.19. So I
> g
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #77 from Gustaw Smolarczyk ---
No pauses after I applied attachment 166571 and "drm/radeon: do a posting read
in si_set_irq" from posting-read branch on top of v3.19. So I guess these
commits combined fix this issue.
@Dieter: I did no
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Dieter Nützel changed:
What|Removed |Added
CC||Dieter at nuetzel-hh.de
--- Comment #76
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #75 from Maarten Lankhorst ---
Michel, enabling irqs before checking the fence signaling was exactly what I
was doing already, I'm hoping the attachment plus the branch is enough. :)
--
You are receiving this mail because:
You are wa
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #74 from Alex Deucher ---
posting reads implemented here:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=posting-read
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #73 from Michel Dänzer ---
(In reply to Alex Deucher from comment #72)
> Does reading any arbitrary register also work? E.g., SRBM_STATUS
I think that would indeed be the right thing to do here, to prevent the PCIe
bridge from delay
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #72 f
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #71 from Maarten Lankhorst ---
Thanks for helping investigate, I will send the attachment as a bugfix to bug
90861, that bug is specifically about the waitqueue ordering in
radeon_fence_default_wait. That one was really caused by me.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #70 from Gustaw Smolarczyk ---
mb(); is ok.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #69 from Maarten Lankhorst ---
Hm full mb(); ?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #68 from Gustaw Smolarczyk ---
rmb(); doesn't seem to be enough.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #67 from Maarten Lankhorst ---
what about a rmb(); there instead?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #66 from Gustaw Smolarczyk ---
It seems that way. I hope others can check that too.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #65 from Maarten Lankhorst ---
So attachment 166571 and the rreg32 addition is enough?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #64 from Gustaw Smolarczyk ---
Yes, the fix still works.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #63 from Maarten Lankhorst ---
What about changing the udelay to a RREG32(DMA_CNTL + DMA0_REGISTER_OFFSET); ?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #62 from Gustaw Smolarczyk ---
Even 1us works.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #61 from Gustaw Smolarczyk ---
5us is ok.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #60 from Maarten Lankhorst ---
can you add a if (fence->ring == R600_RING_TYPE_DMA_INDEX) udelay(50); to
radeon_fence_enable_signaling? after the irq_get again. If that works try
udelay(5), if it doesn't udelay(500) ?
--
You are rece
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #59 from Maarten Lankhorst ---
I was afraid of that, that's the ring used for eviction.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #58 from Gustaw Smolarczyk ---
This patch doesn't help.
I have been experimenting with forcing interrupts on only some rings. In the
end I have found that by adding "|| 1" only to R600_RING_TYPE_DMA_INDEX ring I
have removed the pause
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #57 from Gustaw Smolarczyk ---
Will try when I return home.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Maarten Lankhorst changed:
What|Removed |Added
Attachment #168571|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #55 from Maarten Lankhorst ---
Do you happen to know if it's DMA or DMA1?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #54 from Maarten Lankhorst ---
Just look if there's some output in dmesg or not.
To verify, only having interrupts enabled on the DMA conditions fixes your bug?
--
You are receiving this mail because:
You are watching the assignee o
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #53 from Gustaw Smolarczyk ---
At first, I added "|| 1" only to GFX, CP1 and CP2 (I omitted the two DMA
conditions). This did NOT fix the pauses.
However, after converting these final two DMA conditions, the pauses are gone.
Reverting
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #52 from Maarten Lankhorst ---
Yes, and also add a WARN_ON(!rdev->ih.enabled); to
radeon_fence_enable_signaling, just to be thorough..
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #51 from Gustaw Smolarczyk ---
Should I apply it on top of attachment 166571?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #50 from Maarten Lankhorst ---
Ok never mind that approach then..
in radeon_fence.c, add a
WARN_ON((int)atomic_read(&rdev->irq.ring_int[fence->ring]) <= 0); after the
sw_irq_get, it should never fire.
in si.c you have a few lines lik
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #49 from Gustaw Smolarczyk ---
(had to remove "robj->" from the patch).
Doesn't help.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #48 from Maarten Lankhorst ---
Created attachment 168571
--> https://bugzilla.kernel.org/attachment.cgi?id=168571&action=edit
flush hdp harder
No idea if this does anything, adding a bunch of flushes instead of doing a
sleep.. pause
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #47 from Gustaw Smolarczyk ---
With 500us delay, the performance is nearly back to how it was (~70fps). And
the pauses are still gone.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #46 from Maarten Lankhorst ---
Ok what about udelay(500), should be a smaller pause?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #45 from Gustaw Smolarczyk ---
(In the end I had to use mdelay(50))
The performance was really traumatic (8-11fps). But on a positive side, there
seemed to be no pauses. There was one moment when fps dropped to 0 (for ~1/3 of
a second
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #44 from Gustaw Smolarczyk ---
I think you meant udelay(5). (I just used msleep(50) and got a nice lock-up
since the call was in an atomic context).
Just a sec.
--
You are receiving this mail because:
You are watching the assign
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #43 from Maarten Lankhorst ---
After applying attachment 166571 can you add a usleep(5); in
radeon_fence_enable_signaling after the line "radeon_irq_kms_sw_irq_get(rdev,
fence->ring);" but before the line "if (radeon_fence_activity
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Damien Grassart changed:
What|Removed |Added
CC||damien at grassart.com
--- Comment #42
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #41 from Gustaw Smolarczyk ---
Unfortunately, still no good.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #40 from Maarten Lankhorst ---
It replaces the previous attempts to fix the bug.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #39 from Gustaw Smolarczyk ---
Should I apply it on top of 3.19.0? Or is it an extension of some previous
patch?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Maarten Lankhorst changed:
What|Removed |Added
Attachment #164141|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #37 from Maarten Lankhorst ---
Never mind, that won't matter much..
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #36 from Maarten Lankhorst ---
Ugh.. can you test "another approach" again, but change the list_add to
list_add_tail ? Looks like I messed it up there..
--
You are receiving this mail because:
You are watching the assignee of the bug
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Jon Arne Jørgensen changed:
What|Removed |Added
Attachment #165901|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #34 from Jon Arne Jørgensen ---
Created attachment 165901
--> https://bugzilla.kernel.org/attachment.cgi?id=165901&action=edit
dmesg with refcount on sw irq
Hi, Maarten I finaly got around to append the patch you posted in comment
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #33 from Gustaw Smolarczyk ---
Created attachment 165161
--> https://bugzilla.kernel.org/attachment.cgi?id=165161&action=edit
dmesg after disabling radeon_fence_schedule_check()
I chose to leave the refcount printing patch as it is.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #32 from Maarten Lankhorst ---
You can keep print refcounts or remove it, it doesn't matter much either way. I
just want to have at least 'another approach' applied.
--
You are receiving this mail because:
You are watching the assign
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #31 from Gustaw Smolarczyk ---
Do you mean on top of the latest patch?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #30 from Maarten Lankhorst ---
Can you empty the contents of the radeon_fence_schedule_check function in
radeon_fence.c?
It should make the pauses worse, giving me a chance to find them in the log.
:-)
--
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #29 from Maarten Lankhorst ---
Thanks, that rules out 1 possibility. There is probably no bug in refcounting
irqs. :P
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #28 from Gustaw Smolarczyk ---
Created attachment 165091
--> https://bugzilla.kernel.org/attachment.cgi?id=165091&action=edit
dmesg after "Print refcounts..." patch
I have applied this patch on top of original "another approach" one
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #27 from Maarten Lankhorst ---
Created attachment 165071
--> https://bugzilla.kernel.org/attachment.cgi?id=165071&action=edit
Print refcounts on sw irq, panic on disabled.
Can you test this patch on top of 'another approach', keep t
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #26 from Jon Arne Jørgensen ---
I've tested, and can confirm that they are needed for the patch to fix the
crash.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #25 from Maarten Lankhorst ---
Oke, can you test without the calls to sw_irq_get/put?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #24 from Jon Arne Jørgensen ---
I just commented out the trace_fence_enable_signal call to get it to compile.
Figured I don't need the tracepoint debug to test the patch.
I also uncommented the sw_irq_get and sw_irq_put calls, and ca
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #23 from Jon Arne Jørgensen ---
@Gustaw:
~/Development/c/kernel/src% git describe --long --tags
v3.19-rc5-0-gec6f34e
So, that should be 3.19-rc5 :)
--
You are receiving this mail because:
You are watching the assi
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #22 from Gustaw Smolarczyk ---
@Maarten Lankhorst
The "Clear irqs..." patch doesn't seem to help.
Also, the WARN_ON_ONCE() doesn't seem to be hit (I have added
'WARN_ON_ONCE(1);' in the else block). The dmesg doesn't have anything re
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Jon Arne Jørgensen changed:
What|Removed |Added
CC||jonjon.arnearne at gmail.com
--- Co
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #20 from Gustaw Smolarczyk ---
I will try that on Sunday since I have no access to the radeonsi hardware at
the moment.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #19 from Maarten Lankhorst ---
Created attachment 164511
--> https://bugzilla.kernel.org/attachment.cgi?id=164511&action=edit
Clear irqs before processing.. Patch on top of 'another approach'
Can you try with the irq_put/get lines c
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #18 from Gustaw Smolarczyk ---
Only the second version (with the 2 lines uncommented) of the new patch does
fix the problem.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #17 from Maarten Lankhorst ---
Created attachment 164421
--> https://bugzilla.kernel.org/attachment.cgi?id=164421&action=edit
Another approach
Don't need to test anything but final version, can you test this version
though? I want t
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #16 from Gustaw Smolarczyk ---
Unfortunately, the last patch doesn't seem to help in any way. Should I test
the other two too?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Maarten Lankhorst changed:
What|Removed |Added
Attachment #164131|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Maarten Lankhorst changed:
What|Removed |Added
Attachment #164121|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Maarten Lankhorst changed:
What|Removed |Added
Attachment #163871|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #12 from Gustaw Smolarczyk ---
This hack, when applied on top of 3.19-rc5, seems to fix the problem.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #11 from Maarten Lankhorst ---
Created attachment 163871
--> https://bugzilla.kernel.org/attachment.cgi?id=163871&action=edit
Restore old fence wait behavior
Ok the only difference I can see is the fence wait function being differen
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #10 from Christian König ---
(In reply to Gustaw Smolarczyk from comment #9)
> Created attachment 162601 [details]
> /proc/interrupts on 3.17.4
>
> I have attached the contents of /proc/interrupts on 3.17.4. Should I attach
> one wit
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #9 from Gustaw Smolarczyk ---
Created attachment 162601
--> https://bugzilla.kernel.org/attachment.cgi?id=162601&action=edit
/proc/interrupts on 3.17.4
I have attached the contents of /proc/interrupts on 3.17.4. Should I attach one
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Christian König changed:
What|Removed |Added
CC||deathsimple at vodafone.de
--- Comment
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #7 from Gustaw Smolarczyk ---
Unfortunately, it was a false lead. Disabling iGPU didn't help in any way on
3.18.1.
Additionally, I take back the "less pauses in 3.18.0 and later" thing. 3.18.1
was horrible just now (same as any kernel
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #6 from Maarten Lankhorst ---
I think that right now i915 doesn't use the fence stuff yet so it's probably
not causing the problem, still it would be useful to check.
--
You are receiving this mail because:
You are watching the assig
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #5 from Michel Dänzer ---
(In reply to Gustaw Smolarczyk from comment #4)
> If that may be the source of these problems, I could disable the second
> monitor along with the iGPU in order to test that hypothesis.
That would be interes
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #4 from Gustaw Smolarczyk ---
There seems to be no substantial difference in 3.19-rc2,
39e7f6f84b3a3aa4520504473f2e2bac1f949ffa or
472db7ab3093bf2a2999f6b5aa64a030466d6f92.
The only thing (that may be subjective) is that there seems t
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Maarten Lankhorst changed:
What|Removed |Added
CC||bugs at mblankhorst.nl
--- Comment #3
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #2 from Michel Dänzer ---
Does it still happen with a 3.19-rc kernel?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #1 from Gustaw Smolarczyk ---
I have managed to bisect this regression:
f2c24b83ae90292d315aa7ac029c6ce7929e01aa is the first bad commit
commit f2c24b83ae90292d315aa7ac029c6ce7929e01aa
Author: Maarten Lankhorst
Date: Wed Apr 2 17:1
80 matches
Mail list logo
