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: Sun, 22 Nov 2009 00:59:46 +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 Ferenc Wagner <wferi@...f.hu> writes: > "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. This result (the freeze happens in dpm_suspend_start) may not stand anymore: the parport_pc module was loaded and this falsified my results. That is, after suspending that device, the parport feedback ceased working, outbs becoming ineffective. >>> 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; The problem was the very low (1) default suspend loglevel. After raising it, the incriminated messages (and lots of other stuff) appeared. > 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... These printks of mine are clearly out of scope of dmesg, because they don't happen in the context of the resumed system. I think I'm starting to understand... >>> 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. Looks like this was the effect of portport_pc being loaded when I run s2disk from the desktop, but not when I started it after init=/bin/bash. -- 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