search for: suspended

Hi Eli: >> semantics of the fork intrinsic... thinking about it a bit more, I think >> you're going to run into problems with trying to keep around a return block >> through optimizations: How about this? Make all control flow explicit (duh). declare i8 coro.suspend([...]) returns: 0 - resume 1 - cleanup anything else - suspend Now we can get

...%0, label %resume1 [i8 1 %destroy1] ; or icmp + br i1 >> >> This doesn't look right: intuitively the suspend happens after the return >> block runs. Perhaps, but, that is not the intended semantics. The following two things are distinct concepts: * Coroutine is considered suspended * Coroutine returns control back to its caller (initial caller, resumer, or destroyer) Coroutine is considered suspended means that it is legal to use coro.done, coro.resume, coro.destroy intrinsics (either in this thread or in a different one). It may seem strange, but, consider this examp...

Everywhere else the constant is multiplied by 16/4, so it looks like nvc0_fence_suspend/resume is buggy here. Signed-off-by: Maarten Lankhorst <m.b.lankhorst at gmail.com> Cc: stable at vger.kernel.org [3.7+] --- diff --git a/drivers/gpu/drm/nouveau/nvc0_fence.c b/drivers/gpu/drm/nouveau/nvc0_fence.c index 85a0e78..4f46d8b 100644 --- a/drivers/gpu/drm/nouveau/nvc0_fence.c +++

...ong the process. Basically the change may lie with two aspects: - Lightweight "xm suspend/resume" - Extend suspend support to driver domU [Lightweight "xm suspend/resume"] It''s reasonable for current implementation to save and release whole memory of domU after suspended, since it allows more memory available to other domains. However for platform level S3, this is redundant when box is physically put into a suspend state. What we need is just to send a suspend notification into domU, and let domU fall into __xen_suspend path. Then domU exits scheduler by issu...

hello i think i found a bug i wanted nut to suspend to ram instead of powering off so i made a script that runs the commands but i ran into a problem i changed the shutdown command in upsmon.conf to my suspend script and i tested with upsmon -c fsd everything worked fine system went into suspend and i woke it backup by pressing the power button, now here is where i noticed some problems first one

Hi Jeremy, I backported the branch I have in linux-next plus some older PV on HVM fixes to stable-2.6.32.x. Please pull: git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git stable-2.6.32-pvhvm Ian Campbell (11): xen: do not respond to unknown xenstore control requests xen: use new schedop interface for suspend xen: switch to new schedop hypercall by default. xen:

https://bugs.freedesktop.org/show_bug.cgi?id=79988 Priority: medium Bug ID: 79988 Assignee: nouveau at lists.freedesktop.org Summary: Suspend to ram stoped to work QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: marccollin7379 at gmail.com

nouveau's ->suspend and ->resume callbacks are currently skipped if the device's status is either DRM_SWITCH_POWER_OFF (powered off by vga_switcheroo manual power control) or DRM_SWITCH_POWER_DYNAMIC_OFF (runtime suspended). In the former case this makes sense since the device is powered off behind the PM core's back: It will try to execute the ->suspend and ->resume callbacks upon system sleep, not knowing that the device is inaccessible. Therefore the callbacks have to become no-ops. However the latte...

On Fri, Jun 10, 2016 at 5:25 PM, Gor Nishanov <gornishanov at gmail.com> wrote: > Hi Eli: > > >> Naively, you would expect that it would be legal to hoist the store... > >> but that breaks your coroutine semantics because the global could be > mutated > >> between the first return and the resume. > > Hmmm... I don't see the problem. I think

On Thu, Jun 9, 2016 at 1:49 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >> Right... but that doesn't mean the call to the suspend intrinsic has to be >> the last non-terminator instruction in the basic block before you run >> CoroSplit. You can split the basic block in CoroSplit so any instructions >> after the suspend call are part of a different basic

