I apologize for the newbie question, but I just want to know what the easiest way to do this would be. We're now at 3.10.9 on Slackware64-current, and my laptop fan seems to be running a lot more than it used to a few weeks ago, especially after coming out of suspend. So I am thinking it would be a good idea to change back. I am trying to figure out what version to go back to, and how to do it.

I think my issue started two or three weeks ago, so looking at the Slackware changelog, maybe it was around when we upgraded to 3.10.7. Therefore I wanted to see what changes happened in the kernel between 3.10.7 and 3.10.9. However, when I look at the kernel changelog for these three versions, there is so much low-level information there that it is hard to see what if anything could have to do with power. Can anyone recommend a good place to look that might have the kernel changelog information in a summarized or somewhat more interpreted form?

Then, when I find this information, what would be the best way to go back? Should I follow the information in AlienBob's guide here: http://alien.slackbook.org/dokuwiki/...kernelbuilding, or do something else?

Thanks in advance for any advice.

this is a good place to see changes between versions http://kernelnewbies.org/LinuxChanges
and im not really sure about kernel building, i never did it, maybe i will revert from 3.10.9 in a few weeks, im having problems with the official ati driver myself.

1 members found this post helpful.

I hope the more experienced members will correct me if I'm wrong but I wouldn't go back from, say, 3.10.9 to 3.10.7 as you're just going back bugfixes and security updates. If you must go back go to a bugfixed currently-supported kernel such as 3.4.60 then you'll get a currently supported kernel.

The problem is that, by going back, you reject the security and bug fixes for the new versions.

Going back with the kernel potentially breaks compatibility with userspace software, such as X11 -that is, changing the kernel could mean no graphic output in the screen!

My advice is to learn how to compile and install a kernel (there are lots of information around), then install the one you like in addition to the one you have. That way, if things don't work, you have the old one to fall back into.

1 members found this post helpful.

I would not recommend to go back to older kernels. Instead go to newer kernels and see if that problem persists. If it does then file a bug report. Going back to older kernels may fix your problems, but will only be a temporary fix, until the kernel you use is obsolete and you have to switch back to a newer one. Reporting the bug will fix your problems in a better way.

1 members found this post helpful.

Thanks everyone for responding. I have no problem filing a bug report, but before the bug gets fixed I still need to run a different kernel. I don't like having to reboot my laptop every time I want the fan to turn off. I am worried about all the extra wear on the fan.

I appreciate the information about kernel versioning. I did some reading, and now I understand what the different numbers mean. I guess then I should use 3.4.61 because it is the newest of the longterm releases.

@BlackRider: I'm not quite clear on what you mean by breaking my system by going back to an old kernel vs. compiling a new (older) kernel. Aren't they the same thing? I will go back to an old kernel version by compiling it and then using it, right?

I am curious what other -current users do in regard to upgrading the kernel. I think most of us probably just use what Pat gives us, but there must be some people (like me) who have tricky hardware and don't want to take a chance on a different kernel all the time. Is it common to blacklist the kernel in Slackpkg and just upgrade the kernel manually?

i always compile my own kernel since i wanted to test compatibility between my NVidia driver and also VMWare Workstation against newer kernel

I closely follow the development of the radeon drivers, so most of the time I use the newest stable version from kernel.org or a development kernel from Alex Deucher. I don't blacklist the kernel in slackpkg, so that I always have the latest supported kernel installed for emergency/recovery boots when something went wrong.

1 members found this post helpful.

If you use a Laptop, it's probably recommended you use this package also:

http://slackbuilds.org/repository/14...op-mode-tools/

2 members found this post helpful.

I am not using laptop-mode-tools because it conflicts with pm-utils, and I have not had the time to go through the process of dealing with duplicate hooks in the configuration to stop the conflict. I may make the time, though, to see if it helps.

I am going to take a stab at compiling the 3.4.61 kernel, and also keep the stock one as suggested. In the future I will do as Tobi does and run my custom kernel while allowing the tested one to update as usual. Thanks everybody for their input.

2 members found this post helpful.

My answer comes late, but here it goes.

You can break your system by switching to an older kernel more or less the same way you would break it by using a newer kernel. I have not claimed the opposite.

What I was saying is that you should install a kernel you think will solve your problem, while keeping the current one. That way, if things go wrong, you can point the bootloader back to the working kernel again.

Having an old 90% working kernel is surely better than having a 60% working current kernel, but it is still subobtimal for all the reasons already given in the thread.

I hope your solution is working for you.

1 members found this post helpful.