On Fri, July 06, 2012 at 16:40 (+0200), Chris Mason wrote: > On Fri, Jul 06, 2012 at 08:33:51AM -0600, Sami Liedes wrote: >> On Fri, Jul 06, 2012 at 12:42:50PM +0200, Jan Schmidt wrote: >>> I've no good idea at the moment how to go on. It might help to get a >>> feeling if >>> it's shifting around at least a little bit or really constant in the timing >>> of >>> occurrence. So can you please apply the next patch on top of the other two >>> and >>> give it some more failure tries? The "checksum mismatch [1234]" line will >>> be of >>> most interest. I'm also curious what the additional debug variables will >>> say in >>> the extended version of the very first printk. You can leave out the stack >>> traces if you like, they won't matter much anyway. >> >> Ok. Also turned on CONFIG_DEBUG_PAGEALLOC and CONFIG_SLUB_DEBUG_ON as >> suggested by Chris Mason. >> >> With those and the latest patch, there's an oops already at boot. I >> don't have netconsole yet at that point, but here's the important >> parts (sure I can capture it fully if you need). >> >> By the way, something seems to be untabifying your patches. I don't >> know if it's on my side or yours, but at least some other patches I >> receive via linux-btrfs contain tabs. Doing a M-x tabify in emacs >> mostly makes them apply cleanly for me. >> >> Sami >> >> >> ------------------------------------------------------------ >> btrfs: disk space caching is enabled >> BUG: unable to handle kernel NULL pointer dereference at 0000000000000150 >> IP: [<ffffffffa0223568>] check_node+0x138/0x250 [btrfs] > > This isn't from any of the new debugging. Can you please try it on an > unpatched kernel?
You're confusing that with check_leaf. I added check_node along the way, see my mail from Thu, July 05, 2012 at 15:41 (+0200). I'd really like to add something similar for the 3.6 series. Checking for the null pointer dereference. -Jan -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
