Re: mobile - making a call

Hello everyone. After some more digging turns out that removing the "Status 1: 90 00"  from the firrmware the SIM response gets back to the upper layers. What I've also noticed is that when the SIM response wasn't getting to the mobile application a L1CTL_RESET was following. My question is : would this L1CTL_RESET have the effect of removing pending packets from the queue? Cause that would sort of explain why the delay introduced by the debug printing would influence the overall behaviour. Thanks, Mihai. --- On Sun, 5/15/11, eisencah eisenach <wbg_1000(a)yahoo.com> wrote: From: eisencah eisenach <wbg_1000(a)yahoo.com> Subject: Re: Fw: Re: mobile - making a call To: baseband-devel(a)lists.osmocom.org Date: Sunday, May 15, 2011, 5:52 PM Hi again. So after some digging I'm quite sure the ADPU response doesn't make it back into the upper layers. My question is , case the osmocon output contains some weird characters (see bellow), I should assume that at that point something went wrong with the serial link? Also is there some flag to compile the firmware such that the prints have no effect, as to offload the serial link? Thanks, Mihai. L1CTL_DATA_REQ (link_id=0x00) ul=00811fe0, ul->payload=00811fe4, data_ind=00811fe4, data_ind->data=00811fe4 l3h=00811fe4 SIM Request (7): a0 a4 00 00 02 6f 20 Status 2: 9F 0F SIM Request (5): a0 c0 00 00 0f Status 1: 90 00 SIM Request (14): a0 d6 00 00 09 ff 49 fd 1a 49 8f 70 00 01 Status 2: 90��Q��L1CTL_PARAM_REQ (ta=1, tx_power=6) L1CTL_DATA_REQ (link_id=0x00) ul=00811fe0, ul->payload=00811fe4, data_ind=00811fe4, data_ind->data=00811fe4 l3h=00811fe4 L1CTL_DATA_REQ (link_id=0x00) ul=008123c4, ul->payload=008123c8, data_ind=008123c8, data_ind->data=008123c8 l3h=008123c8 --- On Sat, 5/7/11, Sylvain Munaut <246tnt(a)gmail.com> wrote: From: Sylvain Munaut <246tnt(a)gmail.com> Subject: Re: Fw: Re: mobile - making a call To: "eisencah eisenach" <wbg_1000(a)yahoo.com> Cc: baseband-devel(a)lists.osmocom.org Date: Saturday, May 7, 2011, 11:07 AM No not really ... But there is a good reason the SIM driver is not in master ... it sucks at several level, including blocking behavior in interrupt context IIRC, so it's totally plausible your machine speed triggers some weird things. My advice would be to: - Cleanup the SIM driver - Bypass it in the code and try to access a real PCSC device locally rather than the built in SIM reader. Both are non-trivial of course. Cheers,     Sylvain