Re: [Xenomai-core] About Xenomai test framework and publishing

2007-11-06 Thread Gilles Chanteperdrix
Gilles Chanteperdrix wrote:
  On 11/5/07, Gilles Chanteperdrix [EMAIL PROTECTED] wrote:
   On 11/5/07, Bruno Rouchouse [EMAIL PROTECTED] wrote:
Hi Gilles,
   
yes please, if you can send me your script, it would be great.
   
TIA.
  
   Here comes a tarball with the script (called bx/bin/bx2.sh) and an
   example configuration which you can untar in your home directory.
   Please be careful, do not mix the directories used by the script with
   other directories of yours since the script routinely removes the
   useless files (in order to avoid using too much space if you use it
   every night).
  
  I am trying to run this script, so a few words of advice:
  - the script parse the output of a few commands, so will not work
  properly if your linux is non-english. Add export LANG=C at the
  beginning of the script to avoid this issue;
  - you will need gpg properly installed and configured with kernel.org
  signature imported for the script to verify kernel.org archives
  signatures. Once gpg is configured, importing kernel.org signature is
  easy:
  gpg --keyserver wwwkeys.pgp.net --recv-keys 0x517D0F0E
  - the script will spend a lot of time downloading kernel archives and
  patches when you run it, do not worry, this will happen only once.

Ok. The script needed some changes to work anew.
New version here:
http://sisyphus.hd.free.fr/~gilles/bx.tar.bz2

The scripts result, when run with the example configuration can be found
here:
http://sisyphus.hd.free.fr/~gilles/bx

-- 


Gilles Chanteperdrix.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] About Xenomai test framework and publishing

2007-11-06 Thread Bruno Rouchouse
Hi Gilles,

I did manage to start the script and get everything downloaded but nothing
got compiled indeed.

I'll try again tonight with your updated version.

Thanks.

--Bruno

2007/11/6, Gilles Chanteperdrix [EMAIL PROTECTED]:

 Gilles Chanteperdrix wrote:
  On 11/5/07, Gilles Chanteperdrix [EMAIL PROTECTED] wrote:
   On 11/5/07, Bruno Rouchouse [EMAIL PROTECTED] wrote:
Hi Gilles,
   
yes please, if you can send me your script, it would be great.
   
TIA.
  
   Here comes a tarball with the script (called bx/bin/bx2.sh) and an
   example configuration which you can untar in your home directory.
   Please be careful, do not mix the directories used by the script with
   other directories of yours since the script routinely removes the
   useless files (in order to avoid using too much space if you use it
   every night).
 
  I am trying to run this script, so a few words of advice:
  - the script parse the output of a few commands, so will not work
  properly if your linux is non-english. Add export LANG=C at the
  beginning of the script to avoid this issue;
  - you will need gpg properly installed and configured with kernel.org
  signature imported for the script to verify kernel.org archives
  signatures. Once gpg is configured, importing kernel.org signature is
  easy:
  gpg --keyserver wwwkeys.pgp.net --recv-keys 0x517D0F0E
  - the script will spend a lot of time downloading kernel archives and
  patches when you run it, do not worry, this will happen only once.

 Ok. The script needed some changes to work anew.
 New version here:
 http://sisyphus.hd.free.fr/~gilles/bx.tar.bz2

 The scripts result, when run with the example configuration can be found
 here:
 http://sisyphus.hd.free.fr/~gilles/bx

 --


 Gilles Chanteperdrix.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] [Adeos-main] [PATCH] i386: switch to root domain on unhandled non-root faults

2007-11-06 Thread Jan Kiszka
Jan Kiszka wrote:
 Philippe Gerum wrote:
 Jan Kiszka wrote:
 Jan Kiszka wrote:
 This patch addresses the recently discovered issue that I-pipe actually
 need to deal with faults over non-root domain in which the current
 domain shows no interest in. Such faults could be triggered inside
 copy_*_user, thus can cleanly be handled by Linux - if we only allow for
 this. Currently, if debugging is on, we warn about a potential bug, and
 corrupt the pipeline states otherwise.

 The new approach is to unconditionally drop to root domain in such
 cases, but - for debugging purposes of non-fixable faults - keep track
 of the original domain and report it on oops.

 Similar patches are required for other archs. Maybe I can look into
 x86_64 later.

 Nak, this patch would not work as wanted. Again, what you need is to
 always fixup, and conditionally send a bug report to the kernel log if
 CONFIG_IPIPE_DEBUG is enabled, nothing more.

 This patch assumes that die() is always going to be fired for any
 in-kernel fault, so that all reports only need to go through this
 routine, which is wrong. Kernel fixups through exception tables may fix
 the fault early and silently, and this is particularly the case for
 copy_to_user helpers, which do include kernel fixup code.  By being
 silent when fixing up things in __ipipe_handle_exception() like your
 patch currently is, we would be left with no trace at all that some
 unhandled fault just happened, except by looking at /proc/xenomai/faults.
 
 As you are still remain vague on the actual problematic scenarios, I
 will try to go through them, and maybe you can add/correct what I miss:
 
  - faults in user land = can be silently handled by Linux after
