There are a few situations where we must take care of the cache if direct
I/O was enabled:
- if we do direct I/O for write but not for read, then any write must
invalidate the cache so that a reader gets the written data and not
the not-updated cache.
- if we used a vnode without direct I/O and it is enabled for writing,
we must flush the cache before compeling the open operation, so that
the cachec write are not lost.
And at inactive time, we wipe direct I/O flags so that a new open without
direct I/O does not inherit direct I/O.
When puffs_cookie2vnode() misses an entry, vcache_get()
creates a new node (puffs_vfsop_loadvnode being called to
initialize the PUFFS part), then it discovers it is VNON,
and tries to vrele() it. vrele() calls VOP_INACTIVE(),
which led us in puffs_vnop_inactive() where we sent a
request to the filesystem for a node that already had been
reclaimed.
The fix is to check for VNON nodes in puffs_vnop_inactive()
and to return without doing anyting. This is suboptimal, but
a better workaround would probably need to modify vcache API,
with an impact on other filesystems. Let us keep it simple.
> drm/i915: set backlight duty cycle after backlight enable for gen4
> For reasons I can't claim to fully understand gen4 seems to require
> backlight duty cycle setting after the backlight has been enabled, or
> else black screen follows. I don't have documentation for the correct
> sequence on gen4 either. Confirmed on Dell Latitude D630 and MacBook4,1.
Without this patch, the screen on my T61 (i965) would be blank at boot
unless I booted with the AC adapter unplugged.
the GTT domain in case it belonged there. Also, fix some compilation issues
when turning on WATCH_GTT and WATCH_LISTS, although this is a lost cause;
most of the code has rotted beyond repair.
