Re: Improve the accuracy of the TSC frequency calibration - Updated Patch

[Mike Larkin]

On Thu, Aug 24, 2017 at 12:39:33PM +0800, Adam Steen wrote:
> On Thu, Aug 24, 2017 at 2:35 AM, Mike Larkin  wrote:
> > On Wed, Aug 23, 2017 at 09:29:15PM +0800, Adam Steen wrote:
> >> On Thu, Aug 17, 2017 at 12:19:28PM +0800, Adam Steen wrote:
> >> > On Tue, Aug 8, 2017 at 10:12 PM, Mike Belopuhov  
> >> > wrote:
> >> > > On Tue, Aug 08, 2017 at 08:18 +0800, Adam Steen wrote:
> >> > >> On Mon, Jul 31, 2017 at 3:58 PM, Mike Belopuhov  
> >> > >> wrote:
> >> > >> > On Mon, Jul 31, 2017 at 09:48 +0800, Adam Steen wrote:
> >> > >> >> Ted Unangst  wrote:
> >> > >> >> > we don't currently export this info, but we could add some 
> >> > >> >> > sysctls. there's
> >> > >> >> > some cpufeatures stuff there, but generally stuff isn't exported 
> >> > >> >> > until
> >> > >> >> > somebody finds a use for it... it shouldn't be too hard to add 
> >> > >> >> > something to
> >> > >> >> > amd64/machdep.c sysctl if you're interested.
> >> > >> >>
> >> > >> >> I am interested, as i need the info, i will look into it and 
> >> > >> >> hopefully
> >> > >> >> come back with a patch.
> >> > >> >
> >> > >> > This is a bad idea because TSC as the time source is only usable
> >> > >> > by OpenBSD on Skylake and Kaby Lake CPUs since they encode the TSC
> >> > >> > frequency in the CPUID. All older CPUs have their TSCs measured
> >> > >> > against the PIT. Currently the measurement done by the kernel isn't
> >> > >> > very precise and if TSC is selected as a timecounter, the machine
> >> > >> > would be gaining time on a pace that cannot be corrected by our NTP
> >> > >> > daemon. (IIRC, about an hour a day on my Haswell running with NTP).
> >> > >> >
> >> > >> > To be able to use TSC as a timecounter source on OpenBSD or Solo5
> >> > >> > you'd have to improve the in-kernel measurement of the TSC frequency
> >> > >> > first. I've tried to perform 10 measurements and take an average and
> >> > >> > it does improve accuracy, however I believe we need to poach another
> >> > >> > bit from Linux and re-calibrate TSC via HPET:
> >> > >> >
> >> > >> >  
> >> > >> > http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L409
> >> > >> >
> >> > >> > I think this is the most sane thing we can do. Here's a complete
> >> > >> > procedure that Linux kernel undertakes:
> >> > >> >
> >> > >> >  
> >> > >> > http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L751
> >> > >> >
> >> > >> > Regards,
> >> > >> > Mike
> >> > >>
> >> > >> Hi Mike/All
> >> > >>
> >> > >> I would like to improve the accuracy of TSC frequency calibration as
> >> > >> Mike B. describes above.
> >> > >>
> >> > >> I initially thought the calibration would take place at line 470 of
> >> > >> amd64/identcpu.c
> >> > >> (https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/identcpu.c?annotate=1.87)
> >> > >>
> >> > >
> >> > > Indeed, it cannot happen there simply because you don't know at
> >> > > that point whether or not HPET actually exists.
> >> > >
> >> > >> But I looked into using the acpihpet directly but it is never exposed
> >> > >> outside of acpihpet.c.
> >> > >>
> >> > >
> >> > > And it shouldn't be.
> >> > >
> >> > >> Could someone point me to were if would be appropriate to complete
> >> > >> this calibration and how to use the acpihpet?
> >> > >
> >> > > The way I envision this is a multi-step approach:
> >> > >
> >> > > 1) TSC frequency is approximated with the PIT (possibly performing
> >> > > multiple measurements and averaging them out; also keep in mind that
> >> > > doing it 8 times means you can shift the sum right by 3 instead of
> >> > > using actual integer division).  This is what should happen around
> >> > > the line 470 of identcpu.c
> >> > >
> >> > > 2) A function can be provided by identcpu.c to further adjust the
> >> > > TSC frequency once acpitimer(4) (this is a PM timer) and acpihpet(4)
> >> > > (or any other timer for that matter) are attached.
> >> > >
> >> > > 3) Once acpitimer(4) or acpihpet(4) or any other timecounter source
> >> > > are attached and are verified to be operating correctly, they can
> >> > > perform TSC re-calibration and update the TSC frequency with their
> >> > > measurements.  The idea here is that the function (or functions) that
> >> > > facilitate this must abstract enough logic so that you don't have to
> >> > > duplicate it in the acpitimer or acpihpet themselves.
> >> > >
> >> > >> (Will it need to be
> >> > >> exposed like i8254_delay/delay_func/delay in machdep.c and cpu.h)
> >> > >>
> >> > >
> >> > > No it won't.
> >> > >
> >> > >> Lastly should the calibration be done using both delay(i8254 pit) and
> >> > >> hpet timers similar to Linux described above or just using the hpet?
> >> > >>
> >> > >
> >> > > Well, that's what I was arguing for.  As I said in my initial mail
> >> > > on misc (not quoted here), the TSC must be calibrated using separate
> >> > > known clocks sources.
> >> >
> >> > Hi Mike
> >> >
> >> > Please see the below diff to improve t

