Linux 2.6.34 Kernel Released! Time For 2.6.35

[Loris]

Will try out as soon as 2.6.34 arrives in Gentoo.

Is it possible to force a constant low power mode though? (Like ForceLowPowerMode in UMS X.Org.)

Little steps, cowboy.
This power management implementation permits the r600/r700 GPUs not to burst into flames.

It will be, when the new radeon power management code (which implements voltage variation, too) currently in the "drm-radeon-testing" git branch will be merged in Linus' development tree for 2.6.35. A week or two. Or three.

The developers implemented a sysfs interface which permits enabling a dynamic power management, or a single power state for the GPU/memory.

And that's great.

But I haven't tested it all, yet. I'll report if I do, before the mainline merge.

[curaga]

It is odd that kernelnewbies.org did not mention the updates to compcache in their release notes. I believe that compcache support is supposed to be at the stage where using the in-kernel code is recommended by its developers now.

The patches for full functionality were only posted on LKML on May 7. Ramzswap in .34 does have some bugfixes compared to .33, but the swap free notify is not in .34 (and lacking it makes things nearly useless).

Plus still in staging.

[korpenkraxar]

I've been spoiled with Arch's great community which provides AUR PKGBUILD scripts for the latest kernel and ATI code, and especially the Radeon enthusiasts over at: http://bbs.archlinux.org/viewtopic.php?id=79509&p=1

What is the recommended procedure to try the latest and greatest on Fedora? Are there similar user groups and repositories in the Fedora camp?

[Shining Arcanine]

Will try out as soon as 2.6.34 arrives in Gentoo.

Is it possible to force a constant low power mode though? (Like ForceLowPowerMode in UMS X.Org.)

It was in Gentoo within a few hours of release if you count sys-kernel/vanilla-sources.

[RealNC]

It was in Gentoo within a few hours of release if you count sys-kernel/vanilla-sources.

I know. It's just that I need the boot decor Gentoo patches :P

[Shining Arcanine]

I know. It's just that I need the boot decor Gentoo patches :P

You could make a local overlay for that.

[RealNC]

OK, I've just built 2.6.34 vanilla. It seems the boot decor is still working, in which case I'm left wondering what the heck the Gentoo patches do in the first place

I didn't apply Con's BFS patch, just to see how the default scheduler is doing. Hey, it doesn't suck hard anymore Nice, it seems they fixed most of it.

KMS and dynpm=1 seems to work with my HD4870; at least I can't hear the fan trying to create a scale F5 tornado anymore. Now if I could only know how to read temperatures for the GPU :-/ Probably not possible.

One thing I noticed with V-Synced KMS is that 60FPS video is stuttering hard in windowed mode; with UMS it's tearing of course, but silk-smooth otherwise. It's *almost* OK in fullscreen mode (KDE "unredirects" full screen apps.) Applying the BFS patch though fixed it in fullscreen. Windowed mode still sucks though. Fortunately, the majority of videos aren't 60FPS.

[RealNC]

Hmm, is OpenGL buggy with KMS? glxgears is not getting V-Synced :-/ I'd expect it to get locked at 60FPS (my monitor's refresh rate), but:

Running synchronized to the vertical refresh. The framerate should be
approximately 1/1096764487 the monitor refresh rate.
8297 frames in 5.0 seconds = 1659.295 FPS
7987 frames in 5.0 seconds = 1597.322 FPS
8433 frames in 5.0 seconds = 1686.381 FPS

[RealNC]

(Damn post edit time :P)

Observation #3: KMS is slow as molasses sometimes. And I was using UMS forced at constant low GPU clocks previously, so I guess that says something.

[RealNC]

I switched back to UMS. No one can live with this slowness and GUI lag.

It would be nice if I could say that KMS was worth the wait, but unfortunately this is not the case. It has been a major disappointment here. But I guess just like with fglrx, "next version will be better". Unfortunately for the OSS drivers, fglrx ships each month.