You are not logged in.

#226 2011-09-23 22:49:42

nous
Member
From: Across the Universe
Registered: 2006-08-18
Posts: 323
Website

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

kalpik wrote:

My boot status is still broken, and dmesg messages creep into it sad

If I understood correctly, then you must append the 'quiet' flag to the kernel command line in grub/lilo.

Offline

#227 2011-09-23 23:04:41

nous
Member
From: Across the Universe
Registered: 2006-08-18
Posts: 323
Website

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

kokoko3k wrote:

Thank you for precompiled packages, i've the feeling of a nice speed boost using it on an atom n280 netbook.

Anyway, it seems that powertop doesn't play good with your config:

No detailed statistics available; please enable the CONFIG_TIMER_STATS kernel option
This option is located in the Kernel Debugging section of menuconfig
(which is CONFIG_DEBUG_KERNEL=y in the config file)

Can you please enable it?

EDIT:
If you are wondering, that option has "almost zero" overhead:
http://www.mjmwired.net/kernel/Document … _stats.txt


Well, I have deliberately removed most debugging thingamajigs from config, because I felt them to be unnecessary to a  kernel that's intended to be as fast as it can. Also, I usually start anew with every major kernel release, using the stock ARCH config as a baseline, which means I've probably forgotten the exact options of my previous configuration, barring features unique to linux-pf like aufs.  That being said, I can't really recompile the repos right now but I would gladly enable TIMER_STATS for linux-pf-3.1 if you reminded me.

Offline

#228 2011-09-24 03:30:53

kalpik
Member
From: India
Registered: 2007-05-08
Posts: 163
Website

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

nous wrote:
kalpik wrote:

My boot status is still broken, and dmesg messages creep into it sad

If I understood correctly, then you must append the 'quiet' flag to the kernel command line in grub/lilo.

Adding quiet fixed it! Thanks smile

Offline

#229 2011-09-24 07:45:07

kokoko3k
Member
Registered: 2008-11-14
Posts: 2,389

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

nous wrote:

Well, I have deliberately removed most debugging thingamajigs from config, because I felt them to be unnecessary to a  kernel that's intended to be as fast as it can. Also, I usually start anew with every major kernel release, using the stock ARCH config as a baseline, which means I've probably forgotten the exact options of my previous configuration, barring features unique to linux-pf like aufs.  That being said, I can't really recompile the repos right now but I would gladly enable TIMER_STATS for linux-pf-3.1 if you reminded me.

Gotcha wink

Last edited by kokoko3k (2011-09-24 07:45:32)


Help me to improve ssh-rdp !
Retroarch User? Try my koko-aio shader !

Online

#230 2011-09-30 11:42:04

knedlyk
Member
From: L'viv, Ukraine
Registered: 2009-04-14
Posts: 163
Website

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

Hey, Christos, what happened with your repo? I tried to install a few packages, linux-pf-core2 and nvidia-pf and got message that these packages not found (but listed).

Offline

#231 2011-09-30 21:08:25

nous
Member
From: Across the Universe
Registered: 2006-08-18
Posts: 323
Website

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

knedlyk wrote:

Hey, Christos, what happened with your repo? I tried to install a few packages, linux-pf-core2 and nvidia-pf and got message that these packages not found (but listed).

Works ok from here. Which arch?
Anyway, I re-run repo-add on both arches, can you test?

Offline

#232 2011-09-30 21:23:09

knedlyk
Member
From: L'viv, Ukraine
Registered: 2009-04-14
Posts: 163
Website

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

Hi,

i686, now it works! Thanks!

Offline

#233 2011-10-15 15:39:42

choener
Member
Registered: 2008-01-10
Posts: 22

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

Hi,

I am experiencing strange problems with the precompiled versions of the kernel. If there is user I/O activity, there is a small chance of "being stuck", meaning that further I/O for the user is impossible. Say, I am copying a file, which then stalls with ever-increasing CPU load (in I/O wait). File size does not seem to matter much. I had this problems with whole genomes > 1gbyte and small files < 10 mbyte. Curiously, if I see it early enough, logging in as root (actually, /any/ commands given as root that perform I/O) resolves the problem in that the stuck I/O task continues.

I have this problem on two different computers, all 64bit and three different versions of the kernel: default, K8 and core2.

Switching from bfq to noop I/O scheduler reduces the chance of seeing this, but does not remove the problem completely. Unfortunately, there is nothing in the logs, so basically I am asking if anybody saw this, too and if there is a solution.

Viele Gruesse,
Christian

