Folks, This is my current patch queue that I'm testing. It's sitting on top of Jan Kara's freeze series, but otherwise it is based on an unmodified 3.4-rc4 + oss-xfs/master tree. First of all, this s
Hi Dave, I just hit it again, looks like in test 273. [ 6587.548841] XFS: Assertion failed: push_seq > 0 && push_seq <= This time I have a dump. ;) -Ben
Dave, I want to pull this in and have been testing toward that end. With Jan's patches this seems to be working well. I've had to disable a couple asserts: Index: xfs/fs/xfs/xfs_bmap.c == -- xfs.orig
Look slike the same thing - a NULL ailp, which implies the callback occurred while the log is being torn down.. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
That's the two problems my latest patch series help reduce. I think they solve this second one, and I now understand the remaining case I'm tripping over the first one, and that is a case of modifyin
While testing this patchset without Jan's freeze work, I hit this assert. This one rings bells for me, but I can't find where it's been reported. -Ben [56571.411824] BUG: unable to handle kernel NULL
Any chance you could order the patches not depending on my buffer work first? Given that it still trips up some problems getting the easier patches in ASAP would be a good thing. That especially appl
Ok, do you rmmod the xfs.ko module and insert new ones, or just reboot whenever you have a new module for testing? I'm assuming that you are unloading and reloading based on the "[last unloaded: xfs]
Which is failing on this: (gdb) l *(xfs_log_space_wake+0x17) 0xffffffff81482cb7 is in xfs_log_space_wake (fs/xfs/xfs_log.c:844). 839 struct xfs_mount *mp) 840 { 841 struct log *log = mp->m_log; 842 i