9.1 xdpyinfo oddity

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

This might not be an X problem, but it's a problem observed with an X
program.  If someone has reason to think it's not X-specific, I'd love
to hear about it.

I just installed 9.1 - absolutely stock, straight off
amd64/installation/cdrom/boot.iso - in the hope that its X would better
understand a particular machine.  Those hopes appear to have been
fulfilled, but, in the process, I noticed something that strikes me as
very odd.

I ssh to the machine from my usual desktop.  In one ssh session, I run
xinit with suitable arguments.  The server starts as I would expect,
based on how I ran xinit.  That much is all good.

Then, from a second ssh login, I run

	env DISPLAY=:0 xdpyinfo

I get what I'd expect: xdpyinfo output scrolling past.  So I run

	env DISPLAY=:0 xdpyinfo | less

less displays no output.  So I try

	env DISPLAY=:0 xdpyinfo > z

Sure enough, I see nothing (so, nothing on stderr) and z is empty.

The only way I've found to capture the output is

	script -c 'env DISPLAY=:0 xdpyinfo'

which, it seems to me, really should be overkill.

ktracing both working and failing runs, they appear identical (except
for ASLR-style pointer differences) right up until it's about to start
printing things.  It does

   507      1 xdpyinfo CALL  __fstat50(1,0x7f7fffbd4de0)

(where of course the PID and the pointer differ between runs).
__fstat50 succeeds (the RET line shows 0) in each case, but in the
"working" case, it then does ten mmaps of 0x1000 bytes (all mmaps are
of ANONYMOUS memory), does TIOCGETA on stdout, and starts printing
stuff; in the "failing" case, it does one mmap of 0x5000 bytes and
prints nothing.  After printing some stuff in the one case, each
version does an mmap of 0x3000 bytes and the "working" version prints
more stuff.  It interacts with the X server a little more, printing
some output in the one case.  This pattern continues - interact with
the X server, sometimes allocate more memory, and in the one case print
stuff - until eventually it's done and it exits.  It's possible all the
output is sitting in a buffer somewhere in the "failing" case, but, if
so, I don't see anything to hint at why it's not getting flushed.  I do
not, for example, see any failed write attempts on stdout in the
failing case.

I've tried a handful of other things.  I've tried simple things like
echo and /bin/pwd and ls, I've tried two other X programs (xset q,
xwininfo -root -tree, and xrandr, because those are the first three X
programs I can think of, besides xdpyinfo, that generate text output on
stdout).  So far, xdpyinfo is the only one to behave in this bizarre
fashion.

I have no idea what might be worth reporting here.  This feels to me as
though it's probably separated from the X backend by enough layers I
don't expect it'll be useful to report all that, but I can give a few
of the most basic details.

This is amd64.  The video is Intel, PCI device ID 0x5912; i915drmkms
attaches, but, after reporting kern.module.path, I get a bunch of "kern
info: [drm]" lines that start fine but take a disturbing turn (see
below).  But the X server appears to start fine, and xrandr output
looks fine, possibly excepting reporting four outputs that do not exist
as far as connectors on the machine's case are concerned.  One of them
is named VIRTUAL1, so it may be excused, but the others are named as if
they were real hardware - curiously, based on reported connection
status, the DE-15 ("VGA") connector on the back panel appears to be
DP3.

The [drm] kernel messages I mentioned above:

kern info: [drm] Memory usable by graphics device = 4096M
kern info: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
kern info: [drm] Driver supports precise vblank timestamp query.
kern info: [drm] failed to find VBIOS tables
i915drmkms0: interrupting at ioapic0 pin 16 (i915drmkms0)
kern info: [drm] failed to retrieve link info, disabling eDP
kern error: [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/i915_drv.c:636)i915_firmware_load_error_print] *ERROR* failed to load firmware i915/kbl_dmc_ver1.bin (0)
kern error: [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/i915_drv.c:651)i915_firmware_load_error_print] *ERROR* The driver is built-in, so to load the firmware you need to
include it either in the kernel (see CONFIG_EXTRA_FIRMWARE) or
in your initrd/initramfs image.
kern error: [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_guc_loader.c:560)guc_fw_fetch] *ERROR* Failed to fetch GuC firmware from i915/kbl_guc_ver9_14.bin (error -2)
kern error: [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/i915_gem.c:5417)i915_gem_init_hw] *ERROR* Failed to initialize GuC, error -5 (ignored)
kern info: [drm] GMBUS [i915 gmbus dpd] timed out, falling back to bit banging on pin 6

However, it then goes on to say

intelfb0 at i915drmkms0
intelfb0: framebuffer at 0xffffa98067710000, size 1280x1024, depth 32, stride 5120
wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0
wsmux1: connecting to wsdisplay0
wskbd1: connecting to wsdisplay0
wskbd2: connecting to wsdisplay0
kern info: [drm] RC6 on

so apparently something works nevertheless.  And, as I said, X starts
and works enough to draw an xterm and respond to a few simple client
programs.  (It's a bit odd that it'd be babbling about
initrd/initramfs, which as far as I know are Linuxisms; maybe someone
ported some Linux code and didn't clean up the messages?)

Any thoughts on what might be wrong (and, in particular, whether it's
my problem or 9.1's or what, and what I might be able to do to fix it)?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B