Official thread: "zen-sources" - Part 8

[Rion]

is here any easy way to downgrade alsa to 1.0.20?
1.0.21 doesn't work properly for me.

PS zen-stable

[DigitalCorpus]

I also saw an option to enable something like SCHED_ISO X for X sever, but can find nothing much explaining it anywhere. It is mentioned on the Arch forums. Is this a recommended option with zen?

Here is a copy paste from me asking that same question a couple days ago, It's one of the first results if you do a search.

here's a copy past about sched_iso:
"Unique to -ck this is a scheduling policy designed for pseudo-realttime scheduling without requiring superuser privileges (unlike SCHED_RR and SCHED_FIFO). When scheduled SCHED_ISO, a task can receive very low latency scheduling, and can take the full cpu like SCHED_RR, but unlike the realtime tasks they cannot starve the machine as an upper limit to their cpu usage is specified in a tunable (see below). It is designed for realtime like behaviour without risk to hanging for programs not really coded safely enough to be run realtime such as ordinary audio and video playback software. SCHED_ISO does not take a realtime priority, but nice levels like other normal tasks, although the nice value is largely ignored except when the task uses more than its cpu limit."

[asturm]

*) Use KLive to help us track Zen kernel usage stats! December 18th 2008 link

Isn't klive rather unmaintained at this time? I disabled it some time ago because it had issues with openrc...

EDIT: Ok, trying to boot 2.6.31-zen2 the first time resulted in a black screen. I don't think it's a BFS issue since already bfs-232 made it to kdm login (but not further) and issues with i915 *should* have been fixed since then.

EDIT#2: Seems there still is some i915 bug maybe already fixed in bfs300-test2.patch, I'll wait for it then (won't apply against -zen2 master) to arrive in zen-sources.

EDIT#3: Black screen also with CFS.

EDIT#4: false alarm - CONFIG_DMAR_BROKEN_GFX_WA slipped through make oldconfig. Works now.

EDIT#5: Here's an unusual error I got through dmesg:

Code: Select all

[drm:i915_gem_execbuffer] *ERROR* Object ffff880095096240 appears more than once in object list

This could either be due to BFS, or caused by the 2.6.31-zen2 GEM code which hasn't got the improvements from 2.6.32 that I applied to my vanilla-2.6.31.1. I think I even came across a commit addressing such an issue...

[mantoo]

git down... need backup, need backup...

[cheater1034]

git down... need backup, need backup...

Yes, it's being converted to gitosis

[cheater1034]

Back up:
git://zen-sources.org/kernel/zen-stable.git

zen.git will follow momentarily

[rahulthewall]

Suspend and hibernate are still broken with bfs-300.

[cheater1034]

Suspend and hibernate are still broken with bfs-300.

shouldnt be, try vanilla with bfs 302

---
whoever mentioned a drm problem - i pulled latest drm-next and nouveau again - so try

and whoever wanted reiser4 too, that's there

*edit*
zen-stable.git totally updated:
- Changed zen-sched a bit for individual sched files, not to unify them
- reiser4 updated
- aufs updated
- drm and nouveau updatd
- 2.6.31.2
- 2.6.30 coming momentarily?

[tranquilcool]

to get nvidia-drivers-190.36 to compile with 2.6.32(zen.git)

here is a patch to apply to toolchain-funcs.eclass in /usr/portage/eclass/



