linux-kernel - intel-agp PM experiences (was: 2.6.20-rc5: usb mouse breaks suspend to ram)

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:	Thu, 18 Jan 2007 12:51:05 +0100
From:	Andreas Mohr <andim2@...rs.sourceforge.net>
To:	Pavel Machek <pavel@....cz>
Cc:	andi@...as.de, davej@...emonkey.org.uk,
	kernel list <linux-kernel@...r.kernel.org>
Subject: intel-agp PM experiences (was: 2.6.20-rc5: usb mouse breaks suspend to ram)

Hi,

On Wed, Jan 17, 2007 at 01:57:55AM +0100, Pavel Machek wrote:
> > Especially the PCI video_state trick finally got me a working resume on
> > 2.6.19-ck2 r128 Rage Mobility M4 AGP *WITH*(!) fully enabled and working
> > (and keeping working!) DRI (3D).
> 
> Can we get whitelist entry for suspend.sf.net? s2ram from there can do
> all the tricks you described, one letter per trick :-). We even got
> PCI saving lately.

Whitelist? Let me blacklist it all the way to Timbuktu instead!

I've been doing more testing, and X never managed to come back to working
state without some of my couple intel-agp changes:
- a proper suspend method, doing a proper pci_save_state()
  or improved equivalent
- a missing resume check for my i815 chipset
- global cache flush in _configure
- restoring AGP bridge PCI config space

The remaining suspects (the other hacks alone didn't recover it)
are global cache flush and restoring of the *entire* AGP bridge PCI
config space (no, a 64-bytes-only pci_restore_state() alone doesn't help,
and it didn't help either that intel-agp doesn't do pci_save_state() anywhere
 - unless that's now done by default by PCI layer).
I'll do more testing today to isolate which change exactly fixed it.

All in all intel-agp code semi-shattered my universe.
I didn't expect to find all these issues in rather important core code
for a wide-spread chipset vendor - it doesn't even log an
"unhandled chipset: resuming may fail, please report!" message
in the resume handler in case of a missing chipset check
(although it may be debatable whether people are able to see this message
at all).
However since the new AGP code was a heroic refactoring effort
it's understandable that there are some remaining issues.

Given the myriads of resume issues we experience in general,
it may be wise to do something as simple as a code review of *all*
relevant code no matter how "complete" we expect each driver to be...
(one could e.g. start with reviewing all other AGP chipset drivers).

Andreas Mohr
-
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/