01:11.22 | *** join/#maemo-ssu timoph_ (mjolk@hilla.kapsi.fi) |
01:18.22 | *** join/#maemo-ssu krayon (~krayon@pdpc/supporter/28for7/krayon) |
01:21.30 | *** join/#maemo-ssu guly (~why@shivaya.guly.org) |
01:30.31 | *** join/#maemo-ssu guly (~why@shivaya.guly.org) |
02:39.11 | *** join/#maemo-ssu ZogG (~zoggrules@bzq-79-177-202-47.red.bezeqint.net) |
02:47.56 | *** join/#maemo-ssu Sc0rpius (~naikel@190.78.151.78) |
02:55.11 | *** join/#maemo-ssu guly (~why@shivaya.guly.org) |
02:55.12 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
04:28.06 | *** join/#maemo-ssu Sc0rpius (~naikel@190.78.151.78) |
04:51.40 | *** join/#maemo-ssu wmarone (~wmarone@c-67-174-151-253.hsd1.ca.comcast.net) |
05:32.42 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.141) |
05:45.45 | *** join/#maemo-ssu mirandir (~valentin@lec67-4-82-230-53-23.fbx.proxad.net) |
05:48.01 | *** join/#maemo-ssu Jade (~jade@unaffiliated/jade) |
06:25.50 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-89-102-207-166.net.upcbroadband.cz) |
07:37.21 | *** join/#maemo-ssu dafox (~dafox@dyn-194208.nbw.tue.nl) |
08:38.33 | *** join/#maemo-ssu arcean (~arcean@aadb243.neoplus.adsl.tpnet.pl) |
09:49.58 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-89-102-207-166.net.upcbroadband.cz) |
09:50.22 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.138) |
10:14.18 | *** join/#maemo-ssu BCMM (~user@unaffiliated/bcmm) |
10:42.42 | *** join/#maemo-ssu andre__ (~andre@Maemo/community/bugmaster/andre) |
10:56.35 | *** join/#maemo-ssu BCMM_ (~user@unaffiliated/bcmm) |
11:02.27 | *** join/#maemo-ssu BCMM_ (~user@unaffiliated/bcmm) |
11:07.17 | *** part/#maemo-ssu mirandir (~valentin@lec67-4-82-230-53-23.fbx.proxad.net) |
11:08.17 | *** join/#maemo-ssu mirandir (~valentin@lec67-4-82-230-53-23.fbx.proxad.net) |
11:42.15 | *** join/#maemo-ssu DocScrutinizer (~halley@openmoko/engineers/joerg) |
12:30.54 | *** join/#maemo-ssu Pali (~pali@unaffiliated/pali) |
12:33.31 | *** join/#maemo-ssu ZogG (~zoggrules@79.176.200.113) |
13:11.15 | *** join/#maemo-ssu trbs (~trbs@2001:470:d2ad:1:4a5b:39ff:fe7d:1623) |
13:14.49 | merlin1991 | freemangordon: ping |
13:29.14 | *** join/#maemo-ssu Pali (~pali@unaffiliated/pali) |
13:36.00 | merlin1991 | dang now I need him :/ |
13:45.30 | *** join/#maemo-ssu mase76 (~mase76@p5DD3AAEC.dip.t-dialin.net) |
13:59.34 | freemangordon | merlin1991, pong |
14:00.57 | merlin1991 | dosfstools had to be built without -O2 ? |
14:01.05 | merlin1991 | because you never changed debian/rules |
14:01.32 | merlin1991 | freemangordon: ^^ |
14:02.14 | freemangordon | merlin1991, most probably there won' be a problem to add -O2 |
14:02.22 | freemangordon | *won't |
14:02.27 | merlin1991 | freemangordon: well it's there |
14:02.35 | merlin1991 | but I recall you raging about not again like Qt |
14:02.40 | freemangordon | I don't understand then |
14:02.45 | freemangordon | aah |
14:02.47 | merlin1991 | and saying that it started to work after you killed -02 |
14:03.10 | merlin1991 | so with or without -O2 now? :D |
14:03.19 | freemangordon | merlin1991, no, it was my fault not applying pathches in debian/patches. |
14:03.27 | freemangordon | -O2 is ok |
14:03.29 | merlin1991 | ah okay |
14:03.35 | freemangordon | give me a second |
14:05.34 | freemangordon | merlin1991, debian/rules were missing "include /usr/share/quilt/quilt.make" so the patch in debian/patches have not been applied |
14:06.02 | freemangordon | and it was that patch missing that were resulting in segfault |
14:06.41 | freemangordon | here is the patch that glues all the pieces together https://gitorious.org/community-ssu/dosfstools/commit/7c10cc567693d31ce14f2738dc0b55ca4f68a067 |
14:06.56 | freemangordon | merlin1991 ^^^ |
14:07.16 | merlin1991 | perfect :) |
14:07.19 | *** join/#maemo-ssu BCMM (~user@unaffiliated/bcmm) |
14:07.44 | freemangordon | :) |
14:39.31 | *** join/#maemo-ssu chainsawbike (~chainsawb@unaffiliated/chainsawbike) |
15:00.08 | Estel_ | merlin1991, freemangordon, do You know that e2fs is Maemo is broken, and there is way to repair it that could be included in CSSU |
15:00.33 | Estel_ | it means, that small filesystem coruptions (like repairable by recovering from journal) works, but bigger repairs result in e2fs segfault |
15:00.43 | Estel_ | I've written about it some time ago |
15:00.50 | Estel_ | latest version from Debian works well |
15:00.55 | Estel_ | and doesn't seem to be causing any regressions |
15:09.31 | freemangordon | Estel_, no, I was not aware of that. Will see if latest debian version could be compiled under SB and will put it in cssu-devel |
15:09.48 | Estel_ | thansk a lot. I got something documented "somewhere |
15:09.54 | Estel_ | "" will tyr to find that and send You |
15:09.59 | freemangordon | ok |
15:10.01 | Estel_ | s/tyr/try/ |
15:12.07 | Estel_ | freemangordon, found it, You preffer Pm on TMO or zerobin? |
15:15.38 | Estel_ | freemangordon, BTw, I forget to mention it - 720p video recording stopped working properly for me :( |
15:15.52 | Estel_ | it all stutters, and strange artifacts show on screen |
15:16.02 | Estel_ | on viewfinde,r but they're also included in video |
15:16.25 | Estel_ | it look like on old TV, when FPs were not synced |
15:18.32 | Estel_ | I have such video, if You're interested |
15:18.42 | Estel_ | would like to help in finding why. It's reproduceable |
15:47.51 | freemangordon | Estel_, that is strange, could be relatet to too much zoom |
15:47.59 | Estel_ | 0 zoom |
15:47.59 | freemangordon | *related |
15:48.05 | freemangordon | all resolutions? |
15:48.08 | Estel_ | I never use it as it's software zoom, for obvious reasons |
15:48.21 | Estel_ | lemme check on non-hd ones... |
15:48.33 | Estel_ | I think it started after CSSU *or* kp50 upgrade, can't tell for sure now :/ |
15:48.49 | freemangordon | hmm, could be your DSP is too undervolted |
15:49.11 | freemangordon | there was a change in KP50 re SR voltage calculation |
15:50.23 | Estel_ | maybe, because now I can't reproduce it, WTF... Tried many times in ZOO today, when I was filming my sonb |
15:50.32 | Estel_ | s/sonb/son/ |
15:51.01 | Estel_ | but honestly, it looked rather like stoping tracker or something like that failed |
15:51.07 | Estel_ | will try on fresh reboot |
15:51.10 | Estel_ | maybe it will re-appear |
15:53.28 | freemangordon | Estel_, BTW where that "swap fragmentation" thingie comes from? |
15:53.43 | Estel_ | You mean ereswap, or problem itself? |
15:53.49 | freemangordon | the problem |
15:54.08 | Estel_ | look. swap, initially, is save din purely sequential manner |
15:54.19 | Estel_ | (I've explained it in ereswap readme and thread on TMO :P) |
15:54.26 | Estel_ | so, if Yuo save 100 MB |
15:54.32 | Estel_ | then free 20 in middle |
15:54.35 | freemangordon | I mean: there is an algorithm in kernel to combine non-sequental sectors to sequental writes |
15:54.46 | Estel_ | yea, but it's not that |
15:54.52 | Estel_ | damn, shadowjk would explain it better than me but |
15:55.07 | freemangordon | well, if it is explained I will read it |
15:55.17 | Estel_ | as You know things saved in emmc or mmc does have physical write leveling |
15:55.18 | Estel_ | ok |
15:55.30 | Estel_ | but it's explained in "human language" |
15:55.46 | Estel_ | generally, whole thing is that swaps doesn't care for (logical mapping) freed bits |
15:55.55 | Estel_ | it just keep saving sequentialy |
15:56.00 | Estel_ | but, when ti reaches end of partition |
15:56.07 | Estel_ | it start re-using previously freed bits |
15:56.18 | Estel_ | they're, almsot always, not matching size of what You need to write actually |
15:56.26 | Estel_ | so swpa performance decrease dramaticaly |
15:56.31 | Estel_ | swap* |
15:57.06 | Estel_ | and it doesn't matter than our emmc and microSD flash have wear leveling |
15:57.06 | freemangordon | Estel_, I see, but in fact kernel driver tries to find first big enough free space |
15:57.20 | freemangordon | and it should succeed |
15:57.23 | Estel_ | Hm, haven't know about that, but I must tell You that, somehow, it's still slower |
15:57.25 | freemangordon | most of the time |
15:57.26 | Estel_ | maybe some bug? |
15:57.29 | Estel_ | for sure it's not placebo |
15:57.41 | Estel_ | I feel it really, even if I don't know about writes on swap |
15:57.51 | freemangordon | could be a bug, maybe I should put some tracing to checkwhat is going on |
15:57.55 | Estel_ | sometimes, when something trash my swap without me knowing, I tell myself "wtf, why i started to clutter" |
15:57.57 | Estel_ | then I check it |
15:58.10 | Estel_ | anbd see that I'm, lets say, 20 MB after reaching swap "limit" |
15:58.16 | Estel_ | quite possibloe |
15:58.19 | Estel_ | possible* |
15:58.24 | freemangordon | Estel_, that deffinitely sounds like a bug |
15:58.29 | Estel_ | maybe this kernel-searching is resource hungry? |
15:58.34 | Estel_ | You know, even UI is slower |
15:58.47 | Estel_ | I always wondered why the hell it seems slower even with no memory huingry things |
15:58.58 | Estel_ | OTOH i don't see much CPU usage |
15:59.15 | Estel_ | maybe time penalties for searching? or it's really a bug |
15:59.28 | freemangordon | Estel_, don't sound like resource hunger, as if it that was the case, then your limit wouldn't be exactly the partition size |
15:59.35 | freemangordon | BTW better switch to #maemo |
15:59.38 | Estel_ | true |
16:04.33 | *** join/#maemo-ssu NIN101 (~NIN@p5DD28984.dip0.t-ipconnect.de) |
16:07.50 | ShadowJK | The nokia modified swap algorithm is: Find largest free block in swap, start writing to that block until end of block, repeat find largest free blck. Over time, as stuff is allocated and freed, the largest free block becomes small, and unaligned. For optimal speed we want somethning like 1Mbyte alignment. |
16:10.05 | Estel_ | ShadowJK, thanks a lot |
16:10.13 | Estel_ | could You switch to #maemo |
16:25.30 | *** part/#maemo-ssu mirandir (~valentin@lec67-4-82-230-53-23.fbx.proxad.net) |
16:35.28 | *** join/#maemo-ssu M4rtinK (~M4rtinK@eduroam-221.fi.muni.cz) |
16:51.20 | *** join/#maemo-ssu Atarii (~Atarii@77.107.156.213) |
16:51.20 | *** join/#maemo-ssu Atarii (~Atarii@unaffiliated/atarii) |
17:33.55 | *** join/#maemo-ssu M4rtinK (~M4rtinK@wired-161.fi.muni.cz) |
18:00.10 | *** join/#maemo-ssu M4rtinK (~M4rtinK@eduroam-221.fi.muni.cz) |
19:32.21 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
20:29.23 | *** join/#maemo-ssu ekze-nyan (~nyan@bakaekze.ru) |
20:29.53 | *** join/#maemo-ssu smoku (~spectrum@xkh0g2.infr.xiaoka.com) |
20:31.40 | *** join/#maemo-ssu M4rtinK (~M4rtinK@213.29.197.252) |
20:47.42 | *** join/#maemo-ssu ekze (~nyan@bakaekze.ru) |
20:56.02 | *** join/#maemo-ssu mirandir (~valentin@lec67-4-82-230-53-23.fbx.proxad.net) |
21:39.17 | *** join/#maemo-ssu andre__ (~andre@Maemo/community/bugmaster/andre) |
22:10.18 | *** part/#maemo-ssu smoku (~spectrum@xkh0g2.infr.xiaoka.com) |
22:11.29 | *** join/#maemo-ssu mase76 (~mase76@p5DD3BA63.dip.t-dialin.net) |
22:15.35 | Atarii | hey |
22:15.47 | Atarii | is T-maemo3.1 the latest stable version? |
22:16.56 | Sc0rpius | that's what the topic says |
22:17.06 | merlin1991 | that's what I say aswell :D |
22:17.10 | Sc0rpius | no that's the testing |
22:17.16 | Sc0rpius | the stable is S-maemo3 |
22:17.27 | Sc0rpius | but it's pretty stable anyway |
22:17.31 | Atarii | doh, should have looked at the topic, thanks guys] |
22:17.32 | merlin1991 | something 3 anyway :D |
22:17.41 | Sc0rpius | by the way who managed to stop modest crashes? good job. |
22:17.48 | Sc0rpius | kudos to that guy |
22:17.59 | merlin1991 | Sc0rpius: uhm freemangordon, but well it was just wrongly compiled |
22:18.08 | merlin1991 | all thanks to mags fubar scratchbox |
22:18.13 | merlin1991 | (which also broke ke-recv) |
22:21.55 | Sc0rpius | oh.. |
23:40.43 | *** join/#maemo-ssu ZogG (~zoggrules@bzq-79-180-207-36.red.bezeqint.net) |
23:54.59 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |