Kernel panic when scrub is used

Kernel panic when scrub is used

[Jérôme Poulin]

I experience a kernel panic with "General protection fault" when doing
a scrub on Kernel 3.8-rc7.

Here is a screenshot: http://tinypic.com/r/34r6nad/6

The weird part is that the scrub completes from initramfs, but when
system is fully booted, is kernel panics every time in the low
percentage. (<10%)

Re: Kernel panic when scrub is used

[Arne Jansen]

On 02/18/13 18:14, Jérôme Poulin wrote:
> I experience a kernel panic with "General protection fault" when doing
> a scrub on Kernel 3.8-rc7.
> 
> Here is a screenshot: http://tinypic.com/r/34r6nad/6

I'd love to see the first stacktrace...

> 
> The weird part is that the scrub completes from initramfs, but when
> system is fully booted, is kernel panics every time in the low
> percentage. (<10%)
> --
> 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
> 

Re: Kernel panic when scrub is used

[Jérôme Poulin]

Here you go, I also added 2 other screenshots of the same problem.
http://tinypic.com/r/5ckgug/6
http://tinypic.com/r/t0i9t4/6
http://tinypic.com/r/2r3xdvl/6

On Mon, Feb 18, 2013 at 12:37 PM, Arne Jansen <lists@die-jansens.de> wrote:
> On 02/18/13 18:14, Jérôme Poulin wrote:
>> I experience a kernel panic with "General protection fault" when doing
>> a scrub on Kernel 3.8-rc7.
>>
>> Here is a screenshot: http://tinypic.com/r/34r6nad/6
>
> I'd love to see the first stacktrace...
>
>>
>> The weird part is that the scrub completes from initramfs, but when
>> system is fully booted, is kernel panics every time in the low
>> percentage. (<10%)
>> --
>> 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
>>
>

Re: Kernel panic when scrub is used

[Arne Jansen]

On 02/18/13 18:53, Jérôme Poulin wrote:
> Here you go, I also added 2 other screenshots of the same problem.
> http://tinypic.com/r/5ckgug/6
> http://tinypic.com/r/t0i9t4/6
> http://tinypic.com/r/2r3xdvl/6

do you have any idea how I can reproduce it here?

-Arne

> 
> On Mon, Feb 18, 2013 at 12:37 PM, Arne Jansen <lists@die-jansens.de> wrote:
>> On 02/18/13 18:14, Jérôme Poulin wrote:
>>> I experience a kernel panic with "General protection fault" when doing
>>> a scrub on Kernel 3.8-rc7.
>>>
>>> Here is a screenshot: http://tinypic.com/r/34r6nad/6
>>
>> I'd love to see the first stacktrace...
>>
>>>
>>> The weird part is that the scrub completes from initramfs, but when
>>> system is fully booted, is kernel panics every time in the low
>>> percentage. (<10%)
>>> --
>>> 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
>>>
>>

Re: Kernel panic when scrub is used

[David Sterba]

On Mon, Feb 18, 2013 at 12:53:28PM -0500, Jérôme Poulin wrote:
> http://tinypic.com/r/2r3xdvl/6

At the top of the listing there's apparent trace of a WARN_ON issued and
it's in read_extent_buffer

4660 void read_extent_buffer(struct extent_buffer *eb, void *dstv,
4661                         unsigned long start,
4662                         unsigned long len)
4663 {
4664         size_t cur;
4665         size_t offset;
4666         struct page *page;
4667         char *kaddr;
4668         char *dst = (char *)dstv;
4669         size_t start_offset = eb->start & ((u64)PAGE_CACHE_SIZE - 1);
4670         unsigned long i = (start_offset + start) >> PAGE_CACHE_SHIFT;
4671
4672         WARN_ON(start > eb->len);
4673         WARN_ON(start + len > eb->start + eb->len);

4674
4675         offset = (start_offset + start) & ((unsigned long)PAGE_CACHE_SIZE - 1);
4676
4677         while (len > 0) {
4678                 page = extent_buffer_page(eb, i);
4679
4680                 cur = min(len, (PAGE_CACHE_SIZE - offset));
4681                 kaddr = page_address(page);
4682                 memcpy(dst, kaddr + offset, cur);

first segfault happens at memcpy, it's likely a bad value in 'offset'
calculated from bogus values in 'eb'. With some luck we can guess at which page
it happend (which of RBX=11, RCX=2, RDX=1 holds value of 'i') or what are
values of other variables.

4683
4684                 dst += cur;
4685                 len -= cur;
4686                 offset = 0;
4687                 i++;
4688         }
4689 }

Was the filesystem created with nodesize > 4k ?

david

Re: Kernel panic when scrub is used

[Jérôme Poulin]

On Wed, Feb 20, 2013 at 8:11 AM, David Sterba <dsterba@suse.cz> wrote:
> Was the filesystem created with nodesize > 4k ?

Yes; 64KB.

root@p4:~ btrfs-show-super /dev/sda4
superblock: bytenr=65536, device=/dev/sda4
---------------------------------------------------------
csum 0x799cb7d1 [match]
bytenr 65536
flags 0x1
magic _BHRfS_M [match]
fsid 73f86413-2368-4cf8-8371-71a44d6d8bb3
label p4-btrfsRoot
generation 172418
root 27028815872
sys_array_size 226
chunk_root_generation 171189
root_level 0
chunk_root 27538685952
chunk_root_level 0
log_root 27049787392
log_root_transid 0
log_root_level 0
total_bytes 15415397888
bytes_used 9044217856
sectorsize 4096
nodesize 65536
leafsize 65536
stripesize 4096
root_dir 6
num_devices 4
compat_flags 0x0
compat_ro_flags 0x0
incompat_flags 0xab
csum_type 0
csum_size 4
cache_generation 172418
dev_item.uuid c0494d4e-82ad-4241-9a05-c3f2a1d31bd7
dev_item.fsid 73f86413-2368-4cf8-8371-71a44d6d8bb3 [match]
dev_item.type 0
dev_item.total_bytes 3853848576
dev_item.bytes_used 2973761536
dev_item.io_align 4096
dev_item.io_width 4096
dev_item.sector_size 4096
dev_item.devid 1
dev_item.dev_group 0
dev_item.seek_speed 0
dev_item.bandwidth 0
dev_item.generation 0

Re: Kernel panic when scrub is used

[Jérôme Poulin]

On Wed, Feb 20, 2013 at 1:42 PM, Jérôme Poulin <jeromepoulin@gmail.com> wrote:
> On Wed, Feb 20, 2013 at 8:11 AM, David Sterba <dsterba@suse.cz> wrote:
>> Was the filesystem created with nodesize > 4k ?
>
> Yes; 64KB.

I just noticed I didn't mention that I have raid5/6 code merged in but
it never was used on the partition I scrubbed.