Offline

#234 2011-10-16 08:17:27

nous
Member
From: Across the Universe
Registered: 2006-08-18
Posts: 323
Website

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

choener wrote:

Hi,
I am experiencing strange problems with the precompiled versions of the kernel. If there is user I/O activity, there is a small chance of "being stuck", meaning that further I/O for the user is impossible. Say, I am copying a file, which then stalls with ever-increasing CPU load (in I/O wait). File size does not seem to matter much. I had this problems with whole genomes > 1gbyte and small files < 10 mbyte. Curiously, if I see it early enough, logging in as root (actually, /any/ commands given as root that perform I/O) resolves the problem in that the stuck I/O task continues.
I have this problem on two different computers, all 64bit and three different versions of the kernel: default, K8 and core2.
Switching from bfq to noop I/O scheduler reduces the chance of seeing this, but does not remove the problem completely. Unfortunately, there is nothing in the logs, so basically I am asking if anybody saw this, too and if there is a solution.

I haven't noticed this. All family's boxes run linux-pf (either 32 or 64bit) and use an old Pentium3-pf file server with squid, lighttpd, mysql, samba, dropboxd and transmission as a "sync point", video share and web proxy. Obviously, there's constant I/O on all sides but I haven't spotted any strange lockups.

Do you run anything unusual in the background? Any non-standard sysctl's? If not, it might very well be a BFQ bug (but no-op's also? unlikely); have you tried the well-tested CFQ?

Offline

#235 2011-10-18 17:27:38

choener
Member
Registered: 2008-01-10
Posts: 22

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

nous wrote:

I haven't noticed this. All family's boxes run linux-pf (either 32 or 64bit) and use an old Pentium3-pf file server with squid, lighttpd, mysql, samba, dropboxd and transmission as a "sync point", video share and web proxy. Obviously, there's constant I/O on all sides but I haven't spotted any strange lockups.

Do you run anything unusual in the background? Any non-standard sysctl's? If not, it might very well be a BFQ bug (but no-op's also? unlikely); have you tried the well-tested CFQ?

Hi,

no I am not running anything unusual, strangely the two machines I am having problems with have almost nothing in common except that both are 64bit. One is Intel, a notebook and handles music, vim and smallish programming while the other machine is a workstation with a lot of I/O going on. I will compile from sources, once I have the time, and see what happens.

Gruss,
Christian

Offline

#236 2011-10-22 08:20:33

lucak3
Member
From: Italy
Registered: 2010-01-23
Posts: 72

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

choener wrote:

Hi,

I am experiencing strange problems with the precompiled versions of the kernel. If there is user I/O activity, there is a small chance of "being stuck", meaning that further I/O for the user is impossible. Say, I am copying a file, which then stalls with ever-increasing CPU load (in I/O wait). File size does not seem to matter much. I had this problems with whole genomes > 1gbyte and small files < 10 mbyte. Curiously, if I see it early enough, logging in as root (actually, /any/ commands given as root that perform I/O) resolves the problem in that the stuck I/O task continues.

I have this problem on two different computers, all 64bit and three different versions of the kernel: default, K8 and core2.

Switching from bfq to noop I/O scheduler reduces the chance of seeing this, but does not remove the problem completely. Unfortunately, there is nothing in the logs, so basically I am asking if anybody saw this, too and if there is a solution.

Viele Gruesse,
Christian

It seems you're not the only one. I thought it was the fault of virtualbox module, but it continued even when i disabled that on startup. Sadly, i do not have this problem with linux from repo.
I definitely can't reproduce that at will, can't even get a log, since when it appears, most of the time the PC must be rebooted to restart working: it doesn't respond to anything, like switching to vtty or SysRq keys.


The Linux philosophy is 'laugh in the face of danger'. Oops. Wrong one. 'Do it yourself'. That's it. - Linus Torvalds

Offline

#237 2011-10-22 10:54:01

nous
Member
From: Across the Universe
Registered: 2006-08-18
Posts: 323
Website

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

lucak3 wrote:
choener wrote:

Hi,
I am experiencing strange problems with the precompiled versions of the kernel. If there is user I/O activity, there is a small chance of "being stuck", meaning that Christian

It seems you're not the only one. I thought it was the fault of virtualbox module, but it continued even when i disabled that on startup. Sadly, i do not have this problem with linux from repo.
I definitely can't reproduce that at will, can't even get a log, since when it appears, most of the time the PC must be rebooted to restart working: it doesn't respond to anything, like switching to vtty or SysRq keys.

