Perl 5.22.1 testing request + issue on alpha

[Andrew Fresh]

Again it's time to look at updating perl.  I am looking for more test
results on different platforms.

I have alpha, amd64, armv7, i386, sparc64, and macppc tests already.
Looking for help with any others, especially vax and sparc.

I have built a release with the new perl and dpb built pretty much all
the packages I need for my laptop and pkg_add/delete seem to be working
well.

As usual, download the latest version of the update script:
https://github.com/afresh1/OpenBSD-perl/archive/master.tar.gz

Extract it, and download perl 5.22.1 into the extracted directory:
https://cpan.metacpan.org/authors/id/S/SH/SHAY/perl-5.22.1.tar.gz

cd to someplace you have room
run /path/to/OpenBSD-perl/build_perl
wait
send me the log file(s) it generates


Logs I have already are available on Github.
https://github.com/afresh1/OpenBSD-perl



I have run into a strange issue on alpha that I'm still tracking down.
I fear this has interrupted me too long to get 5.22 in for OpenBSD 5.9,
but maybe we can get ahead of the curve and be ready after unlock.

Previously, NaN + 1 looked like this:
$ perl -we 'print "NaN" + 1'
-nan

Due to improvements in the Inf/NaN code, 5.22 should get:
$ perl -we 'print "NaN" + 1' 
NaN

But for some reason on alpha NaN isn't special and we instead get:
$ ./perl -we 'print "NaN" + 1'
1

As far as I can tell, when reading it in the flags get set properly, so
I'm not sure what's different on alpha.

Re: ksh another home/end pair

[Theo de Raadt]

>> In tmux, home and end send different bytes. I don't know why, but I want
>> things to just work. We already have two different keys here, so what's one
>> more? (how many can there be...?)
>
>We shouldn't have any there.  That's what termcap(3) is for.  If
>you don't link to termcap, you don't get the functionality.

I also find this change disturbing.  Though termcap isn't completely
suitable, we don't want the shell parsing environment and opening
(re-opening) terminal config files on a regular basis.

2000+ other terminal types have been left behind.  This entire
functionality is a non-mandatory convenience written to assume
"ANSI terminals"...

ifconfig: rm not need variable noprint

[Fabian Raetz]

Hi tech@,

this patch removes the 'noprint' variable which was added to ifconfig.c in rev 
1.216
and is not in use since rev. 1.220.

Cheers,
Fabian


Index: sbin/ifconfig/ifconfig.c
===
--- sbin/ifconfig/ifconfig.c.orig
+++ sbin/ifconfig/ifconfig.c
@@ -604,7 +604,6 @@ main(int argc, char *argv[])
int Cflag = 0;
int gflag = 0;
int i;
-   int noprint = 0;
 
/* If no args at all, print all interfaces.  */
if (argc < 2) {
@@ -760,7 +759,7 @@ nextarg:
argc--, argv++;
}
 
