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

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".

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

On Tue, 27 May 2008, Henrik Carlqvist wrote:

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

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

> On Tue, 27 May 2008, Henrik Carlqvist wrote:
>
> > Dominic-Luc Webb <dlwebb@canit.se> 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

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

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

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 shit 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

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

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