Re: 2.6.9-rc2-mm3: swsusp horribly slow on AMD64
From: Pavel Machek (pavel_at_suse.cz)
Date: 09/27/04
- Previous message: Frank van Maarseveen: "Re: NFS TUNING: #define NFS3_MAXGROUPS"
- In reply to: Rafael J. Wysocki: "Re: 2.6.9-rc2-mm3: swsusp horribly slow on AMD64"
- Next in thread: Rafael J. Wysocki: "Re: 2.6.9-rc2-mm3: swsusp horribly slow on AMD64"
- Reply: Rafael J. Wysocki: "Re: 2.6.9-rc2-mm3: swsusp horribly slow on AMD64"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 27 Sep 2004 00:33:51 +0200 To: "Rafael J. Wysocki" <rjw@sisk.pl>
Hi!
> --- pci-driver.c 2004-09-26 23:35:32.701574416 +0200
> +++ pci-driver.c.rjw 2004-09-26 23:35:18.441742240 +0200
> @@ -328,6 +328,7 @@
> */
> static void pci_default_resume(struct pci_dev *pci_dev)
> {
> + printk("pci_default_resume (0x%04x, 0x%04x): %ld\n", pci_dev->vendor,
> pci_dev->device, jiffies/HZ);
> /* restore the PCI config space */
> pci_restore_state(pci_dev, pci_dev->saved_config_space);
> /* if the device was enabled before suspend, reenable */
> @@ -343,6 +344,7 @@
> struct pci_dev * pci_dev = to_pci_dev(dev);
> struct pci_driver * drv = pci_dev->driver;
>
> + printk("pci_device_resume (0x%04x, 0x%04x): %ld\n", pci_dev->vendor,
> pci_dev->device, jiffies/HZ);
> if (drv && drv->resume)
> drv->resume(pci_dev);
> else
>
> in order to identify the offending device. I'm now almost sure that the
> NVidia chipset is to blame but I don't know which part of it exactly.
>
> I've got two logs (attached), one of which is taken from the system with all
> modules loaded (swsusp.log), and the other comes from the system with no
> modules except for ipv6 (swsusp-nomod.log). As you can see from the first
> log, the system with all modules loaded slows down significantly after
> pci_device_resume() is called for the device having vendor id = 0x10de
> (NVidia) and device id = 0x00d7 (no idea). The system without modules is
lspci, and take a look?
> capable of writing 80-83% of pages to the swap _before_ slows down too and I
> have to wait for 1/2 h for the remaining ~20%.
Strange, *very* strange.
> I'm afraid I can't get any more info until I sort out the sysrq
> problem.
This should remap magic key to both-shifts-both-alts-key. Worked for
me once...
Pavel
--- clean-mm/drivers/char/keyboard.c 2004-09-26 01:34:24.000000000 +0200
+++ linux-mm/drivers/char/keyboard.c 2004-09-26 01:42:24.000000000 +0200
@@ -1079,6 +1079,23 @@
sysrq_down = down;
return;
}
+ if (test_bit(KEY_LEFTALT, key_down) &&
+ test_bit(KEY_RIGHTALT, key_down) &&
+ test_bit(KEY_LEFTSHIFT, key_down) &&
+ test_bit(KEY_RIGHTSHIFT, key_down) &&
+ down && !rep) {
+ handle_sysrq(kbd_sysrq_xlate[keycode], regs, tty);
+#ifdef CONFIG_KGDB_SYSRQ
+ sysrq_down = 0; /* in case we miss the "up" event */
+#endif
+ return;
+ }
+
+ if (down)
+ set_bit(keycode, key_down);
+ else
+ clear_bit(keycode, key_down);
+
if (sysrq_down && down && !rep) {
handle_sysrq(kbd_sysrq_xlate[keycode], regs, tty);
#ifdef CONFIG_KGDB_SYSRQ
@@ -1114,11 +1131,6 @@
raw_mode = 1;
}
- if (down)
- set_bit(keycode, key_down);
- else
- clear_bit(keycode, key_down);
-
if (rep && (!vc_kbd_mode(kbd, VC_REPEAT) || (tty &&
(!L_ECHO(tty) && tty->driver->chars_in_buffer(tty))))) {
/*
-- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Frank van Maarseveen: "Re: NFS TUNING: #define NFS3_MAXGROUPS"
- In reply to: Rafael J. Wysocki: "Re: 2.6.9-rc2-mm3: swsusp horribly slow on AMD64"
- Next in thread: Rafael J. Wysocki: "Re: 2.6.9-rc2-mm3: swsusp horribly slow on AMD64"
- Reply: Rafael J. Wysocki: "Re: 2.6.9-rc2-mm3: swsusp horribly slow on AMD64"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
