Re: [PATCH][src] share/man/man8/starttls.8 - use the new cert keyword

[Jason McIntyre]

On Wed, Jun 27, 2018 at 01:22:57AM +0100, Raf Czlonka wrote:
> Hi all,
> 
> The certificate keyword has been recently shortened to cert.
> 
> Regards,
> 
> Raf
> 

fixed, thanks.
jmc

> Index: share/man/man8/starttls.8
> ===
> RCS file: /cvs/src/share/man/man8/starttls.8,v
> retrieving revision 1.25
> diff -u -p -r1.25 starttls.8
> --- share/man/man8/starttls.8 11 Jun 2018 05:49:09 -  1.25
> +++ share/man/man8/starttls.8 27 Jun 2018 00:21:56 -
> @@ -143,7 +143,7 @@ For
>  it's as simple as adding pki configuration to
>  .Xr smtpd.conf 5 :
>  .Bd -literal -offset indent
> -pki mail.example.com certificate "/etc/ssl/mail.example.com.crt"
> +pki mail.example.com cert "/etc/ssl/mail.example.com.crt"
>  pki mail.example.com key "/etc/ssl/private/mail.example.com.key"
>  
>  listen on [...] tls pki mail.example.com auth
> 

Re: [PATCH] src/etc/root/root.mail - URLs -> URL

[Raf Czlonka]

Ping.

After installurl(5):

The /etc/installurl file contains a single line specifying
an OpenBSD mirror server URL, [...]

Cheers,

Raf

On Fri, Mar 30, 2018 at 11:05:44PM BST, Raf Czlonka wrote:
> Hi all,
> 
> A small typo - plural -> singular.
> 
> Regards,
> 
> Raf
> 
> Index: etc/root/root.mail
> ===
> RCS file: /cvs/src/etc/root/root.mail,v
> retrieving revision 1.127
> diff -u -p -r1.127 root.mail
> --- etc/root/root.mail23 Mar 2018 15:45:56 -  1.127
> +++ etc/root/root.mail30 Mar 2018 22:02:39 -
> @@ -27,7 +27,7 @@ find further information regarding confi
>  
>  Several popular binary packages (pre-compiled applications) are
>  available from mirror sites.  Mirror selection is usually automatic
> -during install/upgrade -- a mirror URLs from https://www.openbsd.org/ftp.html
> +during install/upgrade -- a mirror URL from https://www.openbsd.org/ftp.html
>  is stored into the file /etc/installurl.  Installation of packages is
>  as simple as:
>  

[PATCH][src] share/man/man8/starttls.8 - use the new cert keyword

[Raf Czlonka]

Hi all,

The certificate keyword has been recently shortened to cert.

Regards,

Raf

Index: share/man/man8/starttls.8
===
RCS file: /cvs/src/share/man/man8/starttls.8,v
retrieving revision 1.25
diff -u -p -r1.25 starttls.8
--- share/man/man8/starttls.8   11 Jun 2018 05:49:09 -  1.25
+++ share/man/man8/starttls.8   27 Jun 2018 00:21:56 -
@@ -143,7 +143,7 @@ For
 it's as simple as adding pki configuration to
 .Xr smtpd.conf 5 :
 .Bd -literal -offset indent
-pki mail.example.com certificate "/etc/ssl/mail.example.com.crt"
+pki mail.example.com cert "/etc/ssl/mail.example.com.crt"
 pki mail.example.com key "/etc/ssl/private/mail.example.com.key"
 
 listen on [...] tls pki mail.example.com auth

Re: libxshmfence.so.0.0 issues with latest snapshot?

[jungle Boogie]

On 26 June 2018 at 11:46, James Turner  wrote:
>
> I ran into the same issue. You can either wait for a new snapshot, or
> build X yourself following step 5 in release(8).
>

Thanks for the reply! I'll await the next snapshot.

> --
> James Turner



-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info

Re: libxshmfence.so.0.0 issues with latest snapshot?

[James Turner]

