bizarre behavior reading files incorrectly with 4.99.72

[Greg Troxel <gdt%ir.bbn.com@localhost>]

At BBN we have a box testing current/amd64/xen3.1.  It's a core 2 duo,
and the dom0 has only 1 vcpu.  It is running RAID1 with raidframe.  I'll
call this the 'production' box (but it's still in test).  It has two
domUs: one amd64 and one i386_PAE.

We have another box almost the same, but no raid, intended for
pre-qualifying builds of current before installing them on the
production box - just updating the production box to current is too
scary.

Both boxes are running the same base system, installed from sets built
on the qualification box.  The qualification box works fine.

On the production box, there are a lot of inexplicable problems building
things from pkgsrc.  I tracked one problem down to patch giving
truncated results when paching configure from libtool-base and isolated
a test case.

With pkgsrc/devel/libtool/patches/patch-ab (75 hunks!) and configure
from libtool-base, on most systems patch behaves as you'd expect.  But
on the 'production' system, I end up with a patched configure that is
mysteriously trunctated.  Looking at ktrace of patch, I found

 PID..      1 patch    GIO   fd 6 read 8 bytes
       "t_code=\""
 PID..      1 patch    GIO   fd 6 read 0 bytes
       ""

This corresponds exactly to where the output file is truncated, and
patch repeatedly has this behavior.  I md5'd patch, libc, libutil on
production and qualification boxes, and they seem fine.

When I use md5 to compare the files, I get the same values.

On one domU, running i386/4.99.66 (XEN3PAE_DOMU) kernel and very old
(netbsd-4?) userland, I get the same problem.

On another domU, running i386/4.99.72 (XEN3_DOMU) but 7/8 or so
userland, patch runs fine.

None of these systems are running softdep or WAPBL.

Has anyone else seen anything like this?