![]() |
Re: BFS for the power kernel
The system was just started a few minutes before and I also put the "echo bfq ..." into /etc/init.d/rcS and tried it after several reboots. I was able to start xterm but as soon as I started something like cutetube or the browser it always crashed pretty fast. I also once noticed that it rebooted while the screen was turned off and the system was idling. So I guess that it still has something to do with swapping.
Thanks for the effort nonetheless! |
Re: BFS for the power kernel
Quote:
I always prefer to set scheduler on start of hildon-desktop, I don't want to have reboot loops :) Btw, how can I set "elevator=" for the kernel via multiboot? Does it work? My only kernel is bfs, so I'm accurate with booting. Tried the version from your last post, with bfq for mmcblk0 UI freezes (again I switched to desktop and opened the browser) and watchdogs reboot the system after 30 seconds or so, there is no messages in crash log. Seems like Xorg gets stuck, but it doesn't seem to be related to swap: I load Xorg with the mlocker.so trick. With bfq for mmcblk1 the kernel immediately crashes after opening some application that takes additional memory (because I have swap on mmcblk1 in addition to mmcblk0), here is the log: Code:
][65080.278472] Unable to handle kernel NULL pointer dereference at virtual address 00000000 |
Re: BFS for the power kernel
I also load Xorg into memory using libmlockall, which is the same as mlocker, basically. The solitary crash I had (yesterday morning) occurred also when the screen was off and the system idle. I have BFQ on both mmcblk0 and 1, and my swap is also on 1, so I am not convinced about it being swap at fault.
The next stage is to build the kernel without bfqio enabled, if you wouldn't mind testing it. I am unable to reproduce the instability in my own device, which is frustrating as it makes tracking down the cause difficult.. |
Re: BFS for the power kernel
|
Re: BFS for the power kernel
|
Re: BFS for the power kernel
Same result here - about an hour of heavy use with the new kernel (bfqio disaled). BFQ is enabled on mmcblk0 and mmcblk1, and no instability yet.
For the record, I've been testing BFS kernel with swap on default emmc partition and had very bad stability issues using BFQ with the previous kernel. |
Re: BFS for the power kernel
I've just realised I made a mistake when backporting the code. 2.6.32 and above (which the 'official' BFQ v1 was written for, when the site moved some time in 2009) calls __blk_run_queue() instead of blk_start_queueing(). As __blk_run_queue exists in 2.6.28, I assumed this was an optimization - but it turns out that in fact, blk_start_queueing was depreciated some time between .28 and .32, with its sanity checks added to __blk_run_queue; unfortunately, the .28 version (of __blk_run_queue) has almost no such checks at all. I'm just recompiling again, having changed the relevant lines back to blk_start_queueing, and will be testing in due course..
|
Re: BFS for the power kernel
Any updates on this? Hmm this thread is already 1 week inactive
|
Re: BFS for the power kernel
I've been trying to track down the cause of the distorted calls, to no avail so far, sorry to say. I implemented a subset of this patch (minus the "avoid recursion in run_workqueue()" patch, as this causes regressions, and the avenrun patch as that makes BatteryGraph go mental) and also updated the "need_resched" and "should_resched" logic to match the 2.6.29 backport of BFS, but the problem persisted. However I've since found that powertop is showing my C2 to be at 80% almost constantly, even with the power kernel (though my battery life is very good) so I'm contemplating reflashing everything and starting over, but I don't have the time for that at the moment unfortunately.
I did, however, have some joy updating the UBIFS drivers from this git tree, I can't tell if it's any faster or not though. Oh, and I did change the two places __blk_run_queue was called within BFQ (there was no discernable difference, i.e it was still as stable as before without cgroups, but as soon as I enable them, crashes aplenty - not tried since implementing the prereqs though). So, although I haven't updated the thread, I've not been inactive ;) EDIT: Almost forgot, reversed this patch (which has always been present within our BFS) as it's for Android's VM only and I really can't see why it would be needed on Maemo, but again I haven't noticed any difference. |
Re: BFS for the power kernel
Hmm... the CPU in my n900 runs about 89% in C3 and I can happily report that I didn't notice any distortion in the last time.
|
| All times are GMT. The time now is 15:49. |
vBulletin® Version 3.8.8