On 2008-05-27, Dan C <youmustbejoking@lan.invalid> 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

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.

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

On Tue, 27 May 2008 19:54:58 +0200
Dominic-Luc Webb <dlwebb@canit.se> 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.

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

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

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

Dominic-Luc Webb <dlwebb@canit.se> 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 **
************************************************** ******************

On 2008-05-27, Dan C <youmustbejoking@lan.invalid> 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

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