Re: [linux-pm] Re: swsusp 'disk' fails in bk-current - intel_agp at fault?

From: Nigel Cunningham (ncunningham_at_cyclades.com)
Date: 03/30/05

  • Next message: Ingo Oeser: "Re: [ARM] Group device drivers together under their own menu" 
    To: Pavel Machek <pavel@suse.cz>
Date:	Wed, 30 Mar 2005 09:46:26 +1000

    Hi.

    On Wed, 2005-03-30 at 08:35, Pavel Machek wrote:
    > Hi!
    >
    > > > We currently freeze processes for suspend-to-ram, too. I guess that
    > > > disable_usermodehelper is probably better and that in_suspend() should
    > > > only be used for sanity checks... go with disable_usermodehelper and
    > > > sorry for the noise.
    > >
    > > Here's another possibility: Freeze the workqueue that
    > > call_usermodehelper uses (remember that code I didn't push hard enough
    > > to Andrew?), and let invocations of call_usermodehelper block in
    > > TASK_UNINTERRUPTIBLE. In refrigerating processes, don't choke on
    >
    > There may be many devices in the system, and you are going to need
    > quite a lot of RAM for all that... That's why they do not queue it
    > during boot, IIRC. Disabling usermode helper seems right.

    Many devices is true, but very few of them invoke usermode helpers.

    [desktop build-2.6.12-rc1]# find -name *.[ch] | xargs grep usermodehelper
    ./drivers/s390/crypto/z90main.c: call_usermodehelper(argv[0], argv, envp, 0);
    ./drivers/net/hamradio/baycom_epp.c: return call_usermodehelper(eppconfig_path, argv, envp, 1);
    ./drivers/acpi/thermal.c: call_usermodehelper(argv[0], argv, envp, 0);
    ./drivers/acpi/thermal.mod.c: { 0x436006da, "call_usermodehelper" },
    ./drivers/input/input.c: value = call_usermodehelper(argv [0], argv, envp, 0);
    ./drivers/pnp/pnpbios/core.c: value = call_usermodehelper (argv [0], argv, envp, 0);
    ./drivers/macintosh/therm_pm72.c: return call_usermodehelper(critical_overtemp_path, argv, envp, 0);
    ./arch/i386/mach-voyager/voyager_thread.c: if ((ret = call_usermodehelper(argv[0], argv, envp, 1)) != 0) {
    ./include/linux/kmod.h:extern int call_usermodehelper(char *path, char *argv[], char *envp[], int wait);
    ./include/linux/kmod.h:extern void usermodehelper_init(void);
    ./kernel/power/main.c: return call_usermodehelper(argv[0], argv, envp, 1);
    ./kernel/power/suspend_userui.c: retval = call_usermodehelper(userui_program, argv, envp, 0);
    ./kernel/kmod.c: call_usermodehelper wait flag, and remove exec_usermodehelper.
    ./kernel/kmod.c: ret = call_usermodehelper(modprobe_path, argv, envp, 1);
    ./kernel/kmod.c:static int ____call_usermodehelper(void *data)
    ./kernel/kmod.c: pid = kernel_thread(____call_usermodehelper, sub_info, SIGCHLD);
    ./kernel/kmod.c:static void __call_usermodehelper(void *data)
    ./kernel/kmod.c: pid = kernel_thread(____call_usermodehelper, sub_info,
    ./kernel/kmod.c: * call_usermodehelper - start a usermode application
    ./kernel/kmod.c:int call_usermodehelper(char *path, char **argv, char **envp, int wait)
    ./kernel/kmod.c: DECLARE_WORK(work, __call_usermodehelper, &sub_info);
    ./kernel/kmod.c:EXPORT_SYMBOL(call_usermodehelper);
    ./kernel/kmod.c:void __init usermodehelper_init(void)
    ./kernel/cpuset.c: * Note final arg to call_usermodehelper() is 0 - that means
    ./kernel/cpuset.c: return call_usermodehelper(argv[0], argv, envp, 0);
    ./security/keys/request_key.c: return call_usermodehelper(argv[0], argv, envp, 1);
    ./lib/kobject_uevent.c: retval = call_usermodehelper (argv[0], argv, envp, 0);
    ./lib/kobject_uevent.c: pr_debug ("%s - call_usermodehelper returned %d\n",
    ./init/main.c: usermodehelper_init();

    Of course there will be indirect invocations (via kobjects, for
    example), but I still think the number is not that great. I'm already
    using the method I suggested in unreleased Suspend2 code, and the only
    invocation I'm catch is at resume time, for the keseriod.

    Regards,

    Nigel 

    -- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574
Maintainer of Suspend2 Kernel Patches http://suspend2.net
-
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/
  • Next message: Ingo Oeser: "Re: [ARM] Group device drivers together under their own menu"

    Relevant Pages

    • Re: Suspend 2 merge: 10/51: Exports for suspend built as modules.
      ... Nigel Cunningham ... Christian Reformed Church of Tuggeranong ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: mlock(1)
      ... Nigel Cunningham ... Christian Reformed Church of Tuggeranong ... True tolerance, however, can cope with others ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: swsusp: revert to 2.6.0-test3 state
      ... That would be a minimal patch. ... image of RAM, support for highmem, swap files, full asynchronous I/O, ... Nigel Cunningham ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Dealing with swsusp vs. pmdisk
      ... While developing the swapfile support, I had a couple of occasions where ... Nigel Cunningham ... A hypothetical process whereby infinitely improbable events occur ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.4.22 hangs with pcmcia and linux-wlan
      ... If I use the kernel tree's code, I can insmod okay, but my ... >> Regards, ... Nigel Cunningham ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)