2.6.20-rc5: usb mouse breaks suspend to ram

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.

Quoted 7 lines

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?

Hi!

Quoted 9 lines

Quoted 7 lines

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?

Quoted 13 lines

Quoted 9 lines

Quoted 7 lines

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

Quoted 3 lines

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 ;(

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...?!

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 ;(

Quoted 3 lines

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).

Quoted 3 lines

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.

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).

Quoted 7 lines

Quoted 3 lines

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

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*

Hi!

Quoted 10 lines

Quoted 7 lines

Quoted 3 lines

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!

Quoted 7 lines

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.

Quoted 2 lines

All in all intel-agp code semi-shattered my universe.
I didn't expect to find all these issues in rather important core code

...

Quoted 2 lines

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

Quoted 10 lines

Quoted 9 lines

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

Quoted 1 line

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.

Quoted 4 lines

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

Hi!

Quoted 12 lines

Quoted 11 lines

Quoted 9 lines

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?

Quoted 4 lines

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...

Quoted 2 lines

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.

Quoted 6 lines

Quoted 2 lines

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?

Quoted 9 lines · Pavel Machek

Quoted 6 lines

Quoted 2 lines

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.

drivers/char/agp/intel-agp.c +0 -0

index ab0a9c0..f64a115 100644
@@ -1955,6 +1955,15 @@ static int agp_intel_resume(struct pci_d
 

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.

Quoted 4 lines

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...

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?

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, 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?

Hi!

Quoted 10 lines

Quoted 7 lines

Quoted 3 lines

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!

Quoted 7 lines

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.

Quoted 18 lines

Quoted 17 lines

Quoted 7 lines

Quoted 3 lines

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

Quoted 1 line

Can you post a patch?

Took way longer than I'd have wanted it to (nice daughter and stuff ;), but here it is.

#define INTEL_I820_RDCR 0x51

drivers/char/agp/intel-agp.c +1 -1

@@ -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.
 	 */
 

drivers/char/agp/intel-agp.c +2 -2

@@ -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;
 	}
 

drivers/char/agp/intel-agp.c +35 -0

+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 },

+/*
+ * 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

Quoted 14 lines

#define INTEL_I820_RDCR 0x51

drivers/char/agp/intel-agp.c +1 -1

@@ -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;
 

drivers/char/agp/intel-agp.c line 799

Quoted 4 lines

drivers/char/agp/intel-agp.c +1 -1

-	/* 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.

Quoted 14 lines

drivers/char/agp/intel-agp.c +2 -2

@@ -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);
 

drivers/char/agp/intel-agp.c line 1131

Quoted 5 lines

drivers/char/agp/intel-agp.c +1 -1

 	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.

drivers/char/agp/intel-agp.c line 1365

Quoted 6 lines

drivers/char/agp/intel-agp.c +1 -1

@@ -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?

drivers/char/agp/intel-agp.c line 2082

Quoted 4 lines

drivers/char/agp/intel-agp.c +4 -0

+			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?

Quoted 5 lines

+/*
+ * 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?

Quoted 5 lines

drivers/char/agp/intel-agp.c +1 -0

@@ -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 */

drivers/char/agp/intel-agp.c line 2290

Quoted 5 lines

drivers/char/agp/intel-agp.c +5 -0

+	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?

Quoted 2 lines

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.

Due to the "scathing" (well, thorough ;) code review I'll send a patch with those cleanups against 2.6.21-mm1 very soon.