Official thread: "zen-sources" - Part III

[ejs76]

Just in case you mist it:

Nvidia-driver 173.08 is now included in main portage tree. It contains the 2.6.26-pre compatibility patch.

Part from changelog:

# ChangeLog for x11-drivers/nvidia-drivers
# Copyright 1999-2008 Gentoo Foundation; Distributed under the GPL v2
# $Header: /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog,v 1.97 2008/05/09 09:55:14 chainsaw Exp $

09 May 2008; Mark Loeser <halcy0n@gentoo.org>
nvidia-drivers-173.08.ebuild:
Works on x86 for me, marking ~x86

08 May 2008; <chainsaw@gentoo.org>
files/NVIDIA_kernel-173.08-2404825.diff:
Upstream corrected the patch after the fact, update it. No revision bump
as the package is masked.

07 May 2008; <chainsaw@gentoo.org>
nvidia-drivers-71.86.01.ebuild, nvidia-drivers-71.86.04.ebuild,
nvidia-drivers-96.43.01.ebuild, nvidia-drivers-96.43.05.ebuild,
nvidia-drivers-100.14.09.ebuild, nvidia-drivers-100.14.11.ebuild,
nvidia-drivers-100.14.19.ebuild, nvidia-drivers-100.14.23.ebuild:
Quote variables where appropriate.

*nvidia-drivers-173.08 (07 May 2008)

