https://bugs.freedesktop.org/show_bug.cgi?id=91880
GitLab Migration User changed:
What|Removed |Added
Resolution|--- |MOVED
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #210 from emilio.more...@gmail.com ---
(In reply to Sandeep from comment #209)
> Created attachment 141193 [details]
> attachment-13440-0.html
>
> Try removing the amdgpu.dc=1 kernel parameter. Might be causing problems.
> If not,
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #211 from Filip Brygidyn ---
Thank you for fixing this, I wanted to report that in my case enabling DC does
not seem to cause any issues.
I am running amdgpu (no 'amdgpu pro' drivers on top) with following params:
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #209 from Sandeep ---
Try removing the amdgpu.dc=1 kernel parameter. Might be causing problems.
If not, then it's a bug in the driver.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #208 from emilio.more...@gmail.com ---
(In reply to emilio.moretti from comment #207)
> (In reply to Sandeep from comment #206)
> > You've got to make sure that radeon and amdgpu drivers don't clash.
> >
> > Try the following kernel
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #207 from emilio.more...@gmail.com ---
(In reply to Sandeep from comment #206)
> You've got to make sure that radeon and amdgpu drivers don't clash.
>
> Try the following kernel parameters: radeon.si_support=0
> radeon.cik_support=0
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #206 from Sandeep ---
You've got to make sure that radeon and amdgpu drivers don't clash.
Try the following kernel parameters: radeon.si_support=0 radeon.cik_support=0
amdgpu.si_support=1 amdgpu.cik_support=1 amdgpu.dpm=1
That's
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #205 from emilio.more...@gmail.com ---
kernel >4.17 did NOT work.
It didn't hang while using the PC, but it did freeze when the power management
tried to power off my both monitors. One of them was successfully powered off,
while the
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #204 from tkdestroyer2+bugs-freedesk...@gmail.com ---
(In reply to iburnth3playb00k from comment #203)
> (In reply to chris from comment #188)
> > I suffered pretty much all of the issue listed in this thread for many weeks
> > since
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #203 from iburnth3playb00k ---
(In reply to chris from comment #188)
> I suffered pretty much all of the issue listed in this thread for many weeks
> since upgrading to 3 1440p monitors.
>
> I have an Club 3D R9 390 Royal Queen.
>
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #202 from Ioannis Panagiotopoulos ---
Can confirm that worked with kernel 4.16.7-300 on Fedora 28 Gnome with wayland
and the right boot arguments. However this worked when I had the R9 390
installed alone.
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #201 from heavy...@web.de ---
(In reply to Sandeep from comment #200)
> You can probably ignore the warnings, I get them too and nothing bad has
> happened so far. As long as GPU hang doesn't occur, it's all good.
Thanks for the
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #200 from Sandeep ---
You can probably ignore the warnings, I get them too and nothing bad has
happened so far. As long as GPU hang doesn't occur, it's all good.
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=91880
heavy...@web.de changed:
What|Removed |Added
Status|REOPENED|NEEDINFO
--- Comment #199 from
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #198 from Jon Doane ---
I would like to add that the problem appears to be resolved on my installation
of Ubuntu 18.04 with the MSI R9 390 8GB GAMING GPU using the current mainline
kernel (4.17-rc4,) with the
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #197 from Sandeep ---
Anyway, thanks for fixing the bug, AMD devs! (or whoever else did it).
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #196 from Sandeep ---
Ah, I didn't know that. I thought it just disabled/enabled dpm...well,
it works so that's good.
It would be great if it worked out of the box though, without having to add
kernel
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #195 from Alex Deucher ---
(In reply to Sandeep from comment #194)
> So, I had never used amdgpu.dc=1 and amdgpu.dpm=1 kernel parameters when
> testing earlier.
>
> I tried using them now, with the 4.16.7
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #194 from Sandeep ---
So, I had never used amdgpu.dc=1 and amdgpu.dpm=1 kernel parameters when
testing earlier.
I tried using them now, with the 4.16.7 kernel, and replayed the APItrace file.
No crashes!
https://bugs.freedesktop.org/show_bug.cgi?id=91880
no...@amail.club changed:
What|Removed |Added
Resolution|WORKSFORME |---
Status|RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #192 from Sandeep ---
I tested with the APItrace file that I uploaded, still broken on 4.16.7 .
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #191 from no...@amail.club ---
I did some more testing this time with Arch Linux, I started with kernel
4.16.6-1, and went back two months, one month at a time using the Arch Linux
Archive. I never ran into an issue.
It would seem
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #190 from no...@amail.club ---
With 4.16.6, it seems to be fixed!
With a fresh installation of Antergos 18.4, tested with different kernel
arguments, `radeon.cik_support=0 amdgpu.cik_support=1 amdgpu.dpm=1` is all
that's needed to
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #189 from tkdestroyer2+bugs-freedesk...@gmail.com ---
I tried what chris suggested, and it worked up until the point at which some X
session closes (right after login or after exiting basic xterm test session),
where the system locks
https://bugs.freedesktop.org/show_bug.cgi?id=91880
chrisg_...@hotmail.com changed:
What|Removed |Added
Resolution|--- |WORKSFORME
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #187 from Lauri Gustafsson ---
About "I can force a system hard-lock by doing anything which disables a
monitor", on my system it used to crash more frequently the less desktop area I
had. Small resolution monitor
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #186 from Chris Heald ---
I've been doing a lot of experimentation, and I've found a few more things that
I feel are probably related:
* I can force a system hard-lock by doing anything which disables a monitor.
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #185 from Sandeep ---
I have that display/corruption issue too, on the XFX R9 390.
Usually happens after suspend/resume. Will test if it gets fixed with above
steps.
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #184 from Chris Heald ---
Created attachment 138059
--> https://bugs.freedesktop.org/attachment.cgi?id=138059=edit
dmesg output
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=91880
Chris Heald changed:
What|Removed |Added
CC||che...@gmail.com
---
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #182 from Chris Heald ---
Just adding a data point here, I've got an MSI R9 390 running on Ubuntu 18.04
on 4.15.0-10-generic - I haven't had any stability issues, but I have had
maddening screen
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #181 from Sandeep ---
I was able to reliably reproduce the bug with openarena on my XFX R9 390 -
here's a link to a trace file (1.8 GB) -
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #180 from x...@amail.club ---
>From watching this bug progress over the last two years and not really
improving, I guess this problem is never going to get fixed, at least not too
soon.
>From my testing last year, it would seem that
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #179 from Thomas DEBESSE ---
Andrea Zanoni, can you print the output of this command?
lspci -nn | grep VGA
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #178 from Andrea Zanoni ---
I have the same issues with an MSI R9 390 running on a MSI Z170A GAMING M5
motherboard.
The only way I can even use the card, avoiding constant black screens and os
lockup, is to
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #177 from garththei...@hotmail.com ---
Created attachment 134324
--> https://bugs.freedesktop.org/attachment.cgi?id=134324=edit
dmesg capture
Logged this problem against 4.13.2. Started up an accelerated program (game)
and with in
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #176 from Jon Doane ---
(In reply to Thomas DEBESSE from comment #175)
> (In reply to Alex Deucher from comment #174)
> > (In reply to Thomas DEBESSE from comment #173)
> > >
> > > Their AMDGPU-PRO driver looks to
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #175 from Thomas DEBESSE ---
(In reply to Alex Deucher from comment #174)
> (In reply to Thomas DEBESSE from comment #173)
> >
> > Their AMDGPU-PRO driver looks to not be affected by the bug, so they have a
> >
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #174 from Alex Deucher ---
(In reply to Thomas DEBESSE from comment #173)
>
> Their AMDGPU-PRO driver looks to not be affected by the bug, so they have a
> fix somewhere. Why this fix can't make it's way to
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #173 from Thomas DEBESSE ---
(In reply to Jon Doane from comment #172)
> Unless something has changed with how the dpm state is handled, I don't
> expect that to make the system completely stable. They're more
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #172 from Jon Doane ---
(In reply to Thomas DEBESSE from comment #171)
> > This sounds a lot like what I've been doing manually which sounds nice.
> > Thanks for the input. I honestly would like a solution that
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #171 from Thomas DEBESSE ---
> This sounds a lot like what I've been doing manually which sounds nice.
> Thanks for the input. I honestly would like a solution that doesn't cause my
> machine to draw an additional
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #170 from Jon Doane ---
(In reply to Stefan from comment #160)
> Jon Doane, to alleviate your pains, set radeon.dpm=0 as a boot option.
Crippling GPU performance is not a solution and doesn't alleviate pains
https://bugs.freedesktop.org/show_bug.cgi?id=91880
Thomas DEBESSE changed:
What|Removed |Added
Attachment #134125|0 |1
is
https://bugs.freedesktop.org/show_bug.cgi?id=91880
Thomas DEBESSE changed:
What|Removed |Added
Attachment #134124|0 |1
is
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #167 from Thomas DEBESSE ---
Created attachment 134124
--> https://bugs.freedesktop.org/attachment.cgi?id=134124=edit
kernel patch: set "high" default DPM profile instead of "auto" for 0x67B1
variant
So, using
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #166 from garththei...@hotmail.com ---
As does mine, my dmesg ...
[drm] initializing kernel modesetting (HAWAII 0x1002:0x67B1 0x1682:0x9390
0x80).
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #165 from Thomas DEBESSE ---
Note that all joined dmesg reports a HAWAII 0x1002:0x67B1 PCI ID except mine
reporting a HAWAII 0x1002:0x67B0 PCI ID (I also checked the dmesg joined in
duplicates of this bug). So the
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #164 from Thomas DEBESSE ---
(In reply to Jon Doane from comment #159)
> I've literally been doing:
> "echo high > /sys/class/device/drm/card0/power_dpm_force_performance_level"
> every day to boot my machine for
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #163 from Thomas DEBESSE ---
> It seems tied to a small subset of 390s.
Many precise models were listed. It's easy to get one of them.
For example this one is known to be buggy:
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #162 from Chris Waters ---
One of the issues I've seen mentioned by one of the AMD guys on Reddit
(/u/bridgmanAMD) is that they have been unable to reproduce the issue. It
seems tied to a small subset of
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #161 from garththei...@hotmail.com ---
Not sure how well a bug bounty might work for this issue, but would there be
any interest? Maybe a fund for hardware purchase (R9 390) to send to someone
with the expertise to diagnose/fix work
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #160 from Stefan ---
Jon Doane, to alleviate your pains, set radeon.dpm=0 as a boot option.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #159 from Jon Doane ---
Is there going to be any work on this? I've literally been doing:
"echo high > /sys/class/device/drm/card0/power_dpm_force_performance_level"
every day to boot my machine for over a year
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #158 from janweber...@gmail.com ---
asus strix 390 owner.
gentoo kernel 4.12.3 and amdgpu 1.3.0.
get crash after 10-30seconds dwm.
only think that helps: "echo high >
/sys/class/device/drm/card0/power_dpm_force_performance_level"
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #157 from j...@dev1ce.com ---
https://bugs.freedesktop.org/show_bug.cgi?id=101377
this has been open for about a month with no activity.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #156 from John Bridgman ---
#155 sounds like a completely different problem - j...@dev1ce.com can you
please start a new ticket ? Please indicate in that ticket whether this is a
regression (worked before,
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #155 from j...@dev1ce.com ---
Running a gigabyte AMD R9 380 card and getting similar problems.
the system boots, loads the driver and the fans briefly spin to 100% before the
video goes completely dark and the monitor turns off. the
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #154 from gsc_m...@yahoo.com ---
R9 390 owner here. Just replaced my old Ubuntu 14.04 + fglrx with Fedora 25,
then 26 + Mesa and hit this problem as well. It took me a lot of fiddling and
searching to understand why my 3 years newer
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #153 from garththei...@hotmail.com ---
I too have toggled my TPD switch (XFX R9 390) and continue to get black screen
freeze at non-deterministic times with a non-stressful workload. Running 4.11.1
with the latest git firmware
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #152 from Alfredo Mendez ---
(In reply to Marek Olšák from comment #151)
> Alfredo, did you try to switch the TDP switch on the side of the card?
Yeah, and the system eventually was hit with a blackscreen.
--
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #151 from Marek Olšák ---
Alfredo, did you try to switch the TDP switch on the side of the card?
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #150 from Alfredo Mendez ---
I have an ASUS Strix R9 390 and attempted to get it to work, in a nutshell for
those looking for redemption... it didn't work.
I tried to switch drivers from radeon to amdgpu, and
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #149 from alvarex ---
I forgot to mention I had a similar problem on Windows also with a 260x on the
same motherboard so I think in my case is something to do with the motherboard.
I tried modyfing some
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #148 from alvarex ---
(In reply to Chris Waters from comment #133)
> I decided to record how my system behaves when using Linux and my 390
> together.
>
> This is what I see
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #147 from John Boero ---
Would love to see this get pushed through. Frustrating having to manually
build kernels each release. It looks like history of the Fedora kernels has
this being disabled and re-enabled
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #146 from Marek Olšák ---
All Hawaii cards should have a TDP switch on the side of the card. Can you flip
the switch when the computer is powered off and do the testing again. You can
google some info about that
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #145 from Harald Judt ---
You are certainly right and the files differ, so I assume it could be a problem
with the firmware. But since amdgpu works fine for me now, I will simply use
this and bother no longer.
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #144 from Michel Dänzer ---
(In reply to Harald Judt from comment #143)
> With radeon, DPM still fails to resume properly for the 390 after hibernation.
Make sure the bonaire_uvd.bin firmware file is up to date, see bug 98988.
--
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #143 from Harald Judt ---
I have merged
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.10-wip into 4.9 and
am now using amdgpu with the r9 390, and everything works great so far except
that the cursor is no longer
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #142 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> ---
(In reply to Chris Waters from comment #141)
> At what point did we go from talking about radeon, the driver this bug
> report is about, to amdgpu?
This freedesktop.org bug is a
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #141 from Chris Waters ---
At what point did we go from talking about radeon, the driver this bug report
is about, to amdgpu?
Isn't support and performance for GCN 1.1 cards rather bad on amdgpu compared
to radeon?
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #140 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> ---
(In reply to Chris Waters from comment #139)
> Tried Manjaro and an install of Ubuntu MATE with a ppa for mesa-git drivers.
> No pp_dpm_sclk in either.
>
> Am I missing something?
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #139 from Chris Waters ---
Tried Manjaro and an install of Ubuntu MATE with a ppa for mesa-git drivers. No
pp_dpm_sclk in either.
Am I missing something?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #138 from Chris Waters ---
Update:
Finally had time to boot a liveCD (Ubuntu MATE 16.10) and try this all out.
I have multiple card listings in /sys/class/drm, but only one that is a card#
folder (ie card0), the rest are all
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #137 from Thomas DEBESSE ---
(In reply to Chris Waters from comment #136)
> Can this be done without rebooting? I'd like to test this on a liveCD
> since, as I've said, I'm currently stuck on Windows. The idea of needing to
>
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #136 from Chris Waters ---
Can this be done without rebooting? I'd like to test this on a liveCD since,
as I've said, I'm currently stuck on Windows. The idea of needing to install a
distro just to test this is a bit unappealing to
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #135 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> ---
(In reply to Jan Ziak from comment #134)
> (In reply to Chris Waters from comment #133)
> > I decided to record how my system behaves when using Linux and my 390
> > together.
> >
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #134 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> ---
(In reply to Chris Waters from comment #133)
> I decided to record how my system behaves when using Linux and my 390
> together.
>
> This is what I see
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #133 from Chris Waters ---
I decided to record how my system behaves when using Linux and my 390 together.
This is what I see https://www.youtube.com/watch?v=9uVIzHFlTZk
This is Ubuntu MATE 16.10 with Firefox open¹, something that
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #132 from Filip Brygidyn
---
I am experiecing the same freezes on my updated arch box (kernel 4.8.11-2, mesa
13.0.2-2) with my MSI R9 390.
Without radeon.dpm=0 I observe the following:
- I
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #131 from Harald Judt ---
I do not have problems so far except there are sometimes red pixels flickering
on screen. Still need to investigate why that happens.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #130 from Chris Waters ---
This bug has been marked as 'critical' for over a month now, has there been any
work on this in that time?
The bug seems related to the shader clock, possibly the driver isn't setting
correct values? Has
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #129 from Chris Waters ---
> If I disable the lowest 300 MHz shader clock, so that the minimum shader
> clock is 500 MHz and maximum is 1000 MHz, the flickering disappears.
What about lower settings than 500 MHz? Did you try 400
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #128 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> ---
(In reply to Chris Waters from comment #127)
> Second question, is there any way to just force the memory clock to stay at
> 1500MHz? If the bug is caused by memory switching (and
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #127 from Chris Waters ---
I've noticed that on my Win7 install if I up the memory clock a good (1700MHz+)
bit I'll get the same exact artifacts as I would in Linux. Maybe the driver is
trying to switch to too high of a clock for
https://bugs.freedesktop.org/show_bug.cgi?id=91880
Jan Ziak <0xe2.0x9a.0x9b at gmail.com> changed:
What|Removed |Added
Severity|major |critical
---
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #125 from Christoph Seifert
---
For me switching power states does also result in a system freeze. With
radeon.dpm = 0 everthing is working properly but slowly. If I switch manually
to another power profile (e.g. echo high >
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #124 from mail at marcelschaal.de ---
Created attachment 127648
--> https://bugs.freedesktop.org/attachment.cgi?id=127648=edit
PowerColor R9 390 PCS+ vbios
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #123 from mail at marcelschaal.de ---
Still no luck with PowerColor R9 390 PCS+ on Fedora 25 (Kernel 4.8, mesa
12.0.3). Computer freezes after a few seconds. It seems to last a bit longer
with dpm=0, but less than 5-10 minutes.
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #122 from Lauri Gustafsson ---
Seconded that 4.8 kernel on Arch has fixed the unstability. Still getting
rather bad artifacts from time to time because of the dynamic memory clock.
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #121 from emilio.moretti at gmail.com ---
Finally working:
I just upgraded to ubuntu 16.10 (kernel 4.8.0-22-generic) and I've been using
the pc all day long without problems (this was impossible before).
I had to use the kernel
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #120 from DesiOtaku ---
I hate to "me too" here, but I can confirm that the steps outlined in comment
#115 does not resolve the problem. However, the
power_dpm_force_performance_level and power_dpm_state trick outlined in comment
#29
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #119 from PhilipW ---
I also suspect this - microcode does not fix the issue on a Powercolor r9 390
pcs+.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #118 from pc.jago1337 at gmail.com ---
Using radeon, the microcode 'fix' doesn't fix the problem for me. Perhaps there
are multiple bugs, and not just the one?
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #117 from Yuxuan Shui ---
This _k firmware seems to fix the problem for me as well (have been running
without lockup for a while), but only with the radeon driver. With amdgpu, I
still got lock ups, though less often.
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #116 from Calico Bass ---
I found this bug report because I was having problems extracting my vbios and
parsing the extracted rom. I notice that all the vbios.rom files attached here
are 64K.
When parsing my rom I found it was
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #115 from Jonas ---
I'll try to sum up, to help a little if some people are confused about the
process of "workarounding" it.
1) Go here: https://people.freedesktop.org/~agd5f/radeon_ucode/hawaii
2) Download every file.
3) Go here
https://bugs.freedesktop.org/show_bug.cgi?id=91880
pc.jago1337 at gmail.com changed:
What|Removed |Added
Severity|minor |major
11:23 PM
To: dri-devel at lists.freedesktop.org
Subject: [Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable
and poorly performing
Comment # 112<https://bugs.freedesktop.org/show_bug.cgi?id=91880#c112> on bug
91880<https://bugs.freedesktop.org/show_bug.cgi?id=91880>
1 - 100 of 213 matches
Mail list logo