Re: Improve the accuracy of the TSC frequency calibration - Updated Patch

[Mike Belopuhov]

On Fri, Aug 25, 2017 at 00:40 -0700, Mike Larkin wrote:
> On Thu, Aug 24, 2017 at 12:39:33PM +0800, Adam Steen wrote:
> > On Thu, Aug 24, 2017 at 2:35 AM, Mike Larkin  wrote:
> > > On Wed, Aug 23, 2017 at 09:29:15PM +0800, Adam Steen wrote:
> > >>
> > >> Thank you Mike on the feedback on the last patch, please see the diff
> > >> below, update with your input and style(9)
> > >>
> > >> I have continued to use tsc as my timecounter and /var/db/ntpd.driff
> > >> has stayed under 10.
> > >>
> > >> cat /var/db/ntpd.drift
> > >> 6.665
> > >>
> > >> ntpctl -s all
> > >> 4/4 peers valid, constraint offset -1s, clock synced, stratum 3
> > >>
> > >> peer
> > >>wt tl st  next  poll  offset   delay  jitter
> > >> 144.48.166.166 from pool pool.ntp.org
> > >> 1 10  24s   32s-3.159ms87.723ms10.389ms
> > >> 13.55.50.68 from pool pool.ntp.org
> > >> 1 10  3   11s   32s-3.433ms86.053ms18.095ms
> > >> 14.202.204.182 from pool pool.ntp.org
> > >> 1 10  1   14s   32s 1.486ms86.545ms16.483ms
> > >> 27.124.125.250 from pool pool.ntp.org
> > >>  *  1 10  2   12s   30s   -10.275ms54.156ms70.389ms
> > >>
> > >> Cheers
> > >> Adam
> > >
> > > IIRC you have an x220, right?
> > >
> > > If so, could you try letting the clock run for a bit (while using tsc
> > > timecounter selection) after apm -L to drop the speed? (make sure
> > > apm shows that it dropped).
> > >
> > > Even though my x230 supposedly has a constant/invar TSC (according to
> > > cpuid), the TSC drops from 2.5GHz to 1.2GHz when apm -L runs, which
> > > causes time to run too slowly when tsc is selected there.
> > >
> > > -ml
> > >
> >
> > Yes, x220
> > (bios: LENOVO version "8DET69WW (1.39 )" date 07/18/2013)
> > (cpu: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz)
> >
> > I took some measurements to before starting the test.
> >
> > note: the laptop has been up for a few days with apm -A set via 
> > rc.conf.local
> > and sysctl kern.timecounter.hardware as tsc via sysctl.conf and mostly
> > idle.
> >
> > cat /var/db/ntpd.drift
> > 6.459
> >
> > apm -v
> > Battery state: high, 100% remaining, unknown life estimate
> > A/C adapter state: connected
> > Performance adjustment mode: auto (800 MHz)
> >
> > 6 hours ago i ran apm -L, verified it was running slowly (800 MHz),
> > and got the following results
> >
> > The clock appears correct (comparing to other computers)
> >
> > apm -v
> > Battery state: high, 100% remaining, unknown life estimate
> > A/C adapter state: connected
> > Performance adjustment mode: manual (800 MHz)
> >
> > cat /var/db/ntpd.drift
> > 6.385
> >
> > ntpctl -s all
> > 4/4 peers valid, constraint offset 0s, clock synced, stratum 4
> >
> > peer
> >wt tl st  next  poll  offset   delay  jitter
> > 203.23.237.200 from pool pool.ntp.org
> > 1 10  2  153s 1505s   -25.546ms73.450ms 2.644ms
> > 203.114.73.24 from pool pool.ntp.org
> > 1 10  2  253s 1560s-1.042ms75.133ms 0.752ms
> > 192.189.54.33 from pool pool.ntp.org
> >  *  1 10  2  204s 1558s31.644ms70.910ms 3.388ms
> > 54.252.165.245 from pool pool.ntp.org
> > 1 10  2  238s 1518s 0.146ms73.005ms 2.025ms
> >
> > I will leave the laptop in lower power mode over the weekend and see
> > what happens.
> >
>
> No need, I think you've convinced me that it works :)

