Official thread: "zen-sources" - Part 7

Message

Ant P. · Post by **Ant P.** » Mon Aug 31, 2009 10:52 am

You need to turn off Performance Counters. BFS doesn't seem to like them.

Ant P. · Post by **Ant P.** » Mon Aug 31, 2009 2:36 pm

Also I can say -rc8 works with my wifi again, though it took a bit of poking to get it to work at all.

Kernel wouldn't build with CPU=Atom, had to use Core2 + march=native instead. hostapd wouldn't run with wireless extensions disabled, boot hangs before init if I enable wext (no error messages, it just goes to sleep), it only works if I enable config_wireless_ext_sysfs too.

rahulthewall · Post by **rahulthewall** » Mon Aug 31, 2009 2:57 pm

Ant_P wrote:You need to turn off Performance Counters. BFS doesn't seem to like them.

Yup, that fixed it. Though I still have a couple of section mismatches. Any idea on how to fix them?

Code: Select all

WARNING: vmlinux.o(.text+0x20e5b3): Section mismatch in reference from the function pcibios_scan_specific_bus() to the function .devinit.text:pci_scan_bus_on_node()                                                                
The function pcibios_scan_specific_bus() references                                                               
the function __devinit pci_scan_bus_on_node().                                                                    
This is often because pcibios_scan_specific_bus lacks a __devinit                                                 
annotation or the annotation of pci_scan_bus_on_node is wrong.                                                    

WARNING: vmlinux.o(__ksymtab_gpl+0x23d8): Section mismatch in reference from the variable __ksymtab_pci_legacy_init to the function .init.text:pci_legacy_init()                                                                    
The symbol pci_legacy_init is exported and annotated __init                                                       
Fix this by removing the __init annotation of pci_legacy_init or drop the export.

Ant P. · Post by **Ant P.** » Mon Aug 31, 2009 3:09 pm

I get the section mismatch warning too, but it seems to be harmless.

tranquilcool · Post by **tranquilcool** » Mon Aug 31, 2009 4:57 pm

everything is working great here after last pull.
great job! thanks.

kernelOfTruth · Post by **kernelOfTruth** » Mon Aug 31, 2009 6:44 pm

tranquilcool wrote:everything is working great here after last pull.
great job! thanks.

with or without bfs ?

anyone else experiencing this ?

I manually patched my kernel with BFS 201 and have the following problem:

* it boots <-- OK !
* it emerges ati-drivers and virtualbox-module <- OK!
* X, metacity and other stuff launch up <- OK!
* compiz / compositing launches <- ok!
* first terminal in X launches <- ok!

after a short while
* when trying to kill any apps (from the root-account via the terminal) they end up as D (daemon) in the background and seem to prevent everything else new to be opened/started

afaik no app can be killed / removed (only from within X ?) also no additional apps can be started anymore

it seems like if the kernel or the scheduler gets saturated in some kind of way

therefore I couldn't do any further testing

hope this is kind of reproducible and will be fixed soon ...

(I'm sorry but I currently hardly can sacrifice any time for further testing / fixing, etc.)

Ant P. · Post by **Ant P.** » Mon Aug 31, 2009 7:58 pm

My desktop and server box are both working OK on BFS now, but my laptop (eee701, running Debian sid) hasn't come out so well.

The display gets horribly messed up, and what's worse it's still doing it after going back to the old kernel. Maybe I fried it with that compile

cheater1034 · Post by **cheater1034** » Tue Sep 01, 2009 12:17 am

1) performance counters aren't implemented in bfs yet, disable them
2) Do NOT report a bfs problem to con if you are using zen
3) If you are having a problem with BFS - enable debugging options in your kernel, checkout v2.6.30, apply the latest bfs patch from ck.kolivas.org/patches/bfs - then if you still experience it, report it to con (the hint is, don't report it if you are using zen)
4) Determine if it is an actual bfs problem ^^ or a problem with one of the zen patches and bfs - if it's an actual bfs problem, report it to con - otherwise report it to me

Ant P. · Post by **Ant P.** » Tue Sep 01, 2009 2:28 am

I tried to schedtool -D something and got an instant lockup on -rc8 (sysrq wouldn't work). I don't have time to go testing things right now, but has anyone else got it to work or am I only wasting my time trying?

tranquilcool · Post by **tranquilcool** » Tue Sep 01, 2009 6:10 am

kernelOfTruth wrote:
tranquilcool wrote:everything is working great here after last pull.
great job! thanks.
with or without bfs ?

anyone else experiencing this ?

I manually patched my kernel with BFS 201 and have the following problem:

* it boots <-- OK !
* it emerges ati-drivers and virtualbox-module <- OK!
* X, metacity and other stuff launch up <- OK!
* compiz / compositing launches <- ok!
* first terminal in X launches <- ok!

after a short while
* when trying to kill any apps (from the root-account via the terminal) they end up as D (daemon) in the background and seem to prevent everything else new to be opened/started

afaik no app can be killed / removed (only from within X ?) also no additional apps can be started anymore

it seems like if the kernel or the scheduler gets saturated in some kind of way

therefore I couldn't do any further testing

hope this is kind of reproducible and will be fixed soon ...

(I'm sorry but I currently hardly can sacrifice any time for further testing / fixing, etc.)

with bfs.
enabled the sched-iso for X and my video card is now working.
i launched amarok with the schedtool and it seems to fly.

xmixahlx · Post by **xmixahlx** » Tue Sep 01, 2009 7:10 pm

kernelOfTruth wrote:
tranquilcool wrote:everything is working great here after last pull.
great job! thanks.
with or without bfs ?

anyone else experiencing this ?

I manually patched my kernel with BFS 201 and have the following problem:

* it boots <-- OK !
* it emerges ati-drivers and virtualbox-module <- OK!
* X, metacity and other stuff launch up <- OK!
* compiz / compositing launches <- ok!
* first terminal in X launches <- ok!

after a short while
* when trying to kill any apps (from the root-account via the terminal) they end up as D (daemon) in the background and seem to prevent everything else new to be opened/started

afaik no app can be killed / removed (only from within X ?) also no additional apps can be started anymore

it seems like if the kernel or the scheduler gets saturated in some kind of way

therefore I couldn't do any further testing

hope this is kind of reproducible and will be fixed soon ...

(I'm sorry but I currently hardly can sacrifice any time for further testing / fixing, etc.)

i had the same lockup issue with master-2.6.30 (zen5) yesterday with bfs.

pappy_mcfae · Post by **pappy_mcfae** » Tue Sep 01, 2009 7:59 pm

At last, I figured out how to get BFS. I have yet to see a real woohoo, but then again, I haven't really tried anything to see what all the fuss is about. I did try it with the fireworkx openGL screensaver, and I could crank all the options up, and it didn't falter. I did get the same sort of results with 2.6.29-zen2 after I zen-tuned everything to 1. So, I'm going to be playing around to see what BFS can do for me.

Blessed be!
Pappy

cheater1034 · Post by **cheater1034** » Tue Sep 01, 2009 9:02 pm

bfs patch isnt made for .31-rc8, so if you are getting problems there i suggest you try 2.6.30 git tree

And in all cases, bfs should be more snappy on a desktop and it should compile faster

pappy_mcfae · Post by **pappy_mcfae** » Wed Sep 02, 2009 4:46 am

That's what it says it is when I do make defconfig. It started out as 2.6.30, and a patch I made with the following statement:

Code: Select all

git diff v2.6.30 origin/zen-sched > 2.6.30-bfs.patch

.

That was the only way I could get any BFS patch to work. All of the patches discussed and linked, either the links stopped working, or the patches at the end of it all were destined to not work, as in failing chunks, etc.

If I'm supposed to use some other repository, I'd like to know. If not, can you suggest a working patch...as in one that will take 2.6.30 and give it BFS...without bombing, without failing?

Blessed be!
Pappy

kernelOfTruth · Post by **kernelOfTruth** » Wed Sep 02, 2009 3:04 pm

cheater1034 wrote:1) performance counters aren't implemented in bfs yet, disable them
2) Do NOT report a bfs problem to con if you are using zen
3) If you are having a problem with BFS - enable debugging options in your kernel, checkout v2.6.30, apply the latest bfs patch from ck.kolivas.org/patches/bfs - then if you still experience it, report it to con (the hint is, don't report it if you are using zen)
4) Determine if it is an actual bfs problem ^^ or a problem with one of the zen patches and bfs - if it's an actual bfs problem, report it to con - otherwise report it to me

