From: Jan Kiszka <jan.kiszka@domain.hid>
To: Stephan Zimmermann <s.zimmermann@domain.hid>
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] Re: [BUG] trunk: oops with Stephan's stress test
Date: Wed, 28 Feb 2007 15:45:08 +0100 [thread overview]
Message-ID: <45E59574.50808@domain.hid> (raw)
In-Reply-To: <45E58FB4.6070603@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 1824 bytes --]
Jan Kiszka wrote:
> Stephan Zimmermann wrote:
>> Jan Kiszka schrieb:
>>> Philippe Gerum wrote:
>>>> On Fri, 2007-02-23 at 14:34 +0100, Jan Kiszka wrote:
>>>>
>>>>> Attached with 3000 points (to play safe).
>>>> Great, thanks.
>>>>
>>> FYI: Switching prio-coupling off doesn't let it trigger anymore. Which
>>> /may/ mean that it's related to this feature, but which may also mean
>>> that this corner-case race is just far more unlikely in non-RPI setups
>>> (and the effects Stephan see are all related to the same bug -
>>> hopefully).
>>>
>>> Jan
>>>
>> To trigger you again, I just updated my Pentium M Notebook to 2.3.x svn
>> revision 2264, recompiled everything and gave it a try. (kernel 2.6.20)
>> Some runs of my already well-known software and the machine freezes
>> during shutdown. No oops, no backtrace, no error message. It doesn't
>> matter if priority coupling is enabled or not, when it tells me
>> 'Stopping K Display Manager: kdm' the cursor freezes, that's it. My
>> colleague report's the same beahviour on his AMD SMP mashine. The
>> Celeron M crashes during reboot showing ugly backtraces like before.
^^^^
_Re_boot - now I read your message correctly. So you are not facing
elementary boot issues on some boxes, but always memory corruption
*after* running your demo code, right?
Then we should try to find out what mechanism of Xenomai might cause the
corruption. Could you, step by step, simplify your test, e.g. leaving
out some of the tasks or not using the message queues? This would help
to focus the analysis on (hopefully) only a few facilities.
Still, the compiler question remains relevant. 2.6.20 e.g. warns me that
gcc 4.1.0 may miscompile the kernel (but I'm using a SUSE-patched
version that so far behaves).
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
next prev parent reply other threads:[~2007-02-28 14:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-23 12:32 [Xenomai-core] [BUG] trunk: oops with Stephan's stress test Jan Kiszka
2007-02-23 12:53 ` [Xenomai-core] " Jan Kiszka
2007-02-23 13:30 ` Philippe Gerum
2007-02-23 13:34 ` Jan Kiszka
2007-02-23 13:48 ` Philippe Gerum
2007-02-23 13:53 ` Jan Kiszka
2007-02-23 14:04 ` Jan Kiszka
2007-02-28 14:08 ` Stephan Zimmermann
2007-02-28 14:20 ` Jan Kiszka
2007-02-28 14:45 ` Jan Kiszka [this message]
2007-02-28 15:04 ` Stephan Zimmermann
2007-02-28 15:09 ` Stephan Zimmermann
2007-02-28 15:10 ` Jan Kiszka
2007-02-28 15:55 ` Stephan Zimmermann
2007-02-28 16:00 ` Jan Kiszka
2007-03-05 12:44 ` Stephan Zimmermann
2007-03-31 20:47 ` Philippe Gerum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45E59574.50808@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=s.zimmermann@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.