similar to: Intel NUC haswell-ULT

On Wed, Sep 23, 2015 at 7:39 AM, Fabian Arrotin <arrfab at centos.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 23/09/15 08:00, C. L. Martinez wrote: >> Hi all, >> >> Is it possible to upgrade intel X11 org driver on CentOS7?? Maybe >> with elrepo's packages: >>

If it had two (or more) network ports, I'd be all over it. A single gigabit nic is a bit limiting for me. On 05/17/2017 01:04 PM, Nux! wrote: > Hi, > > I have this and happy with it, I believe it ticks all your boxes (+ built-in IR port). > > http://www.intel.co.uk/content/www/uk/en/nuc/nuc-kit-dn2820fykh.html > > -- > Sent from the Delta quadrant using Borg

Installing debian-9, for using with hassio in docker. Followed steps in this tutorial: https://www.home-assistant.io/blog/2017/11/29/hassio-virtual-machine/ This is linux mint on a lenovo computer, unsure what you would need to troubleshoot the following error. Please advise how to go forward. Sincerely Tor Info hardware: lenovo yoga 2 pro, model: yb05031832 lshw WARNING: you should run

Hi all, Is it possible to upgrade intel X11 org driver on CentOS7?? Maybe with elrepo's packages: http://elrepo.org/linux/extras/el7/x86_64/RPMS/xorg-x11-drv-intel-2.99.916-1.el7.elrepo.x86_64.rpm?? It seems it doesn't exists driver in the upstream: https://01.org/linuxgraphics Thanks,

Folks The price point of Intel's NUC unit makes it attractive to use as a server that doesn't have significant computational load. In my environment, a USB connected hard-drive could provide all the storage needed. I wonder if anyone has had experience with it, and can answer: 1) Does Centos6 and/or Centos7 install from a USB connected optical drive? or a USB flash drive? I'd

Hi, I'm from Argentina, this model isn't in the hardware compatibility list: Lyonn ULT-2000 MKR http://www.solytec.com.ar/p03_ups_lyonn_ult1000.php http://www.solytec.com.ar/p03_ups_lyonn_ultrack.php How can I do to control via SNMP? I have an AgentMini hardware. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello, This is my first patch on this list, however I've already submitted several trough bug tracking system. Since it probably needs some review and it's not a bug I am submitting it here. The main intent of this patch is to detect "core-avx2" platform on Haswell i7 CPUs when running -march=native. Currently it detects it as generic x86_64. lib/Support/Host.cpp: * Haswell is

I have been working, for the past few years, with armv7 SOCs and have a number of servers working. Intel, etal are catching up with ARM and I have seen ones like: https://www.aliexpress.com/item/NEW-Mini-pc-X86-4-Lan-Qotom-Q190G4N-with-celeron-J1900-quad-core-4-usb-VGA/32785346279.html I am looking for a low power (this is 10W) x86_64 board that has at least 2 core and 2GB memory. A single

> I promise I'll do the review of your code after that. Tim, I don’t want to push too much. But since there’s 3.4 release on the horizon, maybe you could find a moment review this patch. Especially Haswell is all there since few months. Cheers, -- Adam --- lib/Support/Host.cpp | 8 ++++++++ lib/Target/X86/X86Subtarget.cpp | 3 ++- 2 files changed, 10 insertions(+), 1

> That's far more worrying to me than not being able to detect Haswell. > I can't reproduce the problem here at the moment: both debug and > release builds give identical assembly for Host.cpp. OK. I know the reason you cannot reproduce it, before posting the patch I've decided to check for AVX before checking AVX2, just not to cpuid AVX2 when we don't have AVX1 anyway.

>> + bool HasAVX2 = HasAVX && !GetX86CpuIDAndInfo(0x7, &EAX, &EBX, &ECX, &EDX) && >> + (EBX & 0x20); > > I don't think this guarantees %ecx is 0, does it? Wasn't that the > entire reason the original code went wrong? I don’t remember really, but presuming the conclusions of the discussion, seems it is fixed now. It

Hi Adam, > * I have marked HasAVX2 as "volatile", since otherwise it gets > magically zeroed (by optimizer?) when compiling clang with latest > clang build from trunk That's far more worrying to me than not being able to detect Haswell. I can't reproduce the problem here at the moment: both debug and release builds give identical assembly for Host.cpp. I don't

I have a group of students working with me on some LLVM projects related to our Parabix research. One interesting issue that has come up for us is code generation support for the Haswell new instructions pext and pdep. These instructions shuffle bits within a 64-bit word, either gathering all selected bits to the beginning (pext) or scattering some initial bits throughout (pdep). A natural

I agree with Tim, you need to implement a GetCpuIDAndInfoEx function in Host.cpp and pass the correct value to ecx. Also you need to verify that 7 is a valid leaf because an invalid leaf is defined to return the highest supported leaf on that processor. So if a processor supports say leaf 6 and not leaf 7, then an access leaf 7 will return the data from leaf 6 causing unrelated bits to be

Hi all, Intel has just revealed its AVX2 instruction set, to be supported by the 2013 Haswell architecture, and it's looking quite revolutionary: http://software.intel.com/en-us/forums/showthread.php?t=83399 <http://software.intel.com/en-us/forums/showthread.php?t=83399&o=a&s=lr> &o=a&s=lr It includes powerful 'gather' instructions, which allow reading

> I don’t remember really, but presuming the conclusions of the discussion, seems it is fixed now. It was something about registers when using inline assembly. Anyway this works just fine on all my Haswell machines. I think that's more coincidence than anything else (something perturbed in your host compiler's backend). If you look at lib/Target/X86/MCTargetDesc/X86MCTargetDesc.cpp

Hi I wonder, if live migration (back and forth) is possible on mixed Haswell (Xeon V3) and Broadwell (Xeon V4) installations. The only notable difference between the two is apparently a working TSX implementation on V4, which got disabled on V3 due to bugs. The rest (VMCS-shadowing, posted interrupts) should not apply to our environment, as we do not run nested-vmx nor device-passthrough on

Sorry to blow up everyone's email on this but I tried something new and found a different problem. I uninstalled all the debian package (libvirt, kvm, qemu, virt-manager, etc.) and then remade all the packages and installed them. Haswell again shows up in virt-manager, but now any CPU I choose including kvm64 and qemu64 give the same error: root@mal:~# virsh create

Sounds good, I'll give it a try sooner or later. I've never messed with triples, so is there anything I need to be aware of so I don't break any code on other platforms? In particular, I want llvm::sys::getDefaultTargetTriple() to return me this new haswell-aware triple, so what do I need to do to ensure that I don't break anyone else who is running one of these systems and

Hello All, I'm installing some DIY routers, composed of Intel nuc's ,Linksys usb-ethernet adapters and Centos7 On most machines I just plug in the usb device, install Centos7 and everything works. But on this one machine the network interface doesn't work. After installing ip addr shows: [root at clgmol ~]# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue