All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Strand <bstrand@switchmanagement.com>
To: linux-kernel@vger.kernel.org
Subject: 3c59x + dpti2o problem with interrupt sharing?
Date: Mon, 24 Sep 2001 22:17:52 -0700	[thread overview]
Message-ID: <3BB01380.9070502@switchmanagement.com> (raw)

We just got a new dual AMD box with an Adaptec IDE RAID card and a dual 
3com NIC on the motherboard, running stock suse 7.2 kernel 2.4.4-Suse. 
 All was well for a few days, but when the box was doing some moderate 
Oracle work involving the 3com and the raid card, the box fell off the 
network, and /var/log/messages was suddenly flooded with the following:

Sep 22 14:25:34 db001 kernel: eth0: Host error, FIFO diagnostic register 
0000.
Sep 22 14:25:34 db001 kernel: scsi0: PCI error Interrupt at seqaddr = 0x8
Sep 22 14:25:34 db001 kernel: eth0: PCI bus error, bus status 800000a0
Sep 22 14:25:34 db001 kernel: scsi0: Data Parity Error Detected during 
address or write data phase
Sep 22 14:25:34 db001 kernel: eth0: using NWAY device table, not 8
Sep 22 14:25:34 db001 kernel: scsi1: PCI error Interrupt at seqaddr = 0x8
Sep 22 14:25:34 db001 kernel: scsi1: Data Parity Error Detected during 
address or write data phase
Sep 22 14:25:34 db001 kernel: eth0: Host error, FIFO diagnostic register 
0000.
Sep 22 14:25:34 db001 kernel: eth0: PCI bus error, bus status 80000020
Sep 22 14:25:34 db001 kernel: eth0: using NWAY device table, not 8
Sep 22 14:25:35 db001 kernel: eth0: Host error, FIFO diagnostic register 
0000.
Sep 22 14:25:35 db001 kernel: eth0: PCI bus error, bus status 80000020
Sep 22 14:25:35 db001 kernel: eth0: using NWAY device table, not 8

And the last 3 lines repeat for roughly 300000 lines.  Stripping the 
timestamps and doing an egrep 'eth|scsi' /var/log/messages | sort | 
 uniq of those lines, I got:

NETDEV WATCHDOG: eth0: transmit timed out
eth0: 3Com PCI 3c980 10/100 Base-TX NIC(Python-T) at 0x1400,  00:e0:81
eth0: 3Com PCI 3c980 10/100 Base-TX NIC(Python-T) at 0x1c00,  00:e0:81
eth0: Host error, FIFO diagnostic register 0000.
eth0: Interrupt posted but not delivered -- IRQ blocked by another dev
eth0: PCI bus error, bus status 80000020
eth0: PCI bus error, bus status 800000a0
eth0: Resetting the Tx ring pointer.
eth0: Too much work in interrupt, status e003.
eth0: transmit timed out, tx_status 00 status 7003.
eth0: transmit timed out, tx_status 00 status 7043.
eth0: using NWAY device table, not 8
scsi0: Data Parity Error Detected during address or write data phase
scsi0: PCI error Interrupt at seqaddr = 0x8
scsi1: Data Parity Error Detected during address or write data phase
scsi1: PCI error Interrupt at seqaddr = 0x8

Looking in /proc/interrupts, I noticed that eth0 and dpti were sharing 
an IRQ.  Is this the likely cause of the network failure, and if so, 
does anyone know of a way to get the PCI BIOS to assign separate IRQs to 
the RAID card and the dual 3com?  (I have a Tyan S2462 Thunder K7 board 
with nothing in the manual about this.)  I have disabled onboard SCSI 
(dual AIC7xxx), serial, and parallel as well as pulled the RAID card 
from the machine and power-cycled a few times, but when I put it back 
in, it's sharing an IRQ with the 3com again (I suppose I should try 
disabling/enabling the 3coms too).

A related question is:  should these drivers be able to share IRQs, i.e. 
is it a worthwhile goal to have them operate reliably while sharing 
IRQs, or is IRQ-sharing a performance loss and something to be avoided?

Thanks,
Brian Strand



             reply	other threads:[~2001-09-25  5:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-25  5:17 Brian Strand [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-09-25 18:57 3c59x + dpti2o problem with interrupt sharing? Bonds, Deanna
2001-09-25 22:24 ` Brian Strand

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=3BB01380.9070502@switchmanagement.com \
    --to=bstrand@switchmanagement.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.