**** BEGIN LOGGING AT Fri May 25 02:59:59 2012 May 25 05:59:10 *yawn* May 25 05:59:27 * chem|st drops a pott of coffee in the channel May 25 06:00:11 * fastlane` yawns out loud even May 25 06:03:40 * DocScrutinizer mumbles something May 25 06:04:12 cehteh: the circuit seems rather nifty May 25 06:04:33 cehteh: hard to find sth better and simpler May 25 06:05:11 cehteh: probably only possible by redefinition of "simple" May 25 06:10:32 my 'new' laptop is on its way... *finally* May 25 06:11:14 500GB of free space, I think there's some left over for SB ;-D May 25 06:15:46 so what are the configurations of your new laptop May 25 06:16:08 docscrutinizer May 25 06:18:11 DocScrutinizer, I decided on slightly different approach re thumb2 erratas - ALWAYS set IBE bit on board init, disable it later through sysfs if needed. Any comments? May 25 06:18:46 an old used lenovo t500, with 8GB and 500GB storage May 25 06:19:13 freemangordon: well, not much of a difference, nothing a initscript couldn't handle anyway May 25 06:19:48 it's even arguable if that's maybe the better config, as it alows early boot binaries ith thumb interworking May 25 06:20:19 yeah, that is why i choose it May 25 06:20:29 sounds all ok to me May 25 06:25:06 (t500) I hope to teach linux/X11 to properly switch between 'internal' and auxiliary graca May 25 06:25:57 hell, win7 knows to switch on the fly, so linux will be able to learn that too, no? May 25 06:27:02 * DocScrutinizer anticipates heavy patching sessions against xserver May 25 07:11:57 Pali, ping May 25 07:30:36 http://www.theregister.co.uk/2012/05/24/another_installment_of_patent_stupidity/ <-- hahaha May 25 08:26:38 DocScrutinizer: there might be some problems with intel+fglrx/radeon (I am just guessing the setup) May 25 08:27:05 lot of people drop into #ati asking about that May 25 08:38:46 Estel_: pong May 25 10:04:33 ~seen javiespedro May 25 10:04:37 freemangordon: i haven't seen 'javiespedro' May 25 10:05:50 ~seen javispedro May 25 10:05:51 javispedro <~javier@Maemo/community/contributor/javispedro> was last seen on IRC in channel #maemo, 2d 18h 47m 24s ago, saying: 'that'd make for interesting performance counters'. May 25 10:06:08 teotwaki, thanks May 25 10:29:08 chem|st: yeah, I'm aware of the (heating) problems when enabling both gracas May 25 10:30:33 chem|st: since I'm using the t500 for 99.99% just stationary, I might as well go for 'external' card only setup May 25 10:31:41 +1 May 25 10:32:17 btw DHL delivered, just can't wait to come home May 25 10:35:03 ;) May 25 10:36:07 I cannot wait to get home to have a full 3 days WE without electronics but my phone^^ May 25 12:17:33 Jaffa, re-ping May 25 12:18:38 strange, if I reboot device and left it overnight, then try powertop, it properly enters c3 state May 25 12:18:50 DocScrutinizer51: a friend ov3r here ordered an n9 saying "a good way to show nokia that I still like them but not wp" alike May 25 12:19:27 but, something from normal usage tings make it to sit in C1 all the time. either wifi-adhoc enabling and disabling, or charging... May 25 12:19:33 * Estel_ investigates May 25 12:19:56 that sounds like a PR1.2 bug... May 25 12:22:15 Estel_: re-pong May 25 12:34:26 Does anyone remember, how to set maemo mailing list to forward all messages directly, instead of daily batches? May 25 12:34:29 Hmm, that "Battery low" blomp sound Maemo starts making is annoying me more as time passes. May 25 12:34:50 Need to see where it is disabled. May 25 12:35:05 do share ocne u find out Raimu May 25 12:35:21 is it just neccessary to set up subscribtion without "yes" to "would like to receive batches"? as now I'm receiving only batches, for months actually May 25 12:36:10 chem|st, not possible, I haven't encountered it for ages, afaik kernel-power fixed it long time ago May 25 12:36:17 maybe unsubscribe and resubscribe Estel_ May 25 12:36:22 although, it also ressembled me such old bug May 25 12:36:36 fastlane`, hm May 25 12:37:51 chem|st, maybe something in cssu or kp broke old fix, I'm checking it now May 25 12:38:51 btw, does anyone know, I downloaded the latest qt sdk 1.2.1, it has the harmattan target but not fremantle, so where can I add that target? May 25 12:46:20 Estel_: KP fix for booting issue May 25 12:46:52 possibly breaks USB activation/C1 fix in KP May 25 13:17:25 DocScrutinizer51, why is that? May 25 13:17:51 DocScrutinizer, denied, I can't reproduce it now May 25 13:17:56 idk wtf May 25 13:18:04 it was bugging me whole yesterday May 25 13:18:34 I tried wifi ad hoc, fm radio (with terminating it wrong way) May 25 13:18:36 charging May 25 13:18:50 in all combinations, and CPU properly enters C4 May 25 13:19:28 yesterday, and for few days already, it got stuck on C1 without any reasons - low ammount of hw wakeups etc May 25 13:19:58 dunno why. easdy debians's xbindkeys was keeping cpu in c3, but it isn't related to main issue May 25 13:20:24 Estel_, you should check your voltages, your last issue, along with previous issue with 720p, smells like too much undervolting May 25 13:20:27 for last few days I was using, mainly, ad hox wifi, fm radio and charging :( no idea wtf May 25 13:20:42 or too much OC May 25 13:20:56 freemangordon, tried on dsp setting with stock range May 25 13:21:22 BTW common things for all occurences of problem - after reboot, for some time, cpu enters C4 all right May 25 13:21:35 then, after long usage, "something" trigger some bug May 25 13:21:51 sure, but you know DSP OC combined with SR is unstable on some devices May 25 13:22:01 and CPU is in C1 all the time (0.01 % time in C2, so it "tries") May 25 13:22:07 yea. May 25 13:22:17 yours being one of them :) May 25 13:22:22 hm, it was working fine for months, but who knows May 25 13:22:40 with KP50? I doubt May 25 13:22:42 ok, so if I got hit by it again May 25 13:22:54 what to do to confirm/deny? May 25 13:23:06 Estel_, do you use u-boot by chance? May 25 13:23:10 I'll use device as normal, and check powertop May 25 13:23:12 no, not yet May 25 13:23:34 multiboot, while booting only one kernel (power) :P May 25 13:23:48 ok. as it was behaving like that when L2 cache was disabled, because of a bug in some of the older versions of u-boot May 25 13:24:00 yea, remember about that May 25 13:24:04 latest is fine May 25 13:24:36 hm, so, lets say at evening I check powertop and CPU is stuck at C1 as lowest state May 25 13:24:42 what should I try? May 25 13:24:48 NFC May 25 13:24:49 disabling sr? May 25 13:24:53 yeah, maybe May 25 13:25:07 it doesn't require reboot to activate? May 25 13:25:17 no, it is changed on-the-fly May 25 13:25:19 maybe disable dsp overclock May 25 13:25:21 too May 25 13:25:38 you should try "default" profile May 25 13:25:52 it has range 250-600, no DSP OC, and SR on May 25 13:25:59 and check if problem persist. although something tells me its unrelated. It reminds me of pr 1.2 C1 error too much May 25 13:26:06 ok May 25 13:26:15 (152225 hm, it was working fine for months, but who knows) Estel_ that's the very nature of OC and EM: the chip wears out May 25 13:26:57 DocScrutinizer, can't filter it out as source of issue, although I doubt it. well, will try without dsp OC and mpu OC May 25 13:27:23 I doubt it, as it would be first really confirmed case of such nature, using sane overclocking (900 mhz max) May 25 13:27:42 so lets wait for confirmation, or another OC FUD will arise May 25 13:28:11 odds are the damage done to silicon isn't reversible by reverting to 'normal' clodck and voltage settings May 25 13:29:15 damage to silicon, that behaves like software bug and keep cpu in C1 state only, when certain software conditions are meet? I doubt it, but of course will keep and eye on it May 25 13:29:33 I would rather think that for last few days I'm using things that are rarely used May 25 13:29:42 both by me and by majority of users May 25 13:29:47 DocScrutinizer51, sound reasonable, but AFAIK once once EM hits, there's no way back May 25 13:30:08 = ad-hoc wifi for prolonged period of time, + fm radio program with is buggy as hell. May 25 13:30:17 I even got idea, but no way to check it out May 25 13:30:29 I remember, that everytime I got call during using fm radio... May 25 13:30:36 it stucks beyond "repair" May 25 13:30:40 need to kill it May 25 13:30:43 hard way May 25 13:30:53 then, i can restart it and listen again May 25 13:30:56 Estel_, BTW you said early SSH is the reason for "shutdown" bug, can you confirm it May 25 13:31:03 maybe it's keeping something out of proper state May 25 13:31:30 i say that /default/kernel-boot entry for "*early ssh" can be reason for reboot bug May 25 13:31:42 for me, after disabling it, reboot works May 25 13:31:49 i see May 25 13:31:54 but would need to confirm it from someone who was not hit by bug May 25 13:32:00 i.e You :P May 25 13:32:10 enable it and reboot few times May 25 13:32:58 it should fail approx. 50% of times at least May 25 13:33:17 ok, will check it when have a time May 25 13:33:35 btw, if until late evening I won't get hit by C1 bug, I'll buggy someone to call me while listening to radio and ad-hoc'ing May 25 13:33:52 thanks, report back, maybe we've found it after so many years :P May 25 13:34:26 tried killing fm radio hard way without call, but then it behaves ok May 25 13:34:41 it seems that only heavy usage + call makes it go bananas May 25 13:35:06 then, even after end of call and heavy usage ceased, You can't listen to radio again May 25 13:35:11 and app is "frozen" May 25 13:35:27 without messages about disabling fm module etc May 25 13:36:02 btw I wonder why xbindkeys keeps cpu in C3 instead of C4 (200+ wakeups per 30 sec by xbindkeys from easy debian) May 25 13:36:21 I was using it for more than a year, and haven't encountered decreased battery life May 25 13:36:30 but fact is, that it keeps CPU in C3 May 25 13:37:00 so it must have some effect, even if not noticeable in real life May 25 13:37:23 will check if Maemo's xbindkeys act like that too. May 25 13:38:06 btw yesterday I got my shipment of 4 top-quality replacement styluses from china for 1$ each :P May 25 13:38:27 I had to pretend I'm sales manager of one big gsm company in poland to get them May 25 13:38:38 otherwise, only sold as 5000 units min. May 25 13:38:41 :P May 25 13:39:33 those 4 are from exact same plastic type, just without Nokia's logo. other replacements I tried were too elastic and "cheap", despite having unnecessary nokia logo May 25 13:39:44 my son managed to bite out tip from replacement, lol May 25 13:40:01 now I again feel those thing when taking stylus out from N900 May 25 13:40:15 and this "whiiiz" sound, like taking sword off :P May 25 13:40:35 cheap elastic replacements doesn't make such sound May 25 13:41:21 feel like Witcher again, when taking stylus off N900. I should paint xkcd-style comic about that May 25 13:45:17 ... about N900 user/Wicther, that got task to cure King's daughter Nokia, cursed to be WP and eating people every full moon May 25 13:45:30 ;) May 25 13:46:24 ...and betrayder Elop, who is responsible for cursing "Young" princess. Haha, this pun is understandable only for readers of Sapkowski's books May 25 13:46:45 and/or Witcher rpg players ;) May 25 13:52:08 http://imagebin.org/index.php?mode=image&id=213819 May 25 13:54:46 also, Reuter's coverage of Maxim 100's most beautiful women includes... 50 pictures. May 25 14:59:04 hm, Maemo's xbindkeys allow cpu to enter C4 state normally, so easy debian's xbindkeys may be called depreciated, as it keeps CPU in C3 May 25 14:59:23 power loss isn't terriblr (or, honeslty, almost not noticeable) but still May 25 14:59:58 anyway, I got little problem - I can't run Maemo's xbindkeys via script in /etc/event.d/ on boot 0_o May 25 15:00:29 script actually tries to run it, but it doesn't work May 25 15:00:48 if I run it manually, it works ok May 25 15:00:55 any ideas wtf? May 25 15:01:16 maybe it's run too early, or maybe it has wrong environment. May 25 15:01:19 it just require running it as user, "xbindkeys" May 25 15:01:35 I tried - in script in etc/event.d - to: May 25 15:01:48 osso-xterm 'xbindkeys' May 25 15:01:49 and May 25 15:02:03 osso-xterm 'run-standalone.sh xbindkeys' May 25 15:02:09 ...why would you run it through osso-xterm? May 25 15:02:25 because it doesn't work otherwise at all May 25 15:02:31 blocking rest of script May 25 15:02:39 i.e. i have truecrypt entry as next line May 25 15:02:53 if I try without osso-xterm, next line doesn't even start May 25 15:02:59 I seriously doubt it requires osso-xterm to function May 25 15:03:03 formerly, I've used May 25 15:03:11 rather you need to instruct upstart to start the process in the background May 25 15:03:15 osso-xterm 'debbie xbindkeys' May 25 15:03:19 I don't remember how that's done, though May 25 15:03:24 as I've used easy debian one May 25 15:03:30 it also worked only via osso-xterm May 25 15:03:47 but worked well (despite xbindkeys from ed keeping cpu in c3) May 25 15:03:50 flux, I see May 25 15:03:53 hm May 25 15:04:57 current script is "start on started hildon desktop" May 25 15:05:20 and "stop on starting shutdown" May 25 15:06:11 everything except xbindkeys work like that May 25 15:06:24 setting sysfs entry to disable indicator led for camera... May 25 15:06:34 truecrypt dialog for mounting partition May 25 15:06:49 mounting debian partition via 'debbie exit' :P May 25 15:06:56 only xbindkeys fail to start May 25 15:07:03 of course I may run it manually May 25 15:07:31 but if someone would have idea how to properly automate it via /etc/event.d script like my other things, I would be very grateful May 25 15:07:50 Estel_, maybe it should wait until h-d is started May 25 15:08:17 hm, "start on started hildon desktop" May 25 15:08:23 isn't exactly that? May 25 15:08:30 yep, something like that May 25 15:08:37 but it's like that already May 25 15:08:38 should be hildon-desktop May 25 15:08:51 current script is "start on started hildon desktop" May 25 15:08:54 hm May 25 15:09:07 start on started hildon-desktop May 25 15:09:22 You're telling me that for more than a year I'm using wrong command? :P May 25 15:09:32 quite funny, but it seems You're right May 25 15:09:48 if yes, wiki article is wrong May 25 15:09:49 well, there should be several scripts depending on hildon-desktop, check those for the correct dependency May 25 15:09:56 aye. May 25 15:11:51 it seems You're right, all of them start on hildon-desktop May 25 15:12:16 oh god I'm idiot May 25 15:12:17 don't forget to edit the article on wiki May 25 15:12:29 no, I have it hildon-desktop May 25 15:12:36 just I'm pastefail master May 25 15:12:40 DocScrutinizer already told ya :P May 25 15:12:49 :P true May 25 15:13:05 so, it fails despite being run after starting hildon-desktop May 25 15:13:08 wtf? May 25 15:13:37 if I set it to start after truecrypt window and via osso-xterm I even see flashing xterm window... May 25 15:13:39 do you have DISPLAY variable in place? May 25 15:13:52 aah, ok May 25 15:13:55 and it's run after everything settled down long time ago, yet, not working May 25 15:14:02 display variable? May 25 15:14:26 yeah, export DISPLAY=:0 May 25 15:14:34 for xbindkeys?! May 25 15:14:51 but if I see it, it seems it's set properly, yes? May 25 15:15:13 hmm, it is x... after all, but I may be wrong May 25 15:15:43 it's super strange, as it's first thing I've seen that doesn't start properly via event.d and being run after hildon-desktop started May 25 15:15:51 but works from hand May 25 15:16:12 maybe I should create .sh script and run it via event.d :P May 25 15:16:23 and same command wrapped inside sh will work? May 25 15:16:59 need to test it May 25 15:22:53 hey, I got idea why it may be not working May 25 15:23:03 I got my config in /home/user/.xbindkeysrc May 25 15:23:08 it expect it there May 25 15:23:27 but, when run as root, it expect it in /root/.xbindkeysrc May 25 15:23:34 which doesn't exist May 25 15:23:58 maybe things started via event.d got root bits? May 25 15:24:14 but, debbie works, and when run as root it complains, normally... May 25 15:27:50 Estel_, well, try it with su May 25 15:35:09 nonsense, processes started via init.d/* have no home at all May 25 15:35:28 and no real user in that sense May 25 15:35:53 they got root *permissions* May 25 15:36:10 but no root-user environment May 25 15:36:55 neither $PATH nor $HOME nor anything else associated to *real* users May 25 15:37:37 aah, and event.d is all the same like init.d in that regard May 25 15:37:52 ~botsnack May 25 15:37:52 :), DocScrutinizer51 May 25 15:41:34 particularly about running X-session stuff from init.d we had a lengthy discussion in this very chan iirc, some weeks ago. searchterm: xhost May 25 15:45:38 hm, true, copying config to /root/.xbindkeysrc doesn't help May 25 15:45:45 wrapping inside sh script too. May 25 15:46:57 just can't make it to work, despite it should. May 25 16:24:56 Estel_: wrapping imto anyrhing won't help. Use proper fully qualified pathnames for *all* commands and files May 25 16:25:17 did that already :( May 25 16:25:31 it "seems" to work, i.e. exit with proper code May 25 16:25:41 yet it doesn't seem to be running May 25 16:25:51 if I start it by hand/script/whatever, but not from event.d it works May 25 16:25:57 then you still got the problem that this preocess is no child of xserver May 25 16:26:09 much more complicated things like debbie (.sh script to start debian chroot) works well, though May 25 16:26:30 hm... any way to fix it? why iot isn't child of xserver, when other things are? May 25 16:26:49 and, I've even tried running it via osso-xterm "xbindkeys" May 25 16:27:07 check chanlogs for "xhost" May 25 16:27:36 hi. did any of you switch from n900 some kind of android phone and liked it? May 25 16:27:53 there are for sure better ways than xhost May 25 16:32:02 ok, will try it May 25 16:32:22 ioan, I got NON-pleasure for setting up android phone for family member May 25 16:32:28 installing cyanogenmod and such things May 25 16:32:32 Nevermore! May 25 16:32:51 * Estel_ spreads out black wings and flies out of the window May 25 17:28:09 ~seen SD69 May 25 17:28:23 sd69 was last seen on IRC in channel #maemo, 33d 2h 45m 2s ago, saying: 'any thoughts on cOBS from cssu pov?'. May 25 17:28:41 ~seen ivgalvez May 25 17:28:42 ivgalvez <598c718a@gateway/web/freenode/ip.89.140.113.138> was last seen on IRC in channel #maemo-ssu, 3d 3h 23m 59s ago, saying: 'sorry, we are polluting this room'. May 25 17:44:45 ping x-Fade May 25 17:44:52 ping X-Fade May 25 17:44:56 ~seen X-Fade May 25 17:44:57 x-fade is currently on #maemo #harmattan #meego #maemo-ssu. Has said a total of 13 messages. Is idling for 1d 7h 54m 36s, last said: 'Maemo Council election results: http://maemo.org/vote/results.php?election_id=20'. May 25 18:33:37 the 'syntax' is: : ping May 25 19:24:25 ping freemangordon May 25 19:30:19 freemangordon, bq2415x charger driver working fine May 25 19:30:34 I published all patches to kernel-power garage git May 25 19:31:00 and deb packages are here: http://atrey.karlin.mff.cuni.cz/~pali/bq2415x/ May 25 19:31:48 I created new patch for hostmode which export sysfs entry: /sys/devices/platform/musb_hdrc/hostdevice May 25 19:32:13 it contains speed of attached usb device after boost May 25 19:32:42 so user space script can: choose some speed, enable boost, check hostdevice if correct May 25 19:33:21 and do not depends on some output from dmesg May 25 19:34:45 and when that sysfs file is changes, kernel call sysfs_notify so userspace apps can call poll or select May 25 19:35:25 also some info about charging and hostmode is on: http://atrey.karlin.mff.cuni.cz/~pali/projects/maemo/bq2415x.html May 25 19:35:38 DocScrutinizer, see ^^^ May 25 20:14:29 Pali: cool, will check later May 25 20:14:57 ok, note that charger autodetection working fine May 25 20:16:31 hmm, looks like i missed out on some good info here May 25 20:16:40 * Sicelo turns to the logs May 25 20:19:12 sure, charger detection is simple. The real problem kicks in with hostmode and VBUS applied or generated May 25 20:20:16 for the "generated VBUS" part that's easy when the module itself is creating vboost May 25 20:20:37 for charging hostmode it will be more problem May 25 20:21:52 as checking for fastcharger spoils any peripheral negotiating ENUM etc over VBUS, and both events happen concurrently when you apply VBUS externally May 25 20:24:25 as USB host you *must* pulldown bith D-lines by 12k May 25 20:25:03 for detecting D+. short you *need* to pullup one D-line May 25 20:26:26 pullup of any of the D-lines however is a signal for USB host that peripheral has been attached, and depending on which line gets pulled up, it's a signal for lowspeed or fullspeed May 25 20:27:56 hat's why hostmode kernel patches had a kprintf("some asshole calling charger-detect() while we are in hostmode") May 25 20:28:28 DocScrutinizer, I do not have Y cable for testing now (and I do not have much time for experiments now), but if somebody other has time for testing... May 25 20:29:06 but autodetection is disabled when you enter to host mode May 25 20:29:13 so I think it should work May 25 20:29:19 Pali: \m/ May 25 20:29:25 yep May 25 20:29:37 (of cource if somebody do not cat /sys/.../musb/connect) May 25 20:30:42 abyway my lenovo psu is DOA, and I'm possed and off for dinner and booze now May 25 20:31:03 anyway* and pissed* May 25 20:31:08 at least, we need to create new hostmode script which will use bq2415x driver May 25 20:31:11 and also /sys/devices/platform/musb_hdrc/hostdevice May 25 20:31:22 watching indiana jones at the last crusade May 25 20:31:44 back in the day when people would mail stuff in brown paper May 25 20:33:34 they always do the red line thing don't they? May 25 20:40:54 HELL May 25 20:41:25 plugging in a charger w/o D+-short causes: May 25 20:41:32 22:39 3734 31 31 -13 357 357 357 65535 1538 28 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 May 25 20:41:33 22:39 3617 31 31 -144 357 357 357 65535 149 29 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 May 25 20:41:53 DIScharge jumps from 13mA to 144mA May 25 20:43:16 it is with or without my patches? May 25 20:48:05 stock kernel May 25 20:48:12 22:45 3694 30 30 -24 349 349 349 65535 845 28 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 May 25 20:48:13 22:45 3700 30 30 -27 349 349 349 65535 774 28 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 May 25 20:48:15 May 25 22:45:41 IroN900 ke_recv[1927]: prop_modified:1901: udi /org/freedesktop/Hal/devices/usb_device_1d6b_2_musb_hdrc modified usb_device.vbus May 25 20:48:16 May 25 22:45:41 IroN900 systemui-tklock[1298]: Method call received from: :1.15, iface: com.nokia.system_ui.request, method: tklock_close May 25 20:48:18 May 25 22:45:44 IroN900 cellular: csd[797]: ISI_SMS .644196> ind_reg_status(): Net registration (ind) status:1 rc:0 May 25 20:48:19 May 25 22:45:44 IroN900 cellular: csd[797]: ISI_SMS .645477> set_timeout(): Timeout 27 s event type:-1 May 25 20:48:21 22:45 3612 30 30 -116 349 349 349 65535 180 29 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 May 25 20:48:22 May 25 22:45:52 IroN900 cellular: csd[797]: ISI_SMS .633515> ind_reg_status(): Net registration (ind) status:1 rc:0 May 25 20:48:24 May 25 22:45:52 IroN900 cellular: csd[797]: ISI_SMS .634766> set_timeout(): Timeout 19 s event type:-1 May 25 20:48:26 22:45 3631 30 30 -115 349 349 349 65535 182 29 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 May 25 20:48:28 May 25 22:46:05 IroN900 cellular: csd[797]: ISI_SMS .552613> incoming_cell_broadcast(): Incoming cell broadcast May 25 20:48:29 May 25 22:46:07 IroN900 ke_recv[1927]: prop_modified:1901: udi /org/freedesktop/Hal/devices/usb_device_1d6b_2_musb_hdrc modified usb_device.vbus May 25 20:48:31 May 25 22:46:07 IroN900 browser[2264]: GLIB CRITICAL ** hildon-1 - hildon_window_get_is_topmost: assertion `HILDON_IS_WINDOW (self)' failed May 25 20:48:32 22:46 3628 30 30 -97 348 348 348 65535 215 29 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 May 25 20:48:34 May 25 22:46:09 IroN900 kernel: [102216.049560] kb_lock (GPIO 113) is now closed May 25 20:48:35 May 25 22:46:09 IroN900 systemui-tklock[1298]: Method call received from: :1.15, iface: com.nokia.system_ui.request, method: tklock_open May 25 20:48:36 well, it seems stock ekrnel is not compatible. May 25 20:48:37 May 25 22:46:10 IroN900 kernel: [102216.361877] kb_lock (GPIO 113) is now open May 25 20:48:38 May 25 22:46:11 IroN900 cellular: csd[797]: ISI_SMS .644165> isiclient_sms_timeout(): Request TIMEOUT May 25 20:48:38 kernel* May 25 20:48:40 22:46 3697 30 30 -40 348 348 348 65535 511 29 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 May 25 20:48:41 22:46 3694 30 30 -25 348 348 348 65535 820 28 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 May 25 20:48:43 May 25 22:46:34 IroN900 cellular: csd[797]: ISI_SMS .515076> ind_reg_status(): Net registration (ind) status:1 rc:0 May 25 20:48:44 May 25 22:46:34 IroN900 cellular: csd[797]: ISI_SMS .517578> set_timeout(): Timeout 3577 s event type:-1 May 25 20:48:46 22:46 3692 30 30 -29 348 348 348 65535 707 28 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 May 25 20:48:47 May 25 22:46:43 IroN900 ke_recv[1927]: prop_modified:1901: udi /org/freedesktop/Hal/devices/usb_device_1d6b_2_musb_hdrc modified usb_device.vbus May 25 20:48:49 May 25 22:46:43 IroN900 systemui-tklock[1298]: Method call received from: :1.15, iface: com.nokia.system_ui.request, method: tklock_close May 25 20:48:50 22:46 3591 30 30 -110 347 347 347 65535 189 29 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 May 25 20:48:52 May 25 22:46:50 IroN900 cellular: csd[797]: ISI_SMS .041504> ind_reg_status(): Net registration (ind) status:1 rc:0 May 25 20:48:53 May 25 22:46:50 IroN900 cellular: csd[797]: ISI_SMS .042755> set_timeout(): Timeout 3561 s event type:-1 May 25 20:48:55 22:46 3641 30 30 -95 347 347 347 65535 217 29 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 May 25 20:48:56 May 25 22:47:05 IroN900 cellular: csd[797]: ISI_SMS .813050> incoming_cell_broadcast(): Incoming cell broadcast May 25 20:48:58 22:47 3615 30 30 -107 347 347 347 65535 193 29 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 May 25 20:48:59 OUCH May 25 20:49:06 DocScrutinizer, feel all right? May 25 20:49:09 damn, could someone kick me? May 25 20:49:28 c+p error May 25 20:49:31 * Vib3 kicks DocScrutinizer51 May 25 20:49:33 I see May 25 20:49:40 I immediately closed client May 25 20:49:48 didn't help May 25 20:49:55 ah... Nothing faster than a kick, when You require it. Faster than any support :P May 25 20:50:25 well, it seems stock kernel is not compatible. When I connect duymb charger without D=D- shorted, nothing like that happen. May 25 20:51:10 damn! May 25 20:51:21 I'm disassembling one's N900 screen May 25 20:51:28 and one of screws is... well, screwed May 25 20:51:40 everything just turns around inside screw May 25 20:51:48 and those screen screws aree *really* tight May 25 20:51:53 no idea how to unscrew it May 25 20:52:11 that's why service manual says "discard, do NOT reuse" May 25 20:52:21 screw's point for screwdriver (how it's called in english?) is totally out. May 25 20:52:24 yea, I know May 25 20:52:31 unfortunately, it was this way already May 25 20:52:54 my screws looks like new even after 5 or 6 re-screwing :P May 25 20:53:13 well N900's screw cost probably less than 1 cent, but shipping... May 25 20:53:19 anyway, any idea how to unscrew this bastard? May 25 20:53:28 no way May 25 20:53:33 would just torn it out, if it wouldn't be inside screen May 25 20:53:42 drill it out, with a left turn drill May 25 20:53:48 drilling is a no-go :P May 25 20:54:13 hm May 25 20:54:23 maybe I should solder something to this screw? although, solder is too weak... May 25 20:54:31 and hard-soldering is a no-go too :P May 25 20:54:32 haha May 25 20:55:07 a drop of metal-eater acid, and ceramic screwdriver... :P May 25 20:55:47 you *might* try to glue a scredriver into the screw, but odds are you'll glue the screw to body of device, and usually the screwdriver won't stick enough to get the srew out May 25 20:56:56 so drilling or brute force are your only options May 25 20:57:38 http://paste.debian.net/171188/ was the shit I planned to paste btw May 25 20:57:43 yea, drilling something so close to screw is going to be fun thing to do May 25 20:58:12 looks like charging @ 100 mA and disabling it repeatedly May 25 20:58:13 and I really really wonder why my multiline edit requester didn't pop up on this monster paste May 25 20:59:00 22:45 3694 30 30 -24 349 349 349 65535 845 28 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 May 25 20:59:00 22:45 3700 30 30 -27 349 349 349 65535 774 28 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 May 25 20:59:00 May 25 22:45:41 IroN900 ke_recv[1927]: prop_modified:1901: udi /org/freedesktop/Hal/devices/usb_device_1d6b_2_musb_hdrc modified usb_device.vbus May 25 20:59:00 May 25 22:45:41 IroN900 systemui-tklock[1298]: Method call received from: :1.15, iface: com.nokia.system_ui.request, method: tklock_close May 25 20:59:01 May 25 22:45:44 IroN900 cellular: csd[797]: ISI_SMS .644196> ind_reg_status(): Net registration (ind) status:1 rc:0 May 25 20:59:04 May 25 22:45:44 IroN900 cellular: csd[797]: ISI_SMS .645477> set_timeout(): Timeout 27 s event type:-1 May 25 20:59:06 22:45 3612 30 30 -116 349 349 349 65535 180 29 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 May 25 20:59:08 May 25 22:45:52 IroN900 cellular: csd[797]: ISI_SMS .633515> ind_reg_status(): Net registration (ind) status:1 rc:0 May 25 20:59:11 May 25 22:45:52 IroN900 cellular: csd[797]: ISI_SMS .634766> set_timeout(): Timeout 19 s event type:-1 May 25 20:59:13 22:45 3631 30 30 -115 349 349 349 65535 182 29 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 May 25 20:59:15 May 25 22:46:05 IroN900 cellular: csd[797]: ISI_SMS .552613> incoming_cell_broadcast(): Incoming cell broadcast May 25 20:59:16 Estel_: each time the charge current jumps up, I plugged in charger May 25 20:59:18 May 25 22:46:07 IroN900 ke_recv[1927]: prop_modified:1901: udi /org/freedesktop/Hal/devices/usb_device_1d6b_2_musb_hdrc modified usb_device.vbus May 25 20:59:23 May 25 22:46:07 IroN900 browser[2264]: GLIB CRITICAL ** hildon-1 - hildon_window_get_is_topmost: assertion `HILDON_IS_WINDOW (self)' failed May 25 20:59:26 22:46 3628 30 30 -97 348 348 348 65535 215 29 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 May 25 20:59:28 May 25 22:46:09 IroN900 kernel: [102216.049560] kb_lock (GPIO 113) is now closed May 25 20:59:30 May 25 22:46:09 IroN900 systemui-tklock[1298]: Method call received from: :1.15, iface: com.nokia.system_ui.request, method: tklock_open May 25 20:59:33 May 25 22:46:10 IroN900 kernel: [102216.361877] kb_lock (GPIO 113) is now open May 25 20:59:35 May 25 22:46:11 IroN900 cellular: csd[797]: ISI_SMS .644165> isiclient_sms_timeout(): Request TIMEOUT May 25 20:59:37 22:46 May 25 20:59:39 ouh May 25 20:59:41 it seems that Xchat's multiline requester is screwed May 25 21:00:17 no problem, killed it already. but still thanks. May 25 21:00:50 My konversation edit requester usually works May 25 21:01:10 ah, I though you just plugged it and it jumped on it's own May 25 21:02:03 no, plug in charger: discharging bat with ~120+, unplug and disch current back to <30 May 25 21:02:45 the fun stuff: each unplug unlocks screen May 25 21:03:24 heh May 25 21:03:29 that's why I lock it immediately again: kb_lock (GPIO 113) is now closed May 25 21:08:42 charge21.sh FTW May 25 21:09:18 * DocScrutinizer waves and leaves home with a N900 with empty battery but hooked up to external powerpack May 25 21:11:34 http://paste.debian.net/171191/ May 25 21:36:20 omg the best part of indiana jones is when hitler signs the book May 25 21:38:08 ;) watching it for the first time, eh? May 25 21:51:30 on N90's in question - this one that I've tried to dissasembly - digitizer got kinda "damaged" by bad protecxtor foilk May 25 21:51:32 touching is ok May 25 21:51:42 although, after applying this protector, and rem,oving it - due to bad visual effect May 25 21:51:47 something "stayed" on screen May 25 21:52:01 or, part of antiu-scratch layer on screen pelled off, either way May 25 21:52:06 hard to tell, really May 25 21:52:16 yeah, that's possible May 25 21:52:26 nothing you can do about it May 25 21:52:33 get new digitiser, with a frame May 25 21:52:34 it jsut look like ultrathin layer on few parts of screen, OR lacking ultrathin layer from screen, really hard to tell May 25 21:52:36 yea May 25 21:52:42 but, do you think it's glue that stayed there? May 25 21:52:48 or just something pelled off? May 25 21:53:33 honestly, screen would look ok if I would be able to pell off rest of it, and attach "norma" screen protector (my screen protectors never do such shit to screen) May 25 21:54:18 the worst thing is that one of screws holding screen together is... screwed. no way to unscrew it, and it don' have left-turning driller **** ENDING LOGGING AT Sat May 26 02:59:57 2012