Il 16/02/2009 00:40, Corey Hickey ha scritto:
> Ok, here's the problem.
>
> modem_main.c:976 function modem_main()
> ----------------------------------------------------------------------
> if (need_realtime) {
> struct sched_param prm;
> if(mlockall(MCL_CURRENT|MCL_FUTURE)) {
> ERR("mlockall: %s\n",strerror(errno));
> }
> ----------------------------------------------------------------------
>
> That chunk of code runs when slmodemd starts up; the modem_start() code
> I mentioned in my last email runs when the modem is dialed. So, the
> mlockall(MCL_FUTURE) is allowing only a very limited allocation of
> memory after the setuid().
>
> [...]
>
> Removing the MCL_FUTURE flag makes slmodemd work for me, as far as I can
> tell. Remember that I don't have a phone line to test here. It gets past
> the modem_start() code, at least, and behaves just like my binary that
> has the privilege-dropping patch removed.
>
> I don't know if that's an acceptable solution; locking all allocated
> memory into RAM seems useful. Then again, I wouldn't really expect a
> currently-running slmodemd process to get swapped out unless memory
> constraints are extreme. I don't know the original rationale.
>
> -Corey
Corey, thank you for digging this out.
I think we're facing the same problems jackd users do.
Maybe we can solve this issue with pam_limits: Corey, could you please
try to add this line to /etc/security/limits.conf
Slmodemd hard memlock 256000
and see if this solves the issue even with the MCL_FUTURE flag set?
Thanks
Maurizio
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
