similar to: Intel 4600 Graphics (Haswell) in CentOS 6.4

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,

So, in the ongoing saga of the unusual 1U short-depth workstation, we have narrowed the field to two choices. Both entrants are configured with 16GB memory (4x4GB), two 2.5" drives (1x250GB SSD and 1x1TB HDD), and an NVIDIA NVS510 graphic card (quad display): 1) SuperMicro 5017R-MF, Xeon E5-2609 processor 2) SuperMicro 5017C-LF, Xeon E3-1220 processor (I wish SuperMicro had a list of their

Hi all, I''m having difficulty getting VT-d to work correctly with a new Supermicro MBD-X10SAE-O in QubesOS <http://qubes-os.org/trac>, and I''m hoping someone here might be able to help me (or at least shed some light on my situation). A Qubes developer suggested I contact this list. Here''s my HCL post from the qubes-users group

I found this page: https://01.org/linuxgraphics/downloads/2015q4-intel-graphics-stack-release I have an Intel NUC5C with "Intel HD" graphics and I'm trying to use CentOS 7.2 I downloaded the files suggested: cairo-1.14.4.tar.xz libva-1.6.2.tar.bz2 mesa-11.0.4.tar.xz intel-gpu-tools-1.13.tar.bz2 libva-intel-driver-1.6.2.tar.bz2 xf86-video-intel-2.99.917.tar.gz

I have finally received and am configuring my new workstations eith the NVS510 graphics cards, and have run into rather a problem. The X server seems to be loading the NOUVEAU driver properly (based on the contents of Xorg.0.log), but I have one X11 application that doesn't work correctly; it runs as though XSynchronized is always True, even though it's explicitly set to False in the

I will try to explain this as best I can. I have two computers; one a Supermicro X10SAE running CentOS 6, the other a very old DOS box.[*] The DOS box runs a CCD camera, sending images via Ethernet to the X10SAE. Thus, the X10SAE runs a Python server on port 5700 (a socket which binds to 5700 and listens, and then accepts a connection from the DOS box; nothing fancy).[**] The DOS box connects to

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: >>

I have been following these instructions: https://www.centos.org/forums/viewtopic.php?t=501 to put a bunch of utilities (Clonezilla, SystemRescue, CentOS netinstall/rescue, etc.) on a single USB key. It works great for everything (including Ubuntu Live) except the CentOS 6.4 LiveCD. (You can see my postings at the bottom of the forum.) When booting the LiveCD, I got: Kernel panic - not syncing:

Hi! I wanted to post this to Xen WIKI, but I have no write rights there. I have talked to AsRock support, and they said, that: - all Z87, H87, Q87 and B85 asrock mainboards support vt-d, - you have to check if vt-d is supported by the CPU, - there are no information on vt-d support in future haswell mainboard chipsets, like H81. I''m willing to test it, when I get hands on

The important thing IMO, is to not represent the gather operation as an instruction which takes a vector of pointers, because that's too restrictive for architectures with 64bits pointers. What one most frequently wants to do in those architectures is to specify a 64bit scalar base pointer with a vector of 32bit offsets. This fits what the VGATHERxxx described in the spec provides, and this

greened at obbligato.org (David A. Greene) writes: > Jose Fonseca <jfonseca at vmware.com> writes: > >> The important thing IMO, is to not represent the gather operation as >> an instruction which takes a vector of pointers, because that's too >> restrictive for architectures with 64bits pointers. > > How is it restrictive? Ah, I think you mean you

> I think your real problem is that garbage went into ECX instead of 0 and > caused cpuid to return 0. Ah, that looks very likely. The value seems to come from "xorl %eax, %eax" in both good object files, but a previous cpuid in the bad one. Excellent work Craig, I suspect that would have taken me days to find. Tim.

Hi Adam, > + 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? Cheers. Tim.

>> + 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

> 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

https://bugs.freedesktop.org/show_bug.cgi?id=98398 Peter Wu <peter at lekensteyn.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[Nouveau] Vgaswitcharoo |Acer Aspire V7-582PG |fails to turn off GPU |(Haswell, GTX 750M) fails

https://bugs.freedesktop.org/show_bug.cgi?id=98398 --- Comment #9 from rick.2889 at gmail.com --- Sure, I'll have another test run with 4.7 this week. -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL:

https://bugs.freedesktop.org/show_bug.cgi?id=98398 --- Comment #10 from rick.2889 at gmail.com --- Hmm I just installed Linux 4.7.6 and ran it without any additional kernel parameters and I am getting results close to ˜7.5W too, so it seems to work there. -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was

Hi PCI/ACPI PM experts, Since Linux 4.8, nouveau switched to rely on the PCIe port driver to transition to D3cold. This however does not happen for an Acer Aspire V7-582PG (Haswell, NVIDIA GTX 750M) from Rick. Any idea why? acpidump, lspci, dmesg and other details can be found in the linked bug below. Kind regards, Peter On Wed, Oct 26, 2016 at 10:42:07PM +0000, bugzilla-daemon at

On Thu, Oct 27, 2016 at 09:15:19AM +0000, Rick Kerkhof wrote: > I can confirm what Peter said, path contains \_SB_.PCI0.RP05 and > power_state contains D3hot. And there are no power_resources_Dx directories under /sys/bus/pci/devices/0000:00:1c.4/firmware_node?