A small investigation update for anyone who might be following this issue.
It seems there was some memory initialization issue that has to do
something with inteldrm
and/or intagp on this specific hybrid graphics setup. More details below.
1. Disabling inteldrm on system boot helps. Xorg starts as expected,
although using 'vesa' driver.
2. Closer examination of dmesg outputs for working 5.5 and botched
5.7-snapshot revealed some subtle diffs:
dmesg 5.5:
..
vga1 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x09
intagp0 at vga1
agp0 at intagp0: aperture at 0xc0000000, size 0x10000000
inteldrm0 at vga1
drm0 at inteldrm0
..
vendor "NVIDIA", unknown product 0x0fe4 (class display subclass 3D,
rev 0xa1) at pci4 dev 0 function 0 not configured
..
dmesg 5.7snap:
..
vga1 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x09
intagp at vga1 not configured
inteldrm0 at vga1
drm0 at inteldrm0
drm: Memory usable by graphics device = 2048M
..
1:0:0: mem address conflict 0xfff80000/0x80000
vendor "NVIDIA", unknown product 0x0fe4 (class display subclass 3D,
rev 0xa1) at pci4 dev 0 function 0 not configured
..
3. It was suggested on DaemonForums that this issue might have popped
up due to some code change to 'agp_i810.c', most probably this one:
CVSROOT: /cvs
Module name: src
Changes by: kettenis@<redacted> 2014/05/12 13:29:16
Modified files:
sys/dev/pci : agp_i810.c
sys/dev/pci/drm/i915: i915_drv.c i915_drv.h i915_gem.c
i915_gem_gtt.c
Log message:
Move GTT management for Sandy Bridge and up into inteldrm(4). This makes
it possible to use the non-mappable part of the GTT, prepares the way for
using the PPGTT and reduces the diffs with Linux.
ok jsg@
Is there a way to notify Mark Kettenis or other devs working on these
parts of the system of this possible regression? Should I forward this
report to bugs@?
