Page 26 of 31 « First 162425 26 2728 Last »
Reply
Thread Tools
MONVMENTVM is offline MONVMENTVM
2011-06-13 , 10:44
Posts: 145 | Thanked: 91 times | Joined on Jun 2010
#251
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!
 

The Following User Says Thank You to MONVMENTVM For This Useful Post:
Bad_Habit is offline Bad_Habit
2011-06-13 , 10:45
Posts: 48 | Thanked: 32 times | Joined on Dec 2010 @ Russia, Moscow
#252
Originally Posted by Tigerite View Post
Yep, it seems to definitely be loaded. Did you have bfq as the default scheduler for mmcblk0, if so then setting it on mmcblk1 wouldn't change anything in /syspart.. it's also possible that bfqio is enabled regardless of whether bfq is or not, and just sits idle until called upon. Ok, could you please try one of these (depending on your setup - the modules should be unchanged), I have disabled the "queue small requests" part of BFQ v2 r1 and have been running it happily on my device for a full day without any crashes..

Multiboot deb
Standard deb (use with flasher)
U-Boot image
cfq is the default scheduler, /syspart/bfqio* is always being created

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
[65080.278472] pgd = cc1b8000
[65080.278503] [00000000] *pgd=8859c031, *pte=00000000, *ppte=00000000
[65080.278533] Internal error: Oops: 817 [#1] PREEMPT
[65080.278533] Modules linked in: vfat fat sd_mod scsi_mod iphb rfcomm sco panic_info_buff l2cap ext3 jbd omaplfb pvrsrvkm bridgedriver ipv6 g_file_storage uinput board_rx51_camera et8ek8 omap_previewer_hack omap34xxcam_mod isp_mod iovmm videobuf_dma_sg videobuf_core omap3_iommu iommu2 iommu dspbridge ssi_mcsaab_imp phonet joydev cmt_speech smc91x mii mac80211 crc7 omap_ssi cfg80211 tsc2005 nokia_av hci_h4p bluetooth fmtx_si4713 videodev ad5820 adp1653 lis302dl v4l1_compat compat_ioctl32 smia_sensor rtc_twl4030 tsl2563 smiaregs v4l2_int_device rtc_core leds_twl4030_vibra cifs nls_utf8 fuse ntfs leds_lp5523 led_class mmc_block omap_hsmmc mmc_core twl4030_wdt omap_wdt [last unloaded: wl12xx]
[65080.278869] CPU: 0    Not tainted  (2.6.28.10-bfs6 #1)
[65080.278900] PC is at __bug+0x20/0x2c
[65080.278930] LR is at release_console_sem+0x200/0x21c
[65080.278961] pc : [<c002fe78>]    lr : [<c00560f4>]    psr: 600001d3
[65080.278961] sp : c855fc40  ip : c855fb60  fp : c855fc4c
[65080.278991] r10: cfe0ee84  r9 : c5081280  r8 : cfc01a50
[65080.278991] r7 : 00000014  r6 : cfc44a20  r5 : c5081258  r4 : c5081278
[65080.279022] r3 : 00000000  r2 : 00000001  r1 : ffffffa0  r0 : 00000060
[65080.279052] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment user
[65080.279052] Control: 10c5387d  Table: 8c1b8018  DAC: 00000015
[65080.279083] Process rtcom-call-ui (pid: 1956, stack limit = 0xc855e2e8)
[65080.279113] Stack: (0xc855fc40 to 0xc8560000)
[65080.279113] fc40: c855fc7c c855fc50 c0151684 c002fe64 00000000 cfc01a50 c5081000 cfc44a20 
[65080.279174] fc60: 00000014 cfc44a20 c5081000 c52a0980 c855fc94 c855fc80 c0152118 c0151650 
[65080.279205] fc80: cfc01a20 c5081000 c855fcb4 c855fc98 c015382c c015210c cfc44a20 cf157740 
[65080.279235] fca0: cf157740 cfc01a20 c855fce4 c855fcb8 c01538f4 c01536f0 c01538c0 cfc44a20 
[65080.279296] fcc0: cf157740 cf157740 00001000 00000000 0008b000 c52a0980 c855fd04 c855fce8 
[65080.279327] fce0: c0144dd8 c01538cc cfc44a20 cf157740 00000003 00001000 c855fd24 c855fd08 
[65080.279388] fd00: c0144f74 c0144cc8 cfc44a20 c52a0980 cf157740 00001000 c855fd54 c855fd28 
[65080.279418] fd20: c01479e0 c0144ec4 c855fd74 cfc44a20 c008dd8c c52a0980 cf157740 00000008 
[65080.279479] fd40: c855e000 00000000 c855fd94 c855fd58 c01463f4 c014769c 00000001 cf052840 
[65080.279510] fd60: c00a8018 001200d2 c855fd8c c855fd78 c00df4e0 c008dd5c c05352a0 c52a0980 
[65080.279571] fd80: 00000000 00000000 c855fdec c855fd98 c0147b9c c01461f0 c05352a0 080006e0 
[65080.279602] fda0: c03bf700 c52a0980 080006e0 c05352a0 c00a8018 0008b000 c855fdec c855fdc8 
[65080.279632] fdc0: c00a7eec c00a995c c05352a0 c52a0980 00000000 00000000 001200d2 001200d2 
[65080.279693] fde0: c855fe0c c855fdf0 c00a7fd8 c0147a9c 00000000 c855fe00 c05352a0 080006e0 
[65080.279724] fe00: c855fe34 c855fe10 c00a86fc c00a7f44 080006ff 00000700 08000000 c8534058 
[65080.279785] fe20: 0008b000 0008b000 c855fe64 c855fe38 c00a8794 c00a8654 c855e000 000006e0 
[65080.279815] fe40: c855e000 00000000 00000000 c8534058 000dfe04 cc1b8000 c855fec4 c855fe68 
[65080.279876] fe60: c009cc50 c00a8764 c0533180 00000000 c855fe94 c855fe80 c008b0a4 00000000 
[65080.279907] fe80: 00000800 ce67a600 080006ff 0000022c cc1b8000 c008b078 cc1b9020 ce67a634 
[65080.279968] fea0: c506d500 ce67a600 c8534058 c855ffb0 00000817 0008b020 c855fefc c855fec8 
[65080.279998] fec0: c0298a4c c009c8a4 cbd11580 00000000 40805000 c02988e0 c036c7bc 00000817 
[65080.280029] fee0: c855ffb0 0008b020 40368698 001229a0 c855ffac c855ff00 c002c270 c02988ec 
[65080.280090] ff00: 00000000 ce67a600 00000017 00000014 cc1b9020 c855e000 c855ff44 ce67a634 
[65080.280120] ff20: 00000200 c506d500 c855ff44 c855ff38 c00705dc c015da18 c855ff7c c855ff48 
[65080.280181] ff40: c0298ae4 c00705d8 00000000 c039c1f8 c855ffac ffffffff c855ffb0 80000000 
[65080.280212] ff60: 0000000b=
]<7>mtdoops: Ready 60, 61 (no erase)
[65080.280853] 0011eb18 40368698 001229a0 c855ff9c c855ff80 c0298bc4 c02988ec 
[65080.280883] ff80: ffffffff 0011eb18 00000000 ffffffff 00000000 00000026 00000000 00000000 
[65080.280914] ffa0: 00000000 c855ffb0 c0296f60 c002c23c 00000000 0008b020 00000000 00000000 
[65080.280975] ffc0: 00083f40 00000000 00000026 00000000 00000000 40368698 001229a0 bed024ac 
[65080.281005] ffe0: 0008b020 bed02490 00000001 40805eb8 60000050 ffffffff 00000000 00000000 
[65080.281066] Backtrace: 
[65080.281066] [<c002fe58>] (__bug+0x0/0x2c) from [<c0151684>] (__bfq_activate_entity+0x40/0x22c)
[65080.281127] [<c0151644>] (__bfq_activate_entity+0x0/0x22c) from [<c0152118>] (bfq_activate_bfqq+0x18/0x38)
[65080.281188] [<c0152100>] (bfq_activate_bfqq+0x0/0x38) from [<c015382c>] (bfq_add_rq_rb+0x148/0x1dc)
[65080.281219]  r5:c5081000 r4:cfc01a20
[65080.281250] [<c01536e4>] (bfq_add_rq_rb+0x0/0x1dc) from [<c01538f4>] (bfq_insert_request+0x34/0x278)
[65080.281280]  r7:cfc01a20 r6:cf157740 r5:cf157740 r4:cfc44a20
[65080.281311] [<c01538c0>] (bfq_insert_request+0x0/0x278) from [<c0144dd8>] (elv_insert+0x11c/0x1fc)
[65080.281372] [<c0144cbc>] (elv_insert+0x0/0x1fc) from [<c0144f74>] (__elv_add_request+0xbc/0xc0)
[65080.281402]  r7:00001000 r6:00000003 r5:cf157740 r4:cfc44a20
[65080.281433] [<c0144eb8>] (__elv_add_request+0x0/0xc0) from [<c01479e0>] (__make_request+0x350/0x400)
[65080.281463]  r7:00001000 r6:cf157740 r5:c52a0980 r4:cfc44a20
[65080.281494] [<c0147690>] (__make_request+0x0/0x400) from [<c01463f4>] (generic_make_request+0x210/0x25c)
[65080.281555]  r8:00000000 r7:c855e000 r6:00000008 r5:cf157740 r4:c52a0980
[65080.281585] [<c01461e4>] (generic_make_request+0x0/0x25c) from [<c0147b9c>] (submit_bio+0x10c/0x128)
[65080.281616]  r7:00000000 r6:00000000 r5:c52a0980 r4:c05352a0
[65080.281646] [<c0147a90>] (submit_bio+0x0/0x128) from [<c00a7fd8>] (swap_readpage+0xa0/0xe0)
[65080.281707] [<c00a7f38>] (swap_readpage+0x0/0xe0) from [<c00a86fc>] (read_swap_cache_async+0xb4/0x110)
[65080.281738]  r5:080006e0 r4:c05352a0
[65080.281738] [<c00a8648>] (read_swap_cache_async+0x0/0x110) from [<c00a8794>] (swapin_readahead+0x3c/0x94)
[65080.281799]  r9:0008b000 r8:0008b000 r7:c8534058 r6:08000000 r5:00000700
[65080.281829] r4:080006ff
[65080.281829] [<c00a8758>] (swapin_readahead+0x0/0x94) from [<c009cc50>] (handle_mm_fault+0x3b8/0x7f4)
[65080.281890] [<c009c898>] (handle_mm_fault+0x0/0x7f4) from [<c0298a4c>] (do_page_fault+0x16c/0x2c0)
[65080.281951] [<c02988e0>] (do_page_fault+0x0/0x2c0) from [<c002c270>] (do_DataAbort+0x40/0xa0)
[65080.281982] [<c002c230>] (do_DataAbort+0x0/0xa0) from [<c0296f60>] (ret_from_exception+0x0/0x10)
[65080.282012] Exception stack(0xc855ffb0 to 0xc855fff8)
[65080.282043] ffa0:                                     00000000 0008b020 00000000 00000000 
[65080.282073] ffc0: 00083f40 00000000 00000026 00000000 00000000 40368698 001229a0 bed024ac 
[65080.282135] ffe0: 0008b020 bed02490 00000001 40805eb8 60000050 ffffffff                   
[65080.282165]  r8:00000000 r7:00000000 r6:00000026 r5:00000000 r4:ffffffff
[65080.282196] Code: e1a01000 e59f000c eb009a2c e3a03000 (e5833000) 
][65080.282806] mtdoops: Ready 61, 62 (no erase)
[65080.282836] Kernel panic - not syncing: Fatal exception
[65080.282836] Panic info buffer:
[65080.282867] OSSO_PRODUCT_HARDWARE='RX-51'
[65080.282867] OSSO_PRODUCT_NAME='N900'
[65080.282897] OSSO_PRODUCT_FULL_NAME='Nokia N900'
[65080.282897] OSSO_PRODUCT_RELEASE_NAME='Maemo 5'
[65080.282897] OSSO_PRODUCT_RELEASE_FULL_NAME='Maemo 5'
[65080.282897] OSSO_PRODUCT_RELEASE_VERSION='20.2010.36-2'
[65080.282928] OSSO_PRODUCT_WLAN_CHANNEL='fcc/us'
[65080.282928] OSSO_PRODUCT_KEYBOARD='Russian/Latin'
[65080.282928] OSSO_PRODUCT_REGION='Britain'
[65080.282958] OSSO_PRODUCT_SHORT_NAME='Nokia N900'
[65080.282958] OSSO_VERSION='RX-51_2009SE_20.2010.36-2_PR_MR0'
Bought my external card several days ago, there must be no read/write errors. But my eMMC is not so fine, sometimes crashes happen on high fs load, have no idea if that can be related. Will examine /dev/mtd2ro on next crash, thanks for the hint!
 
