[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.0901301743410.4989@parag-desktop>
Date: Fri, 30 Jan 2009 17:50:36 -0500 (EST)
From: Parag Warudkar <parag.lkml@...il.com>
To: Matt Carlson <mcarlson@...adcom.com>
cc: Parag Warudkar <parag.lkml@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: 2.6.29-rc3: tg3 dead after resume
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);
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists