All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: avorontsov@ru.mvista.com
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Ingo Molnar <mingo@elte.hu>,
	Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Steven Rostedt <rostedt@goodmis.org>,
	Daniel Walker <dwalker@mvista.com>
Subject: Re: [RT] MPIC edge sensitive issues with hardirq preemption
Date: Tue, 01 Jul 2008 14:41:19 +0400	[thread overview]
Message-ID: <486A09CF.1040405@ru.mvista.com> (raw)
In-Reply-To: <20080630190132.GA6492@polina.dev.rtsoft.ru>

Hello.

Anton Vorontsov wrote:

> But how this could be a bug in the PIC code? IMO this is a bug in the
> kernel/irq code, since it assumes that fasteoi PIC will retrigger masked
> edge sources... This isn't true for at least MPIC. To make this work for
> all fasteoi PICs, we should mask edge sensitive interrupts very very
> carefully.
>   

   I guess it assumed this based on 8259's behavior (not sure about I/O 
APIC).
   Hm, but the 8259 code never used "fasteoi" path for some obscure 
reason...

> jammed with the idea that MPIC irq type 0 is low level sensitive, but the
> true thing is that it is rising edge sensitive. (Ah, I know where I got
> confused, type 0 is active-low for ISA PICs).
>   

    You mean in the device tree?

> So in all my previous emails I was wrong when I was saying "mpic is
> programmed to low level sensitive". It was programmed for rising edge
> sensitive. An all my further reasonings were flawed because of this.
>   

   Gah.  I'm surprised how it could work at all then...

> Re-programming MPIC to high level sensitive also makes IDE work. But
> this doesn't mean that IRQ code is correct.
>   

   I wonder why. :-O
   Your ULi IDE is in native mode, so it should be generating a PCI 
interrupt -- which is *low* level sensitive.

MBR, Sergei



  parent reply	other threads:[~2008-07-01 10:41 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-23 23:40 [PATCH -rt] ide: fix interrupts processing issue with preempt-able hardirqs Anton Vorontsov
2008-06-23 23:51 ` Ingo Molnar
2008-06-24  0:00   ` Anton Vorontsov
2008-06-25 12:34     ` Anton Vorontsov
2008-06-25 12:32       ` Alan Cox
2008-06-25 14:12         ` Anton Vorontsov
2008-06-25 13:15       ` Sergei Shtylyov
2008-06-25 14:22         ` Anton Vorontsov
2008-06-25 14:32           ` Alan Cox
2008-06-25 15:26             ` Anton Vorontsov
2008-06-25 14:59           ` Anton Vorontsov
2008-06-28  0:54       ` [PATCH v2 -rt] ide: workaround buggy hardware issues with preemptable hardirqs Anton Vorontsov
2008-06-28  1:09         ` Anton Vorontsov
2008-06-28  9:15           ` Alan Cox
2008-06-28  9:14         ` Alan Cox
2008-06-28 10:43           ` Sergei Shtylyov
2008-06-29 12:49             ` Alan Cox
2008-06-29 13:17               ` Sergei Shtylyov
2008-06-29 14:23                 ` Anton Vorontsov
2008-06-28 10:30         ` Sergei Shtylyov
2008-06-28 11:31           ` Anton Vorontsov
2008-06-28 11:52             ` Sergei Shtylyov
2008-06-29 23:26         ` Benjamin Herrenschmidt
2008-06-30 19:01           ` [RT] MPIC edge sensitive issues with hardirq preemption (was: Re: [PATCH v2 -rt] ide: workaround buggy hardware issues with preemptable hardirqs) Anton Vorontsov
2008-06-30 21:59             ` Benjamin Herrenschmidt
2008-06-30 22:37               ` Anton Vorontsov
2008-07-01 10:41             ` Sergei Shtylyov [this message]
2008-07-01 11:34               ` [RT] MPIC edge sensitive issues with hardirq preemption Anton Vorontsov
2008-06-23 23:52 ` [PATCH -rt] ide: fix interrupts processing issue with preempt-able hardirqs Anton Vorontsov

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=486A09CF.1040405@ru.mvista.com \
    --to=sshtylyov@ru.mvista.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=avorontsov@ru.mvista.com \
    --cc=benh@kernel.crashing.org \
    --cc=bzolnier@gmail.com \
    --cc=dwalker@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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.