vivid-sources

[Woocash]

Ang I've got this error when I wrote ./gcpuctl_hydra :

[fallow]

[Woocash]

Big THX @fallow )))

[DaMouse]

your still using the very old menuconfig-name thing, I updated it:

http://kernel.damouse.co.uk/daconfig/

-DaMouse
_________________
I am the dark lord DaMouse I eat souls and wear the dressing gown of evil.

[fallow]

ok our latest mm release is 2.6.9-rc4-vv_e7 based on mm1.

main features :

[gun26]

I emerged with USE="vesa_tng" and the compile failed this way:

[fallow]

sorry for this error, I using vesa_rrc all the time and i`ve dont tested it with vesa tng patch (compiling) , one of polish forum users point this error today , and I taked the correct ( for mm ) vesa-tng patch from love-pre broken-out release ( I don`t have much time today ) . Now I deleted the old patch file (vesatng_mm.patch.bz2 ), and put new - good - ( vesatng_mm_love.patch.bz2 ) . now its compiling and linking fine.

new ebuild has the same name. sorry again
http://amnesty.scene.pl/~sqward/fallow/kernel/vv_e7/vve-sources-2.6.9_rc4-r7.ebuild
_________________
"Time is a companion that goes with us on a journey. It reminds us to cherish each moment, because it will never come again. What we leave behind is not as important as how we have lived" J-L. Picard

[gun26]

Thank you for the prompt response, fallow. On my setup, any vesa console other than vesa_tng ends up getting scrambled when I switch back after starting X (using the nvidia driver), so vesarrc has never been an option. I've already downloaded the new patch and ebuild and I'll give them a try.

By the way, for vivid are you reversing the mm-sources "optimize-profile-path-slightly.patch"? From my lkml reading, that seems to be the prudent thing to do for both rc3-mm3 and rc4-mm1, so that's what I've been doing myself.

[fallow]

[gun26]

I got it compiled and it's running fine here too, including both vesafb_tng and fbsplash. Sound (via the redoubtable VIA8233 south bridge of my KT-266 chipset) is working well. Ditto the Reiser4 filesystem and everything else kernel-related that I can find.

I've seen random lockups, especially under load, with other patchsets using Con's scheduler in the past, so I suppose the true test will be not getting those here. So far so good, anyway.

Thanks for the links to those threads, but no Polish skills here, alas.

[fallow]

about staircase , imho it`s best desktop cpu scheduler , even if some releases has errors (like 8.3-8.9 etc.) . I also think it`s depend of many individual things and system configurations. for someone better is staircase , for someone nick`s , someone prefers O)1 and someone one of the Peter Williams`s SPA based.

for example some people said , that xmms cut`s sound playing with staircase , but doesn`t know that exists ISO_MODE and schedtool -I -e xmms/bmp solve the problem.

I`m used to to renice X`s to -10 , with staircase it`s not required and as I see X`s working better without it on staircase . With nick`s X`s working better with renincing for me.

also ...imho is good to test some cpu schedulers using spa_hydra and swithing its at runtime .
btw. cfq2 is not a gold solution for every situation, it has bad transfer rate with big files copying , so it`s also good to have io modular_and_switchable schedulers and switching io_sched depends of situation...

ok , I`m go to watch some movie

greetings
_________________
"Time is a companion that goes with us on a journey. It reminds us to cherish each moment, because it will never come again. What we leave behind is not as important as how we have lived" J-L. Picard

[fallow]

also If You`re interested in quick VP update from U2 to U4

http://amnesty.scene.pl/~sqward/fallow/kernel/vv_e7/u2_to_u4.diff.bz2

greetings
_________________
"Time is a companion that goes with us on a journey. It reminds us to cherish each moment, because it will never come again. What we leave behind is not as important as how we have lived" J-L. Picard

[gun26]

Well unfortunately, this morning the system locked up solid under heavy load. I think it's the same old problem I keep finding with Con's patches with any of the 2.6.9_rc-anything kernels. It feels fast as all hell and ends up locking up sooner or later. This has happened to me with many different patchsets that use Con's work, but never so far with straight mm-sources. I could try recompiling with 8I instead of K, but I'm not hopeful that it will make any difference.

[DaMouse]

Fancy merging modular i/o schedulers?

http://kernel.damouse.co.uk/modular/

-DaMouse
_________________
I am the dark lord DaMouse I eat souls and wear the dressing gown of evil.

[fallow]

[fallow]

ok , next release based on 2.6.10-rc1.

main objectives :
* select from (menu)config beetwen staircase9.0 and std O)1 CPU Scheduler
* 2.6.10-rc1-bk2 (so, cfq2 and switchable-and-modular-io-schedulers )
* some mm patches + reiser4 from 2.6.9-mm1
* fbsplash + some additional fs`s and some drivers
* Con`s version of part of Ingo Molnar`s latency fixes

