**** BEGIN LOGGING AT Tue May 25 02:59:57 2010
May 25 04:54:50 <padovan> denkenz: what about my patches to oFono, any comments?
May 25 07:25:47 <padovan> holtmann: take a look on patches 1 to 3 from my last patch series on oFono mailing list, there is a gdbus change there and the same change to the -d option I did for BlueZ.
May 25 07:34:16 <holtmann> Why this is_registered() thing?
May 25 07:36:02 <padovan> holtmann: see patch 2/9. In hfp we need that to avoid call the Disconnect method if the interface is not there anymore.
May 25 07:36:22 <padovan> we did a hack to fix this for the release 0.18
May 25 07:36:53 <padovan> my patch intends to replace this: 766a0bcfa50069dbdfe7ddae7018e963e73f95ec
May 25 07:38:37 <holtmann> I don't consider this a hack.
May 25 07:38:59 <holtmann> Adding the is_registered is a hack for me since you just lost track of what you have done on D-Bus.
May 25 07:41:54 <padovan> Ok, so let the code as is.
May 25 07:43:03 <padovan> holtmann: and patch 3/9 adds the OPTIONAL_FLAG to -d option. 
May 25 07:43:16 <holtmann> That is fine with me.
May 25 07:44:03 <padovan> Ok, nice.
May 25 08:01:16 <akiniemi> There's a unit test that keeps failing:
May 25 08:01:16 <akiniemi> /testsms/Test SMS Assembly Serialize: **
May 25 08:01:18 <akiniemi> ERROR:unit/test-sms.c:1118:test_serialize_assembly: assertion failed: (l != NULL)
May 25 08:10:32 <holtmann> akiniemi: You might have to wait until Denis wakes up.
May 25 11:23:25 <kvalo> ofonod: double free or corruption (out): 0x00000000006df1e0 ***
May 25 11:23:51 <kvalo> from gdb:
May 25 11:23:57 <kvalo> #7  0x00007ffff7bd58a6 in udev_device_unref () from /lib/libudev.so.0
May 25 11:23:57 <kvalo> #8  0x000000000040fc5e in udev_event (channel=0x6da660, condition=G_IO_IN,  user_data=0x6d9140) at plugins/udev.c:466
May 25 11:24:00 <kvalo> #9  0x00007ffff79328c2 in g_main_dispatch (context=0x6d2000) at /build/buildd/glib2.0-2.24.0/glib/gmain.c:1960
May 25 11:24:20 <kvalo> I was plugging and unplugging my huawei modem
May 25 11:26:28 <kvalo> I had some patches of my own, though
May 25 12:07:04 <holtmann> kvalo: Possible, but I haven't seen that yet.
May 25 12:07:28 <holtmann> Sure that this is udev_device_unref? Can we get the full backtrace.
May 25 12:07:50 <holtmann> denkenz: So I am going for the next release soon. What pending patches do you have?
May 25 12:08:38 <kvalo> holtmann: I'll send the full backtrace to the list
May 25 12:09:01 <holtmann> Please also include anything that might have shown up with OFONO_AT_DEBUG=1.
May 25 12:11:43 <kvalo> holtmann: I was able to reproduce it three times already
May 25 12:12:21 <kvalo> but first lunch :)
May 25 12:47:34 <holtmann> kvalo: Do you see my responses on the mailing list. For some reason, I don't see my own emails :(
May 25 12:49:01 <denkenz> akiniemi: Hmm, test-sms works for me
May 25 12:50:04 <denkenz> holtmann: Go ahead with the release, I can wait to push for a little bit, still need to cleanup the pending patches
May 25 12:50:37 <holtmann> denkenz: I will see about Kalle's patches. Seems he got most of the Huawei stuff working. Please have a second look at them.
May 25 12:50:41 <denkenz> Might want to review kvalo's gprs patches though
May 25 12:50:51 <holtmann> I did. Just my emails don't make it to the list today.
May 25 12:51:39 <denkenz> heh, any highlights?
May 25 12:54:53 <holtmann> We will see. We might get Huawei working.
May 25 12:57:27 <denkenz> kvalo: how about treating SIMST properly, as a sim inserted condition
May 25 12:57:38 <denkenz> kvalo: You don't actually need to hack around with the powered state
May 25 12:57:57 <kvalo> holtmann: nope, I don't see any mail from you
May 25 12:58:27 <denkenz> Also, whats the point of using SYSINFO and SIMST?
May 25 12:59:05 <kvalo> denkenz: I haven't looked at sim insertion code at all.
May 25 12:59:37 <kvalo> denkenz: I'm using SYSINFO in case SIMST comes fast and we miss it
May 25 12:59:50 <denkenz> kvalo: Ok, so SYSINFO is used for query, fair enough
May 25 13:00:05 <kvalo> I should have added a comment for that
May 25 13:00:06 <denkenz> kvalo: sim insertion is easy, just remove ofono_sim_inserted from pre_sim
May 25 13:00:27 <denkenz> kvalo: and notify ofono_sim_inserted when SIMST/SYSINFO tell you sim is ready
May 25 13:00:30 <kvalo> heh, too easy ;)
May 25 13:03:45 <denkenz> kvalo: btw, for numbers you don't care about, feel free to use skip_next
May 25 13:04:01 <kvalo> denkenz: cool
May 25 13:04:41 <denkenz> +       g_at_chat_send(data->chat, "AT^SYSINFO", NULL, sysinfo_cb, modem, NULL);
May 25 13:04:50 <denkenz> Always send a prefix for AT commands
May 25 13:05:13 <denkenz> The huawei plugin abuses this a bit
May 25 13:05:58 <denkenz> +       /* follow sim state */
May 25 13:05:59 <denkenz> +       g_at_chat_register(data->event, "^SIMST:", huawei_simst_notify,
May 25 13:06:01 <denkenz> +                       FALSE, modem, NULL);
May 25 13:06:10 <denkenz> Do the registration only after powered has been set to true
May 25 13:06:36 <kvalo> denkenz: I guess I don't need to check the sim state in huawei plugin at all? sim.c handles that, right?
May 25 13:07:00 <denkenz> it should
May 25 13:07:16 <denkenz> its fine to check it for race condition between SIMST and SYSINFO
May 25 13:07:17 <kvalo> at least ofono_sim_inserted_notify() does
May 25 13:07:26 <denkenz> both ways should work
May 25 13:07:46 <kvalo> I'll leave the sim_state to huawei pluging
May 25 13:07:50 <kvalo> plugin
May 25 13:08:02 <denkenz> Btw, in theory SIMST can notify us of SIM removed too
May 25 13:08:36 <kvalo> I was actually to do that also
May 25 13:08:50 <kvalo> so if SIMST is zero, call sim_notify(false)
May 25 13:09:55 <denkenz> yep
May 25 13:10:22 <denkenz> you can also do it this way:
May 25 13:10:38 <denkenz> cfun=1 -> sysinfo? -> register for SIMST
May 25 13:11:14 <kvalo> but isn't there a race then?
May 25 13:11:33 <denkenz> why?
May 25 13:11:55 <denkenz> Unless the firmware sends us the SIMST during SYSINFO execution
May 25 13:12:05 <kvalo> what prevents that?
May 25 13:12:31 <denkenz> In general unsolicited notifications should not be sent during command execution
May 25 13:12:43 <denkenz> Some modems fuck this up (like the Freerunner)
May 25 13:12:55 <kvalo> I was just about to ask can we trust that :)
May 25 13:12:56 <denkenz> leave it as is if you're worried
May 25 13:13:09 <kvalo> ok
May 25 13:32:09 <kvalo> denkenz: I did the sim inserted and a problem is that voicecall commands are executed too early:
May 25 13:32:13 <kvalo> May 25 16:30:08 tukki ofonod[12092]: > AT+CRC=1\r
May 25 13:32:17 <kvalo> May 25 16:30:08 tukki ofonod[12092]: < \r\n+CME ERROR: SIM busy\r\n
May 25 13:32:57 <kvalo> or did I do something wrong, I have to check
May 25 13:34:52 <kvalo> no mistake
May 25 13:35:22 <kvalo> should I move ofono_voicecall_create() to post_sim()?
May 25 13:37:37 <kvalo> yeah, that's one way to do it
May 25 13:37:48 <kvalo> denkenz: but is that ok?
May 25 13:39:38 <pessi> kvalo: you cannot possibly receive calls if sim is not ready
May 25 13:40:18 <pessi> add watch for sim state and say +crc=1 in post sim?
May 25 13:43:13 <kvalo> pessi: true
May 25 13:43:32 <kvalo> pessi: I'll look at that option also. I just don't have any hardware to test voicecalls
May 25 13:44:29 <kvalo> all plugings call ofono_voicecall_create() from pre_sim. hmm
May 25 13:46:41 <pessi> so you can make emergency call
May 25 13:47:04 <kvalo> ah
May 25 13:47:24 <kvalo> I really do not want to touch atmodem/voicecall.c :)
May 25 13:49:08 <kvalo> blah, I just ignore the errors for now. with my modem it's not possible to make calls anyway. 
May 25 13:59:12 <denkenz> We should really remove voicecalls from datacard modems
May 25 13:59:23 <denkenz> its pointless
May 25 14:02:17 <denkenz> Only the em770 can in theory do voicecalls, so feel free to remove it from huawei plugin
May 25 14:03:53 <kvalo> denkenz: ok, I'll send a patch
May 25 14:13:18 <denkenz> kvalo:
May 25 14:13:20 <denkenz> +       } else if (gcd->state == STATE_DISABLING) {
May 25 14:13:21 <denkenz> +               cbd = cb_data_new(gcd->down_cb, gcd->cb_data);
May 25 14:13:25 <denkenz> Err, how about using ppp_shutdown?
May 25 14:13:27 <kvalo> holtmann: can you resend your comments?
May 25 14:13:41 <denkenz> CGACT is useless there
May 25 14:14:05 <denkenz> actually, that entire if else makes no sense
May 25 14:14:09 <kvalo> denkenz: I don't have the patch in front of me, but shouldn't that be in ppp_disconnect()?
May 25 14:14:39 <denkenz> you get a ppp disconnect when the context is down
May 25 14:14:58 <kvalo> true
May 25 14:15:07 <denkenz> so sending CGACT (to deactivate the context) is useless ;)
May 25 14:15:14 <kvalo> sure is :)
May 25 14:16:36 <denkenz> Rest seems fine
May 25 14:16:47 <kvalo> cool
May 25 14:17:19 <denkenz> And you probably don't need the timeout patch
May 25 14:17:20 <kvalo> now I need to fix connman to work without gateway and then I can finally (hopefully?) use my 3G from UI :)
May 25 14:17:38 <kvalo> denkenz: otherwise connman is in some weird state
May 25 14:17:40 <denkenz> since you won't be sending the CGACT
May 25 14:17:48 <kvalo> ah
May 25 14:17:53 <kvalo> yeah, very good point
May 25 14:18:45 <denkenz> The hup is a separate thing that we need to fix
May 25 14:19:03 <denkenz> For now your hardware can be activated once and deactivated, then you need to reboot the modem ;)
May 25 14:19:06 <kvalo> oh yeah. I really want that one fixed :)
May 25 14:19:15 <kvalo> yeah, that's not a problem
May 25 14:19:22 <kvalo> as long as ofono doesn't crash :)
May 25 14:19:41 <denkenz> nod
May 25 14:21:03 <denkenz> pessi: About the opaqueness for EFiccid, the spec only mentions this for 1st G sims
May 25 14:21:11 <denkenz> pessi: Is this still the case for 2G+?
May 25 14:37:59 <denkenz> holtmann: For Daniele's patch, I imagine we'd need the proper automake magic too
May 25 14:38:22 <denkenz> holtmann: Or is dbus-glib part of glib?
May 25 14:49:10 <holtmann> denkenz: We are not including dbus-glib. Ever.
May 25 14:49:33 <holtmann> That is the GObject based crack.
May 25 14:50:05 <denkenz> holtmann: Ok, feel free to reply then, this is for a .c example
May 25 14:50:12 <holtmann> Using libdbus plain and simple from command line tools is easy enough.
May 25 14:50:39 <holtmann> Since my emails don't make it to the mailing list today, I have to wait.
May 25 14:51:52 <kvalo> holtmann: I hope you get it fixed
May 25 14:52:15 <kvalo> weird, very seldom I see this after ppp shutdown:
May 25 14:52:16 <holtmann> They are just queued up somewhere. For sure they left my mailserver.
May 25 14:52:19 <kvalo> ofonod[12701]: < \r\nNO CARRIER\r\n
May 25 14:52:36 <holtmann> Embedded in the HDLC framing ;)
May 25 14:53:09 <kvalo> heh :)
May 25 14:53:28 <denkenz> probably a race between the firmware sending the NO CARRIER and performing a hup
May 25 14:53:49 <kvalo> denkenz: yeah, now I can manage without the ugly timeout patch
May 25 14:54:40 <pessi> denkenz: there are Phase 2+ sims with nonstandard ICCIDs
May 25 14:58:21 <kvalo> denkenz: sorry, misspelt your name!
May 25 14:59:30 <denkenz> pessi: Ok fair enough, I will look again a bit later
May 25 14:59:38 <denkenz> pessi: Can you resubmit the others based on Aki's comments?
May 25 14:59:58 <denkenz> kvalo: no worries
May 25 21:14:55 <pessi> denkenz: ...sent
May 25 21:54:04 <denkenz> pessi, akiniemi: Can we get rid of the (Nokia-D/Helsinki) from Pekka's patches?
May 25 21:58:10 <pessi> denkenz: mine?
May 25 21:58:41 <denkenz> pessi: Yeah, I see Pessi Pekka (Nokia-D/Helsinki) <Pekka.Pessi@nokia.com>
May 25 21:58:47 <denkenz> On the patches Aki just pushed
May 25 21:59:06 <denkenz> So that author info is completely screwed up
May 25 21:59:08 <ljp>  
May 25 21:59:30 <denkenz> Before I saw: Pekka Pessi <Pekka.Pessi@nokia.com>
May 25 21:59:32 <denkenz> Which is fine
May 25 21:59:43 <ljp> annoying how nokia exchange server does that...
May 25 22:00:21 <pessi> Exchange screws the from line
May 25 22:01:02 <denkenz> Well, it used to work, so can you guys go back to that? :)
May 25 22:01:32 <denkenz> All your other patches the author field is fine, only the last 4 are screwed up
May 25 22:06:28 <pessi> nice that it seem to use hungarian notation, too
May 25 22:06:48 <denkenz> exactly, it should be first last name always in the author field
May 26 01:10:02 <zhenhua> padovan: your patches seem having some style problems. can u use checkpatch.pl to verify them?
May 26 01:10:43 <padovan> zhenhua: sure.
May 26 01:10:59 <padovan> I'll check.
May 26 01:12:19 <zhenhua> padovan: thanks. because i want to rebase my patches on top of yours. :-)
May 26 01:46:30 <yang_office> denkenz: Unfortunately, the data in ber-tlv of send sms 1.4.1 is in format of octet, instead of septet. Thus our parse_dataobj_gsm_sms_tpdu() couldn't handle it correctly. 
May 26 02:14:51 <denkenz> yang_office: You're saying DCS gave 8-bit coding but UDL was set to 160?
May 26 02:16:49 <denkenz> yang_office: If so, that's a bug in the test
May 26 02:19:46 <denkenz> most likely they confused 8-bit with 7 bit coding
May 26 02:55:47 <yang_office> denkenz: According to the ber-tlv, TP-DCS is 0xF4, which means it's coded in 8-bit data, and class 0. TP-UDL is 0xA0 (160), and followed by 160 bytes. In all ways, the TP-UD (not TP-UDL) can't be more than 140 bytes, as I think. 
May 26 02:56:40 <yang_office> I will comment these in the test. 
May 26 02:59:08 <zhenhua> denkenz: what's the purpose for PPP server side extension? this part is not clear to me
**** ENDING LOGGING AT Wed May 26 02:59:57 2010