Darn, does this still happen with 3.0.7-pf?

Offline

#238 2011-10-26 07:41:01

lucak3
Member
From: Italy
Registered: 2010-01-23
Posts: 72

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

Yes, but not if i change I/O scheduler to CFQ. It seems to me that BFQ has some starvation problems, I would recommend not using it for production until author is contacted and examines the problem.


The Linux philosophy is 'laugh in the face of danger'. Oops. Wrong one. 'Do it yourself'. That's it. - Linus Torvalds

Offline

#239 2011-10-27 17:11:58

nous
Member
From: Across the Universe
Registered: 2006-08-18
Posts: 323
Website

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

lucak3 wrote:

Yes, but not if i change I/O scheduler to CFQ. It seems to me that BFQ has some starvation problems, I would recommend not using it for production until author is contacted and examines the problem.

The first related post by coener mentioned the same problem with the no-op I/O scheduler too, albeit in a lesser degree. I'm at a loss here, mainly because I haven't been hit by the bug. I'd suggest we wait for 3.1 and if the problem persists, I'll replace BFQ by CFQ or no-op as default I/O scheduler.

Offline

#240 2011-10-27 17:23:52

post-factum
Member
From: /cz
Registered: 2008-09-12
Posts: 149
Website

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

I suggest you to try 3.1 with BFQ right now, because it has been ported by zen-kernel team.

You can grab patch here: http://pastebin.com/iwJfmPqE

BTW, I haven't faced such a bug.


uname == latest pf-kernel

Offline

#241 2011-10-27 17:44:48

post-factum
Member
From: /cz
Registered: 2008-09-12
Posts: 149
Website

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

Also, follow this: http://groups.google.com/group/bfq-iosc … 817ed579ea

BFQ developers are going to release improved version for 3.1.


uname == latest pf-kernel

Offline

#242 2011-10-28 10:27:06

lucak3
Member
From: Italy
Registered: 2010-01-23
Posts: 72

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

I suppose you're waiting for them to release that before doing 3.1.0-pf ?
I would rather build your release since i'm currently on a slow (and capped) net.
I really hope they fixed this since i do not like CFQ behaviour: sometimes (already too often) GUIs get stuck because of bad scheduling of I/O. Never had this problem with BFQ.


The Linux philosophy is 'laugh in the face of danger'. Oops. Wrong one. 'Do it yourself'. That's it. - Linus Torvalds

Offline

#243 2011-10-28 17:17:34

post-factum
Member
From: /cz
Registered: 2008-09-12
Posts: 149
Website

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

I'm waiting for all patches to be released, but if BFQ isn't released in time, I'll include abovementioned patch. So just try it.


uname == latest pf-kernel

Offline

#244 2011-10-30 11:09:04

lkraav
Member
Registered: 2011-04-08
Posts: 37

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

looking forward to 3.1.0-pf. in the meanwhile, i'm running 3.0.2-pf, does anyone happen to know why my laptop system time stops while in suspend?

i thought only PM_DEBUG and friends did that since they save their magic into RTC, but after disabling these, system time still stops in suspend. this used to work fine in 2.6.39 for sure. i suspect it has something to do with the new RTC subsystem redesign in 3.0.

could this be related:

$ sudo hwclock -r
hwclock: select() to /dev/rtc to wait for clock tick timed out: Success

adding --directisa makes hwclock work, but is this how it's supposed to be?

full kernel config is at http://paste.pocoo.org/show/500367/, perhaps someone knows what i'm doing wrong?

these seem interesting:

CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"

Offline

#245 2011-10-30 12:14:50

nous
Member
From: Across the Universe
Registered: 2006-08-18
Posts: 323
Website

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

lkraav wrote:

looking forward to 3.1.0-pf. in the meanwhile, i'm running 3.0.2-pf, does anyone happen to know why my laptop system time stops while in suspend?

It shouldn't. It's most likely a BIOS bug triggered by the new 3.0 kernel. I can't say for sure if it's the RTC subsystem or the suspend code. Which backed do you use, tuxonice or the kernel built-in?

lkraav wrote:

i thought only PM_DEBUG and friends did that since they save their magic into RTC, but after disabling these, system time still stops in suspend. this used to work fine in 2.6.39 for sure. i suspect it has something to do with the new RTC subsystem redesign in 3.0.

could this be related:

$ sudo hwclock -r
hwclock: select() to /dev/rtc to wait for clock tick timed out: Success

adding --directisa makes hwclock work, but is this how it's supposed to be?

