can't load modules - update - Slackware

This is a discussion on can't load modules - update - Slackware ; This is a Slackware 12.0 system with kernel 2.6.21. Updating on the loading modules problem, I see that an installer program for the quickcam module is finding that I have an SMP enabled kernel and this warns about a mismatch ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

Thread: can't load modules - update

  1. can't load modules - update


    This is a Slackware 12.0 system with kernel 2.6.21.

    Updating on the loading modules problem, I see that an
    installer program for the quickcam module is finding that
    I have an SMP enabled kernel and this warns about a
    mismatch between module and kernel. However, "uname -a"
    indicates a non-SMP kernel on this P4 box. Building a new
    custom non-SMP P4 kernel has now made things even worse.

    Did "make", "make install" (don't remember if this is needed
    for this OS, but never caused problems before), "make modules",
    "make modules_install". I then rebooted. Lilo boot manager is
    installed/used and vmlinuz kernel is present with rest of OS
    in first partitiion of /dev/hda under /boot. Pretty standard.
    I then reboot. Lilo launches, and usual couple dozen lines
    about finding hardware prints to screen. Then I get an error
    that no filesystem could mount root. This is followed by
    a kernel panic. Checking and double checking (booting with
    Slackware 11.0 install CD using test26.s), OS and kernel are
    present at /dev/hda1. During bootup with this CD, I set
    "root=/dev/hda1", which works. Looking through "make
    menuconfig", the filesystem support (ext2) was selected. In
    fdisk, boot flag is correctly set to /dev/hda1.

    Not finding the file system is a confusing error. Liloconfig
    indicates correct partition is set for lilo boot. Lilo must be
    finding the vmlinuz kernel at the correct partition, but then
    the kernel is not able to find a file system to mount on the
    same partition where vmlinuz itself resides. I have only seen
    this error in the past when a fs was truly not supported, and
    I have now tried with an without inclusion of ext3, etc without
    luck.

    I am not finding anything in the /usr/src/linux directory
    to explain how to solve this. Any ideas?

    Dominic


  2. Re: can't load modules - update

    Hallo, Dominic-Luc,

    Du meintest am 26.05.08:

    > Did "make", "make install" (don't remember if this is needed
    > for this OS, but never caused problems before), "make modules",
    > "make modules_install". I then rebooted. Lilo boot manager is
    > installed/used and vmlinuz kernel is present with rest of OS
    > in first partitiion of /dev/hda under /boot. Pretty standard.
    > I then reboot. Lilo launches, and usual couple dozen lines
    > about finding hardware prints to screen. Then I get an error
    > that no filesystem could mount root. This is followed by
    > a kernel panic.


    What tells "rdev /boot/vmlinuz"?

    By the way: if you make your own kernel it's no good idea to throw away
    the old one; I prefer putting every self made kernel in its own
    directory under "/boot", together with its system map, configuration
    file and initramdisk. "/etc/lilo.conf" can show many kernels which are
    separated in this way.

    Viele Gruesse
    Helmut

    "Ubuntu" - an African word, meaning "Slackware is too hard for me".


  3. Re: can't load modules - update

    Dominic-Luc Webb wrote:
    > However, "uname -a" indicates a non-SMP kernel on this P4 box.


    The fact that "uname -a" doesn't mention anything about SMP is no
    guarantee that the a home-brewed kernel does not support SMP. The "SMP"
    string that you can see with "uname -a" is only a string that can set to
    any contents when you configure your kernel. If you so wish you can call
    your kernel 2.6.21-Dominic. However, this string is usually used to get
    the right moduels with the right kernel. Your kernel and your modules
    should have the same support for SMP and the same support for high memory.

    > Not finding the file system is a confusing error.


    Unless you use an initial ramdisk your kernel needs built in support for
    anything needed to mount your root file system. This includes the file
    system (reiserfs? ext3? xfs?) and your controller (SATA? SCSI?).

    regards Henrik
    --
    The address in the header is only to prevent spam. My real address is:
    hc3(at)poolhem.se Examples of addresses which go to spammers:
    root@localhost postmaster@localhost


  4. Re: can't load modules - update

    On Tue, 27 May 2008, Henrik Carlqvist wrote:

    > Dominic-Luc Webb wrote:
    > > However, "uname -a" indicates a non-SMP kernel on this P4 box.

    >
    > The fact that "uname -a" doesn't mention anything about SMP is no
    > guarantee that the a home-brewed kernel does not support SMP. The "SMP"



    Agreed that this can be changed, but it sounds really bizarre that
    someone would have deliberately made the kernel build behave such
    that SMP support is not indicated by uname. Anyway, I am now going
    for custom built kernels and simultaneously building modules, so
    this will hopefully be a non-issue. Going back and forth between
    SMP and non-SMP builds, uname appears to be reporting SMP support
    correctly.


    > > Not finding the file system is a confusing error.

    >
    > Unless you use an initial ramdisk your kernel needs built in support for
    > anything needed to mount your root file system. This includes the file
    > system (reiserfs? ext3? xfs?) and your controller (SATA? SCSI?).
    >
    > regards Henrik


    This I have understood from the start. This system is a P4
    generation with IDE and ext2 filesystem. I have checked and double
    checked built-in support (i.e., not module) for ext2, etc. I
    cannot find anything missing so far. In fact, the generic
    kernel boots properly. When I did the custom build, the only thing
    I changed from the default kernel source was to add built-in
    ext2 support because ext2 is not selected, even as a module,
    any longer by default. I also removed SMP since this is not an
    SMP machine. I interpret all this to mean that the config file
    provided in Slackware 12.0 is not the one used to build the
    generic kernel because the generic kernel does support and
    mount the ext2 filesystem. I know from earlier experience that
    the default built-in support for ext3 will not mount ext2
    file system.

    Any suggestions how to efficiently trouble-shoot this kernel
    panic? I can mount the drive using install CD to go through
    "make menuconfig", "rdev /boot/vmlinuz", etc.

    Dominic


  5. Re: can't load modules - update


    On Tue, 27 May 2008, Dominic-Luc Webb wrote:

    > On Tue, 27 May 2008, Henrik Carlqvist wrote:
    >
    > > Dominic-Luc Webb wrote:
    > > > However, "uname -a" indicates a non-SMP kernel on this P4 box.

    > >
    > > The fact that "uname -a" doesn't mention anything about SMP is no
    > > guarantee that the a home-brewed kernel does not support SMP. The "SMP"


    Just a thought! Slackware 12.0 installed both SMP and non-SMP
    kernels into the /boot directory and then apparently copied the
    non-SMP kernel to vmlinuz. During installation, I selected to
    install a kernel from the distro DVD and that's what happened.
    I guess it would be possible for some module installer software,
    like the one for the present quickcam module, to have found
    those SMP kernels, which are not actually running this box,
    and falsely reported an SMP supported kernel. Whether it is
    this or something else, I suspect there is some misreporting
    somewhere, and that uname -a is correctly reporting the
    specific kernel that is actually running the machine.

    Dominic


  6. Re: can't load modules - update

    Dominic-Luc Webb wrote:
    > Updating on the loading modules problem, I see that an
    > installer program for the quickcam module is finding that
    > I have an SMP enabled kernel and this warns about a
    > mismatch between module and kernel. However, "uname -a"
    > indicates a non-SMP kernel on this P4 box. Building a new
    > custom non-SMP P4 kernel has now made things even worse.


    As has been said before: the default sources (kernel-source
    package) has this in its .config:
    CONFIG_SMP=y
    so everything built _against_ those sources will see a SMP kernel,
    even though your _installed_ kernel may be a different one.

    > I am not finding anything in the /usr/src/linux directory
    > to explain how to solve this. Any ideas?


    Read the .config in that dir and also there is a README somewhere
    on the distribution, which tells you what to do IF you want
    to build drivers for a non-SMP kernel (just looked for it:
    extra/linux-2.6.24.5-nosmp-sdk/README.TXT
    is the file I mean).
    But SMP _is_ the default as most cpu's will run just as fast with
    the SMP kernel, even if they're single cpu/core themselves, so there
    is mostly no reason to specifically build a non-SMP kernel.
    --
    ************************************************** ******************
    ** Eef Hartman, Delft University of Technology, dept. EWI/TW **
    ** e-mail: E.J.M.Hartman@math.tudelft.nl, fax: +31-15-278 7295 **
    ** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
    ************************************************** ******************

  7. Re: can't load modules - update

    On Tue, 27 May 2008, Eef Hartman wrote:

    >
    > As has been said before: the default sources (kernel-source
    > package) has this in its .config:
    > CONFIG_SMP=y


    I will check once again, but deliberately configured mine
    when uname -a reported no SMP as follows:

    CONFIG_SMP=n


    > But SMP _is_ the default as most cpu's will run just as fast with
    > the SMP kernel, even if they're single cpu/core themselves, so there
    > is mostly no reason to specifically build a non-SMP kernel.


    Interesting! From beginning, I just did standard Slackware
    12.0 install and selected kernel from distro DVD during
    system configuration for this single CPU P4 box. After reboot,
    "uname -a" reports kernel version without the -SMP extension.
    I guess that particular "uname -a" could have been misleading.
    So does "-SMP" only get reported by uname on machines that
    actually have a multi-processor, even though it is always
    enabled by default?


    Dominic


  8. Re: can't load modules - update

    On Tue, 27 May 2008 16:36:02 +0200, Dominic-Luc Webb wrote:

    > Interesting! From beginning, I just did standard Slackware 12.0 install
    > and selected kernel from distro DVD during system configuration for this
    > single CPU P4 box. After reboot, "uname -a" reports kernel version
    > without the -SMP extension. I guess that particular "uname -a" could
    > have been misleading. So does "-SMP" only get reported by uname on
    > machines that actually have a multi-processor, even though it is always
    > enabled by default?


    The "-SMP" gets reported (or not) at the sole discretion of whomever
    compiled the kernel (and configured the .config file). It's a simple text
    string that can be *anything* you desire. It doesn't actually indicate
    the presence of an SMP system CPU or not.

    Here's the output from 'uname -a' on this old laptop I'm using. It's not
    an SMP system, but do you notice the "-danc" string on the kernel version?
    Guess who put that there... I could have put anything I wanted there,
    including "SMP", or "Piece of **** old laptop kernel". Get it?

    danc@moria:~$ uname -a
    Linux moria 2.6.25.1-danc #1 PREEMPT Sat May 3 21:09:12 CDT 2008 i686
    Pentium III (Coppermine) GenuineIntel GNU/Linux
    danc@moria:~$


    --
    "Ubuntu" -- an African word, meaning "Slackware is too hard for me".
    Now filtering out all posts originating from Google Groups.
    The Usenet Improvement Project: http://improve-usenet.org


  9. Re: can't load modules - update

    On Tue, 27 May 2008, Dan C wrote:

    > The "-SMP" gets reported (or not) at the sole discretion of whomever
    > compiled the kernel (and configured the .config file).


    There is nothing at compile time prompting how to change
    this string. Altering it requires additional steps to
    actively changing it. Steps I never take. It would require a
    pretty twisted mind (like a double personality) to actively
    change this string in order to get a mis-reported uname in
    order to have to trouble-shoot. I'm really not that bad,
    and no split personality. I leave this string alone.
    I have seen that string change based solely on whether I
    have enabled SMP support in "make menuconfig" and run it on
    a P4 vs Core2Duo.

    I am hoping attention can focus on how modules end up
    getting loaded properly assuming the poster is not insane.

    Along these lines, "uname -a" reports a non-SMP enabled
    kernel on my Slackware 12.0 machine. Selection of using
    kernels from install DVD during system configuration copied
    a number of kernels onto the /boot directory. Some ended
    with the -SMP extension, and others did not. One of the
    ones not labelled SMP was copied during system configuration
    to vmlinuz. At no point is there a prompt to enter any
    changes to any of these kernels (including strings read
    by "uname -a"). Rebooting the system directly after the
    Slackware system configuration gives a "uname -a" without
    the "-SMP" extension. Kernel and "uname -a" both look like
    non-SMP. I could also mention that Slackware installed
    two kernel source directories, one with, the other without
    -SMP. Both co-exist by default on Slackware 12.0 install.
    That is, two kernels are in /boot and two kernel source
    trees exist under /usr/src/linux. Compiling in ../2.6.21/
    gives a non-SMP kernel, and compiling under ../2.6.21-SMP/
    gives an SMP kernel. Clear?

    Next:

    I want to install a quickcam module obtained separately
    from a website. It is compiled locally from source code
    while running above non-SMP kernel. Module does not load.
    The sourcecode also comes with a simple program that
    checks for installation problems. That program reports
    that I am running an SMP enabled kernel while uname -a
    and the kernel itself and the kernel config file all
    indicate that it is not SMP enabled.


    Dominic


  10. Re: can't load modules - update

    On Tue, 27 May 2008 19:54:58 +0200, Dominic-Luc Webb wrote:

    >> The "-SMP" gets reported (or not) at the sole discretion of whomever
    >> compiled the kernel (and configured the .config file).


    > There is nothing at compile time prompting how to change
    > this string.


    Correct. It isn't changed at "compile time". It's changed when
    configuring the .config file, prior to compiling (as I already stated).

    > I have seen that string change based solely on whether I
    > have enabled SMP support in "make menuconfig" and run it on
    > a P4 vs Core2Duo.


    No, you haven't. What you may have seen is a different kernel version
    reporting it, because of what source directory you were in when compiling
    the kernel. If you compiled a kernel from the non-SMP source tree, it
    would not report it due to it's .config file not having the string set.
    In the SMP-enabled source tree, the string *is* set in that .config file.

    > I am hoping attention can focus on how modules end up
    > getting loaded properly assuming the poster is not insane.


    We haven't established that yet.

    > Along these lines, "uname -a" reports a non-SMP enabled
    > kernel on my Slackware 12.0 machine. Selection of using
    > kernels from install DVD during system configuration copied
    > a number of kernels onto the /boot directory. Some ended
    > with the -SMP extension, and others did not. One of the
    > ones not labelled SMP was copied during system configuration
    > to vmlinuz. At no point is there a prompt to enter any
    > changes to any of these kernels (including strings read
    > by "uname -a"). Rebooting the system directly after the
    > Slackware system configuration gives a "uname -a" without
    > the "-SMP" extension. Kernel and "uname -a" both look like
    > non-SMP. I could also mention that Slackware installed
    > two kernel source directories, one with, the other without
    > -SMP. Both co-exist by default on Slackware 12.0 install.
    > That is, two kernels are in /boot and two kernel source
    > trees exist under /usr/src/linux. Compiling in ../2.6.21/
    > gives a non-SMP kernel, and compiling under ../2.6.21-SMP/
    > gives an SMP kernel. Clear?


    Always has been clear. Apparently you used an SMP kernel during the
    installation, and then changed (or had it mysteriously change on it's
    own...) to a non-SMP kernel afterwards.

    > I want to install a quickcam module obtained separately from a website.
    > It is compiled locally from source code while running above non-SMP
    > kernel. Module does not load. The sourcecode also comes with a simple
    > program that checks for installation problems. That program reports that
    > I am running an SMP enabled kernel while uname -a and the kernel itself
    > and the kernel config file all indicate that it is not SMP enabled.


    The problem is that you're trying to compile a program against the headers
    that were installed during your system installation (the SMP kernel
    headers). Now that you're not using that SMP kernel, stuff won't compile
    properly. The simple fix is for you to go into the /boot directory, and
    change the symlinks for 'vmlinuz', 'config', and 'System.map' back to the
    SMP kernel which should still be there in that directory. Reboot, and
    then try compiling the webcam module again, and load it. Bet it works.



    --
    "Ubuntu" -- an African word, meaning "Slackware is too hard for me".
    Now filtering out all posts originating from Google Groups.
    The Usenet Improvement Project: http://improve-usenet.org


  11. Re: can't load modules - update

    On 2008-05-27, Dan C wrote:
    > On Tue, 27 May 2008 19:54:58 +0200, Dominic-Luc Webb wrote:
    >
    >>> The "-SMP" gets reported (or not) at the sole discretion of whomever
    >>> compiled the kernel (and configured the .config file).

    >
    >> There is nothing at compile time prompting how to change
    >> this string.

    >
    > Correct. It isn't changed at "compile time". It's changed when
    > configuring the .config file, prior to compiling (as I already stated).
    >
    >> I have seen that string change based solely on whether I
    >> have enabled SMP support in "make menuconfig" and run it on
    >> a P4 vs Core2Duo.

    >
    > No, you haven't. What you may have seen is a different kernel version
    > reporting it, because of what source directory you were in when compiling
    > the kernel. If you compiled a kernel from the non-SMP source tree, it
    > would not report it due to it's .config file not having the string set.
    > In the SMP-enabled source tree, the string *is* set in that .config file.
    >
    >> I am hoping attention can focus on how modules end up
    >> getting loaded properly assuming the poster is not insane.

    >
    > We haven't established that yet.
    >
    >> Along these lines, "uname -a" reports a non-SMP enabled
    >> kernel on my Slackware 12.0 machine. Selection of using
    >> kernels from install DVD during system configuration copied
    >> a number of kernels onto the /boot directory. Some ended
    >> with the -SMP extension, and others did not. One of the
    >> ones not labelled SMP was copied during system configuration
    >> to vmlinuz. At no point is there a prompt to enter any
    >> changes to any of these kernels (including strings read
    >> by "uname -a"). Rebooting the system directly after the
    >> Slackware system configuration gives a "uname -a" without
    >> the "-SMP" extension. Kernel and "uname -a" both look like
    >> non-SMP. I could also mention that Slackware installed
    >> two kernel source directories, one with, the other without
    >> -SMP. Both co-exist by default on Slackware 12.0 install.
    >> That is, two kernels are in /boot and two kernel source
    >> trees exist under /usr/src/linux. Compiling in ../2.6.21/
    >> gives a non-SMP kernel, and compiling under ../2.6.21-SMP/
    >> gives an SMP kernel. Clear?

    >
    > Always has been clear. Apparently you used an SMP kernel during the
    > installation, and then changed (or had it mysteriously change on it's
    > own...) to a non-SMP kernel afterwards.
    >
    >> I want to install a quickcam module obtained separately from a website.
    >> It is compiled locally from source code while running above non-SMP
    >> kernel. Module does not load. The sourcecode also comes with a simple
    >> program that checks for installation problems. That program reports that
    >> I am running an SMP enabled kernel while uname -a and the kernel itself
    >> and the kernel config file all indicate that it is not SMP enabled.

    >
    > The problem is that you're trying to compile a program against the headers
    > that were installed during your system installation (the SMP kernel
    > headers). Now that you're not using that SMP kernel, stuff won't compile
    > properly. The simple fix is for you to go into the /boot directory, and
    > change the symlinks for 'vmlinuz', 'config', and 'System.map' back to the
    > SMP kernel which should still be there in that directory. Reboot, and
    > then try compiling the webcam module again, and load it. Bet it works.


    This has got to be one of the most confused threads I've seen here
    recently. Feeling masochistic this evening, I decided to join in.

    First, while Dan's advice is usually sound, I don't think his advice
    is correct in this case. Namely, I don't see how changing those links
    will do anything.

    Second, looking at my Slack 12.0 installation, I only see one kernel
    source package which only has one set of kernel sources, namely
    /usr/src/linux-2.6.21.5. If you (Dominic-Luc) have directories
    /usr/src/2.6.21 and /usr/src/2.6.21-SMP (or similar) they are of your
    own making, and from what you have told us I can't assume they have
    any relationship to Pat's kernels, including the absence or presence
    of "smp" in the name of the kernel as reported by uname. So when you
    say "Slackware installed two kernel source directories," I'm a bit
    confused about what you mean.

    I'm not familiar with the quickcam module, but I compile a lot of
    3rd-party kernel modules on my systems, and most of them find the
    sources for the running kernel by looking at the target of the symlink
    /lib/modules/`uname -r`/build.

    On my Slack 12.0, both /lib/modules/2.6.21.5/build and
    /lib/modules/2.6.21.5-smp/build point to the same directory, namely
    /usr/src/linux-2.6.21.5. Taking a peek at the .config file there, I
    see
    CONFIG_LOCALVERSION="-smp"
    at line 35. If you copied that .config into your own kernel source
    directory, or if you go in that directory to compile, all of the
    kernels you make should have that as part of the `uname -a` info. As
    Dan reported, that can be anything you want, and is not magically set
    or unset by whether or not you choose CONFIG_SMP=y.

    I haven't read everything you (Dominic-Luc) posted extremely closely,
    partially because I don't think you were explaining everything you did
    carefully enough. If you really want someone here to help you as
    expeditiously as possible, it might be profitable for you to write a
    very unambiguous posting indicating exactly what you did at every
    step, so that people won't be making guesses and assumptions.

    Or not, your choice.

    Cheers and good luck.

    Jim

  12. Re: can't load modules - update

    On Tue, 27 May 2008, Dominic-Luc Webb wrote:

    >
    > On Tue, 27 May 2008, Dan C wrote:
    >
    >> The "-SMP" gets reported (or not) at the sole discretion of whomever
    >> compiled the kernel (and configured the .config file).

    >
    > There is nothing at compile time prompting how to change


    its in the bloody makefile
    VERSION = 2
    PATCHLEVEL = 6
    SUBLEVEL = 24
    EXTRAVERSION = .7-ilovesmp



    --
    Cheers
    Res

    I read usenet and lists in pine. But m$ outlook, thunderbird and gmail
    often use html span/whatever for quotes, makes it hard to tell who said
    what, so I dont try. If I ignore you, thats why! Use a compliant mailer.

  13. Re: can't load modules - update

    On Tue, 27 May 2008 19:32:35 -0300, Jim Diamond wrote:

    >> The problem is that you're trying to compile a program against the headers
    >> that were installed during your system installation (the SMP kernel
    >> headers). Now that you're not using that SMP kernel, stuff won't compile
    >> properly. The simple fix is for you to go into the /boot directory, and
    >> change the symlinks for 'vmlinuz', 'config', and 'System.map' back to the
    >> SMP kernel which should still be there in that directory. Reboot, and
    >> then try compiling the webcam module again, and load it. Bet it works.


    > First, while Dan's advice is usually sound, I don't think his advice
    > is correct in this case. Namely, I don't see how changing those links
    > will do anything.


    Changing those links and rebooting will result in the running kernel (SMP)
    being the same as the installed headers (apparently SMP), and allow the
    module to load properly. Right now his running kernel is not SMP-enabled
    (apparently). Having your running kernel not match the installed headers
    is what causes these kinds of problems.


    --
    "Ubuntu" -- an African word, meaning "Slackware is too hard for me".
    Now filtering out all posts originating from Google Groups.
    The Usenet Improvement Project: http://improve-usenet.org


  14. Re: can't load modules - update

    On Tue, 27 May 2008 19:54:58 +0200
    Dominic-Luc Webb wrote:

    > I leave this string alone. I have seen that string change based
    > solely on whether I have enabled SMP support in "make menuconfig" and
    > run it on a P4 vs Core2Duo.


    With Slackware kernel configs, there are two places where "SMP" might
    show up in uname -a. I'm at a Gentoo machine right now, but its uname -a
    should be good enough to illustrate.

    Linux bellgrove 2.6.24-tuxonice-r4-smp #10 SMP Sun Apr 20 [snip]
    111 222

    1 - doesn't matter, could be anything, as Dan has said
    2 - indicates that my running kernel actually is smp-enabled

    The first one is the result of setting CONFIG_LOCALVERSION -- Patrick
    sets this to "SMP" or something similar for his smp kernels. I'd think
    it's a good idea to change it for kernels you compile yourself.

    The second one is the one that depends an CONFIG_SMP=y.

  15. Re: can't load modules - update


    Thanks for all this input, but sadly, it seems I have uncovered
    some of the mystery and much of it was nothing that any of us
    brought up so far. I do apologize that this got confusing.

    1. Booting
    The bootup problem in which filesystem could not be found
    had little/nothing at all to do with the kernel. Kernel (SMP or
    non-SMP) both worked fine to boot up. The problem was in running
    liloconfig. Running it again without any additional strings
    using the "simple" lilo install booted up fine showing
    something like:

    # rdev vmlinuz
    root = ox0805
    #

    Rather than this with earlier liloconfig, which gave an error
    about not finding a fs to mount as root and kernel panic:

    # rdev vmlinuz
    root = /dev/hda1

    Great! System now boots reliably.

    2. Loading modules
    At this point, headers, modules AND kernel are (believed to be)
    all SMP enabled. All are standard installation as near as I can
    tell. The quickcam module sources I downloaded from a separate
    source was recompiled and still did not load. There is now some
    clutter in this system and I will likely end up just re-installing
    whole thing from beginning, but definitely will re-install kernel
    sources.

    3. Getting both SMP and non-SMP /boot kernels and /usr/src/linux
    source trees.

    Checking, that is somehow what happened on this box. I do not
    know how. I have used Slackware for many years and never seen a
    double kernel/source install like this, but it was system wide.
    Checking the /lib/modules tree, it was double installed there
    too. Since others do not get this, it apparently should not be
    this way and appears to have some connection to my error
    loading modules, I am now working on removing all non-SMP
    enabled files, thinking to just re-install from beginning
    using exclusively SMP enabled everything, since people here
    tell me this is now default even for non-SMP hardware. Easier!

    Thanks for all these tips and sorry for any confusion. I hope
    to report back with success story soon.

    Dominic







  16. Re: can't load modules - update

    On Tue, 27 May 2008, Dan C wrote:

    > >> The problem is that you're trying to compile a program against the headers
    > >> that were installed during your system installation (the SMP kernel
    > >> headers). Now that you're not using that SMP kernel, stuff won't compile
    > >> properly. The simple fix is for you to go into the /boot directory, and
    > >> change the symlinks for 'vmlinuz', 'config', and 'System.map' back to the
    > >> SMP kernel which should still be there in that directory. Reboot, and
    > >> then try compiling the webcam module again, and load it. Bet it works.

    >
    > Changing those links and rebooting will result in the running kernel (SMP)
    > being the same as the installed headers (apparently SMP), and allow the
    > module to load properly. Right now his running kernel is not SMP-enabled
    > (apparently). Having your running kernel not match the installed headers
    > is what causes these kinds of problems.


    I have certainly learned something from you guys. In a nutshell,
    I need to pay close attention to just use exclusively SMP enabled
    everything even on a box without SMP hardware (e.g., P4).

    From the start, I did a pretty standard Slackware install, using
    kernels and sources from the 12.0 distro DVD. I noticed modules
    were not loading and began attacking this problem, starting with
    editing/removing SMP related files/directories because hardware
    is not SMP. This and building a custom non-SMP kernel probably
    just made the problem worse. It is now clear I was in trouble
    since right after installation when I ended up somehow with
    both SMP and nonSMP kernels and sources.

    Dominic





  17. Re: can't load modules - update

    On Tue, 27 May 2008, Q wrote:

    > Linux bellgrove 2.6.24-tuxonice-r4-smp #10 SMP Sun Apr 20 [snip]
    > 111 222
    >
    > 1 - doesn't matter, could be anything, as Dan has said
    > 2 - indicates that my running kernel actually is smp-enabled
    >
    > The first one is the result of setting CONFIG_LOCALVERSION -- Patrick
    > sets this to "SMP" or something similar for his smp kernels. I'd think
    > it's a good idea to change it for kernels you compile yourself.
    >
    > The second one is the one that depends an CONFIG_SMP=y.


    This is how I understood it. I do not think "uname -a" has
    ever mis-reported on my system. WYSIWYG!

    Dominic


  18. Re: can't load modules - update

    Dominic-Luc Webb wrote:
    > # rdev vmlinuz
    > root = ox0805


    To me that is sda5 (first S-ATA or SCSI controller, 08, master, 0,
    partition 5), not hda1.
    /dev/hda is 0x0300, partitions are added TO that value.

    See also the numbers in the /dev directory for those device files:
    brw-rw---- 1 root disk 3, 0 2006-10-11 17:45 /dev/hda
    brw-rw---- 1 root disk 8, 0 2007-09-24 19:42 /dev/sda
    ^^^^
    > # rdev vmlinuz
    > root = /dev/hda1


    That, of course, is much more readable and correct in your case.
    --
    ************************************************** ******************
    ** Eef Hartman, Delft University of Technology, dept. EWI/TW **
    ** e-mail: E.J.M.Hartman@math.tudelft.nl, fax: +31-15-278 7295 **
    ** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
    ************************************************** ******************

  19. Re: can't load modules - update

    On 2008-05-27, Dan C wrote:
    > On Tue, 27 May 2008 19:32:35 -0300, Jim Diamond wrote:
    >
    >>> The problem is that you're trying to compile a program against the headers
    >>> that were installed during your system installation (the SMP kernel
    >>> headers). Now that you're not using that SMP kernel, stuff won't compile
    >>> properly. The simple fix is for you to go into the /boot directory, and
    >>> change the symlinks for 'vmlinuz', 'config', and 'System.map' back to the
    >>> SMP kernel which should still be there in that directory. Reboot, and
    >>> then try compiling the webcam module again, and load it. Bet it works.

    >
    >> First, while Dan's advice is usually sound, I don't think his advice
    >> is correct in this case. Namely, I don't see how changing those links
    >> will do anything.

    >
    > Changing those links and rebooting will result in the running kernel (SMP)
    > being the same as the installed headers (apparently SMP), and allow the
    > module to load properly. Right now his running kernel is not SMP-enabled
    > (apparently). Having your running kernel not match the installed headers
    > is what causes these kinds of problems.


    I think you are confusing the kernel headers with the kernel .config.
    You can generate any number of different kernels from the same version
    of the kernel, and they will all have the same kernel headers (i.e.,
    the files in the .../linux-x.y.z.w/include directory). But, of
    course, they will have different .config files. This is a bit of a
    shortcoming of Slackware, since the .config file in /usr/src/linux/
    can match at most one of the available kernels.

    And if you are using lilo as your boot manager, I don't believe that
    changing the symlinks will do anything without re-running lilo. Grub
    users' mileage may vary.


    Dominic-Luc: you are making this much more difficult than it needs to
    be. Your concern about deleting non-SMP things is probably only
    obfuscating things further.

    Why don't you download a nice new shiny linux-2.6.24.7(*), unpack it
    into some directory of your choice, copy Pat's original .config from
    /usr/src/linux/ into that directory, run "make oldconfig" (or run
    "make menuconfig" or "make xconfig", if you want to go through all the
    options), make a new kernel, install it and the modules, modify your
    /etc/lilo.conf so that you can boot either your new kernel or one of
    the distro kernels, and then reboot. If all goes well, your nice new
    shiny kernel will boot, and from there you can go and try to add your
    quickcam module without worrying about whether you are getting Pat's
    SMP kernel or his non-SMP kernel and which .config matches what.

    (*) When I first installed Slack 12.1 I tried some 2.6.25.x kernel,
    but a number of third-party modules I use would not compile against
    it, so I went back to 2.6.24.7 and everything worked fine. YMMV.

    Cheers.
    Jim

  20. Re: can't load modules - update

    On Wed, 28 May 2008, Jim Diamond wrote:
    > Dominic-Luc: you are making this much more difficult than it needs to
    > be. Your concern about deleting non-SMP things is probably only
    > obfuscating things further.


    This is what I have learned from you guys and now fixing.



    > Why don't you download a nice new shiny linux-2.6.24.7(*), unpack it
    > into some directory of your choice, copy Pat's original .config from
    > /usr/src/linux/ into that directory, run "make oldconfig" (or run
    > "make menuconfig" or "make xconfig", if you want to go through all the
    > options), make a new kernel, install it and the modules, modify your
    > /etc/lilo.conf so that you can boot either your new kernel or one of
    > the distro kernels, and then reboot.


    Right, well I have had real problems with upgrading kernels and
    generally avoid this if not needed. This is a lot of work for
    an older computer in which current kernel already supports
    everything. But thanks for the tip on "make oldconfig". Sounds
    helpful.

    Dominic


+ Reply to Thread
Page 1 of 2 1 2 LastLast