On Tue, Jun 26, 2018 at 10:59:09AM -0700, jungle Boogie wrote:
> Hi All,
> 
> Prior to updating to the latest snapshot (#56), I updated my packages,
> then updated to #56. Now X won't start and I have a library error:
> ls.so: X: can't load library libxshmfence.so.0.0
> 
> At the time of updating packages, there wasn't a new snapshot
> available so I felt it was safe to proceed.
> 
> What are my options at this point? Is this something others are also
> experiencing?
> 
> ---
> inum: 883510009027723
> sip: jungleboo...@sip2sip.info
> 

I ran into the same issue. You can either wait for a new snapshot, or
build X yourself following step 5 in release(8).

-- 
James Turner

libxshmfence.so.0.0 issues with latest snapshot?

[jungle Boogie]

Hi All,

Prior to updating to the latest snapshot (#56), I updated my packages,
then updated to #56. Now X won't start and I have a library error:
ls.so: X: can't load library libxshmfence.so.0.0

At the time of updating packages, there wasn't a new snapshot
available so I felt it was safe to proceed.

What are my options at this point? Is this something others are also
experiencing?




---
inum: 883510009027723
sip: jungleboo...@sip2sip.info

[diff] copyright notice index.html

[Mischa]

Hi @tech,

Just noticed index.html still has 2017 in the copyright notice.

Mischa

Index: index.html
===
RCS file: /cvs/www/index.html,v
retrieving revision 1.726
diff -r1.726 index.html
7c7
< 

Re: Test needed: Unlock 12 network-related syscalls

[Sebastian Benoit]

Mike Larkin(mlar...@azathoth.net) on 2018.06.25 19:31:40 -0700:
> On Mon, Jun 25, 2018 at 01:29:36PM +0200, Martin Pieuchot wrote:
> > On 20/06/18(Wed) 13:13, Martin Pieuchot wrote:
> > > Diff below unlocks the following syscalls:
> > > 
> > >   recvmsg(2), recvfrom(2), accept(2), getpeername(2), getsockname(2),
> > >   accept4(2), connect(2), bind(2), setsockopt(2), listen(2),
> > >   getsockopt(2), shutdown(2)
> > > 
> > > It doesn't mean that they won't run without the KERNEL_LOCK().  Instead
> > > a lock will be picked based on the socket type.  For Unix/pfkey/routing
> > > sockets it is still the KERNEL_LOCK().  That means the KERNEL_LOCK()
> > > will be taken a bit later in the syscall.  But for TCP/UDP sockets it
> > > will grab the NET_LOCK() instead, just like in sendto(2) and sendmsg(2).
> > > 
> > > Tests & oks welcome!
> > 
> > Anyone?
> > 
> 
> Tested on my surface book, no issues seen. Using -current plus this diff.

same here, fine in the past two days. machine runs relayd, bgpd etc...
 
> -ml
> 
> > Index: kern/syscalls.master
> > ===
> > RCS file: /cvs/src/sys/kern/syscalls.master,v
> > retrieving revision 1.182
> > diff -u -p -r1.182 syscalls.master
> > --- kern/syscalls.master20 Jun 2018 10:52:49 -  1.182
> > +++ kern/syscalls.master20 Jun 2018 11:06:20 -
> > @@ -88,18 +88,18 @@
> >  #else
> >  26 UNIMPL  ptrace
> >  #endif
> > -27 STD { ssize_t sys_recvmsg(int s, struct msghdr *msg, \
> > +27 STD NOLOCK  { ssize_t sys_recvmsg(int s, struct msghdr *msg, \
> > int flags); }
> >  28 STD NOLOCK  { ssize_t sys_sendmsg(int s, \
> > const struct msghdr *msg, int flags); }
> > -29 STD { ssize_t sys_recvfrom(int s, void *buf, size_t len, \
> > +29 STD NOLOCK  { ssize_t sys_recvfrom(int s, void *buf, size_t len, \
> > int flags, struct sockaddr *from, \
> > socklen_t *fromlenaddr); }
> > -30 STD { int sys_accept(int s, struct sockaddr *name, \
> > +30 STD NOLOCK  { int sys_accept(int s, struct sockaddr *name, \
> > socklen_t *anamelen); }
> > -31 STD { int sys_getpeername(int fdes, struct sockaddr *asa, \
> > +31 STD NOLOCK  { int sys_getpeername(int fdes, struct sockaddr *asa, \
> > socklen_t *alen); }
> > -32 STD { int sys_getsockname(int fdes, struct sockaddr *asa, \
> > +32 STD NOLOCK  { int sys_getsockname(int fdes, struct sockaddr *asa, \
> > socklen_t *alen); }
> >  33 STD { int sys_access(const char *path, int amode); }
> >  34 STD { int sys_chflags(const char *path, u_int flags); }
> > @@ -205,7 +205,7 @@
> >  91 STD { int sys_nanosleep(const struct timespec *rqtp, \
> > struct timespec *rmtp); }
> >  92 STD { int sys_fcntl(int fd, int cmd, ... void *arg); }
> > -93 STD { int sys_accept4(int s, struct sockaddr *name, \
> > +93 STD NOLOCK  { int sys_accept4(int s, struct sockaddr *name, \
> > socklen_t *anamelen, int flags); }
> >  94 STD { int sys___thrsleep(const volatile void *ident, \
> > clockid_t clock_id, const struct timespec *tp, \
> > @@ -213,18 +213,18 @@
> >  95 STD { int sys_fsync(int fd); }
> >  96 STD { int sys_setpriority(int which, id_t who, int prio); }
> >  97 STD NOLOCK  { int sys_socket(int domain, int type, int protocol); }
> > -98 STD { int sys_connect(int s, const struct sockaddr *name, \
> > +98 STD NOLOCK  { int sys_connect(int s, const struct sockaddr *name, \
> > socklen_t namelen); }
> >  99 STD { int sys_getdents(int fd, void *buf, size_t buflen); }
> >  100STD { int sys_getpriority(int which, id_t who); }
> >  101STD { int sys_pipe2(int *fdp, int flags); }
> >  102STD { int sys_dup3(int from, int to, int flags); }
> >  103STD { int sys_sigreturn(struct sigcontext 
> > *sigcntxp); }
> > -104STD { int sys_bind(int s, const struct sockaddr 
> > *name, \
> > +104STD NOLOCK  { int sys_bind(int s, const struct sockaddr 
> > *name, \
> > socklen_t namelen); }
> > -105STD { int sys_setsockopt(int s, int level, int 
> > name, \
> > +105STD NOLOCK  { int sys_setsockopt(int s, int level, int 
> > name, \
> > const void *val, socklen_t valsize); }
> > -106STD { int sys_listen(int s, int backlog); }
> > +106STD NOLOCK  { int sys_listen(int s, int backlog); }
> >  107STD { int sys_chflagsat(int fd, const char *path, \
> > u_int flags, int 

не могу занрузить консоль (перезагружается комп.) переустанавливал несколько раз ничего не помогает

[maksbiscuit]

 



--
Sent from: 
http://openbsd-archive.7691.n7.nabble.com/openbsd-dev-tech-f151936.html

Re: Test needed: Unlock 12 network-related syscalls

[Bruno Flueckiger]

On 26.06.18 11:47, Martin Pieuchot wrote:
> On 26/06/18(Tue) 10:46, Bruno Flueckiger wrote:
> > On 20.06.2018 13:13, Martin Pieuchot wrote:
> > > Diff below unlocks the following syscalls:
> > > 
> > >   recvmsg(2), recvfrom(2), accept(2), getpeername(2), getsockname(2),
> > >   accept4(2), connect(2), bind(2), setsockopt(2), listen(2),
> > >   getsockopt(2), shutdown(2)
> > > 
> > > It doesn't mean that they won't run without the KERNEL_LOCK().  Instead
> > > a lock will be picked based on the socket type.  For Unix/pfkey/routing
> > > sockets it is still the KERNEL_LOCK().  That means the KERNEL_LOCK()
> > > will be taken a bit later in the syscall.  But for TCP/UDP sockets it
> > > will grab the NET_LOCK() instead, just like in sendto(2) and sendmsg(2).
> > > 
> > > Tests & oks welcome!
> > 
> > Hi Martin,
> > 
> > I run your diff on my HP ProBook 450 G3 for some days now without problems.
> > The only thing to mention is that your diff seems to be incompatible with
> > the DRI3 diff from Mark Kettenis[1]. When I apply both diffs to the -current
> > kernel the kernel panics during boot:
> 
> I guess the diffs didn't apply cleanly.  You can now update your source
> -current an apply my diff only, do "make syscalls" and run the resulting
> kernel.
> 

Thanks for the info. This works now as expected. My system is running
with your patch.

Unlock pipe(2) and pipe2(2)

[Martin Pieuchot]

These syscalls do two operations: they allocate FDs and some buffers.
Thanks to the work done for sockets the file-related bits are now
mp-safe, so we can push the KERNEL_LOCK() down.

Diff below adds some KERNEL_LOCK/UNLOCK() dances around km_alloc(9) and
km_free(9).  It also makes some counters use atomic operations.

My goals for this diff are to prepare the terrain to unlock read(2) &
write(2) for pipes and push the KERNEL_LOCK() at UVM borders, to
hopefully motivate other hackers to push further down!

Index: kern/sys_pipe.c
===
RCS file: /cvs/src/sys/kern/sys_pipe.c,v
retrieving revision 1.81
diff -u -p -r1.81 sys_pipe.c
--- kern/sys_pipe.c 18 Jun 2018 09:15:05 -  1.81
+++ kern/sys_pipe.c 26 Jun 2018 10:27:51 -
@@ -91,8 +91,8 @@ struct filterops pipe_wfiltops =
  * Limit the number of "big" pipes
  */
 #define LIMITBIGPIPES  32
-int nbigpipe;
-static int amountpipekva;
+unsigned int nbigpipe;
+static unsigned int amountpipekva;
 
 struct pool pipe_pool;
 
@@ -214,7 +214,9 @@ pipespace(struct pipe *cpipe, u_int size
 {
caddr_t buffer;
 
+   KERNEL_LOCK();
buffer = km_alloc(size, _any, _pageable, _waitok);
+   KERNEL_UNLOCK();
if (buffer == NULL) {
return (ENOMEM);
}
@@ -227,7 +229,7 @@ pipespace(struct pipe *cpipe, u_int size
cpipe->pipe_buffer.out = 0;
cpipe->pipe_buffer.cnt = 0;
 
-   amountpipekva += cpipe->pipe_buffer.size;
+   atomic_add_int(, cpipe->pipe_buffer.size);
 
return (0);
 }
@@ -443,14 +445,13 @@ pipe_write(struct file *fp, off_t *poff,
 * If it is advantageous to resize the pipe buffer, do
 * so.
 */
-   if ((uio->uio_resid > PIPE_SIZE) &&
-   (nbigpipe < LIMITBIGPIPES) &&
+   if ((uio->uio_resid > PIPE_SIZE) && (nbigpipe < LIMITBIGPIPES) &&
(wpipe->pipe_buffer.size <= PIPE_SIZE) &&
(wpipe->pipe_buffer.cnt == 0)) {
 
if ((error = pipelock(wpipe)) == 0) {
if (pipespace(wpipe, BIG_PIPE_SIZE) == 0)
-   nbigpipe++;
+   atomic_inc_int();
pipeunlock(wpipe);
}
}
@@ -753,12 +754,15 @@ pipe_close(struct file *fp, struct proc 
 void
 pipe_free_kmem(struct pipe *cpipe)
 {
+   u_int size = cpipe->pipe_buffer.size;
+
if (cpipe->pipe_buffer.buffer != NULL) {
-   if (cpipe->pipe_buffer.size > PIPE_SIZE)
-   --nbigpipe;
-   amountpipekva -= cpipe->pipe_buffer.size;
-   km_free(cpipe->pipe_buffer.buffer, cpipe->pipe_buffer.size,
-   _any, _pageable);
+   if (size > PIPE_SIZE)
+   atomic_dec_int();
+   atomic_sub_int(, size);
+   KERNEL_LOCK();
+   km_free(cpipe->pipe_buffer.buffer, size, _any, _pageable);
+   KERNEL_UNLOCK();
cpipe->pipe_buffer.buffer = NULL;
}
 }
@@ -771,7 +775,6 @@ pipeclose(struct pipe *cpipe)
 {
struct pipe *ppipe;
if (cpipe) {
-   
pipeselwakeup(cpipe);
 
/*
Index: kern/syscalls.master
===
RCS file: /cvs/src/sys/kern/syscalls.master,v
retrieving revision 1.182
diff -u -p -r1.182 syscalls.master
--- kern/syscalls.master20 Jun 2018 10:52:49 -  1.182
+++ kern/syscalls.master26 Jun 2018 09:56:44 -
@@ -217,7 +217,7 @@
socklen_t namelen); }
 99 STD { int sys_getdents(int fd, void *buf, size_t buflen); }
 100STD { int sys_getpriority(int which, id_t who); }
-101STD { int sys_pipe2(int *fdp, int flags); }
+101STD NOLOCK  { int sys_pipe2(int *fdp, int flags); }
 102STD { int sys_dup3(int from, int to, int flags); }
 103STD { int sys_sigreturn(struct sigcontext *sigcntxp); }
 104STD { int sys_bind(int s, const struct sockaddr *name, \
@@ -447,7 +447,7 @@
 260UNIMPL
 261UNIMPL
 262UNIMPL
-263STD { int sys_pipe(int *fdp); }
+263STD NOLOCK  { int sys_pipe(int *fdp); }
 264STD { int sys_fhopen(const fhandle_t *fhp, int flags); }
 265UNIMPL
 266UNIMPL

Re: Test needed: Unlock 12 network-related syscalls

[Bruno Flueckiger]

On 20.06.2018 13:13, Martin Pieuchot wrote:

Diff below unlocks the following syscalls:

  recvmsg(2), recvfrom(2), accept(2), getpeername(2), getsockname(2),
  accept4(2), connect(2), bind(2), setsockopt(2), listen(2),
  getsockopt(2), shutdown(2)

It doesn't mean that they won't run without the KERNEL_LOCK().  Instead
a lock will be picked based on the socket type.  For Unix/pfkey/routing
sockets it is still the KERNEL_LOCK().  That means the KERNEL_LOCK()
will be taken a bit later in the syscall.  But for TCP/UDP sockets it
will grab the NET_LOCK() instead, just like in sendto(2) and 
sendmsg(2).


Tests & oks welcome!


Hi Martin,

I run your diff on my HP ProBook 450 G3 for some days now without 
problems. The only thing to mention is that your diff seems to be 
incompatible with the DRI3 diff from Mark Kettenis[1]. When I apply both 
diffs to the -current kernel the kernel panics during boot:


root on sda2a (f0b2020d2a12099d.a) swap on sd2b dump on sd2b
iwm0: hw rev 0x210, fw ver 16.242414.0, address 01:23:45:67:89:ab
panic: rw_enter: fdlock locking against myself
Stopped at  db_enter+0x12:  popq%r11
   TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
*451237  29199  0 0x1  00K init
db_enter() at db_enter+0x12
panic() at panic+0x138
_rw_enter(5cb404b46de93a98, ff041ffb0898,0,3) at _rw_enter+0x338
fdrelease(dd362798c66e5c5b,3) at fdrelease+0xfe
sys_close(359bdf7160fe01fb) at syscall+0x32a
Xsyscall_untramp(6,0,0,0,0,6) at Xsyscall_untramp+0xe4
end of kernel
end trace frame 0x7f7db9a0, count: 8

[1] https://marc.info/?l=openbsd-tech=152954666910012=2

Cheers,
Bruno



Index: kern/syscalls.master
===
RCS file: /cvs/src/sys/kern/syscalls.master,v
retrieving revision 1.182
diff -u -p -r1.182 syscalls.master
--- kern/syscalls.master20 Jun 2018 10:52:49 -  1.182
+++ kern/syscalls.master20 Jun 2018 11:04:05 -
@@ -88,18 +88,18 @@
 #else
 26 UNIMPL  ptrace
 #endif
-27 STD { ssize_t sys_recvmsg(int s, struct msghdr *msg, \
+27 STD NOLOCK  { ssize_t sys_recvmsg(int s, struct msghdr *msg, \
int flags); }
 28 STD NOLOCK  { ssize_t sys_sendmsg(int s, \
const struct msghdr *msg, int flags); }
-29 STD { ssize_t sys_recvfrom(int s, void *buf, size_t len, \
+29 STD NOLOCK  { ssize_t sys_recvfrom(int s, void *buf, size_t len, \
int flags, struct sockaddr *from, \
socklen_t *fromlenaddr); }
-30 STD { int sys_accept(int s, struct sockaddr *name, \
+30 STD NOLOCK  { int sys_accept(int s, struct sockaddr *name, \
socklen_t *anamelen); }
-31 STD { int sys_getpeername(int fdes, struct sockaddr *asa, \
+31 STD NOLOCK  { int sys_getpeername(int fdes, struct sockaddr *asa, \
socklen_t *alen); }
-32 STD { int sys_getsockname(int fdes, struct sockaddr *asa, \
+32 STD NOLOCK  { int sys_getsockname(int fdes, struct sockaddr *asa, \
socklen_t *alen); }
 33 STD { int sys_access(const char *path, int amode); }
 34 STD { int sys_chflags(const char *path, u_int flags); }
@@ -205,7 +205,7 @@
 91 STD { int sys_nanosleep(const struct timespec *rqtp, \
struct timespec *rmtp); }
 92 STD { int sys_fcntl(int fd, int cmd, ... void *arg); }
-93 STD { int sys_accept4(int s, struct sockaddr *name, \
+93 STD NOLOCK  { int sys_accept4(int s, struct sockaddr *name, \
socklen_t *anamelen, int flags); }
 94 STD { int sys___thrsleep(const volatile void *ident, \
clockid_t clock_id, const struct timespec *tp, \
@@ -213,18 +213,18 @@
 95 STD { int sys_fsync(int fd); }
 96 STD { int sys_setpriority(int which, id_t who, int prio); }
 97 STD NOLOCK  { int sys_socket(int domain, int type, int protocol); }
-98 STD { int sys_connect(int s, const struct sockaddr *name, \
+98 STD NOLOCK  { int sys_connect(int s, const struct sockaddr *name, \
socklen_t namelen); }
 99 STD { int sys_getdents(int fd, void *buf, size_t buflen); }
 100STD { int sys_getpriority(int which, id_t who); }
 101STD { int sys_pipe2(int *fdp, int flags); }
 102STD { int sys_dup3(int from, int to, int flags); }
 103STD { int sys_sigreturn(struct sigcontext *sigcntxp); }
-104STD { int sys_bind(int s, const struct sockaddr *name, \
+104STD NOLOCK  { int sys_bind(int s, const struct sockaddr *name, \
socklen_t namelen); }
-105 

Re: acpi: don't fail GPE handler re-registration

[Mark Kettenis]

> Date: Mon, 25 Jun 2018 21:02:38 -0700
> From: Mike Larkin 
> 
> Linux seems to permit GPE re-assignment (at least from what I can
> tell, the code is a bit convoluted). In the Surface Book AML,
> Microsoft provides an _L50 method as well as a _GPE method on the EC
> object that also returns 0x50.  This makes no sense, since EC GPEs
> must be edge-triggered (and an _Lxx method indicates a
> level-triggered GPE). What happens now is that we ignore the second
> GPE registration, meaning all EC GPEs get ignored.
> 
> This diff removes the -EBUSY return in that situation, allowing the second
> (and, I suppose, subsequent) GPEs to be registered properly.
> 
> With this diff, and another one not yet posted, I can get the EC on the
> Surface Book to actually generate events, which means we can support the 
> buttons and other events on this machine.
> 
> I am still not 100% convinced this is the right way to go. I have not yet
> unravelled all the Linux GPE code, but I'd like to see if the diff below
> breaks anyone, in case I decide to go this way. I have discussed this
> with kettenis@ and we can't come up with anything better at the moment.
> 
> Testing appreciated, look for "GPE xxx already enabled" in your dmesgs.

I think you should just commit this (keeping the printf).

ok kettenis@

> Index: acpi.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
> retrieving revision 1.345
> diff -u -p -a -u -r1.345 acpi.c
> --- acpi.c25 Jun 2018 22:33:24 -  1.345
> +++ acpi.c26 Jun 2018 03:36:10 -
> @@ -2186,10 +2186,9 @@ acpi_set_gpehandler(struct acpi_softc *s
>   ptbl = acpi_find_gpe(sc, gpe);
>   if (ptbl == NULL || handler == NULL)
>   return -EINVAL;
> - if (ptbl->handler != NULL) {
> - dnprintf(10, "error: GPE %.2x already enabled\n", gpe);
> - return -EBUSY;
> - }
> + if (ptbl->handler != NULL)
> + printf("%s: GPE %.2x already enabled\n", DEVNAME(sc), gpe);
> +
>   dnprintf(50, "Adding GPE handler %.2x (%s)\n", gpe, edge ? "edge" : 
> "level");
>   ptbl->handler = handler;
>   ptbl->arg = arg;
> 
>