-   if (argc == 0 && actions == 0 && !noprint) {
+   if (argc == 0 && actions == 0) {
printif(ifr.ifr_name, aflag ? ifaliases : 1);
exit(0);
}

Re: allocation simplifications in yacc

[Ted Unangst]

Michael McConville wrote:
> Christian Weisgerber wrote:
> > Christian Weisgerber:
> > 
> > > The removal of the casts causes a problem in ports/devel/mico, where
> > > the yacc output is used in C++:
> > 
> > Also:
> >   graphics/grap
> >   math/aamath
> >   math/logic2cnf
> 
> ok?
>   "goto bail;",
> - "newvs = realloc(yyvs, newsize * sizeof(*newvs)); /* overflow check 
> above */",
> + "newvs = (short *)realloc(yyvs, newsize * sizeof(*newvs)); /* 
> overflow check above */",

no, newvs isn't a short. but i alread fixed it.

Add C11 stdalign.h and stdnoreturn.h

[Michal Mazurek]

I used n1570 for C11: http://www.iso-9899.info/n1570.html
and n3242 for C++11: 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf

C11:
stdalign.h:
7.15.1: The header  defines four macros.
7.15.2: The macro
alignas
expands to _Alignas; the macro
alignof
expands to _Alignof.

7.15.3: The remaining macros are suitable for use in #if preprocessing
directives. They are
__alignas_is_defined
and
__alignof_is_defined
which both expand to the integer constant 1.

stdnoreturn.h:
7.23.1: The header  defines the macro
noreturn
which expands to _Noreturn.

C++11:
stdalign.h:
18.10.2: The contents of these headers are the same as the Standard C library
 headers (...)  (...) respectively, with the following 
changes:
18.10.6: The header  and the header  shall not define a
 macro named alignas.

No mention of stdnoreturn.h.


Note that C++11 does not mention "alignof", even though it mentions
"alignas". Both are defined as keywords (Table 4 - Keywords).

A commit in Clang has this to say:

libstdc++'s  #includes  and expects it to guard 
against
being included in C++. Don't define alignof or alignas in this case.  Note 
that
the C++11 standard is broken in various ways here (it refers to the contents
of  in C99, where that header did not exist, and doesn't mention
the alignas macro at all), but we do our best to do what it intended.

So I went ahead and followed Clang, not C++11.

Clang's stdnoreturn.h differs from the standard as well, as it defines
"__noreturn_is_defined". I couldn't find a reason, so I didn't.

stdnoreturn.h isn't mentioned in C++11, so skip the #ifndef __cplusplus.


The commit message in FreeBSD that contains these files notes: "Even
though these header files make little sense to me, they are part of the
standard.". I believe these headers are defined to preserve backwards
compatibility. There might exist code where the keywords "alignas", "alignof",
and "noreturn" are already defined. The standard therefore picked keywords
from the reserved namespace, i.e. ones starting with an underscore
and an upper case letter and provided the headers for convenience.


And also make whitespace in stdbool.h consistent with other files.


Index: include/Makefile
===
RCS file: /cvs/src/include/Makefile,v
retrieving revision 1.208
diff -u -p -r1.208 Makefile
--- include/Makefile18 Nov 2015 16:48:34 -  1.208
+++ include/Makefile30 Dec 2015 16:43:53 -
@@ -17,8 +17,8 @@ FILES=a.out.h ar.h asr.h assert.h bitst
md5.h memory.h ndbm.h netdb.h netgroup.h nlist.h nl_types.h \
paths.h poll.h pwd.h ranlib.h readpassphrase.h regex.h \
resolv.h rmd160.h search.h setjmp.h sha1.h sha2.h signal.h siphash.h \
-   sndio.h \
-   spawn.h stdbool.h stddef.h stdio.h stdlib.h string.h strings.h struct.h 
\
+   sndio.h spawn.h stdalign.h stdbool.h stddef.h stdio.h stdlib.h \
+   stdnoreturn.h string.h strings.h struct.h \
sysexits.h tar.h tgmath.h time.h ttyent.h unistd.h utime.h \
utmp.h uuid.h vis.h wchar.h wctype.h
 
Index: include/stdalign.h
===
RCS file: include/stdalign.h
diff -N include/stdalign.h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ include/stdalign.h  30 Dec 2015 16:43:53 -
@@ -0,0 +1,18 @@
+/* $OpenBSD$   */
+
+/*
+ * Public domain.
+ */
+
+#ifndef_STDALIGN_H_
+#define_STDALIGN_H_
+
+#ifndef __cplusplus
+#define alignas _Alignas
+#define alignof _Alignof
+#endif
+
+#define __alignas_is_defined 1
+#define __alignof_is_defined 1
+
+#endif /* _STDALIGN_H_ */
Index: include/stdbool.h
===
RCS file: /cvs/src/include/stdbool.h,v
retrieving revision 1.7
diff -u -p -r1.7 stdbool.h
--- include/stdbool.h   4 Sep 2015 23:47:09 -   1.7
+++ include/stdbool.h   30 Dec 2015 16:43:53 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: stdbool.h,v 1.7 2015/09/04 23:47:09 daniel Exp $ */
+/* $OpenBSD: stdbool.h,v 1.7 2015/09/04 23:47:09 daniel Exp $  */
 
 /*
  * Written by Marc Espie, September 25, 1999
Index: include/stdnoreturn.h
===
RCS file: include/stdnoreturn.h
diff -N include/stdnoreturn.h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ include/stdnoreturn.h   30 Dec 2015 16:43:53 -
@@ -0,0 +1,12 @@
+/* $OpenBSD$   */
+
+/*
+ * Public domain.
+ */
+
+#ifndef_STDNORETURN_H_
+#define_STDNORETURN_H_ 
+
+#define noreturn _Noreturn
+
+#endif /* _STDNORETURN_H_ */

-- 
Michal Mazurek

xr mktime

[Ted Unangst]

Neither strftime nor strptime describe the fields inside struct tm, and while
they eventually point that way in references, strftime provides no guidance as
to which of its nine (9!) references I should read next. I don't like
guessing.


Index: strftime.3
===
RCS file: /cvs/src/lib/libc/time/strftime.3,v
retrieving revision 1.34
diff -u -p -r1.34 strftime.3
--- strftime.3  29 Jan 2015 01:46:31 -  1.34
+++ strftime.3  30 Dec 2015 16:46:29 -
@@ -47,6 +47,8 @@ The
 .Fn strftime
 function formats the information from
 .Fa timeptr
+(as described in
+.Xr mktime 3 )
 into the buffer
 .Fa buf
 according to the string pointed to by
Index: strptime.3
===
RCS file: /cvs/src/lib/libc/time/strptime.3,v
retrieving revision 1.24
diff -u -p -r1.24 strptime.3
--- strptime.3  4 Dec 2014 00:10:40 -   1.24
+++ strptime.3  30 Dec 2015 16:47:17 -
@@ -44,7 +44,9 @@ function parses the string
 according to the specified
 .Fa format
 and fills matching data into the structure
-.Fa tm .
+.Fa tm
+(described in
+.Xr mktime 3 ) .
 .Pp
 The
 .Fa format

Re: allocation simplifications in yacc

[Mark Kettenis]

> Date: Wed, 30 Dec 2015 11:30:11 -0500
> From: Michael McConville 
> 
> Christian Weisgerber wrote:
> > Christian Weisgerber:
> > 
> > > The removal of the casts causes a problem in ports/devel/mico, where
> > > the yacc output is used in C++:
> > 
> > Also:
> >   graphics/grap
> >   math/aamath
> >   math/logic2cnf
> 
> ok?

Please revert the diff.  Then propose a new diff that only changes the
NULL-check for free.

> Index: skeleton.c
> ===
> RCS file: /cvs/src/usr.bin/yacc/skeleton.c,v
> retrieving revision 1.36
> diff -u -p -r1.36 skeleton.c
> --- skeleton.c28 Dec 2015 19:14:04 -  1.36
> +++ skeleton.c30 Dec 2015 16:28:57 -
> @@ -137,14 +137,14 @@ char *body[] =
>   "#endif",
>   "if (newsize && YY_SIZE_MAX / newsize < sizeof *newss)",
>   "goto bail;",
> - "newss = realloc(yyss, newsize * sizeof(*newss)); /* overflow check 
> above */",
> + "newss = (short *)realloc(yyss, newsize * sizeof(*newss)); /* 
> overflow check above */",
>   "if (newss == NULL)",
>   "goto bail;",
>   "yyss = newss;",
>   "yyssp = newss + sslen;",
>   "if (newsize && YY_SIZE_MAX / newsize < sizeof *newvs)",
>   "goto bail;",
> - "newvs = realloc(yyvs, newsize * sizeof(*newvs)); /* overflow check 
> above */",
> + "newvs = (short *)realloc(yyvs, newsize * sizeof(*newvs)); /* 
> overflow check above */",
>   "if (newvs == NULL)",
>   "goto bail;",
>   "yyvs = newvs;",
> 
> 

Re: allocation simplifications in yacc

[Ted Unangst]

Mark Kettenis wrote:
> > Date: Wed, 30 Dec 2015 11:30:11 -0500
> > From: Michael McConville 
> > 
> > Christian Weisgerber wrote:
> > > Christian Weisgerber:
> > > 
> > > > The removal of the casts causes a problem in ports/devel/mico, where
> > > > the yacc output is used in C++:
> > > 
> > > Also:
> > >   graphics/grap
> > >   math/aamath
> > >   math/logic2cnf
> > 
> > ok?
> 
> Please revert the diff.  Then propose a new diff that only changes the
> NULL-check for free.

this shouldn't be necessary. i fixed the skeleton and checked it with c++.

Re: Add C11 stdalign.h and stdnoreturn.h

[Mark Kettenis]

This makes no sense as our base compiler doesn't support C11.

Re: Add C11 stdalign.h and stdnoreturn.h

[Todd C. Miller]

On Wed, 30 Dec 2015 18:07:32 +0100, Mark Kettenis wrote:

> This makes no sense as our base compiler doesn't support C11.

In other words, it has no underlying support for _Alignas or _Alignof
so this header could only be used by C compilers in ports.  I don't
think that's what we want...

 - todd

Re: allocation simplifications in yacc

[Michael McConville]

Christian Weisgerber wrote:
> Christian Weisgerber:
> 
> > The removal of the casts causes a problem in ports/devel/mico, where
> > the yacc output is used in C++:
> 
> Also:
>   graphics/grap
>   math/aamath
>   math/logic2cnf

ok?


Index: skeleton.c
===
RCS file: /cvs/src/usr.bin/yacc/skeleton.c,v
retrieving revision 1.36
diff -u -p -r1.36 skeleton.c
--- skeleton.c  28 Dec 2015 19:14:04 -  1.36
+++ skeleton.c  30 Dec 2015 16:28:57 -
@@ -137,14 +137,14 @@ char *body[] =
"#endif",
"if (newsize && YY_SIZE_MAX / newsize < sizeof *newss)",
"goto bail;",
-   "newss = realloc(yyss, newsize * sizeof(*newss)); /* overflow check 
above */",
+   "newss = (short *)realloc(yyss, newsize * sizeof(*newss)); /* 
overflow check above */",
"if (newss == NULL)",
"goto bail;",
"yyss = newss;",
"yyssp = newss + sslen;",
"if (newsize && YY_SIZE_MAX / newsize < sizeof *newvs)",
"goto bail;",
-   "newvs = realloc(yyvs, newsize * sizeof(*newvs)); /* overflow check 
above */",
+   "newvs = (short *)realloc(yyvs, newsize * sizeof(*newvs)); /* 
overflow check above */",
"if (newvs == NULL)",
"goto bail;",
"yyvs = newvs;",

Re: Declare usage() as __dead on fstat(1), plus a few nitpicks

[Theo Buehler]

On Wed, Dec 30, 2015 at 06:41:32PM +, Ricardo Mestre wrote:
> Declare usage() as __dead, and while here align a few variables to the rest of
> the list and also ANSI one function. No functional change.
> 
> OK?

ok tb@

> 
> Index: fstat.c
> ===
> RCS file: /cvs/src/usr.bin/fstat/fstat.c,v
> retrieving revision 1.84
> diff -u -p -u -r1.84 fstat.c
> --- fstat.c   17 Nov 2015 17:17:24 -  1.84
> +++ fstat.c   30 Dec 2015 18:35:29 -
> @@ -96,10 +96,10 @@ int   nflg;   /* (numerical) display f.s. an
>  int  oflg;   /* display file offset */
>  int  sflg;   /* display file xfer/bytes counters */
>  int  vflg;   /* display errors in locating kernel data objects etc... */
> -int  cflg;   /* fuser only */
> +int  cflg;   /* fuser only */
>  
> -int  fuser;  /* 1 if we are fuser, 0 if we are fstat */
> -int  signo;  /* signal to send (fuser only) */
> +int  fuser;  /* 1 if we are fuser, 0 if we are fstat */
> +int  signo;  /* signal to send (fuser only) */
>  
>  kvm_t *kd;
>  uid_t uid;
> @@ -107,7 +107,7 @@ uid_t uid;
>  void fstat_dofile(struct kinfo_file *);
>  void fstat_header(void);
>  void getinetproto(int);
> -void usage(void);
> +__dead void usage(void);
>  int getfname(char *);
>  void kqueuetrans(struct kinfo_file *);
>  void pipetrans(struct kinfo_file *);
> @@ -827,8 +827,7 @@ socktrans(struct kinfo_file *kf)
>   *   print name of protocol number
>   */
>  void
> -getinetproto(number)
> - int number;
> +getinetproto(int number)
>  {
>   static int isopen;
>   struct protoent *pe;
> 

OpenBSD 5.8 on Xeon-D (1540) systems

[Dale Ghent]

Has anyone used or otherwise been able to boot 5.8 on a Xeon-D 1540 system? 
We're experimenting with a SuperMicro Xeon-D 1540 system 
(http://www.supermicro.com/products/system/1U/5018/SYS-5018D-FN4T.cfm) and are, 
surprisingly, not getting terribly far into the kernel boot process, with a 
plethora of "... not configured" messages on console preceding a complete 
free-up after probing the xHCI root hub.

The "not configured" messages also apply to each of the 8 cores ("cpu at 
mainbus0: not configured"). The same thing happens with the latest snapshot 
(dated Dec. 27)

Here's a screenshot of the console showing how far the kernel gets before 
things grind to a halt: http://imgur.com/zETFs7j

Might anyone be able to drop a hint or some background info?

/dale


signature.asc
Description: Message signed with OpenPGP using GPGMail

Declare usage() as __dead on fstat(1), plus a few nitpicks

[Ricardo Mestre]

Declare usage() as __dead, and while here align a few variables to the rest of
the list and also ANSI one function. No functional change.

OK?

Index: fstat.c
===
RCS file: /cvs/src/usr.bin/fstat/fstat.c,v
retrieving revision 1.84
diff -u -p -u -r1.84 fstat.c
--- fstat.c 17 Nov 2015 17:17:24 -  1.84
+++ fstat.c 30 Dec 2015 18:35:29 -
@@ -96,10 +96,10 @@ int nflg;   /* (numerical) display f.s. an
 intoflg;   /* display file offset */
 intsflg;   /* display file xfer/bytes counters */
 intvflg;   /* display errors in locating kernel data objects etc... */
-intcflg;   /* fuser only */
+intcflg;   /* fuser only */
 
-intfuser;  /* 1 if we are fuser, 0 if we are fstat */
-intsigno;  /* signal to send (fuser only) */
+intfuser;  /* 1 if we are fuser, 0 if we are fstat */
+intsigno;  /* signal to send (fuser only) */
 
 kvm_t *kd;
 uid_t uid;
@@ -107,7 +107,7 @@ uid_t uid;
 void fstat_dofile(struct kinfo_file *);
 void fstat_header(void);
 void getinetproto(int);
-void usage(void);
+__dead void usage(void);
 int getfname(char *);
 void kqueuetrans(struct kinfo_file *);
 void pipetrans(struct kinfo_file *);
@@ -827,8 +827,7 @@ socktrans(struct kinfo_file *kf)
  * print name of protocol number
  */
 void
-getinetproto(number)
-   int number;
+getinetproto(int number)
 {
static int isopen;
struct protoent *pe;

Re: OpenBSD 5.8 on Xeon-D (1540) systems

[Mark Kettenis]

> From: Dale Ghent 
> Date: Wed, 30 Dec 2015 14:49:58 -0500
> 
> Has anyone used or otherwise been able to boot 5.8 on a Xeon-D 1540 =
> system? We're experimenting with a SuperMicro Xeon-D 1540 system =
> (http://www.supermicro.com/products/system/1U/5018/SYS-5018D-FN4T.cfm) =
> and are, surprisingly, not getting terribly far into the kernel boot =
> process, with a plethora of "... not configured" messages on console =
> preceding a complete free-up after probing the xHCI root hub.
> 
> The "not configured" messages also apply to each of the 8 cores ("cpu at =
> mainbus0: not configured"). The same thing happens with the latest =
> snapshot (dated Dec. 27)
> 
> Here's a screenshot of the console showing how far the kernel gets =
> before things grind to a halt: http://imgur.com/zETFs7j
> 
> Might anyone be able to drop a hint or some background info?

You could try disabing devices in UKC.  Boot your kernel with "boot
-c" at the boot> prompt, and at the UKC> prompt enter "disable
xhci"and "quit".  If that doesn't help, try disabling other devices as
well.

Cheers,

Mark

Re: utf8 input in el_gets(3)

[Christian Heckendorf]

Ingo Schwarze wrote:

> Hi Christian & Michael,
> 
> Michael McConville wrote on Thu, Dec 24, 2015 at 04:19:03PM -0500:
> > Christian Heckendorf wrote:
> 
> >> A couple of somewhat recent changes in NetBSD's libedit permit
> >> el_gets(3) to accept multibyte characters if the locale supports
> >> it.
> 
> Ugh.  The amount of indirection in that code is disturbing, and the
> amount of contortion is disgusting.  Such stuff is highly error
> prone, in particular since the manual is way below OpenBSD standards
> (functions mentioned in the SYNOPSIS but not actually documented,
> vague statements, confusion regarding bytes versus characters, ...).
> Besides, it's not completely clear which parts of the interface are
> public and which are internal to the library.
> 
> In the vicinity of this particular diff:  The IGNORE_EXTCHARS flag
> appears to be private to the library, the users seems to have no
> way to change it.  Otherwise, the existing code in el_getc(3)
> would already be broken because it clears the flag on exit even
> if it was set on entry.  But as an internal flag, it's completely
> pointless.  If CHARSET_IS_UTF8 is set, the present diff makes
> sure it is never set.  If CHARSET_IS_UTF8 is not set, it has no
> effect because the only place where it is used also checks "bytes > 1",
> which cannot happen in the C locale.
> 
> But if we want to stay in sync with upstream, freely borrowing Bob's
> whale flensing knife may not be the best idea.
> 
> Also note that el_gets(3) is documented to return the number of
> characters read, but actually, callers assume it returns the
> number of *bytes* read, so what your diff is doing makes sense.
> 
> Michael, as you already looked at NetBSD, is there a documentation
> update to go with this diff?
> 

I'll jump in here. As far as I can tell, the man entry for this
function describing the value of count hasn't been touched since
the original commit for the document in 1997 (before the wide
variants existed). I also found the documentation to be a source
of confusion.

Perhaps a change like this would help to clarify at least el_gets(3)
and el_wgets(3).

--
Christian


Index: editline.3
===
RCS file: /cvs/src/lib/libedit/editline.3,v
retrieving revision 1.39
diff -u -p -r1.39 editline.3
--- editline.3  14 Sep 2015 13:45:25 -  1.39
+++ editline.3  30 Dec 2015 20:07:59 -
@@ -208,7 +208,7 @@ state.
 .It Fn el_gets
 Read a line from the tty.
 .Fa count
-is modified to contain the number of characters read.
+is modified to contain the number of bytes read.
 Returns the line read if successful, or
 .Dv NULL
 if no characters were read or if an error occurred.
@@ -220,6 +220,13 @@ contains the error code that caused it.
 The return value may not remain valid across calls to
 .Fn el_gets
 and must be copied if the data is to be retained.
+.It Fn el_wgets
+Behaves the same way as
+.Fn el_gets
+except that
+.Fa count
+is modified to contain the number of wide characters read, rather
+than bytes.
 .It Fn el_getc
 Read a character from the tty.
 .Fa ch

Re: OpenBSD 5.8 on Xeon-D (1540) systems

[Dale Ghent]

I managed to get a slow-motion video of the console and transcribe the first 
several lines of CPU setup and probing from a verbose boot. It seems that the 
kernel isn't finding a lot of stuff here.

>>> bios probe won
bios0 at mainbus0: SMBIUOS rev. 2.8 @ 0xed8b0 (55 entries)
bios0: vendor American Megatrends Inc. version "1.0b" date 09/09/2015
bios0: Supermicro X10SDV-8C-TLN4F
>>> probing for mpbios0
>>> mpbios probe returned 0
>>> probing for acpi0
>>> acpi probe returned 1
>>> acpi probe won
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC FPDT FIDT SPMI NCFG UEFI HPET WDDT SSDT BGRT SSDT 
PRAD SMAR HEST BERT ERST EINJ
>>> probing for acpiec*
>>> acpiec probe returned 0
>>> probing for acpimadt0
>>> acpimadt probe returned 0
>>> probing for acpiprt*
>>> acpiprt returned 0
>>> no winning probe
>>> probing for acpiec*
>>> acpiec probe returned 0
>>> probing for acpimadt0
>>> acpimadt probe returned 0
>>> probing for acpiprt*
>>> acpiprt returned 0
>>> no winning probe
>>> probing for acpiec*
>>> acpiec probe returned 0
>>> probing for acpimadt0
>>> acpimadt probe returned 0
>>> probing for acpiprt*
>>> acpiprt returned 0
>>> acpimadt0 probe won
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
>>> probing for cpu0
>>> cpu probe returned 1
>>> probing for ioapic*
>>> ioapic probe returned 0
>>> probing for efifb0
>>> efifb probe returned 0
>>> probing for pci*
>>> pci probe returned 0
>>> probing for isa0
>>> isa probe returned 0
>>> cpu probe won
cpu0 at mainbus0: apid 0 (application processor)
cpu0: not started
>>> probing for ioapic*
>>> ioapic probe returned 0
>>> probing for efifb0
>>> efifb probe returned 0
>>> probing for pci*
>>> pci probe returned 0
>>> probing for isa0
>>> isa probe returned 0
>>> no winning probe
cpu at mainbus0: not configured
>>> probing for ioapic*
>>> ioapic probe returned 0
>>> probing for efifb0
>>> efifb probe returned 0
>>> probing for pci*
>>> pci probe returned 0

... and so on for each CPU.

> On Dec 30, 2015, at 2:49 PM, Dale Ghent  wrote:
> 
> 
> Has anyone used or otherwise been able to boot 5.8 on a Xeon-D 1540 system? 
> We're experimenting with a SuperMicro Xeon-D 1540 system 
> (http://www.supermicro.com/products/system/1U/5018/SYS-5018D-FN4T.cfm) and 
> are, surprisingly, not getting terribly far into the kernel boot process, 
> with a plethora of "... not configured" messages on console preceding a 
> complete free-up after probing the xHCI root hub.
> 
> The "not configured" messages also apply to each of the 8 cores ("cpu at 
> mainbus0: not configured"). The same thing happens with the latest snapshot 
> (dated Dec. 27)
> 
> Here's a screenshot of the console showing how far the kernel gets before 
> things grind to a halt: http://imgur.com/zETFs7j
> 
> Might anyone be able to drop a hint or some background info?
> 
> /dale



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: OpenBSD 5.8 on Xeon-D (1540) systems

[Dale Ghent]

> On Dec 30, 2015, at 3:21 PM, Mark Kettenis  wrote:
> 
>> From: Dale Ghent 
>> Date: Wed, 30 Dec 2015 14:49:58 -0500
>> 
>> Has anyone used or otherwise been able to boot 5.8 on a Xeon-D 1540 =
>> system? We're experimenting with a SuperMicro Xeon-D 1540 system =
>> (http://www.supermicro.com/products/system/1U/5018/SYS-5018D-FN4T.cfm) =
>> and are, surprisingly, not getting terribly far into the kernel boot =
>> process, with a plethora of "... not configured" messages on console =
>> preceding a complete free-up after probing the xHCI root hub.
>> 
>> The "not configured" messages also apply to each of the 8 cores ("cpu at =
>> mainbus0: not configured"). The same thing happens with the latest =
>> snapshot (dated Dec. 27)
>> 
>> Here's a screenshot of the console showing how far the kernel gets =
>> before things grind to a halt: http://imgur.com/zETFs7j
>> 
>> Might anyone be able to drop a hint or some background info?
> 
> You could try disabing devices in UKC.  Boot your kernel with "boot
> -c" at the boot> prompt, and at the UKC> prompt enter "disable
> xhci"and "quit".  If that doesn't help, try disabling other devices as
> well.

We've tried that route, but unfortunately there's not a whole lot in the BIOS 
options to turn off, including the USB controllers. I just replied to my 
original post with a transcription of the kernel messages when it tries to 
initially probe and set up the busses and cpus... clearly it isn't happy with 
something.

/dale


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: OpenBSD 5.8 on Xeon-D (1540) systems

[Mark Kettenis]

> From: Dale Ghent 
> Date: Wed, 30 Dec 2015 15:35:42 -0500
> 
> > On Dec 30, 2015, at 3:21 PM, Mark Kettenis  =
> wrote:
> >=20
> >> From: Dale Ghent 
> >> Date: Wed, 30 Dec 2015 14:49:58 -0500
> >>=20
> >> Has anyone used or otherwise been able to boot 5.8 on a Xeon-D 1540 =3D=
> 
> >> system? We're experimenting with a SuperMicro Xeon-D 1540 system =3D
> >> =
> (http://www.supermicro.com/products/system/1U/5018/SYS-5018D-FN4T.cfm) =3D=
> 
> >> and are, surprisingly, not getting terribly far into the kernel boot =
> =3D
> >> process, with a plethora of "... not configured" messages on console =
> =3D
> >> preceding a complete free-up after probing the xHCI root hub.
> >>=20
> >> The "not configured" messages also apply to each of the 8 cores ("cpu =
> at =3D
> >> mainbus0: not configured"). The same thing happens with the latest =3D
> >> snapshot (dated Dec. 27)
> >>=20
> >> Here's a screenshot of the console showing how far the kernel gets =3D
> >> before things grind to a halt: http://imgur.com/zETFs7j
> >>=20
> >> Might anyone be able to drop a hint or some background info?
> >=20
> > You could try disabing devices in UKC.  Boot your kernel with "boot
> > -c" at the boot> prompt, and at the UKC> prompt enter "disable
> > xhci"and "quit".  If that doesn't help, try disabling other devices as
> > well.
> 
> We've tried that route, but unfortunately there's not a whole lot in the =
> BIOS options to turn off, including the USB controllers. I just replied =
> to my original post with a transcription of the kernel messages when it =
> tries to initially probe and set up the busses and cpus... clearly it =
> isn't happy with something.

Read my message again. I'm suggesting to turn xhci off in the kernel,
not the BIOS.

Also, using a serial console could help catching afull dmesg.  Looks
like there is no physical serial port, but you can use the IPMI
SOL(serial-over-LAN).  Assuming console redirection to COM1 is enabled
in the bios. Enter "stty com1 115200" and "set tty com1" at the
OpenBSD bootloader boot> prompt to let the kernel use the serial port
as the console.

Cheers,

Mark

Re: malloc should always abort

[Thierry Deval]

​Hi Ted,

FWIW, I agree with malloc always failing on error.​

On Wed, Dec 30, 2015 at 7:12 AM, Ted Unangst  wrote:

> @@ -523,10 +521,8 @@ omalloc_init(struct dir_info **dp)
> mopts.malloc_cache >>= 1;
> break;
> case 'a':
> -   mopts.malloc_abort = 0;
> break;
> case 'A':
> -   mopts.malloc_abort = 1;
> break;
> case 'c':
> mopts.malloc_canaries = 0;
>

​I guess you will remove the option treatment ​in a near future ?  ;-)

On a side note, with this option var removal, you can collapse the switch
condition as :
@@ -523,10 +521,7 @@ omalloc_init(struct dir_info **dp)
mopts.malloc_cache >>= 1;
break;
case 'a':
-   mopts.malloc_abort = 0;
-   break;
case 'A':
-   mopts.malloc_abort = 1;
break;
case 'c':
mopts.malloc_canaries = 0;


​Thierry​

carp: fix SIOCSVH if carpr.carpr_carpdev is \0

[Fabian Raetz]

Hi tech@,

i've found the undocumented -carpdev option in ifconfig(8) which freezes
my sytem if executed.

As the -carpdev option is undocumented in both ifconfig(8) and carp(4) i
propose two patches to remove this functionality.

The patch below will return EINVAL in SIOCSVH if carpr.carpr_carpdev is not a
valid interface name.

I will send another patch to @tech to remove -carpdev from ifconfig(8)

Cheers,
Fabian


Index: ip_carp.c
===
RCS file: /cvs/src/sys/netinet/ip_carp.c,v
retrieving revision 1.284
diff -u -p -r1.284 ip_carp.c
--- ip_carp.c   19 Dec 2015 11:19:35 -  1.284
+++ ip_carp.c   30 Dec 2015 11:31:57 -
@@ -2022,8 +2022,7 @@ carp_ioctl(struct ifnet *ifp, u_long cmd
if ((error = copyin(ifr->ifr_data, , sizeof carpr)))
break;
error = 1;
-   if (carpr.carpr_carpdev[0] != '\0' &&
-   (ifp0 = ifunit(carpr.carpr_carpdev)) == NULL)
+   if ((ifp0 = ifunit(carpr.carpr_carpdev)) == NULL)
return (EINVAL);
if (carpr.carpr_peer.s_addr == 0)
sc->sc_peer.s_addr = INADDR_CARP_GROUP;

ifconfig: remove undocumented -carpdev

[Fabian Raetz]

Hi,

please find below a patch to remove the undocumented -carpdev command from
ifconfig(8).

Cheers,
Fabian


Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.311
diff -u -p -r1.311 ifconfig.c
--- ifconfig.c  10 Dec 2015 17:26:59 -  1.311
+++ ifconfig.c  30 Dec 2015 11:07:40 -
@@ -236,7 +236,6 @@ voidsetcarp_passwd(const char *, int);
 void   setcarp_vhid(const char *, int);
 void   setcarp_state(const char *, int);
 void   setcarpdev(const char *, int);
-void   unsetcarpdev(const char *, int);
 void   setcarp_nodes(const char *, int);
 void   setcarp_balancing(const char *, int);
 void   setpfsync_syncdev(const char *, int);
@@ -395,7 +394,6 @@ const structcmd {
{ "carpdev",NEXTARG,0,  setcarpdev },
{ "carpnodes",  NEXTARG,0,  setcarp_nodes },
{ "balancing",  NEXTARG,0,  setcarp_balancing },
-   { "-carpdev",   1,  0,  unsetcarpdev },
{ "syncdev",NEXTARG,0,  setpfsync_syncdev },
{ "-syncdev",   1,  0,  unsetpfsync_syncdev },
{ "syncif", NEXTARG,0,  setpfsync_syncdev },
@@ -4008,23 +4006,6 @@ setcarpdev(const char *val, int d)
err(1, "SIOCGVH");
 
strlcpy(carpr.carpr_carpdev, val, sizeof(carpr.carpr_carpdev));
-
-   if (ioctl(s, SIOCSVH, (caddr_t)) == -1)
-   err(1, "SIOCSVH");
-}
-
-void
-unsetcarpdev(const char *val, int d)
-{
-   struct carpreq carpr;
-
-   bzero(, sizeof(struct carpreq));
-   ifr.ifr_data = (caddr_t)
-
-   if (ioctl(s, SIOCGVH, (caddr_t)) == -1)
-   err(1, "SIOCGVH");
-
-   bzero(_carpdev, sizeof(carpr.carpr_carpdev));
 
if (ioctl(s, SIOCSVH, (caddr_t)) == -1)
err(1, "SIOCSVH");

Re: [patch] kern/exec_script: avoid invalid free() in a case of error

[Ted Unangst]

Michael McConville wrote:
> Michael McConville wrote:
> > Michael McConville wrote:
> > > > On Sun, Dec 13, 2015 at 9:45 PM, Maxim Pugachev  
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > In exec_script_makecmds function, when EXEC_HASFD flag was set, but
> > > > > copystr/copyinstr returns an error, we need to set *tmpsap to NULL to
> > > > > terminate a loop (under "fail" label) correctly.
> > > 
> > > I spent a while straining to see the forest through the trees, but this
> > > makes sense to me. ok mmcc@
> > > 
> > > Is this allocation chain idiom used elsewhere in sys/kern? Maybe we
> > > could break it out into ~3 functions. The current state of affairs seems
> > > bug-prone.
> > 
> > It seems that all possible paths through this nested condition increment
> > tmpsap. Why not just increment it afterward so no one else ends up with
> > the headache I now have?
> > 
> > As always: I could be misinterpreting this.
> 
> tedu and gsoares pointed out the nop expression in my last diff. I guess
> I was moving too fast...
> 
> Here's a new one:

this looks better to me.

Re: ksh another home/end pair

[Nicholas Marriott]

tmux is doing the right thing and changing what it generates would break
other programs.

ksh should use terminfo to work out what to expect, but we have always
resisted linking ksh against ncurses.

Your change is the best we can do without making ksh use ncurses.



On Wed, Dec 30, 2015 at 01:19:24AM -0500, Ted Unangst wrote:
> Mark Kettenis wrote:
> > > From: "Ted Unangst" 
> > > Date: Tue, 29 Dec 2015 12:11:25 -0500
> > > 
> > > In tmux, home and end send different bytes. I don't know why, but I want
> > > things to just work. We already have two different keys here, so what's 
> > > one
> > > more? (how many can there be...?)
> > 
> > Isn't that somehowa tmux bug?  I mean, isn't tmux supposed to be
> > compatible with some standard terminal type?
> 
> It could be. I don't know why tmux chooses a different set of bytes to
> represent home/end than xterm. I mostly don't care.
> 
> There was a thread on misc about this where it was suggested I either
> reconfigure ksh or tmux. Or both. But that's silly. This should work out of
> the box.
> 
> If somebody would like to propose a diff for tmux, I'd be happy with that, but
> I'm not sure where to begin myself. ksh already appears to be trying to
> support a nonconflicting superset of terminal types without resorting to
> termcap, so it seemed logical to fix here.
> 
> http://marc.info/?l=openbsd-misc=144906064413240=2
> 

Re: Another mpsafe ix(4) diff

[Hrvoje Popovski]

On 29.12.2015. 22:23, Hrvoje Popovski wrote:
> On 29.12.2015. 17:49, Mark Kettenis wrote:
>>> Date: Tue, 22 Dec 2015 23:45:49 +0100

 On 22.12.2015. 22:08, Mark Kettenis wrote:
>> Anybody willing to give this a spin?  I don't have access to hardware
>> currently...
>>
>> Thanks,
>>
>> Mark

 Hi,

 i'm sending 1.1Mpps and this patch almost immediately trigger OACTIVE
 flag. Patch is applied on clean source few minutes ago. If there is
 anything i can do more, please tell
>> ok, that diff wasn't quite right.  Here is a better one.  This one
>> gets rid of the ridiculous number of scatter segments on the 82598.
>> There really is no point in allowing that many segments, and with the
>> new code it would reduce the usable part of the tx ring significantly.
>>
>> I did some testing of forwarding performance on a machine with two
>> sockets filled with:
>>
>>   cpu0: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz, 2400.37 MHz
>>
>> for a total of 16 cores forwarding between ix1 and ix0:
>>
>>   ix0 at pci3 dev 0 function 0 "Intel X540T" rev 0x01: msi, address 
>> 0c:c4:7a:4d:a3:e4
>>   ix1 at pci3 dev 0 function 1 "Intel X540T" rev 0x01: msi, address 
>> 0c:c4:7a:4d:a3:e5
>>
>> I basically tested how many pps I could push through the box without
>> loss, and many pps got through if sent 1Mpps into the box.  All
>> testing was done with pf disabled.
>>
>> With -current I got the following numbers:
>>
>> - 730kpps without loss
>> - 82kpps when receiving 1Mpps
>>
>> and if I set net.inet.ip.ifq.maxlen to 8000 I got:
>>
>> - 740kpps without loss
>> - 640-740kpps when receiving 1Mpps (fluctuating)
>>
>> With this diff I got:
>>
>> - 670kpps without loss
>> - 250kpps when receiving 1Mpps
>>
>> and if I set net.inet.ip.ifq.maxlen to 8000 I got:
>>
>> - 690kpps without loss
>> - 680kpps when receiving 1Mpps (fluctuating)
>>
>> So the maximal throughput goes slightly down, but it seems it with the
>> diff it behaves betterunder load.
>>
>> Further tests are welcome!
> 
> 
> Hi,
> 
> i'm getting similar results with this patch. Sending 1Mpps and getting
> 750Kpps. I didn't see OACTIVE flag even when generating 14Mpps :)
> 
> PF=no
> ddb.console=1
> kern.pool_debug=0
> net.inet.ip.forwarding=1
> net.inet.ip.ifq.maxlen=8192
> kern.maxclusters=32768
> 
> One cpu...
> Intel(R) Xeon(R) CPU E5-2430 v2 @ 2.50GHz, 2800.01 MHz
> 
> ix0 at pci2 dev 0 function 0 "Intel 82599" rev 0x01: msi, address
> 90:e2:ba:33:af:ec
> ix1 at pci2 dev 0 function 1 "Intel 82599" rev 0x01: msi, address
> 90:e2:ba:33:af:ed
> 


just for fun i leave 14Mpps through box over night and ssh is alive,
very slow but it's alive ... and i'm getting stable 650Kpps without
OACTIVE flag ...

Re: ifconfig: remove undocumented -carpdev

[Sebastian Benoit]

Fabian Raetz(fabian.ra...@gmail.com) on 2015.12.30 13:32:54 +0100:
> On Wed, Dec 30, 2015 at 07:24:01AM -0500, Ted Unangst wrote:
> > Fabian Raetz wrote:
> > > Hi,
> > > 
> > > please find below a patch to remove the undocumented -carpdev command from
> > > ifconfig(8).
> > 
> > wouldn't it make more sense to document the command?
> 
> as the command is broken [0] and nobody noticed it so far, i'm
> wondering if anybody needs -carpdev
> 
> [0] https://www.marc.info/?l=openbsd-tech=145147632420539=2

-carpdev was valid back when you did not have to specify the device. Until
some time ago there was magic that chose the parent dev based on the ip on
the carp - the idea was that it must be in the same net as the parent.

This was removed (by mpi i think) to reduce complexety. So now you always
have to specify the carpdev.

I believe the option can go.

Re: ifconfig: remove undocumented -carpdev

[Fabian Raetz]

On Wed, Dec 30, 2015 at 07:24:01AM -0500, Ted Unangst wrote:
> Fabian Raetz wrote:
> > Hi,
> > 
> > please find below a patch to remove the undocumented -carpdev command from
> > ifconfig(8).
> 
> wouldn't it make more sense to document the command?

as the command is broken [0] and nobody noticed it so far, i'm
wondering if anybody needs -carpdev

[0] https://www.marc.info/?l=openbsd-tech=145147632420539=2

Re: allocation simplifications in yacc

[Christian Weisgerber]

Michael McConville:

> Index: skeleton.c
> ===
> RCS file: /cvs/src/usr.bin/yacc/skeleton.c,v
> retrieving revision 1.35
> diff -u -p -r1.35 skeleton.c
> --- skeleton.c16 Mar 2014 18:38:30 -  1.35
> +++ skeleton.c24 Dec 2015 17:34:02 -
> @@ -137,16 +137,14 @@ char *body[] =
>   "#endif",
>   "if (newsize && YY_SIZE_MAX / newsize < sizeof *newss)",
>   "goto bail;",
> - "newss = yyss ? (short *)realloc(yyss, newsize * sizeof *newss) :",
> - "  (short *)malloc(newsize * sizeof *newss); /* overflow check 
> above */",
> + "newss = realloc(yyss, newsize * sizeof(*newss)); /* overflow check 
> above */",
>   "if (newss == NULL)",
>   "goto bail;",
>   "yyss = newss;",
>   "yyssp = newss + sslen;",
>   "if (newsize && YY_SIZE_MAX / newsize < sizeof *newvs)",
>   "goto bail;",
> - "newvs = yyvs ? (YYSTYPE *)realloc(yyvs, newsize * sizeof *newvs) 
> :",
> - "  (YYSTYPE *)malloc(newsize * sizeof *newvs); /* overflow check 
> above */",
> + "newvs = realloc(yyvs, newsize * sizeof(*newvs)); /* overflow check 
> above */",
>   "if (newvs == NULL)",
>   "goto bail;",
>   "yyvs = newvs;",

The removal of the casts causes a problem in ports/devel/mico, where
the yacc output is used in C++:

c++  -I. -I../include  -Wall -Wwrite-strings -O2 -pipe -fno-strict-aliasing 
-D_REENTRANT -D_THREAD_SAFE-c yacc.cc -o yacc.o
yacc.c: In function 'int yygrowstack()':
yacc.c:1183: error: invalid conversion from 'void*' to 'short int*'
yacc.c:1190: error: invalid conversion from 'void*' to 'YYSTYPE*'
yacc.c: In function 'int yyparse()':
yacc.c:1280: warning: deprecated conversion from string constant to 'char*'
yacc.c:3528: warning: deprecated conversion from string constant to 'char*'

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: allocation simplifications in yacc

[Christian Weisgerber]

Christian Weisgerber:

> The removal of the casts causes a problem in ports/devel/mico, where
> the yacc output is used in C++:

Also:
  graphics/grap
  math/aamath
  math/logic2cnf

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Get PCI resources from ACPI

[Mark Kettenis]

It seems more and more server machines ship in a "64-bit"
configuration where the BIOS assigns addresses above the 4GB mark to
64-bit BARs.  We have a hack in arch/amd64/pci_machdep.c:pci_init_extents()
to deal with some of these configurations:

/*
 *  ...
 *
 * Dell 13G servers have important devices outside the
 * 36-bit address space.  Until we can extract the address
 * ranges from ACPI, expand the allowed range to suit.
 */

I ran into a SuperMicro machine that puts stuff even higher.  And
ratherthan extending the range again, I think it is time to bite the
bullet and trust ACPI.

The diff below is a first stab.  Needs a bit more polish, but before I
spend more time on it, I'd like to get some test results.  I'd like to
see the diff tested on a wide variety of machines.  Please send me old
and new dmesg and acpidump output.

Warning!  A kernel with this diff might panic early on in the boot
process, so don't play with it unless you have a way to boot your
previous kernel.


Index: acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.297
diff -u -p -r1.297 acpi.c
--- acpi.c  23 Nov 2015 00:10:53 -  1.297
+++ acpi.c  30 Dec 2015 13:03:38 -
@@ -561,6 +561,48 @@ acpi_matchhids(struct acpi_attach_args *
return (0);
 }
 
+int
+acpi_fill_memex(union acpi_resource *crs, void *arg)
+{
+   int type = AML_CRSTYPE(crs);
+   struct extent *ex = arg;
+   uint64_t min, max, len;
+   uint16_t flags;
+
+   switch (type) {
+   case LR_DWORD:
+   type = crs->lr_dword.type;
+   flags = crs->lr_dword.flags;
+   len = crs->lr_dword._len;
+   min = crs->lr_dword._min;
+   max = crs->lr_dword._max;
+   break;
+   case LR_QWORD:
+   type = crs->lr_qword.type;
+   flags = crs->lr_qword.flags;
+   len = crs->lr_qword._len;
+   min = crs->lr_qword._min;
+   max = crs->lr_qword._max;
+   break;
+   default:
+   return 0;
+   }
+
+   if (type != 0)
+   return 0;
+   if (len == 0)
+   return 0;
+   if ((flags & 0xc) != 0xc)
+   return 0;
+   if (min >= max)
+   return 0;
+   if (len != max - min + 1)
+   return 0;
+
+   extent_free(ex, min, len, EX_NOWAIT);
+   return 0;
+}
+
 /* Map ACPI device node to PCI */
 int
 acpi_getpci(struct aml_node *node, void *arg)
@@ -573,10 +615,17 @@ acpi_getpci(struct aml_node *node, void 
pcitag_t tag;
uint64_t val;
uint32_t reg;
+   int64_t sta = 0;
 
if (!node->value || node->value->type != AML_OBJTYPE_DEVICE)
return 0;
-   if (!aml_evalhid(node, )) {
+
+   /* Evaluate _STA to decide PCI Root node fate and walk fate */
+   if (aml_evalinteger(sc, node, "_STA", 0, NULL, ))
+   sta = STA_PRESENT | STA_ENABLED | STA_DEV_OK | 0x1000;
+
+   if ((sta & (STA_PRESENT|STA_ENABLED)) == (STA_PRESENT|STA_ENABLED) &&
+   !aml_evalhid(node, )) {
/* Check if this is a PCI Root node */
if (_acpi_matchhids(res.v_string, pcihid)) {
aml_freevalue();
@@ -603,6 +652,18 @@ acpi_getpci(struct aml_node *node, void 
dnprintf(10, "found PCI root: %s %d\n",
aml_nodename(node), pci->bus);
TAILQ_INSERT_TAIL(_pcirootdevs, pci, next);
+
+   pci->memex = extent_create("pcimem", 0, -1, M_DEVBUF, 
NULL, 0, EX_NOWAIT | EX_FILLED);
+   KASSERT(pci->memex != NULL);
+
+   if (aml_evalname(sc, node, "_CRS", 0, NULL, ) == 0) 
{
+   aml_parse_resource(, acpi_fill_memex, 
pci->memex);
+   aml_freevalue();
+   printf("bus %d\n", pci->bus);
+   extent_print(pci->memex);
+   if (pci->bus == 0)
+   pcimem_ex = pci->memex;
+   }
}
aml_freevalue();
return 0;
@@ -833,6 +894,7 @@ acpi_pciroots_attach(struct device *dev,
1, EX_NOWAIT) != 0)
continue;
pba->pba_bus = pdev->bus;
+   pba->pba_memex = pdev->memex;
config_found(dev, pba, pr);
}
 }
Index: amltypes.h
===
RCS file: /cvs/src/sys/dev/acpi/amltypes.h,v
retrieving revision 1.40
diff -u -p -r1.40 amltypes.h
--- amltypes.h  7 Sep 2012 19:19:59 -   1.40
+++ amltypes.h  30 Dec 2015 13:03:38 -
@@ -362,6 +362,8 @@ 

Re: malloc should always abort

[Theo Buehler]

On Wed, Dec 30, 2015 at 01:12:05AM -0500, Ted Unangst wrote:
> Long ago, malloc internally had two kinds of failures, warnings and errors.
> The 'A' option elevated warningst to errors, and has been the default for some
> time. But then warnings were effectively eliminated in favor of everything
> being an error, but then the 'a' flag turned errors into warnings!
> 
> 1. This is bad because it means unconditional failures can now be made
> conditional.
> 2. If you are using 'X' (not recommended imo) then the 'a' option effectively
> disables that as well because of the merger.
> 3. Nobody should be running with 'a' anyway.
> 
> We should remove the 'a' option. This diff does. There is now some redundant
> code left to handle wrterror() returning which can be removed next.
> 

This seems to be the natural reaction to the bug reported by Michal and
the one you fixed earlier today.  

ok tb@

> 
> Index: lib/libc/stdlib/malloc.3
> ===
> RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v
> retrieving revision 1.91
> diff -u -p -r1.91 malloc.3
> --- lib/libc/stdlib/malloc.3  14 Sep 2015 13:08:01 -  1.91
> +++ lib/libc/stdlib/malloc.3  30 Dec 2015 06:07:59 -
> @@ -345,10 +345,7 @@ or
>  detect an error condition,
>  a message will be printed to file descriptor
>  2 (not using stdio).
> -Errors will result in the process being aborted,
> -unless the
> -.Cm a
> -option has been specified.
> +Errors will result in the process being aborted.
>  .Pp
>  Here is a brief description of the error messages and what they mean:
>  .Bl -tag -width Ds
> Index: lib/libc/stdlib/malloc.c
> ===
> RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
> retrieving revision 1.179
> diff -u -p -r1.179 malloc.c
> --- lib/libc/stdlib/malloc.c  30 Dec 2015 06:04:39 -  1.179
> +++ lib/libc/stdlib/malloc.c  30 Dec 2015 06:08:00 -
> @@ -177,7 +177,6 @@ struct chunk_info {
>  
>  struct malloc_readonly {
>   struct dir_info *malloc_pool;   /* Main bookkeeping information */
> - int malloc_abort;   /* abort() on error */
>   int malloc_freenow; /* Free quickly - disable chunk rnd */
>   int malloc_freeunmap;   /* mprotect free pages PROT_NONE? */
>   int malloc_hint;/* call madvice on free pages?  */
> @@ -280,8 +279,8 @@ wrterror(char *msg, void *p)
>  #endif /* MALLOC_STATS */
>  
>   errno = saved_errno;
> - if (mopts.malloc_abort)
> - abort();
> +
> + abort();
>  }
>  
>  static void
> @@ -485,7 +484,6 @@ omalloc_init(struct dir_info **dp)
>   /*
>* Default options
>*/
> - mopts.malloc_abort = 1;
>   mopts.malloc_junk = 1;
>   mopts.malloc_move = 1;
>   mopts.malloc_cache = MALLOC_DEFAULT_CACHE;
> @@ -523,10 +521,8 @@ omalloc_init(struct dir_info **dp)
>   mopts.malloc_cache >>= 1;
>   break;
>   case 'a':
> - mopts.malloc_abort = 0;
>   break;
>   case 'A':
> - mopts.malloc_abort = 1;
>   break;
>   case 'c':
>   mopts.malloc_canaries = 0;
> Index: share/man/man5/malloc.conf.5
> ===
> RCS file: /cvs/src/share/man/man5/malloc.conf.5,v
> retrieving revision 1.2
> diff -u -p -r1.2 malloc.conf.5
> --- share/man/man5/malloc.conf.5  9 Dec 2015 14:09:50 -   1.2
> +++ share/man/man5/malloc.conf.5  30 Dec 2015 06:08:00 -
> @@ -35,14 +35,6 @@ and finally for the global variable
>  and scan them for flags in that order.
>  Flags are single letters, uppercase means on, lowercase means off.
>  .Bl -tag -width indent
> -.It Cm A
> -.Dq Abort .
> -.Xr malloc 3
> -will coredump the process, rather than tolerate internal
> -inconsistencies or incorrect usage.
> -This is the default and a very handy debugging aid,
> -since the core file represents the time of failure,
> -rather than when the bogus pointer was used.
>  .It Cm C
>  .Dq Canaries .
>  Add canaries at the end of allocations in order to detect
> 

mg(1) dired-find-alternate-file

[Mark Lumsden]

By shuffling find-alternate-file around we have
dired-find-alternate-file as well. ok?

-lum

Index: def.h
===
RCS file: /cvs/src/usr.bin/mg/def.h,v
retrieving revision 1.153
diff -u -p -u -p -r1.153 def.h
--- def.h   29 Dec 2015 19:44:32 -  1.153
+++ def.h   30 Dec 2015 13:20:35 -
@@ -377,6 +377,7 @@ int  makebkfile(int, int);
 int writeout(FILE **, struct buffer *, char *);
 voidupmodes(struct buffer *);
 size_t  xbasename(char *, const char *, size_t);
+int do_filevisitalt(char *);
 
 /* line.c X */
 struct line*lalloc(int);
Index: dired.c
===
RCS file: /cvs/src/usr.bin/mg/dired.c,v
retrieving revision 1.81
diff -u -p -u -p -r1.81 dired.c
--- dired.c 11 Dec 2015 20:21:23 -  1.81
+++ dired.c 30 Dec 2015 13:20:35 -
@@ -51,6 +51,7 @@ static int d_forwline(int, int);
 static int  d_backline(int, int);
 static int  d_killbuffer_cmd(int, int);
 static int  d_refreshbuffer(int, int);
+static int  d_filevisitalt(int, int);
 static void reaper(int);
 static struct buffer   *refreshbuffer(struct buffer *);
 static int  createlist(struct buffer *);
@@ -120,7 +121,9 @@ static PF diredcz[] = {
d_create_directory  /* + */
 };
 
-static PF diredc[] = {
+static PF direda[] = {
+   d_filevisitalt, /* a */
+   rescan, /* b */
d_copy, /* c */
d_del,  /* d */
d_findfile, /* e */
@@ -184,7 +187,7 @@ static struct KEYMAPE (7) diredmap = {
CCHR('Z'), '+', diredcz, (KEYMAP *) & metamap
},
{
-   'c', 'g', diredc, NULL
+   'a', 'g', direda, NULL
},
{
'n', 'x', diredn, NULL
@@ -838,6 +841,17 @@ d_backline (int f, int n)
 {
backline(f | FFRAND, n);
return (d_warpdot(curwp->w_dotp, >w_doto));
+}
+
+int
+d_filevisitalt (int f, int n)
+{
+   char fname[NFILEN];
+
+   if (d_makename(curwp->w_dotp, fname, sizeof(fname)) == ABORT)
+   return (FALSE);
+
+   return(do_filevisitalt(fname));
 }
 
 /*
Index: file.c
===
RCS file: /cvs/src/usr.bin/mg/file.c,v
retrieving revision 1.99
diff -u -p -u -p -r1.99 file.c
--- file.c  29 Oct 2015 19:46:47 -  1.99
+++ file.c  30 Dec 2015 13:20:35 -
@@ -94,9 +94,7 @@ filevisit(int f, int n)
 int
 filevisitalt(int f, int n)
 {
-   struct buffer   *bp;
-   char fname[NFILEN], *bufp, *adjf;
-   int  status;
+   char fname[NFILEN], *bufp, *fn;
 
if (getbufcwd(fname, sizeof(fname)) != TRUE)
fname[0] = '\0';
@@ -107,11 +105,23 @@ filevisitalt(int f, int n)
else if (bufp[0] == '\0')
return (FALSE);
 
+   fn = fname;
+
+   return (do_filevisitalt(fn));
+}
+
+int
+do_filevisitalt(char *fn)
+{
+   struct buffer   *bp;
+   int  status;
+   char*adjf;
+
status = killbuffer(curbp);
if (status == ABORT || status == FALSE)
return (ABORT);
 
-   adjf = adjustname(fname, TRUE);
+   adjf = adjustname(fn, TRUE);
if (adjf == NULL)
return (FALSE);
if (fisdir(adjf) == TRUE)
Index: mg.1
===
RCS file: /cvs/src/usr.bin/mg/mg.1,v
retrieving revision 1.99
diff -u -p -u -p -r1.99 mg.1
--- mg.129 Dec 2015 19:44:32 -  1.99
+++ mg.130 Dec 2015 13:20:35 -
@@ -952,6 +952,8 @@ dired-next-line
 dired-shell-command
 .It +
 dired-create-directory
+.It a
+dired-find-alternate-file
 .It c
 dired-do-copy
 .It d and C-d
@@ -988,6 +990,9 @@ Copy the file listed on the current line
 Delete the files that have been flagged for deletion.
 .It dired-do-rename
 Rename the file listed on the current line of the dired buffer.
+.It dired-find-alternate-file
+Replace the current dired buffer with an alternate one as specified
+by the position of the cursor.
 .It dired-find-file
 Open the file on the current line of the dired buffer.
 If the cursor is on a directory it will be opened in dired mode.

Re: pledge tokenadm(8)

[Alexander Bluhm]

On Wed, Dec 23, 2015 at 04:26:11PM +, Ricardo Mestre wrote:
> Hi tech@
> 
> tokenadm(8) pretty much needs almost the same pledge annotations as 
> login_token(8),
> "rpath wpath cpath fattr flock" for operations on the DB files and before that
> it also needs getpw due to calling getgrnam(3) to get the group (TOKEN_GROUP).
> In this case where both differ is that tokenadm(8) doesn't call 
> readpassphrase(3)
> and therefore it doesn't need tty.
> 
> Any comments?

Please move the pledge() line just before the while(getopt) loop.

otherwise OK bluhm@

> 
> Index: tokenadm.c
> ===
> RCS file: /cvs/src/usr.sbin/tokenadm/tokenadm.c,v
> retrieving revision 1.10
> diff -u -p -u -r1.10 tokenadm.c
> --- tokenadm.c16 Jan 2015 06:40:22 -  1.10
> +++ tokenadm.c23 Dec 2015 22:24:26 -
> @@ -167,6 +167,9 @@ main(int argc, char **argv)
>   goto usage;
>   }
>  
> + if (pledge("stdio rpath wpath cpath fattr flock getpw", NULL) == -1)
> + err(1, "pledge");
> +
>   if (what == LIST && (dmode || emode))
>   what = MODECH;

Re: ifconfig: remove undocumented -carpdev

[Ted Unangst]

Fabian Raetz wrote:
> Hi,
> 
> please find below a patch to remove the undocumented -carpdev command from
> ifconfig(8).

wouldn't it make more sense to document the command?

Re: ksh another home/end pair

[Christian Weisgerber]

On 2015-12-29, "Ted Unangst"  wrote:

> In tmux, home and end send different bytes. I don't know why, but I want
> things to just work. We already have two different keys here, so what's one
> more? (how many can there be...?)

We shouldn't have any there.  That's what termcap(3) is for.  If
you don't link to termcap, you don't get the functionality.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de