Re: Bug#624131: linux-image-2.6.39-rc4-686-pae: Can somewhat reliably produce kernel panic in btrfs code

Re: Bug#624131: linux-image-2.6.39-rc4-686-pae: Can somewhat reliably produce kernel panic in btrfs code

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]

On Mon, 2011-04-25 at 22:05 +0200, Maik Zumstrull wrote:
> Package: linux-image-2.6.39-rc4-686-pae
> Version: 2.6.39~rc4-1~experimental.1
> Severity: normal
> Tags: experimental
> 
> By simply stressing the system with some I/O, I can make it crash within
> seconds. I'm not setting a higher severity because the bug is in an
> experimental file system in an experimental kernel.

I assume this doesn't happen in 2.6.38?

> Here's the important bits (by my guess) I have on screen from the kernel panic:
> 
> Bug at fs/btrfs/free-space-cache.c:1246
> Bug type: invalid opcode: 0000
> Kernel not tainted, running on an ASUSTek 1005HAG
> EIP is at btrfs_add_free_space+0x285/0x39a [btrfs]

You will probably need to provide a more complete copy of the panic
message.  Let's see what the btrfs developers say.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Bug#624131: linux-image-2.6.39-rc4-686-pae: Can somewhat reliably produce kernel panic in btrfs code

[Maik Zumstrull]

On Mon, Apr 25, 2011 at 22:15, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Mon, 2011-04-25 at 22:05 +0200, Maik Zumstrull wrote:

>> By simply stressing the system with some I/O, I can make it crash within
>> seconds. I'm not setting a higher severity because the bug is in an
>> experimental file system in an experimental kernel.
>
> I assume this doesn't happen in 2.6.38?

Not that I've noticed. I don't use that netbook much, but given how
quickly it happens with .39, I say I would have noticed.

>> Here's the important bits (by my guess) I have on screen from the kernel panic:
>>
>> Bug at fs/btrfs/free-space-cache.c:1246
>> Bug type: invalid opcode: 0000
>> Kernel not tainted, running on an ASUSTek 1005HAG
>> EIP is at btrfs_add_free_space+0x285/0x39a [btrfs]
>
> You will probably need to provide a more complete copy of the panic
> message.

I thought as much, but other than taking a picture of the screen, I
don't know how. I am prepared to cooperate fully in the debugging
effort, though. :-) You or they can tell me what is required.

Re: Bug#624131: linux-image-2.6.39-rc4-686-pae: Can somewhat reliably produce kernel panic in btrfs code

[Peter Stuge]

Maik Zumstrull wrote:
> >> Bug at fs/btrfs/free-space-cache.c:1246
> >> Bug type: invalid opcode: 0000
> >> Kernel not tainted, running on an ASUSTek 1005HAG
> >> EIP is at btrfs_add_free_space+0x285/0x39a [btrfs]
> >
> > You will probably need to provide a more complete copy of the panic
> > message.
> 
> I thought as much, but other than taking a picture of the screen, I
> don't know how.

Take a picture and ideally transcribe it after reboot.


//Peter

Re: Bug#624131: linux-image-2.6.39-rc4-686-pae: Can somewhat reliably produce kernel panic in btrfs code

[cwillu]

On Mon, Apr 25, 2011 at 2:50 PM, Peter Stuge <peter@stuge.se> wrote:
> Maik Zumstrull wrote:
>> >> Bug at fs/btrfs/free-space-cache.c:1246
>> >> Bug type: invalid opcode: 0000
>> >> Kernel not tainted, running on an ASUSTek 1005HAG
>> >> EIP is at btrfs_add_free_space+0x285/0x39a [btrfs]
>> >
>> > You will probably need to provide a more complete copy of the panic
>> > message.
>>
>> I thought as much, but other than taking a picture of the screen, I
>> don't know how.
>
> Take a picture and ideally transcribe it after reboot.

Known issue;  josef sent a patch
(http://permalink.gmane.org/gmane.comp.file-systems.btrfs/10261) that
should fix it, or you can mount with clear_cache on each boot as a
workaround.

Re: Bug#624131: linux-image-2.6.39-rc4-686-pae: Can somewhat reliably produce kernel panic in btrfs code

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

On Mon, 2011-04-25 at 15:05 -0600, cwillu wrote:
> On Mon, Apr 25, 2011 at 2:50 PM, Peter Stuge <peter@stuge.se> wrote:
> > Maik Zumstrull wrote:
> >> >> Bug at fs/btrfs/free-space-cache.c:1246
> >> >> Bug type: invalid opcode: 0000
> >> >> Kernel not tainted, running on an ASUSTek 1005HAG
> >> >> EIP is at btrfs_add_free_space+0x285/0x39a [btrfs]
> >> >
> >> > You will probably need to provide a more complete copy of the panic
> >> > message.
> >>
> >> I thought as much, but other than taking a picture of the screen, I
> >> don't know how.
> >
> > Take a picture and ideally transcribe it after reboot.
> 
> Known issue;  josef sent a patch
> (http://permalink.gmane.org/gmane.comp.file-systems.btrfs/10261) that
> should fix it, or you can mount with clear_cache on each boot as a
> workaround.

This fix doesn't seem to be in your for-linux branch yet.  Please can
you ensure that this (or an alternate fix) is included in 2.6.39.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]