[gun26]

Happened to see your announcement of your new version and I just had to try it.

I emerged with USE="vesa_tng" and picked Staircase 9 for the CPU scheduler. So far so good - everything's working so far, including Reiser4, vesafb, fbsplash, the nvidia kernel, and VIA 8233 sound . Good job, fallow. I was impressed that you got vesa_tng to work with 2.6.10-rc1. When I tried patching it for myself, it wouldn't compile. And fbsplash with 2.6.10-rc1 was hopeless - way too many rejects for me to deal with with my limited knowledge. Kudos. Your kernel patchset deserves more attention in the English language forum.

We'll see if my previous lockup problem with Con's patches returns - if it does, I can try the other CPU scheduler choice, I guess. By the way, is the other scheduler I can pick - "2.6 O)1 CPU Scheduler" - the original one in 2.6.10-rc1?

[fallow]

Glad to hear that

about fbsplash , really there was a "little bit" rejects.
I trust much in Spock (dev.gentoo.org/~spock) knowledge than my,so until Spock resync of fbsplash to latest kernel, I fixed part and part (fbcon.c) is from previous version.

[fallow]

ok , this time new vv_e based on 2.6.10-rc1-bk16.I think is good idea to make version based on O)1 CPU Scheduler from 2610rc1bk16 and partial mm fixes/patches.

main mission objectives :
- 2.6.10-rc1-bk16 with O)1 cpu sched
- fbsplash , vesa_rrc/tng selectable via USE
- reiser4 from latest mm`s
- partial fixes/speed-up`s from mm.

[gun26]

YAY!! Perfect timing, fallow! In the last couple of days I tried to put together my own custom-patched kernel with reiser4, Con's ck3 patchset, and a few things from gentoo-dev-sources including vesa_tng and fbsplash. It patched and ran fine, but within a few hours I got my old bugaboo with Con's patches: lockup. Meanwhile, vv_e1 has been very good for me (with vesa_tng and Con's scheduler, so it works for me at least SOME of the time).

vv_e2 is compiling as I write this - I'll let you know how it goes. By the way, do you have any suggestions for an objective, quantifiable comparison of different kernels? I'd like to base my decisions on more than just what feels fast and turns out to be stable, which is pretty much all I do now.

Edit: Well, dang - I got a compile error:

[Pepek]

[fallow]

yes . erros was fixed in this patch -> http://www.munet.eu.org/~fallow/vv_e2/jbdfix1.diff.bz2. I`ve also added it to the ebuild ( the same name ) .

jbd is required for debbuging , I`m using ext3 without jbd

[gun26]

This is quite belated - soon after reading your replies, Pepek and fallow, I re-downloaded and this time it compiled without errors. But then I found that nvidia-kernel (6629) although it compiled fine and loaded, would hang the machine with a black screen when I started X. At that point I ran out of time to do anything more on it. Today I took the time to do some reading at the nvnews.net Nvidia forums and found the following patch, which is called 2.6.10-rc1-bk8-VM_IO.diff.txt:

[fallow]

nice I`ve tried this one some time ago but without effect`s

I`m using 6629 now with vv_e2 without black screen.
is without black screen when :
- I`m using agpgart for via build in kernel
- or with nvagp 0 with xorg.conf , but very slowly one.

If I`m using nvagp not agpgart I have black screen`s ( other patches from k&h nv 6629 thread also )

which agp are You using nv or agpgart ?

greetings
_________________
"Time is a companion that goes with us on a journey. It reminds us to cherish each moment, because it will never come again. What we leave behind is not as important as how we have lived" J-L. Picard

[gun26]

I'm using NvAGP. I used to use agpgart, but when I first started struggling - and I do mean struggling - with vesa framebuffers and bootsplash last winter, I ran into the old, old problem of vesa consoles getting scrambled whenever X loaded with the nvidia-kernel driver. One of the pieces of advice I read back then was to disable agpgart in the kernel and enable Nvagp in XF86config/xorg.conf. It didn't work - it took Spock's wonderful work with vesafb_tng and fbsplash for me to get the console eye candy going and playing well with X and the nvidia-kernel. But I've configured my kernels that way ever since - no agpgart and NvAGP "1" in xorg.conf. I'm not sure if this affects performance - I've never tried it the other way.

Anyway, vv_e2 is humming along very nicely here. Kudos.

Your patchset really deserves to be better known. I think we'd all better learn Polish ASAP.