But does it actually work on x230 as well?  I'm surprised to learn
that you've observed TSC frequency change on Ivy Bridge.  I was
under impression that everything since at least Sandy Bridge (x220)
has constant and invariant TSC as advertised.

Adam, I've readjusted and simplified your diff a bit.  The biggest
change is that we can select the reference tc based on it's quality
so there's no need to have acpitimer and acpihpet specific functions
and variables.

There's one big thing missing here: increasing the timecounter
quality so that OS can pick it.  Something like this:

https://github.com/mbelop/src/commit/99d6ef3ae95bbd8ea93c27e0425eb65e5a3359a1

I'd say we should try getting this in after 6.3 unlock unless there
are objections.  Further cleanup and testing is welcome of course.


diff --git sys/arch/amd64/amd64/acpi_machdep.c 
sys/arch/amd64/amd64/acpi_machdep.c
index 17d8fb205ef..f632b838ec2 100644
--- sys/arch/amd64/amd64/acpi_machdep.c
+++ sys/arch/amd64/amd64/acpi_machdep.c
@@ -67,10 +67,19 @@ extern int acpi_savecpu(void) __returns_twice;
 #define ACPI_BIOS_RSDP_WINDOW_BASE0xe
 #define ACPI_BIOS_RSDP_WINDOW_SIZE0x2
 
 u_int8_t   *acpi_scan(struct acpi_mem_map *, paddr_t, size_t);
 
