All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: Jan Kiszka <jan.kiszka@domain.hid>, xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] [BUG] trunk: screwed Linux irq state
Date: Mon, 12 Feb 2007 14:46:37 +0100	[thread overview]
Message-ID: <1171287998.5001.4.camel@domain.hid> (raw)
In-Reply-To: <45D068C0.8090208@domain.hid>

On Mon, 2007-02-12 at 14:16 +0100, Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
> > Jan Kiszka wrote:
> > 
> >>2.6.19 didn't magically start to work as well. Instead I have a back
> >>trace now, see attachment.
> >>
> >>I included a full set of 16k points, but the thrilling things are around
> >>-73 to -25: Some Linux process with IRQs on gets preempted by an RT-IRQ
> >>(RTnet NIC). That triggers an RT kernel thread to run for a while (RTnet
> >>stack manager, prio 98). But when returning to Linux again, its IRQs
> >>remain masked now. The reason must be that weird exception at -62. Don't
> >>know where it comes from and why is there no report about THAT issue in
> >>the kernel logs.
> > 
> > 
> > The cause of this page fault will get tracked down later today, but the
> > way it is handled already causes some doubts to me. To make discussion
> > easier, here is the relevant excerpt from the trace:
> 
> Maybe this fault is due to the No-cow patch ? Before the no-cow patch,
> vmalloced areas were added to all processes page directories, now they
> are added only to the page directories of processes with the VM_PINNED
> flag. So, if ipipe_test_root tries to access some module memory area
> over the context of a non-realtime thread, a fault will occur.
> 

Yes, it's a minor fault occurring due to on-demand memory mapping, this
is why we don't get any alarming message in the kernel log.

-- 
Philippe.




  reply	other threads:[~2007-02-12 13:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-11 22:13 [Xenomai-core] [BUG] trunk: screwed Linux irq state Jan Kiszka
2007-02-11 22:26 ` Gilles Chanteperdrix
2007-02-11 22:31 ` Gilles Chanteperdrix
2007-02-11 22:42 ` Philippe Gerum
2007-02-11 23:07   ` Gilles Chanteperdrix
2007-02-11 23:49     ` Philippe Gerum
2007-02-12  0:20       ` Gilles Chanteperdrix
2007-02-12  0:28         ` Jan Kiszka
2007-02-12  1:10           ` Jan Kiszka
2007-02-12 11:49             ` Jan Kiszka
2007-02-12 13:16               ` Gilles Chanteperdrix
2007-02-12 13:46                 ` Philippe Gerum [this message]
2007-02-12 13:49                   ` Jan Kiszka
2007-02-12 14:10                     ` Philippe Gerum
2007-02-12 14:39                       ` Gilles Chanteperdrix
2007-02-12 15:10                         ` Philippe Gerum
2007-02-12 19:02                           ` Gilles Chanteperdrix

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=1171287998.5001.4.camel@domain.hid \
    --to=rpm@xenomai.org \
    --cc=gilles.chanteperdrix@xenomai.org \
    --cc=jan.kiszka@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.