sure,

BUT right now BFS is working great with latest master-2.6.30 so no complaints at the moment

thanks !

edit:

damn ! it's still going bonkers after longer time and work loads (several minutes to hours)

resulting in:

[ 4560.726265] okular D ffff88023f861700 3912 28134 1
[ 4560.726270] ffff880141585c28 0000000000000082 0000000000000000 ffff8801a581e9c0
[ 4560.726276] 000000000000d940 ffff8801a581e7c8 000000000000d940 000000000000d940
[ 4560.726280] 000000000000d940 0000000100100100 000000000000d940 ffff8801a581e9c0
[ 4560.726285] Call Trace:
[ 4560.726294] [<ffffffff802bbe62>] ? __d_lookup+0xa2/0x140
[ 4560.726301] [<ffffffff8086cd22>] __mutex_lock_slowpath+0xe2/0x170
[ 4560.726305] [<ffffffff802bbe62>] ? __d_lookup+0xa2/0x140
[ 4560.726309] [<ffffffff8086ca26>] mutex_lock+0x26/0x50
[ 4560.726312] [<ffffffff802b36e3>] do_lookup+0xd3/0x240
[ 4560.726316] [<ffffffff802b456c>] __link_path_walk+0x84c/0xeb0
[ 4560.726321] [<ffffffff8027b29b>] ? filemap_fault+0x12b/0x3f0
[ 4560.726325] [<ffffffff802b4d97>] path_walk+0x57/0xb0
[ 4560.726328] [<ffffffff802b4eb8>] do_path_lookup+0x78/0x170
[ 4560.726332] [<ffffffff802b2ec6>] ? getname+0x1a6/0x210
[ 4560.726336] [<ffffffff802b5bf2>] user_path_at+0x52/0xa0
[ 4560.726341] [<ffffffff804ce6d1>] ? security_prepare_creds+0x11/0x20
[ 4560.726345] [<ffffffff802a8250>] sys_faccessat+0xd0/0x1d0
[ 4560.726349] [<ffffffff802a8363>] sys_access+0x13/0x20
[ 4560.726353] [<ffffffff8020b56b>] system_call_fastpath+0x16/0x1b
[ 4560.726357] INFO: task dolphin:28164 blocked for more than 120 seconds.
[ 4560.726359] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 4560.726361] dolphin D ffff88023f861700 4168 28164 1
[ 4560.726366] ffff88013c0d1c28 0000000000000086 0000000000001f1f ffff880154c03040
[ 4560.726370] 000000000000d940 ffff880154c02e48 000000000000d940 000000000000d940
[ 4560.726375] 000000000000d940 0000000180209fc5 000000000000d940 ffff880154c03040
[ 4560.726379] Call Trace:
[ 4560.726383] [<ffffffff802bbe62>] ? __d_lookup+0xa2/0x140
[ 4560.726387] [<ffffffff8086cd22>] __mutex_lock_slowpath+0xe2/0x170
[ 4560.726391] [<ffffffff802bbe62>] ? __d_lookup+0xa2/0x140
[ 4560.726395] [<ffffffff8086ca26>] mutex_lock+0x26/0x50
[ 4560.726398] [<ffffffff802b36e3>] do_lookup+0xd3/0x240
[ 4560.726402] [<ffffffff802b456c>] __link_path_walk+0x84c/0xeb0
[ 4560.726406] [<ffffffff8027b29b>] ? filemap_fault+0x12b/0x3f0
[ 4560.726410] [<ffffffff802b4d97>] path_walk+0x57/0xb0
[ 4560.726413] [<ffffffff802b4eb8>] do_path_lookup+0x78/0x170
[ 4560.726417] [<ffffffff802b2ec6>] ? getname+0x1a6/0x210
[ 4560.726421] [<ffffffff802b5bf2>] user_path_at+0x52/0xa0
[ 4560.726424] [<ffffffff804ce6d1>] ? security_prepare_creds+0x11/0x20
[ 4560.726428] [<ffffffff802a8250>] sys_faccessat+0xd0/0x1d0
[ 4560.726432] [<ffffffff802a8363>] sys_access+0x13/0x20
[ 4560.726435] [<ffffffff8020b56b>] system_call_fastpath+0x16/0x1b
[ 4680.726263] INFO: task okular:28134 blocked for more than 120 seconds.
[ 4680.726266] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 4680.726269] okular D ffff88023f861700 3912 28134 1
[ 4680.726275] ffff880141585c28 0000000000000082 0000000000000000 ffff8801a581e9c0
[ 4680.726281] 000000000000d940 ffff8801a581e7c8 000000000000d940 000000000000d940
[ 4680.726285] 000000000000d940 0000000100100100 000000000000d940 ffff8801a581e9c0
[ 4680.726290] Call Trace:
[ 4680.726300] [<ffffffff802bbe62>] ? __d_lookup+0xa2/0x140
[ 4680.726306] [<ffffffff8086cd22>] __mutex_lock_slowpath+0xe2/0x170
[ 4680.726310] [<ffffffff802bbe62>] ? __d_lookup+0xa2/0x140
[ 4680.726314] [<ffffffff8086ca26>] mutex_lock+0x26/0x50
[ 4680.726318] [<ffffffff802b36e3>] do_lookup+0xd3/0x240
[ 4680.726322] [<ffffffff802b456c>] __link_path_walk+0x84c/0xeb0
[ 4680.726327] [<ffffffff8027b29b>] ? filemap_fault+0x12b/0x3f0
[ 4680.726330] [<ffffffff802b4d97>] path_walk+0x57/0xb0
[ 4680.726334] [<ffffffff802b4eb8>] do_path_lookup+0x78/0x170
[ 4680.726338] [<ffffffff802b2ec6>] ? getname+0x1a6/0x210
[ 4680.726341] [<ffffffff802b5bf2>] user_path_at+0x52/0xa0
[ 4680.726346] [<ffffffff804ce6d1>] ? security_prepare_creds+0x11/0x20
[ 4680.726351] [<ffffffff802a8250>] sys_faccessat+0xd0/0x1d0
[ 4680.726354] [<ffffffff802a8363>] sys_access+0x13/0x20
[ 4680.726359] [<ffffffff8020b56b>] system_call_fastpath+0x16/0x1b
[ 4680.726362] INFO: task dolphin:28164 blocked for more than 120 seconds.
[ 4680.726365] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 4680.726367] dolphin D ffff88023f861700 4168 28164 1
[ 4680.726372] ffff88013c0d1c28 0000000000000086 0000000000001f1f ffff880154c03040
[ 4680.726376] 000000000000d940 ffff880154c02e48 000000000000d940 000000000000d940
[ 4680.726380] 000000000000d940 0000000180209fc5 000000000000d940 ffff880154c03040
[ 4680.726385] Call Trace:
[ 4680.726389] [<ffffffff802bbe62>] ? __d_lookup+0xa2/0x140
[ 4680.726393] [<ffffffff8086cd22>] __mutex_lock_slowpath+0xe2/0x170
[ 4680.726397] [<ffffffff802bbe62>] ? __d_lookup+0xa2/0x140
[ 4680.726401] [<ffffffff8086ca26>] mutex_lock+0x26/0x50
[ 4680.726404] [<ffffffff802b36e3>] do_lookup+0xd3/0x240
[ 4680.726408] [<ffffffff802b456c>] __link_path_walk+0x84c/0xeb0
[ 4680.726412] [<ffffffff8027b29b>] ? filemap_fault+0x12b/0x3f0
[ 4680.726416] [<ffffffff802b4d97>] path_walk+0x57/0xb0
[ 4680.726420] [<ffffffff802b4eb8>] do_path_lookup+0x78/0x170
[ 4680.726423] [<ffffffff802b2ec6>] ? getname+0x1a6/0x210
[ 4680.726427] [<ffffffff802b5bf2>] user_path_at+0x52/0xa0
[ 4680.726431] [<ffffffff804ce6d1>] ? security_prepare_creds+0x11/0x20
[ 4680.726434] [<ffffffff802a8250>] sys_faccessat+0xd0/0x1d0
[ 4680.726438] [<ffffffff802a8363>] sys_access+0x13/0x20
[ 4680.726442] [<ffffffff8020b56b>] system_call_fastpath+0x16/0x1b

