On Fri, Aug 22, 2014 at 08:23:24AM +0200, Bruno Prémont wrote: > On Thu, 21 Aug 2014 23:39:31 -0500 Bjorn Helgaas wrote: > > On Thu, Aug 21, 2014 at 4:34 PM, Bruno Prémont wrote: > > > > > A second step would then be to tune vgaarb's initial selection. > > > Bjorn, is it possible to verify which I/O ports are decoded by a PCI > > > device at the time of adding it to vgaarb? If so, how? I would like to > > > check for legacy VGA I/O range (0x03B0-0x03DF) and only let vgaarb set > > > a device as default if that I/O range is decoded by the device. > > > > I don't know of a way. I'm pretty sure VGA devices are allowed to > > respond to those legacy addresses even if there's no BAR for them, but > > I haven't found a spec reference for this. There is the VGA Enable > > bit in bridges, of course (PCI Bridge spec, sec 12.1.1. If the VGA > > device is behind a bridge that doesn't have the VGA Enable bit set, it > > probably isn't the default device. > > Those VGA devices behind bridges are the easy ones that vgaarb selects > properly. > It's the ones not behind a bridge (integrated graphics) like the intel > one that cause problems. > > For Andreas's system the discrete nvidia GPU has no I/O enabled > according to PCI_COMMAND flags while the integrated intel one does have > them (that's why the Intel GPU is chosen). > > Unfortunately I don't know what makes his system choke at boot time as > he did not provide logs for the failing case. Very often when something goes wrong with a kms driver we hang while doing the initial modeset. Which is all done while holding the console_lock (because fbdev+vt locking is just insane). You can try to get a closer look with I915_FBDEV=n which will avoid the console_lock, but which also won't register the legacy/compat i915 fbdev emulation any more, so greatly changes boot behaviour. If that doesn't lead to clues the next approach is to "carefully" drop&reacquire console_lock at a few "interesting" places to get a few printks out over netconsole or similar. Or just hack up entire netconsole loggin infrastructure which bypasses printk and so all the console_lock insanity. It's not pretty, I know :( Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
