vivid-sources

[Woocash]

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

Code: Select all

# ./gcpuctl_hydra.py
Traceback (most recent call last):
  File "./gcpuctl_hydra.py", line 3, in ?
    import pygtk, gtk, gtk.glade, os, re
ImportError: No module named pygtk

Who helps me ?

[fallow]

I've got this error when I wrote this :

Code: Select all

rc-update add cpu_sched default

woocash ~ # rc-update add cpu_sched default
* cpu_sched not executable; skipping

oka , You have to set u+x for cpu_sched ex.

Code: Select all

chmod u+x cpu_sched

and for 2nd post :
Try to emerge pygtk
i`m back from vacations , wow 2.6.8 stable is out
greetings

[Woocash]

Big THX @fallow )))

[DaMouse]

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

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

-DaMouse

[fallow]

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

main features :

Code: Select all

 * Voluntary Preempt U2 , Staircase 8.K and 8.I selectable from menuconfig
 * fbsplash,lufs,lirc,shfs,supermount and some LKML fixes
 * also of course built mm patches like latency fixes/speed-ups , io-modular-schedulers selection and reiser4 , kexec etc.

"vesa_rrc" - old vesa refresh rate patch with vesafb_modes.h edited for 1024x768@85Hz
"vesa_tng" - new vesa tng refresh rate patch
"badram" - badram via USE ,not tested.

patch list:

Code: Select all

[ 2.6.9-rc4-mm1-vivid_e7 ]

voluntary-preempt-2.6.9-rc4-mm1-U2
--base-----------------------------------------
 /selection beetween 8.I and 8.K from menuconfig :)
+ 2.6.9-rc4-mm1_to_staircase8.I.diff
+ Staircase 8.K [ s8i_to_8j + s8j_to_s8k ] 
schedbatch2.4.diff
schediso2.7.diff
schedrange.diff
mapped_watermark6.269r4mm1.diff.bz2 /DaMouse/
--fb/gen/bootsplash----------------------------
fbsp09r8_269rc4mm1vivid.diff
--more fs`s/hardw support----------------------
shfs_good.patch  /Pepek/
supermount-ng205.diff
ir_synaptics_tpad.patch
lirc-2.6.5-20040404
lirc_i2c.diff
px-lirc-hotfix.patch /Pax82/
lufs-0.9.7-2.6.0-test9.patch.bz2
--for more configurable options---------------- 
configurable-hid-mouse-polling-2.6.9-rc2.patch
config_hz.diff
iosched_def_sel.diff /trivial alternative to bootparams elevator=x/
kernel-MAX_INIT_ARGS.patch
daconfig-2.1.1.patch /new DaMouse menuconfig-name/
--LKML fixes-----------------------------------
cfq2_high_io_load_fix.diff /selectable from menuconfig,is better without sometimes imho/ 
acpi_fix1_np.diff
r8169_oops_fix.diff 
proc_fs_fix.diff
amd64_numa_fix.diff
cpu_hotplug_fix.diff
--via USE flags--------------------------------
BadRAM-2.6.8.1.patch
vesa_rrc.patch.bz2
vesatng_mm.patch.bz2

ebuild -> http://amnesty.scene.pl/~sqward/fallow/ ... -r7.ebuild

of course comments , propositions , additions ,feedback will be nice

greetz.

[gun26]

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

Code: Select all

  LD      arch/i386/lib/built-in.o
  CC      arch/i386/lib/bitops.o
  AS      arch/i386/lib/checksum.o
  CC      arch/i386/lib/delay.o
  AS      arch/i386/lib/getuser.o
  CC      arch/i386/lib/memcpy.o
  CC      arch/i386/lib/mmx.o
  CC      arch/i386/lib/strstr.o
  CC      arch/i386/lib/usercopy.o
  AR      arch/i386/lib/lib.a
  GEN     .version
  CHK     include/linux/compile.h
  UPD     include/linux/compile.h
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
drivers/built-in.o(.text+0x16109): In function `vesafb_thread':
: undefined reference to `remap_page_range'
drivers/built-in.o(.text+0x16133): In function `vesafb_thread':
: undefined reference to `remap_page_range'
make: *** [.tmp_vmlinux1] Error 1

