Hmm, perhaps a bug, but for some reason Centos 7 (kernel 3.10.0) does NOT have this problem, even booting in legacy mode. The Xorg.log on a Centos 7 machine shows it works correctly... [ 10.694] (II) Loading sub module "int10" [ 10.694] (II) LoadModule: "int10" [ 10.694] (II) Loading /usr/lib64/xorg/modules/libint10.so [ 10.694] (II) Module int10: vendor="X.Org Foundation" [ 10.694] compiled for 1.17.2, module version = 1.0.0 [ 10.694] ABI class: X.Org Video Driver, version 19.0 [ 10.694] (II) VESA(0): initializing int10 [ 10.694] (II) VESA(0): Primary V_BIOS segment is: 0xc000 [ 10.697] (II) VESA(0): VESA BIOS detected [ 10.697] (II) VESA(0): VESA VBE Version 3.0 [ 10.697] (II) VESA(0): VESA VBE Total Mem: 32704 kB [ 10.697] (II) VESA(0): VESA VBE OEM: Intel(R) SKL Mobile/Desktop Graphics Ch ipset Accelerated VGA BIOS [ 10.697] (II) VESA(0): VESA VBE OEM Software Rev: 0.0 [ 10.697] (II) VESA(0): virtual address = 0x7f666f554000, physical address = 0xc0000000, size = 33488896 [ 10.707] (II) VESA(0): Setting up VESA Mode 0x11B (1280x1024) [ 10.831] (==) VESA(0): Default visual is TrueColor [ 10.831] (==) VESA(0): Backing store enabled [ 10.831] (==) VESA(0): DPMS enabled So could there be a bug, or a newer (read fixed) int10 driver in the Centos 7 version that can be ported to Centos 6.7? Where can I find the package or code for this driver that I may be able to compile for Centos 6.7? Indeed booting UEFI mode locks the resolution at 800x600, and that won't work for me. Thanks, ----------------------------------------------------- Russ Poffenberger | System Architecture Group Phone: +1 / 408 / 635-6049 russell.poffenberger@xcerra.com Xcerra Corporation, LTX/Credence Division 1355 California Circle Milpitas, CA 95035, USA ----------------------------------------------------- <table width=100%> <tr valign=top> <td>From: <td>Adam Jackson <ajax@nwnk.net> <tr valign=top> <td>To: <td>russell.poffenberger@xcerra.com, xorg@lists.x.org <tr valign=top> <td>Date: <td>02/25/2016 05:25 AM <tr valign=top> <td>Subject: <td>Re: Problem with X starting when certain USB configurations exist <tr valign=top> <td>Sent by: <td>"xorg" <xorg-bounces@lists.x.org></table> <hr noshade> <tt>On Tue, 2016-02-23 at 13:12 -0800, russell.poffenberger@xcerra.com wrote: > What happens is that the X server will not start. The relevant lines from the X log appears to be.. > > [ 561.239] (II) Loading /usr/lib64/xorg/modules/libint10.so > [ 561.240] (II) Module int10: vendor="X.Org Foundation" > [ 561.240] compiled for 1.15.0, module version = 1.0.0 > [ 561.240] ABI class: X.Org Video Driver, version 15.0 > [ 561.240] (II) VESA(0): initializing int10 > [ 561.240] (EE) VESA(0): V_BIOS address 0x367f0 out of range That's probably a firmware bug. The vesa driver operates by executing the video BIOS code in a real- mode emulator. It expects this code to be located between addresses 0xc0000 and 0xfffff (ie, where the BIOS lives in the low 1M of RAM in the classic DOS model). To verify this expectation, it examines the software interrupt vector table and checks that it will jump to an address in that range, since int 0x10 and 0x42 are the DOS VBIOS service vectors. For some reason, when you plug in a USB device, the firmware is patching those vectors to point to an address lower than 0xc0000. (If I had to guess, it's paging in some code to handle USB hubs so it can handle keyboards behind those hubs, and needs to move some video code out of the way to make room; why it bothers to do this after the OS loads, I couldn't imagine, but there may be a BIOS configuration option to make it stop doing that.) Since the vesa driver doesn't have code to map the memory there, it knows that can't work, and refuses to try. I'm reasonably sure CentOS 6 supports booting in UEFI mode, so if you boot in UEFI mode instead of BIOS, you should get efifb for the kernel video device and fbdev for the X driver, which won't have this problem. The problem you will have instead is that efifb can't resize the display, so if the video mode set up by the firmware at boot is wrong there will be no fixing it. But booting in UEFI mode is probably good advice on modern Intel systems in any case, the BIOS path routinely has issues and seems to get much less QA than UEFI. Alternatively, you can wait to see if CentOS 6.8 has native 2D support for Skylake. - ajax _______________________________________________ xorg@lists.x.org: X.Org support Archives: </tt><a href="http://cp.mcafee.com/d/avndzgw91NJ5xZNyXwVxATsSzt4s-OyUZsSztxMsCed7bzNJ6W8VZB5NV4Szt-XXObzOpKbtauuvORnnvwg-97UwEfJYoXOVIfJYoXOVJx2ZTrefZvASnTbKetuVtd5V7C1RNRTD-mKzp55mXzfaxVZicHs3jq9JcTvCkTzhOUCqen74PtPo0c-l9QVSf-xZ2IWHs01PoS9Oc_j0Y02r3M09sxlK5LE2zVkDjw_w09JNZMQsCMnWhEw2QqA3_ld41ykOpEw0oQgkDIpOwhd41wDY3h1rUPSk3h04Nwpd45GMtAhrzIVlxgQgu7OFcSU-rhQkF"><tt>http://cp.mcafee.com/d/avndzgw91NJ5xZNyXwVxATsSzt4s-OyUZsSztxMsCed7bzNJ6W8VZB5NV4Szt-XXObzOpKbtauuvORnnvwg-97UwEfJYoXOVIfJYoXOVJx2ZTrefZvASnTbKetuVtd5V7C1RNRTD-mKzp55mXzfaxVZicHs3jq9JcTvCkTzhOUCqen74PtPo0c-l9QVSf-xZ2IWHs01PoS9Oc_j0Y02r3M09sxlK5LE2zVkDjw_w09JNZMQsCMnWhEw2QqA3_ld41ykOpEw0oQgkDIpOwhd41wDY3h1rUPSk3h04Nwpd45GMtAhrzIVlxgQgu7OFcSU-rhQkF</tt></a><tt> Info: </tt><a href="http://cp.mcafee.com/d/2DRPoOrhovsoKUeopdTdETh7fIEKfndETos79zzhOUYrhKyevphsuhdETvK-YyUYCryTiDDDYJlRTU4fyh-8a3Xv6eYKr3Xv6eYKrogLtSPz_nVdBZOXzDnKnjhuhVwtsttV_BHEShhlKUPOEuvkzaT0QSCrjdTVBdUQsK9CzBNNcTsSjDdqymovaAWs7Y01MjlS67OFek7qU7w0jou01bAaJMJZ0kvaAWs7Y01dKfK6zAS2_id40mzkwvWFEwciCjd4036y2AZzek29Ewc4_wq8bv6uOwq80Cc39EwJm3IybstDaIa6y3M-l9CT7PqcIfBY3VpxqK"><tt>http://cp.mcafee.com/d/2DRPoOrhovsoKUeopdTdETh7fIEKfndETos79zzhOUYrhKyevphsuhdETvK-YyUYCryTiDDDYJlRTU4fyh-8a3Xv6eYKr3Xv6eYKrogLtSPz_nVdBZOXzDnKnjhuhVwtsttV_BHEShhlKUPOEuvkzaT0QSCrjdTVBdUQsK9CzBNNcTsSjDdqymovaAWs7Y01MjlS67OFek7qU7w0jou01bAaJMJZ0kvaAWs7Y01dKfK6zAS2_id40mzkwvWFEwciCjd4036y2AZzek29Ewc4_wq8bv6uOwq80Cc39EwJm3IybstDaIa6y3M-l9CT7PqcIfBY3VpxqK</tt></a><tt> Your subscription address: %(user_address)s</tt>