From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4D702802.5080001@domain.hid> Date: Fri, 04 Mar 2011 00:45:06 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <20110302151603.GA14557@domain.hid> <4D6E61B6.906@domain.hid> <4D6E8A06.9060508@domain.hid> <20110303072147.GA4353@domain.hid> <1299137548.2072.3.camel@domain.hid> <4D6F88D6.4010105@domain.hid> <4D6F89C8.9060005@domain.hid> <1299156880.2072.6.camel@domain.hid> In-Reply-To: <1299156880.2072.6.camel@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF6FAA57986A8D36F9A650F8B" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] Stuck MSI in normal Linux driver List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philippe Gerum Cc: "xenomai@xenomai.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF6FAA57986A8D36F9A650F8B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-03-03 13:54, Philippe Gerum wrote: > On Thu, 2011-03-03 at 13:30 +0100, Jan Kiszka wrote: >> On 2011-03-03 13:25, Wolfgang Grandegger wrote: >>> Hi Philippe, >>> >>> On 03/03/2011 08:32 AM, Philippe Gerum wrote: >>>> On Thu, 2011-03-03 at 08:21 +0100, Richard Cochran wrote: >>>>> On Wed, Mar 02, 2011 at 07:18:46PM +0100, Jan Kiszka wrote: >>>>>> On 2011-03-02 16:26, Gilles Chanteperdrix wrote: >>>>>>> Richard Cochran wrote: >>>>>>>> The wiki pages=20 >>>>>>>> >>>>>>>> http://www.xenomai.org/index.php/FAQs >>>>>>>> http://www.xenomai.org/index.php/Configuring_x86_kernels >>>>>>>> >>>>>>>> say not to enable MSI on x86, with a link to a very old (2008) >>>>>>>> discussion. >>>>> >>>>> ... >>>>> >>>>>> The current situation looks like this: >>>>>> - MSI[-X] usage for plain Linux drivers is fine, we are using it = on >>>>>> machines where you can hardly avoid MSI today >>>>>> - MSI[-X] usage for RTDM (ie. RT) drivers is basically fine as lo= ng as >>>>>> you avoid enabling/disabling from RT context (also used for qui= te >>>>>> a while here, no known issues under this restriction) >>>>> >>>>> Okay, so I understand from this: >>>>> >>>>> 1. The wiki warning is out of date. >>>>> >>>>> 2. My own PCIe MSI driver/card *should* work. >>>>> (It is not a current known limitation of adeos/xenomai.) >>>> >>>> The situation is not that clear. Enabling CONFIG_PCI_MSI on some 83x= x >>>> board did cause a lock up at boot for me, so this may point the fing= er >>>> at the pipeline core for ppc, and not to Xenomai which was barely ac= tive >>>> at that stage. >>> >>> Now I remember vaguely that we have seen a similar issue on the mpc83= 08 >>> in autumn last year. Here is what you wrote that time: >>> >>> On 09/29/2010 04:12 PM, Philippe Gerum wrote: >>>> Ok, I have a good news: the issue is spotted; and a bad one: this is= no >>>> trivial stuff to fix. In short, CONFIG_PCI_MSI causes the PIC code t= o >>>> read PCI config memory on the fly during operations (which is intens= ely >>>> insane but that is how it goes). Of course, it does that via the reg= ular >>>> PCI helpers, which are stuffed with normal locking constructs we may= >>>> _not_ call from any real-time/non-regular context. >>>> >>>> To sum up, we need to call those helpers to ack/mask interrupts with= in >>>> the I-pipe, but we are not allowed to do this because this is inhere= ntly >>>> unsafe. >>>> >>>> Work-around: disable CONFIG_PCI_MSI in your configuration. >>>> The real fix would require much more thought, to make the PCI helper= s >>>> Adeos-aware without inducing high latency. >> >> As MSIs are edge-triggered, only requiring ack at the interrupt >> controller level, could it be that PPC is using the wrong flow handler= here? >=20 > The pipeline forces mask/ack to prevent adverse effect of deferred > delivery to downstream handlers. Some chips require this. You mean PPC irqchips? I'm a bit confused as MSIs are immediately acked by the hardware on the bus, independently of the processor delivering or deferring the event. What prevents immediate termination (up to EOI if required) of this IRQ type on PPC? Jan --------------enigF6FAA57986A8D36F9A650F8B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1wKAcACgkQitSsb3rl5xTzugCgru+XGtI87rQQvkGsYUvsF+C3 zywAnjnlZ4Ui467F8g0bgahCYQx6Rapt =DMDY -----END PGP SIGNATURE----- --------------enigF6FAA57986A8D36F9A650F8B--