Official thread: "zen-sources" - Part 7

Message

razum2um · Post by **razum2um** » Sat Sep 12, 2009 5:07 am

Waninkoko wrote:In kernel/pid.c
after the function "find_task_by_vpid", add this line:
Code: Select all
EXPORT_SYMBOL(find_task_by_vpid);
Recompile the kernel (fglrx not needed) and it should work fine.

Ooops! Perhaps I'm really stupid

It's clear, when you see diff-listing attentively. Also, fglrx works.

But my "best" problem with git-master is the same as is already described: it boots from time to time.
Could be, that sometimes during 1,4 sec (booting to init time) it can't initialize my raid0 (/, ext4)?
(no diffeence is there in kernel line raid=autodetect or not)
---
amd64, bfs, bfq

Rion · Post by **Rion** » Sat Sep 12, 2009 5:17 am

hehe just tried to do emerge -pv netbeans with enabled bfs on amd64
...
switched back to cfs

ponciarello · Post by **ponciarello** » Sat Sep 12, 2009 5:40 am

writing from just-pulled smooth master-testing

welcome back dodo

P.S. not very important for me but compcache looks broken (it's a while it's in this state I think), it creates a device of size 0k (and it accept no parameters), reported if anyone has the same problem

kernelOfTruth · Post by **kernelOfTruth** » Sat Sep 12, 2009 7:53 am

darklegion wrote:
kernelOfTruth wrote:anyone tried it on top of plain vanilla 2.6.31 ?

from what I read Con's system is amd64 so it at least should work for some of us
No, doesn't work for me with vanilla 2.6.31.One thing I did notice, is that after making a fresh .config where I accidentally left out the correct options for my hard drives, is that it booted properly, at least as far as it would go without a root drive.Perhaps the bug is some interaction between the ATA subsystem and BFS?

try the following and please report back:

remove

Code: Select all

fastboot

from your grub.conf/menu.lst and add

Code: Select all

scsi_mod.scan=sync

aTan · Post by **aTan** » Sat Sep 12, 2009 11:56 am

bfs211-test3
i've installed and booted basic x86 Gentoo and it works fine. tested with emerge --sync.
in my main ~amd64 installation it as always creates a stucked rsync process with emerge --sync.

it really sucks, why is amd64 broken??!!

hallabro · Post by **hallabro** » Sat Sep 12, 2009 12:32 pm

Running bfs211 myself, haven't had any issue so far since release. Works great.

cheater1034 · Post by **cheater1034** » Sun Sep 13, 2009 12:42 am

Ok guys, a lesson in how we're doing things now with git!
branch information:
master: master is unstable/messy/follows linus' git tree
master-2.6.xy: STABLE branches for STABLE versions

I bring this up, because 2.6.31 was just released, and master-2.6.31 and master are NOT the same thing (master is sloppy and not nice and cleaned up to be stable) - tbh master probably wont get touched until 2.6.32-rc1

so if you want 2.6.31 zen, you need to checkout the 2.6.31 branch (Same applies if you wanted 2.6.30 zen, etc - and this will apply for all future kernels)
git checkout origin/master-2.6.31 (checkout to the remote)
git checkout -b master-2.6.xy origin/master-2.6.xy (checkout a local branch named master-2.6.xy based on origin/master-2.6.xy)
git checkout master (return to master)

you can still update the same when operating on a stable branch, such as master-2.6.31 (git pull or git pull origin master-2.6.31)

