**** BEGIN LOGGING AT Wed Jan 19 02:59:57 2011
Jan 19 05:23:40 <holtmann> wagi: ping
Jan 19 05:25:45 <holtmann> wagi: What did you want for the bearer stuff?
Jan 19 05:48:01 <kristenc> denkenz: holtmann: around?
Jan 19 05:48:11 <holtmann> kristenc: Yes.
Jan 19 05:48:15 <kristenc> yay!
Jan 19 05:48:25 <kristenc> I have a question about signal strength updates.
Jan 19 05:48:46 <kristenc> does ofono request signal strength updates, or do they get pushed by the modem firmware?
Jan 19 05:48:56 <kristenc> and is that configurable?
Jan 19 05:49:06 <kristenc> they are keeping the usb bus from suspending properly
Jan 19 05:49:23 <holtmann> Depends on your modem firmware.
Jan 19 05:49:49 <holtmann> The good ones give it to you via unsolicited vendor command.
Jan 19 05:50:13 <kristenc> can we make them stop?
Jan 19 05:50:30 <kristenc> or change the frequency?
Jan 19 05:50:35 <holtmann> Depends on the hardware.
Jan 19 05:50:43 <denkenz> yes, but you have to turn the unsolicited notification off
Jan 19 05:50:53 <kristenc> how do we do that?
Jan 19 05:50:55 <holtmann> On proper ones we could, but on crap like Huawei they just come in on the second TTY.
Jan 19 05:51:10 <holtmann> With all the other crap they send as well.
Jan 19 05:51:14 <kristenc> so we have crap.
Jan 19 05:51:20 <kristenc> is there anything we can do about it?
Jan 19 05:51:49 <kristenc> even killing ofono seems to not stop the hw from sending stuff.
Jan 19 05:51:50 <holtmann> So here is the problem with all this stuff. We don't know when the USB bus or any other bus wants to suspend.
Jan 19 05:52:10 <holtmann> So we can't do anything proper here since we don't know when.
Jan 19 05:52:16 <denkenz> Ah the wonderful world of suspend
Jan 19 05:52:16 <holtmann> And in case of Huawei we have no control.
Jan 19 05:52:45 <holtmann> I really mean no control whatsoever. Besides bringing the modem offline ;)
Jan 19 05:53:04 <denkenz> There are two ways, you create an interface on the modem driver that lets you suspend / resume the modem unsolicited notifications
Jan 19 05:53:12 <denkenz> And send the appropriate commands
Jan 19 05:53:20 <denkenz> I think the huawei ^RSSI can be turned off
Jan 19 05:53:31 <holtmann> You can turn all notifications off.
Jan 19 05:53:37 <holtmann> And that means all.
Jan 19 05:53:43 <kristenc> ok - how do we do turn them off.
Jan 19 05:53:58 <denkenz> You don't want that
Jan 19 05:54:07 <denkenz> The SMS notification would be off as well ;)
Jan 19 05:54:13 <kristenc> hehe
Jan 19 05:54:29 <holtmann> Let me look this up.
Jan 19 05:54:44 <kristenc> we are voting that we don't care about the sms thing right now.
Jan 19 05:54:59 <kristenc> lower power is more important than that feature.
Jan 19 05:55:07 <denkenz> AT^CURC=0?
Jan 19 05:55:24 <kristenc> just echo that to the modem?
Jan 19 05:55:55 <denkenz> yeah, without the question mark
Jan 19 05:56:10 <holtmann> Unsolicited report control command ^CURC
Jan 19 05:56:13 <kristenc> which is the control port on huawei, usb0 or 1?
Jan 19 05:56:20 <holtmann> Hah, you were faster ;)
Jan 19 05:57:02 <denkenz> lol, Google was faster
Jan 19 05:57:14 <holtmann> I had to find the docs ;)
Jan 19 05:57:48 <holtmann> This still does not solve the problem that you need to indicate to oFono when to execute this AT command.
Jan 19 05:58:05 <holtmann> oFono has no idea about USB wanting to auto-suspend a device.
Jan 19 05:58:18 <kristenc> yes - but lets see if it works at all first, then figure out how we'd make it work in real life.
Jan 19 05:58:22 <denkenz> exactly, you either do this based on a timer (e.g. screen off, suspend) or some form of gpio / whatever magic
Jan 19 05:58:48 <holtmann> But then when you suspend it, how do you get it resumed properly.
Jan 19 05:59:00 <kristenc> if you always have notifications turned off, would the modem function?
Jan 19 05:59:17 <denkenz> modem still functions, it just doesn't write anything to the host
Jan 19 05:59:45 <holtmann> The ^CURC affects things like signal strength, mode change, SIM detection etc.
Jan 19 05:59:56 <denkenz> Resuming is another problem, but presumably there are on_resume scripts
Jan 19 06:00:15 <denkenz> But sounds like a wonderful situation to me ;)
Jan 19 06:00:36 <holtmann> We are doing this execute a script crap and then tell oFono to resume.
Jan 19 06:00:46 <holtmann> That is like fully wasteful.
Jan 19 06:00:57 <kristenc> so having notifications off all the time sounds like it just isn't going to work at all.
Jan 19 06:01:22 <holtmann> Nope. Even with Huawei only disabling certain vendor notifications, it still is a problem.
Jan 19 06:01:44 <holtmann> So potentially you would need to re-enable them on cell change, incoming SMS etc.
Jan 19 06:02:03 <holtmann> You need to find a proper trigger to a) disable them and then b) re-enable them.
Jan 19 06:02:04 <denkenz> cell change? nah
Jan 19 06:02:16 <denkenz> however, on resume you need to re-query a bunch of stuff
Jan 19 06:02:22 <holtmann> Hell I don't know. This is USB selective suspend.
Jan 19 06:02:25 <kristenc> I suppose you could have them off and then every once in a while turn them back on and see if anything has changed.
Jan 19 06:02:34 <holtmann> Not gonna work either.
Jan 19 06:02:46 <kristenc> it's s0i3 actually
Jan 19 06:02:46 <holtmann> You can't query any of these.
Jan 19 06:03:03 <denkenz> Ah the wonderful world of Huawei
Jan 19 06:03:06 <kristenc> the problem is that s0i3 cannot work if usb is busy.
Jan 19 06:03:46 <holtmann> With MBM hardware this would be a lot easier. They have at least thought about this.
Jan 19 06:04:27 <denkenz> Querying many of these things is going to be hard, you also need to have pretty serious intimate knowledege of what oFono actually queries / what can change
Jan 19 06:05:09 <denkenz> And disabling SMS in suspend is a bad idea
Jan 19 06:05:44 <kristenc> would it work to make the firmware delay notifications so that they only sent them up every 1 or 2 seconds.
Jan 19 06:05:56 <holtmann> This is a nasty idea, but you might need to hack into GAtChat to have some sort of idle timeout callback. If no messages are send for a certain amount of time. Disable the vendor notifications. And once you get one incoming nofitication from the modem re-enable them.
Jan 19 06:06:29 <holtmann> Current Huawei firmware does not support that. And they haven't updated that one since 2007. And as far as I heard have no plans to even fix bugs.
Jan 19 06:06:47 <kristenc> we can make them change the firmware.
Jan 19 06:07:03 <holtmann> Good luck. Let them also fix the 3000 bugs they have.
Jan 19 06:07:11 <kristenc> probably not that.
Jan 19 06:07:25 <kristenc> changing vendors is apparently not an option
Jan 19 06:07:41 <holtmann> Are you sure it is ^RSSI that keeps this up. And not just the ^DSFLOWRPT
Jan 19 06:07:50 <kristenc> let me capture a log
Jan 19 06:08:10 <holtmann> Of course not. Since when people listen to my hardware advice ;)
Jan 19 06:08:23 <denkenz> Hacking gatchat won't work
Jan 19 06:08:37 <denkenz> since even things like signal strength querying have to go via totally different path
Jan 19 06:08:46 <holtmann> The ^DSFLOWRPT comes every 2 seconds.
Jan 19 06:09:18 <kristenc> we are rebooting.  this takes a while.... standby
Jan 19 06:12:48 <kristenc> sigh - crash.
Jan 19 06:17:33 <kristenc> holtmann: denkenz: http://pastebin.com/2KGin6Gb
Jan 19 06:18:23 <kristenc> that is with RSSI still on
Jan 19 06:18:37 <holtmann> kristenc: Please give me just "env OFONO_AT_DEBUG=1 ./src/ofonod -n".
Jan 19 06:18:38 <kristenc> with it off, we still get BOOT every 30 seconds.
Jan 19 06:20:49 <holtmann> So it is essentially ^BOOT that is causing the keep alive.
Jan 19 06:21:02 <kristenc> yes - I think so.
Jan 19 06:21:47 <kristenc> can we turn off the BOOT stuff?
Jan 19 06:22:38 <holtmann> I have no documentation on what ^BOOT actually reports.
Jan 19 06:22:55 <kristenc> the at debug log didn't seem useful.
Jan 19 07:45:46 <Makis> does anyone have any pointers to how to use an at modem after the modem.conf file and generic at modem driver were removed?
Jan 19 10:17:05 <wagi> holtmann: pong
Jan 19 11:25:05 <demarchi> holtmann: humn... let me check
Jan 19 11:25:34 <holtmann> wagi: About the bearer stuff. Denis mentioned to me that you had some wishes there.
Jan 19 11:31:55 <akiniemi> holtmann: so auto-only it is then?
Jan 19 11:32:51 <holtmann> The is a language thing. I think auto-only is clearer than forced-auto.
Jan 19 11:34:00 <holtmann> So besides the other comments, this seems fine. Not that I have a SIM card to actually test this.
Jan 19 11:34:30 <holtmann> And while you are at it. Kill the Deregister method. With the Online property that seems rather pointless.
Jan 19 11:35:34 <holtmann> akiniemi: I wonder how the iPhone or Android handles these SIM cards.
Jan 19 11:47:08 <demarchi> holtmann: does your SIM have pin locked?
Jan 19 11:48:23 <demarchi> this is probably due 67486801d02bae51c45bcfa1741d193fb3f9e431
Jan 19 11:49:00 <demarchi> but i can't think in a case it will call notify_sim_state twice]
Jan 19 11:56:14 <Jeevaka> is the git server down?
Jan 19 12:02:57 <demarchi> holtmann: i think i found it... it happens if a ^SYSINFO arrives after a timeout had been set up
Jan 19 12:03:30 <demarchi> holtmann: could you check if this patch fixes for you?
Jan 19 12:03:32 <demarchi> holtmann: http://codepad.org/NCNe0qtY
Jan 19 12:18:18 <akiniemi> holtmann: haven't tested with android or ios
Jan 19 12:18:45 <akiniemi> holtmann: and sure, I will kill the Deregister() as well
Jan 19 12:19:49 <akiniemi> Jeevaka: seems like it
Jan 19 12:21:09 <akiniemi> master.kernel.org is live and kicking, though
Jan 19 12:21:23 <demarchi> Jeevaka: it was
Jan 19 12:21:30 <demarchi> Jeevaka: now it seems to be working
Jan 19 12:22:03 <akiniemi> demarchi: The web interface is still funky
Jan 19 12:24:46 <Jeevaka> demarchi, akiniemi: its still down from my side
Jan 19 12:25:01 <Jeevaka> may be i'll wait for some more time
Jan 19 12:37:08 <holtmann> demarchi: My SIM cards are all unlocked.
Jan 19 12:44:11 <demarchi> holtmann: patch applies anyway...
Jan 19 12:44:28 <demarchi> does it solve for you, i'm sending it to ML
Jan 19 13:41:10 <wagi> holtmann: sorry, was in a (yet another) meeting
Jan 19 13:41:30 <wagi> holtmann: IIRC, we had discussion about the bearer naming
Jan 19 13:42:02 <wagi> holtmann: we want to identify them either as technology (e.g. umts, wlan) or as service name
Jan 19 13:42:12 <wagi> holtmann: my-private-vpn
Jan 19 13:42:46 <wagi> but this was all in connman
Jan 19 13:43:07 <wagi> I can't remember anything special about the bearer in ofono
Jan 19 13:43:17 <wagi> but I tend to forget a lot of things :)
Jan 19 13:55:46 <Jeevaka> holtmann: ping
Jan 19 14:22:40 <holtmann> Jeevaka: pong
Jan 19 14:23:26 <Jeevaka> holtmann: its about the set_buffered and set_encoding issue
Jan 19 14:24:34 <Jeevaka> mailed about the findings
Jan 19 14:24:58 <holtmann> There is something fishy in GLib that screws this up.
Jan 19 14:30:35 <Jeevaka> how to proceed from here on this issue
Jan 19 14:37:13 <holtmann> I think I got it.
Jan 19 14:37:25 <holtmann> The problem is when you try to set it twice. Then it pukes itself.
Jan 19 14:37:38 <holtmann> And g_at_chat_new already does unblocking, no encoding and no buffering.
Jan 19 14:38:06 <holtmann> For some reason you can only set encoding if buffering is enabled.
Jan 19 14:39:40 <holtmann> Jeevaka: Just pushed a patch for it.
Jan 19 14:40:07 <holtmann> I don't have my IFX board up and running right now. So can't easily test it.
Jan 19 14:40:22 <Jeevaka> i have. so no worries
Jan 19 14:40:59 <Jeevaka> is it possible to copy paste the fix in codepad
Jan 19 14:41:33 <Jeevaka> fix: is it just the removal of set_buffered and set_encoded
Jan 19 14:48:13 <holtmann> Yes.
Jan 19 14:48:22 <holtmann> And also the set NON BLOCKING.
Jan 19 15:03:51 <Jeevaka> denkenz: ping
Jan 19 15:06:26 <denkenz> Jeevaka: pong
Jan 19 15:07:20 <Jeevaka> one of the review comment for launch browser is to move the qualifier check to stkutil. for most of the other cases it is handled in stk.c
Jan 19 15:08:58 <Jeevaka> does that mean we need to do the same for other commands as well
Jan 19 15:18:18 <akiniemi> denkenz: you mentioned separating online from SIM availability
Jan 19 15:18:25 <akiniemi> denkenz: how serious were you? ;)
Jan 19 15:23:44 <denkenz> Jeevaka: I looked briefly and most of the data not understood were related to the attribute conversion
Jan 19 15:23:53 <denkenz> Jeevaka: The rest should be in stkutil.c
Jan 19 15:23:59 <denkenz> akiniemi: Pretty serious
Jan 19 15:24:55 <Jeevaka> about the USER REJECT for launch browser
Jan 19 15:25:33 <Jeevaka> as per the description, it applies but as per the table it doesnt apply
Jan 19 15:25:39 <Jeevaka> so which one to consider ?
Jan 19 15:26:15 <wagi> holtmann: should I send the gdbus fixes for ofono as well, or do you apply the two patches from bluez? Johan just applied them.
Jan 19 15:27:11 <denkenz> Jeevaka: Good question
Jan 19 15:27:27 <denkenz> look at what the test specification does, is user reject ever a valid case?
Jan 19 15:27:51 <akiniemi> denkenz: there's even a bug there somewhere: Powered==True even when modem is in PRE_SIM state, meaning that setting Online to True will fail
Jan 19 15:28:30 <akiniemi> denkenz: with nothing in the Modem interface to tell when Online==True might succeed...
Jan 19 15:29:37 <Jeevaka> holtmann: i verified ur fix and it works in ifx
Jan 19 15:30:08 <denkenz> akiniemi: I'm lost, we don't allow setting online until after we get the imsi
Jan 19 15:30:17 <Jeevaka> denkenz: test specification, doesnt have a test case for user reject.
Jan 19 15:30:47 <denkenz> Jeevaka: Then you might have to send a browser temporarily unavailable or something
Jan 19 15:31:04 <akiniemi> denkenz: Well, exactly, but the call for setting Powered to True will complete way before the IMSI is known
Jan 19 15:31:22 <denkenz> akiniemi: Powering has nothing to do with Online though
Jan 19 15:31:31 <denkenz> you can be powered and pin locked
Jan 19 15:31:56 <Jeevaka> denkenz: in that case do we need to have the name as "ConfirmLaunchBrowser" or "LaunchBrowser"
Jan 19 15:32:41 <denkenz> I think Confirm is fine since there is an implied confirmation step
Jan 19 15:32:52 <Jeevaka> ok
Jan 19 15:32:56 <denkenz> The user is supposed to be asked
Jan 19 15:33:10 <denkenz> The disconnect between the table and the description is funny though
Jan 19 15:33:16 <denkenz> Shows how often that feature is used ;)
Jan 19 15:33:33 <Jeevaka> :)
Jan 19 15:41:22 <akiniemi> denkenz: online means "turn the radio on", the only requirement for being able to do that is that the modem is Powered==True
Jan 19 15:41:57 <akiniemi> denkenz: Sure, if SIM is unlocked, Online==True might have a side effect of a registration, too
Jan 19 15:42:31 <kvehmanen> akiniemi: hmm, I'm getting a lot of timeouts getting IMSI from N900 from isi sim.c
Jan 19 15:42:42 <kvehmanen> akiniemi: not seen this before, so possible something related to the new gisi?
Jan 19 15:42:43 <akiniemi> IMO, from org.ofono.Modem point of view you should be able to './enable-modem && ./online-modem'
Jan 19 15:42:56 <akiniemi> Now ^ fails
Jan 19 15:43:36 <akiniemi> kvehmanen: could be
Jan 19 15:43:55 <akiniemi> kvehmanen: can you set OFONO_ISI_TRACE=1 and OFONO_ISI_DEBUG=1 and re-run?
Jan 19 15:44:11 <kvehmanen> akiniemi: nothing interesting from those really
Jan 19 15:44:59 <kvehmanen> akiniemi: I'll try a coldboot first (softboot didn't help)
Jan 19 15:50:34 <denkenz> akiniemi: I don't disagree, but in one of the workshops you guys said we should not online the modem prior to sim pin entry for power saving reasons
Jan 19 15:53:24 <akiniemi> denkenz: I
Jan 19 15:53:30 * akiniemi oops
Jan 19 15:53:45 <akiniemi> denkenz: don't guarantee consistency in my arguments ;)
Jan 19 15:57:33 <kvehmanen> akiniemi: still no go, oh well, I'll try to debug this 
Jan 19 15:58:31 <akiniemi> kvehmanen: you tree freshly pulled?
Jan 19 15:58:41 <denkenz> akiniemi: btw, your ecc patch doesn't seem right according to 22.101
Jan 19 15:59:33 <akiniemi> denkenz: oh?
Jan 19 15:59:49 <denkenz> besides, the default_en_list is always added (see set_new_ecc)
Jan 19 16:01:33 <denkenz> So is there a problem or what are you trying to fix?
Jan 19 16:02:14 <akiniemi> denkenz: could be wrong, but I figured set_new_ecc() is never called after failed EFecc reads
Jan 19 16:02:30 <akiniemi> denkenz: Because new_en_list at that point is NULL...
Jan 19 16:02:48 <denkenz> Failed is different from empty though
Jan 19 16:02:49 <akiniemi> denkenz: So the default_en_list_no_sim entries persist in the ecc
Jan 19 16:03:17 <kvehmanen> akiniemi: yep, latest master
Jan 19 16:03:20 <akiniemi> denkenz: shouldn't both end up in the 'check'
Jan 19 16:03:46 * akiniemi will return in a couple of hours...
Jan 19 16:04:13 <denkenz> The way it works is if we fail to read the SIM we leave the ECC list as is (e.g. default no sim)
Jan 19 16:04:37 <denkenz> However, you should never fail to read from the SIM in normal case
Jan 19 16:26:30 <holtmann> wagi: I apply them. Don't worry.
Jan 19 16:27:43 <holtmann> akiniemi: Online=True will succeed once SIM Present=True and IMSI is signaled.
Jan 19 16:28:29 <holtmann> akiniemi: I wrote the tools/auto-enable for testing this.
Jan 19 16:37:33 <demarchi> denkenz: there are some changes i'd like to do to patches from kristen
Jan 19 16:38:04 <demarchi> how to i procede? should i send the patches without changing the commit author/message?
Jan 19 16:40:32 <denkenz> demarchi: Just mention 'Based on patches from ...'
Jan 19 17:07:50 <holtmann> denkenz: Btw. I am fine with the SIM retry patches, but they are not super elegant.
Jan 19 17:08:12 <holtmann> If you have no objections, I would go ahead and apply them.
Jan 19 17:10:31 <denkenz> why are we doing it this way again?
Jan 19 17:11:04 <denkenz> If we wanted to save off the for loops, the better way to do it would be a macro in drivers/atmodem/sim.c
Jan 19 17:11:21 <denkenz> and separate callbacks calling the macro
Jan 19 17:11:37 <holtmann> Sure, but do we really wanna spent effort with this right now?
Jan 19 17:11:48 <holtmann> wagi: Are you still here?
Jan 19 17:12:06 <denkenz> I dunno, but it looks ugly the way it is
Jan 19 17:12:55 <holtmann> It is fine with me. My only worry is the waste of retires array for all possible codes. Since normally it will be only 4 anyway.
Jan 19 17:17:20 <Jeevaka> holtmann, denkenz: what would be the better option for this sim retries
Jan 19 17:17:39 <Jeevaka> holtmann: i can also change the array to 4
Jan 19 17:18:05 <denkenz> Just do it like I outlined
Jan 19 17:18:21 <denkenz> 2 separate callbacks, and a macro for creating the result array
Jan 19 17:18:49 <Jeevaka> ok, i'll do that
Jan 19 17:21:20 <denkenz> passwd_types can be declared with the right size in this case as well
Jan 19 17:21:28 <denkenz> and the macro can take the array + size
Jan 19 17:22:23 <Jeevaka> do you mean the retries array and retries size
Jan 19 17:24:04 <denkenz> yep
Jan 19 17:24:27 <denkenz> or the passwd_types rather
Jan 19 17:31:57 <pessi> kvehmanen: the n900 modem is busy in boot, let it boot and then settle, then try to connect usb cable
Jan 19 17:32:42 <demarchi> denkenz: are you ok with the way the sms is serialized to disk?
Jan 19 17:33:03 <denkenz> last I looked it was OK
Jan 19 17:33:23 <demarchi> i don't like to store all that information in the file name
Jan 19 17:33:28 <pessi> denkenz: normally we do not want to waste power registering when there is no sim
Jan 19 17:33:55 <demarchi> denkenz: imo it shoud be as the content of the file
Jan 19 17:33:59 <pessi> denkenz: only if we have emergency call we have to do that
Jan 19 17:34:03 <pessi> .. to make
Jan 19 17:35:23 <demarchi> yeah but in this case i'd need an extra file 
Jan 19 17:35:32 <denkenz> pessi: I know, that makes sense, however you guys made a bunch of stipulations that is being implemented by IFX which do not really make sense if you only go online in an emergency
Jan 19 17:36:01 <denkenz> demarchi: The idea to store the info in the file was to be able to easily remove it
Jan 19 17:36:03 <pessi> such as? ;-o
Jan 19 17:36:26 <denkenz> demarchi: So we don't have to re-read the filesystem
Jan 19 17:36:54 <denkenz> pessi: Like weird rules of how to use operator specific / country specific eccs when sim is not present or pin locked
Jan 19 17:37:53 <denkenz> including receiving the ECCs OTA
Jan 19 17:46:35 <Jeevaka> denkenz: let me know if this is fine for pin retries macro http://codepad.org/h42giici
Jan 19 17:47:09 <pessi> I hope we do not require receiving ECCs OTA with limited service
Jan 19 17:47:14 <pessi> I doubt it is possible
Jan 19 17:58:40 <Jeevaka> denkenz: ignore the previous link content
Jan 19 18:15:28 <denkenz> Jeevaka: Yeah that's basically the right direction
Jan 19 18:19:47 <Jeevaka> denkenz: can we agree on this http://codepad.org/rQ7n4od3
Jan 19 18:20:21 <denkenz> why bother with retry_cnt?
Jan 19 18:20:59 <denkenz> But yes, basically that's what I want
Jan 19 18:21:09 <Jeevaka> agree, its always OFONO_SIM_PASSWORD_INVALID
Jan 19 18:21:39 <Jeevaka> but, just wanted to leave it open
Jan 19 18:22:13 <Jeevaka> if somebody uses retries with 5, then we will end up in iterating 16 times
Jan 19 18:22:20 <Jeevaka> just wanted to avoid that
Jan 19 18:22:49 <denkenz> uh?
Jan 19 18:23:01 <denkenz> retry_cnt is used to initialize the array to -1
Jan 19 18:23:06 <Jeevaka> yes
Jan 19 18:23:08 <denkenz> if someone tries it with 5 they will crash the core
Jan 19 18:23:14 <Jeevaka> s
Jan 19 18:23:16 <Jeevaka> is that ok
Jan 19 18:23:43 <denkenz> crashing the core? no ;)
Jan 19 18:24:15 <Jeevaka> so, i assume that you are ok with retry_cnt :)
Jan 19 18:25:07 <denkenz> why can't you do for (i = 0; i < OFONO_SIM_PASSWORD_INVALID; i++) retry[i] = -1
Jan 19 18:25:35 <denkenz> If someone wants a smaller array they're doing something wrong anyway
Jan 19 18:26:31 <denkenz> Try to not give people extra ways to shoot themselves, they will happily use them ;)
Jan 19 18:27:14 <Jeevaka> ok
Jan 19 18:36:12 <demarchi> denkenz: so... suppose we are turned off when we are saving a file
Jan 19 18:36:23 <demarchi> there might be 2 problems:
Jan 19 18:37:51 <demarchi> 1. we might let tmp files on that dir
Jan 19 18:38:00 <demarchi> when recovering,
Jan 19 18:38:16 <demarchi> kristen was using sscanf(dir->d_name, "%*u-%lu-%as", &flags, &uuid);
Jan 19 18:39:23 <demarchi> thus she was considering those files
Jan 19 18:40:00 <demarchi> 2. not considering the tmp files, the rmdir call will fail afterwards, since dir is not empty
Jan 19 18:41:27 <denkenz> So the dangling tmp file is a good point
Jan 19 18:41:45 <denkenz> Perhaps we should remove all tmp files when starting up
Jan 19 18:41:51 <demarchi> and i think this apply not only for sms backup
Jan 19 18:42:07 <denkenz> Yes, it applies to everything in STORAGEDIR
Jan 19 18:42:11 <demarchi> but any storage that uses write_file
Jan 19 18:42:44 <demarchi> i was trying to find a way not to let these files.... i was hoping linux had a fdlink() function
Jan 19 18:42:45 <denkenz> So I'd say just add something to main.c when starting up, clear up any tmp file templates 
Jan 19 18:42:56 <demarchi> or something like this, so i can unlink the file
Jan 19 18:43:08 <demarchi> and then create a new file off a file descriptor
Jan 19 18:43:33 <demarchi> but i think this is not possible.... at least i couldn't find an easy way
Jan 19 18:45:42 <demarchi> another question: why do we need to recalculate the position in queue when we are recovering?
Jan 19 18:46:42 <demarchi> ( i'm talking about
Jan 19 18:46:48 <demarchi> +       /* rename directory to reflect new position in queue */
Jan 19 18:46:54 <demarchi> in sms_tx_queue_load()
Jan 19 18:54:11 <denkenz> been a while, but I believe she uses a monotonically increasing counter when writing to disk
Jan 19 18:54:27 <demarchi> right
Jan 19 18:54:39 <denkenz> so messages can be cancelled / fail
Jan 19 18:54:56 <denkenz> and you also don't want to overflow the counter
Jan 19 18:55:31 <denkenz> whether this is really needed I'd have to look harder
Jan 19 18:55:45 <denkenz> It made sense to me at the time
Jan 19 18:55:50 <demarchi> ahn... i'm trying to get rid of this counter
Jan 19 18:56:26 <denkenz> You could make use of the created timestamp on the directory
Jan 19 19:00:35 <denkenz> ah I know why now
Jan 19 19:00:45 <denkenz> she uses the id to delete the entries when the sms is sent
Jan 19 19:00:49 <denkenz> and the id is reset to 0
Jan 19 19:00:56 <denkenz> when the atom is re-created
Jan 19 20:32:16 <akiniemi> denkenz: bug report says with a SIM present but without any ENs, the ECC list is the default list (*not* default_en_list_no_sim)
Jan 19 20:32:59 <akiniemi> denkenz: This is basically what my patch was trying to achieve, i.e., reset the ENs to default_en_list only
Jan 19 20:58:54 <denkenz> I'm lost now
Jan 19 20:59:32 <Jeevaka> denkenz: are the changes done for the pin retries ok now?
Jan 19 21:02:08 <denkenz> Jeevaka: Yes, that's perfect
Jan 19 21:02:26 <padovan> denkenz: DUN has nothing to do with netreg as well, right?
Jan 19 21:03:18 <denkenz> padovan: Nope
Jan 19 21:03:26 <denkenz> akiniemi: So I think I know what you're trying to achieve
Jan 19 21:03:56 <denkenz> akiniemi: In the case of G2, if the sim read succeeds and there are no EFecc entries, then we never call set_new_ecc
Jan 19 21:04:31 <denkenz> And the same with g3 ECC
Jan 19 21:04:39 <padovan> denkenz: Good, one more patch to throw out.
Jan 19 21:09:30 <denkenz> akiniemi: Question is how do you interpret 22.101 in the case of EFecc missing ;)
Jan 19 21:10:40 <akiniemi> denkenz: indeed. I was lazy and trusted the tester's interpretation (and experience) ;)
Jan 19 21:13:21 <denkenz> So you probably want this:
Jan 19 21:13:23 <denkenz> @@ -2112,9 +2112,6 @@ static void ecc_g2_read_cb(int ok, int total_length, int r
Jan 19 21:13:24 <denkenz>                                                                 g_strdup(en));
Jan 19 21:13:24 <denkenz>         }
Jan 19 21:13:24 <denkenz>  
Jan 19 21:13:25 <denkenz> -       if (vc->new_en_list == NULL)
Jan 19 21:13:25 <denkenz> -               return;
Jan 19 21:13:25 <denkenz> -
Jan 19 21:13:35 <denkenz> @@ -2147,7 +2144,7 @@ static void ecc_g3_read_cb(int ok, int total_length, int r
Jan 19 21:13:35 <denkenz>                 return;
Jan 19 21:13:35 <denkenz>  
Jan 19 21:13:35 <denkenz>  check:
Jan 19 21:13:36 <denkenz> -       if (vc->new_en_list == NULL)
Jan 19 21:13:36 <denkenz> +       if (!ok && vc->new_en_list == NULL)
Jan 19 21:24:36 <akiniemi> denkenz: I see, yes, that would seem to do the trick
Jan 19 21:30:00 <denkenz> akiniemi: So I pushed this patch, works on phonesim but please test it
Jan 19 21:34:33 <akiniemi> denkenz: sure
Jan 19 22:30:36 <padovan> denkenz: any word on that to help me debug? http://pastebin.com/npDCFG15
**** ENDING LOGGING AT Thu Jan 20 02:59:57 2011