From: Jan Kiszka <jan.kiszka@siemens.com>
To: Jeff Webb <jeff.webb@nta-inc.net>
Cc: "Mauerer, Wolfgang" <wolfgang.mauerer@siemens.com>,
Xenomai <xenomai@xenomai.org>
Subject: Re: [Xenomai] [PATCH v2] nucleus: Convert intrlock to a sleeping Linux lock
Date: Thu, 03 Jan 2013 11:46:05 +0100 [thread overview]
Message-ID: <50E5616D.8060303@siemens.com> (raw)
In-Reply-To: <50E497AD.9000404@nta-inc.net>
On 2013-01-02 21:25, Jeff Webb wrote:
> On 01/02/2013 12:07 PM, Jan Kiszka wrote:
>> Conceptually, all users of this lock are supposed to run over Linux
>> context already. Moreover, latest I-pipe patches complain that
>> ipipe_virtualize_irq is called with the Xenomai domain stalled which
>> invalidates that useful internal bug check.
>>
>> So rework the locking for dumping scheduling statistics and convert
>> intrlock to a sleeping Linux variant to avoid the alarm. And to simplify
>> some code paths.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>
> This patch seems to solve the original problem, but I get the following output in the kernel log, when I do a 'cat /proc/xenomai/stat'.
>
> -Jeff
>
> kernel: [ 106.030870] ------------[ cut here ]------------
> kernel: [ 106.030878] WARNING: at kernel/xenomai/nucleus/intr.c:903 xnintr_query_next+0x189/0x1a0()
> kernel: [ 106.030880] Hardware name: Precision WorkStation T3400
> kernel: [ 106.030882] Modules linked in: bnep rfcomm bluetooth binfmt_misc dm_crypt snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq usbhid snd_timer snd_seq_device psmouse mac_hid snd hid coretemp dcdbas x38_edac ppdev soundcore snd_page_alloc serio_raw edac_core parport_pc microcode lp parport reiserfs nouveau tg3 ttm drm_kms_helper drm i2c_algo_bit mxm_wmi video wmi
> kernel: [ 106.030932] Pid: 3106, comm: cat Not tainted 3.4.6-xenomai-2.6.2 #1
> kernel: [ 106.030934] Call Trace:
> kernel: [ 106.030941] [<ffffffff8103cc0f>] warn_slowpath_common+0x7f/0xc0
> kernel: [ 106.030944] [<ffffffff8103cc6a>] warn_slowpath_null+0x1a/0x20
> kernel: [ 106.030947] [<ffffffff811060b9>] xnintr_query_next+0x189/0x1a0
> kernel: [ 106.030951] [<ffffffff81119003>] vfile_stat_next+0x163/0x200
> kernel: [ 106.030955] [<ffffffff8113063b>] vfile_snapshot_open+0x21b/0x2e0
> kernel: [ 106.030960] [<ffffffff81263cc3>] proc_reg_open+0xa3/0x180
> kernel: [ 106.030963] [<ffffffff81130160>] ? vfile_regular_release+0x50/0x50
> kernel: [ 106.030967] [<ffffffff81263c20>] ? proc_alloc_inode+0xb0/0xb0
> kernel: [ 106.030972] [<ffffffff81201ace>] __dentry_open+0x24e/0x310
> kernel: [ 106.030975] [<ffffffff81202f51>] nameidata_to_filp+0x71/0x80
> kernel: [ 106.030979] [<ffffffff81212afc>] do_last+0x26c/0x920
> kernel: [ 106.030983] [<ffffffff812132c3>] path_openat+0xd3/0x3c0
> kernel: [ 106.030986] [<ffffffff812136d2>] do_filp_open+0x42/0xa0
> kernel: [ 106.030990] [<ffffffff8121fb8f>] ? alloc_fd+0x4f/0x130
> kernel: [ 106.030993] [<ffffffff81203058>] do_sys_open+0xf8/0x1d0
> kernel: [ 106.030997] [<ffffffff813a5c4a>] ? __ipipe_syscall_root_thunk+0x35/0x67
> kernel: [ 106.031001] [<ffffffff81203151>] sys_open+0x21/0x30
> kernel: [ 106.031005] [<ffffffff816c61e6>] system_call_fastpath+0x16/0x1b
> kernel: [ 106.031007] ---[ end trace 5ed7b1604d797a3f ]---
>
>
Yes, that's the XNARCH_TIMER_IRQ bug I was referring to.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2013-01-03 10:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-02 18:07 [Xenomai] [PATCH v2] nucleus: Convert intrlock to a sleeping Linux lock Jan Kiszka
2013-01-02 20:25 ` Jeff Webb
2013-01-03 10:46 ` Jan Kiszka [this message]
2013-01-03 14:09 ` [Xenomai] [PATCH v3] " Jan Kiszka
2013-01-06 10:14 ` Philippe Gerum
2013-01-06 10:55 ` Jan Kiszka
2013-01-06 11:03 ` Jan Kiszka
2013-01-06 13:55 ` Gilles Chanteperdrix
2013-01-06 14:20 ` Jan Kiszka
2013-01-06 14:26 ` Gilles Chanteperdrix
2013-01-06 14:35 ` Gilles Chanteperdrix
2013-01-06 14:46 ` Jan Kiszka
2013-01-06 15:09 ` Gilles Chanteperdrix
2013-01-06 15:11 ` Jan Kiszka
2013-01-06 15:15 ` Gilles Chanteperdrix
2013-01-06 15:19 ` Jan Kiszka
2013-01-06 15:26 ` Gilles Chanteperdrix
2013-01-06 15:31 ` Jan Kiszka
-- strict thread matches above, loose matches on Subject: below --
2012-10-17 11:19 [Xenomai] [PATCH] " Jan Kiszka
2012-10-18 17:40 ` [Xenomai] [PATCH v2] " Jan Kiszka
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=50E5616D.8060303@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=jeff.webb@nta-inc.net \
--cc=wolfgang.mauerer@siemens.com \
--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.