it seems to get triggered pretty fast when starting rsync or heavy cpu-load jobs

ps uax | grep rsync
root 28083 0.0 0.0 23472 1572 pts/0 R+ 17:25 0:00 rsync -aq --delete /home/user/data /bak/user/data
root 28084 0.0 0.0 0 0 pts/0 Z+ 17:25 0:00 [rsync] <defunct>
root 28188 0.0 0.0 6240 668 pts/1 S+ 17:29 0:00 grep --color=auto rsync

so the same problem like posted above isn't fixed yet, it has greatly been improved and postponed but not fixed yet ...

I'm wondering if BFS is revealing yet another BUG in the kernel

cheater1034 · Post by **cheater1034** » Wed Sep 02, 2009 8:02 pm

pappy_mcfae wrote:That's what it says it is when I do make defconfig. It started out as 2.6.30, and a patch I made with the following statement:
Code: Select all
git diff v2.6.30 origin/zen-sched > 2.6.30-bfs.patch
.

That isn't right, because if you run that diff command you are not just patching 2.6.30 with bfs, but you are also patching it with all of 2.6.31-rc8 since the zen-sched branch is based on 2.6.31-rc8

That was the only way I could get any BFS patch to work. All of the patches discussed and linked, either the links stopped working, or the patches at the end of it all were destined to not work, as in failing chunks, etc.

