[opensuse] kernel 2.6.36 speeds things up
this has been mentioned before, several times in several threads, but somehow i was assuming that fixes in the new (HEAD) kernel re. video performance would have filtered down, backported to the standard one (obviousl i know nothing about kernel dev). after upgrading to 11.3 at first i didn't notice that everything was somewhat sluggish, but later it became obvious. also obvious was that Xorg was the culprit, using 40% of both CPUs at times (or 80% of one rather). after upgrading to the newer kernel (http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_11.3/) all this disappeared, and the system feels much 'lighter'. no idea if and how this affects different configurations, but if you notice above symptoms and are running the std. kernel, it's probably worth a try. SYSTEM: intel dual core, 4 GB RAM; openSUSE 11.3 (x86_64), Kernel: 2.6.36-rc3-9- desktop, KDE 4.5.1; using nouevo drivers for geforce 9400 [?] GT -- phani. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday, September 03, 2010 05:25:46 am phanisvara das wrote:
but if you notice above symptoms and are running the std. kernel, it's probably worth a try.
...unless you want to use proprietary nvidia drivers, which don't seem to work with this kernel yet. :( i can do w/o desktop effects, but i'd like to adjust contrast / gamma on one of my (2) monitors, which the nouevo driver can't do. -- phani. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday, September 03, 2010 05:25:46 am phanisvara das wrote:
but if you notice above symptoms and are running the std. kernel, it's probably worth a try.
...unless you want to use proprietary nvidia drivers, which don't seem to work with this kernel yet. :(
i can do w/o desktop effects, but i'd like to adjust contrast / gamma on one of my (2) monitors, which the nouevo driver can't do.
-- phani.
Whenever you go to a kernel version outside the supported repository, you need to compile the proprietary driver yourself. Not difficult. Available at Nvidia site, with instructions for openSUSE. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday, September 03, 2010 08:16:18 pm dwgallien wrote:
Whenever you go to a kernel version outside the supported repository, you need to compile the proprietary driver yourself. Not difficult. Available at Nvidia site, with instructions for openSUSE.
[sorry for the private reply; wasn't intentionally.] i'm aware of that and tried it. somewhere in the middle of the compilation process i got a message that the "kernel module cannot be built." (and yes, i have kernel sources, compiler, etc., installed. also went to init 3, so that no x-driver was running, after blacklisting the nuoevo driver & rebooting, as per isntructions.) in the meantime i've found several forum- and blog posts where people claim that the 2.6.36 kernel "does not work with prop. nvidia drivers;" they downgraded to 2.6.35, which apparently does work. i tend to believe these reports. not sure what's required, changes in the kernel or a new nvidia driver, since i know very little about these things. for now i'll just wait and watch. i can work w/o those prop. drivers, no big thing. -- phani. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday, September 03, 2010 10:32:24 pm phanisvara das wrote:
in the meantime i've found several forum- and blog posts where people claim that the 2.6.36 kernel "does not work with prop. nvidia drivers;" they downgraded to 2.6.35, which apparently does work.
i got that pretty much confirmed now: 2.6.36 does _not_ work with nVidia. following some forum or blog post i came across, i downgraded to kernel 2.6.35, which still lives in one repo: http://download.opensuse.org/repositories/Kernel:/v2.6.35/openSUSE_Factory/ [the name "factory" must come from the time when 11.3 _was_ "factory" i believe; it installed fine on 11.3 tonight.] this kernel deals better with the lag caused by Xorg using too much CPU and nvidia drivers compile w/o problem. i observed another interesting fact: using multiple monitors (2 in my case), if you set them to "separate X screens" and then "enable xinerama," that's much heavier on the CPU than using them as "twin vies." no idea why that is so, but it's very obvious on my system. -- phani. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday, September 04, 2010 09:34:02 am phanisvara das wrote:
i observed another interesting fact: using multiple monitors (2 in my case), if you set them to "separate X screens" and then "enable xinerama," that's much heavier on the CPU than using them as "twin vies." no idea why that is so, but it's very obvious on my system.
it's pretty obvious, actually: with "twin views" both monitors use the same X server, whereas "separate X server" needs two of them: double the overhead. -- phani. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday, September 04, 2010 10:10:07 am phanisvara das wrote:
it's pretty obvious, actually: with "twin views" both monitors use the same X server, whereas "separate X server" needs two of them: double the overhead.
using 'twin views' instead of two X-servers i'm also able to use desktop effects. unfortunately this causes Xorg to hang around 20-40% CPU again. may have something to do with the fact that 2.6.35 (in openSUSE) isn't the final version, but a release candidate, i.e., some debugging overhead. no problem though: who needs eye-candy? -- phani. PS: sorry for this monologue, but i figure this might be useful for people who find themselves in a similar situation; i've seen a lot of complaints about sluggishness & slow performance in this list. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 3 Sep 2010 22:32:24 +0530, phanisvara das
in the meantime i've found several forum- and blog posts where people claim that the 2.6.36 kernel "does not work with prop.
With a very small change in the nvidia sources it compiles and seems to work fine. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 04 September 2010 08:12:06 Philipp Thomas wrote:
With a very small change in the nvidia sources it compiles and seems to work fine.
Just, if you would reveal the secret :) -- Regards, Rajko -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 4 Sep 2010 09:39:50 -0500, "Rajko M."
Just, if you would reveal the secret :)
Just comment out the line the compiler complains about, i.e. the initialization of the ioctl callback in struct file_operations. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday, September 04, 2010 11:03:23 pm Philipp Thomas wrote:
Just comment out the line the compiler complains about, i.e. the initialization of the ioctl callback in struct file_operations.
thanks, that should do it. got to extract the files from that ~.run file, of course. thanks a lot. -- phani. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 5 Sep 2010 00:34:19 +0530, phanisvara das
thanks, that should do it. got to extract the files from that ~.run file, of course. thanks a lot.
But that's easy :) You just pass --extract to the .run file and it then extracts all files. Then you edit the file (AFAIR it's kernel/nv.c) and then call nvidia-installer in the toplevel directory of the unpacked sources. This calls the installer which will then compile the kernel module and install all that's necessary. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday, September 05, 2010 05:50:36 am Philipp Thomas wrote:
But that's easy :) You just pass --extract to the .run file and it then extracts all files. Then you edit the file (AFAIR it's kernel/nv.c) and then call nvidia-installer in the toplevel directory of the unpacked sources. This calls the installer which will then compile the kernel module and install all that's necessary.
i figured the extraction bit out myself (sh ~.run --help). but it's nice to get a confirmation of what to do with the stuff afterwards. thanks. -- phani. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday, September 05, 2010 05:50:36 am Philipp Thomas wrote:
You just pass --extract to the .run file...
in my version it's "-x" or "--extract-only", btw. -- phani. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday, September 04, 2010 11:03:23 pm Philipp Thomas wrote:
Just comment out the line the compiler complains about, i.e. the initialization of the ioctl callback in struct file_operations.
didn't work for me. "kernelmodule could not be built," or similar. in the log file, it suggests doing things to the kernel source configuration. i don't want to mess around with that right now--not until i understand better what i'm attempting to do, and probably installing another kernel in parallel, so i have something to fall back if i mess things up. -- phani. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
<snip>
i don't want to mess around with that right now--not until i understand better what i'm attempting to do, and probably installing another kernel in parallel, so i have something to fall back if i mess things up.
-- phani.
fwiw . . . while multiple kernels can be installed in parallel, there is also a quick-n-dirty method that I've used not only for a fast test, but as well as a regular precaution before any kernel upgrade: I have a sub-directory under /boot which is named /last. Before installing the new kernel, I copy the current kernel and initrd files along with the vmlinuz and initrd symlinks into /last. (For extra safety, I also copy in the current /grub directory, too.) I have an added stanza in menu.lst which is identical to the production stanza, except with the kernel and initrd lines changed to point to the /last subdirectory. Something like this: root (hd0,0) kernel /boot/last/vmlinuz <remainder of line> initrd /boot/last/initrd Then following the update, if necessary I can fall back to the previous kernel binary. This method can be used without modifying menu.lst, too - alternatively the regular grub boot stanza can just be edited on-the-fly right at the runtime menu, such that it ref's /last like the above. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Monday, September 06, 2010 01:34:04 am dwgallien wrote:
Then following the update, if necessary I can fall back to the previous kernel binary. This method can be used without modifying menu.lst, too - alternatively the regular grub boot stanza can just be edited on-the-fly right at the runtime menu, such that it ref's /last like the above.
that means there's no other changes necessary to switch kernels? k. understands from initrd where to look for modules, etc.? -- phani. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Monday, September 06, 2010 01:34:04 am dwgallien wrote:
Then following the update, if necessary I can fall back to the previous kernel binary. This method can be used without modifying menu.lst, too - alternatively the regular grub boot stanza can just be edited on-the-fly right at the runtime menu, such that it ref's /last like the above.
that means there's no other changes necessary to switch kernels? k. understands from initrd where to look for modules, etc.?
-- phani.
No, sorry if I wasn't clear. Again, this is just a quick-n-dirty that will simply permit you to boot the last kernel e.g. in the event that the new kernel fails to. The last initrd will contain the boot modules associated with the last kernel, and the system will start up. Modules which are loaded later in the boot process and are dependent on a matching kernel version, will fail. This technique is just to get you back into a working environment from where you can investigate and rectify whatever caused the new kernel to fail, e.g., to look at logs, modify a broken configuration file, reinstall the previous kernel that worked, etc. So it is somewhat similar to booting the Rescue System, but gives you much more to work with. Of course this assumes the user is familiar with the inner workings of the system. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Monday, September 06, 2010 09:04:42 am dwgallien wrote:
that means there's no other changes necessary to switch kernels? k. understands from initrd where to look for modules, etc.?
No, sorry if I wasn't clear. Again, this is just a quick-n-dirty that will simply permit you to boot the last kernel e.g. in the event that the new kernel fails to. The last initrd will contain the boot modules associated with the last kernel, and the system will start up. Modules which are loaded later in the boot process and are dependent on a matching kernel version, will fail.
ah, would have been too easy to be true. of course, getting back into a sort-of working system this way is easier than booting from DVD into rescue mode or something--specially if one doesn't have a CD/DVD drive, like i at the moment. good idea, thanks. -- phani. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* phanisvara das (phani00@gmail.com) [20100905 20:50]:
didn't work for me. "kernelmodule could not be built," or similar. in the log file, it suggests doing things to the kernel source configuration.
The patched I used is attached. Philipp
On Tuesday, September 07, 2010 05:41:13 pm Philipp Thomas wrote:
The patched I used is attached.
thanks a lot. if that also doesn't work i stop trying to understand and wait 'til i'm comfortable upgrading to oS factory (11.4). according to reports, nvidia works fine there. -- phani. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday, September 07, 2010 05:41:13 pm Philipp Thomas wrote:
The patched I used is attached.
this works; nvidia compiles & runs fine now. thanks again. (i ended up in the wrong function trying to follow your earlier hint... :\ ) -- phani. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, 7 Sep 2010 22:47:48 +0530, phanisvara das
this works; nvidia compiles & runs fine now. thanks again.
I'm glad I could help :)
(i ended up in the wrong function trying to follow your earlier hint... :\ )
I guessed something like it so I posted the patch. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday, September 04, 2010 06:42:06 pm Philipp Thomas wrote:
With a very small change in the nvidia sources it compiles and seems to work fine.
good news. do you know where i can find that small change? not necessarily as a patch, just something that makes me understand what needs to be changed & where. -- phani. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (5)
-
dwgallien -
phanisvara das -
Philipp Thomas -
Philipp Thomas -
Rajko M.