search for: halted

> I'm quite sure that in original Berkeley Unix, as on the VAX 11/780, halt > was an immediate halt of the CPU without any process cleanup or file system > umounting or anything. Early SunOS (pre-Solaris) was like this, too. > The SunOS 4.1.2 man page for halt says NAME halt - stop the processor SYNOPSIS /usr/etc/halt [ -oqy ] DESCRIPTION halt writes

> fwiw, i've always used 'init 0' to shut down all sorts of unix/linux > systems. In EL7/EL8, init is now a symlink as well because everything is controlled by systemd. > On old school unix, and I think even early Linux, halt was an > /immediate/ halt, as in catch fire. might as well hit the power switch. > Not quite. Shutdown is a timed thing so you can tell it

...-p it powers off and closes qemu. >> Can poweroff.c32 do the same as sudo halt -p in ubuntu? > > Is there any sort of output? > No, just a blinking cursor. Its similar when you do sudo halt without -p with result also in a blinking cursor and * Will now halt [ 279.570476] System halted.

Working with different OSs can be quite challenging (mentally :-)). I wonder why the command "halt" has not same result between EL6 and EL8. To shutdown the vm or workstation in EL8 i must use "shutdown now". Who mandates this behavior in terms of configuration file? -- Leon

Hi, I've been making some tests with libvirt and LXC and found some problems when halting/restarting a LXC container from within. Basically, on a Ubuntu 12.04 system with libvirt installed as package (0.9.8), I've created a basic container image with: lxc-create -t ubuntu -n lxc And started it using the libvirt XML listed below and the following command: virsh -c lxc:// create

Working with different Linux Distributions makes the life harder. So far I have found out that 'poweroff' & 'reboot' has the same behaviour on Linux/Unix/BSDs. Best Regards, Strahil Nikolov ?? 15 ??? 2020 ?. 5:22:28 GMT+03:00, John Pierce <jhn.pierce at gmail.com> ??????: >On Sun, Jun 14, 2020 at 6:19 PM Pete Biggs <pete at biggs.org.uk> wrote: > >>

Using syslinux 6.01-pre4 and ubuntu 13.10 kernel 32bit LABEL halt com32 poweroff.c32 Does not power off my qemu, it stays open in halt mode. qemu -cdrom ubuntu.iso -boot d -net nic,model=virtio -m 1024 -curses If I boot into ubuntu first and do sudo halt -p it powers off and closes qemu. Can poweroff.c32 do the same as sudo halt -p in ubuntu?

On May 1, 2010, at 11:19 AM, Chris Lattner wrote: > > On May 1, 2010, at 11:07 AM, Owen Anderson wrote: > >> Hey folks, >> >> In a recent blog post, John Regehr pointed out that LLVM is currently optimizing away read-only functions containing infinite loops whose return values are never used. The culprit for the moment is the inliner, but the more insidious problem

Hey folks, In a recent blog post, John Regehr pointed out that LLVM is currently optimizing away read-only functions containing infinite loops whose return values are never used. The culprit for the moment is the inliner, but the more insidious problem is that isTriviallyDeletable currently returns true for any read-only function whose value is not used. In order to prevent this from happening

There is a problem with the patch I sent out yesterday. The patches for the glm code are applied in the wrong place. I have removed the patch file and will have a real one available latter today. Ross =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help",

On May 1, 2010, at 11:07 AM, Owen Anderson wrote: > Hey folks, > > In a recent blog post, John Regehr pointed out that LLVM is currently optimizing away read-only functions containing infinite loops whose return values are never used. The culprit for the moment is the inliner, but the more insidious problem is that isTriviallyDeletable currently returns true for any read-only function

...sudo halt -p in ubuntu? >>> >>> Is there any sort of output? >>> >> >> No, just a blinking cursor. Its similar when you do sudo halt without -p >> with result also in a blinking cursor and >> >> * Will now halt >> [ 279.570476] System halted. > > You can test this with this iso > > http://ovh.to/XAHsNVj > > qemu -cdrom ubuntu.iso -boot d -net nic,model=virtio -m 1024 -curses Which qemu version with which bios are you trying? Sebastian

On Sun, Jun 14, 2020 at 5:20 PM Pete Biggs <pete at biggs.org.uk> wrote: > > > fwiw, i've always used 'init 0' to shut down all sorts of unix/linux > > systems. > > In EL7/EL8, init is now a symlink as well because everything is > controlled by systemd. > > > On old school unix, and I think even early Linux, halt was an > > /immediate/

On Sun, Jun 14, 2020 at 6:19 PM Pete Biggs <pete at biggs.org.uk> wrote: > > > I'm quite sure that in original Berkeley Unix, as on the VAX 11/780, halt > > was an immediate halt of the CPU without any process cleanup or file > system > > umounting or anything. Early SunOS (pre-Solaris) was like this, too. > > > The SunOS 4.1.2 man page for halt says

Hi, I have set-up the ups shutdown feature provided by Red Hat /etc/rc.d/init.d/halt script, which will issue a "upsdrvctl shutdown" command just before powering off the system. It appears that this command fails as if the driver is not available. I wonder whether the usb driver / stack is still available at this very late stage ? If not available then does it mean one cannot

...er images in a loop using GDAL. The thing is that releasing this command in the bash results in the following error Error in function (handle) : GDAL Error 1: TIFFReadDirectory:/tmp/RtmpPCALnL/file265f67a6: cannot handle zero scanline size Calls: <Anonymous> -> .Call Execution halted The scripts halts, although there are more images to process. The question is why the script halts and why the script is not halted (but still "decorated" with errors) when releasing it within the R console like so R CMD source("/data/myscript.R") The result of this R CMD i...

This patch adds base para-virtualization support to the queue spinlock in the same way as was done in the PV ticket lock code. In essence, the lock waiters will spin for a specified number of times (QSPIN_THRESHOLD = 2^14) and then halted itself. The queue head waiter, unlike the other waiter, will spins 2*QSPIN_THRESHOLD times before halting itself. Before being halted, the queue head waiter will set a flag (_Q_LOCKED_SLOWPATH) in the lock byte to indicate that the unlock slowpath has to be invoked. In the unlock slowpath, the cu...

...wrote: > > > I tested the v7,v8 of qspinlock with unfair config on kvm guest. > I was curious about unfair locks performance in undercommit cases. > (overcommit case is expected to perform well) > > But I am seeing hang in overcommit cases. Gdb showed that many vcpus > are halted and there was no progress. Suspecting the problem /race with > halting, I removed the halt() part of kvm_hibernate(). I am yet to > take a closer look at the code on halt() related changes. It seems like there may still be race conditions where the current code is not handling correctly....

...wrote: > > > I tested the v7,v8 of qspinlock with unfair config on kvm guest. > I was curious about unfair locks performance in undercommit cases. > (overcommit case is expected to perform well) > > But I am seeing hang in overcommit cases. Gdb showed that many vcpus > are halted and there was no progress. Suspecting the problem /race with > halting, I removed the halt() part of kvm_hibernate(). I am yet to > take a closer look at the code on halt() related changes. It seems like there may still be race conditions where the current code is not handling correctly....

Setting up nut on a system where an LVM volume holds the root filesystem.. What is the appropriate device form to use with "mdadm --readonly" in halt? This is on a CentOS 5 system. So far I have found three possibilities, but I do not know which one (if any) will still be valid that late in the halt procedure: 1. /dev/md0 (from posts on the net) 2.