linux-kernel - Re: [linux-pm] "i8042: Can't reactivate AUX port" after s2ram on 3.4-rc2

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]

Date:	Sun, 15 Apr 2012 21:52:55 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Mikko Vinni <mmvinni@...oo.com>
Cc:	Bjorn Helgaas <bhelgaas@...gle.com>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Allen Kay <allen.m.kay@...el.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: Re: [linux-pm] "i8042: Can't reactivate AUX port" after s2ram on 3.4-rc2

On Sunday, April 15, 2012, Rafael J. Wysocki wrote:
> On Sunday, April 15, 2012, Mikko Vinni wrote:
> > From: Rafael J. Wysocki:
> > 
> > >>  > Please change that dev_dbg() in pci_restore_state() into dev_info()
> > >>  > and see how many times it gets printed with the commit applied (not 
> > > reverted).
> > >> 
> > >> 
> > >>  I ran the dmesg through "uniq -c" and it looks like this:
> > >> 
> > >>        1 ACPI: Low-level resume complete
> > >>        1 PM: Restoring platform NVS memory
> > >>        1 Enabling non-boot CPUs ...
> > >>        1 Booting Node 0 Processor 1 APIC 0x1
> > >>        1 CPU1 is up
> > >>        1 ACPI: Waking up from system sleep state S3
> > >>       10 pcieport 0000:00:02.0: restoring config space at offset 0x7 (was 
> > > 0x20005151, writing 0x5151)
> > > 
> > > Well, yeah.  So the commit you bisected it to is total and utter crap.
> > > Most importantly, it retries the writes for all of the dwords in the 
> > > device's
> > > config space _including_ the status register (which by definition need not be
> > > the same as the written value).
> > > 
> > > I wonder if the appended patch helps?
> > 
> > It does. It seems there is a change only in the devices that refuse to wake up;
> > somehow writing too many times to them affects the rest of the machine.
> > So, for this machine your patch fixes the problem of the touchpad not working.
> 
> Good, thanks for the confirmation. :-)
> 
> > The write is now attempted (at most) 11 times, as shown below. Probably not
> > a huge deal.
> > 
> >       1 ACPI: Waking up from system sleep state S3
> >      11 pcieport 0000:00:02.0: restoring config space at offset 0x1c (was 0x20005151, writing 0x5151)
> 
> Well, here you see that the PCI Express port is refusing to accept a new BAR value.
> It seems not to be operational and this probably is the reason why the device below
> the port don't respond later.
> 
> I'm not sure why that happens, though.

OK, I know.  There simply are fewer BARs for bridges (and PCIe ports)
and here we're attempting to overwrite the secondary status register.  Sigh.

Well, I guess we should only retry the writes to BARs for Type 0 headers.

Thanks,
Rafael
--
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/