Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Running Debian on an AMD Ryzen system
124 views
Skip to first unread message
Sam Varghese
Feb 21, 2019, 3:40:05 PM2/21/19
to
I would value feedback from anyone on this list who has been running
Debian on an AMD Ryzen system. I have gone back through list posts for a
year and cannot find anything on this subject.
I am running the testing stream and am looking to upgrade a 10-year-old PC
which I use for work. Having had good experiences with AMD processors in
the past - my current box has a K6-2 chip - I would prefer to go with a
processor from the same company.
If anyone does respond, could you please copy me in? I am not subscribed
to the list.
Thanks,
Sam
------
(Sam Varghese)
Debian on an AMD Ryzen system. I have gone back through list posts for a
year and cannot find anything on this subject.
I am running the testing stream and am looking to upgrade a 10-year-old PC
which I use for work. Having had good experiences with AMD processors in
the past - my current box has a K6-2 chip - I would prefer to go with a
processor from the same company.
If anyone does respond, could you please copy me in? I am not subscribed
to the list.
Thanks,
Sam
------
(Sam Varghese)
Dan Ritter
Feb 21, 2019, 3:50:04 PM2/21/19
to
problems, unless you are using the built-in graphics systems, in
which case you may need to get X11 via stretch-backports.
What are you concerned about?
-dsr-
Sam Varghese
Feb 21, 2019, 4:00:03 PM2/21/19
to
I have seen some older reports about kernel issues and crashes. Hence my
concern.
I presume that the built-in graphics system can be disabled from the BIOS
(or UEFI) and a stock standard graphics card used instead. Would I be
correct in assuming that?
Please copy me in as I am not subscribed to the list.
Thanks,
Sam
Sam Varghese
Feb 21, 2019, 4:20:03 PM2/21/19
to
On Fri, February 22, 2019 8:11 am, Dan Ritter wrote:
> Sam Varghese wrote:
>> I have seen some older reports about kernel issues and crashes. Hence my
>> concern.
>
> I haven't seen any while running Stretch or later.
> Sam Varghese wrote:
>> I have seen some older reports about kernel issues and crashes. Hence my
>> concern.
>
>> I presume that the built-in graphics system can be disabled from the
>> BIOS
>> (or UEFI) and a stock standard graphics card used instead. Would I be
>> correct in assuming that?
> stretch-backports amdgpu X11 system works well for him. His last
> remaining issue is that the touchscreen isn't working, which is
> not a Ryzen issue.
>
> Ryzen (and ThreadRipper)_chips without a G or U suffix have no
> built-in graphics anyway, so it's not an issue unless you're
> buying one of those.
Thanks a lot for your input, Dan. Much appreciated.
Sam
Dan Ritter
Feb 21, 2019, 4:20:03 PM2/21/19
to
Sam Varghese wrote:
>
> On Fri, February 22, 2019 7:46 am, Dan Ritter wrote:
> > What are you concerned about?
>
> Thanks for your response, Dan.
>
> I have seen some older reports about kernel issues and crashes. Hence my
> concern.
>
> On Fri, February 22, 2019 7:46 am, Dan Ritter wrote:
> > What are you concerned about?
>
> Thanks for your response, Dan.
>
> I have seen some older reports about kernel issues and crashes. Hence my
> concern.
I haven't seen any while running Stretch or later.
> I presume that the built-in graphics system can be disabled from the BIOS
> (or UEFI) and a stock standard graphics card used instead. Would I be
> correct in assuming that?
> (or UEFI) and a stock standard graphics card used instead. Would I be
> correct in assuming that?
For desktops, yes. My son is using a Ryzen 2300U laptop, and the
stretch-backports amdgpu X11 system works well for him. His last
remaining issue is that the touchscreen isn't working, which is
not a Ryzen issue.
Ryzen (and ThreadRipper)_chips without a G or U suffix have no
built-in graphics anyway, so it's not an issue unless you're
buying one of those.
-dsr-
stretch-backports amdgpu X11 system works well for him. His last
remaining issue is that the touchscreen isn't working, which is
not a Ryzen issue.
Ryzen (and ThreadRipper)_chips without a G or U suffix have no
built-in graphics anyway, so it's not an issue unless you're
buying one of those.
Étienne Mollier
Feb 21, 2019, 5:30:04 PM2/21/19
to
Sam Varghese wrote:
> I have seen some older reports about kernel issues and crashes. Hence my
> concern.
Good Day,
> I have seen some older reports about kernel issues and crashes. Hence my
> concern.
You were probably referring to CPU idle states bugs appearing
under certain circumstances.
I have been confronted to an AMD Ryzen machine a few months ago,
on which processor C-states had to be disabled in UEFI config,
meaning increased energy consumption when idling. The problem
was similar to the one described on Chris's wiki:
https://utcc.utoronto.ca/~cks/space/blog/linux/RyzenMachineLinuxHangs
https://utcc.utoronto.ca/~cks/space/blog/linux/RyzenApparentlyStable
It has been a while since the last time I checked those AGESA
updates for the motherboard, and am not sure if the problem
would still hold true with latest kernel/firmware upgrades/etc
though.
Kind Regards,
--
Étienne Mollier <etienne...@mailoo.org>
All opinions are my own.
Michael Stone
Feb 21, 2019, 5:50:04 PM2/21/19
to
nothing particularly noteworthy in doing so, which is probably why
you're not seeing much. As usual with modern CPUs, get the latest
firmware update available for your motherboard--which will include
updates that affect the performance & stability of the CPU itself to a
much greater extent than in the k6-2 days.
Felix Miata
Feb 21, 2019, 10:00:04 PM2/21/19
to
Sam Varghese composed on 2019-02-22 07:20 (UTC+1100):
> I would value feedback from anyone on this list who has been running
> Debian on an AMD Ryzen system. I have gone back through list posts for a
> year and cannot find anything on this subject.
(IMO, as one who has not purchased any new AMD products in over a decade)
Debian is a Gnu/Linux distribution. Distributions package FOSS software created by loads of
upstream projects. Thus, limiting your search to Debian (or this support list) risks missing
problems that Debian users simply haven't reported but might be discovered without the limiting
search terms.
It is common knowledge that buying hardware that is younger than 6-9 months before a stable
distribution's release is fraught with various dangers to those wishing simply to get work done
with a new PC. It takes time for FOSS development to catch up with new hardware.
"Ryzen" was initially released roughly 4 months before the original release of current Debian
Stable (9.0, Stretch) in June 2017, which translated to a fairly high prospect of various types of
missing functionality or defects in support of Ryzen products. Stable releases are primarily
subject to defect repairs, not feature (support) additions. The dot releases that follow the
original 9.0 do violate that general principle only to some extent.
Ryzen is a family name comprised of several generations. Since initial Ryzen release there have
been at least 3 newer generations. Effectively, "Ryzen" as a generic term is newer than Stable.
Thus, careful shopping is warranted to ensure you aren't buying hardware that won't be adequately
supported at time of purchase.
Having seen numerous complaints recently about latest "Ryzen" products in various forums, I highly
recommend digesting https://en.wikipedia.org/wiki/Ryzen or equivalent before searching using Debian
as a limiting term, else your choice may force you to use Testing/Buster or some other more recent
distribution instead of Stable/Stretch.
--
Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
> I would value feedback from anyone on this list who has been running
> Debian on an AMD Ryzen system. I have gone back through list posts for a
> year and cannot find anything on this subject.
Debian is a Gnu/Linux distribution. Distributions package FOSS software created by loads of
upstream projects. Thus, limiting your search to Debian (or this support list) risks missing
problems that Debian users simply haven't reported but might be discovered without the limiting
search terms.
It is common knowledge that buying hardware that is younger than 6-9 months before a stable
distribution's release is fraught with various dangers to those wishing simply to get work done
with a new PC. It takes time for FOSS development to catch up with new hardware.
"Ryzen" was initially released roughly 4 months before the original release of current Debian
Stable (9.0, Stretch) in June 2017, which translated to a fairly high prospect of various types of
missing functionality or defects in support of Ryzen products. Stable releases are primarily
subject to defect repairs, not feature (support) additions. The dot releases that follow the
original 9.0 do violate that general principle only to some extent.
Ryzen is a family name comprised of several generations. Since initial Ryzen release there have
been at least 3 newer generations. Effectively, "Ryzen" as a generic term is newer than Stable.
Thus, careful shopping is warranted to ensure you aren't buying hardware that won't be adequately
supported at time of purchase.
Having seen numerous complaints recently about latest "Ryzen" products in various forums, I highly
recommend digesting https://en.wikipedia.org/wiki/Ryzen or equivalent before searching using Debian
as a limiting term, else your choice may force you to use Testing/Buster or some other more recent
distribution instead of Stable/Stretch.
--
Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
tv.d...@googlemail.com
Feb 22, 2019, 1:00:04 AM2/22/19
to
Europe, the first batch I got were all defective, the 1700s would hang
anytime they were left idling without disabling C6 management in bios.
The 1800Xs were also exhibiting this bug, but with a second one on top
under heavy compilation load, GCC would throw random errors and the
compilation would fail. There was various workarounds that allowed me to
use the CPUs while progressively returning them to the manufacturer for
exchange. All affected CPUs were made during the very first weeks of
manufacturing, after that AMD fixed the problem and all newer chips were
fine.
I currently have a mix of ryzen 5s, a few 1700 and 1800X left that are
not affected by any bugs and run perfectly, and newer 2xxx second gen
CPUs that I never had any problem with.
Unless you buy second hand from unscrupulous people or get a dusty batch
or first week first gen chips, you will not be affected by those
problems. In any case AMD did their part and the RMA process after
confirming the problem with them was good.
I have no experience with their integrated graphics, I use discrete
Radeon GPUs, but for the CPU part I am really happy with the
cost/performance ratio. Especially for 3D modeling/rendering and video
they work great, software compilation is one of their strong point too,
anything heavily multi-threaded really.
My two sons play on ryzens too and they don't complain, associated with
a decent GPU they run common "big" titles on Steam Linux or standalone.
Again the cost/performance ratio seems very good to me.
Look at the motherboards you could be interested in too and chipset
features, it's important to consider full system price rather than just CPU.
Hope it helps.
Andrea Borgia
Feb 22, 2019, 3:20:03 AM2/22/19
to
Hi, Sam.
Unless you go for the "G" variant of Ryzen (with embedded GPU(, you should be good to go with no special care if you use the current "testing".
If you decide to use "G" as I did, you should probably opt for this kernel:
Regards,
Andrea
Sam Varghese
Feb 22, 2019, 5:50:03 AM2/22/19
to
On Fri, February 22, 2019 7:12 pm, Andrea Borgia wrote:
> Hi, Sam.
>
> Unless you go for the "G" variant of Ryzen (with embedded GPU(, you should
> be good to go with no special care if you use the current "testing".
> If you decide to use "G" as I did, you should probably opt for this
> kernel:
> https://github.com/M-Bab/linux-kernel-amdgpu-binaries
Thank you, Andrea, and everyone else for the helpful responses. Much
> Hi, Sam.
>
> Unless you go for the "G" variant of Ryzen (with embedded GPU(, you should
> be good to go with no special care if you use the current "testing".
> If you decide to use "G" as I did, you should probably opt for this
> kernel:
> https://github.com/M-Bab/linux-kernel-amdgpu-binaries
appreciated.
I think I will avoid the "G" variant; the Ryzen5 2600 is available for
$259 (Australian dollars) which I will probably buy over the weekend.
Sam
----
(Sam Varghese)
Jonathan Dowland
Feb 22, 2019, 6:00:04 AM2/22/19
to
Dear Sam
Not addressing your question, but just to point out
On Fri, Feb 22, 2019 at 07:20:52AM +1100, Sam Varghese wrote:
>------
>(Sam Varghese)
Your sig separator here ("------") does not match the common convention
for sig separators ("-- " with the trailing space), and so it is not
recognised as a signature by MUA software configured to do so. It would
be a kindness to fellow mailing list users to use the conventional sig
separator.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.
Not addressing your question, but just to point out
On Fri, Feb 22, 2019 at 07:20:52AM +1100, Sam Varghese wrote:
>(Sam Varghese)
Your sig separator here ("------") does not match the common convention
for sig separators ("-- " with the trailing space), and so it is not
recognised as a signature by MUA software configured to do so. It would
be a kindness to fellow mailing list users to use the conventional sig
separator.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.
Jerome BENOIT
Feb 22, 2019, 6:30:04 AM2/22/19
to
Hello,
Out of curiosity, in what kind computer do you plan to plug it ?
Jerome
>
> Sam
> ----
> (Sam Varghese)
>
Jerome
>
> Sam
> ----
> (Sam Varghese)
>
Brad Rogers
Feb 22, 2019, 6:50:04 AM2/22/19
to
On Fri, 22 Feb 2019 10:54:25 +0000
Jonathan Dowland <jm...@debian.org> wrote:
Hello Jonathan,
>("-- " with the trailing space)
That's not quite enough to make it entirely valid;
The 'dash, dash, space' must be all that's on that line. Put anything
after the space, and most MUAs won't recognise it as valid.
--
Regards _
/ ) "The blindingly obvious is
/ _)rad never immediately apparent"
Is she really going out with him?
New Rose - The Damned
Jonathan Dowland <jm...@debian.org> wrote:
Hello Jonathan,
>("-- " with the trailing space)
The 'dash, dash, space' must be all that's on that line. Put anything
after the space, and most MUAs won't recognise it as valid.
--
Regards _
/ ) "The blindingly obvious is
/ _)rad never immediately apparent"
Is she really going out with him?
New Rose - The Damned
Jonathan Dowland
Feb 22, 2019, 9:20:04 AM2/22/19
to
On Fri, Feb 22, 2019 at 11:49:16AM +0000, Brad Rogers wrote:
>On Fri, 22 Feb 2019 10:54:25 +0000
>On Fri, 22 Feb 2019 10:54:25 +0000
>>("-- " with the trailing space)
>
>That's not quite enough to make it entirely valid;
>The 'dash, dash, space' must be all that's on that line. Put anything
>after the space, and most MUAs won't recognise it as valid.
Yes. I felt trying to encode the \n inside the quote marks (or putting a
>
>That's not quite enough to make it entirely valid;
>The 'dash, dash, space' must be all that's on that line. Put anything
>after the space, and most MUAs won't recognise it as valid.
literal \n in the quote marks) would harm comprehension, and hoped that
the implication was clear.
Brad Rogers
Feb 22, 2019, 9:40:04 AM2/22/19
to
On Fri, 22 Feb 2019 14:14:18 +0000
Still, there's at least one person on the list that appears unaware.
--
Regards _
/ ) "The blindingly obvious is
/ _)rad never immediately apparent"
Your father was a megalomaniac, you've got an insane brother
Pure Mania - The Vibrators
>Yes. I felt trying to encode the \n inside the quote marks (or putting a
>literal \n in the quote marks) would harm comprehension, and hoped that
Probably true.
>literal \n in the quote marks) would harm comprehension, and hoped that
Still, there's at least one person on the list that appears unaware.
--
Regards _
/ ) "The blindingly obvious is
/ _)rad never immediately apparent"
Pure Mania - The Vibrators
Patrick Bartek
Feb 22, 2019, 12:30:04 PM2/22/19
to
desktop system with a Ryzen 5 1600 one. All the advice given you so
far is good. However, if you're using Stretch, my research said to
upgrade to the 4.18 kernel in stretch-backports which has code that
supports the Ryzen non-apu chip. Buster is supposed to be 100% Ryzen
compatible with non and apu versions. It's also supposed to support
Seureboot. But it's still in alpha and at least six months from Stable
release. So I would avoid it for now.
If you need Stretch to work with apu Ryzen chips, there are various
"fixes," but they all involve a few pulling files from Buster's repos.
Now that I've received all the parts, I'll let you know how my Ryzen
build works since I'm transfering the System drive from my old system
which is 100% MBR (old motherboard doesn't support uefi) as I don't
want to reinstall Stretch or convert the drive to uefi. New
motherboard does have Legacy support. So, I should be okay as long as
I set the BIOS correctly.
B
0 new messages