+#define RECALIBRATE_MAX_RETRIES5
+#define RECALIBRATE_SMI_THRESHOLD  5
+#define RECALIBRATE_DELAY_THRESHOLD20
+
+struct timecounter *recalibrate_tc;
+
+uint64_t acpi_calibrate_tsc_freq(void);
+int acpi_get_tsc_and_timecount(struct timecounter *, uint64_t *, uint64_t *);
+
 int
 acpi_map(paddr_t pa, size_t len

reiser4fs in openbsd

[Андрей Болконский]

hello! If I will achieve change of license for reiser4 FS on BSD and ported
it to the openbsd, you accept it?
And what about Journaling in openbsd?

Re: reiser4fs in openbsd

[Otto Moerbeek]

On Fri, Aug 25, 2017 at 02:31:10PM +0300, Андрей Болконский wrote:

> hello! If I will achieve change of license for reiser4 FS on BSD and ported
> it to the openbsd, you accept it?
> And what about Journaling in openbsd?

We do not make promises about accepting code, especially if it does
not exist.

-Otto

Re: reiser4fs in openbsd

[Андрей Болконский]

ok. is reiser4 need on openbsd?

2017-08-25 17:23 GMT+03:00 Otto Moerbeek :

> On Fri, Aug 25, 2017 at 02:31:10PM +0300, Андрей Болконский wrote:
>
> > hello! If I will achieve change of license for reiser4 FS on BSD and
> ported
> > it to the openbsd, you accept it?
> > And what about Journaling in openbsd?
>
> We do not make promises about accepting code, especially if it does
> not exist.
>
> -Otto
>

Re: relayd interrupted transfers

[Alexander Bluhm]

On Fri, Aug 25, 2017 at 06:38:01AM +, Rivo Nurges wrote:
> Your version works for me.

Good.

Any ok for this diff then?

bluhm

Index: usr.sbin/relayd/relay.c
===
RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.225
diff -u -p -r1.225 relay.c
--- usr.sbin/relayd/relay.c 9 Aug 2017 21:29:17 -   1.225
+++ usr.sbin/relayd/relay.c 24 Aug 2017 14:02:38 -
@@ -791,12 +791,12 @@ relay_write(struct bufferevent *bev, voi
 
getmonotime(&con->se_tv_last);
 
-   if (con->se_done)
+   if (con->se_done && EVBUFFER_LENGTH(EVBUFFER_OUTPUT(bev)) == 0)
goto done;
-   if (relay_splice(cre->dst) == -1)
-   goto fail;
if (cre->dst->bev)
bufferevent_enable(cre->dst->bev, EV_READ);
+   if (relay_splice(cre->dst) == -1)
+   goto fail;
 
return;
  done:

Re: reiser4fs in openbsd

[Daniil Berendeev]

ok. is reiser4 need on openbsd?

Well, a dead fs is not much of an interest. If you would be porting
HAMMER or ZFS (the last one has a painful license though) there
probably would be much more interest.

--
~Cheers~
pipfstarrd.net
pipfsta...@jabbim.com

PGP KEY ID ACE8 41D8 A1B6 54C0
Keys can be retrieved at pgp.mit.edu

Re: reiser4fs in openbsd

[Philipp Buehler]

Am 25.08.2017 17:35 schrieb Daniil Berendeev:

ok. is reiser4 need on openbsd?

Well, a dead fs is not much of an interest. If you would be porting
HAMMER or ZFS (the last one has a painful license though) there
probably would be much more interest.


HAMMER2 - yes, please.

(what happened to the netbsd "journalled" one?)
--
pb

Re: reiser4fs in openbsd

[Victor Kukshiev]

Reiser4 isn't dead FS, but with advanced features,

2017-08-25 18:35 GMT+03:00 Daniil Berendeev :

> ok. is reiser4 need on openbsd?
>>
> Well, a dead fs is not much of an interest. If you would be porting
> HAMMER or ZFS (the last one has a painful license though) there
> probably would be much more interest.
>
> --
> ~Cheers~
> pipfstarrd.net
> pipfsta...@jabbim.com
>
> PGP KEY ID ACE8 41D8 A1B6 54C0
> Keys can be retrieved at pgp.mit.edu
>

Re: reiser4fs in openbsd

[Dinar Talypov]

No code, nothing to discuss.

25 авг. 2017 г. 18:51 пользователь "Victor Kukshiev" <
andrey0bolkon...@gmail.com> написал:

> Reiser4 isn't dead FS, but with advanced features,
>
> 2017-08-25 18:35 GMT+03:00 Daniil Berendeev :
>
> > ok. is reiser4 need on openbsd?
> >>
> > Well, a dead fs is not much of an interest. If you would be porting
> > HAMMER or ZFS (the last one has a painful license though) there
> > probably would be much more interest.
> >
> > --
> > ~Cheers~
> > pipfstarrd.net
> > pipfsta...@jabbim.com
> >
> > PGP KEY ID ACE8 41D8 A1B6 54C0
> > Keys can be retrieved at pgp.mit.edu
> >
>

ksh: crashy HISTSIZE handling

[Jeremie Courreges-Anglas]

The code in sethistsize() is bogus when we want to shrink the array:
- the memmove doesn't copy the last command (which should be
  HISTSIZE=...)
- trying to access *histptr immediately would trigger a crash, as it
  points one element past the array

To reproduce: type HISTSIZE=3, hit  (emacs mode).

I think both problems find their root in the fact that cursize is
misnamed.  The following seems to properly handle all cases here.

Comments / ok?


Index: history.c
===
RCS file: /d/cvs/src/bin/ksh/history.c,v
retrieving revision 1.64
diff -u -p -p -u -r1.64 history.c
--- history.c   11 Aug 2017 19:37:58 -  1.64
+++ history.c   25 Aug 2017 20:53:22 -
@@ -509,18 +509,17 @@ void
 sethistsize(int n)
 {
if (n > 0 && n != histsize) {
-   int cursize = histptr - history;
+   int offset = histptr - history;
 
/* save most recent history */
-   if (n < cursize) {
-   memmove(history, histptr - n, n * sizeof(char *));
-   cursize = n;
+   if (offset > n - 1) {
+   offset = n - 1;
+   memmove(history, histptr - offset, n * sizeof(char *));
}
 
history = areallocarray(history, n, sizeof(char *), APERM);
-
histsize = n;
-   histptr = history + cursize;
+   histptr = history + offset;
}
 }
 

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

xpdf rendering issues / Mesa 17.1.8 rc1

[Jonathan Gray]

Some people have reported rendering issues with xpdf recently specific
to recent changes in the xenocara tree.

Mesa was recently updated to 17.1.6.  Here is a diff that adds the
changes from 17.1.8-rc1 (which still identifies as 17.1.7).  I am curious
if it helps.

The planned release schedule for the rest of the Mesa 17.1 branch is:

17.1.8  2017-08-28
17.1.9  2017-09-08

To test, apply the patch, rebuild xenocara and restart xorg so
the updated dri driver is used.

Index: lib/mesa/VERSION
===
RCS file: /cvs/xenocara/lib/mesa/VERSION,v
retrieving revision 1.1.1.9
diff -u -p -r1.1.1.9 VERSION
--- lib/mesa/VERSION14 Aug 2017 09:30:06 -  1.1.1.9
+++ lib/mesa/VERSION26 Aug 2017 03:19:32 -
@@ -1 +1 @@
-17.1.6
+17.1.7
Index: lib/mesa/configure
===
RCS file: /cvs/xenocara/lib/mesa/configure,v
retrieving revision 1.12
diff -u -p -r1.12 configure
--- lib/mesa/configure  14 Aug 2017 09:57:57 -  1.12
+++ lib/mesa/configure  26 Aug 2017 03:19:32 -
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for Mesa 17.1.6.
+# Generated by GNU Autoconf 2.69 for Mesa 17.1.7.
 #
 # Report bugs to .
 #
@@ -591,8 +591,8 @@ MAKEFLAGS=
 # Identity of this package.
 PACKAGE_NAME='Mesa'
 PACKAGE_TARNAME='mesa'
-PACKAGE_VERSION='17.1.6'
-PACKAGE_STRING='Mesa 17.1.6'
+PACKAGE_VERSION='17.1.7'
+PACKAGE_STRING='Mesa 17.1.7'
 PACKAGE_BUGREPORT='https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa'
 PACKAGE_URL=''
 
@@ -1815,7 +1815,7 @@ if test "$ac_init_help" = "long"; then
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures Mesa 17.1.6 to adapt to many kinds of systems.
+\`configure' configures Mesa 17.1.7 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1886,7 +1886,7 @@ fi
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of Mesa 17.1.6:";;
+ short | recursive ) echo "Configuration of Mesa 17.1.7:";;
esac
   cat <<\_ACEOF
 
@@ -2224,7 +2224,7 @@ fi
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-Mesa configure 17.1.6
+Mesa configure 17.1.7
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2943,7 +2943,7 @@ cat >config.log <<_ACEOF
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by Mesa $as_me 17.1.6, which was
+It was created by Mesa $as_me 17.1.7, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -3879,7 +3879,7 @@ fi
 
 # Define the identity of the package.
  PACKAGE='mesa'
- VERSION='17.1.6'
+ VERSION='17.1.7'
 
 
 cat >>confdefs.h <<_ACEOF
@@ -28533,7 +28533,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_wri
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by Mesa $as_me 17.1.6, which was
+This file was extended by Mesa $as_me 17.1.7, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -28590,7 +28590,7 @@ _ACEOF
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; 
s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-Mesa config.status 17.1.6
+Mesa config.status 17.1.7
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
Index: lib/mesa/src/amd/common/ac_binary.c
===
RCS file: /cvs/xenocara/lib/mesa/src/amd/common/ac_binary.c,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 ac_binary.c
--- lib/mesa/src/amd/common/ac_binary.c 14 Aug 2017 09:41:47 -  1.1.1.2
+++ lib/mesa/src/amd/common/ac_binary.c 26 Aug 2017 03:19:32 -
@@ -109,7 +109,7 @@ static void parse_relocs(Elf *elf, Elf_D
}
 }
 
-void ac_elf_read(const char *elf_data, unsigned elf_size,
+bool ac_elf_read(const char *elf_data, unsigned elf_size,
 struct ac_shader_binary *binary)
 {
char *elf_buffer;
@@ -118,6 +118,7 @@ void ac_elf_read(const char *elf_data, u
Elf_Data *symbols = NULL, *relocs = NULL;
size_t section_str_index;
unsigned symbol_sh_link = 0;
+   bool success = true;
 
/* One of the libelf implementations
 * (http://www.mr511.de/software/english.htm) requires calling
@@ -137,7 +138,8 @@ void ac_elf_read(const char *elf_data, u
GElf_Shdr section_header;
if (gelf_getshdr(section, §ion_header) != §ion_header) {

mg: extract exit status from pclose return value

[Scott Cheloha]

Hi,

compile_mode() currently just reports the value returned by
pclose(3).  This is incorrect because pclose gives you
whatever wait4(2) returned, which needs to be examined
with the various W* macros in  to derive a proper
exit status.

This patch checks how the popen'd process exited and chooses
an exit status as the shell would.

--
Scott Cheloha

Index: usr.bin/mg/grep.c
===
RCS file: /cvs/src/usr.bin/mg/grep.c,v
retrieving revision 1.44
diff -u -p -r1.44 grep.c
--- usr.bin/mg/grep.c   19 Mar 2015 21:48:05 -  1.44
+++ usr.bin/mg/grep.c   26 Aug 2017 04:06:35 -
@@ -2,8 +2,10 @@
 
 /* This file is in the public domain */
 
-#include 
 #include 
+#include 
+#include 
+
 #include 
 #include 
 #include 
@@ -179,7 +181,7 @@ compile_mode(const char *name, const cha
FILE*fpipe;
char*buf;
size_t   len;
-   int  ret, n;
+   int  n, ret, status;
char cwd[NFILEN], qcmd[NFILEN];
char timestr[NTIME];
time_t   t;
@@ -220,12 +222,13 @@ compile_mode(const char *name, const cha
addline(bp, buf);
}
ret = pclose(fpipe);
+   status = WIFEXITED(ret) ? WEXITSTATUS(ret) : 128 + WTERMSIG(ret);
t = time(NULL);
strftime(timestr, sizeof(timestr), "%a %b %e %T %Y", localtime(&t));
addline(bp, "");
-   if (ret != 0)
-   addlinef(bp, "Command exited abnormally with code %d"
-   " at %s", ret, timestr);
+   if (status != 0)
+   addlinef(bp, "Command exited abnormally with status %d"
+   " at %s", status, timestr);
else
addlinef(bp, "Command finished at %s", timestr);