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 this crash.
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 don't
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
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
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
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, nritems
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
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 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 someone
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 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
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
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
occurrence.
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
[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
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 620178657. len
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-tree
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 managed to capture
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
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
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 kernel to not
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
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 not
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 that
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. It's
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 assume
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 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.
28 matches
Mail list logo