I later tried the same vesatng_mm.patch.bz2 on mm-sources (without the vivid-sources additions), and got the same compile error. A quick look at lkml.org tells me that the remap_page_range() function is gone, because it caused memory overflow problems on at least some architectures. Something called remap_pfn_range() apparently has replaced it. At the moment this may be only an mm-sources issue, but this looks like something that will end up in the main kernel pretty soon, so it's well worth fixing for patches like vesa_tng. At this point I'm well beyond my depth in C expertise to make the required changes to the vesa_tng patch to make it work with the newer function, but I'd sure appreciate anything anyone can come up with to fix the patch. The last couple of mm-sources kernels have actually been real honeys in smoothness and performance, so I'm always interested in patchsets like vivid built on top of mm.

[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/ ... -r7.ebuild

[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]

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.

no problem.I had the same problems with "optimize-profile-patch-slighlty.patch" with rc3-mm3...and I must reverse this.
(errors like this)

Code: Select all

/usr/bin/mozilla: line 87:  3265 Segmentation fault      $mozbin "$@"

but with this vivid release everything seems to be fine about profiling errors.I can run mozilla / nobody report bugs with profiling, so I decided to not reversing it. If somethings will be wrong of course I reverse it from base patch.

If you have something to add , some fixes or additions (and time of course ) , just do it. Then I upload it on the server. Cooperation , sugestions are welcome

we have this polish forum thread about vivid_e , and and about "stable" 2681 releases but the language is polish

greetings.

[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

[fallow]

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

http://amnesty.scene.pl/~sqward/fallow/ ... 4.diff.bz2

greetings

[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

[fallow]

Fancy merging modular i/o schedulers?
http://kernel.damouse.co.uk/modular/
-DaMouse

http://kernel.damouse.co.uk/modular/ is empty at now .

We used this patches from mm for io mudalar schedulers with non-mm based releases vv_e1 to vv_e5

Code: Select all

switchable-and-modular-io-schedulers-fix.patch 
switchable-and-modular-io-schedulers-hack-fix.patch 
switchable-and-modular-io-schedulers.patch 
update-cfq-v2-scheduler-patch.patch 
cfq-v2-pin-cfq_data-from-io_context.patch 
return-einval-on-elevator_store-failure.patch

Your patch ( http://kernel.damouse.co.uk/modular-ioschedulers.patch ) is some kind of all in one ?

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.

hmm,so I have the same opinion as You,if with O)1 cpu scheduler everythings is ok and with staircase your system always is going to lock up,then good solution is to not use staircase ( maybe to give a try for some of SPA family? ) or maybe You describe this problem at CK mailing lists ?
http://bhhdoa.org.au/mailman/listinfo/ck

or maybe xx-sources ?
greetings

[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

"vesa_rrc" - vesa rrc with definitions for 1024x768@85Hz
"vesa_tng" - new vesa tng

possible choice from additional menu is beetween Staircase9 and O)1, the default is Staircase9 also , the choice of default io scheduler (std , default is deadline ) instead of kernel boot params elevator=xxx. and lkml cfq2 heavy i/o load fix is selectable (default is off)

Code: Select all

--additional (menu)config selection------------------------
cfq_2_high_io_load_lkml1_fix.diff
default_io_scheduler_select.diff
staircase_and_o1_select.diff
--base-----------------------------------------------------
patch-2.6.10-rc1-bk2.bz2
bk-alsa.patch
2.6.9_to_staircase9.0.diff
schedbatch2.5.diff
schediso2.8.diff
schedrange.diff
269-mingo_ll.diff
--mm part--------------------------------------------------
fix-bad-segment-coalescing-in-blk_recalc_rq_segments.patch
i-o-space-write-barrier.patch
invalidate_inodes-speedup.patch
ipvs-deadlock-fix.patch
make-tree_lock-an-rwlock.patch
minimal-ide-disk-updates.patch
no-buddy-bitmap-patch-revisit-for-mm-page_allocc.patch
no-buddy-bitmap-patch-revist-intro-and-includes.patch
sched-ext3-fix-scheduling-latencies-in-ext3.patch
sched-mm-fix-scheduling-latencies-in-copy_page_range.patch
sched-net-fix-scheduling-latencies-in-__release_sock.patch
vm-pages_scanned-active_list.patch
vmscan-total_scanned-fix.patch
vmtrunc-bug-if-page_mapped.patch
--add-ons / fs --------------------------------------------
fbsplash-0.9-r8-2.6.9.patch
2.6.9-mm1-reiser4.diff
acerhk.patch
cddvd-cmdfilter-drop.patch
configurable-hid-mouse-polling-2.6.9-rc2.patch
daconfig-2.1.1.patch /DaMouse/
kernel-MAX_INIT_ARGS.patch
lirc-2.6.5-20040404
lirc_i2c.diff
px-lirc-hotfix.patch /Pax82/
lufs-0.9.7-2.6.0-test9.patch.bz2
shfs_good.patch /Pepek/
supermount-ng207.diff
synaptics-touchpad-driver-ir.patch
touchpad_scroll-2.6.7-gentoo-r5.diff
--USE--
vesa_rrc | vesa_tng

ebuild -> http://amnesty.scene.pl/~sqward/fallow/ ... -r1.ebuild

If You recompiling kernel with another cpu scheduler don`t forget to recompile modules like nvidia for ex.

greetings

[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.

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?

Yes , exactly

greetings

[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.

"vesa_rrc" - vesa_rrc
"vesa_tng" - vesa tng

lista :

Code: Select all

CPU Scheduler = Ingo`s O)1 from 2610-rc1-bk16 + part of mm patches.
default IO Scheduler = Deadline 
(selectable from menuconfig and switchable at runtime)
--base-------------------------------------------------------------
patch-2.6.10-rc1-bk16.bz2
config_hz.diff
fbsplash-0.9-r8-2.6.10-rc1.patch
2.6.9-oom-kill-fix.patch
shfs_good_035.patch
supermount-ng207.diff
reiser4_from_2610rc-mm
iosched_def_select.diff
lkml_high_io_load_select.diff
kernel-MAX_INIT_ARGS.patch
lufs-0.9.7-2.6.0-test9.patch.bz2
nvidia_compat.diff
cddvd-cmdfilter-drop.patch
configurable-hid-mouse-polling-2.6.9-rc2.patch
--mm part----------------------------------------------------------
add-lock_need_resched.patch
add-page-becoming-writable-notification.patch
allow-modular-ide-pnp.patch
bootmem-use-node_data.patch
break-latency-in-invalidate_list.patch
detect-atomic-counter-underflows.patch
idle-thread-preemption-fix.patch
invalidate_inodes-speedup.patch
make-tree_lock-an-rwlock.patch
prio_tree-fix-prio_tree_expand-corner-c.patch
provide-a-filesystem-specific-syncable-page-bit-fix-2.patch
provide-a-filesystem-specific-syncable-page-bit-fix.patch
provide-a-filesystem-specific-syncable-page-bit.patch
sched-active_load_balance-fixlet.patch
sched-add-cond_resched_softirq.patch
sched-ext3-fix-scheduling-latencies-in-ext3.patch
sched-fix-scheduling-latencies-for-preempt-kernels.patch
sched-fix-scheduling-latencies-in-mttrc.patch
sched-fix-scheduling-latencies-in-vgaconc.patch
sched-mm-fix-scheduling-latencies-in-filemap_sync.patch
sched-mm-fix-scheduling-latencies-in-get_user_pages.patch
sched-mm-fix-scheduling-latencies-in-unmap_vmas.patch
sched-more-agressive-wake_idle.patch
sched-net-fix-scheduling-latencies-in-__release_sock.patch
sched-net-fix-scheduling-latencies-in-netstat.patch
sched-newidle-fix.patch
sched-reset-cache_hot_time.patch
sched-vfs-fix-scheduling-latencies-in-prune_dcache-and-select_parent-fix.patch
sched-vfs-fix-scheduling-latencies-in-prune_dcache-and-select_parent.patch
vm-pageout-throttling.patch

ebuild - > http://www.munet.eu.org/~fallow/vv_e2/v ... -r2.ebuild
all dir -> http://www.munet.eu.org/~fallow/vv_e2/

greetings

[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:

Code: Select all

  LD      fs/isofs/built-in.o
  CC      fs/jbd/transaction.o
  CC      fs/jbd/commit.o
fs/jbd/commit.c: In function `journal_commit_transaction':
fs/jbd/commit.c:544: error: void value not ignored as it ought to be
fs/jbd/commit.c:600: error: void value not ignored as it ought to be
fs/jbd/commit.c:796: error: void value not ignored as it ought to be
make[2]: *** [fs/jbd/commit.o] Error 1
make[1]: *** [fs/jbd] Error 2
make: *** [fs] Error 2

I guess jbd is part of the ext3 file system, right? Anything I can do to narrow down the problem?

[Pepek]

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

Code: Select all

  LD      fs/isofs/built-in.o
  CC      fs/jbd/transaction.o
  CC      fs/jbd/commit.o
fs/jbd/commit.c: In function `journal_commit_transaction':
fs/jbd/commit.c:544: error: void value not ignored as it ought to be
fs/jbd/commit.c:600: error: void value not ignored as it ought to be
fs/jbd/commit.c:796: error: void value not ignored as it ought to be
make[2]: *** [fs/jbd/commit.o] Error 1
make[1]: *** [fs/jbd] Error 2
make: *** [fs] Error 2

I guess jbd is part of the ext3 file system, right? Anything I can do to narrow down the problem?

Try download ebuild again. I think fallow now include in this ebuild patch for your problem.

Cheers.

[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

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).

:) , we have similar idea ( ck,gentoo-dev,pld mix in stable version of vivid - based on 2.6.9 - we have two lines at now - vv_e and vivid_stable ) I think O)1 from latest rc is pretty good , also mm fixes in addition

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.

I think the good way is to do some benchmark via bonnie++ for fs , nick`s scheduler latency timing program (this small one from his site ) and ...hmm.maybe it`s good idea to write some scipts for overall testing scheduler latencies for example , doing parallel calculations etc.
it`s long subject imho , better to talk on irc for ex

greetings

[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:

Code: Select all

diff -ru linux-2.6.10-rc1-bk8/mm/mmap.c linux-2.6.10-rc1-bk8-2/mm/mmap.c
--- linux-2.6.10-rc1-bk8/mm/mmap.c      2004-11-06 15:04:28.000000000 +0100
+++ linux-2.6.10-rc1-bk8-2/mm/mmap.c    2004-11-06 15:39:47.000000000 +0100
@@ -1011,7 +1011,8 @@
        __vm_stat_account(mm, vm_flags, file, len >> PAGE_SHIFT);
        if (vm_flags & VM_LOCKED) {
                mm->locked_vm += len >> PAGE_SHIFT;
-               make_pages_present(addr, addr + len);
+               if (!(vm_flags & VM_IO))
+                       make_pages_present(addr, addr + len);
        }
        if (flags & MAP_POPULATE) {
                up_write(&mm->mmap_sem);

After applying this patch and recompiling, vv_e2 and the Nvidia kernel play well together.

[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

[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.