On Tue, 3 Jul 2012 02:01:21 +0300, Sami Liedes wrote:
> Hi,
>
> I just got this oops on a computer running 3.4.2.
>
> A few minutes before I had started "btrfs device scrub /" and had a
> watcher process running "btrfs scrub status /" every 5 seconds. After
> a few gigabytes of scrubbing, I got t
On Sat, Jul 28, 2012 at 03:08:47PM +0300, Sami Liedes wrote:
> I have not yet figured out if this can be reproduced using a pristine,
> smaller btrfs filesystem in raid-1 configuration inside KVM or if
> there's something about my specific filesystem that causes this. I can
> investigate that too;
On Tue, Jul 17, 2012 at 12:29:33AM +0300, Sami Liedes wrote:
> So, currently my idea is to boot the machine with a live USB stick,
> install kvm and make qemu qcow images backed by the real (2*1.1T)
> devices, but writing changes to the qcow images (I dare not mess with
> the actual devices, and do
On Mon, Jul 16, 2012 at 10:20:28AM +0200, Arne Jansen wrote:
> Any news on this? I you give me some hints, I can try to reproduce
> it here.
I've been planning for a few days now to try if it's reproducible in a
virtual machine with the same filesystem images. However I haven't
gotten around to do
Any news on this? I you give me some hints, I can try to reproduce
it here.
-Arne
On 10.07.2012 08:57, Arne Jansen wrote:
> On 10.07.2012 06:16, Sami Liedes wrote:
>> On Mon, Jul 09, 2012 at 11:05:47AM +0200, Arne Jansen wrote:
* Just before the crash:
btrfs: invalid parameters for re
On 10.07.2012 06:16, Sami Liedes wrote:
> On Mon, Jul 09, 2012 at 11:05:47AM +0200, Arne Jansen wrote:
>>> * Just before the crash:
>>> btrfs: invalid parameters for read_extent_buffer: start (32771) > eb->len
>>> (32768). eb start is 2261163409408, level 100, generation
>>> 4412718571037421157
Thanks for doing this, I'll start looking into it right away.
One thing though: it's probably not the contents of struct eb
that's being corrupted, but the data the eb points to. See for
example read_extent_buffer to see how to access it. Sorry for
being unclear on this.
Thanks,
Arne
On 10.07.201
On Mon, Jul 09, 2012 at 11:05:47AM +0200, Arne Jansen wrote:
> > * Just before the crash:
> > btrfs: invalid parameters for read_extent_buffer: start (32771) > eb->len
> > (32768). eb start is 2261163409408, level 100, generation
> > 4412718571037421157, nritems 538968254. len param 17. debug
On 07.07.2012 01:44, Sami Liedes wrote:
> [Retry: I think this mail didn't make it to the list, probably because
> of the 73 kilobyte attached log. Here's a URL to the file:]
>
>http://www.niksula.hut.fi/~sliedes/btrfs-scrub-debug.log.gz
>
> Sami
>
>
>
[Retry: I think this mail didn't make it to the list, probably because
of the 73 kilobyte attached log. Here's a URL to the file:]
http://www.niksula.hut.fi/~sliedes/btrfs-scrub-debug.log.gz
Sami
On Fri, Jul 06, 2012 at 05:
On Fri, Jul 06, 2012 at 10:59:24PM +0300, Sami Liedes wrote:
> I think I might try running it overnight with KMEMCHECK to see if it
> reports something. But for now, what there's in the log:
My KMEMCHECK kernel didn't even boot (due to some weird KMEMCHECK/ACPI
interaction), so I won't pursue this
On Fri, Jul 06, 2012 at 09:02:34AM -0600, Jan Schmidt wrote:
> 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 g
On Fri, July 06, 2012 at 16:33 (+0200), 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
>> o
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
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
> > o
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
On Fri, Jul 06, 2012 at 04:42:50AM -0600, Jan Schmidt wrote:
> ... down here in the stack. The warning is printed from two levels above,
> __readahead_hook.
>
> Either I'm absolutely blind and there's code along the (rather short) road
> between those two that might do this I haven't seen. Or some
On 06.07.2012 01:47, Sami Liedes wrote:
> On Thu, Jul 05, 2012 at 03:41:33PM +0200, Jan Schmidt wrote:
>> I'd like to see if you corrupted your trees on disk in a really strange
>> manner (with matching checksums?), or if data comes from the disk intact
>> and becomes damaged thereafter.
>>
>> Coul
On Thu, Jul 05, 2012 at 03:41:33PM +0200, Jan Schmidt wrote:
> I'd like to see if you corrupted your trees on disk in a really strange
> manner (with matching checksums?), or if data comes from the disk intact
> and becomes damaged thereafter.
>
> Could you store the output of
> btrfs-debug-
On 04.07.2012 22:24, Sami Liedes wrote:
> On Wed, Jul 04, 2012 at 06:38:00PM +0200, Jan Schmidt wrote:
>>> [ 200.980496] btrfs: invalid parameters for read_extent_buffer: start
>>> (32771) > eb->len (32768). eb start is 2243489562624, level 26, generation
>>> 3144240307695375391, nritems 62017
On Wed, Jul 04, 2012 at 06:38:00PM +0200, Jan Schmidt wrote:
> > [ 200.980496] btrfs: invalid parameters for read_extent_buffer: start
> > (32771) > eb->len (32768). eb start is 2243489562624, level 26, generation
> > 3144240307695375391, nritems 620178657. len param 17. debug
> > 2/989/6201786
On 04.07.2012 18:03, Sami Liedes wrote:
> Here you go.
>
> Sami
> [...]
> [ 200.980496] btrfs: invalid parameters for read_extent_buffer: start
> (32771) > eb->len (32768). eb start is 2243489562624, level 26, generation
> 3144240307695375391, nritems 620178657. len param 17. debug
> 2/9
On Wed, Jul 04, 2012 at 01:26:46PM +0200, Jan Schmidt wrote:
> On 04.07.2012 02:17, Sami Liedes wrote:
> > On Wed, Jul 04, 2012 at 01:47:56AM +0300, Sami Liedes wrote:
> >> I've seen this before: An overly long "Modules linked in:" line causes
> >> a large gap in netconsole output.
> >
> > I manag
On 04.07.2012 02:17, Sami Liedes wrote:
> On Wed, Jul 04, 2012 at 01:47:56AM +0300, Sami Liedes wrote:
>> I've seen this before: An overly long "Modules linked in:" line causes
>> a large gap in netconsole output.
>
> I managed to capture the entire output using netconsole by modifying
> the kerne
On Wed, Jul 04, 2012 at 01:47:56AM +0300, Sami Liedes wrote:
> I've seen this before: An overly long "Modules linked in:" line causes
> a large gap in netconsole output.
I managed to capture the entire output using netconsole by modifying
the kernel to not output the list of modules.
Sami
On Tue, Jul 03, 2012 at 04:35:25PM +0200, Jan Schmidt wrote:
> On 03.07.2012 15:58, Sami Liedes wrote:
> > I think I might try setting up that netconsole to see if there are any
> > interesting console messages before the oops... As I said, I also was
> > able to reproduce this on 3.4.4, so ATM I a
On 03.07.2012 15:58, Sami Liedes wrote:
> I think I might try setting up that netconsole to see if there are any
> interesting console messages before the oops... As I said, I also was
> able to reproduce this on 3.4.4, so ATM I assume I'm able to reproduce
> this at will.
That would be helpful. I
On Tue, Jul 03, 2012 at 03:11:04PM +0200, Jan Schmidt wrote:
> > The oops is transcribed from photos, so it may contain some errors. I
>
> You did *what*? :-) Uploading a photo would be fine, just in case that's
> easier
> for you the next time.
Nah, it's sometimes refreshing to do something tha
On Tue, Jul 03, 2012 at 02:01:21AM +0300, Sami Liedes wrote:
> I just got this oops on a computer running 3.4.2.
I now repeated this on 3.4.4. Merely running a "btrfs scrub start /"
causes this after a couple of minutes of running. This time I didn't
run "btrfs scrub status /" in a loop, so that's
> I just got this oops on a computer running 3.4.2.
>
> A few minutes before I had started "btrfs device scrub /" and had a
> watcher process running "btrfs scrub status /" every 5 seconds. After
> a few gigabytes of scrubbing, I got this crash.
>
> The oops is transcribed from photos, so it may
On Tue, Jul 03, 2012 at 02:01:21AM +0300, Sami Liedes wrote:
> The oops is transcribed from photos, so it may contain some errors. I
> tried to be careful, and double checked the backtrace.
Forgot to menion, the fs is a two-partition filesystem, with both data
and metadata mirrored.
-
Hi,
I just got this oops on a computer running 3.4.2.
A few minutes before I had started "btrfs device scrub /" and had a
watcher process running "btrfs scrub status /" every 5 seconds. After
a few gigabytes of scrubbing, I got this crash.
The oops is transcribed from photos, so it may contain s
32 matches
Mail list logo
