From: Jeff Garzik <jeff@garzik.org>
To: yhlu.kernel@gmail.com
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Miller <davem@davemloft.net>, Greg KH <greg@kroah.com>,
Ingo Molnar <mingo@elte.hu>,
kernel list <linux-kernel@vger.kernel.org>,
netdev@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: [PATCH] e1000: fix IRQx nobody cared for shared irq with INTx
Date: Sat, 29 Mar 2008 17:15:00 -0400 [thread overview]
Message-ID: <47EEB154.9060605@garzik.org> (raw)
In-Reply-To: <200803291403.23479.yhlu.kernel@gmail.com>
Yinghai Lu wrote:
> when try to kexec one latest kernel from kernel.org from RHEL 5.1 got
>
> ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKA] -> GSI 19 (level, low) -> IRQ 19
> acpi->mptable 2 : Int: type 0, pol 1, trig 1, bus 02, IRQ 00, APIC ID 0, APIC INT 13
> PCI: Setting latency timer of device 0000:02:00.0 to 64
> PCI: Enabling Mem-Wr-Inval for device 0000:02:00.0
> scsi0 : on PCI bus 02 device 00 irq 19
> irq 19: nobody cared (try booting with the "irqpoll" option)
> Pid: 1, comm: swapper Not tainted 2.6.24-smp-07682-g551e4fb-dirty #19
>
> Call Trace:
> <IRQ> [<ffffffff8026a3eb>] __report_bad_irq+0x30/0x72
> [<ffffffff8026a651>] note_interrupt+0x224/0x26f
> [<ffffffff8026ae78>] handle_fasteoi_irq+0xa5/0xc8
> [<ffffffff8021ffdc>] call_softirq+0x1c/0x28
> [<ffffffff802218e2>] do_IRQ+0xf1/0x15f
> [<ffffffff8021f361>] ret_from_intr+0x0/0xa
> <EOI> [<ffffffff80785bd6>] pci_mmcfg_write+0x0/0xb0
> [<ffffffff80224dd9>] native_read_tsc+0xd/0x1d
> [<ffffffff804681e7>] __delay+0x17/0x22
> [<ffffffff805cb1a9>] lpfc_sli_brdrestart+0x14c/0x16b
> [<ffffffff805cb264>] lpfc_do_config_port+0x9c/0x3e4
> [<ffffffff802d77a9>] sysfs_link_sibling+0x17/0x31
> [<ffffffff805cb674>] lpfc_sli_hba_setup+0xc8/0x4a2
> [<ffffffff80825397>] lpfc_pci_probe_one+0x750/0x914
> [<ffffffff804728f3>] pci_device_probe+0xb3/0xfb
> [<ffffffff804d958c>] driver_probe_device+0xb5/0x132
> [<ffffffff804d96ab>] __driver_attach+0x0/0x93
> [<ffffffff804d9705>] __driver_attach+0x5a/0x93
> [<ffffffff804d89bc>] bus_for_each_dev+0x44/0x6f
> [<ffffffff804d91b9>] bus_add_driver+0xae/0x1f5
> [<ffffffff804d990e>] driver_register+0x59/0xce
> [<ffffffff80472b56>] __pci_register_driver+0x4a/0x7c
> [<ffffffff80c2d78a>] lpfc_init+0x98/0xba
> [<ffffffff80c0d6e7>] kernel_init+0x175/0x2e1
> [<ffffffff8021fc68>] child_rip+0xa/0x12
> [<ffffffff80c0d572>] kernel_init+0x0/0x2e1
> [<ffffffff8021fc5e>] child_rip+0x0/0x12
>
> handlers:
> [<ffffffff805cdbce>] (lpfc_intr_handler+0x0/0x4c6)
> Disabling IRQ #19
>
> root caused that there is one Intel card that shared io apic pin and irq with
> lpfc
>
> e1000_probe path only use pci_enable_device to setup irq entry but masked, and
> will use e1000_open to use request_irq/setup_irq to install action and
> enable/unmask that io apic entry.
>
> but lpfc driver will call it's probe and request_irq/setup_irq. so it
> enable/umask that io apic entry. and only lpfc's action the lpfc_intr_handler
> is installed.
>
> and some case, the e1000 sent out irq (hw bug or first kernel doesn't call
> e1000_irq_disable?)
> that irq will confuse the hanlder ... it is not for lpfc_intr_handler...
>
> So try to call pci_intx(dev, 0) in e1000_probe,
> and later call pci_intx(dev, 1) after request_irq in e1000_open patch, if the
> irq is using INTx
>
> even e1000 is using MSI, still need this patch. Because even pci_enable_msi in
> e1000_open path will call pci_intx(dev, 0), that is too late. when we have lpfc
> driver loaded before use ifconfig to set network connection.
>
> othe drivers may need to be updated in the same way, if they have same problem
> like nobody cared irq with shared INTx irq.
>
> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
>
> Index: linux-2.6/drivers/net/e1000/e1000_main.c
> ===================================================================
> --- linux-2.6.orig/drivers/net/e1000/e1000_main.c
> +++ linux-2.6/drivers/net/e1000/e1000_main.c
> @@ -324,6 +324,9 @@ static int e1000_request_irq(struct e100
> pci_disable_msi(adapter->pdev);
> DPRINTK(PROBE, ERR,
> "Unable to allocate interrupt Error: %d\n", err);
> + } else if (!adapter->have_msi) {
> + /* enable INTx before if not using MSI */
> + pci_intx(adapter->pdev, 1);
> }
>
> return err;
> @@ -934,6 +937,8 @@ e1000_probe(struct pci_dev *pdev,
> uint16_t eeprom_apme_mask = E1000_EEPROM_APME;
> DECLARE_MAC_BUF(mac);
>
> + /* disable INTx at first */
> + pci_intx(pdev, 0);
> if ((err = pci_enable_device(pdev)))
> return err;
>
> Index: linux-2.6/drivers/net/e1000e/netdev.c
> ===================================================================
> --- linux-2.6.orig/drivers/net/e1000e/netdev.c
> +++ linux-2.6/drivers/net/e1000e/netdev.c
> @@ -960,6 +960,9 @@ static int e1000_request_irq(struct e100
> err);
> if (adapter->flags & FLAG_MSI_ENABLED)
> pci_disable_msi(adapter->pdev);
> + } else if (!(adapter->flags & FLAG_MSI_ENABLED)) {
> + /* enable INTx before if not using MSI */
> + pci_intx(adapter->pdev, 1);
> }
>
> return err;
These seem sane.
> @@ -3726,6 +3729,8 @@ static int __devinit e1000_probe(struct
> u16 eeprom_apme_mask = E1000_EEPROM_APME;
>
> e1000e_disable_l1aspm(pdev);
> + /* disable INTx at first */
> + pci_intx(pdev, 0);
> err = pci_enable_device(pdev);
> if (err)
> return err;
Any pci_* call before pci_enable_device() is questionable. I would put
it after pci_enable_device(), unless there is a _strong_ reason.
PCI devices are not considered available, with resources assigned, until
pci_enable_device()
I am also curious what irq events are being raised? That seems like
another problem area to address, since pci_intx() is just a band-aid
hiding that behavior.
Jeff
next prev parent reply other threads:[~2008-03-29 21:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-29 21:03 [PATCH] e1000: fix IRQx nobody cared for shared irq with INTx Yinghai Lu
2008-03-29 21:15 ` Jeff Garzik [this message]
2008-03-29 23:46 ` Yinghai Lu
2008-03-29 23:50 ` Yinghai Lu
2008-03-31 21:58 ` [PATCH] r8169: " Yinghai Lu
2008-04-02 0:20 ` [PATCH] ixgb/e: " Yinghai Lu
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=47EEB154.9060605@garzik.org \
--to=jeff@garzik.org \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=yhlu.kernel@gmail.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 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.