--- toolchain-funcs.eclass.old 2009-09-02 13:12:39.000000000 -0700
+++ toolchain-funcs.eclass 2009-10-03 17:56:28.000000000 -0700
@@ -187,7 +187,8 @@
# Starting with linux-2.6.24, the 'x86_64' and 'i386'
# trees have been unified into 'x86'.
# FreeBSD still uses i386
- if [[ ${type} == "kern" ]] && [[ $(KV_to_int ${KV}) -lt $(KV_to_int 2.6.24) || ${host} == *freebsd* ]] ; then
+ # In 2.6.32, this has been changed back.
+ if [[ ${type} == "kern" ]] && [[ $(KV_to_int ${KV}) -lt $(KV_to_int 2.6.24) ]] || [[ $(KV_to_int ${KV}) -ge $(KV_to_int 2.6.32) ]] || ${host} == *freebsd* ]] ; then
echo i386
else
echo x86
@@ -230,10 +231,11 @@
x86_64*)
# Starting with linux-2.6.24, the 'x86_64' and 'i386'
# trees have been unified into 'x86'.
- if [[ ${type} == "kern" ]] && [[ $(KV_to_int ${KV}) -ge $(KV_to_int 2.6.24) ]] ; then
+ # In 2.6.32-rc1, this has been changed back.
+ if [[ ${type} == "kern" ]] && [[ $(KV_to_int ${KV}) -ge $(KV_to_int 2.6.24) ]] && [[ $(KV_to_int ${KV}) -lt $(KV_to_int 2.6.32) ]] ; then
echo x86
else
- ninj x86_64 amd64
+ echo x86_64
fi
;;

[asturm]

whoever mentioned a drm problem - i pulled latest drm-next and nouveau again - so try

hurray! Instantly trying...

[wrc1944]

Link to git posted above doesn't work- all I get is:

Error!
The address type is unknown or unsupported

Neither does:

Code: Select all

git clone git://zen-sources.org/zen-stable.git zen-sources

[asturm]

It has changed again to 'git://zen-sources.org/kernel/zen-stable.git', just alter your .git/config accordingly.

[wrc1944]

Thanks genstorm,
I tried

Code: Select all

git clone git://zen-sources.org/kernel/zen-stable.git

and it's cloning now into /usr/src.

EDIT: Hmmm- I'm not sure this is right.

Code: Select all

kdesvn src # git clone git://zen-sources.org/kernel/zen-stable.git
Initialized empty Git repository in /usr/src/zen-stable/.git/
remote: Counting objects: 1390604, done.
remote: Compressing objects: 100% (227726/227726), done.
RReceiving objects:  20% (279942/1390604), 188.75 MiB | 199 KiB/s

It says here that 279942 of 1390604 is 20%, and that's 188.75mb. At this rate, the zen-sources kernel directory is now going to be almost 1GB?

That can't be right.

EDIT2: OK- it finished up, and I now have the kernel sources in /sr--usr/src/zen-stable.

Code: Select all

kdesvn src # git clone git://zen-sources.org/kernel/zen-stable.git
Initialized empty Git repository in /usr/src/zen-stable/.git/
remote: Counting objects: 1390604, done.
remote: Compressing objects: 100% (227726/227726), done.
Receiving objects: 100% (1390604/1390604), 332.68 MiB | 199 KiB/s, done.
remote: Total 1390604 (delta 1159349), reused 1385720 (delta 1154626)
Resolving deltas: 100% (1159349/1159349), done.
Checking out files: 100% (29852/29852), done.

The makefile reads:

Code: Select all

VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 31
EXTRAVERSION = -zen2
NAME = Alien Mind Creator

