From: Doug Ledford <dledford@redhat.com>
To: Pete Zaitcev <zaitcev@redhat.com>
Subject: Re: [PATCH] Fix scsi.c kmod noise
Date: Thu, 9 May 2002 16:41:09 -0400 [thread overview]
Message-ID: <20020509164109.F11386@redhat.com> (raw)
In-Reply-To: <mailman.1020966481.25371.linux-kernel2news@redhat.com> <200205092033.g49KXxG06486@devserv.devel.redhat.com>
On Thu, May 09, 2002 at 04:33:59PM -0400, Pete Zaitcev wrote:
> > [...] This error crops up whenever scsi.c
> > is compiled in (which is fairly common in 2.4, Red Hat Linux does this
> > as well).
>
> > "kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2"
>
> > --- linux/drivers/scsi/scsi.c.OLD Wed May 1 16:33:14 2002
> > +++ linux/drivers/scsi/scsi.c Wed May 1 16:34:46 2002
> > @@ -2389,10 +2389,18 @@
>
> > +/* This doesn't make much sense to do unless CONFIG_SCSI is a module itself.
> > + *
> > + * ~spot <tcallawa@redhat.com> 05012002
> > + */
> > +
> > +#ifdef MODULE
> > #ifdef CONFIG_KMOD
> > if (scsi_hosts == NULL)
> > request_module("scsi_hostadapter");
> > #endif
> > +#endif
> > return scsi_register_device_module((struct Scsi_Device_Template *) ptr);
>
> I do not see how you suppose this should work. What if scsi.c
> is compiled in, and sunesp.c is not? Besides, why are you running
> a kernel with CONFIG_KMOD if exec returns -ENOENT? I suspect
> something is broken in the Aurora land.
Actually, it happens because of the standard initrd. In the initrd we
load scsi_mod first, and on initialization scsi_mod attempt to
request_module the host adapter, but there is no /sbin/modprobe (and no
/etc/modules.conf for modprobe to read either) so you get the error above.
Then, the initrd continues on to load the specific scsi modules. So, in
actuallity, it makes sense to *disable* this entire code section if scsi
is a module because it will *always* be loaded before the host adapter (it
has to for dependancy's sake) and will always be a failure. When compiled
into the kernel I'm not sure it makes any sense either since if the scsi
driver isn't loaded yet, then where would we be getting modprobe and
/etc/modules.conf from? It would either have to be an initrd (in which
case the linuxrc script can load the module manually) or / is on ide (or
something like that) which doesn't depend on our host adapter, in which
case it makes no sense to go around loading things without them being
specifically requested. Personally, I think this code should just die,
period.
--
Doug Ledford <dledford@redhat.com> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
next prev parent reply other threads:[~2002-05-09 20:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.1020966481.25371.linux-kernel2news@redhat.com>
2002-05-09 20:33 ` [PATCH] Fix scsi.c kmod noise Pete Zaitcev
2002-05-09 20:41 ` Doug Ledford [this message]
2002-05-09 22:41 ` Tom 'spot' Callaway
2002-05-09 23:55 ` Christoph Hellwig
2002-05-10 0:46 ` Patrick Mansfield
2002-05-09 17:36 Tom 'spot' Callaway
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=20020509164109.F11386@redhat.com \
--to=dledford@redhat.com \
--cc=zaitcev@redhat.com \
/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