| 00:04.20 | *** join/#maemo-ssu arcean_ (~arcean@aaep168.neoplus.adsl.tpnet.pl) |
| 01:06.31 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.139) |
| 02:02.41 | *** join/#maemo-ssu jonwil (~jonwil@27-33-137-199.static.tpgi.com.au) |
| 02:24.10 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.139) |
| 02:27.42 | *** join/#maemo-ssu amiconn_ (quassel@rockbox/developer/amiconn) |
| 05:05.15 | *** join/#maemo-ssu taziff (~Taziff@cyr108.internetdsl.tpnet.pl) |
| 05:47.19 | *** join/#maemo-ssu chainsawbike (~chainsawb@unaffiliated/chainsawbike) |
| 05:57.41 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.139) |
| 08:08.16 | *** join/#maemo-ssu zeq (~s_j_newbu@178.109.220.37) |
| 08:27.23 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.139) |
| 09:23.13 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.139) |
| 09:32.07 | *** join/#maemo-ssu jonwil (~jonwil@27-33-137-199.static.tpgi.com.au) |
| 09:39.34 | *** join/#maemo-ssu BCMM (~ben@unaffiliated/bcmm) |
| 10:24.15 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.139) |
| 10:27.15 | *** join/#maemo-ssu BCMM (~ben@unaffiliated/bcmm) |
| 10:29.03 | *** join/#maemo-ssu NIN101 (~NIN@p5DD28BB5.dip0.t-ipconnect.de) |
| 10:34.49 | DocScrutinizer05 | merlin1991: I hope you know what your statement of "until proven stable" implies. NO WAY this will get decided by acclamation of guys like estel |
| 10:38.14 | DocScrutinizer05 | and you're the responsible for the stability and absense of colateral damage for every single patch you pull into any such CSSU kernel, and honestly why the bloody fuck is everybody so eager to forcefeed KP into CSSU and to all CSSU users, when each single one of those morons can install KP on his own device whenever he likes? crusade? missionary? leete kids dancing and shouting "look what I did" like tom hanks around the fire? |
| 10:43.30 | DocScrutinizer05 | why do all those revolutionists not simply fork a naemo, the Next maemo? Probably because they want to instruct the CSSU maintainers to drop genuine CSSU (community seamless software update, an extended life for the ssu primarily done by nokia) and rather build that leet stuff for those few who are not eager to install KP by themselves? |
| 10:44.13 | kerio | DocScrutinizer05: i, for one, approve of a cssu-power fork that also adds the said "leete" features |
| 10:44.32 | kerio | (cssu-thumb is kinda like that, if you think about it) |
| 10:44.49 | DocScrutinizer05 | I'll not support a kernel with 50+ patches that honestly all haven't been tested to work without side effects on our device |
| 10:46.05 | kerio | hey, KP50 is in extras! it means that it's stable! </sarcasm> |
| 10:46.09 | DocScrutinizer05 | yes, cssu-thumb is kinda like that, and that's what cssu experimental or whatever the name is meant for. However this is NOT meant to ever merge into cssu-t or even cssu-s |
| 10:47.18 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.139) |
| 10:51.25 | DocScrutinizer05 | as happy as I was yesterday until http://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2012-08-02.log.html#t2012-08-02T22:20:37, as sick I feel for CSSU future 17min later in chanlog |
| 10:52.11 | DocScrutinizer05 | honestly seems you guys planned a proper nice revolution, messing up everything the CSSU founders had in mind, eh? |
| 10:52.19 | kerio | "you guys" who? |
| 10:55.26 | DocScrutinizer05 | whoever initiated that blitz-conference |
| 10:55.37 | DocScrutinizer05 | and drove it that direction |
| 10:57.12 | DocScrutinizer05 | and I bet none of the real experts and co-founders of CSSU been invited - well that's all fine proforma, but in fact it's an unfriendly takeover. And final result will be a fork, one way or the other |
| 10:58.55 | DocScrutinizer05 | forcing KP and a potentially incompatibel (since it proved to always be like that) toolchain on a target customer group of "everybody owning a N900" is outright insane BS driven by hybris and idiocy |
| 11:05.11 | DocScrutinizer05 | most remarkable brainfuck seems to me that those who shout the loudest for KP in CSSU run uBoot or even multiboot(! :-O ) to revert to other kernels as soon as they don't feel content with their one and only love that's allegedly "enough for everybody" "tested by millions" and oh-so-leete |
| 11:09.01 | NIN101 | haha |
| 11:09.08 | DocScrutinizer05 | guys, this is not your latest toy you can mess with to your liking, this is a updating path to propagate bugfixes to *increase* STABILITY for those who maybe want to place emergency calls to 911 eventually with their N900, to save lifes |
| 11:09.32 | NIN101 | 100% ack. |
| 11:12.43 | DocScrutinizer05 | could I advice a medical doctor to use CSSU for his work N900. Till now I can, from now on I seem to have to tell him "No way! it became the playground of hackers who try their latest awesome hacks there" |
| 11:22.41 | *** join/#maemo-ssu krayon (~krayon@pdpc/supporter/28for7/krayon) |
| 11:34.22 | *** join/#maemo-ssu BCMM (~ben@unaffiliated/bcmm) |
| 11:57.16 | LaoLang_cool | Yeah! |
| 11:58.27 | LaoLang_cool | I don't use n900 as my cell phone, I use it as a super-mini tablet, it losts many basic cellphone functions |
| 12:10.34 | *** join/#maemo-ssu fw190 (1faf497d@gateway/web/freenode/ip.31.175.73.125) |
| 12:13.04 | fw190 | DocScrutinizer: as always I read the logs daily and as usually I don't agree with your attitude about CSSU I'm starting to get your point about it - just my 2 cents form a non developer CSSU user |
| 12:27.50 | DocScrutinizer05 | >>Estel_release early, release often ;) |
| 12:28.28 | DocScrutinizer05 | LOL that's true for devel and experimental, it clearly shows there's a massive misconception about what CSSU actually IS |
| 12:30.28 | kerio | ooh, cssu-devel has apt 0.7 |
| 12:30.29 | kerio | neat |
| 12:30.37 | DocScrutinizer05 | CSSU is conservative by nature, the mantra is "release rarely and as little changes as possible, and only do for things that are a) inevitable bugfixes and b) well tested by guys who know how to TEST and not just say "WFM" |
| 12:30.44 | kerio | and an updated busybox, sweet |
| 12:31.40 | DocScrutinizer05 | the only domain where you can be a bit more progressive with your improvements are those that DO NOT have impact on the whole system |
| 12:32.50 | DocScrutinizer05 | since for usability of device as a working phone for 911 calls it's not really dramatic when your wallpaper has rendering issues. A borked kernel however is a killer incident |
| 12:33.33 | DocScrutinizer05 | and NO WAY the mantra "release early, release often" ever applied to and kernel and/or toolchain related things |
| 12:33.57 | DocScrutinizer05 | s/to and/to any/ |
| 12:35.44 | jonwil | so yeah I do agree with not shipping KP but instead shipping kernel with minimal set of tested changes |
| 12:36.23 | jonwil | IIRC that was what was discussed at the meeting before |
| 12:38.01 | kerio | ooh, where do maemo-security-certman-applet and modest-home-applet (non-free) come from, in -devel? |
| 12:40.24 | jonwil | certman-applet is now open source so that can be replaced. I don't have a clue why CSSU is shipping modest-home-applet |
| 12:47.18 | DocScrutinizer05 | jonwil: actually finally they tackled down merlin1991to agree on including KP51 incl all BS bells and whistels, based on the fuzzy precondition it "all works as in stock kernel" while not a single word been said WHO is TESTING this |
| 12:48.56 | jonwil | which I disagree with |
| 12:48.59 | DocScrutinizer05 | as usual estel beaten everybody's intelligence by stating shit like "it's been tested by millions of happy ACME users" |
| 12:49.49 | DocScrutinizer05 | and "there are zero reports of anything bad happening, so there can't be anything" |
| 12:50.18 | DocScrutinizer05 | which is 3 wrong assumptions in one sentence, sth estel is really great on |
| 12:55.58 | DocScrutinizer05 | and aiui they also tortured merlin1991 to accept a new toolchain, something NOBODY SANE EVER dares to do easily, not even for 25% or 50% performance increase or whatever the anticipated benefits. Since a new toolchain resets your WHOLE SYSTEM to square 1 regarding basically everything. You can basically close all existing tickets and only care about new ones against app XY built with new toolchain, and obviously not a single app is |
| 12:55.59 | DocScrutinizer05 | guaranteed to inherit any of the stability it had before you changed toolchain |
| 12:57.20 | DocScrutinizer05 | basically same situation as with a new kernel, only worse |
| 12:58.55 | DocScrutinizer05 | honestly according to common sense such a massively "improved" system shouldn't be called maemo fremantle anymore, it's more like a whole new OS release, sth between fremantle and harmattan |
| 13:00.07 | DocScrutinizer05 | on a usual linux distro you'd bump at least the minor version by .1 |
| 13:00.22 | DocScrutinizer05 | so this should become maemo5.1 then |
| 13:00.42 | kerio | maemo-power! |
| 13:00.52 | DocScrutinizer05 | indeeed |
| 13:00.59 | kerio | or cssu-power |
| 13:01.01 | kerio | or something like that |
| 13:01.15 | DocScrutinizer05 | the suggested fork |
| 13:02.21 | DocScrutinizer05 | just it feels odd some guys try to hijack CSSU and would urge the original CSSU idea to fork to a new name like "CSSU_LTS" |
| 13:02.44 | DocScrutinizer05 | since CSSU been about LTS from day one |
| 13:06.21 | DocScrutinizer05 | and for my ass' sake I can't grok why some people are so eager to turn CSSU(-LTS) into (CSSU-)bleeding_edge. Maybe they want to solve the issue with lack of manpower to work on _their_ leete project rather than giving decent SAFE and TESTED and CONSERVATIVE support to _every_ N900-owner? |
| 13:07.30 | DocScrutinizer05 | hell there's KP51 for everybody to install free of charge! WTF we need to make it a mandatory part of CSSU? |
| 13:08.22 | DocScrutinizer05 | and what's next? Mandatory portrait-only desktop? |
| 13:10.34 | DocScrutinizer05 | "you want a fix for CVE-xy? Hell, go install CSSU(bleeding_edge_the_hackers_paradise)! Well you have to accept it doesn't work in landscape anymore, but if you want that fix you have to live with that. *WE* found portrait is all you ever will need" |
| 13:13.03 | DocScrutinizer05 | "unclear fsckups during power-on? reboot until system comes up! Wut? increased battery drain after unplugging XY from USB? Show evidence or we will close as INVALID" |
| 13:13.52 | DocScrutinizer05 | "missing inbound calls? Get a featurephone if you want to do phonecalls, this is not a phone this is a pocket PC after all" |
| 13:14.30 | DocScrutinizer05 | congrats if this attitude now preveils on CSSU |
| 13:14.35 | kerio | ok, you're well into strawman-land at this point |
| 13:14.45 | kerio | strawmen-land? |
| 13:15.41 | DocScrutinizer05 | kerio: nope, we're already there, or at least halfway |
| 13:16.40 | DocScrutinizer05 | stating KPxy was fit for primetime commercial-grade product is simply neglecting all the already known issues |
| 13:17.08 | DocScrutinizer05 | unclear problems during bootup only one of them |
| 13:18.26 | amiconn | Well, you can't even fix bugs without introducing changes. And *every* change might introduce (other) bugs, instabilities, orincompatibilites |
| 13:18.36 | DocScrutinizer05 | there are dozens of other unconfirmed complaints about regressions attributed to KP. Notion regarding them always been "as long as it's not hitting 100% of users 100% of time, we will just wait for $anybody picking up on the challenge to investigate further" |
| 13:19.00 | *** join/#maemo-ssu arcean (~arcean@aact183.neoplus.adsl.tpnet.pl) |
| 13:19.13 | amiconn | I'm not advocating aggressive moving forward ignoring problems, but I don't understand this "change nothing unless absolutely necessary" attitude |
| 13:19.28 | DocScrutinizer05 | now that's reworded to "tested by the masses" by estel |
| 13:20.08 | amiconn | Imho the most important part is to actually and actively take care of bug reports |
| 13:20.21 | amiconn | Just my 2 cents... |
| 13:21.11 | amiconn | This taking care of bug reports is missing for some maemo apps btw (not cssu material) |
| 13:21.51 | DocScrutinizer05 | amiconn: it's always a evaluation of risk vs benefit. The benefit side scores _only_ on fixing bugs or delivering massive functional improvements that can't get achieved otherwise, while the risk side scores on every single change done, multiplied by the number of subsystems that might get affected by any new bug introduced by the change |
| 13:22.09 | LaoLang_cool | is cssu focus on introducing more features, not on improvment and bugfix? |
| 13:22.54 | DocScrutinizer05 | LaoLang_cool: nope |
| 13:23.23 | DocScrutinizer05 | focus is on LongTermsupport |
| 13:23.29 | DocScrutinizer05 | LTS |
| 13:23.47 | LaoLang_cool | thanks, got it |
| 13:23.57 | amiconn | That's true, but there's another point: If you allow for components getting too much outdated, you will lose support from upstream, meaning you're on your own when it comes to fixing security issues or similar |
| 13:24.50 | DocScrutinizer05 | well, while that's true, it's actually the case already for our kernel since the day first N900 shipped |
| 13:24.53 | amiconn | Even debian sta(b)le now recommends upgrading firefox (iceweasel) from 3.5.x to 10.0.x lts through -backports |
| 13:25.43 | DocScrutinizer05 | well, iceweasel won't break your whole system when an unforeseen new bug appears |
| 13:25.51 | DocScrutinizer05 | kernel does |
| 13:25.55 | DocScrutinizer05 | toolchain does |
| 13:26.15 | amiconn | I know the kernel is ooold... |
| 13:26.28 | DocScrutinizer05 | and CSSU constantly updates subsystems of minor system relevance, like modest etc |
| 13:26.47 | amiconn | New toolchain won't break stuff not compiled using that one. |
| 13:27.00 | DocScrutinizer05 | the risk/benefit eqation looks different for modest than it does for kernel patches |
| 13:27.06 | amiconn | sure |
| 13:28.14 | amiconn | I.e. you could introduce a new toolchain and only use it for less important userland stuff. Then gradually extend its use if you didn't find issues |
| 13:29.05 | DocScrutinizer05 | and particularly any bug in modest will get atrributed to modest quite naturally, while foundation subsystems like glibc or kernel or dbus will introduce bugs (if they introduce a bug, nobody can deny the possibility they will when patched) that *nobody* is able to atrribute to the correct patch instantly |
| 13:29.27 | amiconn | The problem with community drien development is that you don't have a dedicated test center, so you have no other choice than letting the users test changes. Of course the first users going to test stuff should be experienced users, willing to take the risks |
| 13:30.34 | amiconn | But this group must be large enough to get proper results. I know that this problem might be hard to solve (from rockbox development) |
| 13:30.40 | DocScrutinizer05 | the problem is that users usually have no clue how to test |
| 13:32.03 | DocScrutinizer05 | I.E. you use special test tools to test some new patch, like observing CPU load, mem-usage (for memleaks), power consumption etc. Usually users don't even know how to use those tools, they often don't even know of their existence |
| 13:33.05 | kerio | DocScrutinizer05: otoh stuff like glibc has quite the testing already done, upstream |
| 13:33.36 | amiconn | kerio: Upstream certainly didn't test in a maemo environment |
| 13:34.21 | amiconn | DocScrutinizer05: Then it might be necessary to provide special test executables, complete with instructions how to use them. |
| 13:35.53 | DocScrutinizer05 | kerio: upstream testing is basically useless for N900, since we are not on an upstream system |
| 13:36.03 | DocScrutinizer05 | testing by users: http://xkcd.com/937/ |
| 13:36.05 | amiconn | Not sure whether this method works well for a system as complex as maemo5; I did something like this years ago when trying to verify whether an issue with an ATA driver optimisation had been resolved. |
| 13:36.31 | DocScrutinizer05 | amiconn: (special test binaries needed) indeed |
| 13:40.24 | DocScrutinizer05 | http://xkcd.com/937/ the hover text: >>the bug report was marked 'could not reproduce'." |
| 13:40.55 | DocScrutinizer05 | that's basically exactly the situation we're facing here |
| 13:49.24 | DocScrutinizer05 | it's particularly this property of patches to foundation systems like kernel, libs, IPC etc - you can't tell who caused that mega fsckup you just ran into - that makes a lot of users extremely cautious when it comes to somebody messing with "their" kernel or other system stuff. While same users happily accept some hackers messing with modest or desktop orientation, as the user is experienced enough to handle any bad situation |
| 13:49.26 | DocScrutinizer05 | arising from such patches shipped to his device |
| 13:55.07 | DocScrutinizer05 | so while concept of LTS allows moderate and carefully selected updates to particular apps or lower importance auxiliary subsystems like ke-recv, it clearly rules out major kernel upgrades just for the mere inclusion of leete stuff |
| 13:56.07 | DocScrutinizer05 | any additional patch is an additional risk. Users don't want to take that risk with CSSU, if they want to take it they install KP51 |
| 13:57.40 | DocScrutinizer05 | from CSSU users expect bugFIXES for bugs they actually might suffer from in a way that reduces the stability and thus reliability of their device |
| 13:57.49 | DocScrutinizer05 | that's what LTS is all about |
| 13:58.37 | DocScrutinizer05 | for a more leete mailer app they will visit extras(-devel) and get one meeting their taste |
| 14:00.04 | DocScrutinizer05 | if there's a severe bug in stock modest, like e.g. deleting mails from server despite the "don't delete2 option in modest got tagged, users expect CSSU to ship a fix for that |
| 14:00.21 | *** join/#maemo-ssu javispedro (~javier@Maemo/community/contributor/javispedro) |
| 14:00.27 | DocScrutinizer05 | s/ete2/ete"/ |
| 14:02.03 | amiconn | There's one problem with this approach though: you're effectively splitting user bases, meaning that each flavour will see less testing |
| 14:03.10 | DocScrutinizer05 | well, that's kinda true, but then otoh any user testing isn't exactly helping to reduce workload of patch review by peers |
| 14:03.22 | amiconn | Combined with the fact that there is no new maemo5 device, and hence the user base is shrinking over time anyway (*at least* due to devices breaking) |
| 14:04.17 | DocScrutinizer05 | and you of course can migrate a patch tested in environment A by several users, to environment B which still is a test environment but used by another group of users, where it will see further 'testing' |
| 14:04.20 | amiconn | As I said, a model like devel->testing->stable is needed, combined with proper bug handling (and closing as invalid with "cannot reproduce" isn't) |
| 14:04.41 | kerio | yeah but -experimental is different |
| 14:04.57 | kerio | think of cssu-thumb |
| 14:05.02 | DocScrutinizer05 | actually stable is different |
| 14:05.04 | amiconn | And probably test binaries (maybe scripts running the tests and uploading the results) |
| 14:05.11 | kerio | stuff there may never reach cssu-stable |
| 14:05.22 | DocScrutinizer05 | yep |
| 14:05.28 | kerio | devel->testing->stable is a pipeline where stuff is eventually either passed on or removed |
| 14:05.35 | DocScrutinizer05 | it never been meant to reach stable |
| 14:06.07 | DocScrutinizer05 | so for now our cssu-devel in fact is experimental |
| 14:06.32 | kerio | i would start using it, but it would break -thumb :( |
| 14:06.45 | kerio | although i think that freemangordon is recompiling a bunch of stuff for -thumb, so it's at least close |
| 14:06.57 | kerio | (-thumb got the modest/tinymail updates) |
| 14:07.11 | amiconn | Imo everything that's developed in -devel and is not ditched (because of main developer vanishing or getting it to work reliably at all) should reach -stable at some point, otherwise it's useless |
| 14:07.30 | amiconn | s/or getting/or not getting/ |
| 14:07.42 | DocScrutinizer05 | well, if that thumb stuff is sane, it will allow any arbitrary ARM (== non-thumb-compiled) app to run without any probelms |
| 14:07.58 | kerio | DocScrutinizer05: yeah but fastness! |
| 14:08.05 | kerio | :3 |
| 14:08.27 | kerio | i think that cssu-thumb is supposed to be somewhat aligned to cssu-testing |
| 14:08.46 | amiconn | is running KP for many months now, and wouldn't go back to stock kernel |
| 14:09.04 | kerio | amiconn: yeah but KP and the other "l33t" things require time |
| 14:09.14 | kerio | a lot of people don't care about their phone that much |
| 14:09.16 | *** join/#maemo-ssu DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 14:09.25 | *** join/#maemo-ssu DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 14:09.35 | DocScrutinizer05 | and no way fastness is a valid entry ticket to CSSU-S(-LTS) |
| 14:09.37 | kerio | by "require time" i mean that they require a bit of manual effort |
| 14:09.41 | jonwil | My view on this is that the new kernel (not KP, something more conservative with only patches that are of genuine benefit), new libc and new toolchain support should all go into cssu-devel with a view to being moved through to -testing and -stable at some point in the future |
| 14:09.54 | DocScrutinizer05 | sorry, [2012-08-04 16:08:04] <kerio> :3 been last inbound here (disconnect) |
| 14:10.17 | kerio | pastebinning |
| 14:10.31 | kerio | http://fpaste.org/e7Qs/ |
| 14:10.41 | kerio | ...hey, you can just look at the logs! |
| 14:10.43 | amiconn | jonwil: The question is how to select those |
| 14:11.07 | DocScrutinizer05 | thnx |
| 14:11.08 | jonwil | if it fixes a kernel bug its a good patch |
| 14:11.11 | jonwil | generally |
| 14:11.43 | DocScrutinizer05 | yes, if we can prove the bug bites our N900-ass |
| 14:12.00 | jonwil | if it fixes a userspace bug, its also a good candidate |
| 14:12.15 | amiconn | For me the 3 main benefits of KP are: (1) IPv6 support. (2) Reduced battery consumption, due to voltage profiles and smart reflex. (3) Overclocking. I do know that the last one is questionable for general deployment... |
| 14:12.23 | DocScrutinizer05 | that's why I agreed we now need a CSSU kernel, if there's no other way to fix that pselect(9 mess |
| 14:12.50 | jonwil | can anyone remember who is doing the BME replacement work? |
| 14:12.55 | jonwil | I think it was Pali although I cant be sure |
| 14:13.07 | DocScrutinizer05 | yes, userland bugfixes are not as probelmatic as kernel generic or kernel-domain fixes |
| 14:13.19 | DocScrutinizer05 | or fixes to foundation subsystems in general |
| 14:13.27 | jonwil | what I meant was kernel changes that fix userspace issues somehow |
| 14:13.35 | jonwil | such as the kernel fixes that fix pselect() |
| 14:14.07 | DocScrutinizer05 | jonwil: bme kernel replacement: pali |
| 14:14.11 | jonwil | ok |
| 14:14.19 | DocScrutinizer05 | jonwil: hald-addon-bme et al: fmg |
| 14:15.22 | jonwil | I think that overclocking, USB-host-mode, IPv6 are not candidates for a CSSU kernel |
| 14:15.52 | jonwil | The reduced battery consumption is though IMO because reduced battery consumption is something all n900 owners will like and be interested in |
| 14:15.54 | DocScrutinizer05 | amiconn: SR and voltage are highly controversy as well, regarding stability and general sanity for all hw platforms they had to run on |
| 14:16.28 | jonwil | although it depends on how risky the power management changes in question actually are |
| 14:16.40 | amiconn | Well the idea of SR is that it auto-regulates, so it should work everywhere. You're right regarding voltage profiles of course |
| 14:17.30 | DocScrutinizer05 | amiconn: there's been some whisper info from Nokia that SR is broken on a hw level and that's why it wasn't enabled first instance |
| 14:17.46 | amiconn | did actually have issues due to a too low voltage profile himself |
| 14:17.48 | kerio | wouldn't there be an official errata from TI? |
| 14:18.00 | kerio | amiconn: the "starving" profile or something silly like that? |
| 14:18.11 | DocScrutinizer05 | kerio: not if the borkage is in N900 specific design |
| 14:18.22 | kerio | like what? |
| 14:18.26 | amiconn | No, "starving" and even "ideal" don't work at all for me |
| 14:18.47 | DocScrutinizer05 | like a too long too thin trace, a missing or too small or crappy buffer capacitor, or whatever else |
| 14:18.52 | *** join/#maemo-ssu LaoLang_coo_ (~LaoLang_c@221.226.175.139) |
| 14:19.27 | amiconn | On my N900 "ulv" has the CPU working stable, but the DSP crashes, meaning that apps using the dsp (blessn900/ abc, media players, ...) crash |
| 14:20.12 | DocScrutinizer05 | and this might apply to some hw-rev only. Now if we *knew* about details, we could safely recommend to enable SR on the hw-rev devices that aren't affected |
| 14:20.12 | amiconn | With "lv" it's working fine, including SR enabled and overclocked to 805 MHz |
| 14:20.58 | DocScrutinizer05 | for obvious reasons Nokia doesn't like to spread the news that some hw-revs have a 'bug' that others don't |
| 14:21.41 | DocScrutinizer05 | and for same obvious reasons they never implemented a selective SR enabler in their PR |
| 14:22.07 | RST38h | This is not subject of a hw bug |
| 14:22.21 | RST38h | The CPU is rated for a certain voltage range |
| 14:22.29 | DocScrutinizer05 | and I still fail to find a single decent scientific review on how much savings SR will aearn you |
| 14:22.40 | RST38h | If you go outside the range, TI does not guarantee reliable operaion, that is all |
| 14:22.52 | DocScrutinizer05 | RST38h: we're talking about SR |
| 14:23.08 | DocScrutinizer05 | and why it's disabled on fremantle/N900 |
| 14:23.14 | RST38h | That "reflex" mode? |
| 14:23.16 | DocScrutinizer05 | yep |
| 14:23.30 | RST38h | It does not work on the CPUs used in N900 |
| 14:23.42 | DocScrutinizer05 | the 'definitive' answer from Nokia been "it's not stable" afaik |
| 14:23.49 | RST38h | That is non-official word from several independent Nokia engineers, quoting TI |
| 14:23.51 | kerio | "does not work" how? |
| 14:23.52 | amiconn | DocScrutinizer05: It could also just be part of the "fire and forget" attiude that many manufacturers have. You don't like the performance of your device? Buy the successor.... |
| 14:24.10 | RST38h | No, it does not work properly. That is how they go those chips from TI. Nokia has nothign to do with it. |
| 14:24.19 | RST38h | s/go/got |
| 14:24.29 | DocScrutinizer05 | btw there are quite usually SiErr that are NOT published to the unwashed masses by TI |
| 14:24.44 | RST38h | kerio:"Does not work" as in "leads to unpredictable operation" |
| 14:24.45 | kerio | meaning that it offers no benefits whatsoever or that it causes problems? |
| 14:24.45 | kerio | i see |
| 14:24.56 | RST38h | kerio: would you like me to explain what "unpredictable operation" means? |
| 14:25.02 | DocScrutinizer05 | like the general lack of reliability of IRQ-wakes from powerless sleep in OMAP4 |
| 14:25.40 | RST38h | Doc: Of course there are erratas, usually specific to each stepping of the chip production |
| 14:26.08 | DocScrutinizer05 | yep |
| 14:26.42 | DocScrutinizer05 | for OMAP4 IRQ from powerless though, TI says they will fix it in OMAP5 ;-P |
| 14:28.08 | DocScrutinizer05 | I don't know details, since all this is toilet talk, we just see the efforts to work around it, in our change requests from customers |
| 14:28.50 | DocScrutinizer05 | like "please assert the IRQ repeatedly for 20s" |
| 14:29.25 | *** join/#maemo-ssu mase76 (~mase76@p5DD3971E.dip.t-dialin.net) |
| 14:30.21 | DocScrutinizer05 | might be a certain mask stepping of OMAP4 or whatever. No details, as far as i'm concerned I might as well have dreamt all this |
| 14:30.30 | DocScrutinizer05 | or just made it up |
| 14:31.04 | DocScrutinizer05 | you dunno what's this deal with SR in 'our' OMAP3 |
| 14:31.26 | DocScrutinizer05 | you just know Nokia thought it's not safe to enable it |
| 14:31.33 | DocScrutinizer05 | so why do you think it is? |
| 14:31.47 | kerio | because elop hates open source! |
| 14:31.53 | kerio | or maybe because they wanted to be safe |
| 14:32.06 | DocScrutinizer05 | so do 'we', here in CSSU |
| 14:32.11 | amiconn | Or had not enough time to test it |
| 14:32.13 | kerio | uncertain benefits, uncertain stability depending on revision and whatnot |
| 14:32.22 | kerio | uses SR with no problems so far |
| 14:32.42 | DocScrutinizer05 | that's up to you, kerio. nobody will blame you for |
| 14:33.05 | DocScrutinizer05 | but it's not up to CSSU to feed SR-enabled to *everybody* based on that |
| 14:33.29 | DocScrutinizer05 | get my point? |
| 14:33.57 | kerio | oh absolutely |
| 14:34.09 | kerio | to be fair, though, SR is disabled by default with kernel power |
| 14:34.30 | kerio | you have to manually load the "default" settings and/or set them as default to make them actually enabled |
| 14:35.34 | DocScrutinizer05 | so we could consider this particular patch "reviewed for CSSU kernel" if that's actually true and patch doesn't sho any other implications that might introduce new behaviour vs stock kernel |
| 14:35.53 | DocScrutinizer05 | another how many? 89? remaining... |
| 14:37.12 | DocScrutinizer05 | CSSU kernel should be based on stock kernel, with *only* the patch for pselect() applied (plus maybe one or two other patches to fix severe bugs that also need to get reviewed, evaluated, tested and signed off before) |
| 14:38.03 | DocScrutinizer05 | no hostmode or IPv6 or whatever patches have a place in CSSU kernel |
| 14:38.20 | DocScrutinizer05 | there's KP for that |
| 14:40.13 | DocScrutinizer05 | (well, IPv6 *might* eventually advance to status 'mandatory' if it turns out carriers switching to IPv6 makes our CSSU based device break) |
| 14:42.02 | amiconn | Sure, hostmode and the ton of additionally supported filesystems are not necessary for cssu kernel |
| 14:42.15 | amiconn | IPv6 is mandatory nowadays imho |
| 14:43.56 | kerio | ipv6 needs a ton of changes in maemo applications, though |
| 14:43.57 | kerio | doesn't it? |
| 14:44.27 | amiconn | Well it might, but that's another reason for enabling it at the kernel level now |
| 14:44.49 | amiconn | This way application developers have more time to fix the apps |
| 14:45.28 | amiconn | And enabling IPv6 won't affect apps not using it, so it should be safe |
| 14:47.27 | kerio | hmm, the garage page says something about ipv6 requiring two APNs and two pdp contexts |
| 14:47.31 | kerio | why is that? |
| 14:48.34 | kerio | also i'm a bit worried about smartreflex now :c |
| 14:48.52 | DocScrutinizer05 | amiconn: I tend to agree, more than argue |
| 14:49.56 | DocScrutinizer05 | we should evaluate the impact of enabling IPv6, the risk it brings, and that there's actually nothing changing for apps not using it. Then test it and eventually include to CSSU kernel |
| 14:50.18 | kerio | still has no ipv6 in his home network |
| 14:50.22 | kerio | i feel like a noob :c |
| 14:50.50 | BCMM | my damn router doesn't do it as far as i can tell |
| 14:51.00 | DocScrutinizer05 | mine neither |
| 14:51.22 | kerio | i should really build a proper openwrt system and start using 6to4 at least |
| 14:51.47 | BCMM | i'm sure you can still buy v4-only routers, post-exhaustion, which is totally messed up |
| 14:51.57 | DocScrutinizer05 | kerio: (2 APN) probably because IPv6 and IPv4 are not compatible on same media channel |
| 14:52.01 | BCMM | kerio: yeah, i need to find out how to get one of those cheaply |
| 14:52.25 | kerio | DocScrutinizer05: yeah but ipv6 is backwards-compatible, isn't it |
| 14:52.38 | DocScrutinizer05 | nope, not afaik |
| 14:53.10 | DocScrutinizer05 | if it was, then I'd not know why you'd need two APN |
| 14:53.13 | kerio | hm, wasn't there a special address class that encompasses the whole of ipv4? |
| 14:53.18 | kerio | maybe i'm thinking of something else |
| 14:53.21 | kerio | perhaps 6to4 |
| 14:53.36 | DocScrutinizer05 | 6to4 is a tunneling protocol basically |
| 14:53.41 | DocScrutinizer05 | afaik |
| 14:54.00 | kerio | the bestest tunneling is teredo, anyway |
| 14:54.14 | BCMM | there's no way to contact a v4-only host if you don't have a v4 address or NAT, basically |
| 14:54.31 | DocScrutinizer05 | if it actually is you wrap your ipv4 packets into a ipv6 wrapper and send it via ipv6 to a 'gateway' |
| 14:54.34 | BCMM | because how would the host get packets back to you if it doesn't know about v6 addresses? |
| 14:54.54 | kerio | you'd need a 4to6 gateway, yeah |
| 14:59.15 | *** join/#maemo-ssu taziff (~Taziff@cyr108.internetdsl.tpnet.pl) |
| 15:20.03 | *** join/#maemo-ssu M4rtinK (~M4rtinK@mail.melf.eu) |
| 15:27.02 | *** join/#maemo-ssu mase76 (~mase76@p5DD3971E.dip.t-dialin.net) |
| 15:40.32 | *** join/#maemo-ssu mase76 (~mase76@p5DD3971E.dip.t-dialin.net) |
| 15:44.19 | *** join/#maemo-ssu taziff1 (~Taziff@cyr108.internetdsl.tpnet.pl) |
| 16:00.07 | DocScrutinizer05 | javispedro: could you please read the (yeah lengthy) chanlog of 2 days ago, and post your take on CSSU-(LT)S vs CSSU-bleeding-edge-experimental here? |
| 16:00.53 | javispedro | already read part of it |
| 16:01.04 | javispedro | don't really want to enter the discussion |
| 16:01.41 | DocScrutinizer05 | http://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2012-08-02.log.html#t2012-08-02T20:58:59 |
| 16:01.43 | DocScrutinizer05 | ff |
| 16:02.09 | DocScrutinizer05 | Jaffa: what's about you? |
| 16:02.33 | DocScrutinizer05 | generalantilles even missing |
| 16:04.40 | DocScrutinizer05 | it seems to me in this discussion the "old farts" (aka those who once 'invented' CSSU) been severely under-represented |
| 16:05.49 | DocScrutinizer05 | and I'm not sure this happened coincidental |
| 16:06.03 | kerio | well, who called that discussion? |
| 16:06.12 | DocScrutinizer05 | NFC actually |
| 16:06.28 | kerio | and who's got commit access to the repos? |
| 16:07.22 | DocScrutinizer05 | http://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2012-08-02.log.html#t2012-08-02T21:08:06 |
| 16:09.00 | DocScrutinizer05 | the ones that the original project managers included to the respective garage project group, as developers |
| 16:09.52 | javispedro | in any case I suspect that the problem is developer-starvation |
| 16:10.12 | *** join/#maemo-ssu arcean (~arcean@aact183.neoplus.adsl.tpnet.pl) |
| 16:10.31 | javispedro | and when that happens you get that devs want to do what pleases them most instead of the boring tasks ;P |
| 16:10.43 | DocScrutinizer05 | https://garage.maemo.org/projects/cssu/ defines https://garage.maemo.org/projects/cssu-testing/ and https://garage.maemo.org/projects/cssu-stable/ |
| 16:12.19 | DocScrutinizer05 | javispedro: in that case it's outright rogue and dishonest to claim CSSU needs to change, just to "hijack" manpower for a bleeding-edge project that some guys want to drive here |
| 16:13.14 | DocScrutinizer05 | you don't hijack and redefine a project, to shanghai the devels |
| 16:13.44 | DocScrutinizer05 | that's what industry does sometimes. In FOSS though that should get banned publicly |
| 16:14.17 | DocScrutinizer05 | s/banned/bashed/. |
| 16:19.49 | *** join/#maemo-ssu zeq (~s_j_newbu@178.110.126.62) |
| 16:28.39 | *** join/#maemo-ssu mase76 (~mase76@p5DD3971E.dip.t-dialin.net) |
| 16:49.03 | *** join/#maemo-ssu BCMM (~ben@unaffiliated/bcmm) |
| 17:26.19 | DocScrutinizer05 | where's the binary now to check that pselect() fsckup on stock kernel? I definitely wanna see that myself, before I continue to support any cssu kernel fixing it |
| 17:26.53 | DocScrutinizer05 | did somebody provide a link yesterday? |
| 17:28.07 | DocScrutinizer05 | also of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/319729/comments/23 attached own-wrapper test code please |
| 17:31.11 | merlin1991 | DocScrutinizer05: quite a rant you wrote whilst I did other stuff :D |
| 17:31.30 | DocScrutinizer05 | yeah, felt like it's needed |
| 17:31.56 | merlin1991 | But my stance re pk / whanot is still as before meeting, I'll want a stock kernel + patches for stable |
| 17:32.07 | DocScrutinizer05 | good |
| 17:32.21 | DocScrutinizer05 | thought they mugged you |
| 17:33.29 | DocScrutinizer05 | could you kindly provide testcode as in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/319729/comments/23 and https://bugs.launchpad.net/ubuntu/+source/linux/+bug/319729/comments/6 |
| 17:34.00 | DocScrutinizer05 | both flavours each (simmulation and real pselect) |
| 17:34.13 | merlin1991 | I have the arm build on my device (which is in vienna), but I can give you the build when I come back |
| 17:34.20 | merlin1991 | also we have no real pselect on our stock kernel |
| 17:34.25 | DocScrutinizer05 | fine with me |
| 17:34.48 | merlin1991 | that's the whole reason for the patch, on maemo pselect is always simulated |
| 17:34.54 | DocScrutinizer05 | sure thing, the missing pselect() in kernel is what we wanna test, after all |
| 17:35.29 | merlin1991 | freemangordon said he managed to crash the sample code by running ham additionall to get some system load |
| 17:35.43 | DocScrutinizer05 | I'll run a decent set of tests and post the results, since obviously nobody else will do |
| 17:36.17 | merlin1991 | hm I do have my sb with me, the build should be on there |
| 17:36.20 | merlin1991 | reboots |
| 17:40.23 | DocScrutinizer05 | merlin1991: how much of a version hell will we face with all the kernel-flavours like uBoot images and whatnot? with that cssu kernel? |
| 17:41.28 | DocScrutinizer05 | aiui we got 3 different falvours for each kernel now: plain NAND, NAND_with_uBoot, uBoot/multiboot image file |
| 17:41.33 | merlin1991 | well uboot and multiboot will have to be reflashed in case we deploy the cssu kernel |
| 17:41.58 | merlin1991 | and we need to put a big fat warning, because any kernel without pselect will foobar libc |
| 17:42.33 | DocScrutinizer05 | ooh wait, til now each uBoot came bumdled with stock kernel, this is the first kernel that would replace stock kernel attached to uBoot code in NAND, right? |
| 17:43.36 | merlin1991 | nah each uboot came bundled with different kernel |
| 17:43.39 | DocScrutinizer05 | and AIUI we should even roll a new FIACO? |
| 17:43.55 | merlin1991 | nope we don't need to roll a new Fiasco (we can't) |
| 17:43.56 | DocScrutinizer05 | merlin1991: are you sure about that? |
| 17:44.12 | DocScrutinizer05 | (new kernel with each uBoot) |
| 17:44.17 | merlin1991 | DocScrutinizer05: yes, uboot-pr1.3 had stock kernel bundeled uboot-power has pk bundled ... |
| 17:44.32 | DocScrutinizer05 | mhm |
| 17:44.33 | merlin1991 | multiboot is again another story |
| 17:44.43 | merlin1991 | and we overwrite anything in the flash area with our kernel |
| 17:44.51 | DocScrutinizer05 | sure |
| 17:45.00 | merlin1991 | DocScrutinizer05: http://cdnm.at/~christian/maemo/childspin |
| 17:45.06 | DocScrutinizer05 | thanks |
| 17:45.12 | *** join/#maemo-ssu jon_y (~enforcer@swz-175-163.tm.net.my) |
| 17:46.21 | merlin1991 | but we should put a zimage up somewhere so people can recover their n900 with `flasher-3.5 -f -k pathtozimage` if they flashed a non pselect kernel |
| 17:47.15 | DocScrutinizer05 | running |
| 17:47.28 | merlin1991 | you need to put some load on the system for the race condition to happen |
| 17:47.31 | DocScrutinizer05 | :nod: |
| 17:47.35 | merlin1991 | ham should be perfect for that :D |
| 17:47.46 | DocScrutinizer05 | I don't see such requirement |
| 17:48.12 | merlin1991 | well the requirement is that you get a signal between those 3 calls to simulate pselect |
| 17:48.14 | DocScrutinizer05 | anyway ssh over wlan should be hellufalot of enough load |
| 17:48.28 | merlin1991 | which you'll only get if the 3 steps are interrupted |
| 17:48.36 | merlin1991 | which in turn only happens on heavy system load |
| 17:48.50 | DocScrutinizer05 | :shrug: |
| 17:48.59 | DocScrutinizer05 | might be worth a shot, yeah |
| 17:49.23 | merlin1991 | other than that you can ofc let it run for ages and see if it stops at some point (shouldn't stop ever) |
| 17:50.08 | merlin1991 | dang, when I packed my stuff in vienna I was wondering wether to take the 2 n900s with -t and -s or not, seems I made the wrong decision :D |
| 17:53.46 | DocScrutinizer05 | renice -5; i=1; while true; do echo $(( i++ )); done |
| 17:53.54 | DocScrutinizer05 | renice -10; top |
| 17:54.20 | DocScrutinizer05 | should do, I see the jitter in "........................................." |
| 17:54.24 | DocScrutinizer05 | still running |
| 17:55.12 | DocScrutinizer05 | CPU: 28.4% usr 63.2% sys 0.0% nice 0.0% idle 0.0% io 0.5% irq 7.7% softirq |
| 17:55.47 | DocScrutinizer05 | hell, I could actually start HAM as well |
| 17:55.54 | DocScrutinizer05 | :shrug: |
| 17:57.35 | DocScrutinizer05 | CPU: 26.0% usr 63.0% sys 3.3% nice 0.0% idle 0.0% io 1.3% irq 6.2% softirq |
| 17:57.50 | DocScrutinizer05 | hmm, this HAM thing didn't do much? |
| 17:58.33 | kerio | open modest! |
| 17:58.46 | DocScrutinizer05 | 15685 15263 root R 780 0.3 18.2 -sh |
| 17:58.47 | DocScrutinizer05 | <PROTECTED> |
| 17:58.49 | DocScrutinizer05 | 15263 709 root R 1756 0.7 11.7 sshd: root@pts/2 |
| 17:58.50 | DocScrutinizer05 | 18448 17964 root R N 6188 2.5 10.3 /usr/libexec/apt-worker.real backend /tmp/apt-worker.to /tmp/apt-worker.from /tmp/apt-worker.status /tmp/apt-worker.cancel B |
| 17:59.46 | DocScrutinizer05 | . |
| 17:59.48 | DocScrutinizer05 | . |
| 17:59.51 | DocScrutinizer05 | <PROTECTED> |
| 17:59.52 | DocScrutinizer05 | 15685 15263 root R 776 0.3 17.0 -sh |
| 17:59.54 | DocScrutinizer05 | 18448 17964 root R N 6996 2.8 14.9 /usr/libexec/apt-worker.real backend /tmp/apt-worker.to /tmp/apt-worker.from /tmp/apt-worker.status /tmp/apt-worker.cancel B |
| 17:59.55 | DocScrutinizer05 | 15263 709 root S 1724 0.7 14.7 sshd: root@pts/2 |
| 17:59.57 | DocScrutinizer05 | <PROTECTED> |
| 17:59.58 | kerio | mispaste? |
| 18:00.30 | DocScrutinizer05 | indeed, I should prolly kick myself |
| 18:00.40 | kerio | no! don't do it! |
| 18:00.44 | DocScrutinizer05 | anyway, still running |
| 18:02.01 | DocScrutinizer05 | I'll start a second childspin on device xterm, so no overhead for WLAN ssh |
| 18:02.38 | kerio | you spin me right round baby right round like a record baby right round round round |
| 18:04.05 | DocScrutinizer05 | 2 childspin running |
| 18:04.24 | DocScrutinizer05 | CPU: 40.0% usr 54.8% sys 0.0% nice 0.0% idle 0.0% io 0.1% irq 4.8% softirq |
| 18:05.28 | DocScrutinizer05 | twiddles thumbs |
| 18:05.49 | kerio | no, the thumb bug is a different one! |
| 18:05.51 | DocScrutinizer05 | well, newsflash time |
| 18:08.06 | merlin1991 | ... |
| 18:08.50 | DocScrutinizer05 | 20906 3700 root R 288 0.1 3.7 ./childspin |
| 18:08.52 | DocScrutinizer05 | <PROTECTED> |
| 18:09.06 | merlin1991 | R / S meaning? |
| 18:09.20 | merlin1991 | running and suspended? |
| 18:09.52 | merlin1991 | shouldn't that be R and R? |
| 18:09.58 | merlin1991 | (if the bug does not exist) |
| 18:10.59 | merlin1991 | ah wait 1 core can only be R? |
| 18:15.25 | DocScrutinizer05 | <PROTECTED> |
| 18:15.27 | DocScrutinizer05 | 20:15 4138 97 97 -44 1115 1115 1115 65535 1506 49 NOACT:0 IMIN:0 CI:1 CALIP:0 VDQ:1 EDV1:0 EDVF:0 |
| 18:15.56 | DocScrutinizer05 | there's always only one R iirc |
| 18:16.32 | DocScrutinizer05 | actually nope |
| 18:17.04 | DocScrutinizer05 | the childspin only is R if it doesn't just wait on pselect() |
| 18:18.29 | RST38h | Hey, Doc, rumors say someone got hardware audio filter work on N900? |
| 18:18.46 | RST38h | Will that kernel patch be in CSSU, with software filter disabled? =) |
| 18:24.09 | DocScrutinizer05 | rumors say i'm running two childspin since hours, happily |
| 18:25.23 | DocScrutinizer05 | <PROTECTED> |
| 18:25.24 | DocScrutinizer05 | 20906 root 20 0 S - - - 0:44.24 3.0 0.1 ./childspin |
| 18:26.48 | DocScrutinizer05 | while the renice -5; i=1; while true; do echo $(( i++ )); done is at 2500000 meanwhile |
| 18:27.21 | DocScrutinizer05 | merlin1991: I'm sorry, but.... |
| 18:27.54 | DocScrutinizer05 | merlin1991: please recheck your source of childspin |
| 18:28.50 | DocScrutinizer05 | HAAAAHAAAAHAAAAAAAAAAAAAAAAAAA it hanfgs |
| 18:28.58 | DocScrutinizer05 | hangs |
| 18:30.15 | DocScrutinizer05 | <PROTECTED> |
| 18:32.38 | DocScrutinizer05 | ~ # strace -p 3956 |
| 18:32.40 | DocScrutinizer05 | Process 3956 attached - interrupt to quit |
| 18:32.44 | DocScrutinizer05 | select(0, NULL, NULL, NULL, NULL |
| 18:35.27 | DocScrutinizer05 | while... (SPAM!) |
| 18:35.33 | DocScrutinizer05 | clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x4001cc38) = 30839 |
| 18:35.34 | DocScrutinizer05 | rt_sigprocmask(SIG_SETMASK, [], [CHLD], 8) = 0 |
| 18:35.36 | DocScrutinizer05 | select(0, NULL, NULL, NULL, NULL) = ? ERESTARTNOHAND (To be restarted) |
| 18:35.37 | DocScrutinizer05 | --- SIGCHLD (Child exited) @ 0 (0) --- |
| 18:35.39 | DocScrutinizer05 | sigreturn() = ? (mask now [QUIT ILL TRAP ABRT BUS KILL PIPE CHLD CONT STOP TSTP URG XCPU VTALRM PROF WINCH IO PWR RTMIN]) |
| 18:35.40 | DocScrutinizer05 | rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 |
| 18:35.42 | DocScrutinizer05 | wait4(30839, NULL, 0, NULL) = 30839 |
| 18:35.44 | DocScrutinizer05 | write(1, ".", 1) = 1 |
| 18:35.58 | DocScrutinizer05 | . |
| 18:36.12 | DocScrutinizer05 | on the other still running spinchild |
| 18:37.38 | DocScrutinizer05 | merlin1991: ok, confirmed. we (very rarely) see that bug |
| 18:38.37 | DocScrutinizer05 | it's however impossible to say how much impact it has in real life - not that this would matter |
| 18:39.43 | DocScrutinizer05 | given the amount of dbus transactions going on all the time, one occurance per lifetime is minimum I'd expect to see. That's enough to get it fixed |
| 18:40.32 | DocScrutinizer05 | I'll eventually summ up the results and post to ML, if I can find a thread to attach it to |
| 18:42.42 | jon_y | wow, my irc buffer |
| 18:43.14 | jon_y | some soccer mom is going to have a rampage if she sees spin, child, kill in the same sentence :) |
| 18:45.31 | DocScrutinizer05 | merlin1991: could you please build and provide spinchild-sim? with -DUSE_SELECT |
| 18:47.59 | DocScrutinizer05 | (we (very rarely) see that bug) I'm actually disappointed it happens so rarely, since this reduces hope for a massive reliability increase from any fix |
| 18:49.01 | DocScrutinizer05 | otoh it explains how this bug could sneak in and hide all the time |
| 18:51.12 | DocScrutinizer05 | on a sidenote: 1029 user 15 -5 S - - - 1:07.01 0.0 0.7 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session |
| 18:52.03 | DocScrutinizer05 | CPU time of dbus daemon: 67s |
| 18:52.21 | DocScrutinizer05 | <PROTECTED> |
| 18:52.43 | DocScrutinizer05 | childspin hung after 171s CPU time |
| 18:54.25 | DocScrutinizer05 | (btw the other dbus daemon [for systembus] has just 20s more CPU time) |
| 18:54.37 | DocScrutinizer05 | FWIW |
| 18:55.18 | DocScrutinizer05 | Uptime: 2 days, 01:57:07 |
| 18:56.28 | DocScrutinizer05 | so, while this is of course complete handwaving and BS, you still could say dbus is likely to see one error on either system or user bus daemon during a few days of uptime |
| 18:57.02 | DocScrutinizer05 | when comparing it to CPU time spinchild needed to finally freeze |
| 19:02.55 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 19:09.53 | *** join/#maemo-ssu BCMM_ (~user@unaffiliated/bcmm) |
| 19:15.13 | *** join/#maemo-ssu freemangordon_ (~freemango@213.226.63.181) |
| 19:17.12 | freemangordon_ | doc, run childspin, run HAM, choose to edit the catalogs and rotate the device. hang happens as soon as HAM starts the rotation |
| 19:19.43 | freemangordon_ | that way you have both CPU and IO load and the bug is triggered in 90 percent of the tries, see logs from yesterday morning, sorry cannot provde link, I am writing from my n900 |
| 19:20.49 | DocScrutinizer05 | freemangordon_: well, it finally triggered here anyway, and I fail to see how we'd need IO load to trigger it |
| 19:22.03 | DocScrutinizer05 | aiui it's just about preemtion after the sigmask() before the select() |
| 19:22.39 | DocScrutinizer05 | for this preemption it should suffice to run other process with higher prio |
| 19:23.30 | DocScrutinizer05 | idly looks for state of on-device spinchild... |
| 19:23.41 | freemangordon_ | what I am saying, is that you assessment about how often we'll be hit by the bug, is a little bit low :-) |
| 19:24.29 | DocScrutinizer05 | 20906 root 20 0 S - - - 7:46.94 11.0 0.1 ./childspin |
| 19:24.46 | DocScrutinizer05 | 7min47 CPU |
| 19:24.52 | DocScrutinizer05 | running |
| 19:25.09 | freemangordon_ | a wild guess- media player widget could be the the one that suffers from that bug |
| 19:25.11 | DocScrutinizer05 | freemangordon_: I started HAM |
| 19:25.41 | freemangordon_ | it deffinitely misses dbus signals. thugh i might be speaking bullshit as well :-D |
| 19:25.52 | DocScrutinizer05 | freemangordon_: no portrait mode here, so rotating won't help ;-P |
| 19:26.20 | freemangordon_ | well, HAM should rotate anyway (if you are on testing) |
| 19:26.33 | DocScrutinizer05 | it doesn't |
| 19:26.34 | freemangordon_ | you could enable force rotation ;-) |
| 19:26.40 | DocScrutinizer05 | dafaq |
| 19:26.49 | DocScrutinizer05 | I enabled forbid-rotation |
| 19:27.22 | freemangordon_ | well, trust me on that then (tm) :-P |
| 19:27.26 | DocScrutinizer05 | mind you, we're trying to test this on a system as normal as possible |
| 19:28.04 | DocScrutinizer05 | don't give me ideas why CSSU has to bin portrait mode |
| 19:28.07 | DocScrutinizer05 | ;-P |
| 19:28.16 | freemangordon_ | naah :-D |
| 19:29.00 | DocScrutinizer05 | anyway, green light for minimalistic CSSU-kernel from my side |
| 19:29.35 | freemangordon_ | doc, meeting request was sent yesterday 7 am UTC to maemo-developers |
| 19:29.43 | DocScrutinizer05 | which other bugfix patches would we need to pull in to cssu kernel? |
| 19:29.56 | freemangordon_ | I really appologise I forgot you are on holiday |
| 19:30.21 | DocScrutinizer05 | I'm not on holiday, I'm simply not reading MLK on a regular basis |
| 19:30.25 | DocScrutinizer05 | ML* |
| 19:30.41 | freemangordon_ | seems you are not the only one ;-) |
| 19:31.25 | freemangordon_ | anyway, I am on holyday right now, will be back home tomorrow |
| 19:31.28 | DocScrutinizer05 | I got not enough hours in the day to read all my ML |
| 19:32.29 | DocScrutinizer05 | (green light) for pondering how to roll that |
| 19:32.46 | freemangordon_ | according to what was decided, we'll have to go through all the pathes in KP and evaluate what to be removed |
| 19:33.00 | DocScrutinizer05 | we still need to think carefully about any pitfalls we might face |
| 19:33.08 | freemangordon_ | sure |
| 19:33.11 | DocScrutinizer05 | with repos, conflicts, whatever |
| 19:33.45 | freemangordon_ | well, if we use "kernel", we'll have lots of problems solved |
| 19:33.59 | freemangordon_ | including KP uninstaller ;-) |
| 19:34.15 | freemangordon_ | thanks hxka, if you read that someday |
| 19:34.48 | DocScrutinizer05 | moves to TV again, for NCIS |
| 19:35.28 | freemangordon_ | anyway, i have to go back to my gf and friends, otherwise i'll have more serious troubles than any maemo stuff could bring me :-D |
| 19:35.56 | freemangordon_ | will be hanging around though |
| 19:44.20 | DocScrutinizer05 | CPU: 40.6% sy: 55.7% ni: 0.0% hi: 0.5% si: 3.1% wa: 0.0% 20906 root 20 0 S - - - 10:11.89 3.0 0.1 ./childspin |
| 19:48.36 | DocScrutinizer05 | anyway you see how difficult it might get to reproduce a well documented and understood bug |
| 19:49.12 | DocScrutinizer05 | how much worse might it get when it comes to thumb-SiErr, or SR borkedness |
| 19:50.03 | freemangordon_ | doc, it does not make sense to try to recreate race condition bug with only one active process |
| 19:56.01 | DocScrutinizer05 | there are 2 other processes active, at niceness -10 and -15 |
| 19:57.33 | DocScrutinizer05 | CPU: 40.6% sy: 55.7% |
| 19:58.30 | freemangordon_ | io deffinitely plays here, though i didn't think why |
| 20:00.14 | DocScrutinizer05 | while I rethink the effectiveness of my renice cmd |
| 20:02.26 | freemangordon_ | doc, do you have any app supporting portrait? |
| 20:04.09 | *** join/#maemo-ssu MrPingu (~MrPingu@86.92.226.97) |
| 20:05.13 | DocScrutinizer05 | portrait is locked on my device |
| 20:05.23 | DocScrutinizer05 | except for dialer ;-P |
| 20:06.15 | freemangordon_ | :-) |
| 20:11.46 | DocScrutinizer05 | cal me noob, my shellcmd fu is weak |
| 20:12.16 | DocScrutinizer05 | renice and even nice didn't work like expected, prollay thanks to fscking messybox |
| 20:13.07 | DocScrutinizer05 | finally renicing the endless loop to -15 instantly killed childspin (though no causality proven by one incidence) |
| 20:13.59 | DocScrutinizer05 | freemangordon_: ^^^ I bet you love to hear that |
| 20:15.03 | freemangordon_ | hmm, why rising prio should trigger the bug? well, child prosess also have the same prio, but so what? |
| 20:15.04 | DocScrutinizer05 | freemangordon_: (io deffinitely plays here, though i didn't think why) IO is scheduled at a way higher prio than your usual prio-0 userland processes |
| 20:15.34 | freemangordon_ | :nod: |
| 20:16.16 | DocScrutinizer05 | obviously all the CPU load in the world can't preempt a childspin on same niceness level |
| 20:16.46 | DocScrutinizer05 | a higher prio / lower niceness process does - immediately |
| 20:24.09 | freemangordon_ | well, i am glad you are convinced it is severe problem |
| 20:27.27 | DocScrutinizer05 | a bug in kernel is always a severe problem |
| 20:28.11 | DocScrutinizer05 | a severe problem requires honest investigation to completely understand the impact and risks |
| 20:29.10 | DocScrutinizer05 | only after completely understanding the problem, you can come up with the right solution |
| 20:29.33 | DocScrutinizer05 | which in this case seems to roll a patched kernel and lib |
| 20:29.49 | DocScrutinizer05 | ouch my grammar |
| 20:29.50 | freemangordon_ | :-) |
| 20:31.02 | DocScrutinizer05 | any other approach fails due to us once again not knowing where the bug may sleep, IOW which app out there might use pselect() |
| 20:31.27 | DocScrutinizer05 | so the alternative approach to fix all apps that are affected fails |
| 20:32.21 | DocScrutinizer05 | which leaves us with the only feasible solution to fix the root cause, however painful it might be from a maintenance POV |
| 20:35.39 | DocScrutinizer05 | when pondering impact of breaking some custom kernel modules (which shouldn't exist according to GPL anyway) versus fixing pselect() by a patched kernel for all the apps that may use pselect(), I clearly see the bettwer benefit ratio in the latter |
| 20:37.26 | DocScrutinizer05 | which is kinda of my iltimate ratio regarding this CSSU compatibility fsckup we're going to commit here |
| 20:38.11 | DocScrutinizer05 | ultimate even |
| 20:39.14 | DocScrutinizer05 | which doesn't mean we can go all loose now once we broke compatibility a tiny bit, and roll kernel-3.2 now |
| 20:39.22 | DocScrutinizer05 | neither PK51 |
| 20:40.31 | DocScrutinizer05 | while from a compatibility perspective it doesn't make any difference, from a risk management perspective our new cssu kernel has to be as low effort to verify as possible |
| 20:40.32 | freemangordon_ | hmm, 3.2 sounds nice :-P . too bad we don't have working adaptation :-D . |
| 20:40.35 | *** join/#maemo-ssu BCMM_ (~ben@unaffiliated/bcmm) |
| 20:40.52 | freemangordon_ | anyway, I gtg, night |
| 20:40.57 | *** part/#maemo-ssu freemangordon_ (~freemango@213.226.63.181) |
| 20:40.59 | DocScrutinizer05 | n8 freemangordon |
| 20:41.32 | jon_y | wait what, kernel-3.2 on the n900? |
| 20:45.27 | jon_y | DocScrutinizer05: possible? |
| 20:45.47 | DocScrutinizer05 | no |
| 20:45.58 | DocScrutinizer05 | at least not for maemo |
| 20:46.34 | jon_y | ok, too much patches to port forward? |
| 20:50.16 | DocScrutinizer05 | too much blobs not possible to port forward |
| 20:50.27 | DocScrutinizer05 | many* |
| 20:50.42 | jon_y | damn proprietary bits |
| 20:51.08 | jon_y | what about minor version bumps? |
| 20:51.17 | jon_y | eg to 2.6.3x |
| 20:55.36 | DocScrutinizer05 | this is handled by PK via backporting stuff |
| 20:59.56 | jon_y | very nice |
| 21:00.30 | jon_y | btw, does making frame buffer built in cause a big code size increase? |
| 21:15.04 | *** join/#maemo-ssu taziff (~Taziff@178.182.74.128.nat.umts.dynamic.t-mobile.pl) |
| 21:25.33 | kerio | include *all* the modules! _ò/ |
| 21:25.45 | *** join/#maemo-ssu skipper (~service@141-136-229-188.dsl.iskon.hr) |
| 21:45.55 | merlin1991 | DocScrutinizer05: thanks for checking this over a long time and providing the proof for me :) |
| 21:52.35 | kerio | meh, now the full charge is 1500mAh, according to bq27k |
| 21:52.39 | kerio | it's definetely NOT |
| 21:52.44 | kerio | it's 1200 at best |
| 21:53.21 | kerio | whoops, wrong window |
| 21:55.43 | kerio | freemangordon: is the fix already in cssu-thumb? |
| 21:55.50 | kerio | or will it be soon? |
| 21:56.39 | merlin1991 | kerio: whatcha talking about? |
| 21:56.54 | kerio | the pselect bug |
| 21:57.11 | merlin1991 | kerio: currently every klernel has the bug |
| 21:57.14 | kerio | i should've provided a bit more context, i was reading the scrollback |
| 21:57.18 | kerio | aww :c |
| 21:57.21 | merlin1991 | since even if the bug is fixed in the kernel libc isn't recompiled |
| 21:57.40 | kerio | well, cssu-thumb already has an updated glibc |
| 21:57.45 | merlin1991 | libc has to be compiled with kernel headers with a the fix in order for everything to work |
| 21:57.58 | merlin1991 | kerio: that's only due to the newer gcc used to build the thumb stuff |
| 21:58.04 | kerio | i see |
| 21:58.59 | merlin1991 | iirc it's only libstdc++ that is updated in -thumb, though I might be wrong |
| 21:59.51 | DocScrutinizer05 | kerio: |
| 21:59.57 | DocScrutinizer05 | while ! ./bq27200.sh | grep -q 'VDQ:1'; do echo 'Please charge battery! Use fastcharger!'; sleep 60; done; echo -e '\n\nNow stopping bme and discharging battery to lower limit.\nYou will not want to draw extreme power to speed that up too much, since it will spoil calibration.\n\nCharging will resume automatically once battery got discharged, please keep fastcharger connected!'; stop bme; sleep 30; while ./bq27200.sh | grep -q 'EDV1: |
| 21:59.58 | DocScrutinizer05 | 0'; do ./bq27200.sh|grep 'TTF:'; sleep 10; done; ./bq27200.sh; echo '************* RESUMING CHARGING *************'; start bme; sleep 10; stop bme; sleep 2; start bme; echo 'Please let device charge completely now to complete learning cycle!' |
| 22:00.51 | kerio | DocScrutinizer05: that would require leaving the n900 plugged in at all times |
| 22:00.55 | kerio | ish |
| 22:01.01 | DocScrutinizer05 | kerio: just testing ^^^this now, since I need a learning cycle anyway |
| 22:01.17 | DocScrutinizer05 | kerio: yes, so what? |
| 22:01.26 | kerio | well, i kinda have to use it |
| 22:01.35 | DocScrutinizer05 | mmpfff |
| 22:01.39 | kerio | and go to the beach and stuff |
| 22:02.05 | DocScrutinizer05 | sure thing, and when it reaches EDV1 you run for charger |
| 22:03.24 | kerio | but it says "please keep fastcharger connected"! |
| 22:05.25 | merlin1991 | kerio: "beach", where do you live? |
| 22:05.46 | kerio | merlin1991: rome, but i'm at my holiday house |
| 22:05.51 | kerio | still italy, but near the sea |
| 22:06.39 | DocScrutinizer05 | kerio: this "script" is for lazy people that like to calibrate overnight |
| 22:06.44 | kerio | i see |
| 22:06.45 | merlin1991 | kerio: dang I should have known that earlier, I was in rome a year ago |
| 22:07.16 | merlin1991 | I still heaven't met a single soul of this channel personally which I find kinda sad personally |
| 22:07.24 | DocScrutinizer05 | kerio: ideally you should find your N900 in perfect condition, charged and calibrated, when you awake in the morning |
| 22:07.33 | kerio | hm |
| 22:07.37 | kerio | i could do that |
| 22:07.54 | kerio | merlin1991: well, a year ago i wasn't this involved with the n900 community |
| 22:08.04 | kerio | i still had my old one, with a broken usb port |
| 22:08.12 | DocScrutinizer05 | only precondition: make screen backlight stay always on and level5 |
| 22:08.14 | kerio | (my only phone, i couldn't risk bricking it by doing silly stuff) |
| 22:08.23 | kerio | DocScrutinizer05: hm, why? |
| 22:08.30 | kerio | also, won't bme turn it off? |
| 22:08.32 | DocScrutinizer05 | otherwise it doesn't discharge in one night |
| 22:08.33 | kerio | (the backlight) |
| 22:08.37 | kerio | i see |
| 22:08.47 | kerio | well i can just turn it screen-side down |
| 22:08.55 | kerio | should the cell radio be on? |
| 22:08.56 | merlin1991 | DocScrutinizer05: what do you think of a kind of cssu get together some day? |
| 22:09.36 | DocScrutinizer05 | nice idea, though I'm afraid somebody will beat me up (or I feel the urge to do that to somebody ;-P) |
| 22:09.50 | kerio | cssu cage match between doc and estel! |
| 22:10.00 | kerio | the one that survives decides the future of cssu |
| 22:10.25 | DocScrutinizer05 | kerio: nope, future of CSSU got already decided on |
| 22:10.31 | DocScrutinizer05 | always been |
| 22:10.35 | kerio | but i wanted to see a cage match :c |
| 22:11.02 | kerio | ot: hmm, apparently an "iphonehigh" twitch.tv stream only takes like 28kb/s |
| 22:11.27 | merlin1991 | kerio: as long as estel does not have critical mass for all of his ideas inside the cssu team, cssu will stay almost as business as usual |
| 22:11.48 | DocScrutinizer05 | merlin1991: would you like to verify : |
| 22:11.53 | DocScrutinizer05 | while ! ./bq27200.sh | grep -q 'VDQ:1'; do echo 'Please charge battery! Use fastcharger!'; sleep 60; done; echo -e '\n\nNow stopping bme and discharging battery to lower limit.\nYou will not want to draw extreme power to speed that up too much, since it will spoil calibration.\n\nCharging will resume automatically once battery got discharged, please keep fastcharger connected!'; stop bme; sleep 30; while ./bq27200.sh | grep -q 'EDV1: |
| 22:11.54 | DocScrutinizer05 | 0'; do ./bq27200.sh|grep 'TTF:'; sleep 10; done; ./bq27200.sh; echo '************* RESUMING CHARGING *************'; start bme; sleep 10; stop bme; sleep 2; start bme; echo 'Please let device charge completely now to complete learning cycle!' |
| 22:11.59 | kerio | he would have critical mass if he killed everyone else :D |
| 22:12.22 | kerio | DocScrutinizer05: i'm actually going to try |
| 22:12.29 | merlin1991 | DocScrutinizer05: 0.75 L of white wine say I don't want to :D |
| 22:12.48 | DocScrutinizer05 | merlin1991: c&p ;-P |
| 22:12.59 | kerio | DocScrutinizer05: shellscript or gtfo |
| 22:13.08 | DocScrutinizer05 | lol |
| 22:13.49 | merlin1991 | DocScrutinizer05: no n900 here, and since you're the black magic master of shellscripts in here I'm not so sure if I can find any errors by simply reading through it :D |
| 22:15.06 | DocScrutinizer05 | well, wait a while, I'll prolly publish 'proper scriptie' tomorrow |
| 22:15.16 | kerio | :c |
| 22:15.20 | kerio | but i'm going to sleep right now! |
| 22:15.29 | kerio | actually, the battery is almost empty right now |
| 22:15.46 | kerio | and i don't know if there's enough time for it to charge, discharge and charge again |
| 22:16.19 | kerio | (it's only got 9 hours and a half, or something like that |
| 22:16.21 | kerio | ) |
| 22:17.03 | kerio | will it be enough? |
| 22:19.11 | kerio | hm, what does it mean to screw up the calibration? |
| 22:19.22 | kerio | isn't power consumption tracked accurately |
| 22:20.32 | DocScrutinizer05 | kerio: here you are: http://maemo.cloud-7.de/maemo5/patches_n_tools/calibrate-bq27k.sh |
| 22:20.38 | kerio | :3 |
| 22:20.46 | kerio | i'm probably not going to use it right now, though |
| 22:20.57 | DocScrutinizer05 | F*CK-U |
| 22:21.01 | kerio | :c |
| 22:21.04 | DocScrutinizer05 | :-) |
| 22:21.05 | kerio | there's not enough time! |
| 22:21.32 | DocScrutinizer05 | I could've had a piss during the time I prepared that one specially for you |
| 22:22.01 | kerio | you could've peed at the same time |
| 22:22.06 | kerio | don't blame me for your lack of multitasking |
| 22:22.20 | DocScrutinizer05 | o.O |
| 22:23.12 | kerio | DocScrutinizer05: do you think 9 hours are enough for an almost-charge, a discharge with no extra consumption and another charge? |
| 22:23.18 | kerio | also, won't the phone reboot once you restart bme? |
| 22:23.23 | *** join/#maemo-ssu MrPingu (~MrPingu@86.92.226.97) |
| 22:23.29 | DocScrutinizer05 | no |
| 22:23.36 | DocScrutinizer05 | no |
| 22:23.55 | DocScrutinizer05 | you need extra consumption to drain it 'fast'ish |
| 22:24.00 | kerio | hm |
| 22:24.02 | DocScrutinizer05 | like backlight on |
| 22:24.20 | kerio | aww, this dude i'm watching botched a star in super mario 64 and now he's 35 seconds over the WR :c |
| 22:24.21 | DocScrutinizer05 | TTF: 65535 minutes TTE: 168 minutes |
| 22:24.22 | DocScrutinizer05 | TTF: 65535 minutes TTE: 165 minutes |
| 22:26.31 | kerio | DocScrutinizer05: won't bme reset the phone because of the voltage? |
| 22:26.41 | DocScrutinizer05 | so if anybody likes to do a review: http://maemo.cloud-7.de/maemo5/patches_n_tools/calibrate-bq27k.sh much appreciated |
| 22:26.54 | DocScrutinizer05 | ShadowJK_: ^^^ |
| 22:26.56 | kerio | DocScrutinizer05: reset the backlight brightness |
| 22:27.00 | kerio | pali-style |
| 22:27.07 | kerio | whenever you start/stop bme |
| 22:27.34 | DocScrutinizer05 | :nod: |
| 22:27.41 | DocScrutinizer05 | v0.2 |
| 22:27.56 | kerio | DocScrutinizer05: perhaps it's better to use charge21.sh to charge afterwards? |
| 22:28.00 | kerio | bme is a fickle bitch |
| 22:28.06 | DocScrutinizer05 | for now I wanna know if it works at all (pissed it ;-D) |
| 22:28.24 | kerio | in theory, it works |
| 22:28.39 | DocScrutinizer05 | IOW I wrote it down from top of my head, not even checked it twicce |
| 22:29.22 | DocScrutinizer05 | and I'm not completely sure if I picked the correct "triggers" in grep 'trigger' |
| 22:30.06 | DocScrutinizer05 | neither I'm sure if it is semantically correct beyond mere syntax check in mcedit |
| 22:30.59 | DocScrutinizer05 | for all I know it *should* work and even catch EDV before device shuts down, and restart charging |
| 22:31.32 | DocScrutinizer05 | I'm not entirely sure if all that results in a valid learning cycle though |
| 22:32.05 | DocScrutinizer05 | again, it should. For all I recall about that stuff |
| 22:34.33 | kerio | DocScrutinizer05: well, it would be better to i2cget the values you want |
| 22:34.37 | kerio | but the process is sensible |
| 22:35.18 | kerio | are you sure that stopping bme will halt any kind of charging? |
| 22:35.20 | DocScrutinizer05 | no, it's best unix practice to reuse existing tools/filters |
| 22:35.33 | DocScrutinizer05 | kerio: yes |
| 22:35.34 | kerio | and grep the hell out of everything? ew |
| 22:36.07 | DocScrutinizer05 | kerio: I had to create some CPU load to discharge battery anyway ;-P |
| 22:36.13 | kerio | hehe |
| 22:36.25 | kerio | why does using a lot of power screw up the calibration, btw? |
| 22:36.38 | DocScrutinizer05 | battery goes down too quickly |
| 22:36.43 | kerio | so? |
| 22:37.04 | DocScrutinizer05 | it needs several seconds at the edge between EDV1 and total brownout |
| 22:37.23 | kerio | yeah but there's plenty of time between EDV1 and actual brownout |
| 22:37.32 | kerio | there's a lot less time between EDV1 and bme rebooting |
| 22:37.40 | DocScrutinizer05 | you'd be amazed |
| 22:37.41 | kerio | but there's no problem if you use charge21.sh :) |
| 22:37.58 | DocScrutinizer05 | also about your capacity of otherwise good cells when discharged at 1C |
| 22:38.23 | kerio | meh, when i calibrate i enable offline mode, shut down everything and leave the screen on at low brightness |
| 22:38.37 | kerio | (once i get close to 3200mV |
| 22:38.42 | DocScrutinizer05 | (bme /charge21.sh) i'm using neither, since we DIScharge ;-P |
| 22:38.44 | kerio | ugh, mismatched parenthesis) |
| 22:38.53 | kerio | i meant afterwards |
| 22:39.04 | kerio | anyway, going to sleep |
| 22:39.27 | kerio | cya guys |
| 22:39.33 | DocScrutinizer05 | going to have a shower |