Subject: Re: panic in tg3 driver

From: "Matt Carlson" <[email-masked]>
Date: Mon, 24 Jan 2011 18:25:32 -0800

On Mon, Jan 24, 2011 at 04:59:22PM -0800, Matt Carlson wrote:
> 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.

Just curious, is the problem still there if you add pci=nomsi to the
kernel command line?