2.6.0-test1, tcq, xfs corruption

This is to confirm corruption with the xfs filesystem on a tcq-enabled kernel with queue depth 8 (enabled by accident actually). Previously I have experienced massive fs corruption on queue depth 8 tcq kernels with reiser, described here (no replies..):

http://www.ussg.iu.edu/hypermail/linux/kernel/0307.1/1307.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0307.1/1396.html

Is there interest in more testing from me using my old reiserfs root fs? Please reply one way or the other, as I need my hard drive space back.

Here's xfs oops data:

0x0: 84 24 80 00 00 00 50 51 53 e8 2e 03 00 00 83 c4
Filesystem "hda8": XFS internal error xfs_da_do_buf(2) at line 2281 of file fs/x
fs/xfs_da_btree.c. Caller 0xc0203c47

Call Trace:
 [<c0203609>] xfs_da_do_buf+0x439/0x9c0
 [<c0203c47>] xfs_da_read_buf+0x57/0x60
 [<c0203c47>] xfs_da_read_buf+0x57/0x60
 [<c0241429>] pagebuf_get+0xb9/0x140
 [<c020195e>] xfs_da_node_lookup_int+0x7e/0x340
 [<c0203c47>] xfs_da_read_buf+0x57/0x60
 [<c020cba7>] xfs_dir2_leafn_lookup_int+0x397/0x5d0
 [<c020cba7>] xfs_dir2_leafn_lookup_int+0x397/0x5d0
 [<c0142fc6>] cache_grow+0x146/0x240
 [<c0201ace>] xfs_da_node_lookup_int+0x1ee/0x340
 [<c020e75f>] xfs_dir2_node_lookup+0x3f/0xc0
 [<c02061b8>] xfs_dir2_lookup+0x138/0x150
 [<c02203c5>] xfs_ichgtime+0x105/0x107
 [<c0238e38>] xfs_setattr+0xb8/0xee0
 [<c023587c>] xfs_dir_lookup_int+0x4c/0x130
 [<c023b200>] xfs_lookup+0x50/0x90
 [<c0248767>] linvfs_lookup+0x67/0xa0
 [<c0162cb8>] real_lookup+0xc8/0xf0
 [<c0162f46>] do_lookup+0x96/0xb0
 [<c016340f>] link_path_walk+0x4af/0x8e0
 [<c0164223>] open_namei+0x83/0x410
 [<c01549fe>] filp_open+0x3e/0x70
 [<c0154ebb>] sys_open+0x5b/0x90
 [<c010b29b>] syscall_call+0x7/0xb

Note on filesystems:
I've had massive corruption on reiser, limited corruption on xfs, and very minor corruption on ext3. I hope this is helpful.

I am continuing to run an xfs system on a tcq-enabled kernel with 32 depth queue, as this seems to be fine most of the time, except for an oops/lockup when waking from standby (I've posted another bug report).