**** BEGIN LOGGING AT Tue Oct 14 02:59:57 2008 Oct 14 06:08:43 i have installed tomcat5.5 on ubuntu-8.04 hardy. it is running fine. the page http://localhost:8080/ is also responding. i also installed hudson on ubuntu, but when im trying to open the URL http://server-name/huson/ is not responding. can one help me?? Oct 14 06:59:20 morning Oct 14 07:36:48 freesmartphone.org: 03charlie 07framework * r143069817dc8 10/framework/patterns/tasklet.py: Oct 14 07:36:48 freesmartphone.org: tasklet: Added WaitDBusName tasklet Oct 14 07:36:48 freesmartphone.org: This is a special tasklet that blocks until a given DBusName is available on the system bus Oct 14 09:12:41 freesmartphone.org: 03charlie 07framework * r3d8989d0ed73 10/framework/subsystems/opreferencesd/opreferences.py: opreferences: log error instead of info when service not found Oct 14 10:52:56 freesmartphone.org: 03mickey 07gsm0710muxd * r79e10fe8ad08 10/ (ChangeLog configure.ac): (re)release gsm0710muxd version 0.9.2 Oct 14 10:52:59 freesmartphone.org: 03mickey 07specs * r63f08d5b6d38 10/ (2 files in 2 dirs): odeviced: signal lowercase consistency change for org.freesmartphone.Device.IdleNotifier Oct 14 10:53:29 freesmartphone.org: 03mickey 07framework * r2481741a2949 10/ (4 files in 3 dirs): odeviced: signal lowercase consistency change for idlenotifier and kernel26 Oct 14 10:53:34 freesmartphone.org: 03mickey 07libframeworkd-glib * r0307f5c65b07 10/src/odeviced/frameworkd-glib-odeviced-idlenotifier.h: frameworkd-glib-odeviced-idlenotifier.h: catch up with signal lowercase naming consistency changes Oct 14 10:57:27 freesmartphone.org: 03mickey 07framework * r9e6a96fb3f65 10/etc/freesmartphone/oevents/rules.yaml: rules: add emergency shutdown rule Oct 14 11:27:03 mickeyl: ah well seeing r63f08d5b6d38 I was intending to tell you to modify lfg Oct 14 11:27:06 But I see you already did it Oct 14 11:56:14 freesmartphone.org: 03mickey 07framework * rb9e9c0046684 10/framework/subsystems/odeviced/kernel26.py: odeviced: open framebuffer "just in time" for blanking/unblanking ioctl Oct 14 13:55:37 Hey Oct 14 13:57:19 AinuFallback, any news? Oct 14 14:23:19 about what ? Oct 14 14:23:27 my marshalling problem ? Oct 14 14:23:42 Can't work from here, my home computer is down Oct 14 14:25:49 freesmartphone.org: 03sudharsh 07openmoko-gsoc2008 * rf96ccaea0276 10/fsod/src/subsystems/Device/idlenotifier/ (idlenotifier.plugin idlenotifier.vala): Catch up with the case changes in the idlenotifier plugin Oct 14 14:37:36 mickeyl: weird thing here Oct 14 14:37:46 mickeyl: odeviced won't set idle Oct 14 14:37:49 or lock Oct 14 14:37:50 or dim Oct 14 14:39:06 And mdbus -s org.freesmartphone.ogpsd is awfully long Oct 14 14:39:40 (still not answering) Oct 14 14:44:42 mickeyl: it seems that after some suspend signal it won't send signals anymore on the idlenotifier side Oct 14 14:45:25 OK, I installed SHR last night Oct 14 14:45:54 On every boot, contacts crashes every time I bring it up Oct 14 14:46:07 On my first boot, dialer crashed every time I tried to 'call' Oct 14 14:46:15 But after that it doesn't. Oct 14 14:46:16 wurp2|working, did you update the packages? Oct 14 14:46:25 opkg update && opkg upgrade Oct 14 14:46:33 No output from opkg upgrade Oct 14 14:46:38 and your internet connection was working? Oct 14 14:46:41 opkg update appeared to succeed Oct 14 14:46:54 Yeah, I had to edit my /etc/resolv.conf to get opkg update to work Oct 14 14:47:10 ok..opkg list | grep openmoko-contacts please Oct 14 14:49:26 OK, sec Oct 14 14:50:35 spam warning Oct 14 14:50:36 openmoko-contacts3 - 0.0.1+r1-svnr1-r1 - A Contacts application Oct 14 14:50:36 openmoko-contacts3-dbg - 0.0.1+r1-svnr1-r1 - A Contacts application Oct 14 14:50:37 openmoko-contacts3-dev - 0.0.1+r1-svnr1-r1 - A Contacts application Oct 14 14:51:25 yeah, it's an old version Oct 14 14:51:59 k, trying again Oct 14 14:52:32 I used the Oct 14 image, too Oct 14 14:52:52 wurp2|working, I think we've got some issues with package versions/revisions Oct 14 14:53:17 that should be fixed very soon.. Oct 14 14:53:59 wurp2|working, one sec Oct 14 14:54:53 no network on my neo :-( Oct 14 14:54:58 I'm at work Oct 14 14:55:16 gotta go do work stuff for a bit, too :-( Back soon-ish Oct 14 14:55:21 wurp2|working, could you give me opkg list | grep libframeworkd-phonegui-efl Oct 14 14:56:37 wurp2|working, sorry, openmoko-contacts3 version is ok..but probably not lfg-efl's Oct 14 15:20:59 spamagain Oct 14 15:21:00 libframeworkd-phonegui-efl-dbg - 0.0.1+r12-svnr1-r12 - frameworkd EFL phonegui Oct 14 15:21:03 libframeworkd-phonegui-efl-dev - 0.0.1+r12-svnr1-r12 - frameworkd EFL phonegui Oct 14 15:21:07 libframeworkd-phonegui-efl0 - 0.0.1+r12-svnr1-r12 - frameworkd EFL phonegui Oct 14 15:21:52 wurp2|working: if it's crashing, dialer3, contacts3 and messages3 aren't up to date Oct 14 15:21:58 please opkg remove opkg install them Oct 14 15:21:59 or force reinstlal Oct 14 15:22:06 opkg install -force-reinstall things Oct 14 15:22:20 wurp2|working: we didn't regenerate the image Oct 14 15:22:37 AinuFallback, he installed the Oct 14 image Oct 14 15:22:42 that should be up to date, shouldn't it? Oct 14 15:22:53 I should say, I actually installed the link Oct 14 15:22:57 the generically named one Oct 14 15:23:08 I checked that it's (roughly) the same size as the oct 14 one Oct 14 15:23:13 44mb Oct 14 15:23:25 quickdev: I don't know Oct 14 15:23:29 The page only shows rough size Oct 14 15:23:34 But if it's crashing for me packages aren't up to date Oct 14 15:23:36 just try that please wurp2|working Oct 14 15:23:37 wurp2|working, the size is almost equal, yes Oct 14 15:23:39 No network access from my neo at work :-( Oct 14 15:23:48 libframeworkd-phonegui-efl is old, definetely! Oct 14 15:23:52 So I'll try it from home Oct 14 15:23:52 wurp2|working: not even USB for pscp/scp ? Oct 14 15:24:05 I can usb from pc to neo & back Oct 14 15:24:11 Then just download and scp it Oct 14 15:24:15 but no routing from neo to internet at large Oct 14 15:24:29 AinuFallback: If I find time :-) Oct 14 15:24:51 Thanks for the pointers Oct 14 15:25:40 You're *welcome Oct 14 15:25:49 :-> Oct 14 15:26:40 AinuFallback, just implemeting adding and modifying sim contacts Oct 14 15:27:16 nice :-) Oct 14 15:27:21 And deleting Oct 14 15:27:39 quickdev: did you think about my letters wheel ? Oct 14 15:27:51 yeah, I did Oct 14 15:27:57 but that's not a priority I think Oct 14 15:28:05 Hmmm sorry to say I think it is :-/ Oct 14 15:28:09 It's pretty unusable here Oct 14 15:28:12 I have 200+ contacts Oct 14 15:28:30 And it's a true pain to be able to slide to, say, the middle of the contact list Oct 14 15:28:36 If there's people like me out there (and I'm sure there is) Oct 14 15:28:40 It could be a pain Oct 14 15:28:48 I agree it's not a showstopper Oct 14 15:28:56 But it's, I think, important for a first release Oct 14 15:28:58 Don't you think ? Oct 14 15:29:22 (merely throwing ideas, I'm waiting for a good reason here ;-) ) Oct 14 15:29:29 Ainulindale: hi, crappy connection Oct 14 15:31:30 AinuFallback, what about a text entry where you can enter a character? Would be easier to implement at first Oct 14 15:32:53 Ok with that as long as we can do a search Oct 14 15:33:00 If you do that, don't do it with a text entry Oct 14 15:33:05 just do it on focus in the contact list Oct 14 15:33:12 focus an entry, type "Z", will slide to Z Oct 14 15:33:22 even easier to do isn't it ? Oct 14 15:37:56 not really, will think about it Oct 14 15:38:47 AinuFallback, have a look at ophonekitd, there's variable incoming_call_active and outgoing_call_active...why haven't you used them for the suspend during call thing? Oct 14 15:48:01 shoragan, Oct 14 15:48:14 hi Sup3rkiddo Oct 14 15:48:27 alphaone? Oct 14 15:49:02 shoragan, hi, mickey told me that you will be working on the vala/ implementation of frameworkd... Oct 14 15:49:21 the integration of your implementation first Oct 14 15:49:45 Ainulindale? Oct 14 15:50:03 i've tried dl-loading .so written in vala from python Oct 14 15:50:19 but there is some problem with using the same dbus-connection that i need to debug Oct 14 15:50:28 shoragan, oh, it worked?. Oct 14 15:50:38 and i'm currently busy with the mtn to git conversion Oct 14 15:50:43 shoragan, oh ok Oct 14 15:51:00 quickdev: because I forgot I did that :-) Oct 14 15:51:03 Sup3rkiddo, i get two connections to the same bus, so the busname can't be used Oct 14 15:51:10 AinuFallback, maybe I did it ;) Oct 14 15:51:18 AinuFallback, could you do suspend thing then? Oct 14 15:51:33 Can't now, connection is borking Oct 14 15:51:38 Sup3rkiddo, but it's on top of my openmoko todo list Oct 14 15:51:40 I'll do that tonight at home if I can have enough up time Oct 14 15:51:47 shoragan, yeah...is there some code which i can look at? Oct 14 15:52:02 AinuFallback, fine, would be a veery important fix Oct 14 15:52:07 whats your email address? Oct 14 15:52:22 quickdev: anyway I think I did it a while ago, when we didn't know if we could have this kind of information on frameworkd Oct 14 15:52:25 shoragan, sudharsh _at_ gmail . com Oct 14 15:52:28 this active thing Oct 14 15:52:37 proof of a beginner's code with frameworkd I guess Oct 14 15:52:46 And if I don't well good for you :-p Oct 14 15:53:04 yeah, but we could use it Oct 14 15:53:44 mickeyl, here? Oct 14 15:56:41 Sup3rkiddo, i've sent you my test code Oct 14 15:56:56 somehow libdbus gets initialized twice Oct 14 15:57:10 shoragan, yeah, got it..will take a look Oct 14 15:57:12 thanks Oct 14 16:01:12 b Oct 14 16:01:14 oops Oct 14 16:08:42 Well this LPC thing is interesting Oct 14 16:08:58 It would be a nice thing to work on that for SHR Oct 14 16:09:03 LPC? Oct 14 16:09:07 what is it? Oct 14 16:09:21 Linux Plumbers Conference Oct 14 16:09:31 http://lwn.net/Articles/299483/ Oct 14 16:10:26 quickdev: yep, here for a short moment Oct 14 16:11:14 mickeyl, I'd like to save a new contact entry to sim, but I need to know where a free index is. I could get all entries and then see where something is free, but I would need the maximum of stored entries. Is there a way to get this maximum? Oct 14 16:11:16 mickeyl: and I have some questioons too :-p Oct 14 16:11:47 mickeyl: Experienced a weird behavior on frameworkd with idle notifier. Used it with no problem and suddenly it stopped sending DIM Oct 14 16:11:55 AinuFallback, it's interesting...a it's much work I think Oct 14 16:11:57 No useful log out there unfortunately Oct 14 16:12:03 quickdev: exactly Oct 14 16:12:07 But it's interesting nonetheless :-) Oct 14 16:12:12 yeah Oct 14 16:12:17 I'd love to boot my freerunner in half the time it boots now Oct 14 16:12:25 By the way frameworkd is a true hassle Oct 14 16:12:31 Loads in an awful lot of time Oct 14 16:12:36 Isn't there any way to speed that up ? Oct 14 16:12:43 AinuFallback, today morning, I woke up and my neo was awake, although it should have been in suspend...battery almost empty, the same frameworkd bug? Oct 14 16:12:49 quickdev: GetPhonebookInfo Oct 14 16:12:56 quickdev: will give you the minimum and maximum entry Oct 14 16:13:06 quickdev: I heard problems with cell broadcasts Oct 14 16:13:07 quickdev: there's no way to get the "next free". you need to calculate that on your own Oct 14 16:13:09 +about Oct 14 16:13:22 mickeyl, calculating is no problem Oct 14 16:13:30 AinuFallback: (idlenotifier/dim) oops, very strange. i'll look into that anyways because of the suspend/awake logic Oct 14 16:13:48 now that mwester applied the power button swallow on resume press, i add a rule for suspend/resume in rules.yaml Oct 14 16:13:56 ~praise mwester Oct 14 16:17:11 "power button swallow" ? Oct 14 16:17:21 An african or an european swallow ? Oct 14 16:17:31 freesmartphone.org: 03mickey 07zhone * r28e01227063a 10/src/zhone: s/BUSY/busy/ as per IdleNotifier API changes Oct 14 16:17:44 heh Oct 14 16:17:53 But more seriously, what were you talking about ? Oct 14 16:18:04 not delivering power button events on resume Oct 14 16:18:10 Oh, that Oct 14 16:18:12 Ok then :-) Oct 14 16:18:15 :) Oct 14 16:18:53 Oh idle notifier is a state machine I see Oct 14 16:19:16 Bad thing though Oct 14 16:19:22 Timers are hardwired Oct 14 16:19:25 Should be in some rule file :-) Oct 14 16:19:45 timers are not hardwired Oct 14 16:19:49 read from frameworkd.conf Oct 14 16:20:03 just the default fallback is hardwired Oct 14 16:20:05 Ah I didn't get to the end of init :-) Oct 14 16:20:07 :) Oct 14 16:20:14 My humble apologies maaaaaster Oct 14 16:20:22 Please touch my hump maaaaster Oct 14 16:20:25 you will be forgiven this time Oct 14 16:20:29 Master is kind ! Oct 14 16:21:16 :D Oct 14 16:21:19 hmm Oct 14 16:21:28 #1024 bandaid works fine w/ moko8 here Oct 14 16:21:48 now lets see whether it still answers to a call Oct 14 16:22:08 mickeyl: Oct 14 16:22:15 nextIndex = ( index + 1 ) % len(self.states) Oct 14 16:22:17 That is wrong Oct 14 16:23:06 mickeyl, wasn't it already tested with moko8? Oct 14 16:23:18 quickdev: no, the only version i had in .tw was 9-beta1 Oct 14 16:23:21 (I think) Oct 14 16:23:25 AinuFallback: hmm Oct 14 16:23:27 why? Oct 14 16:23:32 Just checking Oct 14 16:23:35 maximum state number is len(self.states) Oct 14 16:23:41 so if you modulo that Oct 14 16:23:47 you will fall into 0 next Oct 14 16:23:51 Now I told that I feel stupid because I'm starting to wonder if I wasn't mislead Oct 14 16:23:52 no? Oct 14 16:23:57 Yeah, yeah, I know about modulo indeed :-p Oct 14 16:24:06 hehe Oct 14 16:24:16 well, I'd rather have you doublechecking than not Oct 14 16:24:17 What I described was prelock awake lock right ? Oct 14 16:24:17 so, thanks Oct 14 16:24:31 yeah Oct 14 16:24:41 let me dig out your mail Oct 14 16:25:08 no Oct 14 16:25:11 Oh, I mailed you ? Oct 14 16:25:14 the problem was LOCK being reported before AWAKE Oct 14 16:25:26 Ah I mailed userland Oct 14 16:25:26 you mailed to smartphones-standards Oct 14 16:25:29 err, userland Oct 14 16:25:36 err no, standards :) Oct 14 16:25:36 No, standards you're right Oct 14 16:25:40 hehe Oct 14 16:25:41 confusion hour Oct 14 16:26:01 DIM, AWAKE, LOCK then Oct 14 16:26:13 yeah, that's kind of wrong Oct 14 16:26:26 did you suspend in the meantime? Oct 14 16:26:38 No Oct 14 16:26:44 What is weird is that PRELOCK isn't even appearing Oct 14 16:26:54 mickeyl: why is there a "none" state by the way ? Oct 14 16:26:55 that's indeed strange Oct 14 16:27:02 i can see it w/ mdbus -s -l Oct 14 16:28:35 hmm Oct 14 16:28:39 Watching for the logs right now Oct 14 16:28:41 (none) i have not the slightest idea :D Oct 14 16:29:08 Ok then Oct 14 16:29:14 I know why I see awake Oct 14 16:29:17 It's my default Oct 14 16:29:28 I bet this is due to the bad names Oct 14 16:29:31 oh Oct 14 16:29:40 It was Oct 14 16:29:41 mickeyl, "I know that Moko7 firmware works well with this parameter but there is a report that Moko8 will not wake from GSM activity if the %SLEEP is issued.", so this means that openmoko had some deep sleep settings? Maybe they once introduced a bug? Do you have access to the firmware update code? Oct 14 16:29:49 So please consider fault as shared :-) Oct 14 16:29:58 :) Oct 14 16:30:53 quickdev: not wake from GSM activity... what does that mean? in suspend? Oct 14 16:31:44 mickeyl, I got that quote from the #1024 page Oct 14 16:31:57 k, let me respond there Oct 14 16:32:10 we have all GSM firmwares ever produced as binary Oct 14 16:32:18 damn.. Oct 14 16:32:22 no source codes? Oct 14 16:32:45 mickeyl: posted a follow-up to that on standard Oct 14 16:32:46 +s Oct 14 16:32:51 AinuFallback: ok Oct 14 16:33:03 mickeyl, makes sense that you haven't them..but who wrote the firmware updates? Oct 14 16:33:14 mickeyl: by the way regarding LPC, the link I posted above, did you ever think about working on performance issues in frameworkd ? Oct 14 16:33:18 (i.e. boot time ?) Oct 14 16:33:24 quickdev: i don't know if i'm allowed to tell the gory details of the horror stories about firmware updates Oct 14 16:33:36 quickdev: atm. we have a data rescue program running... Oct 14 16:34:16 AinuFallback: sure thing, improving boot time is a major cross layer issue which someone should tackle at some point of time. personally i have been waiting for upstream to complete their dbus renovation Oct 14 16:34:28 mickeyl, firmware data became lost? Oct 14 16:34:34 quickdev: something like that, ya Oct 14 16:34:51 at least the latest version Oct 14 16:34:55 nothing a binary hacker can't fix... Oct 14 16:35:54 not that having the source code would matter anyways Oct 14 16:36:01 since the interesting bits are binary only Oct 14 16:36:03 even for us Oct 14 16:36:05 ever have been Oct 14 16:36:29 mickeyl, are there some moko1-5 firmwares that might not have the bug? Oct 14 16:36:54 the old ones for sure Oct 14 16:37:01 since they have no deep sleep at all Oct 14 16:37:12 but using them would have the same effect as %SLEEP=2 Oct 14 16:38:26 mickeyl, is it verified that all moko-firmwares, that implement deep sleep suffer from the bouncing bug? Oct 14 16:38:39 maybe there's one version between that is not affected? Oct 14 16:40:52 hmm Oct 14 16:41:03 i don't think it's verified Oct 14 16:41:11 since in .tw they could not reproduce the bug at all anyways Oct 14 16:41:13 hmpf Oct 14 16:41:28 the thing is, later versions fix other bugs Oct 14 16:41:35 mickeyl: incoming call should trigger BUSY shouldn't it ? Oct 14 16:41:41 pardon me guys, but a .so cannot have a main(), can it? Oct 14 16:41:51 Sup3rkiddo: it can, but it will not be honored Oct 14 16:42:05 mickeyl, oh!! ok Oct 14 16:42:07 mickeyl, but that would be a starting point for further investigation...don't you think that could be a great possibility? Oct 14 16:42:18 AinuFallback: incoming call should trigger a busy, yeah. we don't do that in the rules yet Oct 14 16:42:24 Sup3rkiddo: try running ld.so :) Oct 14 16:42:24 quickdev: i'm afraid not Oct 14 16:42:38 quickdev: at the end of the day, you don't want to go back to moko2 or moko3 Oct 14 16:42:55 since there has been other problems w/ suspend/resume and SIM access Oct 14 16:43:06 mickeyl, you don't want to, but you could compare the updates.. Oct 14 16:43:09 mickeyl: I was just trying to trigger brightness with rules in fact Oct 14 16:43:24 quickdev: that will not get us much Oct 14 16:43:29 again, it's in the binary portion Oct 14 16:43:33 that TI gives us Oct 14 16:43:36 But I was wondering how to reload rules :-) Oct 14 16:43:47 AinuFallback: add one, that should trigger an update ;) Oct 14 16:43:54 Ok then Oct 14 16:43:55 AinuFallback: we should inotify on the rules files Oct 14 16:44:02 should make a ticket on that Oct 14 16:44:12 mickeyl: using dbus by the w ay ? Oct 14 16:44:17 or using rule file editing ? Oct 14 16:44:20 (which I did) Oct 14 16:44:27 using dbus Oct 14 16:44:30 (and I guess you were talking about the former) Oct 14 16:44:32 we don't have an inotify yet Oct 14 16:44:43 Well, which path should I use as an object then ? Oct 14 16:44:54 mickeyl, why are the updates not interesting? and updates should have source code.. Oct 14 16:44:56 good question, never did that Oct 14 16:45:12 charlie added that just yesterday Oct 14 16:45:26 quickdev: again.... we DO NOT have the source code of TI updates Oct 14 16:45:27 Ok then Oct 14 16:45:29 Will restart frameworkd :-) Oct 14 16:45:42 quickdev: we have binaries from them Oct 14 16:45:43 mickeyl, updates written by TI, ok ;) Oct 14 16:45:58 *nod* Oct 14 16:46:07 there is nothing in the part _we_ have that could affect the behaviour Oct 14 16:46:47 fwiw, moko8 resumes fine for me here Oct 14 16:46:53 with sleep=2 Oct 14 16:49:23 resume problem report was from ljp Oct 14 16:49:51 perhaps he can provide additional info. Oct 14 16:50:05 *nod* commented on bug. Oct 14 16:50:58 ok just modified my rules, will try brightness Oct 14 16:51:13 mickeyl: what's the current heuristic used to attempt to return to %SLEEP=4 mode with FSO? Oct 14 16:51:15 yaml rules are weird though Oct 14 16:51:16 should be xml Oct 14 16:51:33 working perfectly here Oct 14 16:52:02 mwester: recording every movement from unreg to reg in a list with its time between unreg and reg Oct 14 16:52:11 every unreg/reg under 3.5 seconds is count as a recamping Oct 14 16:52:40 if we had >= 5 recampings at all, we check the interval between start of recamping and now Oct 14 16:52:55 Ok... I've observed up to 7 seconds here, but the norm is around 2.5 - 4 seconds, I estimate. Oct 14 16:52:57 if that gives a factor of >= 1 recamping per minute, we enable SLEEP=2 Oct 14 16:53:07 after 30 minutes, trying SLEEP=4 again Oct 14 16:53:13 by the way mickeyl Oct 14 16:53:16 then it goes back to the start Oct 14 16:53:18 if you are plugged in Oct 14 16:53:21 and you restart frameworkd Oct 14 16:53:27 it won't get it's plugged in Oct 14 16:53:44 AinuFallback: yeah, somewhere in odeviced there's a big FIXME that says "add coldstart checking" ;) Oct 14 16:53:47 mickeyl: Ok, sounds like a good start. I've been giving thought to a corner case that concerns me a bit. Oct 14 16:54:43 freesmartphone.org: 03ainulindale 07framework * r8b55ff39b037 10/etc/freesmartphone/oevents/rules.yaml: Slight modification of rules.yaml to set brightness to 90 on incoming calls. Oct 14 16:54:56 Here it is Oct 14 16:55:01 AinuFallback: cool Oct 14 16:55:20 Took the liberty to do it, as I requested whether I could or not yesterday mickeyl :-) Oct 14 16:55:30 sure Oct 14 16:55:41 If I bork anything, anyway, feel free to whip me Oct 14 16:55:44 mickeyl: Consider a fringe area, or travelling through a set of micro-cells -- one might end up with a false positive very easily. So I am wondering if we could/should take into consideration the RSSI of the registered cells and/or the actual CI/LAC of the cells. Just thinking... Oct 14 16:55:47 :) Oct 14 16:55:51 Or to call me Guillaume :-p Oct 14 16:55:55 hahah Oct 14 16:55:59 that's mean Oct 14 16:56:13 :-) Oct 14 16:56:35 mwester: hmm, i agree that might trigger a false report. but i think it's a pathological case and with the retry of 30 minutes for deep sleep shouldn't be too bad, even if we have a false positive Oct 14 16:56:58 the thing i'm worried about is Oct 14 16:57:05 we reenable to give it another try Oct 14 16:57:07 then we go into suspend Oct 14 16:57:14 it starts recamping again Oct 14 16:57:17 boom, we lose calls Oct 14 16:57:24 but do not detect since we are sleeping Oct 14 16:57:28 Ouch. Oct 14 16:57:35 and that's unfixable Oct 14 16:57:44 until we make it wake up on CREG Oct 14 16:57:46 which we do not want Oct 14 16:58:30 the only way to prevent this is to not suspend at all Oct 14 16:58:37 cpufreq, anyone? ... Oct 14 16:58:39 Also, if we re-enable, during the "test for recamping" period, the re-enabling could be disruptive. So if the user attempts to place a call at that time, they may get a LOST CARRIER. Oct 14 16:59:22 ooh ya, didn't test the actual effect of that Oct 14 16:59:24 It would seem to me that we would need to coordinate the test to re-enter sleep=4 with the suspend logic, but also with the dialer. Oct 14 16:59:40 I did test it -- it will disrupt outgoing calls :( Oct 14 16:59:47 really? *sigh* Oct 14 16:59:57 ~lart gsm and TI and closed firmwares and everything Oct 14 17:01:07 dinner Oct 14 17:01:15 Yeah, I was hoping we could just re-enable SLEEP=4 at the end of a call, and see if it starts to bounce -- but I quickly found that if it did, and you immediately dialed another call, it would go through only about 1/2 the time for me. Oct 14 17:02:47 so the only way to fix that is to screw power consumption Oct 14 17:02:53 and disable sleep for good Oct 14 17:02:57 but that costs A LOT Oct 14 17:03:32 mickey|dinner: why is waking up on CREG undesirable? Oct 14 17:03:44 pb_: because CREG is triggered on every cell handover Oct 14 17:03:49 which happens constantly Oct 14 17:04:04 (if you happen to live within the boundary of a cell) Oct 14 17:04:18 oh, right, it flip-flops between cells really often? Oct 14 17:04:35 that is a pain. how frequently does it happen? Oct 14 17:04:37 yes, in certain areas once every couple of seconds Oct 14 17:05:17 and there is nothing you can do to prevent that Oct 14 17:05:21 since it's triggered by the BTS Oct 14 17:05:27 bbab Oct 14 17:05:28 iab Oct 14 17:05:29 ah, that is a shame. if it was once a minute or so then it might be tolerable but I guess every second is too much. Oct 14 17:07:02 pb_: I have both T-Mobile and AT&T SIM cards and I must live in an "interesting" area for cell coverage -- the eng. mode AT commands show that I can see three or four towers for each SIM, and they about the same signal quality. So I will change cell sites randomly, and sometimes will end up roaming by changing rooms! Oct 14 17:08:37 mwester: heh. yeah, I have seen that sort of thing as well in the past. Oct 14 17:09:09 it doesn't happen to me when I am on my home network, but if I am roaming and I have several "equally good" foreign networks to choose from then I do seem to end up flipping randomly between them at a high rate. Oct 14 17:10:02 I tried the AT command to force registration to a network, in hopes that would stop the bouncing. It prevented the roaming from occuring, but not the bouncing. Oct 14 17:10:30 that is annoying Oct 14 17:11:06 mickey|dinner: ah I had this bug again Oct 14 17:11:42 (no dimming) Oct 14 17:12:06 And it seems that ogpsd is launching itself Oct 14 17:12:59