Kernel 2.6.34 news

It has been out for a few days. Here is an overview:

http://kernelnewbies.org/Linux_2_6_34

...heaps of interesting stuff. I notice that lzma and lzo compresion is now in the Squashfs filesystem.

Here are a series of articles on the 2.6.34 kernel:

http://www.h-online.com/open/features/Linux-Kernel-2-6-34-tracking-962586.html

---

Comments

OT: Broken Bines
Username: Dougal
Barry, you're really taking the piss with using xdelta in bones... I wanted the latest woof script so I installed bones and did what your woof page says to do. It downloaded all the files, then started patching... and after about fifteen minutes of the cpu maxed out (and draining the battery) I ended up killing it. It really makes no sense that every time you change one line in some script it will have to labor over patching some delta file. Wouldn't it be simpler to just use plain diff patches and embed them inside self-executing shell scripts (a-la dpatch), then you can do anything not supported by diff using embeded shell commands?"19 May 2010, 21:39"01603"109.65.30.166'Compressed swap"Iguleder"Barry, there's something interesting you can add to Woof. It's usable with 2.6.33 and above, but I'm sure a tiny uname in the init scripts can solve the problem. 2.6.34 has ramzswap, but needs a patch for additional, recommended features. It's very very simple: ramzswap is LZO-compressed swap space in the system's RAM. By default, it uses 15% of the system's RAM, so if you have 100 MB of RAM, 15 MB are compressed and practically, are much more than 15 MB! Normally, when your memory is full, you use the slow swap space. However, with this nifty trick, you move to slightly slower (hey, it's LZO, very fast) memory, and only then you proceed to the slow swap on your hard drive. It's very very simple. All you need is a kernel with ramzswap and LZO compiled in. Then you do this: modprobe lzo_compress <= load LZO modules, needed for ramzswap modprobe lzo_decompress modprobe -q ramzswap <= load ramzswap itself rzscontrol /dev/ramzswap0 --init <= create a device swapon /dev/ramzswap0 <= show time It's very very useful for systems with low RAM. The Tiny Core guys will use such a thing in their upcoming 3.0 release. That's a big knock-down for Puppy."20 May 2010, 2:17"01603"79.182.123.93'k2.6.34"panzerpuppy"Wow, I'd love to see the new kernel in the next release of Quirky. Not only LZO, but there's some really good stuff in there for users with ATI cards - power management support for the Radeon driver (finally!) and support for GPU switching on laptops with NVIDIA + Intel video. Username: 20 May 2010, 3:00
"01603"77.29.115.105'lzma"kirk"No, Linus rejected Phillip's lzma patches. I just pulled Phillip's squashfs-lzma into 2.6.34's git tree and compiled it. Haven't tried it out yet. It had a bug with 2.6.32/33. Think it might be fixed now."20 May 2010, 3:13"01603"206.53.157.140'Stuff"BarryK"Dougal, CPU maxed out?! I don't know what you are doing. It isn't like normal version control systems, you don't run "bones save" every time you make one change, only occasionally. In fact, you don't really need to run "bones save" at all. The model is for a single central developer, and you synchronise to latest Woof by running "bones download" -- which will archive any user-modified project files before over-writing them. kirk, According to the release announcement on the kernelnewbies site, lzma and lzo made it into Squashfs. Username: 20 May 2010, 10:18
"01603"114.129.167.148're; lzma"kirk"See this http://lkml.org/lkml/2010/4/21/457 I've been using 2.6.34 with lzma patched in, but it hung twice out of about ten boots. So I just compiled 2.6.34 without the lzma stuff to see if the problems persists. When I tried lzma with 2.6.32 and 33, I would get intermittent lock-ups and squashfs read errors, usually when X when would try to start. The two lockups I got this time didn't have any errors. I'm not 100 percent sure it's the lzma stuff yet. When I tried 2.6.34rc4 without lzma it would hang too. I saw in the patch for rc6 fixes for squashfs, I was hoping that might resolve these problems. "21 May 2010, 10:57"01603"75.91.98.123'Bones"Dougal"All I did was "bones download". It seems like -- since it's the first time it is run -- it gets the _original_ tarball and then applies all the patches (deltas) on top of it, in succession... so you get about thirty patches to apply (each taking something like a minute or so). I still don't see what the point is in having things like the static Busybox binary in there -- you're downloading packages for woof, so you might as well also create a "busybox-static" package and have the scripts use that (it will also make it easier to upgrade/change busybox). (Speaking of static compiling, you might have noticed that the uClibc ext2 filesystem is a little old... since they no longer support that way of using it. However, there seems to be an alternative: http://www.scratchbox.org/download/files/sbox-releases/stable/ I haven't tried yet (big download), but they have x86 images there.) Also woof-related: a new Slackware will be released soon, so you might want to update the package list for that. Username: 22 May 2010, 23:44
"01603"109.64.18.231'kernel 2.6.33"01micko"Hi Barry Trying to compile 2.6.33.2 from your source in lupu. Um, I'm new to this. getting this error at "make bzImage" [code]/tmp/ccp5xXOe.s: Assembler messages: /tmp/ccp5xXOe.s:10: Error: unknown pseudo-op: `.cfi_sections' make[4]: *** [arch/x86/kernel/acpi/realmode/wakemain.o] Error 1 make[3]: *** [arch/x86/kernel/acpi/realmode/wakeup.bin] Error 2 make[2]: *** [arch/x86/kernel/acpi] Error 2 make[1]: *** [arch/x86/kernel] Error 2 make: *** [arch/x86] Error 2[/code] Any idea? Cheers"23 May 2010, 18:16"01603"115.64.206.145'Re error"BarryK"No, have no idea. Username: 23 May 2010, 21:31
"01603"114.129.167.148'mending bones"technosaurus"@Dougal - xdelta is better for binary files - If it weren't for woof needing to have binary files there is already a similar version control project called Bky, by Angel Ortega at triptico.com (also the author of the Minimum Profit text editor) that works almost exactly as you describe I guess the binaries could be separate, but that would be painful to manage. ... the current setup is probably much easier for Barry to maintain and time spent on version control is time away from working on woof, quirky, and other projects. Still if you find a way to periodically rebase on a current snapshot, I would love to see it too. busybox is now providing what amounts to a static uclibc allyesconfig build if you want to use it. The latest 486 build is available here: http://busybox.net/downloads/binaries/1.16.1/busybox-i486 I read the readme file there and found other uclibc extras provided by the same toolchain, but you would still need to provide a shared gtkdialog (probably without glade support since it is not required and would just be an extra dependency) Username: 25 May 2010, 2:02
"01603"138.162.8.58'Re Latest Woof"BarryK"Well, I suppose that I could upload the latest tarball of Woof for those who do not want the history. The way it is now, you download the original tarball from when Woof was placed on Bones, then the xdeltas. With broadband and a fast CPU, it only takes a few minutes to download them all and build the latest Woof. And it is a one-off download, as future "bones download" will only download any later xdelta files. When I do a "bones save" a woof-LATEST.tar.gz file gets generated, and I could also upload that, for those who don't want the history. But then they would miss out on the Bones update mechanism. Unless I expand "bones download" with option not to download the history. The problem with Bones, and most little projects that I work on, is my effort is spread rather thin. I have many ideas for what Bones could be made to do, and it should really be a major project in it's own right -- but I have to move on to all the other things I do. Ok, I'll go back and give Bones some more attention. Username: 25 May 2010, 8:48
"01603"114.129.167.148'lupu compile error when recompiling 2.6.33 source"nohype"@01micko, that's a known problem with older binutils (2.18). Please install 2.20.1-binutils from the Puppy Package Manager. Username: 25 May 2010, 19:16
"01603"85.179.155.130're compile error"01micko"Thank you So far so good, now to see if it works! Cheers"25 May 2010, 24:40"01603"115.64.206.145'

Tags: puppy