public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Roland Dreier <roland@topspin.com>
To: "Nguyen, Tom L" <tom.l.nguyen@intel.com>
Cc: "cramerj" <cramerj@intel.com>,
	"Ronciak, John" <john.ronciak@intel.com>,
	"Venkatesan, Ganesh" <ganesh.venkatesan@intel.com>,
	<linux-net@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] [broken?] Add MSI support to e1000
Date: Mon, 23 Aug 2004 12:39:01 -0700	[thread overview]
Message-ID: <521xhxve3u.fsf@topspin.com> (raw)
In-Reply-To: <C7AB9DA4D0B1F344BF2489FA165E50240619D9DA@orsmsx404.amr.corp.intel.com> (Tom L. Nguyen's message of "Mon, 23 Aug 2004 12:09:36 -0700")

    Tom> MSI is an edge trigger, which requires the synchronization
    Tom> handshake between the hardware device and its software device
    Tom> driver. For the MSI-X capability structure, the kernel
    Tom> handles the synchronization by masking and unmasking the MSI
    Tom> maskbits. For the MSI capability structure, the MSI maskbits
    Tom> is optional. If the e1000 hardware does not support the MSI
    Tom> maskbits in its MSI capability structure, I guess it could be
    Tom> a race condition in e1000 hardware, which results an
    Tom> unpredictable behavior.

It seems e1000 does not support the per-vector masking feature of MSI
(see full PCI header dump below).

However if I understand the x86 APIC properly, even without masking,
edge-triggered MSI interrupts should work OK.  As I understand it,
when the interrupt is dispatched, its bit is moved from the IRR to the
ISR.  If the same interrupt is received while the interrupt handler is
running, its bit will be set again in the IRR and it will be
dispatched again as soon as the handler exits.

It seems this should work OK for e1000 -- the chip should not generate
another MSI until the driver reads the ICR in the interrupt handler,
although it might generate an interrupt immediately afterward (while
the interrupt handler is still running).

Am I misunderstanding something?  Or is there something in the
chipset's interrupt handling, outside of the CPU, that will break in
this case?

Thanks,
  Roland

0000:02:0c.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet Controller (rev 02)        Subsystem: Dell: Unknown device 0151
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 185
        Memory at fcfe0000 (32-bit, non-prefetchable) [size=128K]
        I/O ports at df40 [size=64]
        Capabilities: [dc] Power Management version 2
        Capabilities: [e4] PCI-X non-bridge device.
        Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
00: 86 80 0e 10 17 01 30 02 02 00 00 02 10 40 00 00
10: 00 00 fe fc 00 00 00 00 41 df 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 51 01
30: 00 00 00 00 dc 00 00 00 00 00 00 00 09 01 ff 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 e4 22 c8
e0: 00 20 00 1b 07 f0 02 00 00 00 40 04 00 00 00 00
f0: 05 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00

  reply	other threads:[~2004-08-24  0:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-23 19:09 [PATCH] [broken?] Add MSI support to e1000 Nguyen, Tom L
2004-08-23 19:39 ` Roland Dreier [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-08-24 17:40 Nguyen, Tom L
2004-08-24 16:01 Nguyen, Tom L
2004-08-23 23:17 Nguyen, Tom L
2004-08-24  2:15 ` Roland Dreier
2004-08-23 19:41 Nguyen, Tom L
2004-08-23 23:39 ` Andi Kleen
2004-08-24 14:19   ` Roland Dreier
     [not found] <2wpoS-1ai-1@gated-at.bofh.it>
     [not found] ` <2wqXF-2jm-29@gated-at.bofh.it>
2004-08-23 18:17   ` Andi Kleen
2004-08-23 18:26     ` Roland Dreier
2004-08-23 15:41 Nguyen, Tom L
2004-08-23 17:25 ` Roland Dreier
2004-08-24 21:49   ` Chris Leech
2004-08-24 23:36     ` Roland Dreier
2004-08-20 21:37 Roland Dreier

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=521xhxve3u.fsf@topspin.com \
    --to=roland@topspin.com \
    --cc=cramerj@intel.com \
    --cc=ganesh.venkatesan@intel.com \
    --cc=john.ronciak@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-net@vger.kernel.org \
    --cc=tom.l.nguyen@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox