Hi guys, I ran into a bug today with 3.8-rc2 [0], following an "make modules_install && make install" of the kernel. I have been using the same kernel without problems for some days, the only change immediately before the oops was that I switched from plain partitions to using multi-device and subvolumes. Is there any more info I could give? Cheers, Tom [0]: <https://plus.google.com/114015603831160344127/posts/fzEYnF64NkZ> (I''m sorry about the quality of the picture, hopefully it is still useful). -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Mon, Jan 07, 2013 at 01:51:21AM +0100, Tom Gundersen wrote:> I ran into a bug today with 3.8-rc2 [0], following an "make > modules_install && make install" of the kernel. > > I have been using the same kernel without problems for some days, the > only change immediately before the oops was that I switched from plain > partitions to using multi-device and subvolumes. > > [0]: <https://plus.google.com/114015603831160344127/posts/fzEYnF64NkZ>BUG at mm/page-writeback.c:2164 2160 int clear_page_dirty_for_io(struct page *page) 2161 { 2162 struct address_space *mapping = page_mapping(page); 2163 2164 BUG_ON(!PageLocked(page)); btrfs on the stack is only __btrfs_buffered_write + btrfs_file_aio_write, ie. just a buffered write, originating from pwrite64. The bug_on condition is clear, the question is why the page is not locked. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 07, 2013 at 04:10:37AM -0700, David Sterba wrote:> Hi, > > On Mon, Jan 07, 2013 at 01:51:21AM +0100, Tom Gundersen wrote: > > I ran into a bug today with 3.8-rc2 [0], following an "make > > modules_install && make install" of the kernel. > > > > I have been using the same kernel without problems for some days, the > > only change immediately before the oops was that I switched from plain > > partitions to using multi-device and subvolumes. > > > > [0]: <https://plus.google.com/114015603831160344127/posts/fzEYnF64NkZ> > > BUG at mm/page-writeback.c:2164 > > 2160 int clear_page_dirty_for_io(struct page *page) > 2161 { > 2162 struct address_space *mapping = page_mapping(page); > 2163 > 2164 BUG_ON(!PageLocked(page)); > > btrfs on the stack is only __btrfs_buffered_write + > btrfs_file_aio_write, ie. just a buffered write, originating from > pwrite64. > > The bug_on condition is clear, the question is why the page is not > locked.The big question is, can you make it happen again? -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 7, 2013 at 2:00 PM, Chris Mason <chris.mason@fusionio.com> wrote:> The big question is, can you make it happen again?I wish I could, but I don''t want to ;-) At least not on this machine (it is, very foolishly, my work machine). I''ll try to reproduce it in a VM and let you know if/when I manage. Cheers, Tom -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html