I get the same stack trace. There's another report out there somewhere with another similar stack trace. I know the realtime code is not maintained so much but it seems to be a waste to let it fall out of maintenance when it's the only thing on linux that seems to fill the realtime io niche.
So this email is mainly about the null pointer deref on the spinlock in _xfs_buf_find on realtime files, but I figure I might also ask a few more questions.
What kind of differences should one expect between GRIO and realtime files?
What kind of on latencies of writes should one expect for realtime files vs normal?
My use case is diagnostic tracing on an embedded system as well as saving raw video to disk (3 high res 10bit video streams, 5.7MB per frame, at 20hz so effectively 60fps total). I use 2 512GB OCZ vertex 4 SSDs which support ~450MB/s each. I've soft-raided them together (raid 0) with a 4k chunksize and I get about 900MB/s avg in a benchmark program I wrote to simulate my videostream logging needs. I only save one file per videostream (only 1 videostream modeled in simulation), which I append to in a loop with a single write call, which records the frame, over and over while keeping track of timing. The frame is in memory and nonzero with some interesting pattern to defeat compression if its in the pipeline anywhere. I get 180-300MB/s with O_DIRECT, so better performance without O_DIRECT (maybe because it's soft-raid?). The problem is that I occationally get hickups in latency... there's nothing else using the disk (embedded system, no other pid's running + root is RO). I use the deadline io scheduler on both my SSDs.
I only have 50 milliseconds per frame and latencies exceeding this would result in dropped frames (bad).
Benchmarks (all time values in milliseconds per frame for the write call to complete), with 4k chunksizes for raid-0 (85-95% CPU):
[04:42:08.450483000]  min: 4 max: 375 avg: 6.6336148 std: 4.6589185 count = 163333, transferred 900.33G [07:52:21.204783000]  min: 4 max: 438 avg: 6.4564963 std: 3.9554192 count = 34854, transferred 192.12G (total time=226.65sec, ~154fps)