If I'm supposed to use some other repository, I'd like to know. If not, can you suggest a working patch...as in one that will take 2.6.30 and give it BFS...without bombing, without failing?

Blessed be!
Pappy

Anyway, zen-sources master and master-2.6.30 (essentially, the latest and the stable zen-sources) come equipped with cfs and bfs (cfs is default, bfs can be selected) - so you can either use zen master-2.6.30 (which has the latest bfs on 2.6.30.5), use zen master (which has the latest bfs on linus master), or use the patches that con gives at ck.kolivas.org (which are over 2.6.30).

Keep in mind!!!!!!!!!!
* If you find a bug in zen master (2.6.31-rc8-zen1) related to bfs, DO NOT REPORT IT TO CON - just us, and after you report it to us we will tell you to try the patch from ck.kolivas.org on 2.6.30 vanilla
* If you find a bug in zen master-2.6.30 (2.6.30-zen5) related to bfs, DO NOT REPORT IT TO CON - "just us, and........vanilla"
* If you want to test a bfs BUG, download the latest patch from http://ck.kolivas.org/patches/bfs/ - apply it over the kernel version it is made for (currently, 2.6.30 - NOT anything else, plain 2.6.30, NOT 2.6.30.1-2.6.30.5)

@kerneloftruth
Please pull master-2.6.30 to test bfs 203 - if it has the same problem please download the patch from http://ck.kolivas.org/patches/bfs/ and try a plain old 2.6.30 kernel and see if you exhibit the same behavior, then i will aid in you reporting it to con.

---------

and guys, please read the other stuff in the directory of bfs folder on ck's website
http://ck.kolivas.org/patches/bfs/
you fill find interesting things like this: http://ck.kolivas.org/patches/bfs/CFSvBFS202.png
which basically shows that bfs is faster at EVERY job level than cfs

