All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Sebastian Smolorz <Sebastian.Smolorz@domain.hid>
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] Strange behaviour of RTDM CAN driver
Date: Tue, 16 May 2006 15:11:09 +0200	[thread overview]
Message-ID: <4469CF6D.2000005@domain.hid> (raw)
In-Reply-To: <200605161240.33036.Sebastian.Smolorz@domain.hid>

Sebastian Smolorz wrote:
> Hello all,
> 
> the following is a really nasty problem I am trying to solve for months now. I 
> really hope that someone on the list knows the solution.
> 
> As you may remember some months ago I announced a RTDM CAN driver for SJA1000 
> based cards (see 
> https://mail.gna.org/public/xenomai-core/2005-11/msg00108.html). The driver 
> works well with the cards at our institute. Some time ago I was asked to 
> extend the driver so that it would work also with a card from another vendor 
> (Advantech PCM3680). By now, the driver does its job as expected, with one 
> exception: It gets stuck in the interrupt handler. The problem is that the 
> interrupt register of the SJA1000 chip does not get cleared after a read 
> command like it should. So the driver never knows that there is no interrupt 
> anymore and therefore never leaves the interrupt handler.
> 
> After I installed a break after 20 loops inside the handler and an additional 
> read of the interrupt register in the following syscall routine issued by the 
> test program, I noticed that the register is cleared! So I strongly think 
> that the reason for clearing this register lies in actions taken after the 
> driver left the interrupt handler. But I am not very sure about this. Maybe 
> there is another reason I do not see (or in the end the hardware is 
> faulty ...).
> 
> Did any of you experienced a similar problem in the past? Any hint would be 
> appreciated!
> 
> Interestingly, the driver does not show the above behaviour with all interrupt 
> numbers. E.g. with interrupt number 12 the driver gets no interrupt at all.
> 
> Some technical details:
> - Linux Kernel 2.6.16
> - adeos-ipipe-2.6.16-i386-1.3-01.patch
> - Xenomai 2.1.50
> 
> 

It would be interesting to know how Adeos is asked to deal with such 
interrupt upon receipt, e.g. does it relay it to Linux? What do the 
following say? And also, which is the number of your interrupt in the 
dumps below?

$ cat /proc/ipipe/Xenomai
$ cat /proc/ipipe/Linux
$ cat /proc/xenomai/irq

-- 

Philippe.


  parent reply	other threads:[~2006-05-16 13:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-16 10:40 [Xenomai-core] Strange behaviour of RTDM CAN driver Sebastian Smolorz
     [not found] ` <16854688.1147779550976.JavaMail.ngmail@domain.hid>
2006-05-16 12:30   ` Sebastian Smolorz
2006-05-24 10:23     ` Sebastian Smolorz
2006-05-16 13:11 ` Philippe Gerum [this message]
2006-05-16 13:57   ` Sebastian Smolorz
2006-05-24 10:51   ` Sebastian Smolorz

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=4469CF6D.2000005@domain.hid \
    --to=rpm@xenomai.org \
    --cc=Sebastian.Smolorz@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.