...cution in another LLVM context. void callMaySuspendCallback(); On May 12, 2014, at 5:26 PM, Nick Lewycky <nlewycky at google.com> wrote: > Would you (or anyone) oppose a simple maySuspendContext() callback API? It would mean nothing more than the thread(s) for a given LLVM context can be suspended independent from other contexts. > > I think this is the right approach. So a given thread hits a safe point, it optionally calls a "suspend check" or "i an safe to suspend right now" callback if set. It doesn't stop other threads, it doesn't continue until the fu...

Currently running Wine 1.2-rc2 on Ubuntu 10.04 x64 on a Lenovo ThinkPad x61. After doing a suspend, I can't run Wine. The app I normally run with Wine is Lotus Notes. But I've tried something as simple as going in to the wine config. I tried doing a wineserver -k but that doesn't help either. Only thing I found to work is a full reboot. This has actually been happening since Ubuntu

Hi all. I'm having problems trying to suspend/hibernate my Dell Latitude D810 Laptop. Basically I have an ATI X600 videographics and SATA harddrive and run httpd and mysqld daemons on it. I use fglrx (ATI propietary drivers) and the open too with no success. I tried with 1 and 2 screens configurations with no success. I tried with CA and/or with battery with no success. I need some help

...spend state equal or greater/deeper than Suspend-to-memory, > known as S3. How does the application learn that its memory got wiped? S2disk is an async operation and it can happen at any time during the task execution. So how does the application work to prevent from corrupted state - e.g. when suspended between two memory loads? -- Michal Hocko SUSE Labs

...spend state equal or greater/deeper than Suspend-to-memory, > known as S3. How does the application learn that its memory got wiped? S2disk is an async operation and it can happen at any time during the task execution. So how does the application work to prevent from corrupted state - e.g. when suspended between two memory loads? -- Michal Hocko SUSE Labs

...s is the two-function approach I suggested earlier... that way, the first call to suspend isn't special, so everything just works. There might be some other way to solve it, but I think it just becomes more awkward. For example, you could add a boolean that tracks whether the function has been suspended yet, and explicitly reroute the control flow to conditionally perform one-time operations before each call to suspend. But then you need a giant switch statement or a separate one-time cleanup function to actually route the control flow correctly. -Eli -------------- next part -------------- An H...

The RHEL 5 release notes for their desktop version claim "Improved ACPI support with features such as suspend to disk" but this isn't working with CentOS 5. I've installed all the packages and updates for CentOS 5 i386 on a ThinkPad T43 but when selecting suspend, Gnome pops up a URL to a site that didn't seem to give a solution. Gnome makes an entry in /var/log/messages

...rg/wiki/Qemu_Guest_Agent_Integration shows these same 4 as false, so I'm not sure if they're always supposed to be that way. My overall point is to be able to run dompmsuspend servo disk. After setting up qemu-ga as far as I have, it at least says: ===== Domain <vmname> successfully suspended ===== But, Using libvirt 1.2.18 (-1 Arch) and QEMU git-master (2.4.0.r40384.2d69736). pm-utils 1.4.1-6. acpid 2.0.23-4 Installed using Q35 chipset. ====== {{{ domain xml file includes: }}} <pm> <suspend-to-mem enables='yes'/> <suspend-to-disk enables='yes'/&gt...

...:00PM +0100, Lukas Wunner wrote: > > nouveau's ->suspend and ->resume callbacks are currently skipped if the > > device's status is either DRM_SWITCH_POWER_OFF (powered off by > > vga_switcheroo manual power control) or DRM_SWITCH_POWER_DYNAMIC_OFF > > (runtime suspended). > > > > In the former case this makes sense since the device is powered off > > behind the PM core's back: It will try to execute the ->suspend and > > ->resume callbacks upon system sleep, not knowing that the device is > > inaccessible. Therefore the c...

Changes since last sent: * add a patch to set the device into DRM_SWITCH_POWER_CHANGING state (can be dropped actually, I thought I was needing it, came up with a different approach and forgot to delete it, doesn't hurt though) * expose information about runtime suspending to nvkm so that we can run the pcie workaround only on runtime suspend Karol Herbst (8): pci: disable ASPM