lkml.org 
[lkml]   [2002]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Fix scsi.c kmod noise
    On Thu, May 09, 2002 at 06:41:58PM -0400, Tom 'spot' Callaway wrote:

    > I agree, but I didn't want to make any sort of drastic changes to scsi.c
    > in Aurora (I'm still getting my feet wet here!).
    >
    > As to the claim that this is broken solely due to Aurora being broken, I
    > can dispell that simply by pointing to the fact that Red Hat Linux 7.3
    > exhibits this behavior as shipped, on machines where the scsi drivers
    > are modular. dmesg log from 2.4.18-3smp is attached to this email.
    >
    > In fact, sunesp is modular in Aurora, which is how this issue came to
    > light. When I made the change from compiled in to modular (and started
    > using an initrd), several testers reported this as a bug.
    >
    > Feel free to correct me (and Doug) if I'm wrong, because I cede that you
    > know a HELL of a lot more about this than I do. My Aurora kernels use
    > this, the scsi subsystem works (the modules all load as they should),
    > and I don't have a kmod error message in dmesg.
    >
    > For reference, Aurora builds kernels with the following relevant
    > options:
    >
    > CONFIG_MODULES=y
    > CONFIG_MODVERSIONS=y
    > CONFIG_KMOD=y
    >
    > CONFIG_SCSI=y
    > CONFIG_BLK_DEV_SD=y
    >
    > CONFIG_SCSI_SUNESP=m
    >
    >
    > The Red Hat Linux 7.3 i686 config builds kernels with the following
    > relevant options:
    >
    > CONFIG_MODULES=y
    > CONFIG_MODVERSIONS=y
    > CONFIG_KMOD=y
    >
    > CONFIG_SCSI=m
    > CONFIG_BLK_DEV_SD=m
    >
    > CONFIG_SCSI_AIC7XXX=m
    >
    > As a result of further testing and thought, I definitely agree with
    > Doug. The patch that I originally submitted will only get rid of the
    > kmod error noise when BLK_DEV_SD is compiled into the kernel. Perhaps
    > this block of code should die? I'll leave that to the experts to decide.
    >
    > ~spot

    It is the upper level device init/insmod that is driving the load of the
    scsi adapter (in scsi.c), not the init/insmod of scsi.o. I can't think of
    a good reason to just load the scsi adapter if you want it, rather than
    having the init of sd.o load it.

    IMO, it should go away or always happen - not conditionally on whether another
    adapter is already available, or whether sd.o is loading.

    If you are booting without initrd, aren't there lines in /etc/modules.conf
    for scsi_hostadapter?

    If you are booting with initrd, my RH 7.2 mkinitrd shows:

    ln -s /bin/nash $MNTIMAGE/sbin/modprobe

    man nash says:

    Additionally, if nash is invoked as modprobe, it will
    immediately exit with a return code of zero. This is to
    allow initrd's to prevent some extraneous kernel error
    messages during startup.

    -- Patrick
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:26    [W:0.026 / U:32.268 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site