Hi!
I started using el-cheapo usb mouse... only to find out that it breaks
suspend to RAM. Suspend-to-disk works okay. I was not able to extract
any usefull messages...
Resume process hangs; I can still switch console and even type on
keyboard, but userland is dead, and I was not able to get magic sysrq
to respond.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 1/16/07, Pavel Machek <[email protected]> wrote:
> Hi!
>
> I started using el-cheapo usb mouse... only to find out that it breaks
> suspend to RAM. Suspend-to-disk works okay. I was not able to extract
> any usefull messages...
>
> Resume process hangs; I can still switch console and even type on
> keyboard, but userland is dead, and I was not able to get magic sysrq
> to respond.
Are you using hid or usbmouse?
--
Dmitry
Hi!
> >I started using el-cheapo usb mouse... only to find out that it breaks
> >suspend to RAM. Suspend-to-disk works okay. I was not able to extract
> >any usefull messages...
> >
> >Resume process hangs; I can still switch console and even type on
> >keyboard, but userland is dead, and I was not able to get magic sysrq
> >to respond.
>
> Are you using hid or usbmouse?
I think it is hid:
pavel@amd:/data/l/linux$ cat .config | grep MOUSE
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_SERIAL=y
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_USB_IDMOUSE is not set
pavel@amd:/data/l/linux$ cat .config | grep HID
CONFIG_BT_HIDP=y
# HID Devices
CONFIG_HID=y
CONFIG_USB_HID=y
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
# CONFIG_USB_HIDDEV is not set
# CONFIG_USB_PHIDGET is not set
pavel@amd:/data/l/linux$
Should I disable config_hid and try some other driver?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 1/16/07, Pavel Machek <[email protected]> wrote:
> Hi!
>
> > >I started using el-cheapo usb mouse... only to find out that it breaks
> > >suspend to RAM. Suspend-to-disk works okay. I was not able to extract
> > >any usefull messages...
> > >
> > >Resume process hangs; I can still switch console and even type on
> > >keyboard, but userland is dead, and I was not able to get magic sysrq
> > >to respond.
> >
> > Are you using hid or usbmouse?
>
> I think it is hid:
>
> pavel@amd:/data/l/linux$ cat .config | grep MOUSE
> CONFIG_INPUT_MOUSEDEV=y
> CONFIG_INPUT_MOUSEDEV_PSAUX=y
> CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
> CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
> CONFIG_INPUT_MOUSE=y
> CONFIG_MOUSE_PS2=y
> CONFIG_MOUSE_SERIAL=y
> # CONFIG_MOUSE_INPORT is not set
> # CONFIG_MOUSE_LOGIBM is not set
> # CONFIG_MOUSE_PC110PAD is not set
> # CONFIG_MOUSE_VSXXXAA is not set
> # CONFIG_USB_IDMOUSE is not set
> pavel@amd:/data/l/linux$ cat .config | grep HID
> CONFIG_BT_HIDP=y
> # HID Devices
> CONFIG_HID=y
> CONFIG_USB_HID=y
> # CONFIG_USB_HIDINPUT_POWERBOOK is not set
> # CONFIG_HID_FF is not set
> # CONFIG_USB_HIDDEV is not set
> # CONFIG_USB_PHIDGET is not set
> pavel@amd:/data/l/linux$
>
> Should I disable config_hid and try some other driver?
No, HID is the preferred... I am not sure what is going on - on my box
STR does not work at all thanks to nvidia chip turning the display on
all the way as the very last step of suspend ;(
--
Dmitry
Hi!
> >> >I started using el-cheapo usb mouse... only to find out that it breaks
> >> >suspend to RAM. Suspend-to-disk works okay. I was not able to extract
> >> >any usefull messages...
> >> >
> >> >Resume process hangs; I can still switch console and even type on
> >> >keyboard, but userland is dead, and I was not able to get magic sysrq
> >> >to respond.
> >>
> >> Are you using hid or usbmouse?
> >
> >I think it is hid:
> >
> >pavel@amd:/data/l/linux$ cat .config | grep MOUSE
...
> >pavel@amd:/data/l/linux$
> >
> >Should I disable config_hid and try some other driver?
>
> No, HID is the preferred... I am not sure what is going on - on my box
> STR does not work at all thanks to nvidia chip turning the display on
> all the way as the very last step of suspend ;(
Hmm, I guess we should fix the suspend for you...
Strange, I can't reproduce the hang any more.
I found other weirdness while trying to hang it: if I move the mouse
while suspending, it is _not_ completely powered off while machine is
suspended. LED still shines, at half brightness...?!
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi,
On Tue, Jan 16, 2007 at 04:25:20PM -0500, Dmitry Torokhov wrote:
> No, HID is the preferred... I am not sure what is going on - on my box
> STR does not work at all thanks to nvidia chip turning the display on
> all the way as the very last step of suspend ;(
One or several of these options might help cure this:
- agp=off kernel command line (plus AGP driver option enabled in nvidia xorg.conf)
- suspend: cat /proc/bus/pci/AA/BB.C >/tmp/video_state --> resume
- suspend: vbetool vbestate save --> resume
- directly after resume: vbetool post
- playing with chvt to not stay in X vt upon suspend
- acpi_sleep=s3_bios or acpi_sleep=s3_mode
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).
Or, to be precise, video_state was the ticket to keeping X.org alive
after resume instead of near-100% X lockup, which then allowed
vbestate post to successfully deal with the remaining pixel line distortion
in order to get a clear display again.
And some agp hacks might have played a role here, too, need to investigate
this again and submit something if this is the case.
In your case this sounds like the all-too-familiar mis-signalling of the
TFT display causing it to "melt" which ends up with an all-white screen,
so this should most likely be cured via vbetool post or so.
keywords: agpgart r128 suspend resume vbetool intel-agp dri
Andreas Mohr
Hi!
> > No, HID is the preferred... I am not sure what is going on - on my box
> > STR does not work at all thanks to nvidia chip turning the display on
> > all the way as the very last step of suspend ;(
>
> One or several of these options might help cure this:
> - agp=off kernel command line (plus AGP driver option enabled in nvidia xorg.conf)
> - suspend: cat /proc/bus/pci/AA/BB.C >/tmp/video_state --> resume
> - suspend: vbetool vbestate save --> resume
> - directly after resume: vbetool post
> - playing with chvt to not stay in X vt upon suspend
> - acpi_sleep=s3_bios or acpi_sleep=s3_mode
>
> 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.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, 16 Jan 2007, Pavel Machek wrote:
> Strange, I can't reproduce the hang any more.
>
> I found other weirdness while trying to hang it: if I move the mouse
> while suspending, it is _not_ completely powered off while machine is
> suspended. LED still shines, at half brightness...?!
dmesg output (with CONFIG_USB_DEBUG) would be helpful, and so would a
usbmon log (see Documentation/usb/usbmon.txt).
Alan Stern
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
Hi.
On Thu, 2007-01-18 at 12:51 +0100, Andreas Mohr wrote:
[...]
> 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).
Now that's a really good idea, and simple to do too.
For some time I've been thinking of a sysfs entry that could list for
you all the drivers in the tree. Perhaps that, combined with your idea
(as well as implementing your idea separately) would be helpful?
> 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).
Yes, we really need to get around to checking what drivers do suspend
and resume properly for both S3 and S4, and prodding the authors where
necessary.
Regards,
Nigel
Hi!
> > > 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
Can you post a patch?
Whitelist entry would still be welcome.
> All in all intel-agp code semi-shattered my universe.
> I didn't expect to find all these issues in rather important core code
...
> 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*
Any volunteers?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 2007.01.18 23:16:51 +0000, Pavel Machek wrote:
> Hi!
>
> > > > 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
>
> Can you post a patch?
I've post a patch which trys to resolve pci config restore issue, see
http://lkml.org/lkml/2007/1/16/297. It resolves s3 issue with my 965G machine,
that my X can come back to live after s3, but I wasn't aware of the issues Andreas
has noted. It'll be good if more people could try this out.
> Whitelist entry would still be welcome.
>
> > All in all intel-agp code semi-shattered my universe.
> > I didn't expect to find all these issues in rather important core code
> ...
> > 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*
>
> Any volunteers?
> Pavel
Hi!
> > > 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
> >
> > Can you post a patch?
>
> I've post a patch which trys to resolve pci config restore issue, see
> http://lkml.org/lkml/2007/1/16/297. It resolves s3 issue with my 965G machine,
> that my X can come back to live after s3, but I wasn't aware of the issues Andreas
> has noted. It'll be good if more people could try this out.
Ok, I guess we'd like some testing here... so that in can be fixed in
mainline...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 1/23/07, Pavel Machek <[email protected]> wrote:
> > I've post a patch which trys to resolve pci config restore issue, see
> > http://lkml.org/lkml/2007/1/16/297. It resolves s3 issue with my 965G machine,
> > that my X can come back to live after s3, but I wasn't aware of the issues Andreas
> > has noted. It'll be good if more people could try this out.
>
> Ok, I guess we'd like some testing here... so that in can be fixed in
> mainline...
Pavel,
It was same with me too, there were some ACPI issues (don't remember
properly).
http://lkml.org/lkml/2007/1/17/64
I am not getting enough time to do the tests for 965 board. I can
volunteer for this ;-) Any guidelines for testing a MOBO to comply
with LKML (am new for testing, have decided to start with this 965
MOBO).
Awaiting for suggestions...
[OT] Are there any issues with 975 (have this board too, but never
tested till now)
> Pavel
Thanks,
~Akula2
Hi,
On Mon, Jan 22, 2007 at 12:45:19PM +0800, Wang Zhenyu wrote:
> I've post a patch which trys to resolve pci config restore issue, see
> http://lkml.org/lkml/2007/1/16/297. It resolves s3 issue with my 965G machine,
> that my X can come back to live after s3, but I wasn't aware of the issues Andreas
> has noted. It'll be good if more people could try this out.
[sorry, somewhat late, had complete and utter heating failure at home]
I employed a variant of your patch (added a static i815_dev
to support my i815 chipset). It didn't help, X hung on resume.
PCI IDs of i815 are 0x1130, 0x1131, 0x1132.
I'm having 0x1130 and 0x1131, IOW an i815 system in
"external AGP graphics" mode:
00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82815 815 Chipset AGP Bridge (rev 02)
so I need to query 0x1131 instead of PCI_DEVICE_ID_INTEL_82815_CGC
(0x1132) for resume of the proper device, right??
Or am I supposed to restore the PCI space of my *non-builtin*
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M4 AGP
card instead?
The diff below (against 2.6.19-ck2 or in fact plain 2.6.19)
shows what I changed from my (working!) version to what I think I
had to do to be compatible with your intentions. OK, not quite,
I now merely disabled the suspend/restore of the full PCI space,
several other parts remained the same.
IOW, suspending/restoring the *full* PCI space of my Host Bridge
helped, whereas restoring the standard PCI space of my Host Bridge
plus restoring the PCI space of the AGP bridge as you suggested
did NOT.
Can we conclude from that that I'm having rather different issues
than you?
I think this means that we are required/supposed to backup
the entire PCI space of host bridges, right? How to actually implement
this cleanly? Oh, and of course my patch manages to fix the X11
lockup only, actual video is still garbled and requires
vbetool magic to get it fixed, too...
Thanks,
Andreas Mohr
--- intel-agp.c 2007-02-07 21:50:49.000000000 +0100
+++ intel-agp.c.2619ck2.patched 2007-02-07 21:50:04.000000000 +0100
@@ -1666,6 +1666,9 @@
return 1;
}
+static struct pci_dev *i815_dev;
+
+
static int __devinit agp_intel_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
@@ -1719,7 +1722,10 @@
if (find_i810(PCI_DEVICE_ID_INTEL_82815_CGC))
bridge->driver = &intel_810_driver;
else
+ {
+ i815_dev = pci_get_device(PCI_VENDOR_ID_INTEL, 0x1131, NULL);
bridge->driver = &intel_815_driver;
+ }
name = "i815";
break;
case PCI_DEVICE_ID_INTEL_82820_HB:
@@ -1921,12 +1927,62 @@
}
#ifdef CONFIG_PM
+
+#if 0
+static u32 pci_cfg_space[64];
+
+static int agp_intel_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+ int i;
+ for (i = 0; i <= 63; i++)
+ pci_read_config_dword(pdev, i * 4, &pci_cfg_space[i]);
+ pci_set_power_state(pdev, pci_choose_state(pdev, state));
+
+ printk(KERN_INFO "agp_intel_suspend\n");
+
+ return 0;
+}
+#endif
+
static int agp_intel_resume(struct pci_dev *pdev)
{
struct agp_bridge_data *bridge = pci_get_drvdata(pdev);
+ int i;
+ int val;
+ pci_set_power_state (pdev, PCI_D0);
pci_restore_state(pdev);
+ if (i815_dev)
+ pci_restore_state(i815_dev);
+
+#if 0
+ for (i = 15; i >= 0; i--) {
+ pci_read_config_dword(pdev, i * 4, &val);
+ if (val != pci_cfg_space[i]) {
+ printk(KERN_DEBUG "AGP: Writing back config space on "
+ "device %s at offset %x (was %x, writing %x)\n",
+ pci_name(pdev), i,
+ val, pci_cfg_space[i]);
+ pci_write_config_dword(pdev, i * 4,
+ pci_cfg_space[i]);
+ }
+ }
+ for (i = 63; i >= 16; i--) {
+ pci_read_config_dword(pdev, i * 4, &val);
+ if (val != pci_cfg_space[i]) {
+ printk(KERN_DEBUG "AGP: Writing back config space on "
+ "device %s at offset %x (was %x, writing %x)\n",
+ pci_name(pdev), i,
+ val, pci_cfg_space[i]);
+ pci_write_config_dword(pdev, i * 4,
+ pci_cfg_space[i]);
+ }
+ }
+#endif
+
+ printk(KERN_INFO "agp bridge is %04x\n", agp_bridge->dev->device);
+
if (bridge->driver == &intel_generic_driver)
intel_configure();
else if (bridge->driver == &intel_850_driver)
@@ -1939,6 +1995,8 @@
intel_i915_configure();
else if (bridge->driver == &intel_830_driver)
intel_i830_configure();
+ else if (bridge->driver == &intel_815_driver)
+ intel_815_configure();
else if (bridge->driver == &intel_810_driver)
intel_i810_configure();
else if (bridge->driver == &intel_i965_driver)
@@ -1998,6 +2056,7 @@
.probe = agp_intel_probe,
.remove = __devexit_p(agp_intel_remove),
#ifdef CONFIG_PM
+ //.suspend = agp_intel_suspend,
.resume = agp_intel_resume,
#endif
};
Andreas Mohr
Le mardi 23 janvier 2007 à 09:44 +0000, Pavel Machek a écrit :
> Hi!
>
> > > > 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
> > >
> > > Can you post a patch?
> >
> > I've post a patch which trys to resolve pci config restore issue, see
> > http://lkml.org/lkml/2007/1/16/297. It resolves s3 issue with my 965G machine,
> > that my X can come back to live after s3, but I wasn't aware of the issues Andreas
> > has noted. It'll be good if more people could try this out.
>
> Ok, I guess we'd like some testing here... so that in can be fixed in
> mainline...
I can confirm that this patch is needed for my Intel Mac Mini to resume
correctly when used without BIOS emulation (EFI mode). Here're the
relevant lspci lines:
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
Fred.
Hi!
> > Ok, I guess we'd like some testing here... so that in can be fixed in
> > mainline...
>
> I can confirm that this patch is needed for my Intel Mac Mini to resume
> correctly when used without BIOS emulation (EFI mode). Here're the
> relevant lspci lines:
Can you attach the patch you tested (there was link above, but it did
not work for me), and try pushing it through maintainers?
Pavel
> 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03)
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
> 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
>
> Fred.
>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Le lundi 29 janvier 2007 à 23:10 +0100, Pavel Machek a écrit :
> > > Ok, I guess we'd like some testing here... so that in can be fixed in
> > > mainline...
> >
> > I can confirm that this patch is needed for my Intel Mac Mini to resume
> > correctly when used without BIOS emulation (EFI mode). Here're the
> > relevant lspci lines:
>
> Can you attach the patch you tested (there was link above, but it did
> not work for me), and try pushing it through maintainers?
I inlined the patch I used below. If I'm not mistaken, the maintainer is
Davej which is already in the Cc: list. I think it's exactly the same as
was submitted in http://lkml.org/lkml/2007/1/16/297 (I may have hand
copied it though, can't remember). The above link is more complete as it
contains the Signed-off-by and a description.
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index ab0a9c0..f64a115 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -1955,6 +1955,15 @@ static int agp_intel_resume(struct pci_d
pci_restore_state(pdev);
+ /* We should restore our graphics device's config space,
+ * as host bridge (00:00) resumes before graphics device (02:00),
+ * then our access to its pci space can work right.
+ */
+ if (intel_i810_private.i810_dev)
+ pci_restore_state(intel_i810_private.i810_dev);
+ if (intel_i830_private.i830_dev)
+ pci_restore_state(intel_i830_private.i830_dev);
+
if (bridge->driver == &intel_generic_driver)
intel_configure();
else if (bridge->driver == &intel_850_driver)
On Mon, Jan 29, 2007 at 11:21:31PM +0100, Fr?d?ric Riss wrote:
> Le lundi 29 janvier 2007 ? 23:10 +0100, Pavel Machek a ?crit :
> > > > Ok, I guess we'd like some testing here... so that in can be fixed in
> > > > mainline...
> > >
> > > I can confirm that this patch is needed for my Intel Mac Mini to resume
> > > correctly when used without BIOS emulation (EFI mode). Here're the
> > > relevant lspci lines:
> >
> > Can you attach the patch you tested (there was link above, but it did
> > not work for me), and try pushing it through maintainers?
>
> I inlined the patch I used below. If I'm not mistaken, the maintainer is
> Davej which is already in the Cc: list. I think it's exactly the same as
> was submitted in http://lkml.org/lkml/2007/1/16/297 (I may have hand
> copied it though, can't remember). The above link is more complete as it
> contains the Signed-off-by and a description.
>
> diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
> index ab0a9c0..f64a115 100644
> --- a/drivers/char/agp/intel-agp.c
> +++ b/drivers/char/agp/intel-agp.c
> @@ -1955,6 +1955,15 @@ static int agp_intel_resume(struct pci_d
>
> pci_restore_state(pdev);
>
> + /* We should restore our graphics device's config space,
> + * as host bridge (00:00) resumes before graphics device (02:00),
> + * then our access to its pci space can work right.
> + */
> + if (intel_i810_private.i810_dev)
> + pci_restore_state(intel_i810_private.i810_dev);
> + if (intel_i830_private.i830_dev)
> + pci_restore_state(intel_i830_private.i830_dev);
This has been in agpgart.git since the 17th.
I asked Linus to pull last night.
Dave
--
http://www.codemonkey.org.uk
On 2007.01.29 22:30:53 +0000, Andreas Mohr wrote:
> > I've post a patch which trys to resolve pci config restore issue, see
> > http://lkml.org/lkml/2007/1/16/297. It resolves s3 issue with my 965G machine,
> > that my X can come back to live after s3, but I wasn't aware of the issues Andreas
> > has noted. It'll be good if more people could try this out.
>
> [sorry, somewhat late, had complete and utter heating failure at home]
>
> I employed a variant of your patch (added a static i815_dev
> to support my i815 chipset). It didn't help, X hung on resume.
> PCI IDs of i815 are 0x1130, 0x1131, 0x1132.
> I'm having 0x1130 and 0x1131, IOW an i815 system in
> "external AGP graphics" mode:
> 00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 02)
> 00:01.0 PCI bridge: Intel Corporation 82815 815 Chipset AGP Bridge (rev 02)
>
> so I need to query 0x1131 instead of PCI_DEVICE_ID_INTEL_82815_CGC
> (0x1132) for resume of the proper device, right??
> Or am I supposed to restore the PCI space of my *non-builtin*
> 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M4 AGP
> card instead?
Sorry I don't have 815G board nowadays, this board seems has two
pci devs, one for AGP bridge, another for integrated gfx card if no add-in card.
So have you tried both cases?
>
> The diff below (against 2.6.19-ck2 or in fact plain 2.6.19)
> shows what I changed from my (working!) version to what I think I
> had to do to be compatible with your intentions. OK, not quite,
> I now merely disabled the suspend/restore of the full PCI space,
> several other parts remained the same.
>
> IOW, suspending/restoring the *full* PCI space of my Host Bridge
> helped, whereas restoring the standard PCI space of my Host Bridge
> plus restoring the PCI space of the AGP bridge as you suggested
> did NOT.
>
> Can we conclude from that that I'm having rather different issues
> than you?
>
> I think this means that we are required/supposed to backup
> the entire PCI space of host bridges, right? How to actually implement
> this cleanly? Oh, and of course my patch manages to fix the X11
> lockup only, actual video is still garbled and requires
> vbetool magic to get it fixed, too...
ok, just see the AGP tables bits definition for intel_i815_driver,
/* Intel registers */
#define INTEL_APSIZE 0xb4
#define INTEL_ATTBASE 0xb8
#define INTEL_AGPCTRL 0xb0
...
And this could explain why your patch can make X come back to live on
i815, as default suspend saves 64bytes. We need suspend func to handle
this, but for now mainline intel integrated gfx, this's not needed.
Would you send out a cleanup patch later?
Thanks.
-zhen
Hi,
On Tue, Jan 30, 2007 at 08:36:32PM +0800, Wang Zhenyu wrote:
> On 2007.01.29 22:30:53 +0000, Andreas Mohr wrote:
> Sorry I don't have 815G board nowadays, this board seems has two
> pci devs, one for AGP bridge, another for integrated gfx card if no add-in card.
> So have you tried both cases?
Does this mean that it has builtin i815 video, too?
How would I be able to "try both cases", then?
I somehow would have to configure it to boot with builtin graphics and
thus show 0x1130 and 0x1132 PCI IDs, right? Help, I'm confused...
> ok, just see the AGP tables bits definition for intel_i815_driver,
> /* Intel registers */
> #define INTEL_APSIZE 0xb4
> #define INTEL_ATTBASE 0xb8
> #define INTEL_AGPCTRL 0xb0
> ...
> And this could explain why your patch can make X come back to live on
> i815, as default suspend saves 64bytes. We need suspend func to handle
> this, but for now mainline intel integrated gfx, this's not needed.
> Would you send out a cleanup patch later?
OK, I'll keep working on this (trying a backup specific to those registers
above).
I suspect that your patch might actually additionally help in my case, too,
but of course I first need my enhanced PCI space backup to prevent it
from locking up.
IOW, your patch might then enable me to skip vbetool hackery entirely
since graphics mode appearance would already be correct.
I'll verify this.
How to transform all this newly-gained knowledge into a *clean* generic
intel-agp driver layer is a different question, though.
Specifically, I'm unsure about all those xxx_configure() calls in the resume
function, this sounds rather unclean to me...
("let's just yank it all back into a clean default state, that will somehow
magically make everything work again after resume")
Andreas Mohr
Hi,
On Tue, Jan 30, 2007 at 08:36:32PM +0800, Wang Zhenyu wrote:
> ok, just see the AGP tables bits definition for intel_i815_driver,
> /* Intel registers */
> #define INTEL_APSIZE 0xb4
> #define INTEL_ATTBASE 0xb8
> #define INTEL_AGPCTRL 0xb0
> ...
> And this could explain why your patch can make X come back to live on
> i815, as default suspend saves 64bytes. We need suspend func to handle
> this, but for now mainline intel integrated gfx, this's not needed.
> Would you send out a cleanup patch later?
OK, I just spent an entire evening on this tiresome procedure
of trying, not quite successful, machine killed, rebooting, adapting,
trying, hang, ...
My conclusions:
- never forget about stup@#$@#$% PCI posting! (hours wasted
due to register values NOT restored after resume...)
- those 3 registers above are not sufficient, since AGP status is
completely broken, not even such basic things as 4x mode or sideband
addressing bits get restored, so these need proper care as well.
- backing up about 10 registers properly (all those that have
different state after resume) makes it work fine without going
over the whole extended PCI register range needlessly
I'm going to spend more time on this, so...:
Questions (in order of fine-grainedness):
- is intel-agp the right place to reinit such things, or should
something be changed in a more global way? Would other drivers
be responsible for that instead? x.org?
- should we have infrastructure available which records AGP state
in all its nicety in various variables, with chipset-specific
access functions (AGP mode, memory setup, ...)?
That way we'd be able to implement one chipset-agnostic
suspend/resume, which could be a heavenly thing
considering the amount of different chipsets...
(IOW, we should perhaps focus on maintaining an abstract device state
tracking, not blindly push those I/O instructions out to the
device and forget about actual device state)
- should we just implement a plain'n stupid I/O register array
for each chipset which denotes the registers that need resume
maintenance and also records their pre-suspend values? (DUMB)
- or even (shudder) simply always recover the entire PCI I/O space
no matter which chipset it is?
I really want to get this improved, so any ideas how it should
best be updated to get a nice clean generic suspend/resume functionality
for all chipsets? (at least Intel, or even better for all types)
And it would be very useful to add a generic function for those
repeated agp_bridge->dev->device == PCI_DEVICE_... checks
which takes a PCI ID array input... (inline or real function, doesn't matter).
Thanks!
Andreas Mohr
Hi,
On Thu, Jan 18, 2007 at 11:16:51PM +0000, Pavel Machek wrote:
> Hi!
>
> > > > 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
>
> Can you post a patch?
Took way longer than I'd have wanted it to (nice daughter and stuff ;),
but here it is.
- add .suspend handler and pci_set_power_state() calls
- add i815-specific function agp_i815_remember_state() to remember important
i815 register values
- add generic DEBUG_AGP_PM framework which will allow people to resume properly
and help identify which registers need attention
- add obvious and detailed log message to make people sit up and take notice
about long-standing AGP resume issues
- spelling fixes
Patch against 2.6.21-rc7-mm2, my Inspiron 8000 (i815 with Radeon AGP card,
internal Intel VGA unit NOT active) resumes fine with both
either i815-specific register saving or generic DEBUG_AGP_PM mechanism enabled.
(of course my notebook needs vbetool post and manual saving of video card
PCI space, too, but even when doing all this I still had X.org lockups before
whenever DRI/3D was enabled)
After resume I'm now still able to run both glxgears and glxinfo without
anomalies.
Right now all I care about is that this gets into mainline relatively soon,
since I'm rather certain that many other machines suffer from similar
AGP resume lockup issues that could be debugged this way (e.g. some Thinkpads,
as witnessed accidentally via IRC chats, and from the well-known "don't enable
DRI, that will lock up on resume!" chants).
Yes, this code is a cludge and somewhat far from a nicely generic
extended PCI space resume framework, but we've spent almost 10 (TEN!) years
without anything even remotely resembling a working cludge for
AGP suspend/resume in combination with DRI, so...
Feel free to offer thoughts on how this missing generic extended PCI space
restore functionality could be implemented, to be used by intel-agp and
various other drivers. No promise that it will be me who implements that,
though ;)
> Whitelist entry would still be welcome.
OK, I'll work on this next.
Thanks!
Signed-off-by: Andreas Mohr <[email protected]>
--- linux-2.6.21-rc7-mm2.orig/drivers/char/agp/intel-agp.c 2007-05-10 14:52:26.000000000 +0200
+++ linux-2.6.21-rc7-mm2/drivers/char/agp/intel-agp.c 2007-05-10 14:31:48.000000000 +0200
@@ -31,9 +31,16 @@
extern int agp_memory_reserved;
-/* Intel 815 register */
-#define INTEL_815_APCONT 0x51
-#define INTEL_815_ATTBASE_MASK ~0x1FFFFFFF
+/* Intel i815 registers, see Intel spec #29068801 */
+#define I815_GMCHCFG 0x50
+#define I815_APCONT 0x51
+#define I815_UNKNOWN_80 0x80
+#define I815_ATTBASE_MASK ~0x1FFFFFFF
+#define I815_SM_RCOMP 0x98 /* Sys Mem R Compensation Ctrl */
+#define I815_SM 0x9c /* System Memory Control Reg */
+#define I815_AGPCMD 0xa8 /* AGP Command Register */
+#define I815_ERRSTS 0xc8 /* undocumented in i815 spec; since this one is modified on resume and many other related chipsets have it, I assume it *is* ERRSTS */
+#define I815_UNKNOWN_E8 0xe8
/* Intel i820 registers */
#define INTEL_I820_RDCR 0x51
@@ -664,7 +671,7 @@
if ((pg_start + mem->page_count) > num_entries)
goto out_err;
- /* The i830 can't check the GTT for entries since its read only,
+ /* The i830 can't check the GTT for entries since it's read-only,
* depend on the caller to make the correct offset decisions.
*/
@@ -787,7 +794,7 @@
if ((pg_start + mem->page_count) > num_entries)
goto out_err;
- /* The i915 can't check the GTT for entries since its read only,
+ /* The i915 can't check the GTT for entries since it's read-only,
* depend on the caller to make the correct offset decisions.
*/
@@ -1103,8 +1110,8 @@
/* attbase - aperture base */
/* the Intel 815 chipset spec. says that bits 29-31 in the
* ATTBASE register are reserved -> try not to write them */
- if (agp_bridge->gatt_bus_addr & INTEL_815_ATTBASE_MASK) {
- printk (KERN_EMERG PFX "gatt bus addr too high");
+ if (agp_bridge->gatt_bus_addr & I815_ATTBASE_MASK) {
+ printk (KERN_EMERG PFX "gatt bus addr too high\n");
return -EINVAL;
}
@@ -1119,7 +1126,7 @@
agp_bridge->gart_bus_addr = (temp & PCI_BASE_ADDRESS_MEM_MASK);
pci_read_config_dword(agp_bridge->dev, INTEL_ATTBASE, &addr);
- addr &= INTEL_815_ATTBASE_MASK;
+ addr &= I815_ATTBASE_MASK;
addr |= agp_bridge->gatt_bus_addr;
pci_write_config_dword(agp_bridge->dev, INTEL_ATTBASE, addr);
@@ -1127,8 +1134,8 @@
pci_write_config_dword(agp_bridge->dev, INTEL_AGPCTRL, 0x0000);
/* apcont */
- pci_read_config_byte(agp_bridge->dev, INTEL_815_APCONT, &temp2);
- pci_write_config_byte(agp_bridge->dev, INTEL_815_APCONT, temp2 | (1 << 1));
+ pci_read_config_byte(agp_bridge->dev, I815_APCONT, &temp2);
+ pci_write_config_byte(agp_bridge->dev, I815_APCONT, temp2 | (1 << 1));
/* clear any possible error conditions */
/* Oddness : this chipset seems to have no ERRSTS register ! */
@@ -1355,7 +1362,7 @@
pci_write_config_dword(agp_bridge->dev, INTEL_ATTBASE, agp_bridge->gatt_bus_addr);
/* agpctrl */
- pci_write_config_dword(agp_bridge->dev, INTEL_AGPCTRL, 0x0000);
+ pci_write_config_dword(agp_bridge->dev, INTEL_AGPCTRL, 0x00000000);
/* mchcfg */
pci_read_config_word(agp_bridge->dev, INTEL_I7505_MCHCFG, &temp2);
@@ -2011,12 +2018,178 @@
}
#ifdef CONFIG_PM
+
+static int agp_i815_remember_state(struct pci_dev *pdev, int restore)
+{
+ typedef struct {
+ int reg;
+ u32 value;
+ } saved_regs;
+
+ /* Dell Inspiron 8000 BIOS rev. A23 needs the following registers saved
+ * to be able to successfully restore X11 when AGP 3D is enabled
+ * (register values given are after resume vs. before suspend):
+ *
+ * I815_GMCHCFG (0x50; we need to set bit 1 (Aperture Access Global Enable) of I815_APCONT (0x51),
+ * thus use I815_GMCHCFG (0x50) as 32bit base register); 0x4fdd0040 instead of 0x4fdd0240
+ * ??? (0x80); 0x07ce1cde instead of 0x07cb94de
+ * I815_SM_RCOMP (0x98); 0x80648064 instead of 0x80548054
+ * I815_SM (0x9c); 0x00c48405 instead of 0x04848405
+ * I815_AGPCMD (0xa8); 0x00000000 instead of 0x00000304
+ * INTEL_AGPCTRL (0xb0); 0x00000000 instead of 0x00000080
+ * INTEL_APSIZE (0xb4);
+ * INTEL_ATTBASE (0xb8); 0x00000000 instead of 0x024b0000
+ * I815_ERRSTS?? (0xc8; undocumented for i815, see above); 0x00000000 instead of 0x00000800
+ * ??? (0xe8); 0x1c700000 instead of 0x18500000
+ *
+ * Other machines/chipsets/BIOS versions may require
+ * a different set of registers to be properly saved.
+ */
+ static saved_regs i815_saved_regs[] = {
+ { I815_UNKNOWN_80, 0 },
+ { I815_GMCHCFG, 0 },
+ { I815_SM_RCOMP, 0 },
+ { I815_SM, 0 },
+ { I815_AGPCMD, 0 },
+ { INTEL_AGPCTRL, 0 },
+ { INTEL_APSIZE, 0 },
+ { INTEL_ATTBASE, 0 },
+ { I815_ERRSTS, 0 },
+ { I815_UNKNOWN_E8, 0 },
+ { 0, 0 }, /* DELIMITER */
+ };
+ saved_regs *p;
+
+ if (restore) {
+ u32 val;
+ for (p = i815_saved_regs; (p->reg != 0); p++)
+ {
+ pci_read_config_dword(pdev, p->reg, &val);
+ if (val != p->value) {
+ printk(KERN_DEBUG "AGP: Writing back config space on "
+ "device %s at offset %x (was %x, writing %x)\n",
+ pci_name(pdev), p->reg,
+ val, p->value);
+ pci_write_config_dword(pdev, p->reg,
+ p->value);
+ }
+ }
+ } else {
+ for (p = i815_saved_regs; (p->reg != 0); p++)
+ pci_read_config_dword(pdev, p->reg, &p->value);
+ }
+ return 1;
+}
+
+/*
+ * set DEBUG_AGP_PM to 1 if your AGP chipset has issues resuming
+ * (machine lockups due to non-restored hardware registered values),
+ * then figure out from the log which registers have to be restored manually,
+ * then add specific support for your chipset, similar to what already exists
+ * for i815 (Dell Inspiron) above.
+ * E.g. IBM X31 (i855PM) seems to still have intel-agp suspend issues, too.
+ *
+ * Once it's obvious which chipsets need which treatment
+ * (this is an important step to gain knowledge about all chipsets!)
+ * this stop-gap code handling (we need something that works NOW,
+ * since we could have had it almost a decade ago already!)
+ * should be cleaned up, probably by implementing a generic Linux
+ * PCI function to save/restore extended PCI config space
+ * by supplying a register array or so...
+ * At this point, it would also be nice to clean up the _suspend()/_resume() functions
+ * to use some non-ugly and nicely generic restore mechanism.
+ */
+#define DEBUG_AGP_PM 0
+
+#if DEBUG_AGP_PM
+static u32 pci_cfg_space[64];
+
+static void agp_intel_suspend_debug(struct pci_dev *pdev, pm_message_t state)
+{
+ int i;
+ for (i = 63; i >= 0; i--)
+ pci_read_config_dword(pdev, i * 4, &pci_cfg_space[i]);
+}
+
+static void agp_intel_resume_debug(struct pci_dev *pdev)
+{
+ int i;
+ int val;
+
+ /* Try first reading main PCI config space, then extended space;
+ * this order should hopefully prevent any lockups that may easily
+ * occur otherwise.
+ */
+ for (i = 15; i >= 0; i--) {
+ pci_read_config_dword(pdev, i * 4, &val);
+ if (val != pci_cfg_space[i]) {
+ /* Who the *** decided (in PM code) that logging
+ * register offsets in very weird offset notation
+ * (extremely uncommon in PCI datasheet spheres) was a good idea?
+ * Fixing this in this AGP-specific log message by multiplying offsets
+ */
+ int reg = i * sizeof(u32);
+ printk(KERN_DEBUG "AGP: Writing back config space on "
+ "device %s at offset %x (was %x, writing %x)\n",
+ pci_name(pdev), reg,
+ val, pci_cfg_space[i]);
+ pci_write_config_dword(pdev, reg,
+ pci_cfg_space[i]);
+ }
+ }
+ for (i = 63; i >= 16; i--) {
+ pci_read_config_dword(pdev, i * 4, &val);
+ if (val != pci_cfg_space[i]) {
+ int reg = i * sizeof(u32);
+ printk(KERN_DEBUG "AGP: Writing back config space on "
+ "device %s at offset %x (was %x, writing %x)\n",
+ pci_name(pdev), reg,
+ val, pci_cfg_space[i]);
+ pci_write_config_dword(pdev, reg,
+ pci_cfg_space[i]);
+ }
+ }
+}
+#else
+static inline void agp_intel_suspend_debug(struct pci_dev *pdev, pm_message_t state) { }
+static inline void agp_intel_resume_debug(struct pci_dev *pdev) { }
+#endif /* DEBUG_AGP_PM */
+
+
+static int agp_intel_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+ struct agp_bridge_data *bridge = pci_get_drvdata(pdev);
+
+ if (bridge->driver == &intel_815_driver)
+ agp_i815_remember_state(pdev, 0);
+
+ agp_intel_suspend_debug(pdev, state);
+
+ pci_save_state(pdev);
+ pci_set_power_state(pdev, pci_choose_state(pdev, state));
+
+ return 0;
+}
+
static int agp_intel_resume(struct pci_dev *pdev)
{
struct agp_bridge_data *bridge = pci_get_drvdata(pdev);
+ /* This ought to be enough meat in here to let us
+ * resume successfully, at least when also being helped
+ * by additional manual /sys/bus/pci/DEVICE recovering
+ * of the graphics card and "vbetool post"
+ * (the s2ram tool should do this nicely already)
+ */
+
+ pci_set_power_state (pdev, PCI_D0);
pci_restore_state(pdev);
+ agp_intel_resume_debug(pdev);
+
+ if (bridge->driver == &intel_815_driver)
+ agp_i815_remember_state(pdev, 1);
+
/* We should restore our graphics device's config space,
* as host bridge (00:00) resumes before graphics device (02:00),
* then our access to its pci space can work right.
@@ -2038,6 +2211,8 @@
intel_i915_configure();
else if (bridge->driver == &intel_830_driver)
intel_i830_configure();
+ /* Please no entry for i815 here since it already has
+ * specific resume support above */
else if (bridge->driver == &intel_810_driver)
intel_i810_configure();
else if (bridge->driver == &intel_i965_driver)
@@ -2045,7 +2220,7 @@
return 0;
}
-#endif
+#endif /* CONFIG_PM */
static struct pci_device_id agp_intel_pci_table[] = {
#define ID(x) \
@@ -2098,6 +2273,7 @@
.probe = agp_intel_probe,
.remove = __devexit_p(agp_intel_remove),
#ifdef CONFIG_PM
+ .suspend = agp_intel_suspend,
.resume = agp_intel_resume,
#endif
};
@@ -2106,6 +2282,12 @@
{
if (agp_off)
return -EINVAL;
+ /* let people know that this is an important place to investigate at in case of resume lockups */
+ printk(KERN_INFO PFX
+ "suspend/resume of intel-agp.ko is NOT always stable for all Intel AGP\n"
+ "chipset/BIOS combos, may cause resume lockups when DRI (3D accel) active,\n"
+ "in AGP (non-PCI) mode! (see DEBUG_AGP_PM in intel-agp.c source to investigate)\n"
+ );
return pci_register_driver(&agp_intel_pci_driver);
}
Hi!
> > > > > 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
> >
> > Can you post a patch?
>
> Took way longer than I'd have wanted it to (nice daughter and stuff ;),
> but here it is.
No problem.
Ok, I guess we'll need a real commit log.
> #define INTEL_I820_RDCR 0x51
> @@ -664,7 +671,7 @@
> if ((pg_start + mem->page_count) > num_entries)
> goto out_err;
>
> - /* The i830 can't check the GTT for entries since its read only,
> + /* The i830 can't check the GTT for entries since it's read-only,
> * depend on the caller to make the correct offset decisions.
> */
>
> @@ -787,7 +794,7 @@
> if ((pg_start + mem->page_count) > num_entries)
> goto out_err;
>
> - /* The i915 can't check the GTT for entries since its read only,
> + /* The i915 can't check the GTT for entries since it's read-only,
> * depend on the caller to make the correct offset decisions.
> */
>
You should not do cleanups at the same time as code changes.
> @@ -1103,8 +1110,8 @@
> /* attbase - aperture base */
> /* the Intel 815 chipset spec. says that bits 29-31 in the
> * ATTBASE register are reserved -> try not to write them */
> - if (agp_bridge->gatt_bus_addr & INTEL_815_ATTBASE_MASK) {
> - printk (KERN_EMERG PFX "gatt bus addr too high");
> + if (agp_bridge->gatt_bus_addr & I815_ATTBASE_MASK) {
> + printk (KERN_EMERG PFX "gatt bus addr too high\n");
> return -EINVAL;
> }
>
> @@ -1119,7 +1126,7 @@
> agp_bridge->gart_bus_addr = (temp & PCI_BASE_ADDRESS_MEM_MASK);
>
> pci_read_config_dword(agp_bridge->dev, INTEL_ATTBASE, &addr);
> - addr &= INTEL_815_ATTBASE_MASK;
> + addr &= I815_ATTBASE_MASK;
> addr |= agp_bridge->gatt_bus_addr;
> pci_write_config_dword(agp_bridge->dev, INTEL_ATTBASE, addr);
And I guess macro search&replace counts as cleanup, too. It would be
nice to submit them separately and first.
> @@ -1355,7 +1362,7 @@
> pci_write_config_dword(agp_bridge->dev, INTEL_ATTBASE, agp_bridge->gatt_bus_addr);
>
> /* agpctrl */
> - pci_write_config_dword(agp_bridge->dev, INTEL_AGPCTRL, 0x0000);
> + pci_write_config_dword(agp_bridge->dev, INTEL_AGPCTRL, 0x00000000);
>
Huh?
> #ifdef CONFIG_PM
> +
I'd kill this empty line.
> +static int agp_i815_remember_state(struct pci_dev *pdev, int restore)
> +{
> + typedef struct {
> + int reg;
> + u32 value;
> + } saved_regs;
> +
> + /* Dell Inspiron 8000 BIOS rev. A23 needs the following registers saved
> + * to be able to successfully restore X11 when AGP 3D is enabled
> + * (register values given are after resume vs. before suspend):
> + *
> + * I815_GMCHCFG (0x50; we need to set bit 1 (Aperture Access Global Enable) of I815_APCONT (0x51),
> + * thus use I815_GMCHCFG (0x50) as 32bit base register); 0x4fdd0040 instead of 0x4fdd0240
> + * ??? (0x80); 0x07ce1cde instead of 0x07cb94de
> + * I815_SM_RCOMP (0x98); 0x80648064 instead of 0x80548054
> + * I815_SM (0x9c); 0x00c48405 instead of 0x04848405
> + * I815_AGPCMD (0xa8); 0x00000000 instead of 0x00000304
> + * INTEL_AGPCTRL (0xb0); 0x00000000 instead of 0x00000080
> + * INTEL_APSIZE (0xb4);
> + * INTEL_ATTBASE (0xb8); 0x00000000 instead of 0x024b0000
> + * I815_ERRSTS?? (0xc8; undocumented for i815, see above); 0x00000000 instead of 0x00000800
> + * ??? (0xe8); 0x1c700000 instead of 0x18500000
> + *
> + * Other machines/chipsets/BIOS versions may require
> + * a different set of registers to be properly saved.
> + */
> + static saved_regs i815_saved_regs[] = {
> + { I815_UNKNOWN_80, 0 },
> + { I815_GMCHCFG, 0 },
> + { I815_SM_RCOMP, 0 },
> + { I815_SM, 0 },
> + { I815_AGPCMD, 0 },
> + { INTEL_AGPCTRL, 0 },
> + { INTEL_APSIZE, 0 },
> + { INTEL_ATTBASE, 0 },
> + { I815_ERRSTS, 0 },
> + { I815_UNKNOWN_E8, 0 },
> + { 0, 0 }, /* DELIMITER */
> + };
> + saved_regs *p;
> +
> + if (restore) {
> + u32 val;
> + for (p = i815_saved_regs; (p->reg != 0); p++)
> + {
This goes to previous line. ";p->reg ;" is enough.
> + pci_read_config_dword(pdev, p->reg, &val);
> + if (val != p->value) {
> + printk(KERN_DEBUG "AGP: Writing back config space on "
> + "device %s at offset %x (was %x, writing %x)\n",
> + pci_name(pdev), p->reg,
> + val, p->value);
> + pci_write_config_dword(pdev, p->reg,
> + p->value);
> + }
> + }
> + } else {
> + for (p = i815_saved_regs; (p->reg != 0); p++)
Same here.
> + pci_read_config_dword(pdev, p->reg, &p->value);
> + }
> + return 1;
> +}
Should this betwo functions, one for save, one for restore, with "to
save" array being global?
> +/*
> + * set DEBUG_AGP_PM to 1 if your AGP chipset has issues resuming
> + * (machine lockups due to non-restored hardware registered values),
> + * then figure out from the log which registers have to be restored manually,
> + * then add specific support for your chipset, similar to what already exists
Can we get debugging stuff separately?
> @@ -2106,6 +2282,12 @@
> {
> if (agp_off)
> return -EINVAL;
> + /* let people know that this is an important place to investigate at in case of resume lockups */
> + printk(KERN_INFO PFX
> + "suspend/resume of intel-agp.ko is NOT always stable for all Intel AGP\n"
> + "chipset/BIOS combos, may cause resume lockups when DRI (3D accel) active,\n"
> + "in AGP (non-PCI) mode! (see DEBUG_AGP_PM in intel-agp.c source to investigate)\n"
> + );
I'm not sure if we want such big/ugly warnings. Can you get it to one
line, at least?
Otherwise it looks ok.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wed, May 02, 2007 at 12:17:18PM +0200, Pavel Machek wrote:
> > #define INTEL_I820_RDCR 0x51
> > @@ -664,7 +671,7 @@
> > if ((pg_start + mem->page_count) > num_entries)
> > goto out_err;
> >
> > - /* The i830 can't check the GTT for entries since its read only,
> > + /* The i830 can't check the GTT for entries since it's read-only,
> > * depend on the caller to make the correct offset decisions.
> > */
> >
> > @@ -787,7 +794,7 @@
> > if ((pg_start + mem->page_count) > num_entries)
> > goto out_err;
> >
> > - /* The i915 can't check the GTT for entries since its read only,
> > + /* The i915 can't check the GTT for entries since it's read-only,
> > * depend on the caller to make the correct offset decisions.
> > */
>
> You should not do cleanups at the same time as code changes.
Indeed.
> > @@ -1103,8 +1110,8 @@
> > /* attbase - aperture base */
> > /* the Intel 815 chipset spec. says that bits 29-31 in the
> > * ATTBASE register are reserved -> try not to write them */
> > - if (agp_bridge->gatt_bus_addr & INTEL_815_ATTBASE_MASK) {
> > - printk (KERN_EMERG PFX "gatt bus addr too high");
> > + if (agp_bridge->gatt_bus_addr & I815_ATTBASE_MASK) {
> > + printk (KERN_EMERG PFX "gatt bus addr too high\n");
> > return -EINVAL;
> > }
> >
> > @@ -1119,7 +1126,7 @@
> > agp_bridge->gart_bus_addr = (temp & PCI_BASE_ADDRESS_MEM_MASK);
> >
> > pci_read_config_dword(agp_bridge->dev, INTEL_ATTBASE, &addr);
> > - addr &= INTEL_815_ATTBASE_MASK;
> > + addr &= I815_ATTBASE_MASK;
> > addr |= agp_bridge->gatt_bus_addr;
> > pci_write_config_dword(agp_bridge->dev, INTEL_ATTBASE, addr);
>
> And I guess macro search&replace counts as cleanup, too. It would be
> nice to submit them separately and first.
I'm not a big fan of the s/INTEL_/I_/ change to be honest.
I'd prefer we didn't change this, as a) there may be additional
patches in flight which touch intel-agp.c depending on those defines,
b) it'll make future changes to intel-agp.c harder to backport to
-stable releases, and c) it doesn't really add any value.
> > @@ -1355,7 +1362,7 @@
> > pci_write_config_dword(agp_bridge->dev, INTEL_ATTBASE, agp_bridge->gatt_bus_addr);
> >
> > /* agpctrl */
> > - pci_write_config_dword(agp_bridge->dev, INTEL_AGPCTRL, 0x0000);
> > + pci_write_config_dword(agp_bridge->dev, INTEL_AGPCTRL, 0x00000000);
>
> Huh?
harmless, but ok.
> > + pci_read_config_dword(pdev, p->reg, &p->value);
> > + }
> > + return 1;
> > +}
>
> Should this betwo functions, one for save, one for restore, with "to
> save" array being global?
yes.
> > +/*
> > + * set DEBUG_AGP_PM to 1 if your AGP chipset has issues resuming
> > + * (machine lockups due to non-restored hardware registered values),
> > + * then figure out from the log which registers have to be restored manually,
> > + * then add specific support for your chipset, similar to what already exists
>
> Can we get debugging stuff separately?
ACK.
> > @@ -2106,6 +2282,12 @@
> > {
> > if (agp_off)
> > return -EINVAL;
> > + /* let people know that this is an important place to investigate at in case of resume lockups */
> > + printk(KERN_INFO PFX
> > + "suspend/resume of intel-agp.ko is NOT always stable for all Intel AGP\n"
> > + "chipset/BIOS combos, may cause resume lockups when DRI (3D accel) active,\n"
> > + "in AGP (non-PCI) mode! (see DEBUG_AGP_PM in intel-agp.c source to investigate)\n"
> > + );
>
> I'm not sure if we want such big/ugly warnings. Can you get it to one
> line, at least?
I'd drop this completely. The majority of users will never see it anyway,
and the boot process already spews so much stuff that it'll just get lost
in the noise.
Thanks,
Dave
--
http://www.codemonkey.org.uk
[dri-devel added]
Hi,
On Wed, May 02, 2007 at 12:17:18PM +0200, Pavel Machek wrote:
> > Took way longer than I'd have wanted it to (nice daughter and stuff ;),
> > but here it is.
>
> No problem.
>
> Ok, I guess we'll need a real commit log.
Thanks to all the people who replied and sent some suggestions!
Due to the "scathing" (well, thorough ;) code review I'll send a patch
with those cleanups against 2.6.21-mm1 very soon.
(I was actually a bit surprised to see akpm commit this thing after this
review mail, but it's ok since it lets people experiment with it).
Thanks!
Andreas Mohr
Hi,
On Sat, May 05, 2007 at 07:56:05PM +0200, Andreas Mohr wrote:
> Due to the "scathing" (well, thorough ;) code review I'll send a patch
> with those cleanups against 2.6.21-mm1 very soon.
working 3D/DRI intel-agp.ko resume for i815 chip cleanup patch:
- revert register define name change to ease backporting etc.
- shorten resume issues warning message to two lines while still preserving
all required information (use many shorter words)
I'm not ultimately sure about the register define names, since there's
a general inconsistency in naming here which perhaps would be a good idea
to resolve (my original renaming happened to decrease inconsistency but didn't
quite get rid of it, so it was kind of useless to do it...).
The warning message, while definitely ugly (and that's its job ;), IMHO is
very important to make knowledgeable people see where the problem is.
Those people, if they experience issues, WILL look at kernel logs...
Splitting the remember_state function in two parts isn't very useful given
that it's supposed to be a temporary, "make it work at all" measure only
until there's generic save/restore support (I want to keep this "debug"
code at a minimum). Once there's further chipset data and/or information
how to implement this cleanly, I'm definitely interested in continuing that.
Run-tested on 2.6.21-mm2, resumes fine.
Signed-off-by: Andreas Mohr <[email protected]>
--- linux-2.6.21-mm2/drivers/char/agp/intel-agp.c 2007-05-19 06:25:00.000000000 +0200
+++ linux-2.6.21-mm2.agp/drivers/char/agp/intel-agp.c 2007-05-19 06:23:51.000000000 +0200
@@ -32,15 +32,15 @@
/* Intel i815 registers, see Intel spec #29068801 */
-#define I815_GMCHCFG 0x50
-#define I815_APCONT 0x51
-#define I815_UNKNOWN_80 0x80
-#define I815_ATTBASE_MASK ~0x1FFFFFFF
-#define I815_SM_RCOMP 0x98 /* Sys Mem R Compensation Ctrl */
-#define I815_SM 0x9c /* System Memory Control Reg */
-#define I815_AGPCMD 0xa8 /* AGP Command Register */
-#define I815_ERRSTS 0xc8 /* undocumented in i815 spec; since this one is modified on resume and many other related chipsets have it, I assume it *is* ERRSTS */
-#define I815_UNKNOWN_E8 0xe8
+#define INTEL_I815_GMCHCFG 0x50
+#define INTEL_I815_APCONT 0x51
+#define INTEL_I815_UNKNOWN_80 0x80
+#define INTEL_I815_ATTBASE_MASK ~0x1FFFFFFF
+#define INTEL_I815_SM_RCOMP 0x98 /* Sys Mem R Compensation Ctrl */
+#define INTEL_I815_SM 0x9c /* System Memory Control Reg */
+#define INTEL_I815_AGPCMD 0xa8 /* AGP Command Register */
+#define INTEL_I815_ERRSTS 0xc8 /* undocumented in i815 spec; since this one is modified on resume and many other related chipsets have it, I assume it *is* ERRSTS */
+#define INTEL_I815_UNKNOWN_E8 0xe8
/* Intel i820 registers */
#define INTEL_I820_RDCR 0x51
@@ -1110,7 +1110,7 @@
/* attbase - aperture base */
/* the Intel 815 chipset spec. says that bits 29-31 in the
* ATTBASE register are reserved -> try not to write them */
- if (agp_bridge->gatt_bus_addr & I815_ATTBASE_MASK) {
+ if (agp_bridge->gatt_bus_addr & INTEL_I815_ATTBASE_MASK) {
printk (KERN_EMERG PFX "gatt bus addr too high\n");
return -EINVAL;
}
@@ -1126,7 +1126,7 @@
agp_bridge->gart_bus_addr = (temp & PCI_BASE_ADDRESS_MEM_MASK);
pci_read_config_dword(agp_bridge->dev, INTEL_ATTBASE, &addr);
- addr &= I815_ATTBASE_MASK;
+ addr &= INTEL_I815_ATTBASE_MASK;
addr |= agp_bridge->gatt_bus_addr;
pci_write_config_dword(agp_bridge->dev, INTEL_ATTBASE, addr);
@@ -1134,8 +1134,8 @@
pci_write_config_dword(agp_bridge->dev, INTEL_AGPCTRL, 0x0000);
/* apcont */
- pci_read_config_byte(agp_bridge->dev, I815_APCONT, &temp2);
- pci_write_config_byte(agp_bridge->dev, I815_APCONT, temp2 | (1 << 1));
+ pci_read_config_byte(agp_bridge->dev, INTEL_I815_APCONT, &temp2);
+ pci_write_config_byte(agp_bridge->dev, INTEL_I815_APCONT, temp2 | (1 << 1));
/* clear any possible error conditions */
/* Oddness : this chipset seems to have no ERRSTS register ! */
@@ -2018,7 +2018,6 @@
}
#ifdef CONFIG_PM
-
static int agp_i815_remember_state(struct pci_dev *pdev, int restore)
{
typedef struct {
@@ -2030,18 +2029,18 @@
* to be able to successfully restore X11 when AGP 3D is enabled
* (register values given are after resume vs. before suspend):
*
- * I815_GMCHCFG (0x50; we need to set bit 1 (Aperture Access Global
- * Enable) of I815_APCONT (0x51),
- * thus use I815_GMCHCFG (0x50) as 32bit base register);
+ * INTEL_I815_GMCHCFG (0x50; we need to set bit 1
+ * (Aperture Access Global Enable) of INTEL_I815_APCONT (0x51),
+ * thus use INTEL_I815_GMCHCFG (0x50) as 32bit base register);
* 0x4fdd0040 instead of 0x4fdd0240
* ??? (0x80); 0x07ce1cde instead of 0x07cb94de
- * I815_SM_RCOMP (0x98); 0x80648064 instead of 0x80548054
- * I815_SM (0x9c); 0x00c48405 instead of 0x04848405
- * I815_AGPCMD (0xa8); 0x00000000 instead of 0x00000304
+ * INTEL_I815_SM_RCOMP (0x98); 0x80648064 instead of 0x80548054
+ * INTEL_I815_SM (0x9c); 0x00c48405 instead of 0x04848405
+ * INTEL_I815_AGPCMD (0xa8); 0x00000000 instead of 0x00000304
* INTEL_AGPCTRL (0xb0); 0x00000000 instead of 0x00000080
* INTEL_APSIZE (0xb4);
* INTEL_ATTBASE (0xb8); 0x00000000 instead of 0x024b0000
- * I815_ERRSTS?? (0xc8; undocumented for i815, see above);
+ * INTEL_I815_ERRSTS?? (0xc8; undocumented for i815, see above);
* 0x00000000 instead of 0x00000800
* ??? (0xe8); 0x1c700000 instead of 0x18500000
*
@@ -2049,23 +2048,23 @@
* a different set of registers to be properly saved.
*/
static saved_regs i815_saved_regs[] = {
- { I815_UNKNOWN_80, 0 },
- { I815_GMCHCFG, 0 },
- { I815_SM_RCOMP, 0 },
- { I815_SM, 0 },
- { I815_AGPCMD, 0 },
+ { INTEL_I815_UNKNOWN_80, 0 },
+ { INTEL_I815_GMCHCFG, 0 },
+ { INTEL_I815_SM_RCOMP, 0 },
+ { INTEL_I815_SM, 0 },
+ { INTEL_I815_AGPCMD, 0 },
{ INTEL_AGPCTRL, 0 },
{ INTEL_APSIZE, 0 },
{ INTEL_ATTBASE, 0 },
- { I815_ERRSTS, 0 },
- { I815_UNKNOWN_E8, 0 },
+ { INTEL_I815_ERRSTS, 0 },
+ { INTEL_I815_UNKNOWN_E8, 0 },
{ 0, 0 }, /* DELIMITER */
};
saved_regs *p;
if (restore) {
u32 val;
- for (p = i815_saved_regs; (p->reg != 0); p++) {
+ for (p = i815_saved_regs; p->reg; p++) {
pci_read_config_dword(pdev, p->reg, &val);
if (val != p->value) {
printk(KERN_DEBUG "AGP: Writing back config "
@@ -2078,7 +2077,7 @@
}
}
} else {
- for (p = i815_saved_regs; (p->reg != 0); p++)
+ for (p = i815_saved_regs; p->reg; p++)
pci_read_config_dword(pdev, p->reg, &p->value);
}
return 1;
@@ -2285,11 +2284,16 @@
{
if (agp_off)
return -EINVAL;
- /* let people know that this is an important place to investigate at in case of resume lockups */
+
+ /* let people know that this is an important place to investigate at
+ * in case of resume lockups.
+ * Let's hope we'll be able to kill this message in mid-2008 or so
+ * once all/most problematic Intel chipset cases have proper 3D resume
+ * after users reported details.
+ */
printk(KERN_INFO PFX
- "suspend/resume of intel-agp.ko is NOT always stable for all Intel AGP\n"
- "chipset/BIOS combos, may cause resume lockups when DRI (3D accel) active,\n"
- "in AGP (non-PCI) mode! (see DEBUG_AGP_PM in intel-agp.c source to investigate)\n"
+ "suspend/resume problematic: resume with 3D/DRI active may lockup X.Org\n"
+ "on some chipset/BIOS combos (see DEBUG_AGP_PM in intel-agp.c)\n"
);
return pci_register_driver(&agp_intel_pci_driver);
}