so I guess I'm OK here.
However, zen-stable is 717.8mb, whereas 2.6.31-zen1 is 426.4mb (about like any of the hundreds of kernels I've compiled over the years).

Why this huge discrepancy?

[kernelOfTruth]

Suspend and hibernate are still broken with bfs-300.

shouldnt be, try vanilla with bfs 302

---
whoever mentioned a drm problem - i pulled latest drm-next and nouveau again - so try

and whoever wanted reiser4 too, that's there

*edit*
zen-stable.git totally updated:
- Changed zen-sched a bit for individual sched files, not to unify them
- reiser4 updated
- aufs updated
- drm and nouveau updatd
- 2.6.31.2
- 2.6.30 coming momentarily?

thanks !

It has changed again to 'git://zen-sources.org/kernel/zen-stable.git', just alter your .git/config accordingly.

done ...

updated links in the first post

[kernelOfTruth]

Thanks genstorm,
I tried

Code: Select all

git clone git://zen-sources.org/kernel/zen-stable.git

and it's cloning now into /usr/src.

EDIT: Hmmm- I'm not sure this is right.

Code: Select all

kdesvn src # git clone git://zen-sources.org/kernel/zen-stable.git
Initialized empty Git repository in /usr/src/zen-stable/.git/
remote: Counting objects: 1390604, done.
remote: Compressing objects: 100% (227726/227726), done.
RReceiving objects:  20% (279942/1390604), 188.75 MiB | 199 KiB/s

It says here that 279942 of 1390604 is 20%, and that's 188.75mb. At this rate, the zen-sources kernel directory is now going to be almost 1GB?

That can't be right.

indeed it IS right

du -hs linux-2.6/
1007M linux-2.6/
lexa kernel # du -hs zen-sources/
789M zen-sources/

please take a look at the Tips & Tricks section in the first post of this thread and search for: "speeding up merge (download) of zen-sources (during first time)"

that way you won't put that much load on the zen-servers - besides that you don't have to sync that much every time

only caveat:

*) you have to maintain / sync 2 overlays -> first the official kernel.org overlay then the one from zen-sources

IMO that makes everything easier and better sorted out


also when you want to use a new kernel --->

DON'T use the overlay-directory and re-checkout / clone everything when you want a new one:

instead

1) use the directory as reference / "archive" where everything lies

2) checkout the release you want: e.g. git checkout v2.6.31-zen2

3) copy over the directory to /usr/src (most of the .git stuff won't be copied and therefore you'll save space)

4) (example) resulting in the following folder structure:

/usr/src/linux-2.6.31-zen2
/usr/src/sources/kernel/linux-2.6/
/usr/src/sources/kernel/zen-sources/


edit:


it's not that extreme anymore but still somewhat big

456M zen-stable/

I guess I need to resync the official (kernel.org) repo to safe a few megabytes since it exists already pretty long on my part ...

[rahulthewall]

Suspend and hibernate are still broken with bfs-300.

shouldnt be, try vanilla with bfs 302

---
whoever mentioned a drm problem - i pulled latest drm-next and nouveau again - so try

and whoever wanted reiser4 too, that's there

*edit*
zen-stable.git totally updated:
- Changed zen-sched a bit for individual sched files, not to unify them
- reiser4 updated
- aufs updated
- drm and nouveau updatd
- 2.6.31.2
- 2.6.30 coming momentarily?

Vanilla (vanilla-sources-2.6.31.1) with BFS-302 works perfectly with suspend and hibernate. Zen-stable (with BFS-302) does not.

Moreover, the latest drm updates have resulted in my kms powered console being invisible. (Intel 945 GM).

In case (in the hope) it helps, here are my configs for vanilla and zen respectively.

http://pastebin.com/m17179dd6

http://pastebin.com/m24b2bf1e

Good night everyone!

[wrc1944]

kernelOfTruth,
Thanks for the info. In my post above (2nd edit- maybe you missed it)), zen-stable wound up at 717mb.
However, all the 2.6 kernel.org sources I've ever used (hundreds) are all around 400mb, even patched heavily.

The only reason I used git clone was because this was the first time using zen git on this box.

Maybe I'm misunderstanding, but your post above seems more complicated that I thought this stuff was going to be.

I thought I just did the git clone routine the first time, and then for future zen-x versions on that base (e.g. linux-2.6.31, or whatever) I just needed to do a git pull in that directory to update the zen version, and then recompile.

That's wrong?

I've never read anything in "zen" threads about having to maintain a second "offical kernel.org overlay."

[kernelOfTruth]

kernelOfTruth,
Thanks for the info. In my post above (2nd edit- maybe you missed it)), zen-stable wound up at 717mb.
However, all the 2.6 kernel.org sources I've ever used (hundreds) are all around 400mb, even patched heavily.

The only reason I used git clone was because this was the first time using zen git on this box.

