hello, i am trying to rebuild my kernel so that i can use the 1.25gb of ram in my system. right now linux only sees 866mb. the following is an error i get after doing a make oldconfig from my current kernel and adding the highmem support module...
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block (0,0).
other than adding the highmem support i havent touched any other settings from current working debian kernel. here are the steps im following.. am i missing something?
make oldconfig
make xconfig
make
make install
i have tried to do make install_modules but it says there's no target to make.
then i run update-grub.
my current working kernel is 2.6.22-3-486 and im trying to compile the latest kernel (2.6.23.9) from kernel.org.
any ideas what im doing wrong and/or how to fix it?
also, on my current kernel, at boot up i get an error about some libcrypt 1.2.3 version and a message about how it cant resume the device.. so i hit enter to bypass it and linux boots fine. how can i get rid of that error?
bwkaz
12-11-2007, 09:21 PM
the following is an error i get after doing a make oldconfig from my current kernel and adding the highmem support module...
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block (0,0). What's in the .config file when you "make oldconfig"? It needs to be your current kernel's configuration.
The kernel can't magically figure out how your currently-running kernel was configured; oldconfig is really just a way to "upgrade" your .config file from one kernel version to the next. (It reads in .config, then reads in the set of configuration settings that are required, then sets any settings that still exist to their old value, then uses the default (out of arch/*/defconfig) for any new settings that have been added.)
So if you didn't copy your old kernel's .config file, "make oldconfig" won't do you any good...
make oldconfig
make xconfig I assume you set the HIGHMEM_4G option here?
(Have you thought about using a 64-bit kernel? You don't have any of these issues then. :p)
make
make install
i have tried to do make install_modules but it says there's no target to make. That's because the target's name is modules_install, not install_modules. ;)
update-grub I'm not sure what this does, since it's a Debian script or program that I don't use, but does it rebuild your initramfs image? If not, you might need to do that.
jiggolo182
12-12-2007, 07:53 AM
ok, i did not copy my old config file over, wasnt even aware that i had one. this is a new installation of Debian. i did find what appears to be a config file in
/usr/src/linux-headers-2.6.22-3/arch/i386 but it is called Kconfig instead of .config.
yes, i was setting the HIGHMEM_4G option on the new kernel. 64-bit kernel isnt really an option as its an old 32-bit socket A processor.
so, if i never ran 'make modules_install' then that would probably be a reason why i cant boot into the new kernel, right? i guess ill have to try that again.
update-grub just creates the entries in the grub boot loader so that i can boot into the newly installed kernel. i dont think it does anything with the initramfs stuff. i do have mkinitramfs that i can run as root, is that something i would need to run as well?
ph34r
12-12-2007, 09:14 AM
I'll guess that it is an ext3 file system, and you have ext3 as a module and not compiled into the kernel itself.
I like my FS support built in... however, you can use a module instead, it just means that you need an initrd (initial ram disk).
jiggolo182
12-12-2007, 09:39 AM
ok, i just looked in my .config for the 2.6.23.9 kernel and CONFIG_EXT3_FS=m was in there, but i changed it to y, so that should build it into the kernel, correct?
jiggolo182
12-12-2007, 04:50 PM
alright, well i just added the ext3fs into the kernel and rebuilt but i still get the "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block (0,0)." error.
also, any ideas on how to get rid of this error on my working kernel?
"resume: libcrypt version: 1.2.3
resume: could not stat the resume device file. please type in the filename to try again or hit enter to boot the system."
bwkaz
12-12-2007, 08:19 PM
(1) You NEED your old kernel's configuration. (Either that, or you need good knowledge of exactly what your distro expects to be a module, and what hardware you have. Getting a .config file is easier.) You can't just use the defaults that get shipped with the kernel and expect them to work.
(2) Kconfig is not the same as .config. The former is what tells the kernel configuration system which options to show where; the latter is the file that holds your files. You will not have a .config file in a newly-unpacked kernel source; you need to get it from your distro's binary kernel package (or kernel-source package) somehow. If your distro enabled the proper kernel options, you can just zcat /proc/config.gz >.config to get it, but the distro would have had to enable both CONFIG_IKCONFIG and CONFIG_IKCONFIG_PROC. I don't know if any do.
That gets the configuration directly from the running kernel, so it's guaranteed to be correct. There are other options, though: you can hope that your distro stuck the file somewhere that you can get at it (e.g. /boot/config-<version> is somewhat common). Or you can try to find your distro's kernel source package (make sure it's for the correct kernel version and options, e.g. 486/686, smp/non-smp, etc.).
However, there is one final option that I just remembered: Debian has highmem-enabled kernels available. If you have kernel 2.6.22-3-486, try installing 2.6.22-3-486-highmem (or whatever it's called) via apt-get.
You're getting the "can't find resume file" because something is telling your distro to resume from disk, but you didn't suspend-to-disk when shutting down. The only option is to either suspend-to-disk instead of shutting down, or avoid telling it to resume. :)
jiggolo182
12-13-2007, 09:58 PM
ok, so here's what i've tried so far.. still with no success but ive gotten a little farther.. i think.
i created a .config for the new kernel from the current kernel using this method "/boot/config-<version>".. then i did a make oldconfig.. then make xconfig.. added highmem4g support and made sure that ext3 filesystem was compiled into the kernel rather than a module (as ph34r had suggested). make.. make install.. make modules_install.. mkinitrd for the new kernel.. then ran update-grub. the following is the error that i receive when i try to boot into the new kernel...
/bin/cat : /sys/block/sdb/dev : no such file or directory
Device /sys/block/sdb/dev seems to be down
/bin/mknod: missing operand after 'b'
then it repeats that error for sdb1
finally, i get..
mount: special device /dev/sdb1 does not exist
i have tried changing the grub menu to look for /dev/hdb instead of /dev/sdb but that doesnt work either.
any other ideas of what im doing wrong? should i be going about this the "proper debian way"? shouldnt make; make install; make modules_install work just as well?
oh, and i looked in apt-get and debian does not have a highmem kernel available.. or maybe they do but it is in the unstable repository.. im using the testing release.
lastly, in the kernel config i also took out the suspend-to-disk/hibernate options so hopefully if i ever get a new working kernel i wont receive that other error that i get on boot-up.
bwkaz
12-14-2007, 08:14 PM
i created a .config for the new kernel from the current kernel using this method "/boot/config-<version>".. then i did a make oldconfig.. then make xconfig.. added highmem4g support and made sure that ext3 filesystem was compiled into the kernel rather than a module (as ph34r had suggested). make.. make install.. make modules_install.. mkinitrd for the new kernel.. then ran update-grub. the following is the error that i receive when i try to boot into the new kernel... OK, as far as I know, that should have been OK...
/bin/cat : /sys/block/sdb/dev : no such file or directory
Device /sys/block/sdb/dev seems to be down Hmm.
For some reason, some program is trying to get cat to read /sys/block/sdb/dev (if you check on your normal system while it's running under the old kernel, this file should exist -- it'll contain two numbers, separated by a colon). The two numbers are the device major and minor number of the /dev/sdb device file (if you "ls -l" the file, you'll see those same two numbers).
/bin/mknod: missing operand after 'b' This is even more odd -- it almost looks like your initramfs is trying to create the root partition on its own (before it mounts it). But it's failing because the cat failed, because the .../sdb/dev file didn't exist.
Does it still drop to a shell at this point? See what directories exist under /sys/block/ (if any), and what's in the "dev" file in each of them. Also see if you can tell whether udevd is present (e.g. in /bin or /sbin), and (if possible) whether it's running.
any other ideas of what im doing wrong? should i be going about this the "proper debian way"? shouldnt make; make install; make modules_install work just as well? I'm not sure what the "proper Debian way" is, since I don't compile kernels on the Debian machine I use -- but I would think you'd be able to get the custom kernel build to work...
oh, and i looked in apt-get and debian does not have a highmem kernel available.. or maybe they do but it is in the unstable repository.. im using the testing release. So is the machine I was using -- but it's been a while since I looked. Maybe they've removed the highmem kernel, although I wouldn't have thought they'd have done that.
jiggolo182
12-15-2007, 11:38 AM
cat on /sys/block/sdb/dev returns with 8:16 under the current running kernel (2.6.22-3-486).
when i try to boot into the new kernel and receive the errors about /sys/block/sdb/dev it eventually goes into a kernel panic, so i cant really run any commands.
the proper debian way can be found at the following link... http://forums.debian.net/viewtopic.php?t=4468&highlight=kernel+upgrade
lastly, udev is installed on my system under /sbin and it is currently running.. though i cant really check that when i boot into the new kernel since i cant even get to initramfs
bwkaz
12-16-2007, 03:47 PM
Oh, I was thinking the initramfs gave you a shell after it had failed to find whatever it was looking for. If it's not, then it's harder to diagnose the problem because you can't see what the system looks like when the error happens, but you can at least tell whether udev is present in the initramfs image.
Whatever file the initramfs is held in is a gzipped cpio image. So you can do something like zcat /boot/initramfs-blah.cpio.gz | cpio -i -t --absolute-filenames to get the list of all files in the initramfs archive. If that contains a bunch of stuff that looks like udev, then you should have it available.
You might be able to figure out a way to replace the /init script (or binary) in the cpio archive with a symlink to /bin/sh or /bin/bash (depending on which file exists), to get a simple shell. But you'd need to know what was in the /init script to be able to emulate it and see where it fails...
jiggolo182
12-16-2007, 04:14 PM
umm.. so what happens if i dont have a /boot/initramfs file for any of the kernels.. the bad one and the good one? is that something i should have?
bwkaz
12-17-2007, 07:40 PM
Well, you have some initramfs somewhere -- that's what's running the cat / mknod / etc. stuff. :) It may not be called initramfs-<x>, though.
See what your bootloader is using for an initrd (that's what this type of thing was called before kernel 2.6, but an initrd is a full disk, including a filesystem, while an initramfs is just a group of files; the group of files compresses better). That file should be an initramfs image.
If your bootloader doesn't have an initrd line, then it's also possible to build the initramfs right into the kernel, but AFAIK nobody actually does that...
jiggolo182
12-18-2007, 12:22 PM
ok, i do have an initrd file for the new kernel in /boot.. i manually created it with a debian util called yaird.. so would i use mkinitramfs to make a ramfs files? i wonder if perhaps i should try to build this kernel with the debian tutorial and see if i have any better luck. maybe that takes care of some these steps for me. the tutorial still has me make an initrd manually though. thoughts?
bwkaz
12-18-2007, 08:04 PM
Yes, you'll (still?) have to make the initramfs yourself. Even when using Debian kernels, a kernel upgrade rebuilds the initramfs on the target system; it's not part of the distributed kernel package.
Have you looked at whether the udev binaries are in the initramfs image that you generated? I'm not sure where the /init script comes from using yaird, but it may be possible to inject a call to "/bin/bash" in the script right before the point that it gives you that error -- then you'll get a shell, and can look around in the running system. Not sure exactly what to look at, though, other than which modules are loaded and which devices show up.
Following the tutorial might also be a decent thing to try. :)
jiggolo182
12-19-2007, 05:40 PM
ok so i created an initramfs file for the 2.6.23.9 kernel with the command `mkinitramfs -k -o /boot/initramfs-2.6.23.9 2.6.23.9.highmem` then i ran your command to see what all is contained in the image.. i output it to a file so you can look at it.. but it looks like everything i need would be there.. ext3 stuff, udevd, etc..
now do i need to make an entry line in my bootloader to use the initramfs file instead of the initrd file that i have in there now?
if this doesnt work then ill try the debian tutorial.. giving up hope comes after that..
bwkaz
12-19-2007, 08:19 PM
Assuming you use grub, the bootloader line that you need will look something like initrd /boot/initramfs-2.6.23.9 (but possibly without the /boot on the start, depending on whether /boot is a separate partition -- use the same directory name as what's already in the file for the kernel). I.e., make sure it refers to the right file, but the name of the setting will still be "initrd".
I don't think the problem is with ext3, I think the problem is that your disk itself isn't showing up. I don't know why it isn't, though. What hardware is it plugged into? (E.g., IDE, SATA, or something else? Which controller?)
The other thing to try is extracting the /init file out of the initramfs -- something like mkdir temp && cd temp && zcat /boot/initramfs-2.6.23.9 | cpio -i -d should extract everything into a new directory named "temp". The file named "init" here is what the kernel starts up; if that's a shell script, post it. :)
jiggolo182
12-20-2007, 09:10 AM
ok, my linux drive is the seconary drive on the master IDE controller.
yes, i am using grub as my bootloader, ill add that line to the initrd field but im not sure whether i need to put the /boot part.. i dont think i do since its all on one partition.
lastly, i am attaching the 'init' script for you to look at.. thanks!
Bryon Speede
12-21-2007, 12:07 PM
For Debian make sure you compile support for CRAMFS into the kernel, not as a module. Debian (and Debian based) distros use cramfs to read the initrd.
jiggolo182
12-21-2007, 12:58 PM
the following line is found in my .config under Misc Filesystems so i think im ok, in that respect.
CONFIG_CRAMFS=y
bwkaz
12-22-2007, 12:28 PM
ok, my linux drive is the seconary drive on the master IDE controller. So under the old rules for naming, that's /dev/hdb, right? (Of course the SCSI version of that name (/dev/sdX) isn't stable...)
but im not sure whether i need to put the /boot part.. i dont think i do since its all on one partition. If it's all on one partition, then you do need to use /boot. :)
lastly, i am attaching the 'init' script for you to look at.. thanks! OK, after looking at this file, most of the work is actually done in other files. (Figures. ;)) Can you extract the initramfs image again, and post etc/udev/udev.conf (if it exists), conf/arch.conf, conf/initramfs.conf, conf/conf.d/* (all the files), and (finally) scripts/functions? Dumping them into a .zip file might be the best way to get them uploaded.
What does the full kernel command line look like?
Oh -- after looking at this script, you can probably get rid of the other message (in either kernel) by taking out the resume=BLAH kernel command-line parameter. Or, you might be able to add an extra "noresume" parameter, but it's easier to remove the one that's there. :)
For Debian make sure you compile support for CRAMFS into the kernel, not as a module. Debian (and Debian based) distros use cramfs to read the initrd. The initrd, perhaps. Not the initramfs.
ALL initramfs setups use a gzip-compressed CPIO archive. That's the only format that the kernel knows how to handle. (That's also why the initramfs is better (IMO) than the initrd -- with an initrd, you need support in the kernel for the filesystem that was used, plus any compression. With an initramfs, the gunzip algorithm is tiny (and built into the kernel anyway), and the cpio format parser is also tiny (and got built into the kernel starting with 2.6). Plus the kernel already has a filesystem that can be used for this -- ramfs.)
jiggolo182
12-22-2007, 08:02 PM
yes, under older kernels my linux drive is seen as /dev/hdb but for this new kernel (im running testing, i believe) i have to use /dev/sdb to get it to work. the same goes for mounting other drives as well.
i am attaching the files.zip but youll need to rename it files.tar.gz, then you should be able to open/extract it correctly. the resume file that youll see is all that was listed in conf/conf.d/ .
im not sure what you mean by this...
What does the full kernel command line look like?
also, in which file can i take out that 'resume=' call?
bwkaz
12-23-2007, 03:12 PM
the resume file that youll see is all that was listed in conf/conf.d/ . That's interesting -- I wasn't expecting resume to be forced by one of the config files. Hmm... let me see if I can still figure out a way to disable it...
Ah, that "noresume" parameter should be helpful. Assuming you don't have a resume= parameter in the kernel command line (see below), then adding "noresume" should suppress the hardcoded resume device as well. :)
im not sure what you mean by this... The kernel command line is in grub's menu.lst, on the "kernel" line -- for instance, an older kernel on my machine looks like this:
The command line there is everything after the kernel's filename (so "root=/dev/hda11 video=vesafb:mtrr vga=794 ro" in this case; yours will look different).
also, in which file can i take out that 'resume=' call? The same file: grub's menu.lst (/boot/grub/menu.lst). Remove it from the kernel command line, if it's present, and add "noresume" in its place.
Although I still don't have the full picture. (:() How big is the initramfs image itself? Would it be possible to post the whole thing? If not, then at least the entire contents of the "scripts" directory would be useful (and keeping the existing directory structure in place would be necessary, as well)...
jiggolo182
12-24-2007, 01:35 AM
ok, i am attaching the entire contents of the initramfs file and preserving the directory structure as you requested..
in the kernel parameters in the menu.lst file there was no 'resume' but i went ahead and added the noresume line and ill let you know how that works out..
i seem to have encountered the same problem that prompted me to do a full reinstall a few weeks ago.. that is, suddenly my sound card appears to not work anymore.. though it works in windows and shows up in lspci.. alsaconf sees it but i cant use it.. i feel like this is a losing battle! oh well, perhaps its time for a new computer for xmas! im a little off topic now, sorry. anyways, im going to continue to troubleshoot this problem, at least for a little while longer..
ok, so the contents of the initramfs file appear to be too large to upload.. if you give me an email address or something then ill gladly send you the zip file. it is 4.4 MB
bwkaz
12-26-2007, 12:18 AM
in the kernel parameters in the menu.lst file there was no 'resume' but i went ahead and added the noresume line and ill let you know how that works out.. OK -- that should fix the "can't find resume file" message, at least. I don't think it'll fix the whole bootup thing, though.
ok, so the contents of the initramfs file appear to be too large to upload.. Boo.
it is 4.4 MB Does the email interface on this forum let you attach files that big? If not, it may make more sense to try to figure out which files inside the initramfs are that huge, and just exclude them. lib/modules/* and most of /bin and /sbin, for instance, are very likely not needed; if that brings the file down under the forum's size limit, that might make more sense. If not, I can PM you an email address. :)
jiggolo182
12-26-2007, 11:05 PM
adding the noresume to the kernel command line worked.. i dont get the error anymore..
ill PM you a link to where you can download the file..
bwkaz
12-27-2007, 10:41 AM
In that entire zip file, the only call to mknod that tries to create a block device (which I'm looking for because of the "missing operand after 'b'" error) is in the functions file. But the function that tries to do that is supposed to return (i.e. not call mknod) if $ROOT is set to anything that starts with a '/' character (i.e. "root=/dev/sdX" or /dev/hdX should work, although LABEL=x (for some labeled partition) or UUID=x (using some filesystem's UUID), or even /dev/disk/by-path/x (for some by-path symlink) would work better).
The one missing piece of information is the kernel command line (after adding the "noresume" parameter) -- what's that set to?
jiggolo182
12-27-2007, 11:22 AM
the following is the rest of the kernel command line in menu.lst..
root=/dev/hdb1 ro quiet noresume, ive also tried /dev/sdb1 but still get the same errors..
bwkaz
12-28-2007, 09:03 PM
OK, well, now my ideas are all wrong. That command line looks fine. ;)
So let's try adding some debugging stuff to the files in the initramfs, and rebuilding it. Start by deleting init.txt, since that's not needed anymore. Then, edit init, and right before the call to parse_numeric, add the following lines:
echo "BOOT=${BOOT}"
echo "ROOT=${ROOT}"
echo "cmdline:"
cat /proc/cmdline
echo "Contents of /sys/block:"
ls /sys/block Then, after parse_numeric, add the following lines:
echo "New ROOT=$ROOT" Save and exit. To build a new initramfs, you can go into the temp directory and:
Then, as root, move the ../initramfs-test.cpio.gz file to /boot and edit menu.lst to use it instead of the current initramfs file. (Copy your current boot stanza and change just the initrd line; that way you can boot using both initramfs images.) Boot to that initramfs, and post what the script told you (that is, the values of BOOT, ROOT, the contents of /proc/cmdline, and the contents of /sys/block, plus the new value of ROOT after calling parse_numeric).
jiggolo182
12-29-2007, 04:41 PM
ok so this is a little weird.. first of all here's the info you asked for..
then it just hung there.. so i rebooted and tried it again but this time changing the cmdline to /dev/sdb1 and it booted. i swear ive tried that before and it didnt work. anyways so i login and linux now sees all my memory (which was the whole point of installing the new kernel) but it wont let me reinstall my nvidia driver for this kernel. it says there is one already installed (but its for the other kernel), and my sound is still gone. perhaps my disk is going bad and it keeps losing information/files but when it does a fsck everything is clean and the disk is only 6 months old, if that.
last time my sound did this i couldnt get alsa to reinstall its modules.. i might try that again but i ultimately had to reinstall.. that was about a month ago and now the problem is back... maybe i should use debian stable heh.
bwkaz
12-30-2007, 02:49 PM
so i rebooted and tried it again but this time changing the cmdline to /dev/sdb1 and it booted. Good! :)
but it wont let me reinstall my nvidia driver for this kernel. it says there is one already installed (but its for the other kernel), The nvidia driver installer is kinda dumb. If you just change the kernel version, you don't need to reinstall the whole driver, just the kernel part. IIRC, there's an option on the installer that lets you do that; something like --kernel-module-only should work. (You probably also want to add --no-precompiled-interface, to make sure it builds the module instead of trying to use the wrong distro prebuilt module.)
and my sound is still gone. That one I don't know about, but I can see if I can come up with anything obvious. :) By "alsaconf sees it but can't use it", what do you mean: what error are you getting? If the card shows up in lspci, does a driver load automatically? (What driver?) If the driver loads, what does alsamixer say?
jiggolo182
12-31-2007, 12:33 AM
when i run alsaconf it finds the card and lets me configure it.. but when i run alsamixer to try and fix sound levels it says no device found.. and if i open xmms and try to play a song i get an error there too. lspci does show the card.. its an older soundblaster (ca0106) and when i do a lsmod all the modules for the card are listed. a restart on the alsa service doesnt fix the problem either.
bwkaz
01-01-2008, 10:55 AM
when i run alsaconf it finds the card and lets me configure it.. Having never used alsaconf, I'm not sure what that means... ;)
but when i run alsamixer to try and fix sound levels it says no device found. Does it say the same thing if you try to cat a file into /dev/dsp (the OSS device file) or /dev/snd/pcmC0D0p (the Alsa device file for playback on the first device on the first card)? What about trying to run "aplay" on a WAV file? (Also, it'd help to get the exact error: preferably via copy/paste.)
its an older soundblaster (ca0106) and when i do a lsmod all the modules for the card are listed. Assuming that ca0106 is a driver name, I'm guessing that may be an OSS module? Alsa modules all start with snd_, I think. Maybe it'd help to list the modules that are loaded. :)
jiggolo182
01-01-2008, 10:18 PM
alsaconf is just a little util that lets you configure a sound device from the command line.
the soundcard is seen as ca0106 but the lsmod shows snd_ca0106 as well as a few other modules, so they are definitely alsa mods. also, even when i try to play a file in xmms using alsa, oss, esound, etc.. none of them see the card. but the hardware browser shows it and lspci lists it as part of the system..
i can get you the exact alsamixer error tomorrow.. and try the other troubleshooting thing. right now im in Windoze because i need my sound heh..
jiggolo182
01-03-2008, 05:38 PM
ok, so it seems that the problem was this.. i somehow lost all my group information for my account.. so i re-enabled audio, among other things.. and voila.. my sound is back..
bwkaz
01-03-2008, 07:52 PM
Ah, so the error was "permission denied" then, right? That makes more sense. :)
So now everything's working, then?
jiggolo182
01-03-2008, 08:13 PM
well, not exactly.. i still cant get xmms and firefox to share my sound card.. ive tried the /etc/asound.conf file but that hasnt helped..
and ive tried reinstalling the nvidia driver for the new kernel with the following command
sudo sh NVIDIA-Linux-x86-1.0-7185-pkg1.run --kernel-source-path=/usr/src/linux-2.6.23.9/ --kernel-module-only
but i receive the following error in /var/log/nvidia-installer.log
NVIDIA: calling KBUILD...
make CC=cc KBUILD_VERBOSE=1 -C /usr/src/linux-2.6.23.9/ SUBDIRS=/tmp/selfgz
19159/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv modules
test -e include/linux/autoconf.h -a -e include/config/auto.conf || ( \
echo; \
echo " ERROR: Kernel configuration is invalid."; \
echo " include/linux/autoconf.h or include/config/auto.conf are mis
sing."; \
echo " Run 'make oldconfig && make prepare' on kernel src to fix it
."; \
echo; \
/bin/false)
NVIDIA: left KBUILD.
nvidia.ko failed to build!
make[1]: *** [module] Error 1
make: *** [module] Error 2
-> Error.
ERROR: Unable to build the NVIDIA kernel module.
ERROR: Installation has failed. Please see the file
'/var/log/nvidia-installer.log' for details. You may find suggestions
on fixing installation problems in the README available on the Linux
driver download page at www.nvidia.com.
bwkaz
01-04-2008, 08:26 PM
i still cant get xmms and firefox to share my sound card.. Yay AC97 no-hardware-mixing crap. :mad:
ive tried the /etc/asound.conf file but that hasnt helped.. To get my AC97 chipset to do dmix, I had to add this to ~/.asoundrc (I'm not sure whether it's valid in /etc/asound.conf or not -- but it can't hurt to try it in ~/.asoundrc):
pcm.!default {
type plug
slave.pcm dmixer
}
pcm.dmixer {
type dmix
ipc_key 247865
slave {
pcm "hw:0"
period_time 0
period_size 1024
buffer_size 4096
periods 6
rate 48000
}
bindings {
0 0
1 1
}
} You will want to change the ipc_key value, and if you change the "pcm.dmixer", then you'll have to change the "slave.pcm dmixer" line inside the "pcm.!default" section as well.
Also try to match the "rate" to your sound card's native rate, and play with both period_size and buffer_size (and possibly periods?) to avoid sound latency.
sudo sh NVIDIA-Linux-x86-1.0-7185-pkg1.run --kernel-source-path=/usr/src/linux-2.6.23.9/ --kernel-module-only Are you using that old of a driver for any particular reason? I believe the legacy driver (71xx series) is up to 7186 if you need a driver from that series, but the "normal" driver is probably 10 releases newer than that now. (There's also a 9xxx legacy driver for hardware that's newer than the 71xx, but older than the current "normal" driver.) If you want to update, it shouldn't hurt to do so, and it may help with this issue. :)
test -e include/linux/autoconf.h -a -e include/config/auto.conf || ( \
echo; \
echo " ERROR: Kernel configuration is invalid."; \
echo " include/linux/autoconf.h or include/config/auto.conf are mis
sing."; \
echo " Run 'make oldconfig && make prepare' on kernel src to fix it
."; \
echo; \
/bin/false) That throws me off when I see it too -- but this isn't actually an error. It's just what the script would print if it can't find either autoconf.h or auto.conf.
NVIDIA: left KBUILD.
nvidia.ko failed to build!
make[1]: *** [module] Error 1
make: *** [module] Error 2 There should have been more output before this, explaining what failed.
jiggolo182
01-05-2008, 02:59 AM
ok, so i tried your ~/.asoundrc file but that didnt seem to have any effect.. i can try tweaking some settings later and maybe ill get it to work.. ill let you know.
the reason that im using such an old driver is because of the age of my card.. its an ancient GeForce2 Ti card and that driver is the only one that ive ever gotten to work in the last 3 years or so..
i was definitely expecting a little more explanation from the nvidia-installer.log file but as far as i can see there isnt too much more in there that looks like an error. ill post the entire file and you can take a look at it. i did later realize that those werent the actual errors i received but just part of the script itself. the actual error that i receive is the "unable to build kernel module".
honestly, im thinking about making this a windows machine.. this is a fairly old machine to begin with and it seems even slower in linux than it does in windows.. but thats prolly because im running a lot more stuff in linux.. like apache2, ssh, etc... and not being able to use the correct graphics drivers takes away from the system's performance anyways..
here's the nvidia-installer log...
bwkaz
01-05-2008, 08:40 PM
OK, first, start by doing an export LC_ALL=C -- that way you won't start generating stupid UTF-8 files (with MS-word-style "stupid quotes" in them) when plain-ASCII would work just as well. Plus I'd actually be able to read the ASCII version. :p
Second, what I was able to figure out from that log file was that something in your compiler didn't like something in one of the nvidia files, but I can't really tell what, since the random UTF-8 bytes (where quotes would be in the output) make it really hard to tell what's real output from the compiler, and what's random junk characters. So, run the installer with the --extract-only argument, then cd into the newly-created directory (it'll be named after the .run file, just without the .run extension). Then cd usr/src/nv, and make (remember, make sure LC_ALL is set to C). Then paste the result here. :)
(Also, what's your compiler version? cc -dumpversion should tell you that. :))
jiggolo182
01-05-2008, 09:05 PM
hmmm.. well i did the extract.. then cd into usr/src/nv and did make with sudo. no errors were returned. however, im still booted into X as i did the make. does that make a difference?
cc -dumpversion = 4.2.3
ok, i just tried to do a sudo make install after the make and here's the error i get...
**update**
brandon@wembley:~/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv$ sudo make install
NVIDIA: calling KBUILD...
make CC=cc KBUILD_OUTPUT=/lib/modules/2.6.23.9.highmem/build KBUILD_VERBOSE=1 -C /lib/modules/2.6.23.9.highmem/source SUBDIRS= modules
make -C /lib/modules/2.6.23.9.highmem/build \
KBUILD_SRC=/usr/src/linux-2.6.23.9 \
KBUILD_EXTMOD="" -f /usr/src/linux-2.6.23.9/Makefile modules
rm -f include/config/kernel.release
echo 2.6.23.9.highmem > include/config/kernel.release
Using /usr/src/linux-2.6.23.9 as source for kernel
if [ -f /usr/src/linux-2.6.23.9/.config -o -d /usr/src/linux-2.6.23.9/include/config ]; then \
echo " /usr/src/linux-2.6.23.9 is not clean, please run 'make mrproper'";\
echo " in the '/usr/src/linux-2.6.23.9' directory.";\
/bin/false; \
fi;
/usr/src/linux-2.6.23.9 is not clean, please run 'make mrproper'
in the '/usr/src/linux-2.6.23.9' directory.
make[3]: *** [prepare3] Error 1
make[2]: *** [modules] Error 2
NVIDIA: left KBUILD.
nvidia.ko failed to build!
make[1]: *** [module] Error 1
make: *** [install] Error 2
brandon@wembley:~/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv$
**another update**
so after looking at the error, i did 'make mrproper' in /usr/src/linux-2.6.23.9 and then tried to build the nvidia module again, from inside ~/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv.. no such luck. here's the error i get when running 'sudo make install'...
If you are using a Linux 2.4 kernel, please make sure
you either have configured kernel sources matching your
kernel or the correct set of kernel headers installed
on your system.
If you are using a Linux 2.6 kernel, please make sure
you have configured kernel sources matching your kernel
installed on your system. If you specified a separate
output directory using either the "KBUILD_OUTPUT" or
the "O" KBUILD parameter, make sure to specify this
directory with the SYSOUT environment variable or with
the equivalent nvidia-installer command line option.
Depending on where and how the kernel sources (or the
kernel headers) were installed, you may need to specify
their location with the SYSSRC environment variable or
the equivalent nvidia-installer command line option.
*** Unable to determine the target kernel version. ***
bwkaz
01-07-2008, 08:28 PM
however, im still booted into X as i did the make. does that make a difference? Nope. The only time you need to exit out of X is when you try to unload the current kernel module and load the one you just built. The nvidia installer does this as part of the installation, so that's why it forces you to exit X before you run it. But if you're compiling and installing manually, then it doesn't matter: you can exit out of X once the module has installed successfully. :)
cc -dumpversion = 4.2.3 OK. I'm guessing that's fine, although I don't know for sure. It's working fine here with gcc 4.1.1, but I doubt that it's a bug in your gcc version. (That's what I was considering first, even though I really doubt it. Anyway, with the version number, I can go do some more looking if it looks like that may be the problem.)
ok, i just tried to do a sudo make install after the make and here's the error i get... Um, hang on there. The targets that I've always used are module and module-install (so e.g. "make module && make module-install"). I don't know if the "install" target works or not, but I'd stay away from it.
NVIDIA: calling KBUILD...
make CC=cc KBUILD_OUTPUT=/lib/modules/2.6.23.9.highmem/build KBUILD_VERBOSE=1 -C /lib/modules/2.6.23.9.highmem/source SUBDIRS= modules That's wrong. The SUBDIRS should be set to your current directory. So now we have to figure out why that won't work...
make -C /lib/modules/2.6.23.9.highmem/build \
KBUILD_SRC=/usr/src/linux-2.6.23.9 \ That KBUILD_SRC looks wrong, but I'm not sure if it actually is...
KBUILD_EXTMOD="" -f /usr/src/linux-2.6.23.9/Makefile modules And that KBUILD_EXTMOD definitely is. But I'd try to track down why SUBDIRS is wrong, first.
/usr/src/linux-2.6.23.9 is not clean, please run 'make mrproper'
in the '/usr/src/linux-2.6.23.9' directory. DON'T do this!
This will destroy your kernel configuration info. I have no idea why the kernel build system is telling you to do it, but it's NOT a good idea! :)
so after looking at the error, i did 'make mrproper' in /usr/src/linux-2.6.23.9 Um... crud! :(
Do you have the .config file that you used originally when building this kernel? You'll have to copy it back to the kernel source directory and "make oldconfig" before going ANY farther.
If you are using a Linux 2.4 kernel, [...]
If you are using a Linux 2.6 kernel, please make sure
you have configured kernel sources matching your kernel
installed on your system. [...] Yeah, it wasn't able to find a usable (that is, configured) kernel source tree. The "make mrproper" killed that...
Anyway, once you copy back the .config file and run "make oldconfig", we'll have to figure out why SUBDIRS is set wrong. So to try to remove any possible issues, make sure you're booted to the new kernel (it's just easier to do the module build correctly that way).
Then, get back into the usr/src/nv directory, and "make clean". Then "make module", and see if that works. If not, stop -- just post the error. :)
If it does work, then become root (you can compile without root privileges just fine, and in fact if your kernel sources are in /usr, then it's even safer; an nvidia makefile bug can't screw up your kernel), and "make module-install". Again, if you get an error, stop and post it. :)
Although actually, it may also help to figure out what KBUILD_PARAMS is set to if you get an error (in either step). To find out, open up the Makefile.kbuild in any text editor (as long as this editor doesn't replace tabs with spaces: a Makefile must contain tabs in certain places), and at the bottom, add the following:
show-data:
<TAB>@echo "KBUILD_PARAMS=$(KBUILD_PARAMS)"
<TAB>@echo "PWD=$(PWD)" Except, hit the tab key instead of typing in <TAB> (I'm pretty sure the forum software will replace my tab character with spaces, which is why I didn't put tabs in there). Anyway, save and exit, then run "make show-data". It should print out the values of KBUILD_PARAMS and PWD both. Include that with your error message. :)
jiggolo182
01-07-2008, 09:51 PM
Quote:
make -C /lib/modules/2.6.23.9.highmem/build \
KBUILD_SRC=/usr/src/linux-2.6.23.9 \
That KBUILD_SRC looks wrong, but I'm not sure if it actually is...
also, before i did the 'make mrproper' in /usr/src/linux-2.6.23.9 i copied my old .config.. then when i tried to do the nvidia build again and saw that it didnt work, i copied the .config back into the dir and rebuilt the kernel.. didnt bother with installing or anything.. no need, since this one is working with the highmem4g stuff.
ok, now after doing the 'make oldconfig' as you suggested, i ran make clean in the nv dir and then make module.. below is what i get..
brandon@wembley:~/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv$ make module
that part should be ok, right? It may be the right directory in the end, but it should not be using that path to get there. It should be using one of the symlinks in /lib/modules instead.
also, before i did the 'make mrproper' in /usr/src/linux-2.6.23.9 i copied my old .config.. Good! :)
i copied the .config back into the dir and rebuilt the kernel.. You don't have to rebuild the whole kernel, and in fact it's probably better if you don't. (That way you can't accidentally change one of the settings during your normal kernel build process...)
brandon@wembley:~/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv$ make module
NVIDIA: calling KBUILD...
make CC=cc KBUILD_OUTPUT=/lib/modules/2.6.23.9.highmem/build KBUILD_VERBOSE=1 -C /lib/modules/2.6.23.9.highmem/source SUBDIRS=/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv modules That looks much better (note how SUBDIRS is set now ;)).
thousands of lines that look this..
make -C /usr/src/linux-2.6.23.9 O=/usr/src/linux-2.6.23.9 modules
why is the O there.. shouldnt that be an actual variable? O is a variable that the kernel build system uses. (It's the base of the output directory -- the kernel supports building itself so that all the object files go into a different tree, if you don't have write access to the original tree.)
Was there any output before this, after the "make XXXXX modules" above?
and then thousands more that look like this one..
make[x]: *** [modules] Error 2
where x is any number from 2 to 4000+
then finally..
NVIDIA: left KBUILD.
nvidia.ko failed to build!
make[1]: *** [module] Error 1
make: *** [module] Error 2 It sounds like it's choking because there's an infinite loop of dependencies somewhere? The 4000 recursive "make"s sounds wrong. It's also possible that if you don't have write permission to the kernel source tree, something might break (to try to work around this, copy the .config file off again, "make mrproper", then copy it back and "make oldconfig" -- don't build the whole kernel -- then try the nvidia stuff again).
and lastly, i updated the Makefile.kbuild which is what Makefile is symlinked to, and when i run the 'make show-data' i get the following..
make: *** No rule to make target `show-data'. Stop. Oh, dangit, I forgot about the makefile (lowercase initial m). Try this instead:
make -f Makefile.kbuild show-data
("make -f Makefile show-data" would work too.) Also, try adding show-data to the makefile, on the line that looks like this:
module nvidia.o nvidia.ko install nv-linux.o module-install package-install print-module-filename: select_makefile Add it just before the colon (after print-module-filename, add a space and then add show-data). Then run plain old "make show-data"; if you get anything different from the first result, then post both. :)
jiggolo182
01-08-2008, 09:55 PM
ok i seem really screwed here.. in the /usr/src/linux-2.6.23.9 dir when i run 'sudo make mrproper' i get all these errors again.. what the hell did i do?
make -C /usr/src/linux-2.6.23.9 O=/usr/src/linux-2.6.23.9 mrproper and i get similar errors when i do make in the usrc/src/nv dir as well.
however, i did get the make -f Makefile.kbuild to work.. here's the data that it posts..
ok i seem really screwed here.. in the /usr/src/linux-2.6.23.9 dir when i run 'sudo make mrproper' i get all these errors again.. what the hell did i do? Well, I'm not sure -- but I suspect some kind of symlink gone wrong possibly? If the Makefile in the kernel tree is a symlink to the Makefile in the nvidia driver tree, then that might cause this. What I'd do is copy .config off again, delete the kernel tree, re-extract it, copy .config back, "sudo make oldconfig", and then try the nvidia stuff again. (Not under sudo though.)
KBUILD_PARAMS=KBUILD_OUTPUT=/lib/modules/2.6.23.9.highmem/build KBUILD_VERBOSE=1 -C /lib/modules/2.6.23.9.highmem/source SUBDIRS=/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv All that looks OK.
PWD=/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv That's also fine. (Which makes sense, because SUBDIRS is also fine.) At this point I'm guessing the main issue is some screwy file in the kernel tree? If you can get past the 4000-levels-of-make-recursion, you'll hopefully either get an nvidia module built, or a better error message. :)
jiggolo182
01-09-2008, 08:37 PM
ok, heres what ive got so far..
i added the show-data to makefile in usr/src/nv and compared its output to that of make -f Makefile show-data. no differences!
i have copied the kernel source tree back again and done the make oldconfig with the .config that i saved. when i try to build the nvidia module i get this again..
brandon@wembley:~/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv$ make module
If you are using a Linux 2.4 kernel, please make sure
you either have configured kernel sources matching your
kernel or the correct set of kernel headers installed
on your system.
If you are using a Linux 2.6 kernel, please make sure
you have configured kernel sources matching your kernel
installed on your system. If you specified a separate
output directory using either the "KBUILD_OUTPUT" or
the "O" KBUILD parameter, make sure to specify this
directory with the SYSOUT environment variable or with
the equivalent nvidia-installer command line option.
Depending on where and how the kernel sources (or the
kernel headers) were installed, you may need to specify
their location with the SYSSRC environment variable or
the equivalent nvidia-installer command line option.
*** Unable to determine the target kernel version. ***
make: *** [select_makefile] Error 1
so, i run make in the kernel source tree and let it rebuild the version number.. once it does that i stop the build process and try to build the nvidia module again. now i get this error.. which looks a little more helpful..
brandon@wembley:~/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv$ make module
NVIDIA: calling KBUILD...
make CC=cc KBUILD_OUTPUT=/lib/modules/2.6.23.9.highmem/build KBUILD_VERBOSE=1 -C /lib/modules/2.6.23.9.highmem/source SUBDIRS=/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv modules
make -C /lib/modules/2.6.23.9.highmem/build \
KBUILD_SRC=/usr/src/linux-2.6.23.9 \
KBUILD_EXTMOD="/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv" -f /usr/src/linux-2.6.23.9/Makefile modules
test -e include/linux/autoconf.h -a -e include/config/auto.conf || ( \
echo; \
echo " ERROR: Kernel configuration is invalid."; \
echo " include/linux/autoconf.h or include/config/auto.conf are missing."; \
echo " Run 'make oldconfig && make prepare' on kernel src to fix it."; \
echo; \
/bin/false)
mkdir -p /home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/.tmp_versions
rm -f /home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/.tmp_versions/*
WARNING: Symbol version dump /usr/src/linux-2.6.23.9/Module.symvers
is missing; modules will have no dependencies and modversions.
make -f /usr/src/linux-2.6.23.9/scripts/Makefile.build obj=/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv
cc -Wp,-MD,/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/.nv.o.d -nostdinc -isystem /usr/lib/gcc/i486-linux-gnu/4.2.3/include -D__KERNEL__ -Iinclude -Iinclude2 -I/usr/src/linux-2.6.23.9/include -include include/linux/autoconf.h -I/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Os -pipe -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=i486 -mtune=generic -ffreestanding -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -I/usr/src/linux-2.6.23.9/include/asm-i386/mach-default -Iinclude/asm-i386/mach-default -fomit-frame-pointer -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -I/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv -Wall -Wimplicit -Wreturn-type -Wswitch -Wformat -Wchar-subscripts -Wparentheses -Wpointer-arith -Wno-multichar -Werror -O -fno-common -MD -Wsign-compare -Wno-cast-qual -Wno-error -D_LOOSE_KERNEL_NAMES -D__KERNEL__ -DMODULE -DNTRM -D_GNU_SOURCE -D_LOOSE_KERNEL_NAMES -D__KERNEL__ -DMODULE -DNV_MAJOR_VERSION=1 -DNV_MINOR_VERSION=0 -DNV_PATCHLEVEL=7185 -DNV_UNIX -DNV_LINUX -DNV_INT64_OK -DNVCPU_X86 -UDEBUG -U_DEBUG -DNDEBUG -DNV_SIGNAL_STRUCT_RLIM -DNV_MULTIPLE_BRIDGE_AGPGART_PRESENT -DNV_PCI_GET_CLASS_PRESENT -DNV_PM_MESSAGE_T_PRESENT -DNV_PCI_CHOOSE_STATE_PRESENT -DNV_VM_INSERT_PAGE_PRESENT -DNV_REMAP_PFN_RANGE_PRESENT -DNV_CHANGE_PAGE_ATTR_PRESENT -DNV_VMAP_4_PRESENT -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(nv)" -D"KBUILD_MODNAME=KBUILD_STR(nvidia)" -c -o /home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/.tmp_nv.o /home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c
In file included from include/linux/list.h:8,
from include/linux/preempt.h:11,
from include/linux/spinlock.h:49,
from include/linux/seqlock.h:29,
from include/linux/time.h:8,
from include/linux/timex.h:57,
from include/linux/sched.h:53,
from include/linux/utsname.h:35,
from /home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv-linux.h:19,
from /home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c:14:
include/linux/prefetch.h: In function ‘prefetch_range’:
include/linux/prefetch.h:62: warning: pointer of type ‘void *’ used in arithmetic
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c: At top level:
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c:93: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c: In function ‘nvos_create_alloc’:
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c:392: error: ‘nv_pte_t_cache’ undeclared (first use in this function)
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c:392: error: (Each undeclared identifier is reported only once
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c:392: error: for each function it appears in.)
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c: In function ‘nvos_free_alloc’:
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c:429: error: ‘nv_pte_t_cache’ undeclared (first use in this function)
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c: In function ‘nvidia_init_module’:
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c:1332: error: ‘nv_pte_t_cache’ undeclared (first use in this function)
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c:1332: error: too many arguments to function ‘kmem_cache_create’
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c:1466: error: void value not ignored as it ought to be
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c: In function ‘nvidia_exit_module’:
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c:1491: error: void value not ignored as it ought to be
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c:1596: error: ‘nv_pte_t_cache’ undeclared (first use in this function)
make[4]: *** [/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.o] Error 1
make[3]: *** [_module_/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv] Error 2
make[2]: *** [modules] Error 2
NVIDIA: left KBUILD.
nvidia.ko failed to build!
make[1]: *** [module] Error 1
make: *** [module] Error 2
brandon@wembley:~/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv$
still no success but maybe we are getting closer, i hope?
bwkaz
01-10-2008, 07:43 PM
i added the show-data to makefile in usr/src/nv and compared its output to that of make -f Makefile show-data. no differences! OK, that's good. :)
i have copied the kernel source tree back again and done the make oldconfig with the .config that i saved. when i try to build the nvidia module i get this again.. That's surprising. I'm guessing you might want to just build the whole kernel (but don't install it) maybe?
brandon@wembley:~/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv$ make module
<...>
WARNING: Symbol version dump /usr/src/linux-2.6.23.9/Module.symvers
is missing; modules will have no dependencies and modversions. And that's why you probably want to have the whole kernel built. I don't know if this will cause any grief or not when you try to load the module, but it's better to have versioning info. ;)
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c: At top level:
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c:93: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token So we're back to what I think was the original error (before the UTF-8 smart quote stuff). Can you post lines 90 through 100 of nv.c?
still no success but maybe we are getting closer, i hope? Well, we're back to one of the first errors, but at least it's repeatable. ;)
jiggolo182
01-10-2008, 07:55 PM
ok, these are actually lines 89 through 101 but it doesnt look at that helpful so ill go ahead post the entire nv.c file, just incase. it might save us an intermediate step. you can get it at http://pastebin.com/m36068c51
#ifdef NV_CHANGE_PAGE_ATTR_PRESENT
int nv_use_cpa = 1;
#endif
static kmem_cache_t *nv_pte_t_cache = NULL;
// allow an easy way to convert all debug printfs related to events
// back and forth between 'info' and 'errors'
#if defined(NV_DBG_EVENTS)
#define NV_DBG_EVENTINFO NV_DBG_ERRORS
#else
#define NV_DBG_EVENTINFO NV_DBG_INFO
#endif
bwkaz
01-11-2008, 08:05 PM
Oh boy, kmem_cache_t. That explains it.
This is why you need a different nvidia driver version. :p That kmem_cache_t type was removed from the kernel in 2.6.23-rc1 (i.e. the first post-2.6.22 kernel). The specific git log is here:
whose log message is "Given that there is no remaining usage of the deprecated kmem_cache_t typedef anywhere in the tree, remove that typedef." The type itself has been deprecated ever since December 2006 (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1b1cec4bbc59feac89670d5d6d2 22a02545bac94), but the driver that you're using was written long before that. The easiest fix would be to try 7185 if you aren't already; since it's the latest version of the legacy driver, it will probably have this fix in it. (And it was released in April 2007, several months after this typedef was deprecated.)
If that still doesn't work (or if that driver doesn't work for some other reason), newer nvidia modules have replaced "kmem_cache_t" with a simple "void" -- while I would not recommend that unless absolutely necessary, it might work.
(This is also why out-of-tree drivers are bad. Not that I should talk, since I use this same driver, but still: when you can't get basic cleanup tasks done by the kernel team themselves, you're going to cause problems. The kernel developers will not keep internal interfaces stable, because that means they can't fix mistakes...)
jiggolo182
01-12-2008, 12:13 PM
hmmm.. just great! well i am already using the 1.0.7185 version which apparently does not contain the fix. i tried declaring that variable to a void pointer but then it just gave me other errors later in the file where that variable is an argument to function calls.. also, i dont see where the kmem_cache_t is typedef'd but removing that prolly wouldnt help either.
if you are using this driver, how did you get it to install? what kernel are you running?
bwkaz
01-12-2008, 10:31 PM
i tried declaring that variable to a void pointer but then it just gave me other errors later in the file where that variable is an argument to function calls.. Which function calls, and what's the error? Do the functions just need to be changed to take void pointers as well? If so, you'll have to change kmem_cache_t to void everywhere that it gets used.
Alternately, you might be able to do something like add this:
#define kmem_cache_t void right before the first usage in nv.c -- but depending on what the headers have in them, that may not work either. But I'd still like to see the other errors you get. :)
also, i dont see where the kmem_cache_t is typedef'd but removing that prolly wouldnt help either. Well, that's the whole problem, actually: It isn't typedef'd anymore. (It used to be in one of Linux's internal headers.) The typedef was removed since nobody in the kernel tree was using it anymore, and it had already been deprecated for something like a year. There's no point in keeping old baggage around that nobody's using when you're maintaining that code. ;)
(That's also why drivers need to get put into the kernel tree, not kept outside it. This kind of cleanup happens automatically in that case...)
if you are using this driver, how did you get it to install? Er, I obviously wasn't clear enough. ;) I am using the nvidia driver, but I have a 6800-chipset card, so I use the current driver (100.14.19, not 1.0-7185). The current driver does (seem to) have the fix in it.
jiggolo182
01-13-2008, 01:36 AM
after changing the kmem_cache_t to void and running make module, here are the errors that i receive.. i also tried the #define kmem_cache_t void trick but if i recall correctly i think it produced the exact same errors.
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c: In function 'nvidia_init_module':
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c:1334: error: too many arguments to function 'kmem_cache_create'
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c:1468: error: void value not ignored as it ought to be
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c: In function 'nvidia_exit_module':
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c:1493: error: void value not ignored as it ought to be
make[4]: *** [/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.o] Error 1
make[3]: *** [_module_/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv] Error 2
make[2]: *** [modules] Error 2
NVIDIA: left KBUILD.
nvidia.ko failed to build!
make[1]: *** [module] Error 1
make: *** [module] Error 2
bwkaz
01-13-2008, 03:37 PM
i also tried the #define kmem_cache_t void trick but if i recall correctly i think it produced the exact same errors. OK -- if it did, then you might as well remove the #define. The kmem_cache_t symbol doesn't look like it's involved in any of these errors, so I'm guessing that these are just newer changes made in the kernel.
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c: In function 'nvidia_init_module':
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c:1334: error: too many arguments to function 'kmem_cache_create' Um, yikes.
Well, I'll have to see if I can find anything obvious; hang on.
Ah, this (http://support.zenwalk.org/index.php?topic=11803.0;wap2) page looks slightly helpful -- they're using a different driver, though, so don't just follow the instructions there. They do, however, show where the kmem_cache_create call goes wrong: it's being passed two NULL parameters, but one of those isn't taken by the kernel's version of that function anymore. (The problem on that thread is that that nvidia driver doesn't detect the number of parameters of kmem_cache_create properly (that's why their solution won't work very well for you); I'm guessing that your driver doesn't even do that test.)
To fix it, you'll probably have to change one of the header files (the code you put on pastebin just shows a call to NV_KMEM_CACHE_CREATE, which is a macro #defined somewhere in the headers); let me go get the 7185 package and see if I can find out which one and what to change...
Ah yes, here we go. In nv-linux.h, you'll find a "#define NV_KMEM_CACHE_CREATE(kmem_cache, name, type)" line. That macro is what needs to change -- find the "NULL, NULL" after it, and remove one of the NULLs (along with its comma). Compiling after making that change should make this error go away.
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c:1468: error: void value not ignored as it ought to be
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c: In function 'nvidia_exit_module':
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c:1493: error: void value not ignored as it ought to be OK, I can't quite tell what this is, because I can't find anything on lines 1468 or 1493. If you tried this compile after adding the #define, then please retry it with the version that you had on pastebin (with the kmem_cache_t -> void change, but without any added or removed lines). Then let me know what line numbers these errors show up on.
Alternately, post the code around lines 1468 and 1493 (say, 5 lines before and after, or so) in your version of nv.c; that'd work too. :)
retsaw
01-13-2008, 05:13 PM
I suspect the error you are getting with your nVidia driver is because the drivers usually have to be updated to compile against new kernel versions and the driver you are using is older than the kernel. Have you tried the 7186 driver (http://www.nvidia.com/object/linux_display_x86_71.86.01.html)? Although the 2.6.23 kernel was released a little after this driver was, so still may not work, which means you likely need to go back to using an older kernel if you want the official nvidia driver.
jiggolo182
01-13-2008, 09:26 PM
ok so i got 'make module' to work without returning any errors after commenting out the lines that we're giving me errors.. they were jsut debugging lines that used the kmem_cache variable anyways.. but when i run 'sudo make module-install' i get the following error which we've seen before..
brandon@wembley:~/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv$ sudo make module-install
NVIDIA: calling KBUILD...
make CC=cc KBUILD_OUTPUT=/lib/modules/2.6.23.9.highmem/build KBUILD_VERBOSE=1 -C /lib/modules/2.6.23.9.highmem/source SUBDIRS= modules
make -C /lib/modules/2.6.23.9.highmem/build \
KBUILD_SRC=/usr/src/linux-2.6.23.9 \
KBUILD_EXTMOD="" -f /usr/src/linux-2.6.23.9/Makefile modules
rm -f include/config/kernel.release
echo 2.6.23.9.highmem > include/config/kernel.release
Using /usr/src/linux-2.6.23.9 as source for kernel
if [ -f /usr/src/linux-2.6.23.9/.config -o -d /usr/src/linux-2.6.23.9/include/config ]; then \
echo " /usr/src/linux-2.6.23.9 is not clean, please run 'make mrproper'";\
echo " in the '/usr/src/linux-2.6.23.9' directory.";\
/bin/false; \
fi;
/usr/src/linux-2.6.23.9 is not clean, please run 'make mrproper'
in the '/usr/src/linux-2.6.23.9' directory.
make[3]: *** [prepare3] Error 1
make[2]: *** [modules] Error 2
NVIDIA: left KBUILD.
the whole 'make mrproper' thing that it suggests to do doesnt help either.. since we've tried that before. and, i actually tried it again anyways..
this week this computer wont be my main one anymore as my new parts come in to tomorrow.. ill prolly just end up using this one as a server or something.. thus, i wont need to run X or use the nvidia driver. and the sound issue was never resolved either.. i got tired of dealing with it really..
retsaw, i just tried the driver that you linked to and that one didnt work either.. i still received the same error that i pasted above... i think its hopeless to get this driver to install in a newer kernel.. oh well
bwkaz
01-14-2008, 09:07 PM
NVIDIA: calling KBUILD...
make CC=cc KBUILD_OUTPUT=/lib/modules/2.6.23.9.highmem/build KBUILD_VERBOSE=1 -C /lib/modules/2.6.23.9.highmem/source SUBDIRS= modules You may notice that SUBDIRS is empty again here. Somehow $(PWD) is empty when you do module-install, but not when you compile the module normally? Either that, or something else on your system is changing between these two runs.
You can always just copy the module to the right directory yourself, since something seems intent on screwing up the build system here.
the whole 'make mrproper' thing that it suggests to do doesnt help either.. since we've tried that before. and, i actually tried it again anyways.. But that's just another symptom. The real problem (I think anyway) is that $(PWD) is empty.
i wont need to run X or use the nvidia driver. Well, OK, I suppose that works too.
jiggolo182
01-14-2008, 10:11 PM
damn how did we fix that subdirs thing last time?
when i run 'make module' the SUBDIRS variable is set correctly.. here's some of the output..
brandon@wembley:~/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv$ make module
lastly, just incase you were wondering.. here is what the module-install command looks like in Makefile.kbuild.. i guess it looks right to me.. i dont think the video dir is totally necessary but i dont care..
damn how did we fix that subdirs thing last time? I don't think we did -- I think it just sort of went away. :(
lastly, just incase you were wondering.. here is what the module-install command looks like in Makefile.kbuild.. Yeah, that looks OK -- it's running into problems because it's trying to rebuild module (since it's a dependency of module-install). Not sure how to prevent it from doing that though. :(
also, if i want to just manually copy the module into the directory which one do i copy? You'd do something like:
mkdir /lib/modules/2.6.23.9.highmem/kernel/drivers/video &&
cp nvidia.ko /lib/modules/2.6.23.9.highmem/kernel/drivers/video/ &&
depmod -ae 2.6.23.9.highmem to create the proper directory, copy the nvidia.ko module over, and then run depmod. (If you're currently running 2.6.23.9.highmem, then you can leave the version number off the "depmod -ae", but it won't hurt to leave it on.)
I.e., you only need nvidia.ko. :)
bwkaz
01-19-2008, 02:09 PM
Not that it matters anymore, but the cause of this:
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c: In function 'nvidia_init_module':
/home/brandon/NVIDIA-Linux-x86-1.0-7185-pkg1/usr/src/nv/nv.c:1334: error: too many arguments to function 'kmem_cache_create' error can be found at:
http://lwn.net/Articles/2.6-kernel-api/
Specifically, this change:
The destructor argument has been removed from kmem_cache_create(), as destructors are no longer supported. All in-kernel callers have been updated. is what broke this code.
But it doesn't matter anymore, because we got it to compile by deleting the NULL value that nvidia was trying to pass for a destructor. ;)
(I just read through that article today, so I figured I'd link to it. That's probably a decent reference if you run into future compilation errors too, although I don't know how specific that article will be. Still, it may be worth searching through it. :))
jiggolo182
01-19-2008, 02:42 PM
well, i actually never got the nvidia module to install.. ive sorta given up since i built the other box.. i followed your instructions but to no avail..
i forget what the exact error was but it was something like it couldnt find the nvidia module.. shouldnt i have a nvidia_drv.o file copied into another directory as well.. like /usr/lib/xorg/modules since thats what my ModulePath variable in my xorg.conf is set to look for stuff?
bwkaz
01-20-2008, 02:35 PM
Kernel modules are separate from X-server modules and drivers. You don't care about anything that's loaded by X (or configured in xorg.conf) at this point -- you're just trying to get "modprobe nvidia" to work. So no, you don't need nvidia_drv.o (actually it's .so in newer drivers, but that doesn't matter) at this point. :)
I assume the error was from depmod, right? I suppose if you're not worried about it anymore, then I won't worry about it either -- but it might help others in the future, so if you do want to see if you can get this last little thing to work, that might be useful. Either way. :)
jiggolo182
01-21-2008, 01:32 AM
well, the actual error that i receive is "Failed to load the NVIDIA kernel module!" according to /var/log/Xorg.0.log
all the other steps above worked fine.. however, i did notice that there is an nvidia folder inside of the /lib/modules/2.6.23.9.highmem/kernel/drivers/video dir and i also tried copying the nvidia.ko into that dir as well but still received the same error.
im happy to announce though, that the nvidia card in my new system had absolutely not problems.. haha.. prolly since i wasnt forced to use such an ancient driver!
bwkaz
01-21-2008, 08:28 PM
well, the actual error that i receive is "Failed to load the NVIDIA kernel module!" according to /var/log/Xorg.0.log OK... what happens if you try to modprobe nvidia? I assume you'll get some kind of error message; post it.
however, i did notice that there is an nvidia folder inside of the /lib/modules/2.6.23.9.highmem/kernel/drivers/video dir and i also tried copying the nvidia.ko into that dir as well but still received the same error. I'd get rid of any directory named nvidia (assuming it's empty apart from the nvidia.ko file) -- that's not right. You should have only a kernel/drivers/video/nvidia.ko file, and AFAIK nothing else named nvidia* should exist...
jiggolo182
01-21-2008, 08:42 PM
brandon@wembley:~$ sudo modprobe nvidia
FATAL: Error inserting nvidia (/lib/modules/2.6.23.9.highmem/kernel/drivers/video/nvidia/nvidia.ko): Unknown symbol in module, or unknown parameter (see dmesg)
the pastebin link is the output that dmesg gives me..
http://pastebin.com/m39a71a2f
also, right now, the contents of /lib/modules/2.6.23.9.highmem/kernel/drivers/video/nvidia are the nvidia.ko file and another file called nvidiafb.ko
bwkaz
01-22-2008, 10:55 PM
OK, if you have an nvidiafb.ko file, that sounds like maybe it's the reason the nvidia directory was created. Get nvidia.ko out of there (its normal path is just the .../kernel/drivers/video/ directory), and rerun depmod. Actually, scratch depmod, now that I see the errors you're getting -- it looks like something's horribly messed up between kernels here.
What I'd do is start over completely. Save away .config, do a "make mrproper", copy .config back, do a "make oldconfig", then build the kernel and modules, and install the kernel. Then boot to this kernel. Then remove the nvidia driver's directory and re-extract it. Then cd into the usr/src/nv directory, and do the same changes that you did before to get it to compile -- replace kmem_cache_t with void, and remove the extra argument to kmem_cache_create, then do whatever else you had to do to get it to compile before. Then "make module", then create a new /lib/modules/$(uname -r)/kernel/drivers/video directory (if it doesn't exist), then copy nvidia.ko to that directory. Then run depmod -ae and (if it works) try to modprobe nvidia.
That way, you're running the actual kernel that you compiled against, and there's no chance for versioning mismatches, or issues because some version string got regenerated to something different after an mrproper. ;)
jiggolo182
01-23-2008, 09:49 AM
eh, i still got all those same errors even after doing all that.. i think its just not gonna work with the newer kernels. my only option is prolly just to rebuild the 2.6.22-3 kernel that was installed with debian and just enable highmem in that one. i was able to get the NVIDIA driver package to install just fine with the older kernel..
bwkaz
01-23-2008, 07:39 PM
Well, either way. I'll stop posting here now. ;)
jiggolo182
01-23-2008, 08:59 PM
haha yeah.. that must be a relief for you now.. thanks for helping though.. ill let ya know how the other project goes.. right now its not at the top of the list anymore..
play5331
02-18-2008, 08:14 PM
Just thought I'd add a bit before you give up on this for the time being..I have read through these threads and I did not see any mention as to when if you have selected the riva {nvidia} in your new kernel.. either as a module or into the kernel .having had similar experience with a Nvidia Ti4200 doing the same with older kernels 2.6.20 I did read on the net not to build riva and nvida support into these so I had simply made copies of .config{s} and saved them on the attempts for building the new kernel ..one thing I remember about using that Ti4200 was using Nvidia's 76xx series drivers on Linux...they seemed to work for me a bit better.
The other issue I just wanted to comment on and [since this is my first post here] is the incredible patience, support and wisdom that you have received here is Amazing !!
The last time I had similar initrd and rms askew was with Fedora 7 searched a bunch of forums and found out I wasn't the only one ..ha ha and a real tail chase to boot or not boot as the case of the new kernel
I had been just checking Fedora 7 out for sport >> since I prefer Debian and Sabayon anyway.
justlinux.com
Copyright Internet.com Inc. All Rights Reserved.