From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8C2B76.9020405@domain.hid> Date: Mon, 01 Mar 2010 22:02:46 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> <4B8C25B9.8090705@domain.hid> <4B8C26F7.3020306@domain.hid> <4B8C2797.2000501@domain.hid> <4B8C29E1.7070404@domain.hid> <4B8C2B08.8080907@domain.hid> In-Reply-To: <4B8C2B08.8080907@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig79CCC2D4D3EF47F5199C59FA" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: "xenomai@xenomai.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig79CCC2D4D3EF47F5199C59FA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gilles Chanteperdrix wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Jan Kiszka wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Jan Kiszka wrote: >>>>>> Charlton, John wrote: >>>>>>> I added some printk output to the cond.c file in xenomai-2.5.1 an= d it shows that xnsync_sleep_on returned -ETIMEDOUT as it should: >>>>>>> Xenomai: registered exported object M1-1908 (mutexes) >>>>>>> Xenomai: registered exported object C1-1908 (condvars) >>>>>>> xnsynch_sleep_on returned: -110 >>>>>>> xnsynch_sleep_on returned: -110 >>>>>>> xnsynch_sleep_on returned: -110 >>>>>>> xnsynch_sleep_on returned: -110 >>>>>>> xnsynch_sleep_on returned: -110 >>>>>>> xnsynch_sleep_on returned: -110 >>>>>>> xnsynch_sleep_on returned: -4 >>>>>>> Xenomai: native: cleaning up cond "C1-1908" (ret=3D0). >>>>>>> Xenomai: unregistered exported object C1-1908 (condvars) >>>>>>> Xenomai: native: cleaning up mutex "M1-1908" (ret=3D0). >>>>>>> Xenomai: unregistered exported object M1-1908 (mutexes) >>>>>>> Xenomai: POSIX: destroyed thread df5a0800 >>>>>>> >>>>>>> I put the printk on line cond.c:433 after err is set in rt_cond_w= ait_prologue(): >>>>>>> >>>>>>> info =3D xnsynch_sleep_on(&cond->synch_base, >>>>>>> timeout, timeout_mode); >>>>>>> if (info & XNRMID) >>>>>>> err =3D -EIDRM; /* Condvar deleted while pending. */ >>>>>>> else if (info & XNTIMEO) { >>>>>>> err =3D -ETIMEDOUT; /* Timeout. */ >>>>>>> } >>>>>>> else if (info & XNBREAK) { >>>>>>> err =3D -EINTR; /* Unblocked. */ >>>>>>> } >>>>>>> printk(KERN_DEBUG "xnsynch_sleep_on returned: %d\n", err)= ; >>>>>>> >>>>>>> I put a printk in rt_cond_wait_inner() which is called directly b= y rt_cond_wait() from user mode but did not see the output in the dmesg o= utput for that one. >>>>>> One of our problems is the prologue/epilogue split up (both in ker= nel >>>>>> and user space): the epilogue can eat the error code or the prolog= ue, >>>>>> including the -ETIMEDOUT. >>>>> Ah. My fault. Looks user-space is Ok though. Only kernel-space has = a >>>>> problem. >>>>> >>>> Both are affected. >>>> >>>> Could you help me with what issues >>>> 97323b3287b5ee8cad99a7fa67cd050bc51f76c4 should fix? >>> Ah, restart after RT-signals! So far we blocked on the concluding >>> rt_mutex_lock without breaking out to user space, now we have to loop= >>> over -EINTR to allow signals, right? >> Yes, it is needed even for handling linux signals (getting gdb working= =20 >> for instance). However, since we do not want rt_cond_wait to result in= to >> two syscalls all the time, we handle everything in the first syscall i= f=20 >> possible. >> >> Try this: >> >> diff --git a/ksrc/skins/native/syscall.c b/ksrc/skins/native/syscall.c= >> index 40e5cfd..d4e885c 100644 >> --- a/ksrc/skins/native/syscall.c >> +++ b/ksrc/skins/native/syscall.c >> @@ -1869,9 +1869,12 @@ static int __rt_cond_wait_prologue(struct pt_re= gs *regs) >> >> err =3D rt_cond_wait_prologue(cond, mutex, &lockcnt, timeout_m= ode, timeout); >> >> - if (err =3D=3D 0 || err =3D=3D -ETIMEDOUT) >> - err =3D rt_cond_wait_epilogue(mutex, lockcnt); >> - >> + if (err =3D=3D 0 || err =3D=3D -ETIMEDOUT) { >> + int loc_err =3D rt_cond_wait_epilogue(mutex, lockcnt);= >> + if (loc_err < 0) >> + err =3D loc_err; >> + } >> + >> if (err =3D=3D -EINTR && __xn_reg_arg3(regs) >> && __xn_safe_copy_to_user((void __user *)__xn_reg_arg3(reg= s), >> &lockcnt, sizeof(lockcnt))) >=20 > No. That is not ok either. We need to store the first status somewhere > for returning it to user-space after looping several times in the > epilogue function. Precisely (also in user space). Jan --------------enig79CCC2D4D3EF47F5199C59FA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuMK3YACgkQitSsb3rl5xRxyQCfYselVvaiSJJH4XluLHF0zliZ shQAoOKZoilmcbu8Oznwpl/JvQvRIXMY =OkHY -----END PGP SIGNATURE----- --------------enig79CCC2D4D3EF47F5199C59FA--