lkml.org 
[lkml]   [2009]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: 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);
>
>


\
 
 \ /
  Last update: 2009-01-30 23:53    [W:0.143 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site