Announcement

Collapse
No announcement yet.

Linux 4.15 Is A Huge Update For Both AMD CPU & Radeon GPU Owners

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • sa666666
    replied
    Originally posted by LeJimster View Post
    Disabling c-state in UEFI has stopped my random reboots. Before I turned it off, I was getting 1-2 random reboots a day. Still it needs fixing obviously, but I personally don't think it's a big enough problem to force me to ditch my AMD system. Unfortunately, this kind of problem is to be expected of new platforms, usually by the 2nd generation all the kinks are ironed out.
    I've tried everything (and I mean everything) that has been suggested. In fact, in the past month I spent more time researching this issue and trying to get things working than I am on actual software development. And I have lost work because of it too, since the system has locked up before I could save something, and I have to start over.

    Perhaps the 2nd gen will be better, but I will be sitting this one out. Maybe near the end of 2018 or early 2019 when they get their processes worked out I will try again. But only after reading about many success stories.

    Leave a comment:


  • LeJimster
    replied
    Originally posted by sa666666 View Post
    I hated to do this, but I've already ordered an 8700K system to replace my Ryzen 1800x. I really want to support AMD here, but I just can't have an unstable system; it's being used for stuff where I can't have downtime. And the maddening lockups at seemingly random times really have an anxiety-inducing effect; at every keystroke I'm thinking "is this the moment the system is going to freeze?....
    Disabling c-state in UEFI has stopped my random reboots. Before I turned it off, I was getting 1-2 random reboots a day. Still it needs fixing obviously, but I personally don't think it's a big enough problem to force me to ditch my AMD system. Unfortunately, this kind of problem is to be expected of new platforms, usually by the 2nd generation all the kinks are ironed out.

    Leave a comment:


  • sa666666
    replied
    I hated to do this, but I've already ordered an 8700K system to replace my Ryzen 1800x. I really want to support AMD here, but I just can't have an unstable system; it's being used for stuff where I can't have downtime. And the maddening lockups at seemingly random times really have an anxiety-inducing effect; at every keystroke I'm thinking "is this the moment the system is going to freeze?"

    I haven't decided what to do with the Ryzen CPU/board yet; sell it to a Windows user (where there are no issues at all), or keep it until it works in Linux. Problem is, it's been 6 months of suggestions on how to fix the Linux issues, and still we don't have a final solution (everything I try works for a while, but never rock-solid). At least I will still be using AMD graphics cards; they have the best support in Linux, and with the new DC code committed, it looks like it will stay that way.

    EDIT: I will say that the last 3 months have been the most nerve-wracking in almost 30 years of building computers. I've never had as much problems with an unstable system. I think AMD really has a problem on their hands here, because I'm afraid this has soured my opinion of the platform, and it will be a long time before I try AMD CPUs again. I am satisfied with their video cards and use them almost exclusively. But the CPU situation is beyond frustrating. It's even affected my development activities, and caused deadlines to slip (self-inflicted deadlines, but deadline non-the-less).

    Finally, benchmarks show that the 8700K and the 1800x have similar compile times (my main application), so there's not even that advantage anymore. And to top it all off, I actually paid much more for the AMD CPU/board than I just did for the Intel stuff

    At this point, even if the kernel guys would come out with a fix tomorrow, I have lost confidence in the platform, and would be constantly wondering when something would go wrong again.
    Last edited by sa666666; 19 November 2017, 02:43 PM.

    Leave a comment:


  • plasmasnake
    replied
    Add me to the list of regretful Ryzen customers who is experiencing the idle-freeze bug... I am EXTREMELY disappointed with AMD's continued refusal to publicly acknowledge this issue. And tech support has the nerve to blame our expensive 80Plus Gold power supplies. Sorry AMD but we have multiple systems all affected by the same issue. The problem is your CPU, not our power supplies. Is it too much to expect a simple "we're investigating the issue" response?

    Leave a comment:


  • RavFX
    replied
    I just added a bugs asking specifically to revert the IBM dude patch


    Please add weight, it should be available for distribution to enable by default.

    Leave a comment:


  • RavFX
    replied
    Originally posted by xiando View Post
    No. It does not seem to be anyone higher up the chain in kernel development or AMD who's aware of this.

    As for kernel commit 3fc5b3b6a80b2e08a0fec0056208c5dff757e547, that's not it unless it would somehow trigger something in combination with a lot of other things. I say this because that's a patch that went into 4.12 rc2. Kernels 4.12 will work just fine on Fedora and other distributions who ship with kernels configured with CONFIG_RCU_NOCB_CPU_ALL=Y. Kernel 4.13 and later hangs because this kernel configuration option is removed. The IBM assets commit 44c65ff2e3b0b48250a970183ab53b0602c25764 removed this option which is why kernels later than 4.12 are unusable with Ryzen CPUs without adding a boot parameter.

    Adding a boot parameter isn't a good solution. My old mother doesn't know how to do that. You can't expect her to configure her kernel options or find out that she needs one to not make her computer hang for that matter; all people who can barely work a TV remote on their own will know is that their computer stopped working for some reason. And that's the situation, you use Ryzen, you update your kernel and now you're totally screwed.
    Funny how it was removed in the merge windows two week after it was posted on google about being an important Ryzen workaround. For an option that was there for more that five years, what do we call that? an extremely well timed coincidence?

    Some people just say to disable C6, that is not the fix. C6 disabled make my system consume an extra 20W of power and I still get display corruption. CONFIG_RCU_NOCB_CPU_ALL Fix everything and allow CPU voltage to go down to 0.4V when IDLE.
    Last edited by RavFX; 19 November 2017, 01:11 PM.

    Leave a comment:


  • LeJimster
    replied
    Originally posted by xiando View Post
    Adding a boot parameter isn't a good solution. My old mother doesn't know how to do that. You can't expect her to configure her kernel options or find out that she needs one to not make her computer hang for that matter; all people who can barely work a TV remote on their own will know is that their computer stopped working for some reason. And that's the situation, you use Ryzen, you update your kernel and now you're totally screwed.
    Yep, and for that matter even those with technical expertise might not know about this "fix" that you've found. I certainly didn't until you mentioned it. It needs addressing before Ravens Ridge is released especially. (Presuming the bug occurs on those chips too).

    Leave a comment:


  • xiando
    replied
    Originally posted by nanonyme View Post
    Did anyone escalate the matter to Linus?
    No. It does not seem to be anyone higher up the chain in kernel development or AMD who's aware of this.

    As for kernel commit 3fc5b3b6a80b2e08a0fec0056208c5dff757e547, that's not it unless it would somehow trigger something in combination with a lot of other things. I say this because that's a patch that went into 4.12 rc2. Kernels 4.12 will work just fine on Fedora and other distributions who ship with kernels configured with CONFIG_RCU_NOCB_CPU_ALL=Y. Kernel 4.13 and later hangs because this kernel configuration option is removed. The IBM assets commit 44c65ff2e3b0b48250a970183ab53b0602c25764 removed this option which is why kernels later than 4.12 are unusable with Ryzen CPUs without adding a boot parameter.

    Adding a boot parameter isn't a good solution. My old mother doesn't know how to do that. You can't expect her to configure her kernel options or find out that she needs one to not make her computer hang for that matter; all people who can barely work a TV remote on their own will know is that their computer stopped working for some reason. And that's the situation, you use Ryzen, you update your kernel and now you're totally screwed.

    Leave a comment:


  • xpander
    replied
    Originally posted by LeJimster View Post

    I thought C6 was ultra low power state and C0 highest boost state? Maybe I was misreading. It's not a great experience out of the box for Ryzen users eitherway. I plan to use P-state overclocking eventually, just been working on making sure my system is stable first.
    i dont have 100% answer for that but i havent seen ultra low power state with C6 turned on, so i dont know what it is.
    My motherboard Asus X370 prime has some bugs with P-state overclocking so i wont touch that i just pushed with voltage offset. 3.9ghz and +0.0275 or something. this way its been stable except the C6 bug with kernel 4.13+.

    Leave a comment:


  • LeJimster
    replied
    Originally posted by xpander View Post

    it still goes down to 0.9V and 1.9ghz (1.9ghz to 2.2 ghz in ondemand mode), so i dont think we loose much. C6 state is something else i guess, for boost state or similar
    I thought C6 was ultra low power state and C0 highest boost state? Maybe I was misreading. It's not a great experience out of the box for Ryzen users eitherway. I plan to use P-state overclocking eventually, just been working on making sure my system is stable first.

    Leave a comment:

Working...
X