Maybe I'm misunderstanding, but your post above seems more complicated that I thought this stuff was going to be.

I thought I just did the git clone routine the first time, and then for future zen-x versions on that base (e.g. linux-2.6.31, or whatever) I just needed to do a git pull in that directory to update the zen version, and then recompile.

That's wrong?

I've never read anything in "zen" threads about having to maintain a second "offical kernel.org overlay."

wrc1944, sorry for confusing you,

it indeed is somewhat more complicated (not really that much):

I'd like to have one or more fallback-kernels in case something goes wrong (it isn't that seldom),

and since I observed in the past that the (cloned) directory is bigger than a directory to which the directory was copied e.g.

cp -r zen-sources zen-sources_2.6.31-zen2

zen-sources_2.6.31-zen2 <-- was smaller (probably because all of the additional git/kernel-data of previous or above kernel-releases is missing)

I'm making kind of "copies" from the "master" (the git-repository) <-- thus resulting in space-usage


if you're fine with using one directory (the git-repository) and then updating to the latest via e.g. "git pull" and then re-compiling it - why not ?


do it that way which suits you best / your style


I hope that post was somewhat understandable since it's already pretty late here and it has been a pretty busy day


Good night @all

[wrc1944]

@kernelOfTruth,
As always, I benefit greatly from all your detailed and informative posts over the years, and always appreciate your willingness to spend time helping us Gentoo users. I'm sure I speak for a lot of people on this forum.
Thanks again!

[cheater1034]

Suspend and hibernate are still broken with bfs-300.

shouldnt be, try vanilla with bfs 302

---
whoever mentioned a drm problem - i pulled latest drm-next and nouveau again - so try

and whoever wanted reiser4 too, that's there

*edit*
zen-stable.git totally updated:
- Changed zen-sched a bit for individual sched files, not to unify them
- reiser4 updated
- aufs updated
- drm and nouveau updatd
- 2.6.31.2
- 2.6.30 coming momentarily?

Vanilla (vanilla-sources-2.6.31.1) with BFS-302 works perfectly with suspend and hibernate. Zen-stable (with BFS-302) does not.

Moreover, the latest drm updates have resulted in my kms powered console being invisible. (Intel 945 GM).

In case (in the hope) it helps, here are my configs for vanilla and zen respectively.

http://pastebin.com/m17179dd6

http://pastebin.com/m24b2bf1e

Good night everyone!

