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

nous · 2011-09-23 22:49:42

kalpik wrote:

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

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

nous · 2011-09-23 23:04:41

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.

kalpik · 2011-09-24 03:30:53

nous wrote:

kalpik wrote:
My boot status is still broken, and dmesg messages creep into it
If I understood correctly, then you must append the 'quiet' flag to the kernel command line in grub/lilo.

Adding quiet fixed it! Thanks

kokoko3k · 2011-09-24 07:45:07

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

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

knedlyk · 2011-09-30 11:42:04

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).

nous · 2011-09-30 21:08:25

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?

knedlyk · 2011-09-30 21:23:09

Hi,

i686, now it works! Thanks!

choener · 2011-10-15 15:39:42

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

nous · 2011-10-16 08:17:27

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?

choener · 2011-10-18 17:27:38

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

lucak3 · 2011-10-22 08:20:33

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.

nous · 2011-10-22 10:54:01

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?

lucak3 · 2011-10-26 07:41:01

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.

nous · 2011-10-27 17:11:58

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.

post-factum · 2011-10-27 17:23:52

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.

post-factum · 2011-10-27 17:44:48

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

BFQ developers are going to release improved version for 3.1.

lucak3 · 2011-10-28 10:27:06

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.

post-factum · 2011-10-28 17:17:34

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.

lkraav · 2011-10-30 11:09:04

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"

nous · 2011-10-30 12:14:50

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.

lkraav · 2011-10-30 16:56:51

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)

gee · 2011-10-31 00:38:54

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!

nous · 2011-10-31 07:35:59

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

nous · 2011-10-31 07:41:12

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).

gee · 2011-10-31 14:21:15

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

Arch Linux

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Board footer