including the FAQ, graphs, and tests

remember, bfs is a totally new scheduler - it isn't a port of SD, so if you find a bug: report it (just test vanilla, not zen)

pappy_mcfae · Post by **pappy_mcfae** » Thu Sep 03, 2009 7:37 am

At last! A patch that actually works. Thanks for the tip.

As for bugs, how about no-boot with x86_64? Actually, it gets to the point in the boot cycle where init is supposed to start, and it stops. The cursor remains flashing, as if the machine is waiting for something. If I attempt to reboot (ie <ctrl><alt><del>), I get a hard lock with the following:

Code: Select all

[   95.802116] sd 2:0:0:0:0: [sdb] Synchronizing SCSI cache 
[   95.809133] sd 0:0:0:0:0: [sda] Synchronizing SCSI cache

.
What other info do you/Con need?

Blessed be!
Pappy

xmixahlx · Post by **xmixahlx** » Thu Sep 03, 2009 8:37 am

just checked out master-2.6.30/zen5 bfs203 and it is ridiculously fast. all is well... for now.

tranquilcool · Post by **tranquilcool** » Thu Sep 03, 2009 9:10 am

xmixahlx wrote:just checked out master-2.6.30/zen5 bfs203 and it is ridiculously fast. all is well... for now.

git command to check that out?
don't know how to handle git. thanks!

ponciarello · Post by **ponciarello** » Thu Sep 03, 2009 10:20 am

near the same for creating patch as few posts ago

Code: Select all

git diff v2.6.30 origin/master-2.6.30 | lzma -z -c > /tmp/2.6.30-zen.patch.lzma

tranquilcool · Post by **tranquilcool** » Thu Sep 03, 2009 3:07 pm

ponciarello wrote:near the same for creating patch as few posts ago
Code: Select all
git diff v2.6.30 origin/master-2.6.30 | lzma -z -c > /tmp/2.6.30-zen.patch.lzma

thanks.
some patch back it was working great but as by 204
/dev/video is not created with vanilla.
no /dev/sr0 and /dev/video with the zen patch.

cheater1034 · Post by **cheater1034** » Thu Sep 03, 2009 7:14 pm

pappy_mcfae wrote:At last! A patch that actually works. Thanks for the tip.

As for bugs, how about no-boot with x86_64? Actually, it gets to the point in the boot cycle where init is supposed to start, and it stops. The cursor remains flashing, as if the machine is waiting for something. If I attempt to reboot (ie <ctrl><alt><del>), I get a hard lock with the following:
Code: Select all
[   95.802116] sd 2:0:0:0:0: [sdb] Synchronizing SCSI cache 
[   95.809133] sd 0:0:0:0:0: [sda] Synchronizing SCSI cache
.
What other info do you/Con need?

Blessed be!
Pappy

It's certainly not a very common bug:
http://ck.kolivas.org/patches/bfs/2.6.3 ... -204.patch

use that patch over 2.6.30 (not 2.6.30.1-2.6.30.5) - if you get the same results let me know

I had a similar problem but couldnt get any information to help get it fixed

the problem i had was intermittent boot, sometimes it booted, sometimes it would stop before starting init

Ant P. · Post by **Ant P.** » Thu Sep 03, 2009 8:43 pm

That boot hang was exactly what I was seeing - this might be relevant...

xmixahlx · Post by **xmixahlx** » Thu Sep 03, 2009 9:47 pm

xmixahlx wrote:just checked out master-2.6.30/zen5 bfs203 and it is ridiculously fast. all is well... for now.

still running strong. will wait for bfs204 issues to sort out...

is this ideal for 2.6.30-zen5-bfs? : bfs, autoschedisoforx, preempt_rcu, preempt, no no_hrz, no numa, hrz_1000, default_cfq

cheater1034 · Post by **cheater1034** » Fri Sep 04, 2009 2:06 am

test patch for bfs 204 unreliable boot:
please test guys that have the boot problems:
http://ck.kolivas.org/patches/bfs/bfs204-test.patch