31–40 of 45 posts
This is a non-article, an exercise in bias confirmation. Without a control with no segfaults, or a root cause, it's not useful.
In the article (or perhaps the original article that is linked in this one) they explain that they ran the same tests on Intel processors without any issues whatsoever...
https://www.phoronix.com/forums/forum/phoronix/latest-phoron...
Earlier quoted context omitted.
No idea, but honestly I can't be arsed anymore with new stuff when it's so unreliable. This is from a few minutes ago (the timestamps are hours old, but that's because dmesg timestamps don't take into account sleep time) [Sat Aug 5 13:46:21 2017] ------------[ cut here ]------------ [Sat Aug 5 13:46:21 2017] WARNING: CPU: 0 PID: 16026 at drivers/base/firmware_class.c:1225 _request_firmware+0x51f/0x8a0 [Sat Aug 5 13:4…
Modern hardware is unreliable, especially under GNU/Linux. Ryzen didn't give me any problem under Windows, but GNU/Linux.. the same can be said of Skylake/Broadwell i915 gpu driver. Both my Thinkpad T450s and X250 are not able to get past a few weeks uptime while using Debian. Under Windows they can go on for months.
Note that it appears that a large number of the segfaults which Michael (phoronix) is reporting may be coming from a software issue. In particular, people on the phoronix forums are reporting that conftest segfaults are a known software issue and also one has reported that he was able to reproduce the conftest segfaults on an intel CPU. So not saying that there's not a problem with Ryzen, but it is possible a large n…
Agreed. It is a very basic comparison, which should be done before posting the article. I don't understand why he keeps posting these before running the exact same test on different processors (an Intel or even a different AMD should be ok)
Earlier quoted context omitted.
No idea, but honestly I can't be arsed anymore with new stuff when it's so unreliable. This is from a few minutes ago (the timestamps are hours old, but that's because dmesg timestamps don't take into account sleep time) [Sat Aug 5 13:46:21 2017] ------------[ cut here ]------------ [Sat Aug 5 13:46:21 2017] WARNING: CPU: 0 PID: 16026 at drivers/base/firmware_class.c:1225 _request_firmware+0x51f/0x8a0 [Sat Aug 5 13:4…
Modern hardware is unreliable, especially under GNU/Linux. Ryzen didn't give me any problem under Windows, but GNU/Linux.. the same can be said of Skylake/Broadwell i915 gpu driver. Both my Thinkpad T450s and X250 are not able to get past a few weeks uptime while using Debian. Under Windows they can go on for months.
Earlier quoted context omitted.
Can we all switch to Xeons and ? Or do those have similar issues?
No idea, but honestly I can't be arsed anymore with new stuff when it's so unreliable. This is from a few minutes ago (the timestamps are hours old, but that's because dmesg timestamps don't take into account sleep time) [Sat Aug 5 13:46:21 2017] ------------[ cut here ]------------ [Sat Aug 5 13:46:21 2017] WARNING: CPU: 0 PID: 16026 at drivers/base/firmware_class.c:1225 _request_firmware+0x51f/0x8a0 [Sat Aug 5 13:4…
My shallow guess is that this warning is caused by the btusb module trying to load a firmware file while the kernel disallows this because suspend/resume is in progress or something like that. Take a look at the referenced drivers/base/firmware_class.c:1225 in your 4.13.0-0.rc3.git1.2.fc27.x86_64 sources for more details. I think this looks like a normal software bug in the Linux kernel.
You are running bleeding edge hardware and software and that has always been a bumpy ride. I would expect the software to mature as your hardware grows old...
Earlier quoted context omitted.
Modern hardware is unreliable, especially under GNU/Linux. Ryzen didn't give me any problem under Windows, but GNU/Linux.. the same can be said of Skylake/Broadwell i915 gpu driver. Both my Thinkpad T450s and X250 are not able to get past a few weeks uptime while using Debian. Under Windows they can go on for months.
Funny, I've got several Linux systems and the limiting factor to uptime is power outages.
With older computers (T420, X201) and Xeon servers I got months and even years uptime. Maybe I just got unlucky with my recent acquisitions or maybe the complexity of the new hardware together with the lack of support for Linux means that these kind of bugs are and will become more prevalent in consumer hardware.
Should people planning to buy a Ryzen system hold off until this is fixed?
Earlier quoted context omitted.
No idea, but honestly I can't be arsed anymore with new stuff when it's so unreliable. This is from a few minutes ago (the timestamps are hours old, but that's because dmesg timestamps don't take into account sleep time) [Sat Aug 5 13:46:21 2017] ------------[ cut here ]------------ [Sat Aug 5 13:46:21 2017] WARNING: CPU: 0 PID: 16026 at drivers/base/firmware_class.c:1225 _request_firmware+0x51f/0x8a0 [Sat Aug 5 13:4…
Please consider using gists or something for things like this!
Earlier quoted context omitted.
Funny, I've got several Linux systems and the limiting factor to uptime is power outages.
My anecdotal experience is that I can get better uptime using Windows rather than Linux in consumer computers. The i915 bug made me end up using a Windows host with Debian in a virtual machine, just so I could trust that my computer would not freeze every few weeks. With older computers (T420, X201) and Xeon servers I got months and even years uptime. Maybe I just got unlucky with my recent acquisitions or maybe the…
At this point I suspect getting reliable computers is a lottery.