Tigerite is offline Tigerite
2011-06-13 , 12:07
Posts: 284 | Thanked: 320 times | Joined on May 2010 @ Peterborough, UK
#253
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..
 
Tigerite is offline Tigerite
2011-06-13 , 12:56
Posts: 284 | Thanked: 320 times | Joined on May 2010 @ Peterborough, UK
#254
Ok, here we go again with bfqio disabled this time..

Standard
Multiboot
U-Boot
 

The Following 5 Users Say Thank You to Tigerite For This Useful Post:
MONVMENTVM is offline MONVMENTVM
2011-06-13 , 13:28
Posts: 145 | Thanked: 91 times | Joined on Jun 2010
#255
Originally Posted by Tigerite View Post
Ok, here we go again with bfqio disabled this time..

Standard
Multiboot
U-Boot
After some minutes messing around in cutetube, watching videos and using the browser there were no crashes so far.
 

The Following 4 Users Say Thank You to MONVMENTVM For This Useful Post:
thingonaspring is offline thingonaspring
2011-06-13 , 18:03
Posts: 34 | Thanked: 50 times | Joined on Jun 2010
#256
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.
Last edited by thingonaspring; 2011-06-13 at 18:42. Reason: fix gibberish
 

The Following User Says Thank You to thingonaspring For This Useful Post:
Tigerite is offline Tigerite
2011-06-13 , 20:16
Posts: 284 | Thanked: 320 times | Joined on May 2010 @ Peterborough, UK
#257
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..
Last edited by Tigerite; 2011-06-13 at 20:28.
 

The Following 8 Users Say Thank You to Tigerite For This Useful Post:
Radicalz38 is offline Radicalz38
2011-06-21 , 07:43
Posts: 1,042 | Thanked: 430 times | Joined on May 2010
#258
Any updates on this? Hmm this thread is already 1 week inactive
 
Tigerite is offline Tigerite
2011-06-21 , 08:25
Posts: 284 | Thanked: 320 times | Joined on May 2010 @ Peterborough, UK
#259
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.
 

The Following 4 Users Say Thank You to Tigerite For This Useful Post:
MONVMENTVM is offline MONVMENTVM
2011-06-22 , 13:48
Posts: 145 | Thanked: 91 times | Joined on Jun 2010
#260
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.
 
Reply
Page 26 of 31 « First 162425 26 2728 Last »

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 02:41.

Contact Us - Home - Archive - Top