**** BEGIN LOGGING AT Mon Jan 24 02:59:58 2011 **** BEGIN LOGGING AT Mon Jan 24 11:22:50 2011 Jan 24 11:46:42 hi everybody! A question from noob - I have a noname integrated modem based on qualcomm msm6290 chipset, connected to usb. Which driver is suitable for me? Jan 24 12:11:02 slava_: try zte? Jan 24 12:29:57 Hi, I haven't received comments about patch "[PATCH] sim: check if lock is locked after code input attempt" which I sent Monday 17th. Has it been missed since that's the first I sent with different authorship info or did my mail system ruined the content still? Jan 24 12:40:21 pessi, thank you very much! It worked! Jan 24 13:04:48 holtmann, denkenz, padovan: Hi guys, I am currently working on AT emulator for DUN and I wondered if Jan 24 13:04:48 1) there should be one emulator associated to multiple modems? Then the dun gateway would be connected to this one that would behave as one modem only. Jan 24 13:04:48 2) or there should be one emulator associated to each modem. Then there would be multiple bluetooth server registered but in this case how the dun gateway should select the emulator? Jan 24 13:04:55 denkenz: pessi : hello, if we have a new type for long phone numbers (80 max) we would need a new struct for that long number?. I see, for example, that __ofono_voicecall_dial() does a strncpy(req->ph.number, addr, 20);. That number member of the current ofono_phone_number struct is a char [OFONO_MAX_PHONE_NUMBER_LENGTH + 1]. Jan 24 13:11:40 denkenz: pessi : I would like to know your suggestions Jan 24 14:40:41 Gzajac: My current take on this one is that we have one DUN server. And it will map to the first modem we have. Jan 24 14:41:16 In theory we can start a DUN server for each modem, but why bother. Sounds like a bit too much for really limited use. Jan 24 14:58:42 holtmann: I see, thanks. Jan 24 15:01:27 Gzajac: I really all depends in the end how simple it is btw. BlueZ can certainly easily handle having more than one DUN server running. Jan 24 15:01:50 If you see this in an end product, I don't think so. Maybe it is useful for testing purposes. Jan 24 15:13:59 ok Jan 24 15:25:19 holtmann: In the case we have 2 modems on a netbook, Jan 24 15:26:09 holtmann: and we have to select one, maybe the emulator should contain the list of modems. Jan 24 15:26:36 Gzajac: Don't overthink this right now. The best solution will come once you start implementing the details. Jan 24 15:27:37 holtmann: i'm facing strange issues with URCs Jan 24 15:27:45 Jeevaka: Which hardware? Jan 24 15:27:56 ifx Jan 24 15:28:05 Is this still our GIOChannel stuff? Jan 24 15:28:10 Or is this IFX firmware? Jan 24 15:28:26 most probably GIOChannel stuff Jan 24 15:28:45 So what is the exact problem. Jan 24 15:29:03 I can see in the logs "Aux: < \r\n+SATI: ......" but it never reaches the callback registered callback function Jan 24 15:29:31 I noticied similar issue with signal strength notifications Jan 24 15:30:51 So what do you see with -d '*stk*' Jan 24 15:32:06 Also we need some context around it. Jan 24 15:33:38 currently, test is done with the orange card, UK Jan 24 15:36:19 Jeevaka: But any further command just works fin the Aux: channel? Jan 24 15:36:39 Are you sure the firmware is behaving properly. Jan 24 15:36:54 Either all URC should break or none. Jan 24 15:37:23 not sure. i'll check the other commands as well Jan 24 15:38:29 check the parser, maybe the modem says something weird on the aux channel Jan 24 15:38:48 ok Jan 24 15:51:49 Jeevaka: We are still running the v1 strict syntax for IFX. The last remaining one since STE failed as well ;) Jan 24 15:59:48 biggest issue is its not happening always Jan 24 16:01:14 That is weird. You might need to add some extra debug code into gatchat and gatio to track this down. Jan 24 16:12:52 at what point can I set the modem online? Jan 24 16:13:07 I tried to wait for SIM Present, but that fails with busy error Jan 24 16:14:45 courmisch: When you get the SubscribeIdentiy. Check auto-enable.c test script. Jan 24 16:15:17 And you might need to check the Lock Required. Jan 24 16:15:59 SIM Present just means there is a SIM card. It does not tell you about its state or its locks. Jan 24 16:16:16 and how do I know that it fails? Jan 24 16:16:49 What fails? Jan 24 16:17:21 if I wait for a signal, I need to know that I should still be waiting Jan 24 16:17:27 I can't just deadlock if the signal never comes Jan 24 16:18:28 Yes, you can. Jan 24 16:18:34 There is nothing much you can do. Jan 24 16:18:59 If the SIM is locked you need user interaction to unlock it. And you have to sit and wait until someone unlocks it. Jan 24 16:20:39 something needs to change there. Emergency calls won't work Jan 24 16:21:22 That is still under discussion on how we handle that best. Jan 24 16:31:52 zrafa: perhaps you can change this structure to allow up to 80 chars, but just have different validating functions Jan 24 16:33:22 zrafa: It is easier to validate the 80 character limit for outgoing calls Jan 24 16:33:32 zrafa: And keep the limit the same for the rest Jan 24 16:33:32 denkenz: i'll look into the simfs ops cancellation, sorry was away sinze Fri Jan 24 16:33:51 balrog-k1n: No prob, no hurry since it has been a problem since August or so ;) Jan 24 16:34:18 i also need to finish refresh, but it's scary :) Jan 24 16:35:01 Yeah, I noticed ;) Jan 24 16:39:30 denkenz: yes, I read that. But going further.. the number, after validation (for outgoing calls) is strcopied to an ofono_phone_number thing.. and it has a "number" member 20 digits max. Does not it matter? Jan 24 16:39:58 zrafa: It does, and you should extend it to 80 characters like andrew said Jan 24 16:50:15 balrog-k1n: denkenz: okey. But then, let me try to follow all the changes, because the comments look like my RFC patches, or I am not following you completely :( .. My patches changes OFONO_MAX_PHONE_NUMBER_LENGTH to 80, .. so that struct has the number is a char [OFONO_MAX_PHONE_NUMBER_LENGTH + 1], and also the patches added a new validator for max length 20. The idea would be to modify OFONO_MAX_PHONE_NUMBER_LENGTH yet right?.. (using the previous 20 characte Jan 24 16:50:49 has the number is = has a number member which is Jan 24 16:51:13 modify OFONO_MAX_PHONE_NUMBER_LENGTH = modify OFONO_MAX_PHONE_NUMBER_LENGTH to 80 Jan 24 16:51:40 extending OFONO_MAX_PHONE_NUMBER_LENGTH is fine Jan 24 16:51:59 However, the easiest thing to do would be to change valid_phone_number to making sure that it is 20 characters Jan 24 16:52:12 and then specialize the one for outgoing calls to accept up to 80 Jan 24 16:52:48 denkenz: okey, good Jan 24 22:18:51 http://pastebin.com/8yf07CzF Jan 24 22:19:19 systembus has disconnected. the log is from calypso on a freerunner Jan 24 22:19:57 any hints? or what i can logging more in detail? Jan 24 22:20:21 wasn't a fix pushed for this one already? Jan 24 22:20:39 commit 19b9ffdb44ac71197ac1ac7c4502ee13194cd78f Jan 24 22:21:19 jep, i have read this. but i have running HEAD on my freerunner Jan 24 22:21:51 I would assume you do not run HEAD. Jan 24 22:21:55 I did fix this. Jan 24 22:22:20 moment Jan 24 22:22:41 Otherwise follow the same steps on the mailing list thread and track down the D-Bus statement that creates an invalid message. Jan 24 22:23:19 root@gta02:~/ofono# git log Jan 24 22:23:19 commit 2999252d15ebd4c8a3fcdd8c37fca780c60fab22 Jan 24 22:23:19 Author: Marcel Holtmann Jan 24 22:23:20 Date: Sun Jan 23 10:17:31 2011 +0100 Jan 24 22:24:11 That is fine, but did you actually compile and install it on the target device. Jan 24 22:24:23 Oh yeah, DUN server is working now. :) Jan 24 22:24:32 padovan: Sweet. Jan 24 22:25:07 jep, i have compile it just in time Jan 24 22:25:34 I need to work in the ConnMan part now, but first I have to organize the code here in commits. ;) Jan 24 22:35:22 holtmann: i get this disconnect only with incomming calls Jan 24 22:38:46 As I said, track down the D-Bus function that creates the invalid message. Jan 24 22:39:10 fgau: can you run ofonod -n -d "*voicecall*" and tell what you see Jan 24 22:39:26 Your previous pastebin is definitely not running HEAD though Jan 24 22:42:07 demarchi: You might have to initialize cnap/cnap_validity and called number type in calypsomodem properly Jan 24 22:42:40 However, the current driver should not cause crashes Jan 24 22:43:20 I did a memset for the ofono_call that should have fixed this. Jan 24 22:45:13 denkenz: Crap. cnap_valditiy needs to be 2. Jan 24 22:45:25 = not available. Jan 24 22:46:12 But this should still not cause a crash. The name[] string is then just empty. Jan 24 22:47:09 demarchi: And we should start using the enum constants here and not the hardcoded values for clip. Jan 24 22:47:56 demarchi: That is a nice cleanup task. Use the proper constants for CLIP validity. At least atmodem needs also fixing. Jan 24 22:48:19 And the history examples. Jan 24 22:48:51 constant is not the problem, the fact that the structure was not initialized properly is Jan 24 22:49:26 That is just a cleanup. Using 0 and 2 all over the place is confusing ;) Jan 24 22:49:37 Not really Jan 24 22:54:55 holtmann: denkenz : sorry, you are right. i have started ofono from my deb package. with HEAD all is fine. sry! Jan 24 22:55:46 hah Jan 24 22:56:52 where could I check the max length for voicecall deflect? should be it 80 digits max as outgoing calls? or just let it 20 characters limit Jan 24 23:05:12 zrafa: Try poking 24.008 for deflect Jan 24 23:06:40 If not, then just use 20 characters for now and post a question on the ML, maybe someone knows Jan 24 23:07:49 denkenz: okey. for 24.008: I did,.. but no luck. Let me check again, if no, then I will ask on the ML Jan 25 02:32:03 denkenz: was my highlight correct? Jan 25 02:32:42 denkenz: cnap/cnap_validity in calypsomodem ?! Jan 25 02:32:50 denkenz: i'm a bit confused Jan 25 02:33:57 i'll give it a look tomorrow, but i'm not sure why i'm the one you talked too Jan 25 02:34:04 s/too/to/ Jan 25 02:50:49 demarchi: All voicecall drivers need to be updated to handle cnap properly Jan 25 02:56:58 denkenz: humn... padovan did the cnap property Jan 25 02:57:07 but i can look at it, np Jan 25 02:57:21 i finished the cleanup of the sms storage Jan 25 02:57:29 and porting it to the new api Jan 25 02:57:49 demarchi: Ah, well the line id is also the culprit Jan 25 02:58:16 tomorrow when i'm at work I'll send the patches and then i start to look at this Jan 25 02:58:24 sur Jan 25 02:58:24 e Jan 25 02:58:29 denkenz: are you experiencing crashes? Jan 25 02:59:16 denkenz: but it should be ok if a driver does not implement that method **** ENDING LOGGING AT Tue Jan 25 02:59:57 2011