From mboxrd@z Thu Jan 1 00:00:00 1970 From: Philippe Gerum In-Reply-To: <4CC5F612.8040508@domain.hid> References: <4CC20AD2.4060501@domain.hid> <4CC44C02.4050003@domain.hid> <4CC5603E.1090707@domain.hid> <4CC566A2.2000702@domain.hid> <4CC5C93E.70503@domain.hid> <4CC5DD1F.4090405@domain.hid> <1288041712.26618.189.camel@domain.hid> <4CC5F612.8040508@domain.hid> Content-Type: text/plain; charset="UTF-8" Date: Mon, 25 Oct 2010 23:43:14 +0200 Message-ID: <1288042994.26618.206.camel@domain.hid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Slow hard drive access in xenomai List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai@xenomai.org, Peter Pastor On Mon, 2010-10-25 at 23:26 +0200, Jan Kiszka wrote: > Am 25.10.2010 23:21, Philippe Gerum wrote: > > On Mon, 2010-10-25 at 21:40 +0200, Jan Kiszka wrote: > >> Am 25.10.2010 21:03, Peter Pastor wrote: > >>> Hey Jan, > >>> > >>> I did not apply any ubuntu patch for kernel 2.6.35 (since I do not have > >>> one). Also, good to know that I should not use xenomai patches together > >>> with ubuntu patches. > >>> > >>> Anyway, the problem occurred as well with the kernel 2.6.35 (see attached > >>> dmesg_bad_2.6.35) > >>> I also attached the config. > >>> > >> > >> ... > >> > >>> [ 5751.714643] irq 16: nobody cared (try booting with the "irqpoll" option) > >>> [ 5751.714649] Pid: 0, comm: swapper Tainted: P 2.6.35-ipipe-2.5.4-slim #2 > >>> [ 5751.714653] Call Trace: > >>> [ 5751.714655] [] __report_bad_irq+0x26/0xa0 > >>> [ 5751.714668] [] note_interrupt+0x18c/0x1d0 > >>> [ 5751.714672] [] handle_fasteoi_irq+0xcd/0x100 > >>> [ 5751.714677] [] handle_irq+0x1d/0x30 > >>> [ 5751.714681] [] do_IRQ+0x70/0x100 > >>> [ 5751.714685] [] __ipipe_sync_stage+0x207/0x20d > >>> [ 5751.714689] [] ? do_IRQ+0x0/0x100 > >>> [ 5751.714692] [] ? __xirq_end+0x0/0x9c > >>> [ 5751.714696] [] ? do_IRQ+0x0/0x100 > >>> [ 5751.714700] [] __ipipe_walk_pipeline+0x113/0x120 > >>> [ 5751.714706] [] __ipipe_handle_irq+0x124/0x310 > >>> [ 5751.714708] [] ? __ipipe_ack_fasteoi_irq+0x0/0x10 > >>> [ 5751.714712] [] common_interrupt+0x13/0x2c > >>> [ 5751.714713] [] ? __ipipe_halt_root+0x26/0x40 > >>> [ 5751.714718] [] ? atomic_notifier_call_chain+0x11/0x20 > >>> [ 5751.714722] [] default_idle+0x45/0x50 > >>> [ 5751.714725] [] cpu_idle+0x7a/0xd0 > >>> [ 5751.714728] [] start_secondary+0x1c1/0x1c5 > >>> [ 5751.714730] handlers: > >>> [ 5751.714730] [] (usb_hcd_irq+0x0/0xb0) > >>> [ 5751.714735] [] (mpt_interrupt+0x0/0xa00 [mptbase]) > >>> [ 5751.714747] Disabling IRQ #16 > >> > >> I'm not yet sure, but a first thought: We have a shared fasteoi IRQ > >> here, and we are on SMP. Compared to vanilla, the fasteoi flow of ipipe > >> looks so much different to me ATM that I tend to believe two cores end > >> up having this IRQ queued at the same time. One runs first and handles > >> all triggers, the second bails out like above. > >> > >> Philippe, we _end_ fasteoi in the ipipe ack path. Do we mask them prior > >> to this? What prevents a second IRQ arriving after this early eoi? > > > > All fasteoi handlers are supposed to mask+ack when the pipeline is > > enabled, > > What am I missing? The code I was looking at (__ipipe_ack_fasteoi) just > does a regular eoi at chip level. Have a look at the chip handlers. > > > to avoid interrupt storm due to the deferral we may introduce > > in the irq delivery. I do see this in the regular ioapic chip > > descriptor, but this is lacking with interrupt remap. I guess we could > > have a problem with Intel IOMMUs. > > IOMMUs should blow up the system anyway once a PCI driver is used in the > RT domain (DMA remapping involved Linux locks and may even allocate > memory). Guess we should add a !IPIPE to their Kconfig entries. > Yes, would make sense. > Jan > -- Philippe.