Re: panic in tg3 driver

["Matt Carlson" <mcarlson@broadcom.com>]

On Sun, Jan 16, 2011 at 10:11:50AM -0800, Stephen Clark wrote:
> On 01/13/2011 08:12 AM, Stephen Clark wrote:
> > On 01/11/2011 10:06 PM, Matt Carlson wrote:
> >> lspci -vvv -xxx -s 81:00.0
> >
> >
> >
> > Further information - I found these messages in /var/log/messages. It 
> > looks
> > like after it switched to INTx mode interrupts for other devices were 
> > hosed.
> >
> > Jan 12 08:37:49 localhost kernel: tg3 0000:81:00.0: eth2: No interrupt 
> > was gener
> > ated using MSI. Switching to INTx mode. Please report this failure to 
> > the PCI ma
> > intainer and include system chipset information
> > Jan 12 08:37:49 localhost kernel: ADDRCONF(NETDEV_UP): eth2: link is 
> > not ready
> > Jan 12 08:38:50 localhost kernel: ata2: lost interrupt (Status 0x50)
> > Jan 12 08:38:50 localhost kernel: ata2.01: exception Emask 0x0 SAct 
> > 0x0 SErr 0x0
> >  action 0x6 frozen
> > Jan 12 08:38:50 localhost kernel: ata2.01: failed command: WRITE DMA
> > Jan 12 08:38:50 localhost kernel: ata2.01: cmd 
> > ca/00:08:e0:bc:51/00:00:00:00:00/f0 tag 0 dma 4096 out
> > Jan 12 08:38:50 localhost kernel:          res 
> > 40/00:01:00:4f:c2/00:00:00:00:00/b0 Emask 0x4 (timeout)
> > Jan 12 08:38:50 localhost kernel: ata2.01: status: { DRDY }
> > Jan 12 08:38:50 localhost kernel: ata2: soft resetting link
> > Jan 12 08:38:50 localhost kernel: do_IRQ: 0.64 No irq handler for 
> > vector (irq -1)
> > Jan 12 08:38:50 localhost kernel: ata2.01: configured for UDMA/33
> > Jan 12 08:38:54 localhost pppd[1983]: No response to 3 echo-requests
> > Jan 12 08:39:55 localhost pppoe[1988]: Inactivity timeout... something 
> > wicked happened on session 3363 
> Just checking to make sure you have everything you need?

Sorry for the delay Stephen.

It looks to me like interrupts aren't being setup correctly on this
system.  I tested MSI and INTx interrupt modes locally and they both
work.  I'm guessing one of two things could be happening:

1) The 2nd parameter of the low-level ISR (tg3_interrupt_tagged()) is
   not correct.  The ISR tries to tell the hardware the interrupt is
   acknowledged, but the message goes unheard.  (This might also explain
   why other devices are also afflicted.)

2) Something is blocking the delivery of the interrupt to the tg3 driver
   altogether.

In both cases, the hardware persistently nags the host to ack the
interrupt, hence the interrupt storm.