Failing channel assignment

[Dieter Spaar]

Hello,

I noticed some issues in the following situation, I used the "testing"
branch (I think it affects both current "testing" branches):

  - the signalling channel is an SDCCH/8 on a timeslot different from
    TS0, for example on TS4

  - an ASSIGNMENT COMMAND switches to another channel on a different TS
    than the SDCCH/8, e.g. to TS2

Now the following two problems can happen:

  1.) The ASSIGNMENT COMMAND releases the SDCCH/8 with an L1CTL_DM_REL_REQ.
  Depending on when the L1CTL_DM_REL_REQ is received, it could be that
  there are still burst scheduled for transmit (e.g. for the SACCH). Due
  to the L1CTL_DM_REL_REQ, rfch_get_params() will return wrong data
  (l1s.dedicated.type is now set to GSM_DCHAN_NONE) and the transmit
  of the bursts happens on the wrong ARFCN and/or TS.

  My temporary workaround is to clear every item in the scheduler including
  the current bucket when a L1CTL_DM_REL_REQ is received, this action
  requires to disable the FIQ, otherwise problems might happen.


  2.) There is some code to check for a switch to a lower timeslot in
  check_lost_frame(). However it can happen that this code gets not
  triggered although it should: The ASSIGNMENT COMMAND causes a
  L1CTL_DM_REL_REQ, l1s.dedicated.type is now GSM_DCHAN_NONE ("0").
  The next call to check_lost_frame() resets "last_ts" to 0. Now the
  new channel is assigned (in the example from above its a switch
  from TS4 to TS 2) and a "LOST" occures, however the required
  increment of the GSM time does not happen because "last_ts" is 0
  although it should be 4.

  My current workaround is to not reset "last_ts" to 0 in check_lost_frame()
  but during "L1CTL_RESET_REQ: FULL!".

I don't post any patches because my changes are really just ugly workaround
which seem to work in (most) situations where it I otherwise observe failures.

To really solve this issues something else should be done, maybe put
the whole switch of a channel into an atomic operation instead of
doing several operations (this is just an idea, maybe there are
better solutions).

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de