From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Sami Liedes <sami.liedes@iki.fi>,
Goldwyn Rodrigues <rgoldwyn@suse.com>, Neil Brown <neilb@suse.de>,
bugzilla-daemon@bugzilla.kernel.org
Cc: linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [Bug 100491] New: Oops under bitmap_start_sync [md_mod] at boot
Date: Mon, 29 Jun 2015 08:28:24 -0400 [thread overview]
Message-ID: <559139E8.9020008@gmail.com> (raw)
In-Reply-To: <20150628205347.GA18403@sli.dy.fi>
[-- Attachment #1: Type: text/plain, Size: 1831 bytes --]
On 2015-06-28 16:53, Sami Liedes wrote:
> On Thu, Jun 25, 2015 at 09:02:45PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
>> https://bugzilla.kernel.org/show_bug.cgi?id=100491
>>
>> Bug ID: 100491
>> Summary: Oops under bitmap_start_sync [md_mod] at boot
> [...]
>> Reading all physical valumes. This may take a while...
>> Found volume group "rootvg" using metadata type lvm2
>> device-mapper: raid: Device 0 specified for rebuild: Clearing superblock
>> md/raid1:mdX: active with 1 out of 2 mirrors
>> mdX: invalid bitmap file superblock: bad magic
>> md-cluster module not found.
>> mdX: Could not setup cluster service (256)
>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000100
>> IP: [<ffffffff8159e4a9>] _raw_spin_lock_irq+0x29/0x70
>> PGD 0
>> Oops: 0002 [#1] PREEMPT SMP
> [...]
>
> I'm marking this as a regression in bugzilla, since this seems to
> prevent booting on 4.1.0 at least in certain circumstances (namely
> those which I have; I wonder if any raid1 recovery works?) while 4.0.6
> boots correctly.
I can confirm having the same issue with the MD code being used through
dm-raid.
>
> I bisected this down to one of four commits. Well, assuming that the
> problem was caused by changes in drivers/md; a fair assumption, I
> think. The commits are:
>
> $ git bisect view --oneline
> f9209a3 bitmap_create returns bitmap pointer
> 96ae923 Gather on-going resync information of other nodes
> 54519c5 Lock bitmap while joining the cluster
> b97e9257 Use separate bitmaps for each nodes in the cluster
My own bisect turned up the same set of commits, although I wouldn't
have the time to go any further with it until next weekend.
>
> The crash happens whether or not CONFIG_MD_CLUSTER is enabled.
Again, same here.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2967 bytes --]
prev parent reply other threads:[~2015-06-29 12:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <12832_1435266173_558C6C7D_12832_48_1_bug-100491-1606@https.bugzilla.kernel.org/>
2015-06-28 20:53 ` [Bug 100491] New: Oops under bitmap_start_sync [md_mod] at boot Sami Liedes
2015-06-29 12:28 ` Austin S Hemmelgarn [this message]
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=559139E8.9020008@gmail.com \
--to=ahferroin7@gmail.com \
--cc=bugzilla-daemon@bugzilla.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
--cc=rgoldwyn@suse.com \
--cc=sami.liedes@iki.fi \
/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;
as well as URLs for NNTP newsgroup(s).