On 2013-02-25 12:11, Jan Kiszka wrote:
On 2013-02-25 11:18, Anders Blomdell wrote:
On 2013-02-15 16:26, Jan Kiszka wrote:
On 2013-02-15 16:15, Anders Blomdell wrote:
Hi,
I have a that dies with "kernel BUG at
arch/x86/kernel/ipipe.c:589!" when running Xenomai. This is not very
surprising since when running the system with an ordinary kernel thera
are a few 'do_IRQ: X.Y No irq handler for vector (irq -1)' each day.
Question is if it would be possible to do something less fatal than
'BUG_ON(irq < 0);' in the code below:
This remains a bug that has to be understood.
int __ipipe_handle_irq(struct pt_regs *regs)
{
struct ipipe_percpu_data *p = __ipipe_this_cpu_ptr(&ipipe_percpu);
int irq, vector = regs->orig_ax, flags = 0;
struct pt_regs *tick_regs;
if (likely(vector < 0)) {
irq = __this_cpu_read(vector_irq[~vector]);
BUG_ON(irq < 0);
} else { /* Software-generated. */
irq = vector;
flags = IPIPE_IRQF_NOACK;
}
Kernel 3.5.7 with latest I-pipe?
Yes.
This is the second report of this kind,
see [1] for the discussion and suggestions. If you don't have KGDB and
that kind enabled, try Gilles' instrumentations.
After a running xenomai five and a half day on a DX58SO motherboard, the
system crashed, leaving a single 'do_IRQ: 2.166 No irq handler for
vector (irq -1)' on our logserver.
I'm planning to put in Gilles instrumentations and change the BUG_ON to
a WARN_ON/WARN, but what should I return after that (my guess is a
'return 1', but waiting a week to be proved wrong would be a waste of
time :-).
Err, what was the test setup that generated the Linux error but not the
I-pipe BUG_ON? Was it a Xenomai-enabled kernel with the BUG_ON removed?
Strangely enough, a Xenomai-enabled kernel with BUG_ON still in place,
so yes it's a mystery how the do_IRQ gets triggered. No realtime tasks
active at all though!
After the do_IRQ on the logserver, the system is mostly unresponsive
(i.e no way to get the screen to light up, the ssh-daemon immediately
terminates login sessions). Since the BUG_ON on the DX79SI motherboard
seemed to kill the filesystem, my immediate thought is that it's what
happened here as well (loosely based on the fact that the message did
not reach the local /var/log/messages).
Another thing I could test is to run a stock 3.5.7 kernel and see if the
do_IRQ message appears there as well (3.6.11 has not shown any signs of
do_IRQ messages).
/Anders
--
Anders Blomdell Email: [email protected]
Department of Automatic Control
Lund University Phone: +46 46 222 4625
P.O. Box 118 Fax: +46 46 138118
SE-221 00 Lund, Sweden
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai