From: Peter Palfrader <peter@palfrader.org>
To: linux-kernel@vger.kernel.org
Subject: Re: 2.6.16: Oops - null ptr in blk_recount_segments?
Date: Mon, 27 Mar 2006 06:58:23 +0200 [thread overview]
Message-ID: <20060327045823.GW25288@asteria.noreply.org> (raw)
In-Reply-To: <20060327043601.GE27189130@melbourne.sgi.com>
On Mon, 27 Mar 2006, David Chinner wrote:
> > I've seen a few of these since upgrading to 2.6.16 on my x86_64 system:
>
> What did you upgrade from?
2.6.14.2.
> > [14513.189101] Call Trace: <ffffffff80288e8d>{blk_recount_segments+125}
> > [14513.189113] <ffffffff8045ab19>{schedule_timeout+153} <ffffffff8017df90>{__bio_clone+128}
> > [14513.189134] <ffffffff8017dfed>{bio_clone+61} <ffffffff80144a70>{autoremove_wake_function+0}
> > [14513.189143] <ffffffff882576c1>{:dm_crypt:crypt_alloc_buffer+65}
> > [14513.189157] <ffffffff8825813e>{:dm_crypt:crypt_map+174} <ffffffff8823b463>{:dm_mod:__map_bio+83}
> > [14513.189190] <ffffffff8823b6a8>{:dm_mod:__clone_and_map+168} <ffffffff8823b8de>{:dm_mod:__split_bio+174}
> > [14513.189223] <ffffffff8823b9dc>{:dm_mod:dm_request+204} <ffffffff8028b532>{generic_make_request+258}
> > [14513.189243] <ffffffff8028b628>{submit_bio+216} <ffffffff8017e20f>{__bio_add_page+463}
> > [14513.189256] <ffffffff8026bd3e>{xfs_submit_ioend_bio+30} <ffffffff8026bec0>{xfs_submit_ioend+144}
> > [14513.189269] <ffffffff8026cd03>{xfs_page_state_convert+1379} <ffffffff8026d2e0>{linvfs_writepage+176}
>
> This area of XFS changed in 2.6.16; it might be doing something wrong
> with bios that is blowing up later. Then again, it might be something in dm
> that is wrong. Does this happen on non-dmcrypt XFS filesystems you have?
All the Oopses so far had dm_crypt in their backtrace, but then the
non-crypted XFSs don't see that much action. Also, I recently added a
new XFS filesytem to the system. Is there a way to tell which of them
causes the Oops?
> I understand that the recognised way to find introduced a reproducable problem
> like this is to do a git bisect to find the mod that introduced the problem.
> Is it possible for you to do this?
I can certainly try but it usually takes several hours or a at least a
few days to manifest here on my desktop.
--
PGP signed and encrypted | .''`. ** Debian GNU/Linux **
messages preferred. | : :' : The universal
| `. `' Operating System
http://www.palfrader.org/ | `- http://www.debian.org/
next prev parent reply other threads:[~2006-03-27 4:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-27 2:28 Peter Palfrader
2006-03-27 4:36 ` David Chinner
2006-03-27 4:58 ` Peter Palfrader [this message]
2006-03-27 6:10 ` David Chinner
2006-03-28 14:22 ` Jan Engelhardt
2006-03-28 21:38 ` Peter Palfrader
2006-03-28 21:42 ` Nathan Scott
2006-03-29 0:59 ` Peter Palfrader
2006-03-29 8:23 ` Jens Axboe
2006-03-29 4:40 ` Peter Palfrader
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060327045823.GW25288@asteria.noreply.org \
--to=peter@palfrader.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®