Fedora Core 2: Solution without compiling kernel

[cabrilo]

If you are as lazy as me and you just LOVE rpm's, here is a solution to all of your problems:

http://www.linuxant.com/driverloader...ernel-i686.php

"They are identical to the Fedora kernels, except for the removal of problematic CONFIG_4KSTACKS, nostack and 4G/4G patches."

I am using one right now. glxgears is giving nice results!

[LordMorgul]

Very nice find, I'm glad to see someone managed to make the necessary fixes to related patches -- merely removing the 4kstack patch to that SRPM does not work... (as I and a few others tested and Arjan van de Ven confirmed). Perhaps the 4G/4G split was also to blame for my rebuild failures since I left this in.

I'll be testing this kernel tomorrow when I return from school, I haven't yet.
Disclaimer -- you really should consider whether you trust this source before running the kernel... I'm going to risk my test machine with it but make that choice for yourself.

update: it does work for me - P4 GeF4ti4400 intel i850e chipset

[dschueths]

Works!

[dubious9]

I can verify that this indeed works. Here was my situation: I intalled the NVidia drivers, and experienced the resulting system hang. I changed my xorg.conf back to nv to fallback to the default driver. Then I downloaded the rpm, unzipped it and installed it via

rpm -U

Upon restart the driver still didn't work, but the system noticed this time that it couldn't start the x server. I was glad it wasn't a hard crash, and tried the reinstall the driver. So I did and it works. GLX gears reports 4184 fps on my Athon XP1700 and 5600 ultra.

One question. This is the first time I've run the x.org X server. Are there any operational differences between xorg.conf and XF86Config, or anywhere else?

[tidixon]

Wow. Congrats and thanks for the rpms. Do you think you could do the same to the redhat 2.6.6 kernel in the updates-testing branch? Or do the 4K stacks totally break compatability in the 2.6.6 kernel?

[munsen]

This great. Thanks to the person who did this but the only thing I worry about is that Nvidia may now take longer to release a fixed driver for our problem. From what I understand, The 4k patch added significant speed to the desktop. Does anybody else think this really isnt much better than using FC1 with newer packages and a new kernel? Dont get me wrong, I will be upgrading tonight finally, but I'm just not sure this is the ideal solution.

[cabrilo]

These rpm's were created by linuxant (I am their customer, I don't have anything else to do with them).

And yes, it's not a solution. Personally, I will only keep this kernel until nvidia releases their fix. I still didn't delete the original one.

[hpx]

This is great. I've downloaded the new RPM and the latest NVIDIA drivers work fantastic! However, ntfs support was not compiled in, and I've been pulling my hair out for the last two hours trying to compile a module. I've downloaded the updated source on linuxant, recomplied for NTFS support, recomplied the ntfs modules, loaded them, tried to mount an ntfs filesystem, and bang! module crashs: (from dmesg:

NTFS driver 2.1.6 [Flags: R/O MODULE].
Unable to handle kernel NULL pointer dereference at virtual address 00000234
printing eip:

I built the module by:

make clean
make mrproper
make xconfig (and enabled ntfs)
make prepare
make SUBDIRS=fs/ntfs modules
cp fs/ntfs/*.ko /lib/modules/`uname -r`/fs/ntfs
depmod -a
modprobe ntfs

Does anyone have ntfs support enabled in this kernel and working!!!! Any help is greatly appreciated

[Kamel]

why don't you all compile your own kernel? it's really simple...

# cd /usr/src/linux
# make menuconfig
# make
# cp arch/i386/kernel/bzImage /boot/bzImage

i really don't understand

btw, hpx, you need to do make modules_install iirc. may be dumb to mention this, but also make sure it's built as a module and not into the kernel.

[cabrilo]

Originally Posted by Kamel

why don't you all compile your own kernel? it's really simple...

# cd /usr/src/linux
# make menuconfig
# make
# cp arch/i386/kernel/bzImage /boot/bzImage

i really don't understand

btw, hpx, you need to do make modules_install iirc. may be dumb to mention this, but also make sure it's built as a module and not into the kernel.

Well, just a bit more complicated than that (you have to use "clean" kernel from kernel.org), but that's not the point. It takes a lot of time to compile, there is always a possibility of screwing up, etc. RPM are just more conveniant, and why not use them?

[LordMorgul]

Originally Posted by munsen

From what I understand, The 4k patch added significant speed to the desktop. Does anybody else think this really isnt much better than using FC1 with newer packages and a new kernel? Dont get me wrong, I will be upgrading tonight finally, but I'm just not sure this is the ideal solution.

It is not an ideal situation, however there are many changes in FC2 as opposed to FC1 using a 2.6 kernel.. updated glibc and a kernel built on gcc3.3.x are two huge issues.

The comments in the kernel changelog and in the LKML that I read suggest the 4K stack change was not primarily for desktop speed or response times.. it is a change to vastly improve system scalability (aimed at highly multithreaded apps such as network servers). Register Parameters may have a more direct effect on desktop performance.. the newer updates to the scheduler are actually where the best gains in desktop 'response' and 'speed' come from.

[Kamel]

Originally Posted by cabrilo

Well, just a bit more complicated than that (you have to use "clean" kernel from kernel.org), but that's not the point. It takes a lot of time to compile, there is always a possibility of screwing up, etc. RPM are just more conveniant, and why not use them?

i totally agree with what you said, except for "why not use them?" -- if you're having problems, just build your own. if you can get away with using an RPM and not have to compile the kernel, then all the better.

point is, if you've having trouble with it, just compile the kernel.