Linux 2.6.36 is out
 

Cheers! I see that Linux 2.6.36 is out.

Linus' blurb: http://lkml.org/lkml/2010/10/20/409
Changelog: http://kernelnewbies.org/Linux_2_6_36

I will probably be testing it later today with Slackware 13.1 x64. If you are using it already, please let us know how that works out for you.

FYI, Con Kolivas' patchset (with BFS scheduler) that applies to it is out also :)

http://ck-hack.blogspot.com/2010/10/2636-ck1.html

ponce, you mean Ck is back working on kernel stuff?

I've been using his patches for 2.6.34 for awhile, haven't bothered with new kernels since then.

yes gnashley, he got back with new motivation when he read this xkcd comic, "supported features"

http://ck.kolivas.org/patches/bfs/su...d_features.png

:D

Meh, that's Adobe's fault.

yes, he blame them too in the faq :)

but, on that side, with webm/html5 things are getting better ;)

when executing anybody?

Latest 2.6.35.7 reacts properly.

2.6.36
 

Built and running using config-generic-2.6.35
64 bit no multi-lib
no problems so far
needed to update the Nvidia driver

Anyone know when nouveau will be usable?

thanks
john

I don't think make bzImage modules is valid. I just upgraded to .36 using

Worked without any issues. Try make help in the source.

It's been valid for years, so I don't think it's the problem. Probably something went wrong during gcc-multilib upgrade few hours earlier.

Update:
:D

I have used it on my desktop and laptop and so far, so good
The latest NVidia driver 260.12.19 is compatible with it and if you are running VMWare Workstation, i have found a workaround patch to make it work with 2.6.36 and i have posted it on my blog: http://slackblogs.blogspot.com/2010/...ux-kernel.html

In my case, i used:

It is valid. See Alien Bob's site: http://alien.slackbook.org/dokuwiki/...rnelbuilding&s[]=kernel&s[]=compile
I build my kernels this way every time.

I think, the problem is the y in front of gcc. ;)

My guess is that the "y" prefix comes from the make *config (probably from some cross compiling option), env var or even a patch. I'd try with a clean source tree.


As for the "make bzImage modules", the GNU make [1] takes the following args[2]:
In this case, "bzImage" and "modules" are targets and the command should be valid - assuming he is using the GNU make[1].


I have been using this kernel for a couple of hours now. The only problem i have had so far is that sometimes (usually when i open an OpenGL application or start a video playback with either mplayer or vlc) my screen "blinks" for 1-2sec.


[1] I'm not sure if the non-GNU versions accept multiple targets.
[2] From the man make(1)

I used the config for the generic kernel from Slackware-current X64

There were some new in 2.6.36 so it had me update the above config.

2.6.36 so far runs better than 2.6.35.7 did for me.

video is improved (HD5450 radeon kms and open source driver). I no longer have an one time blinking of screen when I first start Firefox or other X gui apps.

Thanks.

--
Alan.

I'm running X64 Slackware 13.1 with not the multilib.

Maxmiorim ->

Due to lack of time, I didn't even use make menuconfig, just zcated .config from proc, then "make oldconfig" and "make bzImage modules". Seems I have to omit using current .config file and start from scratch.

Thank for the interest guys.

I just upgraded to 2.6.36 and so far the only trouble was that the nVidia blob was saying something like:

"(EE) NVIDIA0 nvidia card <blah> unable to communicate with driver!"

And X wouldn't start.

I had had MSI/X enabled in /etc/modprobe.d/whatever for the nvidia driver. Disabling that fixed it. So, MSI/X worked for 260.19.12 + 2.6.35 but not 260.19.12 + 2.6.36. Last time I looked, MSI/X was still disabled by default as it's not fully reliable.

Just want to say that I rarely upgrade kernels. I only upgrade if there's a problem, that's why I upgraded to 2.6.35.7, and I'll stay with it until there's a problem with this kernel.

worked
 

For what it's worth, it worked for me. I just made oldconfig on my mutilated huge config and filled in the blanks. I also use NVIDIA's driver, and my good old NVIDIA-Linux-x86_64-256.44.run would not even build with the new kernel. But the latest NVIDIA-Linux-x86_64-260.19.12.run worked fine.

Just installed Kernel 2.6.36 (ran oldconfig on my handcrafted 2.6.35 .config) and Nvidia 260.19.12. (I'm running Robby's Xorg 1.9 build)

When I tried to install the nvidia module on my existing 2.6.35 kernel it complained that the kernel had been built with a different version of glibc to that which is currently installed (I didn't know that mattered so I've learnt something new).

As I have to rebuild the kernel against the new glibc anyway in order to build the new nvidia module, I thought I might as well update the kernel at the same time. Usually I'm a little more cautious and wait for the .1, but it seems ok so far.

Is there a guide as to "what would Slackware set" for new config settings? For the most part I use M for module when it comes to settings that I have no clue what they mean/do, but what of the config settings that do not have an M option?

That's an interesting question.

I use to disable the stuff that is tagged experimental (unless I really need that feature) and use the defaults for everything else. Maybe that's not exactly what Pat does but it works for me. :)

I am about as clueless as they go when it comes to kernel options, so I included everything (as M if I could) aside from a few exotic device drivers I absolutely positively know I will never need. Whatever is there, it won't even make a splash in the huge config.

P.S. Oh and that is an interesting question: "what would Slackware set". Looking forward to 13.2 or 14, I think I would want to default to Pat's choices while keeping the crud out. So there will be some merging. I'd like to know if there is a graceful solution to this.

Maxmiorim ->

You were right, config_cross_compile was set to "y". Funny fact - it doesn't affect 2.6.35.7. Why does the string value add as a prefix to gcc and ld commands when compiling 2.6.36 - no idea.

Concerning new (and old) options in new kernel: Slackware is being used on so many machines filling so many different needs that answer to "what would Slackware set" doesn't exist.

Hmm, are you sure you used the same config that current uses?

I don't have kernel-huge installed but i think it's not set there as well.

Also, for reference, here's the sha1sum of my config (it's the same on the four boxes that i have access to right now):

I used my own .config file, that dates back to 2.6.21 times I think, of course modified in the process. Never had problem with kernel updates and I'm pretty sure I didn't set "y" to "CONFIG_CROSS_COMPILE" when compiling 2.6.35.7.

While that may be true that Slackware is used on many machines, in the end the configs used are generally the same with a few differences here and there to accommodate 32/64-bit platforms and the huge and generic kernels.

Today I saw a small fix for '.357 Magnum' here...

Sound words indeed m8. I'll just modify a bit of it as follows: "... if there's a problem or if I wish to tinker with some cutting/bleeding edge stuff" :).

To add my 2 cents to the post above, initially I was not particularly mad about rebuilding the kernel, but it seems to be the way to go with Slackware on a home desktop. I run just about everything on this machine: Open Office, firefox (but not flash :banghead:), apache+PHP, bind,... so keeping it secure takes some thought. A few weeks back, when the whole 32 emulation layer came under fire, I realized that building my own kernel may be the easiest route to take if I want react in real-time to the latest security advisories. Slackware's non-reliance on a custom kernel really shines here: the new kernel just works. On top of that, the home desktop is also hungry for device drivers. I've seen already digital cameras that refused to play with 2.6.35.y, but I know that Linus is constantly adding more support for USB, so there is another reason to upgrade. And as I delved into the kernel config, I learned a bunch of new stuff, so no time was wasted.