**** BEGIN LOGGING AT Mon Apr 18 02:59:57 2011
Apr 18 10:51:02 <Rishi_> hey all
Apr 18 10:52:10 <Rishi_> can anybody tell me the files getting cached by ofono
Apr 18 10:52:14 <Rishi_> from sim 
Apr 18 13:07:19 <BertrandAygon> Jeevaka: ping
Apr 18 13:19:38 <BertrandAygon> Hi, I am looking at bug 15124, which is a crash when putting a modem online/offline often and rapidly. I could have reproduce it, and have one idea, but need the background and experience of some oFono engineer
Apr 18 13:20:07 <BertrandAygon> According to log, the modem get online, offline and online again, in a very short period of time
Apr 18 13:21:05 <BertrandAygon> During the first online, zte_post_online probe some atoms (I am interrested in the USSD one), which will put some AT command in the gatchat queue
Apr 18 13:21:18 <BertrandAygon> Then, when going offline, all atoms are flushed
Apr 18 13:21:47 <BertrandAygon> But atoms are flushed before the CUSD command for the USSD probe has been handled
Apr 18 13:22:14 <BertrandAygon> And so, when the CUSD command is handled, there is a crash, which seems to be due to the fact that atoms has been flushed.
Apr 18 13:22:23 <BertrandAygon> Is my assumption correct/possible or not?
Apr 18 14:43:18 <denkenz> BertrandAygon: gdb will tell you for sure, however, all commands associated with the atom are canceled when it goes away
Apr 18 14:46:53 <BertrandAygon> gdb tell me that the crash is  in at_ussd_register (ok=1, result=0xbffff048, user=0x813a620) at drivers/atmodem/ussd.c:301
Apr 18 14:47:41 <BertrandAygon> do you want me to send you the log and call stack?
Apr 18 14:48:31 <denkenz> Anyway, I've fixed it 
Apr 18 14:48:43 <BertrandAygon> I am reproducing this bug easily, so you can also try
Apr 18 14:48:47 <BertrandAygon> oh really, cool
Apr 18 14:48:53 <BertrandAygon> where was the problem?
Apr 18 14:48:59 <denkenz> -       g_at_chat_send(chat, "AT+CSCS?", cscs_prefix, read_charset_cb, data,
Apr 18 14:48:59 <denkenz> -                       NULL);
Apr 18 14:49:00 <denkenz> +       g_at_chat_send(data->chat, "AT+CSCS?", cscs_prefix,
Apr 18 14:49:00 <denkenz> +                       read_charset_cb, data, NULL);
Apr 18 14:49:00 <denkenz>  
Apr 18 14:49:00 <denkenz> -       g_at_chat_send(chat, "AT+CUSD=1", NULL, at_ussd_register, ussd, NULL);
Apr 18 14:49:01 <denkenz> +       g_at_chat_send(data->chat, "AT+CUSD=1", NULL,
Apr 18 14:49:01 <denkenz> +                       at_ussd_register, ussd, NULL);
Apr 18 14:49:18 <denkenz> Basically ussd is using a non-cloned chat, so the first two commands don't get cleaned up properly
Apr 18 14:49:45 <denkenz> I checked other probe functions in drivers/atmodem and they look alright to me
Apr 18 14:50:09 <BertrandAygon> Perfect.
Apr 18 14:50:25 <BertrandAygon> So I was not so far... 
Apr 18 14:50:58 <denkenz> yep, like all good bugs this one was subtle
Apr 18 14:51:00 <BertrandAygon> One more point, when doing the same test, I also got sometimes a crash in gprs
Apr 18 14:51:29 <denkenz> which modem driver?
Apr 18 14:51:33 <Rishi_> anyBody has some info on sim file caching ???
Apr 18 14:51:39 <BertrandAygon> but I will say 90% I got the USSD crash, so I will wait for fix to track the gprs one
Apr 18 14:51:49 <BertrandAygon> I am using a ZTE
Apr 18 14:53:26 <denkenz> Do you get this crash in zte_disconnect?
Apr 18 14:53:44 <BertrandAygon> arg, I do not save the traces, but I don't think so
Apr 18 14:54:31 <denkenz> Likely the zte needs to be modeled after the huawei for handling online / offline transitions
Apr 18 14:55:50 <denkenz> Rishi_: sim file caching is a fairly complicated topic, lets just say that we cache files that are non-modifiable by the user
Apr 18 14:56:15 <denkenz> The cache is generic and not limited to any particular set
Apr 18 14:56:54 <denkenz> However, oFono only uses a small subset of EFs defined in 31.102/51.011
Apr 18 14:56:59 <Rishi_> so is there any code snippet for the same. I cud see ef_db in simutil.c 
Apr 18 14:57:13 <Rishi_> what is that for ??
Apr 18 14:58:44 <denkenz> code snippet for what?
Apr 18 14:59:08 <denkenz> and ef_db is something you need 3 beers to understand
Apr 18 14:59:19 <denkenz> and 5 to explain
Apr 18 15:00:43 <Rishi_> :)\
Apr 18 15:00:46 <Rishi_> :P
Apr 18 15:01:48 <denkenz> If you really want to know curl up with 102.221 and 11.14
Apr 18 15:02:17 <denkenz> However, the cache is done completely automatically by oFono, using ofono_sim_read is all you need to care about
Apr 18 15:02:44 <Rishi_> hey i know about the hex values written over there :)
Apr 18 15:03:13 <Rishi_> but i wanted to have some list of what files are being cached so that i may introduce some more on need basis
Apr 18 15:03:59 <denkenz> the process is simple, if your file is not covered by ef_db, you just add it there with permissions taken from 31.102
Apr 18 15:04:16 <denkenz> simfs.c takes care of the rest
Apr 18 15:04:40 <Rishi_> so the files are cached in STORAGEDIR, is it ??
Apr 18 15:05:01 <denkenz> yes, which is /var/lib/ofono by default
Apr 18 15:05:57 <Rishi_> there are two functions actually ofono_sim_read  and sim_fs_read_info. They both push sim operation task on queue
Apr 18 15:06:03 <Rishi_> am i  correct?
Apr 18 15:06:53 <denkenz> so where's my beer? ;)
Apr 18 15:07:00 <Rishi_> ;)
Apr 18 15:07:35 <Rishi_> thanks for the explanation :) But i cud not find the implementation for the same. SO I was wondering 
Apr 18 15:07:46 <denkenz> ofono_sim_read is the public API
Apr 18 15:07:57 <denkenz> that is what the other atoms should be using
Apr 18 15:08:31 <denkenz> ofono_sim_read basically uses the sim_fs functions to do its magic
Apr 18 15:08:32 <Rishi_> so the atoms won't come to know whether information is coming from cache or it is a sim read ?
Apr 18 15:08:41 <denkenz> nope
Apr 18 15:09:28 <Rishi_> there is also a sim_ef_db_lookup function for that matter
Apr 18 15:10:35 <denkenz> That is just black magic
Apr 18 15:10:54 <Rishi_> Magic Overdose
Apr 18 15:11:23 <Rishi_> am I missing anything else i shud know wrt sim caching
Apr 18 15:11:25 <Rishi_> ????
Apr 18 15:11:42 <denkenz> Actually you shouldn't even know about sim caching ;)
Apr 18 15:11:49 <denkenz> As a client you really don't care
Apr 18 15:12:12 <Rishi_> no but i care if i need to change some core functionalities
Apr 18 15:12:53 <Rishi_> but i guess the details have been abstracted out by simfs
Apr 18 15:13:53 <denkenz> Lets just say that efdb is a bit of a hack to get around hardware limitations
Apr 18 15:14:17 <Rishi_> ya so i see. There are some comments for the same
Apr 18 15:14:20 <denkenz> 3G UICC get response does not contain all of the EF's permission information
Apr 18 15:14:33 <denkenz> And hw does not allow us to read the relevant EFs
Apr 18 15:14:49 <denkenz> So we used a more creative approach
Apr 18 15:14:50 <Rishi_> So if i add more ef file information to ef_db, i am sure it will be cached !?
Apr 18 15:16:04 <denkenz> someone still has to read the file, and the EF permissions must not allow modification by the user
Apr 18 15:16:50 <Rishi_> ya exactly. NO thats what i was wondering, where does this db come into picture in the Core code
Apr 18 15:17:58 <denkenz> ofono_sim_read -> sim_fs_read -> driver_read_info -> driver_read_info_callback -> if 3g, efdb lookup -> sim_fs_read_callback
Apr 18 15:18:53 <denkenz> efdb is more of a utility
Apr 18 15:19:02 <Rishi_> ok 
Apr 18 15:20:45 <Rishi_> now i kind of get it 
Apr 18 15:21:08 <Rishi_> Thanks Denis
Apr 18 15:21:22 <Rishi_> It was a pleasure talking to you
Apr 18 15:21:35 <denkenz> sure, anytime
Apr 18 15:21:52 <Rishi_> i have mailed the same question on the list also
Apr 18 15:22:37 <Rishi_> no but i was more interested in the oFono -Core
Apr 18 15:23:08 <Rishi_> i will bother u again if needed
Apr 18 15:23:12 <Rishi_> thanks a lot
Apr 18 15:23:13 <Rishi_> :)
Apr 18 15:28:25 <BertrandAygon> denkenz: I have try with your fix, and this is working fine. I could not have reproduce the cash in gprs, so maybe the callstack was corrupted...
Apr 18 15:29:21 <denkenz> There is still probably a problem
Apr 18 15:29:28 <denkenz> But you need to have an active context
Apr 18 15:30:23 <BertrandAygon> ok, I will try...
Apr 18 15:34:09 <denkenz> Seems 13679 and 14784 are the same bug
Apr 18 15:36:02 <denkenz> And so is 15124
**** ENDING LOGGING AT Tue Apr 19 02:59:57 2011