From: Neil Brown <neilb@suse.de>
To: bugme-daemon@bugzilla.kernel.org
Cc: Greg KH <greg@kroah.com>, linux-kernel@vger.kernel.org
Subject: Re: SCSI discover order strangeness [Bug 8412] New: CONFIG_MOUSE_PS2 makes RAID detection fail
Date: Tue, 1 May 2007 19:46:36 +1000 [thread overview]
Message-ID: <17975.3196.435174.722895@notabene.brown> (raw)
In-Reply-To: message from bugme-daemon@bugzilla.kernel.org on Tuesday May 1
[Please reply-to-all rather than replying through bugzilla so that
people on cc list get to see replies...
I hope bugzilla can pick the Bug number out of the middle of the
subject line....]
On Tuesday May 1, bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8412
>
> Summary: CONFIG_MOUSE_PS2 makes RAID detection fail
Based on subsequent comments, I think you got that backwards - absense
of CONFIG_MOUSE_PS2 makes RAID detection fail, but no matter..
> Kernel Version: 2.6.21
> Status: NEW
> Severity: low
> Owner: io_md@kernel-bugs.osdl.org
> Submitter: shutdown@brend.org
>
> Problem Description: If a kernel without CONFIG_MOUSE_PS2 enabled is used, the
> kernel won't detect my RAID1 array, but the hard drives it consits of are
> properly detected and the partition type reads "FD - Linux Raid Autodetect" as well.
> No /dev/md0 is created while booting the kernel.
> I built 2.6.21 with the same .config except for CONFIG_MOUSE_PS2 twice for
> testing purposes and discovered this weird thing.
> I'm going to attach the .config (without CONFIG_MOUSE_PS2), the dmesg of this
> kernel as well as the CONFIG_MOUSE_PS2-enabled kernels dmesg.
In the failure case, the SCSI drives (sdb, sdc) on which your raid
resides are not getting detected until after md initialisation has
decided that there is nothing to assemble.
My first thought was that the new threaded device discovery was
allowing md init to happen before scsi discovery was complete. Maybe
the presence of CONFIG_MOUSE_PS2 makes some bit go faster...
However
# CONFIG_SCSI_SCAN_ASYNC is not set
so maybe not...
Greg (or anyone else reading): you know about this threaded
discovery.. could it allow some discovery to complete after userspace
has started, and does CONFIG_SCSI_SCAN_ASYNC affect it?
I think you best bet is to not depend on raid-auto-detect but to run
mdadm to assemble your arrays instead. As your root isn't on md/raid,
that should be trivial to arrange.
NeilBrown
next parent reply other threads:[~2007-05-01 9:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200705010918.l419IC8B016596@fire-2.osdl.org>
2007-05-01 9:46 ` Neil Brown [this message]
2007-05-02 3:31 ` Greg KH
2007-05-07 4:22 ` Neil Brown
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=17975.3196.435174.722895@notabene.brown \
--to=neilb@suse.de \
--cc=bugme-daemon@bugzilla.kernel.org \
--cc=greg@kroah.com \
--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®