Re: [Iaxclient-devel] sched_priority

[Jean-Denis G. <jd....@sy...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I've done some more testing, and I think I have a complete explanation.

On the system where my patch is needed, the user I run as belongs to
group audio, and /etc/security/limits.conf shows:
	@audio          -       rtprio           50
When iaxclient is initialized iaxci_prioboostbegin sets priority to 49
(sched_get_priority_min returns 0, sched_get_priority_max 99) without
error. Then StartWatchDog is called, which in turn calls WatchDogProc.
It tries to set priority to 53, which fails because of security limit.
If I change the rtprio limit to 60 for group audio, then setting
priority to 53 works fine.

On the other system, user does not belong to group audio, so it cannot
set real-time priority, StartWatchDog and WatchDogProc are never called,
then iaxclient works fine.

I think my patch does address a real problem, at least for Mandriva
users (and probably others), which won't be able to use iaxclient based
applications out of the box.


Andrea Suisani wrote:
| Hi Jean-Denis
|
| [cut]
|
|> No, it's failing in a more subtle way: when placing a call, it seems
|> that IAX events are not received correctly. For example, here is the
|> trace from my application (MozPhone, see http://moziax.mozdev.org/) when
|> a call is successfully placed (with my patched iaxclient-2.1beta3):
|> - ------------
|> iaxc_initialize OK, 2 lines
|> WatchDogProc: cannot set watch dog priority 53 !
|> WatchDogProc: cannot set watch dog priority 52 !
|> WatchDogProc: cannot set watch dog priority 51 !
|
| anyhow there's something that makes priority switching
| somekind problmeatic, am I right? you've to decrease
| priority 3 times before getting it set.
|
|
|> Looking for Plantronics cs60usb...
|
| [cut]
|
|> warning: The VAD has been replaced by a hack pending a complete rewrite
| [cut]
|> warning: The VAD has been replaced by a hack pending a complete rewrite
|
| why you need to load speex codec library twice?
|
|> As you can see IAX events are received as expected, call is successful.
|> Now here is what I get with original iaxclient-2.1beta3:
|> - ---------------------
|> iaxc_initialize OK, 2 lines
|
| [cut]
|
|> As you can see, IAX state event accepted is never received.
|
| I see :/
|
| [cut]
|
|> Both systems where 2.6.25.x kernels, but one is 64bits-smp (base distro
|> is Mandriva-2008.1-64), the other is 32 bits (Mandriva cooker-32).
|
| Which one fails without the patch?
|
| Are those plain vanilla kernel (fetched from kernel org) or are they
| provided by rmps
| (yum)?
|
| I'm not very familiar with Mandriva's world, though it seems to me that
| coocker is the dev branch, isn't it? so maybe it could be something
| in the cooker toolchain that makes things a little bit "unstable".
|
|
|>>> I already reported same problem long ago, but maybe I'm the only one
|>>> affected by this...
|>>>
http://sourceforge.net/mailarchive/message.php?msg_id=4366C3DF.2010308%40sysnux.pf

|>>>
|>>>
|>> reading through this thread I've just noted you said
|>> that also portaudio/pa_unix_oss/pa_unix.c has to be changed.
|>> is this editing still needed?
|>
|> No, it is no longer needed.
|>
|> I know priorities permissions can be modified on Linux according to
|> limits.conf, but I think this is a real problem for Linux users, that my
|> proposed patch can solve.
|>
|> I just downloaded / tested binary iaxcomm-1.2.0: it fails to run as
|> normal user because it cannot set the watchdog priority, and runs fine
|> as root.
|
| Any chance to test this on a different machine with a different
| linux flavours? (cause I've never experienced such a bug both on
| Debian (etch/4.0)and Ubuntu (>=7.04))
|
| Andrea
|


Thanks,
- --
Jean-Denis Girard

SysNux                  Systèmes  Linux  en Polynésie française
http://www.sysnux.pf/   Tél: +689 50 10 40 / GSM: +689 79 75 27
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iEYEARECAAYFAkhpRUMACgkQuu7Rv+oOo/jeEwCffKtr8xZaJFNtgtJ/vV/818C+
kRAAniWMEVArlypABsnVAd3oTSmlvWmo
=kv6Q
-----END PGP SIGNATURE-----