Problem with X starting when certain USB configurations exist

[Adam Jackson]

On Tue, 2016-02-23 at 13:12 -0800, russell.poffenberger at 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