Will fix bfs,
and on top of that will also take a look at drm (it's drm-next - must be problem)

*edit*
bfs fixed, accomplished by reverting 2.6.32 everything, except tweaks --- 2.6.32 scheduler wanters and use zen.git now
drm possibly fixed
*edit2*
Forgot to mention, BFS is now selected to be the default CPU scheduler in zen

[ponciarello]

curiosity is killing me ( ) so, after having tried bfs303 with zen-stable (all ok), I tried new zenunstable

Code: Select all

  CC      drivers/usb/host/ehci-hcd.o
drivers/usb/host/ehci-hcd.c: In function 'ehci_reset':
drivers/usb/host/ehci-hcd.c:245: error: implicit declaration of function 'dbgp_reset_prep'
drivers/usb/host/ehci-hcd.c:257: error: 'USBMODE_EX_HC' undeclared (first use in this function)
drivers/usb/host/ehci-hcd.c:257: error: (Each undeclared identifier is reported only once
drivers/usb/host/ehci-hcd.c:257: error: for each function it appears in.)
drivers/usb/host/ehci-hcd.c:257: error: 'USBMODE_EX_VBPS' undeclared (first use in this function)
drivers/usb/host/ehci-hcd.c:258: error: 'USBMODE_EX' undeclared (first use in this function)
drivers/usb/host/ehci-hcd.c:259: error: 'TXFIFO_DEFAULT' undeclared (first use in this function)
drivers/usb/host/ehci-hcd.c:260: error: 'TXFILLTUNING' undeclared (first use in this function)
drivers/usb/host/ehci-hcd.c:269: error: implicit declaration of function 'dbgp_external_startup'
In file included from drivers/usb/host/ehci-hcd.c:306:
drivers/usb/host/ehci-hub.c: In function 'ehci_bus_suspend':
drivers/usb/host/ehci-hub.c:148: error: 'HOSTPC0' undeclared (first use in this function)
drivers/usb/host/ehci-hub.c:183: error: 'HOSTPC_PHCD' undeclared (first use in this function)
drivers/usb/host/ehci-hub.c: In function 'ehci_hub_control':
drivers/usb/host/ehci-hub.c:619: error: 'HOSTPC0' undeclared (first use in this function)
drivers/usb/host/ehci-hub.c:901: error: 'HOSTPC_PHCD' undeclared (first use in this function)
make[3]: *** [drivers/usb/host/ehci-hcd.o] Error 1
make[2]: *** [drivers/usb/host] Error 2
make[1]: *** [drivers/usb] Error 2
make: *** [drivers] Error 2

you probably know of it already (just reporting )

[manwithaplan1976]

I've been following the Zen Sources for couple of month's now ... And I just want so say thanks for such a great contribution... Zen stable ... has been working great with BFS on my Core2.
On earlier releases I had some issue's with reboot's and shutdowns & BFS instability. Since the recent git pull and a rebuild... Its stable, and is a pleasure tweaking to my hearts content.

I noticed on gitweb that the zen-overlay is missing, and from a recent layman -S ...? Am I assuming their will be no more zen-overlay with ebuilds..?

[rahulthewall]

Suspend and hibernate are still broken with bfs-300.

shouldnt be, try vanilla with bfs 302

---
whoever mentioned a drm problem - i pulled latest drm-next and nouveau again - so try

and whoever wanted reiser4 too, that's there

*edit*
zen-stable.git totally updated:
- Changed zen-sched a bit for individual sched files, not to unify them
- reiser4 updated
- aufs updated
- drm and nouveau updatd
- 2.6.31.2
- 2.6.30 coming momentarily?

Vanilla (vanilla-sources-2.6.31.1) with BFS-302 works perfectly with suspend and hibernate. Zen-stable (with BFS-302) does not.

Moreover, the latest drm updates have resulted in my kms powered console being invisible. (Intel 945 GM).

In case (in the hope) it helps, here are my configs for vanilla and zen respectively.

http://pastebin.com/m17179dd6

http://pastebin.com/m24b2bf1e

Good night everyone!

Will fix bfs,
and on top of that will also take a look at drm (it's drm-next - must be problem)

*edit*
bfs fixed, accomplished by reverting 2.6.32 everything, except tweaks --- 2.6.32 scheduler wanters and use zen.git now
drm possibly fixed
*edit2*
Forgot to mention, BFS is now selected to be the default CPU scheduler in zen

Good morning!

Everything fixed. Thanks a lot.

Cheers
Rahul

[dodo1122]

I've been following the Zen Sources for couple of month's now ... And I just want so say thanks for such a great contribution... Zen stable ... has been working great with BFS on my Core2.
On earlier releases I had some issue's with reboot's and shutdowns & BFS instability. Since the recent git pull and a rebuild... Its stable, and is a pleasure tweaking to my hearts content.

I noticed on gitweb that the zen-overlay is missing, and from a recent layman -S ...? Am I assuming their will be no more zen-overlay with ebuilds..?

Yes, there will be no more zen-overlay since its not needed. Patches for stable releases will still be uploaded to the website however. If someone wants to maintain ebuilds in their overlay that's perfectly fine, it's just that we don't see a point anymore, a package manager should not have anything to do with the kernel, especially since it only unpacks the sources.

dodo

[yoshi314]

hmm, current zen-stable git (5692deda2c65ef19b303c96c8524dcacb310bc70) locks up when luks is about to open my partition. no message on screen, no kernel panic.

strange. fortunately i have -zen1 as a fallback, which is surprisingly stable (for me).

does anyone else have similar behavior?