similar to: Zen arch in 5.0?

So there's more patches in the pipeline to land, then? On Sun, Jun 25, 2017 at 10:36 PM, Das, Dibyendu <Dibyendu.Das at amd.com> wrote: > Scheduler - yes. > > Sent from my Windows Phone > ________________________________ > From: Carsten Mattner via llvm-dev > Sent: ‎6/‎25/‎2017 3:47 PM > To: llvm-dev > Subject: [llvm-dev] Zen arch in 5.0? > > Will 5.0 have

On Wed, Apr 1, 2020 at 12:33 PM Peter Kjellstr?m <cap at nsc.liu.se> wrote: > On Wed, 1 Apr 2020 10:01:04 +0530 > Thomas Stephen Lee <lee.iitb at gmail.com> wrote: > ... > > Thanks for the information ?. > > Rented a new EPYC Rome Server from Hetzner, but sensors does not show > > status of all cores in list, which is why I asked. > > Curious what

* Premachandra Mallappa: > [AMD Public Use] > > Hi Floarian, > >> I'm including a proposal for the levels below. I use single letters for them, but I expect that the concrete implementation of this proposal will use >> names like “x86-100”, “x86-101”, like in the glibc patch referenced above. (But we can discuss other approaches.) > > Personally I am not a big

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

I plugged my son's new (Christmas) Zen V player into my CentOS 5.1 box and it doesn't register as a device that the system can see or mount. If I lsusb, it shows up as bus 2, device 8, but there is no corresponding /dev/??? device for it, so the system can't get at it. (I tried my flash drive in the same USB port and it works fine, so it's not the hardware.) How do I get around

Most Linux distributions still compile against the original x86-64 baseline that was based on the AMD K8 (minus the 3DNow! parts, for Intel EM64T compatibility). There has been an attempt to use the existing AT_PLATFORM-based loading mechanism in the glibc dynamic linker to enable a selection of optimized libraries. But the general selection mechanism in glibc is problematic: hwcaps

The following program is whittled down from a much larger program that always works on Intel, and always works on AMD's threadripper with lapply but not mclappy. With mclapply on AMD, all processes go into "suspend" mode and the program then hangs. This bug is replicable on an AMD Ryzen Threadripper 2950X 16-Core Processor (128GB RAM), running latest ubuntu 18.04. The R version

Thought I'd pass this along for Theora users on the Windowzz platform. The latest alpha build of the ffdshow filter (20041003) on Sourceforge http://sourceforge.net/projects/ffdshow/ Seems to have had theora, broken since the June/July unofficial builds, fixed. This build also connects nicely to Zen's Ogg splitter and also decodes Helix Producer encoded Ogg's well. The encoder side

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

our new Server with AMD EPYC and super micro board reboots ramdonly. There is no error message before the reboot in /var/log/messages. we are running 2 Server with VMWare workstation without any problem. The new server should run KVM. older servers with AMD (before EPYC) running KVM without any problem. any idea or recommendation? -- Viele Gr??e Helmut Drodofsky Internet XS Service GmbH

Good Evening, I recently purchased an EPYC quantum UPS. I installed NUT on the home assistant by connecting the UPS via USB and tried all the various drivers in the list, the only one that seems to work is: usbhid-ups with this log: s6-rc: info: service s6rc-oneshot-runner: starting s6-rc: info: service s6rc-oneshot-runner successfully started s6-rc: info: service base-addon-banner: starting

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

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

> On 30/10/2018 06:46, Simon Matter wrote: >>> On 10/29/18 1:55 AM, Simon Matter wrote: >>>> To me it seems like, if they are smart, they will try to push IBM >>>> POWER >>>> and RedHat Linux together to establish real competition in the >>>> hardware >>>> market again (and of course don't forget to keep Fedora/CentOS

> On 10/29/18 1:55 AM, Simon Matter wrote: >> To me it seems like, if they are smart, they will try to push IBM POWER >> and RedHat Linux together to establish real competition in the hardware >> market again (and of course don't forget to keep Fedora/CentOS alive)! > > Er, RHEL has been running on Power for a very long time. The fastest > supercomputer in the

> On 2018-10-30 02:46, Simon Matter wrote: >>> On 10/29/18 1:55 AM, Simon Matter wrote: >>>> To me it seems like, if they are smart, they will try to push IBM >>>> POWER >>>> and RedHat Linux together to establish real competition in the >>>> hardware >>>> market again (and of course don't forget to keep Fedora/CentOS

I've seen several references to running VMWare under CentOS, but does anybody know how well Parallels runs under CentOS? On a related note, now that Zen is as mature as it is, are commercial VMs really much better than Zen? Miark

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

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.

So an iPod made in the last 4 years has not even a dsp that's used for help in low-power playback of mp3? What are my best options for a portable player I can put opus on and have 10 hours of opus playback? On Sun, Dec 15, 2013 at 6:10 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > The vast majority of audio players do *not* have special hardware for > MP3 and Vorbis.