Re: 2.6.29-rc3: tg3 dead after resume

[Parag Warudkar <parag.lkml@gmail.com>]

On Fri, 30 Jan 2009, Matt Carlson wrote:

> 
> If the PCI_COMMAND message doesn't match, then it means that the
> PCI_COMMAND register isn't getting restored for some reason.  If they do
> On Thu, Jan 29, 2009 at 02:35:44PM -0800, Parag Warudkar wrote:
> > 
> > 
> > On Thu, 29 Jan 2009, Matt Carlson wrote:
> > 
> > > FWIW, I can suspend and resume using the latest linux-2.6 kernel
> > > on a machine with a similar chip here.  The problem doesn't seem to
> > > affect all Broadcom devices.
> > 
> > It is failing for me on HP xw6600 workstation, if that helps in any way.
> > 
> > Parag
> 
> O.K.  Let's test some more assumptions.  Can you apply the following
> patch and observe the system logs when the device is first loaded and
> again after resume.  The patch looks at the pci command register to
> verify that memory space IO is indeed enabled.  (It should be.)  This is
> all that should be needed for MMIO to work.
> On Thu, Jan 29, 2009 at 02:35:44PM -0800, Parag Warudkar wrote:
> > 
> > 
> > On Thu, 29 Jan 2009, Matt Carlson wrote:

> O.K.  Let's test some more assumptions.  Can you apply the following
> patch and observe the system logs when the device is first loaded and
> again after resume.  The patch looks at the pci command register to
> verify that memory space IO is indeed enabled.  (It should be.)  This is
> all that should be needed for MMIO to work.
> match, then something else in the system is not getting restored
> correctly.
> 
Here is the output after applying the patch (fresh boot btw) -

[   29.698877] eth0: PCI_COMMAND reg = 0x406 (bit 1 is on)
[   29.698880] eth0: Reg value at offset 0x0 is 0x167b14e4
[   29.758169] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   31.295087] tg3: eth0: Link is up at 100 Mbps, full duplex.
[   31.295090] tg3: eth0: Flow control is off for TX and off for RX.
[   31.297574] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   41.872007] eth0: no IPv6 routers present
^^^ Pre-Suspend

[  245.924484] eth0: PCI_COMMAND reg = 0x406 (bit 1 is on)
[  245.924487] eth0: Reg value at offset 0x0 is 0xffffffff
[  247.317971] tg3: eth0: No firmware running.
[  258.710634] ADDRCONF(NETDEV_UP): eth0: link is not ready
^^^ Post-Suspend

So it looks like the memory space IO is enabled before and after suspend.
The device/vendor id goes 0xffffffff after resume - just like before.
Does that one matter? (Firmware may be looking at it?) 

> 
> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> index 8b3f846..67bb29f 100644
> --- a/drivers/net/tg3.c
> +++ b/drivers/net/tg3.c
> @@ -7225,8 +7225,17 @@ static int tg3_reset_hw(struct tg3 *tp, int reset_phy)
>   */
>  static int tg3_init_hw(struct tg3 *tp, int reset_phy)
>  {
> +	u16 cmd;
> +
>  	tg3_switch_clocks(tp);
>  
> +	pci_read_config_word(tp->pdev, PCI_COMMAND, &cmd);
> +
> +	printk(KERN_NOTICE "%s: PCI_COMMAND reg = 0x%x (bit 1 is %s)\n",
> +	       tp->dev->name, cmd, (cmd & PCI_COMMAND_MEMORY) ? "on" : "off");
> +	printk(KERN_NOTICE "%s: Reg value at offset 0x0 is 0x%x\n",
> +	       tp->dev->name, tr32(0x0));
> +
>  	tw32(TG3PCI_MEM_WIN_BASE_ADDR, 0);
>  
>  	return tg3_reset_hw(tp, reset_phy);
> 
>