linux-kernel - Re: [REGRESSION] tg3 dead after s2ram

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <200708021005.45773.joachim.deguara@amd.com>
Date:	Thu, 2 Aug 2007 10:05:44 +0200
From:	"Joachim Deguara" <joachim.deguara@....com>
To:	"Michael Chan" <mchan@...adcom.com>
cc:	"Andrew Morton" <akpm@...ux-foundation.org>,
	"lkml List" <linux-kernel@...r.kernel.org>,
	"Michal Piotrowski" <michal.k.k.piotrowski@...il.com>,
	"netdev" <netdev@...r.kernel.org>, linux-acpi@...r.kernel.org
Subject: Re: [REGRESSION] tg3 dead after s2ram

On Wednesday 01 August 2007 23:00:23 Michael Chan wrote:
> On Wed, 2007-08-01 at 10:47 -0700, Michael Chan wrote:
> > You have 2 Broadcom devices in your system.  07:00.0 is a wireless
> > device, I think.  8:4.0 is the tg3 device.
> >
> > It's clear that the tg3 device is still in D3 state after resume and
> > that explains why all register accesses fail.  tg3_resume() should put
> > the device back in D0 state in a very straight forward way and I don't
> > see how that can fail.  It worked for me when I tested it last night.
> > Can you add some printk() to tg3_resume() to see what's happening?  Let
> > me know if you want me to send you some debug patches to do that.
>
> I misread the PCI registers below.  The power state was ok.
>
> The problem is that memory enable and bus master were not set in PCI
> register 4 after resume.  This also explains the register access
> failures.
>
> In tg3_resume(), we call pci_restore_state() which should re-enable
> those 2 bits in PCI register 4.  Can you add some printk() to see why
> those bits are not restored after pci_restore_state()?

Reading pci_restore_state() it looks already instrumented.  Sorry about the 
wrong pci device, looking at my BCM5788 it is pci device 08:04.0 and looking 
at the log from my first post there is nothing restored in the first 64 
bytes!  Otherwise it would have said "PM: Writing back..."

Is this what you are looking for or should I do other printk instrumentation?

-Joachim

 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/