**** BEGIN LOGGING AT Thu Jun 24 02:59:58 2010 Jun 24 04:00:35 Q-Master: so you've reproduced my issue, but didn't do anything to test really? :( i'd try manual +CLCC through debug... Jun 24 04:01:14 Q-Master: If you get +CRING: VOICE it means it didn't lost network. Jun 24 05:15:42 PaulFertser: I did +CLCC through debug, but I've got error from dbus on not responding service on it Jun 24 05:16:16 PaulFertser: Seems that the problem is in fsogsmd dbus service. Jun 24 08:52:05 GNUtoo|laptop: hi Jun 24 08:52:09 good morning Jun 24 08:53:39 hi Jun 24 11:00:45 Q-Master: interesting... So the log keeps growing, but fsogsmd stops responding to dbus. Doesn't look like calypso problems. Jun 24 11:01:15 Q-Master: probably you might want to add this info to the ticket, so mickey|zzZZzz can have all the data handy. Jun 24 11:16:30 mickey|zzZZzz: hi Jun 24 11:16:34 are you awake? Jun 24 11:16:53 GNUtoo|laptop: I got the answer from mickey|zzZZzz Jun 24 11:17:15 I'll do the requested modifications in my email now Jun 24 11:25:02 GNUtoo|laptop, mickey|zzZZzz: I did the modifications, mickey requested Jun 24 11:25:08 please review it Jun 24 11:37:42 _o/ Jun 24 11:38:25 | Jun 24 11:38:27 --- Jun 24 11:38:37 /\ Jun 24 11:40:10 err... yes? :p Jun 24 12:27:58 leviathan, ok Jun 24 12:29:57 leviathan, ok sounds good Jun 24 12:30:06 ok Jun 24 12:30:17 when mickey is also happy with the formulation Jun 24 12:30:19 we can send it Jun 24 12:30:20 :-) Jun 24 12:30:23 ok Jun 24 13:06:02 mickey, hi did you saw my suspend mail? Jun 24 13:20:20 yes Jun 24 13:23:10 ok Jun 24 13:27:34 i'm out of ideas though what this again could be Jun 24 13:28:04 ok Jun 24 13:28:13 do you need more logs/tests? Jun 24 13:28:35 btw I've a suggestion Jun 24 13:28:42 on SHR-image Jun 24 13:28:52 it often resume with SMD_RPCCALL Jun 24 13:29:02 if I remember well the image Jun 24 13:29:16 can't we check for +CRING or something like that Jun 24 13:29:17 ? Jun 24 13:29:27 but that would be after the basics work Jun 24 13:30:16 is there any traffic from the modem waking up? Jun 24 13:32:07 I don't know Jun 24 13:32:14 inspect the logs :) Jun 24 13:32:29 ok I'll do when it'll occur but before: the basics Jun 24 13:34:45 perhaps it doesn't want to be set into mem suspend more than once Jun 24 13:35:07 with the incredible wakelock architecture it can be gazillions of problems :( Jun 24 13:35:13 is we don't have any clue, we call der kommisar,he'll investigate,the only problem is that instead of fixing the bug,he'll workarround and put it in a FreeBSD jail Jun 24 13:35:30 try removing the 'mem' above the while loop Jun 24 13:35:52 ah Jun 24 13:35:58 ok Jun 24 13:36:00 I'll try Jun 24 13:37:04 maybe I should retry without fsodeviced Jun 24 13:37:18 SHR: 03seba.dos1 07shr-settings * ra670c0d441f6 10/ (TODO shr-settings): launcher: make error handling better Jun 24 13:40:50 2010-06-24T13:39:08.677612Z [DEBUG] LowLevelAndroid <>: Waiting for suspend returned with resume reason 'gpio_kp' Jun 24 13:40:57 2010-06-24T13:39:08.678039Z [DEBUG] LowLevelAndroid <>: Setting power state 'mem' Jun 24 13:40:59 mmm Jun 24 13:41:09 that's ok but after it doesn't get the keypress Jun 24 13:41:21 it's waiting for the phone to suspend Jun 24 13:41:44 I didn't test the // mem Jun 24 13:41:46 yet Jun 24 13:46:39 hmm Jun 24 13:47:25 you mean mem inside the while loop? Jun 24 13:47:34 because I found nothing above it Jun 24 13:47:40 only inside it but on top Jun 24 13:47:41 yeah, try to move it above the while loop Jun 24 13:47:45 ah ok Jun 24 13:50:15 ok bitbaking Jun 24 13:50:24 now without fsodevice I've the same thing Jun 24 13:51:13 http://pastebin.com/s8QZuCyJ here's the full log without the fix Jun 24 13:52:37 hmm, it could be that we don't get the 'cycle' attribute, if we don't wake up! Jun 24 13:52:48 so it would wait for the cycle, that would never appear Jun 24 13:52:55 ok Jun 24 13:53:01 thing is, we only need to wait for the 'cycle' the first time Jun 24 13:53:24 subsequently we only need to wait for resume reason Jun 24 13:53:48 ok Jun 24 13:53:53 or we could stop listening to 'cycle' completely and only use resume reason Jun 24 13:56:12 what is cycle exactly? Jun 24 13:56:17 I saw it in the logs Jun 24 13:59:25 SHR: 03seba.dos1 07shr-settings * r4ec202132c50 10/ (TODO shr_settings_modules/shr_gsm.py): [GSM] support fsogsmd Jun 24 14:02:33 cycle is written "into" the proc fs when a suspend/resume cycle has been completed Jun 24 14:03:03 let me eat something and work 5 minutes on a patch Jun 24 14:03:37 2010-06-24T14:02:19.615844Z [ERROR] UsageController <3 R>: DBus Error while talking to IdleNotifier: Launch helper exited with unknown return code 0 Jun 24 14:03:39 what's that? Jun 24 14:04:59 ok Jun 24 14:07:14 GNUtoo|laptop: fsousaged tries to talk to fsodeviced in order to set "busy" idle state on resume Jun 24 14:07:27 GNUtoo|laptop: if you don't have fsodeviced running, then that's ok Jun 24 14:07:31 ok Jun 24 14:08:30 http://pastebin.com/Xb3qc4Ws Jun 24 14:08:41 dos1, thanks a lot Jun 24 14:16:47 GNUtoo|laptop, mickey: I'll send it now Jun 24 14:17:03 ok Jun 24 14:17:26 GNUtoo|laptop: also to smartphones-userland@linuxtogo.org? Jun 24 14:17:29 http://pastebin.com/rCwpZm7a <- calling the phone when suspended Jun 24 14:17:42 ask mickeyl for the correct lists Jun 24 14:17:46 he's eating Jun 24 14:17:55 ok Jun 24 14:18:01 I should do the same Jun 24 14:18:04 forgot lunch Jun 24 14:18:06 >_< Jun 24 14:18:09 was soldering Jun 24 14:18:24 I've still some issue with this circuit in front of me Jun 24 14:18:39 I need sinus wave with more amplitude for the generator Jun 24 14:18:52 I got a feedback, where the opamp exploded Jun 24 14:18:54 same call: http://pastebin.com/EqDkLfKs Jun 24 14:18:54 -.- Jun 24 14:18:57 ok Jun 24 14:19:21 I was right when I told it sounded dangerous? Jun 24 14:20:17 freesmartphone.org: 03mickey 07cornucopia * ra930f85766af 10/fsousaged/src/plugins/lowlevel_android/plugin.vala: fsousaged: lowlevel_android: next try to get this darn plugin right Jun 24 14:35:01 TAsn: ping Jun 24 14:37:54 mickey|, still the same issue,I'll look&paste the logs Jun 24 14:39:28 GNUtoo|laptop, mickey|: looks like it's suspending kernel earlier, than suspending resources Jun 24 14:43:35 http://pastebin.com/sHZzZbRy Jun 24 14:46:05 hmm Jun 24 14:46:10 ok, i'm finally out of ideas then Jun 24 14:50:36 i try here just make sure it's not the baseband firmware difference Jun 24 14:56:30 ok Jun 24 14:56:49 I've an idea Jun 24 14:56:54 maybe input sleeps Jun 24 14:59:32 with the newer plugin(not modified) Jun 24 14:59:34 2010-06-24T14:58:02.941253Z [DEBUG] LowLevelAndroid <>: Waiting for suspend returned with resume reason 'gpio_kp' Jun 24 14:59:34 2010-06-24T14:58:02.941833Z [DEBUG] LowLevelAndroid <>: Setting power state 'mem' Jun 24 14:59:34 2010-06-24T14:58:02.942687Z [DEBUG] LowLevelAndroid <>: Waiting for suspend to actually happen... Jun 24 15:03:46 if input sleeps, how are we supposed to find out the event? Jun 24 15:03:54 the fake resume should wakeup input for a short while Jun 24 15:04:07 at least that's who i understood phh Jun 24 15:04:47 ok Jun 24 15:04:51 s/who/how/ Jun 24 15:04:52 mickey| meant: at least that's how i understood phh Jun 24 15:05:12 fake input ? what ? Jun 24 15:07:49 any idea why we're only getting the first input event on intermediate resume? Jun 24 15:08:08 subsequent button presses don't generate any events Jun 24 15:08:14 oO Jun 24 15:08:15 no Jun 24 15:08:33 k Jun 24 15:09:09 ok I was right Jun 24 15:09:13 I see no input on Jun 24 15:09:26 evtest /dev/input/event3 Jun 24 15:09:43 when pressing VOL_DOWN first Jun 24 15:09:48 and the the power button Jun 24 15:10:26 voldown and power button are on the same event ? Jun 24 15:10:57 I think so they're both /dev/input/event3 Jun 24 15:11:55 Event code 114 (VolumeDown) Jun 24 15:11:57 and: Jun 24 15:12:09 Event code 107 (End) Jun 24 15:12:16 are both on /dev/input/event3 Jun 24 15:12:35 end is power button ? Jun 24 15:12:42 ok then Jun 24 15:12:45 yes Jun 24 15:13:52 basically I fear that: Jun 24 15:14:08 real-suspend -> resume -> can read the button Jun 24 15:14:23 fake-suspend -> can't read the button Jun 24 15:14:30 because I connected the phone trough usb Jun 24 15:14:36 and it's still not fully resumed Jun 24 15:14:50 I sill can't get the button Jun 24 15:19:59 well, at least that seems to work here Jun 24 15:20:16 ah what steps did you do exactly? Jun 24 15:20:22 evtest /dev/input/3 Jun 24 15:20:27 before that Jun 24 15:20:27 in another shell echo mem Jun 24 15:20:31 ok Jun 24 15:20:36 I did that Jun 24 15:20:39 unplug usb Jun 24 15:20:43 touch a couple of buttons Jun 24 15:20:45 plug in usb Jun 24 15:20:52 s.sh is sleep 5 && apm -s Jun 24 15:20:54 then i see all touched buttons Jun 24 15:20:57 ok Jun 24 15:20:58 in the evtest shell Jun 24 15:21:05 I did that : Jun 24 15:21:12 sh s.sh & exit Jun 24 15:21:17 I disconnect usb Jun 24 15:21:33 oops Jun 24 15:21:36 yes,that's expected Jun 24 15:21:37 I re-explain Jun 24 15:21:40 if you use apm -s, it won't work Jun 24 15:21:42 screen Jun 24 15:21:46 evtest /dev/input/3 Jun 24 15:21:51 sh s.sh & exit Jun 24 15:21:53 fsouaged is grabbing the input nodes Jun 24 15:22:02 then disconnect Jun 24 15:22:03 ok Jun 24 15:22:15 then button volume,then button power Jun 24 15:22:16 i just tested whether it works at all Jun 24 15:22:19 then reconnect Jun 24 15:22:33 ok Jun 24 15:22:40 so what should I do? Jun 24 15:22:43 echo mem instead? Jun 24 15:22:44 i think the kernel is -again- at fault here Jun 24 15:22:48 if you check logread Jun 24 15:23:01 you'll see that there is no gpio_kp multiple times Jun 24 15:23:05 but only once Jun 24 15:23:15 so fsousaged has no idea as well Jun 24 15:23:25 indeed Jun 24 15:23:43 let me look Jun 24 15:23:59 I'll reboot to get clean logs Jun 24 15:24:51 so 2 apps can't gab the keys at the same time? Jun 24 15:25:13 no, that's the idea of a grab :) Jun 24 15:25:34 ok Jun 24 15:25:57 sane systems swallow the resume event *cough* Jun 24 15:26:07 since our kernel does not do that, we need to do it in userland Jun 24 15:27:53 ok indeed only one gpio_kp Jun 24 15:28:27 yep, so our idea does not work Jun 24 15:28:29 mickey|, by does not do that,you mean that it's broken by design Jun 24 15:28:33 ? Jun 24 15:28:41 well, that's disputable Jun 24 15:28:58 some say kernel should never swallow events Jun 24 15:29:17 some say kernel should not deliver wakeup keys Jun 24 15:29:22 at the end of the day it's taste Jun 24 15:30:16 so what should we do? implement something in the kernel? Jun 24 15:30:21 is it hard to do? Jun 24 15:30:39 swallowing or not is not our problem Jun 24 15:32:02 our problem is that this kernel's idea of how suspend/resume works is incompatible with our userland Jun 24 15:32:16 and the longer we fight against that the more tired i get Jun 24 15:33:06 so what should I do? Jun 24 15:33:15 at this point i have no idea Jun 24 15:33:20 we could remove wakelocks Jun 24 15:33:21 ? Jun 24 15:33:24 we can't Jun 24 15:33:29 I did once Jun 24 15:33:29 the kernel will blow up Jun 24 15:33:37 and It booted Jun 24 15:33:38 it's full of race conditions that are duct-taped with wakelocks Jun 24 15:33:43 ah ok Jun 24 15:33:53 at least that's my subjective opinion Jun 24 15:33:57 ok Jun 24 15:34:00 android-fanboys will disagreee Jun 24 15:34:03 lol Jun 24 15:34:22 with this suspend implementation I had some hope Jun 24 15:34:37 but maybe I will go back thinking about buying the palm pre if we have no ideas Jun 24 15:34:52 basically I understood the problem reading how palm pre suspends Jun 24 15:35:05 if suspend would be the last problem we had, i would be more motivated Jun 24 15:35:11 you want to act as it was a freerunner Jun 24 15:35:15 but once we fix that, there's a dozens of problem still ahead Jun 24 15:35:28 mickey|, only wifi,alsa Jun 24 15:35:39 gps, bluetooth, compass, accelerometer Jun 24 15:35:42 the rest is less important Jun 24 15:35:53 ok Jun 24 15:35:56 we were so close Jun 24 15:35:58 too bad Jun 24 15:36:30 alsa is one thread on the alsa ml or one talk with Thingol Jun 24 15:36:34 i'm too demotivated to think about that crap now. i need some days rest, perhaps i get another idea Jun 24 15:36:38 ok Jun 24 15:36:44 rest gives good ideas Jun 24 15:36:46 heh Jun 24 15:36:49 hopefully Jun 24 15:36:50 bbl Jun 24 15:36:53 ok Jun 24 15:37:00 so I'll think about buying palm pre then Jun 24 15:37:12 and wait for wifi answer Jun 24 15:37:57 basically the model was the freerunner Jun 24 15:38:06 palm pre is alsmost the same Jun 24 15:38:14 there is a resume reason etc... Jun 24 15:58:32 mickey|zzZZzz: hey Jun 24 15:58:56 which ML should I use for sending the email? Jun 24 16:04:24 wow Jun 24 16:04:56 we also open-sourced several additional hardware-related libraries that had been closed-source in previous releases,[...]and the interface between the media framework and Qualcomm chipsets Jun 24 16:09:19 ( http://android-developers.blogspot.com/2010/06/froyo-code-drop.html ) Jun 24 16:31:53 freesmartphone.org: 03mickey 07cornucopia * r227b3143d32f 10/fsousaged/src/plugins/lowlevel_android/plugin.vala: fsousaged: lowlevel_android: sick Jun 24 16:39:41 GNUtoo|laptop: reverted to something very simple. for now, you _must_ press power key to wakeup the phone after issuing suspend. Jun 24 16:40:15 suspend via USB or baseband is not being recognized, USB will probably never, but for baseband we need to find a solution Jun 24 16:40:16 later Jun 24 16:40:25 s/suspend/resume/ Jun 24 16:47:45 mickey|: which MLs should I send the mail to? Jun 24 16:48:05 ok I'll try Jun 24 16:48:19 mickey|: oh, hi first ;-) Jun 24 16:48:34 mickey|, for baseband we listen to +CRING? Jun 24 16:49:02 leviathan: smartphones-userland@linuxtogo.org, community@lists.openmoko.org, and perhaps shr-devel@lists.shr-project.org Jun 24 16:49:31 GNUtoo|laptop: something like that, i don't know where yet, but i will think about it Jun 24 16:49:45 ok Jun 24 16:49:55 maybe fsogsmd<->fsousaged Jun 24 16:49:55 either also in lowlevel Jun 24 16:50:03 or changing the model to match android more Jun 24 16:50:09 ok Jun 24 16:50:09 so that fsogsmd asks fsousaged to resume Jun 24 16:50:13 dunno yet Jun 24 16:50:13 mickey|: ok Jun 24 16:50:14 thx Jun 24 16:50:24 thanks a lot Jun 24 16:50:45 np, i hope that this at least works good enough so that you can continue your sutff Jun 24 16:50:48 stuff Jun 24 16:50:53 mickey|, also in android 2.2 they said to have released the libraries that permit video decoding offload Jun 24 16:51:03 ok Jun 24 16:54:19 hmm Jun 24 16:54:21 ok Jun 24 16:55:51 GNUtoo|laptop: the one thing that android nightmare is good for is to force us to think about intermediate resume sooner than later Jun 24 16:56:09 ok Jun 24 16:56:11 (i.e. a resume where we only do some housekeeping tasks and then transparently suspend again) Jun 24 16:56:35 obviously for GNU/Linux systems we do need more work on that Jun 24 16:56:41 for android it's almost done Jun 24 16:56:54 (since it's somewhat built-in) Jun 24 16:57:21 mickey|: very interesting idea... Jun 24 16:57:37 what kind of tasks? Jun 24 16:58:38 waiting for a next GPS fix and logging the location Jun 24 16:58:46 contacting a server to ping it for something Jun 24 16:58:51 possibilities are endless Jun 24 16:59:07 Q-Master: ping Jun 24 16:59:16 stupid idea: something like "/bin/init", but for resume, which then decides whether to do further? Jun 24 16:59:22 PaulFertser: pong Jun 24 16:59:25 (/sbin/init obviously) Jun 24 16:59:58 Q-Master: you say that after fsogsmd stuck in a clcc loop, you couldn't contact it over dbus anymore, right? Jun 24 17:00:06 Q-Master: can you please add a comment to the ticket? Jun 24 17:00:07 Weiss: yeah, or that Jun 24 17:00:25 (thinking about how it might be implemented) Jun 24 17:00:31 although that's somehwat tough with android kernels Jun 24 17:00:39 PaulFertser: sorry, I need to register first, and I have no time just now. Can you plz add this for me Jun 24 17:00:40 since we have no central point of knowledge for resume Jun 24 17:00:44 (by "stupid idea", I meant "this is my stupid idea for how to achieve that") Jun 24 17:00:49 (which is the nightmare we have been talking about today) Jun 24 17:00:50 PaulFertser: also add plz Jun 24 17:01:18 PaulFertser: that after killing the fsogsmd and restarting the X, it resumed to work properly Jun 24 17:01:58 although in some way it might have to talk to other processes which are frozen Jun 24 17:02:12 Q-Master: the second point is obvious Jun 24 17:02:16 Q-Master: ok, np Jun 24 17:03:44 PaulFertser: not exactly. If that was the problem of a chip - It will not respond anymore without HW reset. But it responds Jun 24 17:05:38 mickey|, I'll test more but at first sight it seem to work Jun 24 17:05:50 * Jun 24 17:05:51 ok Jun 24 17:07:13 Q-Master: fsogsmd restart causes hardware restart of the chip too. Jun 24 17:07:31 PaulFertser: not seeing this in log file Jun 24 17:07:49 PaulFertser: it is exactly vice versa Jun 24 17:07:59 PaulFertser: the chip responds immediately Jun 24 17:11:44 mickey|, even phone seem to be ok, it vibrates and the screen stays off,which is good Jun 24 17:11:58 because else a button could be pressed by accident Jun 24 17:12:03 like hangup Jun 24 17:12:13 before the person would have a chance to pickup Jun 24 17:15:58 btw for shr-image vs fso2-demo-image I think xset is lacking in fso2-demo-image Jun 24 17:16:06 which maybe saved us from some bugs Jun 24 17:36:24 ok Jun 24 17:36:25 nice Jun 24 17:36:32 phonefsod is the issue Jun 24 17:36:36 in SHR in the dream Jun 24 17:36:41 s/in the/on the Jun 24 17:38:19 GNUtoo|laptop: in what way? Jun 24 17:40:45 basically I've still not identified the part responsible of the issue,but the issue has to do with suspend Jun 24 17:40:59 basically on fso2-demo-image or shr-image with phonefsod disabled Jun 24 17:41:04 it suspend correctly Jun 24 17:41:08 apm -s work Jun 24 17:41:13 the screen becomes black etc... Jun 24 17:41:27 then if fhonefsod works when I do apm -s it suspends Jun 24 17:41:30 then it comes back Jun 24 17:41:40 and the lock screen appear Jun 24 17:41:50 but it's somewhat still suspended Jun 24 17:41:56 because the input doesn't work Jun 24 17:42:02 then I press the power button Jun 24 17:42:13 and it fullu resume and input work again Jun 24 17:42:26 mmm Jun 24 17:42:31 if I comment the idle part Jun 24 17:42:46 #[idle] Jun 24 17:42:52 in phonefsod.conf Jun 24 17:42:56 it seem to work so far Jun 24 17:42:59 it didn't resume yet Jun 24 17:43:24 and resume when I press the power button Jun 24 17:43:26 which is fine Jun 24 17:43:54 ah it depends Jun 24 17:43:57 sometimes it works Jun 24 17:44:00 sometimes no Jun 24 17:44:06 (the suspend) Jun 24 17:44:34 ah sorry it worked everytime but one Jun 24 17:44:44 so maybe I pressed something accidentally Jun 24 17:44:51 so if I disable idle Jun 24 17:44:54 it works fine Jun 24 17:45:16 ouch screen crashed Jun 24 17:46:06 hmm Jun 24 17:46:58 screen crashed is our kernel,not fso/shr Jun 24 17:47:36 GNUtoo|laptop: are you sure "apm -s" is the correct way to suspend? Jun 24 17:47:49 ah? Jun 24 17:48:13 GNUtoo|laptop: or do you use fso-apm? Jun 24 17:48:22 I use fso-apm Jun 24 17:48:25 so it calls dbus Jun 24 17:48:29 ok then :) Jun 24 17:48:41 apm [OPTION...] - FSO APM Compatibility Utility V2 Jun 24 17:50:09 GNUtoo|laptop: on resume fsousaged sends busy state to fsodeviced's idle notifier Jun 24 17:50:31 GNUtoo|laptop: on busy state phonefsod is setting full backlight Jun 24 17:50:43 GNUtoo|laptop: maybe something is wrong with kernels' backlight handling? Jun 24 17:50:51 yes Jun 24 17:50:52 maybe Jun 24 17:51:06 when I press on the volume button it crashes the screen Jun 24 17:51:20 in fso2-demo-image it didn't even wake the screen Jun 24 17:51:23 hmmm Jun 24 17:52:42 GNUtoo|laptop: try to set everything in [idle] section to 100 and uncomment it Jun 24 17:52:49 ok Jun 24 17:52:54 GNUtoo|laptop: and then check if it's still crashing Jun 24 17:53:04 ok thanks a lot Jun 24 17:54:24 * dos1 would like to be able to play with some other SHR-running device than Freerunner to check, how shr-settings behaves on other hardware ;x Jun 24 17:55:09 about shr-settings I'm bitbaking it right now Jun 24 17:55:16 I can do screenshots if you want Jun 24 17:55:32 I'm bitbaking it because I saw the fsogsmd commit Jun 24 17:56:09 GNUtoo|laptop: just check if something is not working Jun 24 17:56:24 minimum_brightness=127 is fine? Jun 24 17:56:30 max brightness is 127 Jun 24 17:56:40 dos1, most things is not working Jun 24 17:56:45 GNUtoo|laptop: no, it's precentage Jun 24 17:56:48 s/pre/per/ Jun 24 17:56:49 dos1 meant: GNUtoo|laptop: no, it's percentage Jun 24 17:57:03 set everything to 100 Jun 24 17:57:16 ok Jun 24 17:57:23 GNUtoo|laptop: which things exactly? Jun 24 17:58:10 some things can't work because we need special handling Jun 24 17:58:15 like gps or wifi Jun 24 17:58:23 bluetooth don't work yet Jun 24 17:58:28 so forget about that Jun 24 17:58:32