linux-kernel - Re: SwSusp to disk doesn't work

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200703112027.03532.rjw@sisk.pl>
Date:	Sun, 11 Mar 2007 20:27:03 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Thomas Meyer <thomas@...3r.de>
Cc:	linux-kernel@...r.kernel.org, Pavel Machek <pavel@....cz>
Subject: Re: SwSusp to disk doesn't work - Try 2

On Sunday, 11 March 2007 19:37, Thomas Meyer wrote:
> Rafael J. Wysocki schrieb:
> >
> > Could you please put some printk()s in kernel/cpu.c:_cpu_up() to see where
> > it gets stuck?  I bet one of the notifiers goes to sleep (cpufreq, maybe).
> >   
> Here we go (ok. i forgot __FUNCTION__ ...):
> 
> Mar 11 19:31:33 [kernel] ac ACPI0003:00: freeze
> Mar 11 19:31:33 [kernel] acpi device:00: freeze
> Mar 11 19:31:33 [kernel] processor ACPI0007:01: freeze
> Mar 11 19:31:33 [kernel] processor ACPI0007:00: freeze
> Mar 11 19:31:33 [kernel] button button_power:00: freeze
> Mar 11 19:31:33 [kernel] acpi acpi_system:00: freeze
> Mar 11 19:31:33 [kernel] Disabling non-boot CPUs ...
> Mar 11 19:31:33 [kernel] kvm: disabling virtualization on CPU1
> Mar 11 19:31:33 [kernel] CPU 1 is now offline
> Mar 11 19:31:33 [kernel] SMP alternatives: switching to UP code
> Mar 11 19:31:33 [kernel] PM: Removing info for No Bus:cpu1
> Mar 11 19:31:33 [kernel] PM: Removing info for No Bus:msr1
> Mar 11 19:31:33 [kernel] CPU1 is down
> Mar 11 19:31:33 [kernel] swsusp debug: Waiting for 5 seconds.
> Mar 11 19:31:33 [kernel] Enabling non-boot CPUs ...
> Mar 11 19:31:33 [kernel] <NULL>: before notifier CPU_UP_PREPARE.
> 
> Hung here.

This means that one of the notifiers had not returned before you pressed
the button.  Now the question is which one (there are many).

I don't know if there's any nicer way to find out that, but I usually hack
kernel/sys.c:notifier_call_chain() to print nb->notifier_call (as a pointer)
before the call is made.  Then I write down the address of the last one
called before the hang/oops and use gdb to check which function it points to.

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/