This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi all
On Mon, Jun 29, 2009 at 02:57:16PM +0200, Holger Hans Peter Freyther wrote:
> On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
> > patch 40: in case of a channel breakdown, the signal handler for
> > releasing lchan is called. the wrong pointer was used as lchan. (see
> > last hunk) also we don't need to check use counter of lchan, if we
> > receive an "cause 22 error". the lchan gets released anyway, if use
> > counter becomes 0. (see first hunk). also i think we can force channel
> > release when we receive an error indication. this can easily be tested:
> > remove the battery during active call, then send a message to the mobile
> > station (hang up on the remote). the message cannot be delivered, so the
> > BTS send us an error indication, the channels and the call process gets
> > released.
>
>
> Okay. As stupid as it might sound please split that into three patches.
>
> 1.) Fixing my stupidity in gsm0408_handle_lchan_signal!!! sorry for making you
> suffer from it and thanks for fixing it.
I've applied this as a single commit now.
> 2.) static int rsl_rx_rll_err_ind(struct msgb *msg)
I've modified it to check for the cause, i.e. only release the channel
in case T200 is expired. I'm not sure if we need to give up that quickly on
other types of error indications.
> 3.) Explain why
>
> +// if (msg->lchan->use_count > 0) {
> +// }
>
> is a good change and should be applied?
done, too.
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)