On 2/26/13, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: > On 2/26/13 3:58 PM, Jason Detring wrote: >> Here's the kicker: All this seems to happen only if xfs.ko is >> crosscompiled with GCC 4.6 or 4.7. > > urk! That is a kicker. > >> A module (just the module, the rest of kernel can be built with >> anything) compiled with >> cross-GCC 4.4.1, 4.5.4, or curiously 4.8 (20130224) has no issue at all. >> I've kept an old 2009 Sourcery G++ (4.4.1) Lite toolchain around just >> for building kernels. >> I'd really like to retire it, but I'm a little afraid this is going to >> recur in newer compilers. > > Maybe you can provide an xfs.ko built with each (for the same kernel) > with debug info, and we can compare the disassembly? OK, will do this evening when I can get things cleaned up a bit. > Enabling the trace_xfs_da_btree_corrupt tracepoint might yield more > info, can you do that? > > I think it's: > > # trace-cmd -e xfs_da_btree_corrupt & > # <do your dir read> > # fg > # ^C (ctrl-c trace-cmd) > # trace-cmd report > > We might get more info about the buffer in question that way. I'll give it a go, but it might take me a while to get back to you. I'm not familiar with that tool, and it looks like it's not part of my base install. > -Eric Jason _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