just to let you know the changes, again: master =/= master-2.6.31, master-2.6.30, etc
so if you are running master, you are running unstable following linus tree (although it will halt following linus' tree until 2.6.32-rc1), and currently msater-2.6.31 is totally different from master.

Had to emphasize this because we're just starting doing it like this.

whats the difference btw: master-2.6.31 is clean (confirmed to fix zen-caused boot failures in master - on AMD atleast - not bfs caused boot failures)

darklegion · Post by **darklegion** » Sun Sep 13, 2009 6:21 am

kernelOfTruth wrote:
darklegion wrote:
kernelOfTruth wrote:anyone tried it on top of plain vanilla 2.6.31 ?

from what I read Con's system is amd64 so it at least should work for some of us
No, doesn't work for me with vanilla 2.6.31.One thing I did notice, is that after making a fresh .config where I accidentally left out the correct options for my hard drives, is that it booted properly, at least as far as it would go without a root drive.Perhaps the bug is some interaction between the ATA subsystem and BFS?
try the following and please report back:

remove
Code: Select all
fastboot
from your grub.conf/menu.lst and add
Code: Select all
scsi_mod.scan=sync

Yeah, I tried this, and managed to get it to boot once with no issues.But then I tried again, and haven't been able to get it to boot since, so I think it was just dumb luck.
I also disabled the option in the kernel, as I don't compile my ATA/SCSI drivers as modules, and I don't think that option applies when they are built into the kernel.

DigitalCorpus · Post by **DigitalCorpus** » Sun Sep 13, 2009 8:21 am

cheater1034 wrote:...I bring this up, because 2.6.31 was just released, and master-2.6.31 and master are NOT the same thing (master is sloppy and not nice and cleaned up to be stable) - tbh master probably wont get touched until 2.6.32-rc1

so if you want 2.6.31 zen, you need to checkout the 2.6.31 branch (Same applies if you wanted 2.6.30 zen, etc - and this will apply for all future kernels)
git checkout origin/master-2.6.31 (checkout to the remote)
git checkout -b master-2.6.xy origin/master-2.6.xy (checkout a local branch named master-2.6.xy based on origin/master-2.6.xy)
git checkout master (return to master)

you can still update the same when operating on a stable branch, such as master-2.6.31 (git pull or git pull origin master-2.6.31)...

So being new to git, how does this differ from the instructions on the front page about cloning the zen-sources to get started?

ponciarello · Post by **ponciarello** » Sun Sep 13, 2009 9:19 am

by nothing I think, cheater was simply specifiing which branch to get if you want to checkout a specific release (2.6.31, 2.6.30 and so on) updated with zen stuff.
by default master branch is checked out.
they also release ready-to-apply patches on the site. (or you can create them with git)

cheater1034 · Post by **cheater1034** » Sun Sep 13, 2009 3:40 pm

http://zen-sources.org/content/master-c ... -using-git

cheater1034 · Post by **cheater1034** » Sun Sep 13, 2009 10:01 pm

2.6.30-zen5 released:
http://zen-sources.org/content/zen-sources-2630-zen5

includes 2.6.30.6, bfs 220 backported, and reverted ps3 (caused boot hangs on some systems non-ppc and non-ps3)

if you're still using 2.6.30 i haven't forgotten about you

and bfq is FAST guys, try it and report your results compared to cfq! (what i've seen and heard on IRC it's a significant improvement in many aspects and under many loads)

dodo1122 · Post by **dodo1122** » Sun Sep 13, 2009 10:47 pm

2.6.31-zen1 released

i'll add an ebuilds for 2.6.30-zen5 and 2.6.31-zen1 tomorrow.

mantoo · Post by **mantoo** » Sun Sep 13, 2009 10:55 pm

mmh, very nice, thank you!

btw i had probswith 2.6.30-zen4 and my portage-image being mounted using aufs, as it resulted in completly hanging and locking up my box!
luckily i found unionfs back in zen, which was gone some releases ago what made me to switch to aufs. as im kinda busy i did not have the time to study aufs-docs, but what i didn´t like was that my squash_portage-script always, even if no changes were made to my portage tree due to eix-sync, recompressed my/usr/portage.
unionfs only behaves like that when shutting down my box if changes were made.
maybe someone has any tips to make aufs more cooperative?

thanks!
mantoo

kernelOfTruth · Post by **kernelOfTruth** » Sun Sep 13, 2009 11:06 pm

dodo1122 wrote:2.6.31-zen1 released
i'll add an ebuilds for 2.6.30-zen5 and 2.6.31-zen1 tomorrow.

Hi dodo !

does 2.6.31-zen1 also include bfs 220 ?

Thanks for that version bump

ponciarello · Post by **ponciarello** » Mon Sep 14, 2009 7:13 am

looking at git I think yes, kot

tnx for backporting bfs220 to 2.6.30, much appreciated

P.S. my dell work pc (optiplex 960) resets just after loading kernel with latest git (2.6.31 patch is ok), dunno if because of new bfs or new drm commits on master-2.6.31.

MageSlayer · Post by **MageSlayer** » Mon Sep 14, 2009 4:45 pm

Rsyncing portage tree still hangs under bfs on Intel Core2.
Tested under vanilla 2.6.31 + manual 221 bfs patch.

Is there any workaround known?

BTW, are those tags in git like v2.6.31, v2.6.30.6 are from Linus tree?

kernelOfTruth · Post by **kernelOfTruth** » Mon Sep 14, 2009 5:18 pm

MageSlayer wrote:Rsyncing portage tree still hangs under bfs on Intel Core2.
Tested under vanilla 2.6.31 + manual 221 bfs patch.

Is there any workaround known?

BTW, are those tags in git like v2.6.31, v2.6.30.6 are from Linus tree?

working fine here with 2.6.31-zen1

BFS is rockstable so far (running for several hours, only KMS + radeon have crashed X once --> qt3-based app, guarddog)

I'm currently syncing my portage-tree and it's still up so far

a workaround would be to sync your tree and all of your overlays via paludis (paludis -s)

yeah, those should be the tags from Linus' tree

MageSlayer · Post by **MageSlayer** » Mon Sep 14, 2009 5:40 pm

kernelOfTruth wrote: working fine here with 2.6.31-zen1

BFS is rockstable so far (running for several hours, only KMS + radeon have crashed X once --> qt3-based app, guarddog)

I'm currently syncing my portage-tree and it's still up so far

a workaround would be to sync your tree and all of your overlays via paludis (paludis -s)

Sorry, I didn't get it - what is the difference of syncing via paludis or without it? I'm using paludis also, but AFAIK it uses rsync to do the job.

kernelOfTruth wrote: yeah, those should be the tags from Linus' tree

Ok, thanks.

aTan · Post by **aTan** » Mon Sep 14, 2009 5:52 pm

But no one tells which HW does he use. It works for me on x86 but doesn't on amd64. Have tried on the same HW.

kernelOfTruth · Post by **kernelOfTruth** » Mon Sep 14, 2009 6:07 pm

MageSlayer wrote: Sorry, I didn't get it - what is the difference of syncing via paludis or without it? I'm using paludis also, but AFAIK it uses rsync to do the job.

I dunno,

sometimes bugs get triggered by python, etc. so it could have been related to portage explicitly instead of heavy I/O (rsync)

aTan wrote:But no one tells which HW does he use. It works for me on x86 but doesn't on amd64. Have tried on the same HW.

lspci
00:00.0 Host bridge: Intel Corporation 82975X Memory Controller Hub (rev c0)
00:01.0 PCI bridge: Intel Corporation 82975X PCI Express Root Port (rev c0)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01)
00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 6 (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01)
00:1f.2 SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) SATA AHCI Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)
01:03.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)
02:00.0 SATA controller: JMicron Technology Corp. 20360/20363 Serial ATA Controller (rev 02)
02:00.1 IDE interface: JMicron Technology Corp. 20360/20363 Serial ATA Controller (rev 02)
03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 20)
05:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4850]
05:00.1 Audio device: ATI Technologies Inc HD48x0 audio