dropping to root domain. This lowering is perfectly fine as the
higher domains showed no interest in the fault, thus are currently
running in domain-agnostic code paths anyway.
 
  - faults on fixable kernel addresses = same as above. If the high
domains fail to evaluate the fix-up result, it's not I-pipe's fault.
 
  - minor faults on kernel addresses (more precisely: in the I-pipe core
or some I-pipe user) = those would now went unnoticed and need
further thoughts, granted.
 +
  - major faults on kernel addresses = still generate major oopses and
will thus be visible.
 
 Did I missed something? If not, I would now start addressing the
 remaining problematic scenario directly instead of throwing all into the
 same pot.
 
 By sending the report immediately when fixing up in the latter routine,
 you also avoid the ugly ipipe_orig_domain stuff.
 
 It's not nice, but it is at least as ugly as reporting a kernel BUG when
 there is only a gracefully fixable bug in user code. I definitely do not
 agree with your approach as well, and I'm convinced we need to find a
 third way here.

OK, I think this should be acceptable for everyone. It's basically your
approach, reworked to avoid false positives. Moreover, it
unconditionally sets the root domain - should be faster.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
---
 arch/i386/kernel/ipipe.c |   38 ++
 1 file changed, 22 insertions(+), 16 deletions(-)

Index: linux-2.6.23-ipipe/arch/i386/kernel/ipipe.c
===
--- linux-2.6.23-ipipe.orig/arch/i386/kernel/ipipe.c
+++ linux-2.6.23-ipipe/arch/i386/kernel/ipipe.c
@@ -643,26 +643,32 @@ fastcall int __ipipe_handle_exception(st
 	}
 #endif /* CONFIG_KGDB */
 
-	if (!ipipe_trap_notify(vector, regs)) {
-#ifdef CONFIG_IPIPE_DEBUG
-		if (!ipipe_root_domain_p) {
-			/* Fix up domain so that Linux can handle this. */
-			ipipe_current_domain = ipipe_root_domain;
-			ipipe_trace_panic_freeze();
-			printk(KERN_ERR BUG: Unhandled exception over domain
-	 %s - switching to ROOT\n,
-	ipipe_current_domain-name);
-		}
-#endif /* CONFIG_IPIPE_DEBUG */
-		__ipipe_std_extable[vector](regs, error_code);
+	if (unlikely(ipipe_trap_notify(vector, regs))) {
 		local_irq_restore(flags);
-		__fixup_if(regs);
-		return 0;
+		return 1;
 	}
 
-	local_irq_restore(flags);
+#ifdef CONFIG_IPIPE_DEBUG
+	/* Warn about unhandled faults over non-root domains in kernel space
+	 * unless they occured at fixable locations. */
+	if (unlikely(!ipipe_root_domain_p)  !(error_code  4) 
+	!search_exception_tables(regs-eip)) {
+		struct ipipe_domain *ipd = ipipe_current_domain;
+		ipipe_current_domain = ipipe_root_domain;
+		ipipe_trace_panic_freeze();
+		printk(KERN_ERR BUG: Unhandled exception over domain
+ %s - switching to ROOT\n, ipd-name);
+		dump_stack();
+	}
+#endif /* CONFIG_IPIPE_DEBUG */
 
-	return 1;
+	/* Always switch to root so that Linux can handle it cleanly. */
+	ipipe_current_domain = ipipe_root_domain;
+
+	__ipipe_std_extable[vector](regs, error_code);
+	local_irq_restore(flags);
+	__fixup_if(regs);
+	return 0;
 }
 
 fastcall int __ipipe_divert_exception(struct pt_regs *regs, int 

Re: [Xenomai-core] About Xenomai test framework and publishing

2007-11-06 Thread Gilles Chanteperdrix
On Nov 6, 2007 1:22 PM, Bruno Rouchouse [EMAIL PROTECTED] wrote:
 Gilles,

 don't pay attention to my previous email, I managed to download the file.

 Thanks.

In case it matters I have done a chmod a+r


-- 
   Gilles Chanteperdrix

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core