search for: poweroff_wait

...4 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 0xc01720be in dumpsys () (kgdb) bt #0 0xc01720be in dumpsys () #1 0xc0171e8f in boot () #2 0xc01722b4 in poweroff_wait () #3 0xc023dd1e in trap_fatal () #4 0xc023d9f1 in trap_pfault () #5 0xc023d5af in trap () #6 0xc01fffde in vnode_pager_generic_putpages () #7 0xc01eab72 in ffs_putpages () #8 0xc01ffe3a in vnode_pager_putpages () #9 0xc01fcdb8 in vm_pageout_flush () #10 0xc01fa38e in vm_object_page_collect_...

...cb at physical address 0x0036e460 panicstr: vm_map_entry_create: kernel resources exhausted panic messages: --- panic: vm_map_entry_create: kernel resources exhausted syncing disks... 2 2 done Uptime: 7d7h13m45s (kgdb) where #0 0xc01682aa in dumpsys () #1 0xc016807b in boot () #2 0xc01684a0 in poweroff_wait () #3 0xc02553f0 in vm_map_entry_create () #4 0xc02555e9 in vm_map_insert () #5 0xc0255810 in vm_map_find () #6 0xc0178cfb in pipespace () #7 0xc0178dd2 in pipe_create () #8 0xc0178b54 in pipe () #9 0xc02c21f5 in syscall2 () #10 0xc02b3875 in Xint0x80_syscall () #11 0x28081e1f in ?? () #12 0...

...bled, resume, IOPL = 0 current process = 2528 (zebra) interrupt mask = trap number = 12 panic: page fault (kgdb) where #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 #1 0xc0150bec in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316 #2 0xc0151020 in poweroff_wait (junk=0xc02794ec, howto=-1071149073) at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xc0242283 in trap_fatal (frame=0xdf0b1ce8, eva=4) at /usr/src/sys/i386/i386/trap.c:974 #4 0xc0241f3d in trap_pfault (frame=0xdf0b1ce8, usermode=0, eva=4) at /usr/src/sys/i386/i386/trap.c:867 #5 0xc0241b13 in tra...

...28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 dumpsys () at ../../kern/kern_shutdown.c:487 487 if (dumping++) { (kgdb) bt #0 dumpsys () at ../../kern/kern_shutdown.c:487 #1 0xc02367df in boot (howto=260) at ../../kern/kern_shutdown.c:316 #2 0xc0236c04 in poweroff_wait (junk=0xc041ef00, howto=-813081692) at ../../kern/kern_shutdown.c:595 #3 0xc02310db in lockmgr (lkp=0xcf895bcc, flags=33620002, interlkp=0xc04f5be4, p=0xdfab4440) at ../../kern/kern_lock.c:337 #4 0xc025e010 in getblk (vp=0xde97cb40, blkno=41922624, size=16384, slpflag=0, slptimeo=0)...

...37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Following is the stack trace (as output from bt): #0 dumpsys () at ../../kern/kern_shutdown.c:487 #1 0xc015b2ef in boot (howto=260) at ../../kern/kern_shutdown.c:316 #2 0xc015b714 in poweroff_wait (junk=0xc02594cc, howto=-1071280145) at ../../kern/kern_shutdown.c:595 #3 0xc021c30a in trap_fatal (frame=0xc82c7a48, eva=44) at ../../i386/i386/trap.c:974 #4 0xc021bfdd in trap_pfault (frame=0xc82c7a48, usermode=0, eva=44) at ../../i386/i386/trap.c:867 #5 0xc021bbc7 in trap (frame={...

...18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 487 if (dumping++) { (kgdb) bt #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 #1 0xc01a1c4f in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316 #2 0xc01a2074 in poweroff_wait (junk=0xc031a58c, howto=-1070489457) at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xc02c1006 in trap_fatal (frame=0xdf65dbfc, eva=303703667) at /usr/src/sys/i386/i386/trap.c:974 #4 0xc02c0cd9 in trap_pfault (frame=0xdf65dbfc, usermode=0, eva=303703667) at /usr/src/sys/i386/i386/trap.c:867 #5 0xc0...

It's about that situation when power returns during the shutdown sequence, and the UPS ignores the "Kill power now!" command. In Debian, there is an old workaround for this: the POWEROFF_WAIT option. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358696 . However, it does not work in Debian Stable (Jessie, NUT 2.7.2-4), apparently because systemd thinks it's smart enough to handle shutdown by itself. I wonder if it's even possible to implement this kind of thing with...

...ock = 01000002; cpuid = 1; lapic.id = 01000000 boot() called on cpu#1 Uptime: 6d22h55m44s dumping to dev #twed/0x20001, offset 2097152 (kgdb) where #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 #1 0xc01593ac in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:316 #2 0xc0159814 in poweroff_wait (junk=0xc026f0aa, howto=1) at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xc026f0aa in bsl1 () #4 0xc026d1aa in get_pv_entry () at /usr/src/sys/i386/i386/pmap.c:1539 #5 0xc026d34f in pmap_insert_entry (pmap=0xc02f1620, va=3299061760, mpte=0x0, m=0xc07de248) at /usr/src/sys/i386/i386/pmap.c:...

...ith upsmon -c fsd, the UPS fails to cut power. The normal halt procedure completes, and my machine turns itself off and stays off. The relevant part of the shutdown script is: flag=`sed -ne 's#^ *POWERDOWNFLAG *\(.*\)$#\1#p' /etc/nut/upsmon.conf` wait_delay=`sed -ne 's#^ *POWEROFF_WAIT= *\(.*\)$#\1#p' /etc/default/nut` if [ -f "$flag" ] ; then if $upsmon -K >/dev/null 2>&1 ; then log_action_msg "Shutting down the UPS ..." # log_action_msg "Restarting udev to give USB access" # /etc/init.d/udev start #...

...start_stop_server start && echo -n " upsd" start_stop_client start && echo -n " upsmon" echo "." ;; poweroff) flag=`sed -ne 's#^ *POWERDOWNFLAG *\(.*\)$#\1#p' usr/local/ups/etc/upsmon.conf` wait_delay=`sed -ne 's#^ *POWEROFF_WAIT= *\(.*\)$#\1#p' /etc/default/nut` if [ -f "$flag" ] ; then if $upsmon -K >/dev/null 2>&1 ; then echo "Shutting down the UPS ..." sleep 1 if $upsdrvctl shutdown ; then sleep 5 echo -n "Waiting for UPS to cu...

...10 9 8 7 6 5 4 3 2 1 0 --- #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 487 if (dumping++) { (kgdb) where full #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 error = 0 #1 0xc0171ddb in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:316 howto = 260 #2 0xc0172200 in poweroff_wait (junk=0xc032454c, howto=-1070448561) at /usr/src/sys/kern/kern_shutdown.c:595 fmt = 0xc032454c "%s" bootopt = 260 buf = "page fault", '\000' <repeats 245 times> #3 0xc02d0976 in trap_fatal (frame=0xc032d134, eva=48) at /usr/src/sys/i386/i386/trap.c:974 fra...

Today my system coredumped (4.8-STABLE from Saturday), I believe it's somehow X11 related: X11 crashed first (signal 11). I was running it as root (I know I shouldn't). I didn't think about it and restarted X11. While it was starting, I had a look at the console, there was a bright white message: issignal. This shows up at X11 startup. Then the system coredumped. Below is more

OK, can someone tell me what utterly moronic thing I am doing wrong? I have two roughly identical Linux system running NUT, and one works properly. The other almost does. The second system works well once everything is up, but after booting, the system does not have connectivity to the UPS. I have to manually run `upsdrvctl start backup`, `/etc/init.d/nut start`, and `upsd` to get NUT

G'day ... David Schultz, in his spare time, has been working through some of the issues I've been able to 'tweak' in the unionfs code ... as he is currently working on forward-patching it to -CURRENT right now, he can't commit the code to the -STABLE tree ... in order to allow others using unionfs to test the patch (I've been running it a few weeks now on a very heavily

...9 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 (kgdb) bt #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 #1 0xc01a8cd8 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316 #2 0xc01a910c in poweroff_wait (junk=0xc037558c, howto=-1070116721) at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xc030d057 in trap_fatal (frame=0xd08d3c60, eva=54) at /usr/src/sys/i386/i386/trap.c:974 #4 0xc030cd19 in trap_pfault (frame=0xd08d3c60, usermode=0, eva=54) at /usr/src/sys/i386/i386/trap.c:867 #5 0xc...

Yesterday I begin a couple of update to the latest 4.8-STABLE. After that the two boxes continues to go in panics as soon as Apache (1.3 from the ports, also freshly recompiled, 2.0.x seems NOT to hang) starts. I don't know if it is related to the other thread : "Kernel core dump in recent 4.8-STABLE" but it is easily reproducible by cvsupping to a today -STABLE and then running

I almost had nut_2.0.5-3_i386.deb (from http://packages.debian.org/unstable/admin/nut - installed via dpkg, not via repository) working: * problems with getting it to come up during boot * monitoring via knutclient was OK * shutdown on low battery worked adequately, if not quite as described) and newhidups suddenly stopped talking to my Belkin F6C550-AVR . It's only been in use for a