P5W DH Deluxe, 8 GB DDR2, Intel Core 2 Duo E6600

Portage 2.2_rc40 (default/linux/amd64/2008.0, gcc-4.4.1, glibc-2.10.1-r0, 2.6.31-zen1_bfs x86_64)
=================================================================
System uname: Linux-2.6.31-zen1_bfs-x86_64-Intel-R-_Core-TM-2_CPU_6600_@_2.40GHz-with-gentoo-2.0.1
Timestamp of tree: Mon, 14 Sep 2009 16:45:03 +0000
app-shells/bash: 3.2_p48-r1
dev-java/java-config: 1.3.7-r1, 2.1.9
dev-lang/python: 2.5.4-r3, 2.6.2-r1, 3.1.1
dev-python/pycrypto: 2.0.1-r8
dev-util/cmake: 2.6.4-r2
sys-apps/baselayout: 2.0.1
sys-apps/openrc: 0.4.3-r5
sys-apps/sandbox: 2.1
sys-devel/autoconf: 2.13, 2.63-r1
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2, 1.11
sys-devel/binutils: 2.19.51.0.10, 2.19.51.0.11, 2.19.51.0.13, 2.19.51.0.14, 2.20.51.0.1
sys-devel/gcc-config: 1.4.1
sys-devel/libtool: 2.2.6a
virtual/os-headers: 2.6.30-r1
ACCEPT_KEYWORDS="amd64 ~amd64"

Is that enough information ?

ponciarello · Post by **ponciarello** » Mon Sep 14, 2009 6:25 pm

you forgot to tell him about your hardcore compiler flags

( if I remember well

)

tranquilcool · Post by **tranquilcool** » Mon Sep 14, 2009 6:49 pm

bfs boots sometimes and hald fails too very often.
2.6.31-zen1 and 2.6.30-zen5.

pappy_mcfae · Post by **pappy_mcfae** » Mon Sep 14, 2009 8:02 pm

Still no stability for core-too with 2.6.31-zen1. This machine, of course, loves it.

Blessed be!
Pappy

MageSlayer · Post by **MageSlayer** » Mon Sep 14, 2009 8:31 pm

kernelOfTruth

Well. Quite enough

.

I've chatted a bit with guys on #ck. They tell (& Con's FAQ tells the same) that reiserfs3.6 has poor implementation, so it hangs on bfs. I'm going to convert my /var partition to ext4 and watch how rsync going.