| DocScrutinizer05 | dear estel, your statements are exactly "purely theoretical, just for sake of doing so" | 00:00 |
|---|---|---|
| DocScrutinizer05 | the possibility of existing custom kernel modules out there that will break with new kernel due to loss of ABI compliance is "purely theoretical, just for sake of doing so" while assuming a problem out of a very rare race that's not even been demontrated by testcode on stock kernel is a welcome argument to push your own ideas. Now THAT'S scientific and honest for sure | 00:03 |
| DocScrutinizer05 | and this guy denigrates my merits | 00:03 |
| DocScrutinizer05 | >:-( | 00:04 |
| *** BCMM has quit IRC | 00:05 | |
| DocScrutinizer05 | homestly when you got estel on your side arguing for you, prepare for failure even when your positions and arguments been good | 00:05 |
| kerio | kinda unrelated: was ABI-compatibility kept between nokia upgrades to the kernel? | 00:05 |
| kerio | were those the same kernel version? | 00:05 |
| DocScrutinizer05 | nope | 00:05 |
| DocScrutinizer05 | that's a direct result of the facts I quoted why it's impossible to keep ABI compatibilty between kernel versions (usually) | 00:06 |
| DocScrutinizer05 | btw I'm not absolutely sure if we've seen a kernel update with any PR upgrade | 00:07 |
| DocScrutinizer05 | so maybe Nokia didn't dare to push a new kernel | 00:07 |
| DocScrutinizer05 | they might however have fixed some modules | 00:07 |
| DocScrutinizer05 | without pushing a new kernel | 00:08 |
| DocScrutinizer05 | if you want to know for sure, you need to run a md4sum across kernel fiasco segment of PR1.0 image | 00:08 |
| DocScrutinizer05 | and even then you might get wrong idea, since already a later compile time will change the md5sum while it usually should keep ABI stable when *nothing* changed in kernel sources | 00:09 |
| kerio | -20094101-0m5 for 1.0, -20103103-0m5 for >=1.2, says maemo.org | 00:12 |
| kerio | but it's probably not a version change | 00:13 |
| DocScrutinizer05 | but NB I'm maybe enough of a kernel hacker to look into musb_hdrc and spot some things to patch to make USB hostmode work, but I'm not the kernel guru to tell you every detail about symbol binding and early / late addr linking in kernel->module ABI | 00:13 |
| *** TMavica has joined #maemo-ssu | 00:13 | |
| *** TMavica has quit IRC | 00:14 | |
| DocScrutinizer05 | if it works similar to usual .so then there's a table of verbatim symbols with some tagging of their types, and as long as that srays unchanged, basic ABI compatibility should stay intact | 00:14 |
| DocScrutinizer05 | then you just have to cope with, or override, vermagic and hope for it to not make your system go *boom* | 00:15 |
| DocScrutinizer05 | but I could as well be completely off the lane here | 00:16 |
| DocScrutinizer05 | and honestly I didn't get it why fmg got so upset when I suggested to run his new allegedly compatible kernel against stock modules. After all it *should* work, minus for the vermagic, for all I know | 00:17 |
| DocScrutinizer05 | in the end it's just a question of parameters on stack and in registers, and those shouldn't have changed, no? | 00:18 |
| * kerio doesn't know that much about the kernel | 00:19 | |
| *** BCMM has joined #maemo-ssu | 00:22 | |
| *** TMavica has joined #maemo-ssu | 00:25 | |
| *** zeq has quit IRC | 00:25 | |
| DocScrutinizer05 | do you think estel knows more than you? | 00:33 |
| *** BCMM has quit IRC | 00:35 | |
| kerio | meh | 00:37 |
| *** zeq has joined #maemo-ssu | 00:44 | |
| *** zeq has quit IRC | 00:54 | |
| DocScrutinizer05 | >>Estel_so, gentlemans, do we have any concerns about this point? someone wantg to present opposite arguments? Or are we trying to convince already convinced people? :) | 01:14 |
| DocScrutinizer05 | incredible how this guy always tries to push his own tiny horizon and topic and POV | 01:14 |
| DocScrutinizer05 | instead of shutting up and listening when experts talk | 01:15 |
| *** zeq has joined #maemo-ssu | 01:20 | |
| zeq | IRC doesn't do well with intermittent connectivity! DocScrutinizer05: If I owe you an apology for my part in yesterday's discussion, you have it. I particularly wanted to discuss the future plans for updating (e)glibc (outside of CSSU) and maintaining compatibility with CSSU/stock, and I actually really wanted you there, especially to come up with the difficult arguments and objections. At least from me there was no intention of spreading FUD or makin | 01:56 |
| zeq | g unwarranted assumptions, you're just a good experienced engineer and know the pitfalls. You are needed to keep everybody honest. | 01:56 |
| Raimu | Haha. | 02:02 |
| * Raimu strongly agrees | 02:03 | |
| Raimu | With the last phrasing, at least | 02:03 |
| *** andre__ has quit IRC | 02:05 | |
| DocScrutinizer05 | zeq: your position and rationale was without any concern from my side | 02:17 |
| DocScrutinizer05 | and I'm happy I made it til http://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2012-08-02.log.html#t2012-08-02T22:20:37 now and still seems common sense of the wiser attendees prevailed | 02:19 |
| DocScrutinizer05 | I'm just musing about an incompatibility between userland/*.so and kernel | 02:19 |
| DocScrutinizer05 | and I'm fully supporting merlin1991 with his take on kernel for CSSU shouldn't be another KP51 with bells and whistles nobody ever really tested if they play nice with N900, even if they're upstream. We've seen enough BS upsream, just look at lis302dl.ko vs lis3lv02.ko | 02:21 |
| DocScrutinizer05 | zeq: there's a reason maemo kernel is _not_ upstream kernel | 02:23 |
| DocScrutinizer05 | and any patch being upstream doesn't guarantee it's all sugar and cake for our device | 02:23 |
| DocScrutinizer05 | so my take on CSSU kernel is like merlin1991's: port every CVE separately, after *proper* evaluation on the ML, review of at least 2 other experts about possible impact, and finally proper testing before deploying the patch with a new kernel | 02:25 |
| DocScrutinizer05 | s/of at/by at/ | 02:25 |
| infobot | DocScrutinizer05 meant: so my take on CSSU kernel is like merlin1991's: port every CVE separately, after *proper* evaluation on the ML, review by at least 2 other experts about possible impact, and finally proper testing before deploying the patch with a new kernel | 02:25 |
| DocScrutinizer05 | zeq: when estel dare to throw around numbers like "99.99% of users", I can do as well. Keep in mind you're potentially wrecking the devices of 50000 or 100000 users that don't show up here to utter their concerns | 02:27 |
| DocScrutinizer05 | and anybody now jumping up and questioning those numbers has to debate with me about his attitude what CSSU is meant to be | 02:28 |
| DocScrutinizer05 | aim is to move CSSU on every single N900 ever sold | 02:29 |
| DocScrutinizer05 | if we're not there yet, we can't use this as an excuse for anything, particularly not for sloppyness and careless messing with system, but rather we should ponder why we're not there yet | 02:30 |
| DocScrutinizer05 | zeq: think "risk management", think "IF we mess it up completely, can we deliver a proper recovery path, and can we do that fast and safely?" | 02:32 |
| zeq | I can't disagree with any of that | 02:32 |
| DocScrutinizer05 | I know | 02:32 |
| DocScrutinizer05 | that's why I definitely didn't mean you, merlin1991, pali or even fmg with my rant about the non-expert half opening their mouth way to wide when they better shut up and listen | 02:33 |
| DocScrutinizer05 | but according to estel you're all under my satanic influence | 02:34 |
| DocScrutinizer05 | ;-P | 02:34 |
| zeq | :) | 02:34 |
| DocScrutinizer05 | and I hope some guys have learnt now that my satanic influence is STRONG even when I'm just not around | 02:35 |
| DocScrutinizer05 | XD | 02:35 |
| zeq | incidently, is it known how many N900s there are out there? | 02:37 |
| DocScrutinizer05 | numbers differ, I seem to recall preworders been 250k | 02:37 |
| DocScrutinizer05 | or sales during first 3 months incl preorders? | 02:38 |
| DocScrutinizer05 | dunno | 02:38 |
| DocScrutinizer05 | maybe I'm totally wrong and my memory clouded | 02:39 |
| *** NIN101 has quit IRC | 02:39 | |
| DocScrutinizer05 | guys like gan should know better | 02:39 |
| Raimu | I wish all this in-scene fighting shit would just recede. | 02:39 |
| Raimu | Seen it too often in different circles. | 02:39 |
| zeq | I'd better get to sleep now, on holiday you know! ;) | 02:40 |
| DocScrutinizer05 | Raimu: seems a normal thing in FOSS | 02:40 |
| DocScrutinizer05 | :-S | 02:40 |
| Raimu | Suppose. | 02:40 |
| Raimu | No problem with differing opinions, though. Just when it goes ballistic. | 02:40 |
| DocScrutinizer05 | yep | 02:40 |
| DocScrutinizer05 | well, all you can earn in FOSS is fame. Some need it more than others, some are ruthless in their means to achive that goal | 02:41 |
| DocScrutinizer05 | and some simply haven't groked the concept of meritocracy | 02:42 |
| Raimu | Bah, not what I'm talking about. | 02:43 |
| DocScrutinizer05 | meritocracy is a top-down concept, where gurus appoint others for peers | 02:43 |
| Raimu | Hmm, yes. | 02:43 |
| DocScrutinizer05 | it's not the unwashed masses cheering up those with merit | 02:43 |
| Raimu | I mean some views are complementary rather than "naturally contradictory". | 02:43 |
| Raimu | Anyways. | 02:44 |
| * Raimu hugs everyone like a drunkard | 02:45 | |
| Raimu | I guess that's what I mean. :P | 02:45 |
| DocScrutinizer05 | :-D | 02:45 |
| * DocScrutinizer05 afk for a late beer | 02:46 | |
| Raimu | One can swing ace concepts every which way, but they're still just that. | 02:46 |
| * Raimu already started with a quart of rum'n'ginger | 02:46 | |
| DocScrutinizer05 | zeq: n8 pal | 02:46 |
| *** arcean_ has joined #maemo-ssu | 03:04 | |
| *** arcean has quit IRC | 03:07 | |
| *** LaoLang_cool has joined #maemo-ssu | 04:06 | |
| *** arcean_ has quit IRC | 04:18 | |
| *** jonwil has joined #maemo-ssu | 05:02 | |
| *** LaoLang_cool has quit IRC | 05:23 | |
| *** LaoLang_cool has joined #maemo-ssu | 05:24 | |
| *** amiconn has quit IRC | 05:27 | |
| *** amiconn_ has joined #maemo-ssu | 05:27 | |
| *** amiconn_ is now known as amiconn | 05:27 | |
| *** zeq has quit IRC | 05:28 | |
| *** LaoLang_cool has quit IRC | 06:54 | |
| *** taziff has quit IRC | 08:05 | |
| *** taziff has joined #maemo-ssu | 08:05 | |
| *** chainsawbike has quit IRC | 08:41 | |
| *** chainsawbike has joined #maemo-ssu | 08:47 | |
| *** LaoLang_cool has joined #maemo-ssu | 08:57 | |
| *** LaoLang_cool has quit IRC | 09:08 | |
| *** jonwil has quit IRC | 10:49 | |
| *** zeq has joined #maemo-ssu | 11:08 | |
| *** LaoLang_cool has joined #maemo-ssu | 11:27 | |
| *** zeq has quit IRC | 11:31 | |
| *** LaoLang_cool has quit IRC | 12:22 | |
| *** LaoLang_cool has joined #maemo-ssu | 12:23 | |
| *** jonwil has joined #maemo-ssu | 12:32 | |
| *** BCMM has joined #maemo-ssu | 12:39 | |
| *** BCMM has quit IRC | 13:11 | |
| *** LaoLang_cool has quit IRC | 13:23 | |
| *** LaoLang_cool has joined #maemo-ssu | 13:24 | |
| *** BCMM has joined #maemo-ssu | 13:27 | |
| *** NIN101 has joined #maemo-ssu | 13:29 | |
| 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 | 13:34 |
| 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? | 13:38 |
| 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? | 13:43 |
| kerio | DocScrutinizer05: i, for one, approve of a cssu-power fork that also adds the said "leete" features | 13:44 |
| kerio | (cssu-thumb is kinda like that, if you think about it) | 13:44 |
| 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 | 13:44 |
| *** LaoLang_cool has quit IRC | 13:46 | |
| kerio | hey, KP50 is in extras! it means that it's stable! </sarcasm> | 13:46 |
| 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 | 13:46 |
| *** LaoLang_cool has joined #maemo-ssu | 13:47 | |
| 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 | 13:51 |
| DocScrutinizer05 | honestly seems you guys planned a proper nice revolution, messing up everything the CSSU founders had in mind, eh? | 13:52 |
| kerio | "you guys" who? | 13:52 |
| DocScrutinizer05 | whoever initiated that blitz-conference | 13:55 |
| DocScrutinizer05 | and drove it that direction | 13:55 |
| 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 | 13:57 |
| 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 | 13:58 |
| 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 | 14:05 |
| NIN101 | haha | 14:09 |
| 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 | 14:09 |
| NIN101 | 100% ack. | 14:09 |
| 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" | 14:12 |
| *** krayon has joined #maemo-ssu | 14:22 | |
| *** BCMM has quit IRC | 14:32 | |
| *** BCMM has joined #maemo-ssu | 14:34 | |
| LaoLang_cool | Yeah! | 14:57 |
| 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 | 14:58 |
| *** fw190 has joined #maemo-ssu | 15:10 | |
| 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 | 15:13 |
| *** fw190 has quit IRC | 15:17 | |
| DocScrutinizer05 | >>Estel_release early, release often ;) | 15:27 |
| DocScrutinizer05 | LOL that's true for devel and experimental, it clearly shows there's a massive misconception about what CSSU actually IS | 15:28 |
| kerio | ooh, cssu-devel has apt 0.7 | 15:30 |
| kerio | neat | 15:30 |
| 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" | 15:30 |
| kerio | and an updated busybox, sweet | 15:30 |
| 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 | 15:31 |
| 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 | 15:32 |
| DocScrutinizer05 | and NO WAY the mantra "release early, release often" ever applied to and kernel and/or toolchain related things | 15:33 |
| DocScrutinizer05 | s/to and/to any/ | 15:33 |
| infobot | DocScrutinizer05 meant: and NO WAY the mantra "release early, release often" ever applied to any kernel and/or toolchain related things | 15:33 |
| jonwil | so yeah I do agree with not shipping KP but instead shipping kernel with minimal set of tested changes | 15:35 |
| jonwil | IIRC that was what was discussed at the meeting before | 15:36 |
| kerio | ooh, where do maemo-security-certman-applet and modest-home-applet (non-free) come from, in -devel? | 15:38 |
| 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 | 15:40 |
| 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 | 15:47 |
| jonwil | which I disagree with | 15:48 |
| DocScrutinizer05 | as usual estel beaten everybody's intelligence by stating shit like "it's been tested by millions of happy ACME users" | 15:48 |
| DocScrutinizer05 | and "there are zero reports of anything bad happening, so there can't be anything" | 15:49 |
| DocScrutinizer05 | which is 3 wrong assumptions in one sentence, sth estel is really great on | 15:50 |
| 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 | 15:55 |
| DocScrutinizer05 | guaranteed to inherit any of the stability it had before you changed toolchain | 15:55 |
| DocScrutinizer05 | basically same situation as with a new kernel, only worse | 15:57 |
| 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 | 15:58 |
| DocScrutinizer05 | on a usual linux distro you'd bump at least the minor version by .1 | 16:00 |
| DocScrutinizer05 | so this should become maemo5.1 then | 16:00 |
| kerio | maemo-power! | 16:00 |
| DocScrutinizer05 | indeeed | 16:00 |
| kerio | or cssu-power | 16:00 |
| kerio | or something like that | 16:01 |
| DocScrutinizer05 | the suggested fork | 16:01 |
| 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" | 16:02 |
| DocScrutinizer05 | since CSSU been about LTS from day one | 16:02 |
| 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? | 16:06 |
| DocScrutinizer05 | hell there's KP51 for everybody to install free of charge! WTF we need to make it a mandatory part of CSSU? | 16:07 |
| DocScrutinizer05 | and what's next? Mandatory portrait-only desktop? | 16:08 |
| 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" | 16:10 |
| 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" | 16:13 |
| 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" | 16:13 |
| DocScrutinizer05 | congrats if this attitude now preveils on CSSU | 16:14 |
| kerio | ok, you're well into strawman-land at this point | 16:14 |
| kerio | strawmen-land? | 16:14 |
| DocScrutinizer05 | kerio: nope, we're already there, or at least halfway | 16:15 |
| DocScrutinizer05 | stating KPxy was fit for primetime commercial-grade product is simply neglecting all the already known issues | 16:16 |
| DocScrutinizer05 | unclear problems during bootup only one of them | 16:17 |
| amiconn | Well, you can't even fix bugs without introducing changes. And *every* change might introduce (other) bugs, instabilities, orincompatibilites | 16:18 |
| 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" | 16:18 |
| *** arcean has joined #maemo-ssu | 16:18 | |
| amiconn | I'm not advocating aggressive moving forward ignoring problems, but I don't understand this "change nothing unless absolutely necessary" attitude | 16:19 |
| DocScrutinizer05 | now that's reworded to "tested by the masses" by estel | 16:19 |
| amiconn | Imho the most important part is to actually and actively take care of bug reports | 16:20 |
| amiconn | Just my 2 cents... | 16:20 |
| amiconn | This taking care of bug reports is missing for some maemo apps btw (not cssu material) | 16:21 |
| 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 | 16:21 |
| LaoLang_cool | is cssu focus on introducing more features, not on improvment and bugfix? | 16:22 |
| DocScrutinizer05 | LaoLang_cool: nope | 16:22 |
| DocScrutinizer05 | focus is on LongTermsupport | 16:23 |
| DocScrutinizer05 | LTS | 16:23 |
| LaoLang_cool | thanks, got it | 16:23 |
| 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 | 16:23 |
| DocScrutinizer05 | well, while that's true, it's actually the case already for our kernel since the day first N900 shipped | 16:24 |
| amiconn | Even debian sta(b)le now recommends upgrading firefox (iceweasel) from 3.5.x to 10.0.x lts through -backports | 16:24 |
| DocScrutinizer05 | well, iceweasel won't break your whole system when an unforeseen new bug appears | 16:25 |
| DocScrutinizer05 | kernel does | 16:25 |
| DocScrutinizer05 | toolchain does | 16:25 |
| amiconn | I know the kernel is ooold... | 16:26 |
| DocScrutinizer05 | and CSSU constantly updates subsystems of minor system relevance, like modest etc | 16:26 |
| amiconn | New toolchain won't break stuff not compiled using that one. | 16:26 |
| DocScrutinizer05 | the risk/benefit eqation looks different for modest than it does for kernel patches | 16:26 |
| amiconn | sure | 16:27 |
| 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 | 16:28 |
| 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 | 16:29 |
| 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 | 16:29 |
| 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) | 16:30 |
| DocScrutinizer05 | the problem is that users usually have no clue how to test | 16:30 |
| 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 | 16:32 |
| kerio | DocScrutinizer05: otoh stuff like glibc has quite the testing already done, upstream | 16:33 |
| amiconn | kerio: Upstream certainly didn't test in a maemo environment | 16:33 |
| amiconn | DocScrutinizer05: Then it might be necessary to provide special test executables, complete with instructions how to use them. | 16:34 |
| DocScrutinizer05 | kerio: upstream testing is basically useless for N900, since we are not on an upstream system | 16:35 |
| DocScrutinizer05 | testing by users: http://xkcd.com/937/ | 16:36 |
| 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. | 16:36 |
| DocScrutinizer05 | amiconn: (special test binaries needed) indeed | 16:36 |
| DocScrutinizer05 | http://xkcd.com/937/ the hover text: >>the bug report was marked 'could not reproduce'." | 16:40 |
| DocScrutinizer05 | that's basically exactly the situation we're facing here | 16:40 |
| 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 | 16:49 |
| DocScrutinizer05 | arising from such patches shipped to his device | 16:49 |
| 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 | 16:55 |
| 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 | 16:56 |
| 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 | 16:57 |
| DocScrutinizer05 | that's what LTS is all about | 16:57 |
| DocScrutinizer05 | for a more leete mailer app they will visit extras(-devel) and get one meeting their taste | 16:58 |
| 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 | 17:00 |
| *** javispedro has joined #maemo-ssu | 17:00 | |
| DocScrutinizer05 | s/ete2/ete"/ | 17:00 |
| infobot | DocScrutinizer05 meant: if there's a severe bug in stock modest, like e.g. deleting mails from server despite the "don't delete" option in modest got tagged, users expect CSSU to ship a fix for that | 17:00 |
| amiconn | There's one problem with this approach though: you're effectively splitting user bases, meaning that each flavour will see less testing | 17:02 |
| DocScrutinizer05 | well, that's kinda true, but then otoh any user testing isn't exactly helping to reduce workload of patch review by peers | 17:03 |
| 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) | 17:03 |
| 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' | 17:04 |
| 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) | 17:04 |
| kerio | yeah but -experimental is different | 17:04 |
| kerio | think of cssu-thumb | 17:04 |
| DocScrutinizer05 | actually stable is different | 17:05 |
| amiconn | And probably test binaries (maybe scripts running the tests and uploading the results) | 17:05 |
| kerio | stuff there may never reach cssu-stable | 17:05 |
| DocScrutinizer05 | yep | 17:05 |
| kerio | devel->testing->stable is a pipeline where stuff is eventually either passed on or removed | 17:05 |
| DocScrutinizer05 | it never been meant to reach stable | 17:05 |
| DocScrutinizer05 | so for now our cssu-devel in fact is experimental | 17:06 |
| kerio | i would start using it, but it would break -thumb :( | 17:06 |
| kerio | although i think that freemangordon is recompiling a bunch of stuff for -thumb, so it's at least close | 17:06 |
| kerio | (-thumb got the modest/tinymail updates) | 17:06 |
| 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 | 17:07 |
| amiconn | s/or getting/or not getting/ | 17:07 |
| infobot | amiconn meant: Imo everything that's developed in -devel and is not ditched (because of main developer vanishing or not getting it to work reliably at all) should reach -stable at some point, otherwise it's useless | 17:07 |
| DocScrutinizer05 | well, if that thumb stuff is sane, it will allow any arbitrary ARM (== non-thumb-compiled) app to run without any probelms | 17:07 |
| kerio | DocScrutinizer05: yeah but fastness! | 17:07 |
| kerio | :3 | 17:08 |
| kerio | i think that cssu-thumb is supposed to be somewhat aligned to cssu-testing | 17:08 |
| * amiconn is running KP for many months now, and wouldn't go back to stock kernel | 17:08 | |
| kerio | amiconn: yeah but KP and the other "l33t" things require time | 17:09 |
| *** DocScrutinizer has quit IRC | 17:09 | |
| kerio | a lot of people don't care about their phone that much | 17:09 |
| *** DocScrutinizer has joined #maemo-ssu | 17:09 | |
| *** DocScrutinizer05 has quit IRC | 17:09 | |
| *** DocScrutinizer05 has joined #maemo-ssu | 17:09 | |
| DocScrutinizer05 | and no way fastness is a valid entry ticket to CSSU-S(-LTS) | 17:09 |
| kerio | by "require time" i mean that they require a bit of manual effort | 17:09 |
| 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 | 17:09 |
| DocScrutinizer05 | sorry, [2012-08-04 16:08:04] <kerio> :3 been last inbound here (disconnect) | 17:09 |
| kerio | pastebinning | 17:10 |
| kerio | http://fpaste.org/e7Qs/ | 17:10 |
| kerio | ...hey, you can just look at the logs! | 17:10 |
| amiconn | jonwil: The question is how to select those | 17:10 |
| DocScrutinizer05 | thnx | 17:11 |
| jonwil | if it fixes a kernel bug its a good patch | 17:11 |
| jonwil | generally | 17:11 |
| DocScrutinizer05 | yes, if we can prove the bug bites our N900-ass | 17:11 |
| jonwil | if it fixes a userspace bug, its also a good candidate | 17:11 |
| 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... | 17:12 |
| DocScrutinizer05 | that's why I agreed we now need a CSSU kernel, if there's no other way to fix that pselect(9 mess | 17:12 |
| jonwil | can anyone remember who is doing the BME replacement work? | 17:12 |
| jonwil | I think it was Pali although I cant be sure | 17:12 |
| DocScrutinizer05 | yes, userland bugfixes are not as probelmatic as kernel generic or kernel-domain fixes | 17:13 |
| DocScrutinizer05 | or fixes to foundation subsystems in general | 17:13 |
| jonwil | what I meant was kernel changes that fix userspace issues somehow | 17:13 |
| jonwil | such as the kernel fixes that fix pselect() | 17:13 |
| DocScrutinizer05 | jonwil: bme kernel replacement: pali | 17:14 |
| jonwil | ok | 17:14 |
| DocScrutinizer05 | jonwil: hald-addon-bme et al: fmg | 17:14 |
| jonwil | I think that overclocking, USB-host-mode, IPv6 are not candidates for a CSSU kernel | 17:15 |
| jonwil | The reduced battery consumption is though IMO because reduced battery consumption is something all n900 owners will like and be interested in | 17:15 |
| DocScrutinizer05 | amiconn: SR and voltage are highly controversy as well, regarding stability and general sanity for all hw platforms they had to run on | 17:15 |
| jonwil | although it depends on how risky the power management changes in question actually are | 17:16 |
| amiconn | Well the idea of SR is that it auto-regulates, so it should work everywhere. You're right regarding voltage profiles of course | 17:16 |
| 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 | 17:17 |
| * amiconn did actually have issues due to a too low voltage profile himself | 17:17 | |
| kerio | wouldn't there be an official errata from TI? | 17:17 |
| kerio | amiconn: the "starving" profile or something silly like that? | 17:17 |
| DocScrutinizer05 | kerio: not if the borkage is in N900 specific design | 17:18 |
| kerio | like what? | 17:18 |
| amiconn | No, "starving" and even "ideal" don't work at all for me | 17:18 |
| DocScrutinizer05 | like a too long too thin trace, a missing or too small or crappy buffer capacitor, or whatever else | 17:18 |
| *** LaoLang_coo_ has joined #maemo-ssu | 17:18 | |
| 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 | 17:19 |
| *** LaoLang_cool has quit IRC | 17:19 | |
| 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 | 17:20 |
| amiconn | With "lv" it's working fine, including SR enabled and overclocked to 805 MHz | 17:20 |
| DocScrutinizer05 | for obvious reasons Nokia doesn't like to spread the news that some hw-revs have a 'bug' that others don't | 17:20 |
| DocScrutinizer05 | and for same obvious reasons they never implemented a selective SR enabler in their PR | 17:21 |
| RST38h | This is not subject of a hw bug | 17:22 |
| RST38h | The CPU is rated for a certain voltage range | 17:22 |
| DocScrutinizer05 | and I still fail to find a single decent scientific review on how much savings SR will aearn you | 17:22 |
| RST38h | If you go outside the range, TI does not guarantee reliable operaion, that is all | 17:22 |
| DocScrutinizer05 | RST38h: we're talking about SR | 17:22 |
| DocScrutinizer05 | and why it's disabled on fremantle/N900 | 17:23 |
| RST38h | That "reflex" mode? | 17:23 |
| DocScrutinizer05 | yep | 17:23 |
| RST38h | It does not work on the CPUs used in N900 | 17:23 |
| DocScrutinizer05 | the 'definitive' answer from Nokia been "it's not stable" afaik | 17:23 |
| RST38h | That is non-official word from several independent Nokia engineers, quoting TI | 17:23 |
| kerio | "does not work" how? | 17:23 |
| 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.... | 17:23 |
| RST38h | No, it does not work properly. That is how they go those chips from TI. Nokia has nothign to do with it. | 17:24 |
| RST38h | s/go/got | 17:24 |
| DocScrutinizer05 | btw there are quite usually SiErr that are NOT published to the unwashed masses by TI | 17:24 |
| RST38h | kerio:"Does not work" as in "leads to unpredictable operation" | 17:24 |
| kerio | meaning that it offers no benefits whatsoever or that it causes problems? | 17:24 |
| kerio | i see | 17:24 |
| RST38h | kerio: would you like me to explain what "unpredictable operation" means? | 17:24 |
| DocScrutinizer05 | like the general lack of reliability of IRQ-wakes from powerless sleep in OMAP4 | 17:25 |
| RST38h | Doc: Of course there are erratas, usually specific to each stepping of the chip production | 17:25 |
| DocScrutinizer05 | yep | 17:26 |
| DocScrutinizer05 | for OMAP4 IRQ from powerless though, TI says they will fix it in OMAP5 ;-P | 17:26 |
| 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 | 17:28 |
| DocScrutinizer05 | like "please assert the IRQ repeatedly for 20s" | 17:28 |
| *** mase76 has joined #maemo-ssu | 17:29 | |
| 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 | 17:30 |
| DocScrutinizer05 | or just made it up | 17:30 |
| DocScrutinizer05 | you dunno what's this deal with SR in 'our' OMAP3 | 17:31 |
| DocScrutinizer05 | you just know Nokia thought it's not safe to enable it | 17:31 |
| DocScrutinizer05 | so why do you think it is? | 17:31 |
| kerio | because elop hates open source! | 17:31 |
| kerio | or maybe because they wanted to be safe | 17:31 |
| DocScrutinizer05 | so do 'we', here in CSSU | 17:32 |
| amiconn | Or had not enough time to test it | 17:32 |
| kerio | uncertain benefits, uncertain stability depending on revision and whatnot | 17:32 |
| * kerio uses SR with no problems so far | 17:32 | |
| DocScrutinizer05 | that's up to you, kerio. nobody will blame you for | 17:32 |
| DocScrutinizer05 | but it's not up to CSSU to feed SR-enabled to *everybody* based on that | 17:33 |
| DocScrutinizer05 | get my point? | 17:33 |
| kerio | oh absolutely | 17:33 |
| kerio | to be fair, though, SR is disabled by default with kernel power | 17:34 |
| kerio | you have to manually load the "default" settings and/or set them as default to make them actually enabled | 17: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 | 17:35 |
| DocScrutinizer05 | another how many? 89? remaining... | 17:35 |
| 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) | 17:37 |
| DocScrutinizer05 | no hostmode or IPv6 or whatever patches have a place in CSSU kernel | 17:38 |
| DocScrutinizer05 | there's KP for that | 17:38 |
| DocScrutinizer05 | (well, IPv6 *might* eventually advance to status 'mandatory' if it turns out carriers switching to IPv6 makes our CSSU based device break) | 17:40 |
| amiconn | Sure, hostmode and the ton of additionally supported filesystems are not necessary for cssu kernel | 17:42 |
| amiconn | IPv6 is mandatory nowadays imho | 17:42 |
| kerio | ipv6 needs a ton of changes in maemo applications, though | 17:43 |
| kerio | doesn't it? | 17:43 |
| amiconn | Well it might, but that's another reason for enabling it at the kernel level now | 17:44 |
| amiconn | This way application developers have more time to fix the apps | 17:44 |
| amiconn | And enabling IPv6 won't affect apps not using it, so it should be safe | 17:45 |
| kerio | hmm, the garage page says something about ipv6 requiring two APNs and two pdp contexts | 17:47 |
| kerio | why is that? | 17:47 |
| kerio | also i'm a bit worried about smartreflex now :c | 17:48 |
| DocScrutinizer05 | amiconn: I tend to agree, more than argue | 17:48 |
| 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 | 17:49 |
| * kerio still has no ipv6 in his home network | 17:50 | |
| kerio | i feel like a noob :c | 17:50 |
| BCMM | my damn router doesn't do it as far as i can tell | 17:50 |
| DocScrutinizer05 | mine neither | 17:51 |
| kerio | i should really build a proper openwrt system and start using 6to4 at least | 17:51 |
| BCMM | i'm sure you can still buy v4-only routers, post-exhaustion, which is totally messed up | 17:51 |
| DocScrutinizer05 | kerio: (2 APN) probably because IPv6 and IPv4 are not compatible on same media channel | 17:51 |
| BCMM | kerio: yeah, i need to find out how to get one of those cheaply | 17:52 |
| kerio | DocScrutinizer05: yeah but ipv6 is backwards-compatible, isn't it | 17:52 |
| DocScrutinizer05 | nope, not afaik | 17:52 |
| DocScrutinizer05 | if it was, then I'd not know why you'd need two APN | 17:53 |
| kerio | hm, wasn't there a special address class that encompasses the whole of ipv4? | 17:53 |
| kerio | maybe i'm thinking of something else | 17:53 |
| kerio | perhaps 6to4 | 17:53 |
| DocScrutinizer05 | 6to4 is a tunneling protocol basically | 17:53 |
| DocScrutinizer05 | afaik | 17:53 |
| kerio | the bestest tunneling is teredo, anyway | 17:53 |
| BCMM | there's no way to contact a v4-only host if you don't have a v4 address or NAT, basically | 17:54 |
| DocScrutinizer05 | if it actually is you wrap your ipv4 packets into a ipv6 wrapper and send it via ipv6 to a 'gateway' | 17:54 |
| BCMM | because how would the host get packets back to you if it doesn't know about v6 addresses? | 17:54 |
| kerio | you'd need a 4to6 gateway, yeah | 17:54 |
| *** taziff has quit IRC | 17:58 | |
| *** taziff has joined #maemo-ssu | 17:59 | |
| *** LaoLang_coo_ has quit IRC | 18:00 | |
| *** mase76 has quit IRC | 18:13 | |
| *** M4rtinK has joined #maemo-ssu | 18:20 | |
| *** mase76 has joined #maemo-ssu | 18:27 | |
| *** mase76 has quit IRC | 18:32 | |
| *** mase76 has joined #maemo-ssu | 18:40 | |
| *** taziff1 has joined #maemo-ssu | 18:44 | |
| *** taziff has quit IRC | 18:45 | |
| *** mase76 has quit IRC | 18:56 | |
| 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? | 19:00 |
| javispedro | already read part of it | 19:00 |
| javispedro | don't really want to enter the discussion | 19:01 |
| DocScrutinizer05 | http://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2012-08-02.log.html#t2012-08-02T20:58:59 | 19:01 |
| DocScrutinizer05 | ff | 19:01 |
| *** jonwil has quit IRC | 19:01 | |
| DocScrutinizer05 | Jaffa: what's about you? | 19:02 |
| DocScrutinizer05 | generalantilles even missing | 19:02 |
| DocScrutinizer05 | it seems to me in this discussion the "old farts" (aka those who once 'invented' CSSU) been severely under-represented | 19:04 |
| DocScrutinizer05 | and I'm not sure this happened coincidental | 19:05 |
| *** arcean has quit IRC | 19:05 | |
| kerio | well, who called that discussion? | 19:06 |
| DocScrutinizer05 | NFC actually | 19:06 |
| kerio | and who's got commit access to the repos? | 19:06 |
| DocScrutinizer05 | http://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2012-08-02.log.html#t2012-08-02T21:08:06 | 19:07 |
| DocScrutinizer05 | the ones that the original project managers included to the respective garage project group, as developers | 19:08 |
| javispedro | in any case I suspect that the problem is developer-starvation | 19:09 |
| *** arcean has joined #maemo-ssu | 19:10 | |
| javispedro | and when that happens you get that devs want to do what pleases them most instead of the boring tasks ;P | 19:10 |
| DocScrutinizer05 | https://garage.maemo.org/projects/cssu/ defines https://garage.maemo.org/projects/cssu-testing/ and https://garage.maemo.org/projects/cssu-stable/ | 19:10 |
| *** BCMM has quit IRC | 19:11 | |
| 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 | 19:12 |
| DocScrutinizer05 | you don't hijack and redefine a project, to shanghai the devels | 19:13 |
| DocScrutinizer05 | that's what industry does sometimes. In FOSS though that should get banned publicly | 19:13 |
| DocScrutinizer05 | s/banned/bashed/. | 19:14 |
| *** zeq has joined #maemo-ssu | 19:19 | |
| *** mase76 has joined #maemo-ssu | 19:28 | |
| *** BCMM has joined #maemo-ssu | 19:49 | |
| *** zeq has quit IRC | 20:16 | |
| 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 | 20:26 |
| DocScrutinizer05 | did somebody provide a link yesterday? | 20:26 |
| DocScrutinizer05 | also of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/319729/comments/23 attached own-wrapper test code please | 20:28 |
| *** javispedro has quit IRC | 20:30 | |
| merlin1991 | DocScrutinizer05: quite a rant you wrote whilst I did other stuff :D | 20:31 |
| DocScrutinizer05 | yeah, felt like it's needed | 20:31 |
| merlin1991 | But my stance re pk / whanot is still as before meeting, I'll want a stock kernel + patches for stable | 20:31 |
| DocScrutinizer05 | good | 20:32 |
| DocScrutinizer05 | thought they mugged you | 20:32 |
| 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 | 20:33 |
| DocScrutinizer05 | both flavours each (simmulation and real pselect) | 20:34 |
| merlin1991 | I have the arm build on my device (which is in vienna), but I can give you the build when I come back | 20:34 |
| merlin1991 | also we have no real pselect on our stock kernel | 20:34 |
| DocScrutinizer05 | fine with me | 20:34 |
| merlin1991 | that's the whole reason for the patch, on maemo pselect is always simulated | 20:34 |
| DocScrutinizer05 | sure thing, the missing pselect() in kernel is what we wanna test, after all | 20:34 |
| merlin1991 | freemangordon said he managed to crash the sample code by running ham additionall to get some system load | 20:35 |
| DocScrutinizer05 | I'll run a decent set of tests and post the results, since obviously nobody else will do | 20:35 |
| merlin1991 | hm I do have my sb with me, the build should be on there | 20:36 |
| * merlin1991 reboots | 20:36 | |
| *** jon_y has quit IRC | 20:36 | |
| *** mase76 has quit IRC | 20:40 | |
| 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? | 20:40 |
| DocScrutinizer05 | aiui we got 3 different falvours for each kernel now: plain NAND, NAND_with_uBoot, uBoot/multiboot image file | 20:41 |
| merlin1991 | well uboot and multiboot will have to be reflashed in case we deploy the cssu kernel | 20:41 |
| merlin1991 | and we need to put a big fat warning, because any kernel without pselect will foobar libc | 20:41 |
| 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? | 20:42 |
| merlin1991 | nah each uboot came bundled with different kernel | 20:43 |
| DocScrutinizer05 | and AIUI we should even roll a new FIACO? | 20:43 |
| merlin1991 | nope we don't need to roll a new Fiasco (we can't) | 20:43 |
| DocScrutinizer05 | merlin1991: are you sure about that? | 20:43 |
| DocScrutinizer05 | (new kernel with each uBoot) | 20:44 |
| merlin1991 | DocScrutinizer05: yes, uboot-pr1.3 had stock kernel bundeled uboot-power has pk bundled ... | 20:44 |
| DocScrutinizer05 | mhm | 20:44 |
| merlin1991 | multiboot is again another story | 20:44 |
| merlin1991 | and we overwrite anything in the flash area with our kernel | 20:44 |
| DocScrutinizer05 | sure | 20:44 |
| merlin1991 | DocScrutinizer05: http://cdnm.at/~christian/maemo/childspin | 20:44 |
| DocScrutinizer05 | thanks | 20:45 |
| *** jon_y has joined #maemo-ssu | 20:45 | |
| 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 | 20:46 |
| DocScrutinizer05 | running | 20:47 |
| merlin1991 | you need to put some load on the system for the race condition to happen | 20:47 |
| DocScrutinizer05 | :nod: | 20:47 |
| merlin1991 | ham should be perfect for that :D | 20:47 |
| DocScrutinizer05 | I don't see such requirement | 20:47 |
| merlin1991 | well the requirement is that you get a signal between those 3 calls to simulate pselect | 20:48 |
| DocScrutinizer05 | anyway ssh over wlan should be hellufalot of enough load | 20:48 |
| merlin1991 | which you'll only get if the 3 steps are interrupted | 20:48 |
| merlin1991 | which in turn only happens on heavy system load | 20:48 |
| DocScrutinizer05 | :shrug: | 20:48 |
| DocScrutinizer05 | might be worth a shot, yeah | 20:48 |
| merlin1991 | other than that you can ofc let it run for ages and see if it stops at some point (shouldn't stop ever) | 20:49 |
| 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 | 20:50 |
| DocScrutinizer05 | renice -5; i=1; while true; do echo $(( i++ )); done | 20:53 |
| DocScrutinizer05 | renice -10; top | 20:53 |
| DocScrutinizer05 | should do, I see the jitter in "........................................." | 20:54 |
| DocScrutinizer05 | still running | 20:54 |
| DocScrutinizer05 | CPU: 28.4% usr 63.2% sys 0.0% nice 0.0% idle 0.0% io 0.5% irq 7.7% softirq | 20:55 |
| DocScrutinizer05 | hell, I could actually start HAM as well | 20:55 |
| DocScrutinizer05 | :shrug: | 20:55 |
| DocScrutinizer05 | CPU: 26.0% usr 63.0% sys 3.3% nice 0.0% idle 0.0% io 1.3% irq 6.2% softirq | 20:57 |
| DocScrutinizer05 | hmm, this HAM thing didn't do much? | 20:57 |
| kerio | open modest! | 20:58 |
| DocScrutinizer05 | 15685 15263 root R 780 0.3 18.2 -sh | 20:58 |
| DocScrutinizer05 | 10 2 root RW 0 0.0 16.4 [omap2_mcspi] | 20:58 |
| DocScrutinizer05 | 15263 709 root R 1756 0.7 11.7 sshd: root@pts/2 | 20:58 |
| 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 | 20:58 |
| DocScrutinizer05 | . | 20:59 |
| DocScrutinizer05 | . | 20:59 |
| DocScrutinizer05 | 10 2 root SW 0 0.0 17.6 [omap2_mcspi] | 20:59 |
| DocScrutinizer05 | 15685 15263 root R 776 0.3 17.0 -sh | 20:59 |
| 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 | 20:59 |
| DocScrutinizer05 | 15263 709 root S 1724 0.7 14.7 sshd: root@pts/2 | 20:59 |
| DocScrutinizer05 | 3956 2896 root R 284 0.1 8.6 ./childspin | 20:59 |
| kerio | mispaste? | 20:59 |
| DocScrutinizer05 | indeed, I should prolly kick myself | 21:00 |
| kerio | no! don't do it! | 21:00 |
| DocScrutinizer05 | anyway, still running | 21:00 |
| DocScrutinizer05 | I'll start a second childspin on device xterm, so no overhead for WLAN ssh | 21:02 |
| kerio | you spin me right round baby right round like a record baby right round round round | 21:02 |
| DocScrutinizer05 | 2 childspin running | 21:04 |
| DocScrutinizer05 | CPU: 40.0% usr 54.8% sys 0.0% nice 0.0% idle 0.0% io 0.1% irq 4.8% softirq | 21:04 |
| * DocScrutinizer05 twiddles thumbs | 21:05 | |
| kerio | no, the thumb bug is a different one! | 21:05 |
| DocScrutinizer05 | well, newsflash time | 21:05 |
| merlin1991 | ... | 21:08 |
| DocScrutinizer05 | 20906 3700 root R 288 0.1 3.7 ./childspin | 21:08 |
| DocScrutinizer05 | 3956 2896 root S 284 0.1 3.1 ./childspin | 21:08 |
| merlin1991 | R / S meaning? | 21:09 |
| merlin1991 | running and suspended? | 21:09 |
| merlin1991 | shouldn't that be R and R? | 21:09 |
| merlin1991 | (if the bug does not exist) | 21:09 |
| merlin1991 | ah wait 1 core can only be R? | 21:10 |
| *** taziff1 has quit IRC | 21:14 | |
| DocScrutinizer05 | mv RSOC CSOC mA NAC CACD CACT TTF TTE TEMP | 21:15 |
| 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 | 21:15 |
| DocScrutinizer05 | there's always only one R iirc | 21:15 |
| DocScrutinizer05 | actually nope | 21:16 |
| DocScrutinizer05 | the childspin only is R if it doesn't just wait on pselect() | 21:17 |
| RST38h | Hey, Doc, rumors say someone got hardware audio filter work on N900? | 21:18 |
| RST38h | Will that kernel patch be in CSSU, with software filter disabled? =) | 21:18 |
| DocScrutinizer05 | rumors say i'm running two childspin since hours, happily | 21:24 |
| DocScrutinizer05 | 3956 root 20 0 S - - - 2:44.84 5.0 0.1 ./childspin | 21:25 |
| DocScrutinizer05 | 20906 root 20 0 S - - - 0:44.24 3.0 0.1 ./childspin | 21:25 |
| DocScrutinizer05 | while the renice -5; i=1; while true; do echo $(( i++ )); done is at 2500000 meanwhile | 21:26 |
| DocScrutinizer05 | merlin1991: I'm sorry, but.... | 21:27 |
| DocScrutinizer05 | merlin1991: please recheck your source of childspin | 21:27 |
| DocScrutinizer05 | HAAAAHAAAAHAAAAAAAAAAAAAAAAAAA it hanfgs | 21:28 |
| DocScrutinizer05 | hangs | 21:28 |
| DocScrutinizer05 | 3956 root 20 0 S - - - 2:51.02 0.0 0.1 ./childspin | 21:30 |
| DocScrutinizer05 | ~ # strace -p 3956 | 21:32 |
| DocScrutinizer05 | Process 3956 attached - interrupt to quit | 21:32 |
| DocScrutinizer05 | select(0, NULL, NULL, NULL, NULL | 21:32 |
| DocScrutinizer05 | while... (SPAM!) | 21:35 |
| DocScrutinizer05 | clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x4001cc38) = 30839 | 21:35 |
| DocScrutinizer05 | rt_sigprocmask(SIG_SETMASK, [], [CHLD], 8) = 0 | 21:35 |
| DocScrutinizer05 | select(0, NULL, NULL, NULL, NULL) = ? ERESTARTNOHAND (To be restarted) | 21:35 |
| DocScrutinizer05 | --- SIGCHLD (Child exited) @ 0 (0) --- | 21:35 |
| DocScrutinizer05 | sigreturn() = ? (mask now [QUIT ILL TRAP ABRT BUS KILL PIPE CHLD CONT STOP TSTP URG XCPU VTALRM PROF WINCH IO PWR RTMIN]) | 21:35 |
| DocScrutinizer05 | rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 | 21:35 |
| DocScrutinizer05 | wait4(30839, NULL, 0, NULL) = 30839 | 21:35 |
| DocScrutinizer05 | write(1, ".", 1) = 1 | 21:35 |
| DocScrutinizer05 | . | 21:35 |
| DocScrutinizer05 | on the other still running spinchild | 21:36 |
| DocScrutinizer05 | merlin1991: ok, confirmed. we (very rarely) see that bug | 21:37 |
| DocScrutinizer05 | it's however impossible to say how much impact it has in real life - not that this would matter | 21:38 |
| 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 | 21:39 |
| DocScrutinizer05 | I'll eventually summ up the results and post to ML, if I can find a thread to attach it to | 21:40 |
| jon_y | wow, my irc buffer | 21:42 |
| jon_y | some soccer mom is going to have a rampage if she sees spin, child, kill in the same sentence :) | 21:43 |
| DocScrutinizer05 | merlin1991: could you please build and provide spinchild-sim? with -DUSE_SELECT | 21:45 |
| 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 | 21:47 |
| *** NIN101 has quit IRC | 21:48 | |
| DocScrutinizer05 | otoh it explains how this bug could sneak in and hide all the time | 21:48 |
| 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 | 21:51 |
| DocScrutinizer05 | CPU time of dbus daemon: 67s | 21:52 |
| DocScrutinizer05 | 3956 root 20 0 S - - - 2:51.02 0.0 0.1 ./childspin | 21:52 |
| DocScrutinizer05 | childspin hung after 171s CPU time | 21:52 |
| DocScrutinizer05 | (btw the other dbus daemon [for systembus] has just 20s more CPU time) | 21:54 |
| DocScrutinizer05 | FWIW | 21:54 |
| DocScrutinizer05 | Uptime: 2 days, 01:57:07 | 21:55 |
| 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 | 21:56 |
| DocScrutinizer05 | when comparing it to CPU time spinchild needed to finally freeze | 21:57 |
| *** nox- has joined #maemo-ssu | 22:02 | |
| *** BCMM_ has joined #maemo-ssu | 22:09 | |
| *** BCMM has quit IRC | 22:12 | |
| *** BCMM_ is now known as BCMM | 22:12 | |
| *** freemangordon_ has joined #maemo-ssu | 22:15 | |
| freemangordon_ | doc, run childspin, run HAM, choose to edit the catalogs and rotate the device. hang happens as soon as HAM starts the rotation | 22:17 |
| 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 | 22:19 |
| DocScrutinizer05 | freemangordon_: well, it finally triggered here anyway, and I fail to see how we'd need IO load to trigger it | 22:20 |
| DocScrutinizer05 | aiui it's just about preemtion after the sigmask() before the select() | 22:22 |
| DocScrutinizer05 | for this preemption it should suffice to run other process with higher prio | 22:22 |
| * DocScrutinizer05 idly looks for state of on-device spinchild... | 22:23 | |
| freemangordon_ | what I am saying, is that you assessment about how often we'll be hit by the bug, is a little bit low :-) | 22:23 |
| DocScrutinizer05 | 20906 root 20 0 S - - - 7:46.94 11.0 0.1 ./childspin | 22:24 |
| DocScrutinizer05 | 7min47 CPU | 22:24 |
| DocScrutinizer05 | running | 22:24 |
| freemangordon_ | a wild guess- media player widget could be the the one that suffers from that bug | 22:25 |
| DocScrutinizer05 | freemangordon_: I started HAM | 22:25 |
| freemangordon_ | it deffinitely misses dbus signals. thugh i might be speaking bullshit as well :-D | 22:25 |
| DocScrutinizer05 | freemangordon_: no portrait mode here, so rotating won't help ;-P | 22:25 |
| freemangordon_ | well, HAM should rotate anyway (if you are on testing) | 22:26 |
| DocScrutinizer05 | it doesn't | 22:26 |
| freemangordon_ | you could enable force rotation ;-) | 22:26 |
| DocScrutinizer05 | dafaq | 22:26 |
| DocScrutinizer05 | I enabled forbid-rotation | 22:26 |
| freemangordon_ | well, trust me on that then (tm) :-P | 22:27 |
| DocScrutinizer05 | mind you, we're trying to test this on a system as normal as possible | 22:27 |
| DocScrutinizer05 | don't give me ideas why CSSU has to bin portrait mode | 22:28 |
| DocScrutinizer05 | ;-P | 22:28 |
| freemangordon_ | naah :-D | 22:28 |
| DocScrutinizer05 | anyway, green light for minimalistic CSSU-kernel from my side | 22:28 |
| freemangordon_ | doc, meeting request was sent yesterday 7 am UTC to maemo-developers | 22:29 |
| DocScrutinizer05 | which other bugfix patches would we need to pull in to cssu kernel? | 22:29 |
| freemangordon_ | I really appologise I forgot you are on holiday | 22:29 |
| DocScrutinizer05 | I'm not on holiday, I'm simply not reading MLK on a regular basis | 22:30 |
| DocScrutinizer05 | ML* | 22:30 |
| freemangordon_ | seems you are not the only one ;-) | 22:30 |
| freemangordon_ | anyway, I am on holyday right now, will be back home tomorrow | 22:31 |
| DocScrutinizer05 | I got not enough hours in the day to read all my ML | 22:31 |
| DocScrutinizer05 | (green light) for pondering how to roll that | 22:32 |
| freemangordon_ | according to what was decided, we'll have to go through all the pathes in KP and evaluate what to be removed | 22:32 |
| DocScrutinizer05 | we still need to think carefully about any pitfalls we might face | 22:32 |
| freemangordon_ | sure | 22:33 |
| DocScrutinizer05 | with repos, conflicts, whatever | 22:33 |
| freemangordon_ | well, if we use "kernel", we'll have lots of problems solved | 22:33 |
| freemangordon_ | including KP uninstaller ;-) | 22:33 |
| freemangordon_ | thanks hxka, if you read that someday | 22:34 |
| * DocScrutinizer05 moves to TV again, for NCIS | 22:34 | |
| 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 | 22:35 |
| freemangordon_ | will be hanging around though | 22:35 |
| 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 | 22:44 |
| DocScrutinizer05 | anyway you see how difficult it might get to reproduce a well documented and understood bug | 22:48 |
| DocScrutinizer05 | how much worse might it get when it comes to thumb-SiErr, or SR borkedness | 22:49 |
| freemangordon_ | doc, it does not make sense to try to recreate race condition bug with only one active process | 22:50 |
| DocScrutinizer05 | there are 2 other processes active, at niceness -10 and -15 | 22:56 |
| DocScrutinizer05 | CPU: 40.6% sy: 55.7% | 22:57 |
| freemangordon_ | io deffinitely plays here, though i didn't think why | 22:58 |
| DocScrutinizer05 | while I rethink the effectiveness of my renice cmd | 23:00 |
| freemangordon_ | doc, do you have any app supporting portrait? | 23:02 |
| *** MrPingu has joined #maemo-ssu | 23:04 | |
| DocScrutinizer05 | portrait is locked on my device | 23:05 |
| DocScrutinizer05 | except for dialer ;-P | 23:05 |
| freemangordon_ | :-) | 23:06 |
| DocScrutinizer05 | cal me noob, my shellcmd fu is weak | 23:11 |
| DocScrutinizer05 | renice and even nice didn't work like expected, prollay thanks to fscking messybox | 23:12 |
| DocScrutinizer05 | finally renicing the endless loop to -15 instantly killed childspin (though no causality proven by one incidence) | 23:13 |
| DocScrutinizer05 | freemangordon_: ^^^ I bet you love to hear that | 23:13 |
| freemangordon_ | hmm, why rising prio should trigger the bug? well, child prosess also have the same prio, but so what? | 23:15 |
| 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 | 23:15 |
| freemangordon_ | :nod: | 23:15 |
| DocScrutinizer05 | obviously all the CPU load in the world can't preempt a childspin on same niceness level | 23:16 |
| DocScrutinizer05 | a higher prio / lower niceness process does - immediately | 23:16 |
| freemangordon_ | well, i am glad you are convinced it is severe problem | 23:24 |
| DocScrutinizer05 | a bug in kernel is always a severe problem | 23:27 |
| DocScrutinizer05 | a severe problem requires honest investigation to completely understand the impact and risks | 23:28 |
| DocScrutinizer05 | only after completely understanding the problem, you can come up with the right solution | 23:29 |
| DocScrutinizer05 | which in this case seems to roll a patched kernel and lib | 23:29 |
| DocScrutinizer05 | ouch my grammar | 23:29 |
| freemangordon_ | :-) | 23:29 |
| 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() | 23:31 |
| DocScrutinizer05 | so the alternative approach to fix all apps that are affected fails | 23:31 |
| DocScrutinizer05 | which leaves us with the only feasible solution to fix the root cause, however painful it might be from a maintenance POV | 23:32 |
| 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 | 23:35 |
| DocScrutinizer05 | which is kinda of my iltimate ratio regarding this CSSU compatibility fsckup we're going to commit here | 23:37 |
| DocScrutinizer05 | ultimate even | 23:38 |
| DocScrutinizer05 | which doesn't mean we can go all loose now once we broke compatibility a tiny bit, and roll kernel-3.2 now | 23:39 |
| DocScrutinizer05 | neither PK51 | 23:39 |
| 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 | 23:40 |
| freemangordon_ | hmm, 3.2 sounds nice :-P . too bad we don't have working adaptation :-D . | 23:40 |
| *** BCMM_ has joined #maemo-ssu | 23:40 | |
| freemangordon_ | anyway, I gtg, night | 23:40 |
| *** freemangordon_ has left #maemo-ssu | 23:40 | |
| DocScrutinizer05 | n8 freemangordon | 23:40 |
| jon_y | wait what, kernel-3.2 on the n900? | 23:41 |
| jon_y | DocScrutinizer05: possible? | 23:45 |
| DocScrutinizer05 | no | 23:45 |
| DocScrutinizer05 | at least not for maemo | 23:45 |
| jon_y | ok, too much patches to port forward? | 23:46 |
| DocScrutinizer05 | too much blobs not possible to port forward | 23:50 |
| DocScrutinizer05 | many* | 23:50 |
| jon_y | damn proprietary bits | 23:50 |
| jon_y | what about minor version bumps? | 23:51 |
| jon_y | eg to 2.6.3x | 23:51 |
| DocScrutinizer05 | this is handled by PK via backporting stuff | 23:55 |
| jon_y | very nice | 23:59 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!