We have a similar problem: A HD6570(TURKS) card with RS780E chipset. When
booting, DVI output is good, but VGA output is black screen; after X
started, DVI is still good and VGA blinks forever. We have tried
3.4~3.9-rc7 kernel, all kernels after the commit "drm/radeon: properly
handle mc_stop/mc_re
We have a similar problem: A HD6570(TURKS) card with RS780E chipset. When
booting, DVI output is good, but VGA output is black screen; after X
started, DVI is still good and VGA blinks forever. We have tried
3.4~3.9-rc7 kernel, all kernels after the commit "drm/radeon: properly
handle mc_stop/mc_re
https://bugs.freedesktop.org/show_bug.cgi?id=56139
Florian Mickler changed:
What|Removed |Added
CC||florian at mickler.org
--- Comment #25
https://bugs.freedesktop.org/show_bug.cgi?id=56139
Florian Mickler changed:
What|Removed |Added
CC||flor...@mickler.org
--- Comment #25 fr
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #24 from Alexandre Demers ---
I'll retest it with the latest two patches, but I think setting gfxpayload=text
prevents the bug. I know for sure that with the index patch, suspend/resume
cycle is fixed. Also, if I remove gfxpayload=kee
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #23 from Alex Deucher ---
(In reply to comment #19)
> Should I try to combine patch 69113
> and patch 69370 with the others?
Worth a shot.
--
You are receiving this mail because:
You are the assignee for the bug.
-- nex
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #22 from Alexandre Demers ---
(In reply to comment #21)
> (In reply to comment #19)
> > If I followed you correctly, setting bit 24 to "1" disables memory but keeps
> > the CRTC state as it is (hopefully in sync with the monitor). How
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #21 from Alex Deucher ---
(In reply to comment #19)
> If I followed you correctly, setting bit 24 to "1" disables memory but keeps
> the CRTC state as it is (hopefully in sync with the monitor). However, what
> I see when grub2 kicks
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #20 from Alexandre Demers ---
Should I have a look at how grub2 handles and talks to the kernel when using
gfxpayload=keep? A quick search shows this issue has been lurking for some time
(2010) with various radeon card
(https://bugs.l
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #24 from Alexandre Demers ---
I'll retest it with the latest two patches, but I think setting gfxpayload=text
prevents the bug. I know for sure that with the index patch, suspend/resume
cycle is fixed. Also, if I remove gfxpayload=kee
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #23 from Alex Deucher ---
(In reply to comment #19)
> Should I try to combine patch 69113
> and patch 69370 with the others?
Worth a shot.
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #22 from Alexandre Demers ---
(In reply to comment #21)
> (In reply to comment #19)
> > If I followed you correctly, setting bit 24 to "1" disables memory but keeps
> > the CRTC state as it is (hopefully in sync with the monitor). How
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #21 from Alex Deucher ---
(In reply to comment #19)
> If I followed you correctly, setting bit 24 to "1" disables memory but keeps
> the CRTC state as it is (hopefully in sync with the monitor). However, what
> I see when grub2 kicks
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #20 from Alexandre Demers ---
Should I have a look at how grub2 handles and talks to the kernel when using
gfxpayload=keep? A quick search shows this issue has been lurking for some time
(2010) with various radeon card
(https://bugs.l
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #19 from Alexandre Demers ---
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #12)
> > > (In reply to comment #11)
> > > > Found what is wrong with the help of a few printk and by comparing to
> > > > t
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #18 from Alexandre Demers ---
(In reply to comment #16)
> Created attachment 69573 [details] [review]
> possible fix
>
> Actually, I think I found the problem. Missing index in mc_resume().
This seems to fix my resume problem I was
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #17 from Alexandre Demers ---
I'm about to test patches. But before, as promised, here are the values
retrieved read and written to the registers. By the way, I have only a single
monitor.
tmp = RREG32(EVERGREEN_CRTC_CONTROL + crtc_of
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #19 from Alexandre Demers ---
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #12)
> > > (In reply to comment #11)
> > > > Found what is wrong with the help of a few printk and by comparing to
> > > > t
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #16 from Alex Deucher ---
Created attachment 69573
--> https://bugs.freedesktop.org/attachment.cgi?id=69573&action=edit
possible fix
Actually, I think I found the problem. Missing index in mc_resume().
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #18 from Alexandre Demers ---
(In reply to comment #16)
> Created attachment 69573 [details] [review]
> possible fix
>
> Actually, I think I found the problem. Missing index in mc_resume().
This seems to fix my resume problem I was
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #15 from Alex Deucher ---
(In reply to comment #14)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > Found what is wrong with the help of a few printk and by comparing to the
> > > code being replaced. All the logic is
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #14 from Alexandre Demers ---
(In reply to comment #12)
> (In reply to comment #11)
> > Found what is wrong with the help of a few printk and by comparing to the
> > code being replaced. All the logic is good (going through crtc, disa
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #17 from Alexandre Demers ---
I'm about to test patches. But before, as promised, here are the values
retrieved read and written to the registers. By the way, I have only a single
monitor.
tmp = RREG32(EVERGREEN_CRTC_CONTROL + crtc_of
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #13 from Alex Deucher ---
Created attachment 69564
--> https://bugs.freedesktop.org/attachment.cgi?id=69564&action=edit
possible fix
Slightly adjusted wait for vblank function. Maybe this will help?
--
You are receiving this mai
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #12 from Alex Deucher ---
(In reply to comment #11)
> Found what is wrong with the help of a few printk and by comparing to the
> code being replaced. All the logic is good (going through crtc, disabling
> them, waiting for vblank) BU
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #16 from Alex Deucher ---
Created attachment 69573
--> https://bugs.freedesktop.org/attachment.cgi?id=69573&action=edit
possible fix
Actually, I think I found the problem. Missing index in mc_resume().
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #15 from Alex Deucher ---
(In reply to comment #14)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > Found what is wrong with the help of a few printk and by comparing to the
> > > code being replaced. All the logic is
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #11 from Alexandre Demers ---
Found what is wrong with the help of a few printk and by comparing to the code
being replaced. All the logic is good (going through crtc, disabling them,
waiting for vblank) BUT setting "tmp |=
EVERGREEN_
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #14 from Alexandre Demers ---
(In reply to comment #12)
> (In reply to comment #11)
> > Found what is wrong with the help of a few printk and by comparing to the
> > code being replaced. All the logic is good (going through crtc, disa
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #13 from Alex Deucher ---
Created attachment 69564
--> https://bugs.freedesktop.org/attachment.cgi?id=69564&action=edit
possible fix
Slightly adjusted wait for vblank function. Maybe this will help?
--
You are receiving this mai
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #12 from Alex Deucher ---
(In reply to comment #11)
> Found what is wrong with the help of a few printk and by comparing to the
> code being replaced. All the logic is good (going through crtc, disabling
> them, waiting for vblank) BU
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #11 from Alexandre Demers ---
Found what is wrong with the help of a few printk and by comparing to the code
being replaced. All the logic is good (going through crtc, disabling them,
waiting for vblank) BUT setting "tmp |=
EVERGREEN_
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #10 from Alexandre Demers ---
The good news is: the code under resume() is not to be blamed for the lock
after coming back from suspend.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next p
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #10 from Alexandre Demers ---
The good news is: the code under resume() is not to be blamed for the lock
after coming back from suspend.
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #9 from Alexandre Demers ---
(In reply to comment #8)
> Created attachment 69370 [details] [review]
> possible fix
>
> (In reply to comment #7)
> > Alex, would it be possible to print what is going on or if an error occurred
> > in e
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #8 from Alex Deucher ---
Created attachment 69370
--> https://bugs.freedesktop.org/attachment.cgi?id=69370&action=edit
possible fix
(In reply to comment #7)
> Alex, would it be possible to print what is going on or if an error occu
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #7 from Alexandre Demers ---
Alex, would it be possible to print what is going on or if an error occurred in
evergreen_mc_stop()?
I see four things that could be going on:
1- we are not using the right path for CAYMAN -> (ASIC_IS_DCE
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #9 from Alexandre Demers ---
(In reply to comment #8)
> Created attachment 69370 [details] [review]
> possible fix
>
> (In reply to comment #7)
> > Alex, would it be possible to print what is going on or if an error occurred
> > in e
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #8 from Alex Deucher ---
Created attachment 69370
--> https://bugs.freedesktop.org/attachment.cgi?id=69370&action=edit
possible fix
(In reply to comment #7)
> Alex, would it be possible to print what is going on or if an error occu
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #7 from Alexandre Demers ---
Alex, would it be possible to print what is going on or if an error occurred in
evergreen_mc_stop()?
I see four things that could be going on:
1- we are not using the right path for CAYMAN -> (ASIC_IS_DCE
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #6 from Alexandre Demers ---
(In reply to comment #5)
> Created attachment 69113 [details] [review]
> possible fix
>
> (In reply to comment #4)
> > the bug appeared. So it seems blanking the display controllers with for(i =
> > 0; i
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #6 from Alexandre Demers ---
(In reply to comment #5)
> Created attachment 69113 [details] [review]
> possible fix
>
> (In reply to comment #4)
> > the bug appeared. So it seems blanking the display controllers with for(i =
> > 0; i
https://bugs.freedesktop.org/show_bug.cgi?id=56139
Alex Deucher changed:
What|Removed |Added
Attachment #68760|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=56139
Alex Deucher changed:
What|Removed |Added
Attachment #68760|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #4 from Alexandre Demers ---
First, I made a mistake last time I wrote: the evergreen_mc_resume() function
patch was fine. The bad code was in the evergreen_mc_stop() function. Sorry for
the wrong lead, I realized it today when I cont
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #4 from Alexandre Demers ---
First, I made a mistake last time I wrote: the evergreen_mc_resume() function
patch was fine. The bad code was in the evergreen_mc_stop() function. Sorry for
the wrong lead, I realized it today when I cont
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #3 from Alexandre Demers ---
So, I went further and I split commit 62444b in 3 patches. On for the register
values, one for the stop function and one for the resume function. I applied
the first and the second patches for now and it s
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #3 from Alexandre Demers ---
So, I went further and I split commit 62444b in 3 patches. On for the register
values, one for the stop function and one for the resume function. I applied
the first and the second patches for now and it s
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #2 from Alexandre Demers ---
(In reply to comment #1)
> Created attachment 68760 [details] [review]
> possible fix
>
> Does this patch help?
Applied suggested patch on top of 62444b7462a2b98bc78d68736c03a7c4e66ba7e2 and
it doesn't f
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #2 from Alexandre Demers ---
(In reply to comment #1)
> Created attachment 68760 [details] [review]
> possible fix
>
> Does this patch help?
Applied suggested patch on top of 62444b7462a2b98bc78d68736c03a7c4e66ba7e2 and
it doesn't f
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #1 from Alex Deucher ---
Created attachment 68760
--> https://bugs.freedesktop.org/attachment.cgi?id=68760&action=edit
possible fix
Does this patch help?
--
You are receiving this mail because:
You are the assignee for the bug.
-
https://bugs.freedesktop.org/show_bug.cgi?id=56139
Alexandre Demers changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #1 from Alex Deucher ---
Created attachment 68760
--> https://bugs.freedesktop.org/attachment.cgi?id=68760&action=edit
possible fix
Does this patch help?
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=56139
Alexandre Demers changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
54 matches
Mail list logo