full kernel config is at http://paste.pocoo.org/show/500367/, perhaps someone knows what i'm doing wrong?

these seem interesting:

CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"

If you use hibernate-script instead of pm-utils, you might want to take a look at /etc/hibernate/common.conf and change "SaveClock restore-only" to "SaveClock yes" and see if that somehow persuades BIOS not to freeze the RTC. Worst case scenario, until it gets fixed, you'd need a ntpdate directive appended to the "OnResume" option in the aforementioned common.conf.

Offline

#246 2011-10-30 16:56:51

lkraav
Member
Registered: 2011-04-08
Posts: 37

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

nous wrote:

It shouldn't. It's most likely a BIOS bug triggered by the new 3.0 kernel. I can't say for sure if it's the RTC subsystem or the suspend code. Which backed do you use, tuxonice or the kernel built-in?

using builtin. haven't felt a need for tuxonice, is there an overview somewhere about what it particularly does better, if anything? unless you have a url bookmarked dont waste your time googling for me :>

nous wrote:

If you use hibernate-script instead of pm-utils, you might want to take a look at /etc/hibernate/common.conf and change "SaveClock restore-only" to "SaveClock yes" and see if that somehow persuades BIOS not to freeze the RTC. Worst case scenario, until it gets fixed, you'd need a ntpdate directive appended to the "OnResume" option in the aforementioned common.conf.

i'm on pm-utils. this is one of the reasons im eager to try 3.1.0-pf, to get some btrfs fixes and see if this clock thing improves. strange thing is googling for "linux kernel suspend clock stops" and similar is a complete dead end. i would expect more people being hit if it was a kernel issue..

Last edited by lkraav (2011-10-30 16:57:40)

Offline

#247 2011-10-31 00:38:54

gee
Member
Registered: 2006-11-29
Posts: 313

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

Hey,

I have installed your core2 package to get aufs, but when I compile aufs3-util from aur I get this:
"ver.c:19:29: fatal error: linux/aufs_type.h: No such file or directory"

Any idea?

Thanks!

Offline

#248 2011-10-31 07:35:59

nous
Member
From: Across the Universe
Registered: 2006-08-18
Posts: 323
Website

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

gee wrote:

Hey,
I have installed your core2 package to get aufs, but when I compile aufs3-util from aur I get this:
"ver.c:19:29: fatal error: linux/aufs_type.h: No such file or directory"
Any idea?
Thanks!

I don't know. The header file exists:

% pacman -Qo /lib/modules/3.0-pf/build/include/linux/aufs_type.h
/lib/modules/3.0-pf/build/include/linux/aufs_type.h is owned by linux-pf-core2 3.0.7-1

Offline

#249 2011-10-31 07:41:12

nous
Member
From: Across the Universe
Registered: 2006-08-18
Posts: 323
Website

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

lkraav wrote:
nous wrote:

It shouldn't. It's most likely a BIOS bug triggered by the new 3.0 kernel. I can't say for sure if it's the RTC subsystem or the suspend code. Which backed do you use, tuxonice or the kernel built-in?

using builtin. haven't felt a need for tuxonice, is there an overview somewhere about what it particularly does better, if anything? unless you have a url bookmarked dont waste your time googling for me :>

nous wrote:

If you use hibernate-script instead of pm-utils, you might want to take a look at /etc/hibernate/common.conf and change "SaveClock restore-only" to "SaveClock yes" and see if that somehow persuades BIOS not to freeze the RTC. Worst case scenario, until it gets fixed, you'd need a ntpdate directive appended to the "OnResume" option in the aforementioned common.conf.

i'm on pm-utils. this is one of the reasons im eager to try 3.1.0-pf, to get some btrfs fixes and see if this clock thing improves. strange thing is googling for "linux kernel suspend clock stops" and similar is a complete dead end. i would expect more people being hit if it was a kernel issue..

I use tuxonice on my laptops, as it provides a nice splash interface. Also (a big one), built-in hibernation kills X when its image doesn't fit in swap (when I forget to shut down my Opera with 97 open tabs).

Offline

#250 2011-10-31 14:21:15

gee
Member
Registered: 2006-11-29
Posts: 313

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

Yup I get the same


pacman -Qo /lib/modules/3.0-pf/build/include/linux/aufs_type.h                                                                                                                               
/lib/modules/3.0-pf/build/include/linux/aufs_type.h is owned by linux-pf-core2 3.0.7-1


but still cannot compile aufs sad

Offline

Board footer

Powered by FluxBB