From: Doug Ledford <dledford@redhat.com>
To: Linux Scsi Mailing List <linux-scsi@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Why /dev/sdc1 doesn't show up...
Date: Sun, 17 Nov 2002 14:52:58 -0500 [thread overview]
Message-ID: <20021117195258.GC3280@redhat.com> (raw)
Because module loading of any incestious, cross-locking modules is horked
:-P
NOTE: I suspect the same bug applies to IDE devices as well, but you
wouldn't see it unless you compile your IDE drivers as modules and use
initrd or equivelant to load the modules.
Longer answer:
Device scans happen almost exclusively at either host module init time or
device module init time. At that point in time, either the host the
device is on or the high level driver accessing the device will still be
in it's init_module() routine. That, of course, implies that either
host->hostt->module->live is 0 or that *_template->module->live is 0 (and
consequently so is fops->owner->live == 0). As a result, when you
register sdc with the driverfs code, it then tries to fops->open(sdc) to
read the partition table and then automatically register subdevices.
This fails if you are currently loading sd_mod because fops->owner->live
== 0. This fails if you are loading your low level driver because the
replacement for __MOD_INC_USE_COUNT(sdev->host->hostt->module); in
sd_open() is to instead use try_module_get(sdev->host->hostt->module) and
with the low level driver still in it's init_module() routine, this fails.
For hot plug events when the module is already live, things work fine.
However, that doesn't help hot plug drivers at boot up because when they
register their hot plug table they immediately get called for the devices
that are already present, and in those cases they will have the exact same
problem that we have with non hot plug drivers.
Hrmph...
Working on a fix. Haven't decided how to do it yet. Something as ugly as
adding:
driver_template.module->live = 1;
scsi_register_host(&driver_template);
driver_template.module->live = 0;
in scsi_module.c works, but is too ugly to live (and totally defeats the
purpose of the new module loading code anyway). Oh, and all the high
level drivers would have to do the same thing in their module init
routines in order to make things work properly when the lldd is loaded
before the high level driver.
I could make all the scsi drivers delay bus scans (via a work queue entry
that we don't wait for completion on, but I haven't figured out how to do
that without leaking mem yet, unless I write a special SCSI worker thread
that kfree()'s the work structs on completion...) until after their init
routines have finished (and do the same for the high level scsi drivers),
but that's quite a pain in the ass and doesn't fix IDE. A generic fix
would be preferable.
Suggestions Rusty?
--
Doug Ledford <dledford@redhat.com> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
next reply other threads:[~2002-11-17 19:45 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-17 19:52 Doug Ledford [this message]
2002-11-17 20:01 ` Why /dev/sdc1 doesn't show up Alexander Viro
2002-11-17 20:12 ` Doug Ledford
2002-11-17 20:16 ` Alexander Viro
2002-11-17 23:20 ` Andries Brouwer
2002-11-17 23:45 ` Doug Ledford
2002-11-18 8:52 ` Rusty Russell
2002-11-18 9:51 ` Alexander Viro
2002-11-18 23:49 ` Rusty Russell
2002-11-19 0:08 ` Linus Torvalds
2002-11-19 20:54 ` Rusty Russell
2002-11-20 15:45 ` Linus Torvalds
2002-11-24 22:30 ` Rusty Russell
2002-11-19 0:09 ` Doug Ledford
2002-11-19 20:58 ` Rusty Russell
2002-11-19 0:32 ` Alan Cox
2002-11-18 10:02 ` Roman Zippel
-- strict thread matches above, loose matches on Subject: below --
2002-11-19 5:52 Rusty Russell
2002-11-19 7:12 ` Alexander Viro
2002-11-19 21:29 ` Rusty Russell
2002-11-19 22:33 ` Andries Brouwer
2002-11-19 16:06 ` Doug Ledford
2002-11-19 17:55 ` Jeff Garzik
2002-11-19 21:42 ` Rusty Russell
2002-11-20 23:41 ` john slee
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=20021117195258.GC3280@redhat.com \
--to=dledford@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/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