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
| ||
|
Date: Wed, 18 Nov 2009 23:54:05 +0100 From: Ferenc Wagner <wferi@...f.hu> To: "Rafael J. Wysocki" <rjw@...k.pl> Cc: linux-pm@...ts.linux-foundation.org, Jesse Barnes <jbarnes@...tuousgeek.org>, Andrew Morton <akpm@...ux-foundation.org>, yakui.zhao@...el.com, LKML <linux-kernel@...r.kernel.org>, ACPI Devel Maling List <linux-acpi@...r.kernel.org>, Len Brown <lenb@...nel.org> Subject: Re: [linux-pm] intermittent suspend problem again "Rafael J. Wysocki" <rjw@...k.pl> writes: > On Wednesday 18 November 2009, Ferenc Wagner wrote: >> Ferenc Wagner <wferi@...f.hu> writes: >> >> > Since I've instrumented s2disk and the hibernation path, no freeze >> > happened during hibernating the machine. >> >> Not until I removed the delays from hibernation_platform_enter(), which >> were put there previously to get step-by-step feedback. Removing them >> again resulted in a freeze in short course, maybe just two hibernations >> later. The instrumentation shows it stuck in dpm_suspend_start(PMSG_HIBERNATE). >> Does it mean that some device driver is at fault? > > A driver or one of the platform hooks. > >> I'll check if it always fails at the same point (although tracing into >> dpm_suspend_start isn't pure fun because of the multitude of devices it >> loops over). Is there any way to get printk output from that phase? > > Compile with CONFIG_PM_VERBOSE (it does mean exactly that). I've been running with CONFIG_PM_VERBOSE=y for a good while, but that didn't help getting for example the result of the following printks to the VGA console (0x3bc is the parallel port): @@ -445,34 +446,66 @@ int hibernation_platform_enter(void) * hibernation_ops->finish() before saving the image, so we should let * the firmware know that we're going to enter the sleep state after all */ + printk ("hibernation_ops->begin()...\n"); + outb(16, 0x3bc); error = hibernation_ops->begin(); + outb(17, 0x3bc); + printk ("hibernation_ops->begin(): %d\n", error); if (error) goto Close; However, my dmesg is full of lines like agpgart-intel 0000:00:00.0: preparing freeze pci 0000:00:00.1: preparing freeze pci 0000:00:00.3: preparing freeze etc., I'll check it they are the same all the time. Anyway, the above printk strings aren't present in dmesg after a successful resume even, so I must be doing something wrong... The parport pins do change, though. Maybe explicit levels would work better? I can't see any other difference from the pm_dev_dbg macro producing the above lines. >> Side question: If I run s2disk from the init=/bin/bash prompt, the >> instrumentation in acpi_enter_sleep_state_prep in drivers/acpi/acpica/hwsleep.c >> fires before the "Snapshotting system" phase, but it does not fire if I >> hibernate from the full running desktop. (That instrumentation was put >> there to investigate the KMS-triggered STR freeze.) What could explain >> this? > > It looks like it uses the "shutdown" method when run with init=/bin/bash, but > I don't know why exactly. Thanks for the tip, I'll check this too. -- Regards, Feri. -- 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/
Powered by blists - more mailing lists