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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