07 May 2008; <chainsaw@gentoo.org>
+files/NVIDIA_kernel-173.08-2404825.diff, +nvidia-drivers-173.08.ebuild:
Masked beta driver 173.08 with upstream patch from Zander (
http://www.nvnews.net/vbulletin/showpos ... stcount=35 ) for
>=2.6.26-rc1 compatibility. Dropped keywords as this has only been tested
on 2.6.26-rc1-00166-gc0a1811 SMP x86_64 so far. Now installs module
control file in modprobe.d where it belongs. Upstream advises to use PAT
over MTRR. Some reports of low performance and 2D corruption, tread
carefully.

[kernelOfTruth]

"regression" on bfq and cfq compared to other io-schedulers:

performance "regression" in cfq compared to anticipatory, deadline and noop

you guys noticed the same "behavior" ?

[Kollin]

OMG is custom-kernels dead :

Code: Select all

felis ~ # layman -a custom-kernels
* Running command "/usr/bin/svn co "http://opensvn.csie.org/custom_kernels/" "/usr/portage/local/layman/custom-kernels""...
svn: Unrecognized URL scheme for 'http://opensvn.csie.org/custom_kernels'
* Failed to add overlay "custom-kernels".
* Error was: Adding the overlay failed!

[MostAwesomeDude]

I've merged squashfs to master. I will NOT be merging LZMA or squashfs/LZMA as long as their patches are so terribly written, though.

[goffrie]

OMG is custom-kernels dead :

Code: Select all

felis ~ # layman -a custom-kernels
* Running command "/usr/bin/svn co "http://opensvn.csie.org/custom_kernels/" "/usr/portage/local/layman/custom-kernels""...
svn: Unrecognized URL scheme for 'http://opensvn.csie.org/custom_kernels'
* Failed to add overlay "custom-kernels".
* Error was: Adding the overlay failed!

custom-kernels works fine for me.
Maybe you didn't compile subversion with proper HTTP support -

ewarn "WebDAV support is disabled. You need WebDAV to"
ewarn "access repositories through the HTTP protocol."
ewarn
ewarn "WebDAV support needs one of the following USE flags enabled:"
ewarn " webdav-neon webdav-serf"
ewarn
ewarn "You can do this by enabling one of these flags in /etc/portage/package.use:"
ewarn " =${CATEGORY}/${PF} webdav-neon webdav-serf"

[darklegion]

"regression" on bfq and cfq compared to other io-schedulers:

performance "regression" in cfq compared to anticipatory, deadline and noop

you guys noticed the same "behavior" ?

Yes, I did benchmarks with hdparm -t -T and bfq was around 10MB/s per-seconds slower than anticipatory.
Also bfq temporarily freezes my system when growisofs is preparing to burn a dvd-r.BFQ has much better interactivity otherwise, though.
I'll post benchmarks later.

[rmh3093]

"regression" on bfq and cfq compared to other io-schedulers:

performance "regression" in cfq compared to anticipatory, deadline and noop

you guys noticed the same "behavior" ?

Yes, I did benchmarks with hdparm -t -T and bfq was around 10MB/s per-seconds slower than anticipatory.
Also bfq temporarily freezes my system when growisofs is preparing to burn a dvd-r.BFQ has much better interactivity otherwise, though.
I'll post benchmarks later.

I have been out of the loop in kernel shit for a while, just getting back into it, so I missed when BFQ came out, i first tried it on .25-zen and though it was absolutely horrid, I am not using .26-zen and I still think it sucks, i get those micro freeze like you ... what kernel are you on?

[rmh3093]

OMG is custom-kernels dead :

Code: Select all

felis ~ # layman -a custom-kernels
* Running command "/usr/bin/svn co "http://opensvn.csie.org/custom_kernels/" "/usr/portage/local/layman/custom-kernels""...
svn: Unrecognized URL scheme for 'http://opensvn.csie.org/custom_kernels'
* Failed to add overlay "custom-kernels".
* Error was: Adding the overlay failed!

custom-kernels works fine for me.
Maybe you didn't compile subversion with proper HTTP support -

ewarn "WebDAV support is disabled. You need WebDAV to"
ewarn "access repositories through the HTTP protocol."
ewarn
ewarn "WebDAV support needs one of the following USE flags enabled:"
ewarn " webdav-neon webdav-serf"
ewarn
ewarn "You can do this by enabling one of these flags in /etc/portage/package.use:"
ewarn " =${CATEGORY}/${PF} webdav-neon webdav-serf"

I am going to be removing custom kernels from layman....

[Kollin]

custom-kernels works fine for me.
Maybe you didn't compile subversion with proper HTTP support -

ewarn "WebDAV support is disabled. You need WebDAV to"
ewarn "access repositories through the HTTP protocol."
ewarn
ewarn "WebDAV support needs one of the following USE flags enabled:"
ewarn " webdav-neon webdav-serf"
ewarn
ewarn "You can do this by enabling one of these flags in /etc/portage/package.use:"
ewarn " =${CATEGORY}/${PF} webdav-neon webdav-serf"

You are correct !! Thank you !

I am going to be removing custom kernels from layman....

Well... no one wanted to update it anyway

[creidiki]

I have been out of the loop in kernel shit for a while, just getting back into it, so I missed when BFQ came out, i first tried it on .25-zen and though it was absolutely horrid, I am not using .26-zen and I still think it sucks, i get those micro freeze like you ... what kernel are you on?

You people need to learn to actually read the articles/mails instead of going off on your own personal tangent all the bleedin' time

That report says BFQ/CFQ has better interactvity than noop/anticipatory/deadline, but with a regression in pure IO performance - I'm surprised this is even a complaint, pure throughput always causes interactivity lossage and vice versa, its the same with pre-emption and HZ settings.

This is definitely not what you're encountering.

[rmh3093]

I have been out of the loop in kernel shit for a while, just getting back into it, so I missed when BFQ came out, i first tried it on .25-zen and though it was absolutely horrid, I am not using .26-zen and I still think it sucks, i get those micro freeze like you ... what kernel are you on?

You people need to learn to actually read the articles/mails instead of going off on your own personal tangent all the bleedin' time

That report says BFQ/CFQ has better interactvity than noop/anticipatory/deadline, but with a regression in pure IO performance - I'm surprised this is even a complaint, pure throughput always causes interactivity lossage and vice versa, its the same with pre-emption and HZ settings.

This is definitely not what you're encountering.

i meant to quote darklegion's post about the freezes/lags with bfq, not the article about the regression

[roadnottaken]

I am running the zen-sources git from repo.or.cz on a debian system and recently switched from bootsplash to fbcondecor. Unfortunately, the background only appeared on the first two consoles and I could not enable it on the other consoles. Earlier today, though, I recompiled my kernel after changing a few minor configuration items, and now I only get the fbsplash background on the second console. This recent behavior has me fully convinced that what I am experiencing is a bug. I would like help trying to resolve it and get fbsplash working fully on my system.

Can anyone help with this?

[MostAwesomeDude]

I am running the zen-sources git from repo.or.cz on a debian system and recently switched from bootsplash to fbcondecor. Unfortunately, the background only appeared on the first two consoles and I could not enable it on the other consoles. Earlier today, though, I recompiled my kernel after changing a few minor configuration items, and now I only get the fbsplash background on the second console. This recent behavior has me fully convinced that what I am experiencing is a bug. I would like help trying to resolve it and get fbsplash working fully on my system.

Can anyone help with this?

Please try the new version from zen-sources.org.

[darklegion]

I have been out of the loop in kernel shit for a while, just getting back into it, so I missed when BFQ came out, i first tried it on .25-zen and though it was absolutely horrid, I am not using .26-zen and I still think it sucks, i get those micro freeze like you ... what kernel are you on?

You people need to learn to actually read the articles/mails instead of going off on your own personal tangent all the bleedin' time

That report says BFQ/CFQ has better interactvity than noop/anticipatory/deadline, but with a regression in pure IO performance - I'm surprised this is even a complaint, pure throughput always causes interactivity lossage and vice versa, its the same with pre-emption and HZ settings.

This is definitely not what you're encountering.

i meant to quote darklegion's post about the freezes/lags with bfq, not the article about the regression

I should note, that I still prefer bfq over anticipatory and the rest, despite the current problems with it.Intertactivity is much better than anticipatory in most cases, and cfq seems to have more of these corner cases than bfq.

EDIT: I ran the benchmarks again, and I don't seem to be getting any major differences between bfq/anticipatory/cfq.

[rmh3093]

I have been out of the loop in kernel shit for a while, just getting back into it, so I missed when BFQ came out, i first tried it on .25-zen and though it was absolutely horrid, I am not using .26-zen and I still think it sucks, i get those micro freeze like you ... what kernel are you on?

You people need to learn to actually read the articles/mails instead of going off on your own personal tangent all the bleedin' time

That report says BFQ/CFQ has better interactvity than noop/anticipatory/deadline, but with a regression in pure IO performance - I'm surprised this is even a complaint, pure throughput always causes interactivity lossage and vice versa, its the same with pre-emption and HZ settings.

This is definitely not what you're encountering.

i meant to quote darklegion's post about the freezes/lags with bfq, not the article about the regression

I should note, that I still prefer bfq over anticipatory and the rest, despite the current problems with it.Intertactivity is much better than anticipatory in most cases, and cfq seems to have more of these corner cases than bfq.

EDIT: I ran the benchmarks again, and I don't seem to be getting any major differences between bfq/anticipatory/cfq.

well that lag is unacceptable to me, im going back to AIO

[tranquilcool]

frequent freezes with bfq.
am back to cfq for now.

[rmh3093]

frequent freezes with bfq.
am back to cfq for now.

are you getting those hardlocks on the .25 kernel or the .26-rc1 kernel

[tranquilcool]

frequent freezes with bfq.
am back to cfq for now.

are you getting those hardlocks on the .25 kernel or the .26-rc1 kernel

on both.

[rmh3093]

frequent freezes with bfq.
am back to cfq for now.

are you getting those hardlocks on the .25 kernel or the .26-rc1 kernel

on both.

thats not good, i though we narrowed the hardlocks to the some of the -rt patches were merged into .25

[hoacker]

frequent freezes with bfq.
am back to cfq for now.

Had some freezes with bfq and .25, too. Disabled swap prefetching as suggested by KernelOfTruth earlier in this thread and no more freezes since.

BTW: Anyone got NVIDIA < 173.08 running with .26? Won't emerge for me...

[tranquilcool]

frequent freezes with bfq.
am back to cfq for now.

are you getting those hardlocks on the .25 kernel or the .26-rc1 kernel

on both.

thats not good, i though we narrowed the hardlocks to the some of the -rt patches were merged into .25

let me try to disable swap prefetching and see if that's
the problem.

[rmh3093]

frequent freezes with bfq.
am back to cfq for now.

Had some freezes with bfq and .25, too. Disabled swap prefetching as suggested by KernelOfTruth earlier in this thread and no more freezes since.

BTW: Anyone got NVIDIA < 173.08 running with .26? Won't emerge for me...

no i think the only version that works with .26 is nvidia-drivers-173.08

[tranquilcool]

frequent freezes with bfq.
am back to cfq for now.

Had some freezes with bfq and .25, too. Disabled swap prefetching as suggested by KernelOfTruth earlier in this thread and no more freezes since.

BTW: Anyone got NVIDIA < 173.08 running with .26? Won't emerge for me...

no i think the only version that works with .26 is nvidia-drivers-173.08

there is a patch somewhere to make it work. let me see if i can find it.
haven't tried it though so dunno if it works.

patch for nvidia-drivers-169.12 for 2.6.26-rc1-zen-zen0 -> http://omploader.org/vaG50

[jurek]

patch for nvidia-drivers-169.12 for 2.6.26-rc1-zen-zen0 -> http://omploader.org/vaG50

Code: Select all

Verifying archive integrity... OK
Uncompressing NVIDIA Accelerated Graphics Driver for Linux-x86 169.12............................................................................................................................................................................................................................................................................................
patching file usr/src/nv/nv-linux.h
Hunk #2 succeeded at 680 (offset -4 lines).
Hunk #3 succeeded at 1025 (offset -14 lines).
Hunk #4 succeeded at 1124 (offset -14 lines).
patching file usr/src/nv/nv-reg.h
Hunk #1 succeeded at 469 (offset -2 lines).
Hunk #2 succeeded at 524 with fuzz 1 (offset -2 lines).
Hunk #3 succeeded at 570 with fuzz 1 (offset -2 lines).
patching file usr/src/nv/nv.c
Hunk #1 succeeded at 21 (offset -1 lines).
Hunk #2 succeeded at 39 (offset -1 lines).
Hunk #3 succeeded at 605 (offset 2 lines).
Hunk #4 succeeded at 857 (offset 2 lines).
Hunk #5 succeeded at 894 (offset 2 lines).
Hunk #6 succeeded at 905 (offset 2 lines).
Hunk #7 succeeded at 982 (offset 2 lines).
Hunk #8 succeeded at 1007 with fuzz 1 (offset 2 lines).
Hunk #10 succeeded at 1273 with fuzz 1 (offset -3 lines).
Hunk #11 succeeded at 1305 (offset -3 lines).
Hunk #12 FAILED at 1314.
Hunk #13 succeeded at 1442 (offset -3 lines).
Hunk #14 succeeded at 1520 (offset -2 lines).
Hunk #15 succeeded at 1696 (offset -2 lines).
Hunk #16 succeeded at 1823 (offset -14 lines).
Hunk #17 succeeded at 1835 (offset -14 lines).
Hunk #18 succeeded at 1863 (offset -14 lines).
Hunk #19 succeeded at 2202 (offset -25 lines).
Hunk #20 succeeded at 2231 (offset -25 lines).
Hunk #21 succeeded at 2252 (offset -25 lines).
Hunk #22 succeeded at 3487 (offset -25 lines).
Hunk #23 FAILED at 3503.
Hunk #24 FAILED at 3531.
Hunk #25 succeeded at 3757 (offset -40 lines).
3 out of 25 hunks FAILED -- saving rejects to file usr/src/nv/nv.c.rej
patching file usr/src/nv/os-agp.c
patching file usr/src/nv/os-interface.c
Hunk #1 succeeded at 1339 (offset -16 lines).
Failed to apply patch file "/home/jurek/Desktop/nvidia-drivers-kernel.patch"

[hoacker]

patch for nvidia-drivers-169.12 for 2.6.26-rc1-zen-zen0 -> http://omploader.org/vaG50

Code: Select all

Verifying archive integrity... OK
Uncompressing NVIDIA Accelerated Graphics Driver for Linux-x86 169.12............................................................................................................................................................................................................................................................................................
patching file usr/src/nv/nv-linux.h
Hunk #2 succeeded at 680 (offset -4 lines).
...
Failed to apply patch file "/home/jurek/Desktop/nvidia-drivers-kernel.patch"

Works fine here for me (1st boot with .26 and nvidia 169.12 few seconds ago). I modified the ebuild to apply the patch AFTER the regular patches included in portage.

[EDIT: typo fixed]