search for: ryzens

James A. Peltier <jpeltier at sfu.ca> wrote: > While I can't assure you that upgrading to 7 will fix the problem, > the likeliness that will work is at least 50% better being as 7 is > based on a newer kernel. I've installed CentOS 7 with the latest kernel from elrepo (4.11.8), and I can't get Grub to install. I think I'll have to conclude that it really

I have a new system with an AMD Ryzen 1600 CPU and I'm trying to run CentOS, so far without success. The only information I could find was a post reporting that CentOS 7 would crash during installation on a Ryzen system: https://www.centos.org/forums/viewtopic.php?t=61831 . I tried updating to the latest elrepo "mainline stable" kernel, version 4.11 (by booting from a live CD and

On Fri, 30 Jun 2017 00:05:52 -0400 "Yves Bellefeuille" <yan at storm.ca> wrote: > James A. Peltier <jpeltier at sfu.ca> wrote: > > > While I can't assure you that upgrading to 7 will fix the problem, > > the likeliness that will work is at least 50% better being as 7 is > > based on a newer kernel. > > I've installed CentOS 7 with the

The issue is likely about the chipset not being properly supported and so you will have to wait and see if 6.10/7.4 helps. You may want to check the RH release notes for RHEL 6.10/7.4 and see if support for the processor is listed there. While I can't assure you that upgrading to 7 will fix the problem, the likeliness that will work is at least 50% better being as 7 is based on a newer

I'm exploring latency overhead of parallel PSOCK workers and noticed that serializing/unserializing data back to the main R session is significantly slower on Linux than it is on Windows/MacOS with similar hardware. Is there a reason for this difference and is there a way to avoid the apparent additional Linux overhead? I attempted to isolate the behavior with a test that simply returns

OK, AMD has announced it's new line of server and desktop processors. What level of CentOS has been tested on them? OK then, when will CentOS be tested on them? Or do we wait for Red Hat? -- Eugene Poole Woodstock, Georgia

On Mon, 2 Nov 2020 at 02:22, Simon Urbanek <simon.urbanek at r-project.org> wrote: > > It looks like R sockets on Linux could do with TCP_NODELAY -- without (status quo): How many network packets are generated with and without it? If there are many small writes and thus setting TCP_NODELAY causes many small packets to be sent, it might make more sense to set TCP_QUICKACK instead.

Package: src:xen Version: 4.14.1+11-gb0b734a8b3-1 Severity: critical Justification: causes serious data loss X-Debbugs-Cc: debianbts at virtualzone.hu Dear Maintainer, after a clean install of bullseye/testing the xen dmesg shows the following message: (XEN) AMD-Vi: IO_PAGE_FAULT: 0000:01:00.1 d0 addr fffffffdf8000000 flags 0x8 I this is the sata device: 01:00.1 SATA controller: Advanced Micro

hi, our current servers are suffering from a weird hardware issue that forces us to start over. in short we have two servers with 15 disks at 6TB each, divided into three raid5 arrays for three bricks per server at 22TB per brick. each brick on one server is replicated to a brick on the second server. the hardware issue is that somewhere in the backplane random I/O errors happen when the system

I'm not sure the user would know ;). This is very system-specific issue just because the Linux network stack behaves so differently from other OSes (for purely historical reasons). That makes it hard to abstract as a "feature" for the R sockets that are supposed to be platform-independent. At least TCP_NODELAY is actually part of POSIX so it is on better footing, and disabling

Hi, amdgpu + IOMMU + SME is now working for me on 5.7, yay! But, it is broken on torvalds master, boo. On boot, depending on which exact commit I test, it either hangs immediately (with built-in driver, before starting initramfs), displays some errors then hangs, or spams the screen with many amdgpu errors. I bisected the black screen hang to: commit dce8d6964ebdb333383bacf5e7ab8c27df151218

Hi, amdgpu + IOMMU + SME is now working for me on 5.7, yay! But, it is broken on torvalds master, boo. On boot, depending on which exact commit I test, it either hangs immediately (with built-in driver, before starting initramfs), displays some errors then hangs, or spams the screen with many amdgpu errors. I bisected the black screen hang to: commit dce8d6964ebdb333383bacf5e7ab8c27df151218

It looks like R sockets on Linux could do with TCP_NODELAY -- without (status quo): Unit: microseconds expr min lq mean median uq max clusterEvalQ(cl, iris) 1449.997 43991.99 43975.21 43997.1 44001.91 48027.83 neval 1000 exactly the same machine + R but with TCP_NODELAY enabled in R_SockConnect(): Unit: microseconds expr

Will 5.0 have scheduler, reg alloc etc. bits for explicit support of AMD's 1st gen Zen (Ryzen, Epyc) arch? Is it safe to assume that the changes for Zen's 2nd gen will land prior to the hardware release, once the 1st gen is added? I think zen2 will arrive next year.

Could TCP_NODELAY and TCP_QUICKACK be exposed to the R user so that they might determine what is best for their potentially latency- or throughput-sensitive application? Best, Jeff On Mon, Nov 2, 2020 at 14:05, I?aki Ucar <iucar at fedoraproject.org> wrote: > On Mon, 2 Nov 2020 at 02:22, Simon Urbanek > <simon.urbanek at r-project.org> wrote: >> >> It looks

Hi everyone, My PC don't have an integrated WLAN card, so I bought an USB WIFI device which use the MediaTek MT7601U chip(image 'dongle.jpg'). ------------------------------------------------------------------------------------------------------ My PC specification- OS = CentOS 7.8.2003. Processor = AMD Ryzen 5 1600. Mother-Board = GA-Gigabyte A320M-S2H

Hi folks, I am able to install workstation successfully on a dedicated SSD w/ GPT partition w/ UEFI boot using the latest `CentOS-8.2.2004-x86_64-dvd1.iso` from a bootable pen drive. The motherboard is ASRock x570 Gaming 4 ( https://www.asrock.com/mb/AMD/X570%20phantom%20Gaming%204/index.asp) w/ Ryzen 3600, 16G RAM, 1TB SSD in question. However, after login, when I do a DNF update (which is

I'm having a problem installing CentOS 8 from a USB drive. When the installer boots from the USB, it displays the language selection screen. After I select English and continue, the installer freezes. The USB drive flashes a couple times over the next minute or so, the stops. The mouse moves the cursor, but the installer is unresponsive to either selecting QUIT or HELP. I've

Please, check a tcpdump session on localhost while running the following script: library(parallel) library(tictoc) cl <- makeCluster(1) Sys.sleep(1) for (i in 1:10) { tic() x <- clusterEvalQ(cl, iris) toc() } The initialization phase comprises 7 packets. Then, the 1-second sleep will help you see where the evaluation starts. Each clusterEvalQ generates 6 packets: 1. main ->

Excerpts from Joerg Roedel's message of June 22, 2020 6:02 am: > Hi Alex, > > On Thu, Jun 11, 2020 at 07:05:21PM -0400, Alex Xu (Hello71) wrote: >> I am using an ASRock B450 Pro4 with Ryzen 1600 and ASUS RX 480. I don't >> understand this code at all, but let me know what I can do to >> troubleshoot. > > Does it boot without SME enabled? > >