Re: Virtual Machine Debian - problems with date/time updating

[David Coppa]

Il Sab 21 Ott 2023, 09:37 Luca Di Gregorio  ha scritto:

> Host:
> # uname -a
> OpenBSD xxx.my.domain 7.4 GENERIC.MP#1397 amd64
> # dmesg | egrep '(VMX/EPT|SVM/RVI)'
> vmm0 at mainbus0: VMX/EPT
> # vmctl show
>ID   PID VCPUS  MAXMEM  CURMEM TTYOWNERSTATE NAME
> 2 17798 11.0G519M   ttyp4 root  running debian
> 1 89226 11.0G   1006M   ttyp2 root  running obsd
>
> Guest debian:
> root@debian:~# lsb_release -a
> No LSB modules are available.
> Distributor ID: Debian
> Description:Debian GNU/Linux 12 (bookworm)
> Release:12
> Codename:   bookworm
>
> I see a strange behavior on the guest debian.
> With a simple 'sleep 2', I see that the sleep time is much more than 2
> secs.
> Can be observed with:
> root@debian:~# while [ 1 ]; do sleep 2; date; done
>
> On obsd guest, that is OpenBSD 7.4, sleep works as expected.
>
> Is this a bug of vmd?
>

You should try this: https://github.com/voutilad/vmm_clock

Ciao,
David

Re: HP nc2400 zzz or ZZZ does not work the last few snapshots

[David Coppa]

On Thu, Aug 31, 2017 at 3:39 PM, Eda Sky  wrote:
> Hi
>
> I use HP nc2400 i386 current from 15.7.2017? Before switching to clang.
>
> It worked fantastically zzz and ZZZ
> suspend several times a day to the last week
> After updating to current the system goes to sleep
> but it will freeze hard on awakening
> I tested 4 snapshots, last of 29.8.2017

Already fixed:

https://marc.info/?l=openbsd-cvs=150413713118158=2

Log message:
adjust ACPI resume-time saved stack location to account for a different
layout used by clang on i386. Also add a clarification to amd64's version
of the same (amd64 already had such an adjustment).

Ciao!
David

Re: radeon(4) drm crashing on current/amd64

[David Coppa]

On Wed, Jun 1, 2016 at 10:57 PM, Daniel Jakots <danj+o...@chown.me> wrote:
> On Fri, 27 May 2016 16:18:48 +0200, David Coppa <dco...@gmail.com>
> wrote:
>
>> On Fri, 27 May 2016, Carlin Bingham wrote:
>>
>> > On Fri, May 27, 2016 at 01:07:09AM +0200, Theo Buehler wrote:
>> > > On Thu, May 26, 2016 at 05:54:30PM -0400, Andre Smagin wrote:
>> > > > On Sat, 14 May 2016 21:01:29 +0200 (CEST)
>> > > > danj+o...@chown.me wrote:
>> > > >
>> > > > > >Synopsis:radeon(4) drm crashing on current/amd64
>> > > > [...]
>> > > > > drm:pid77501:radeon_fence_wait_empty_locked *ERROR* error
>> > > > > waiting for ring[3] to become idle (-1601868)
>> > > >
>> > > >
>> > > > I am seeing the same issue, very infrequently (may be once
>> > > > every week or two):
>> > > >
>> > > > drm:pid55825:radeon_fence_wait_empty_locked *ERROR* error
>> > > > waiting for ring[3] to become idle (-6007676) i3(49392):
>> > > > syscall 97 "inet"
>> > > >
>> > > > Not sure what happens to i3 as X crashes, but I get that pledge
>> > > > message every time. (Previously mentioned i3 to dcoppa, but
>> > > > before realizing it was related to radeon issue.)
>> > >
>> > > I combed through the i3 source code hoping to get an indication
>> > > what might be the cause for that socket(2) call breaking a pledge
>> > > promise i3. I couldn't find anything: all socket calls are with
>> > > AF_LOCAL that should be covered by the "unix" pledge.
>> > >
>> > > Without seeing a ktrace output, I don't think I can make any
>> > > progress here.
>> > >
>> >
>> > i3's restore_xcb_check_cb() (src/restore_layout.c), if it sees that
>> > the connection to X has been lost, it calls restore_connect() which
>> > calls libxcb's xcb_connect().
>> >
>> > In libxcb that calls xcb_connect_to_display_with_auth_info() which
>> > calls _xcb_open(), which calls _xcb_open_unix() and ususally that
>> > would be it, but if opening the unix socket fails (beause X has
>> > fallen over) it tries again to connect by calling _xcb_open_tcp()
>> > which sets up an AF_INET addrinfo and passes that to
>> > _xcb_socket()... and you can probably guess what happens next.
>>
>> Fallback code could be removed with no (imho) dramatic consequences.
>
> So I've been running with this code since saturday, no issue.
> It just died again and now I have at the end of my dmesg:
>
> drm:pid29592:radeon_fence_wait_empty_locked *ERROR* error waiting for ring[3] 
> to become idle (-1352594)
> xhci0: NULL xfer pointer
>
> So no more i3 pledge call :)
>
> FWIW, I was just browsing with chrome (and ironically, I was actually
> looking for a *ring* (I hope my gf doesn't read this ml :3)),
> with a bunch of terminator and with an instance of smplayer. Code run is
> -current, checked out and compiled about 5 hours ago.
>
>> Index: src/xcb_util.c
>> ===
>> RCS file: /cvs/xenocara/dist/libxcb/src/xcb_util.c,v
>> retrieving revision 1.11
>> diff -u -p -u -p -r1.11 xcb_util.c
>> --- src/xcb_util.c2 Feb 2016 18:42:22 -   1.11
>> +++ src/xcb_util.c27 May 2016 14:18:23 -
>> @@ -297,11 +297,6 @@ static int _xcb_open(const char *host, c
>>  fd = _xcb_open_unix(protocol, file);
>>  free(file);
>>
>> -if (fd < 0 && !protocol && *host == '\0') {
>> -unsigned short port = X_TCP_PORT + display;
>> -fd = _xcb_open_tcp(host, protocol, port);
>> -}
>> -
>>  return fd;
>>  #endif /* !_WIN32 */
>>  return -1; /* if control reaches here then something has gone
>> wrong */
>>
>

Here's upstream commit, FYI:

https://cgit.freedesktop.org/xcb/libxcb/commit/?id=7d235c62f0d5bd0df1236cc52141c10c5d272a18

unfortunately, there is no rationale...

Ciao!
David

Re: radeon(4) drm crashing on current/amd64

[David Coppa]

On Fri, 27 May 2016, Carlin Bingham wrote:

> On Fri, May 27, 2016 at 01:07:09AM +0200, Theo Buehler wrote:
> > On Thu, May 26, 2016 at 05:54:30PM -0400, Andre Smagin wrote:
> > > On Sat, 14 May 2016 21:01:29 +0200 (CEST)
> > > danj+o...@chown.me wrote:
> > > 
> > > > >Synopsis:  radeon(4) drm crashing on current/amd64
> > > [...]
> > > > drm:pid77501:radeon_fence_wait_empty_locked *ERROR* error waiting for 
> > > > ring[3] to become idle (-1601868)
> > > 
> > > 
> > > I am seeing the same issue, very infrequently (may be once every week or 
> > > two):
> > > 
> > > drm:pid55825:radeon_fence_wait_empty_locked *ERROR* error waiting for 
> > > ring[3] to become idle (-6007676)
> > > i3(49392): syscall 97 "inet"
> > > 
> > > Not sure what happens to i3 as X crashes, but I get that pledge message 
> > > every time.
> > > (Previously mentioned i3 to dcoppa, but before realizing it was related 
> > > to radeon issue.)
> > 
> > I combed through the i3 source code hoping to get an indication what
> > might be the cause for that socket(2) call breaking a pledge promise i3.
> > I couldn't find anything: all socket calls are with AF_LOCAL that should
> > be covered by the "unix" pledge.
> > 
> > Without seeing a ktrace output, I don't think I can make any progress
> > here.
> > 
> 
> i3's restore_xcb_check_cb() (src/restore_layout.c), if it sees that the
> connection to X has been lost, it calls restore_connect() which calls
> libxcb's xcb_connect().
> 
> In libxcb that calls xcb_connect_to_display_with_auth_info() which calls
> _xcb_open(), which calls _xcb_open_unix() and ususally that would be it,
> but if opening the unix socket fails (beause X has fallen over) it tries
> again to connect by calling _xcb_open_tcp() which sets up an AF_INET
> addrinfo and passes that to _xcb_socket()... and you can probably guess
> what happens next.

Fallback code could be removed with no (imho) dramatic consequences.

Index: src/xcb_util.c
===
RCS file: /cvs/xenocara/dist/libxcb/src/xcb_util.c,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 xcb_util.c
--- src/xcb_util.c  2 Feb 2016 18:42:22 -   1.11
+++ src/xcb_util.c  27 May 2016 14:18:23 -
@@ -297,11 +297,6 @@ static int _xcb_open(const char *host, c
 fd = _xcb_open_unix(protocol, file);
 free(file);
 
-if (fd < 0 && !protocol && *host == '\0') {
-unsigned short port = X_TCP_PORT + display;
-fd = _xcb_open_tcp(host, protocol, port);
-}
-
 return fd;
 #endif /* !_WIN32 */
 return -1; /* if control reaches here then something has gone wrong */

Re: Default OpenBSD 5.9 GCC 4.2.1 compiler segfaults when compiling a sample file

[David Coppa]

On Wed, May 25, 2016 at 1:18 PM, David Coppa <dco...@gmail.com> wrote:
> On Tue, 24 May 2016, Stefan Kempf wrote:
>
>> Hmm, looking closer at your bugzilla link, this somewhat larger diff
>> should also fix the same problem, but it was committed against GPLv2 sources.
>> Still need to try it though.
>>
>> https://gcc.gnu.org/ml/gcc-patches/2006-11/msg00206.html
>
> The larger diff works as well, just tested.
>
> Here's an adaptation for our tree:

Just did a 'make build' using the patched gcc: no problems encountered.

Cheers!
David

> Index: gnu/gcc/gcc/builtins.c
> ===
> RCS file: /cvs/src/gnu/gcc/gcc/builtins.c,v
> retrieving revision 1.7
> diff -u -p -u -p -r1.7 builtins.c
> --- gnu/gcc/gcc/builtins.c  28 Dec 2013 02:27:08 -  1.7
> +++ gnu/gcc/gcc/builtins.c  25 May 2016 10:45:39 -
> @@ -8614,13 +8614,8 @@ fold_builtin_isascii (tree arglist)
>arg = build2 (BIT_AND_EXPR, integer_type_node, arg,
> build_int_cst (NULL_TREE,
>~ (unsigned HOST_WIDE_INT) 0x7f));
> -  arg = fold_build2 (EQ_EXPR, integer_type_node,
> -arg, integer_zero_node);
> -
> -  if (in_gimple_form && !TREE_CONSTANT (arg))
> -   return NULL_TREE;
> -  else
> -   return arg;
> +  return fold_build2 (EQ_EXPR, integer_type_node,
> + arg, integer_zero_node);
>  }
>  }
>
> @@ -8663,12 +8658,8 @@ fold_builtin_isdigit (tree arglist)
>arg = fold_convert (unsigned_type_node, TREE_VALUE (arglist));
>arg = build2 (MINUS_EXPR, unsigned_type_node, arg,
> build_int_cst (unsigned_type_node, target_digit0));
> -  arg = fold_build2 (LE_EXPR, integer_type_node, arg,
> -build_int_cst (unsigned_type_node, 9));
> -  if (in_gimple_form && !TREE_CONSTANT (arg))
> -   return NULL_TREE;
> -  else
> -   return arg;
> +  return fold_build2 (LE_EXPR, integer_type_node, arg,
> + build_int_cst (unsigned_type_node, 9));
>  }
>  }
>
> Index: gnu/gcc/gcc/fold-const.c
> ===
> RCS file: /cvs/src/gnu/gcc/gcc/fold-const.c,v
> retrieving revision 1.1.1.1
> diff -u -p -u -p -r1.1.1.1 fold-const.c
> --- gnu/gcc/gcc/fold-const.c15 Oct 2009 17:11:28 -  1.1.1.1
> +++ gnu/gcc/gcc/fold-const.c25 May 2016 10:45:40 -
> @@ -6263,11 +6263,6 @@ fold_inf_compare (enum tree_code code, t
> return fold_build2 (neg ? GE_EXPR : LE_EXPR, type,
> arg0, build_real (TREE_TYPE (arg0), max));
>
> -  /* The transformation below creates non-gimple code and thus is
> -not appropriate if we are in gimple form.  */
> -  if (in_gimple_form)
> -   return NULL_TREE;
> -
>temp = fold_build2 (neg ? LT_EXPR : GT_EXPR, type,
>   arg0, build_real (TREE_TYPE (arg0), max));
>return fold_build1 (TRUTH_NOT_EXPR, type, temp);
> @@ -11215,8 +11210,7 @@ fold_binary (enum tree_code code, tree t
>   break;
> }
>
> -   else if (!in_gimple_form
> -&& TREE_INT_CST_HIGH (arg1) == signed_max_hi
> +   else if (TREE_INT_CST_HIGH (arg1) == signed_max_hi
>  && TREE_INT_CST_LOW (arg1) == signed_max_lo
>  && TYPE_UNSIGNED (TREE_TYPE (arg1))
>  /* signed_type does not work on pointer types.  */
> Index: gnu/gcc/gcc/tree-ssa-ccp.c
> ===
> RCS file: /cvs/src/gnu/gcc/gcc/tree-ssa-ccp.c,v
> retrieving revision 1.2
> diff -u -p -u -p -r1.2 tree-ssa-ccp.c
> --- gnu/gcc/gcc/tree-ssa-ccp.c  28 Dec 2013 02:27:08 -  1.2
> +++ gnu/gcc/gcc/tree-ssa-ccp.c  25 May 2016 10:45:40 -
> @@ -2063,13 +2063,15 @@ fold_stmt_r (tree *expr_p, int *walk_sub
>   tem = fold_binary (TREE_CODE (op0), TREE_TYPE (op0),
>  TREE_OPERAND (op0, 0),
>  TREE_OPERAND (op0, 1));
> - set = tem && is_gimple_condexpr (tem);
> + set = tem && set_rhs (expr_p, tem);
>   fold_undefer_overflow_warnings (set, fold_stmt_r_data->stmt, 0);
>   if (set)
> -   TREE_OPERAND (expr, 0) = tem;
> - t = expr;
> -  break;
> +   {
> + t = *expr_p;
> + break;
> +   }
>  }
> +  return NULL_TREE;
>
>  default:
>return NU

Re: Default OpenBSD 5.9 GCC 4.2.1 compiler segfaults when compiling a sample file

[David Coppa]

On Tue, 24 May 2016, Stefan Kempf wrote:

> Hmm, looking closer at your bugzilla link, this somewhat larger diff
> should also fix the same problem, but it was committed against GPLv2 sources.
> Still need to try it though.
> 
> https://gcc.gnu.org/ml/gcc-patches/2006-11/msg00206.html

The larger diff works as well, just tested.

Here's an adaptation for our tree:

Index: gnu/gcc/gcc/builtins.c
===
RCS file: /cvs/src/gnu/gcc/gcc/builtins.c,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 builtins.c
--- gnu/gcc/gcc/builtins.c  28 Dec 2013 02:27:08 -  1.7
+++ gnu/gcc/gcc/builtins.c  25 May 2016 10:45:39 -
@@ -8614,13 +8614,8 @@ fold_builtin_isascii (tree arglist)
   arg = build2 (BIT_AND_EXPR, integer_type_node, arg,
build_int_cst (NULL_TREE,
   ~ (unsigned HOST_WIDE_INT) 0x7f));
-  arg = fold_build2 (EQ_EXPR, integer_type_node,
-arg, integer_zero_node);
-
-  if (in_gimple_form && !TREE_CONSTANT (arg))
-   return NULL_TREE;
-  else
-   return arg;
+  return fold_build2 (EQ_EXPR, integer_type_node,
+ arg, integer_zero_node);
 }
 }
 
@@ -8663,12 +8658,8 @@ fold_builtin_isdigit (tree arglist)
   arg = fold_convert (unsigned_type_node, TREE_VALUE (arglist));
   arg = build2 (MINUS_EXPR, unsigned_type_node, arg,
build_int_cst (unsigned_type_node, target_digit0));
-  arg = fold_build2 (LE_EXPR, integer_type_node, arg,
-build_int_cst (unsigned_type_node, 9));
-  if (in_gimple_form && !TREE_CONSTANT (arg))
-   return NULL_TREE;
-  else
-   return arg;
+  return fold_build2 (LE_EXPR, integer_type_node, arg,
+ build_int_cst (unsigned_type_node, 9));
 }
 }
 
Index: gnu/gcc/gcc/fold-const.c
===
RCS file: /cvs/src/gnu/gcc/gcc/fold-const.c,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 fold-const.c
--- gnu/gcc/gcc/fold-const.c15 Oct 2009 17:11:28 -  1.1.1.1
+++ gnu/gcc/gcc/fold-const.c25 May 2016 10:45:40 -
@@ -6263,11 +6263,6 @@ fold_inf_compare (enum tree_code code, t
return fold_build2 (neg ? GE_EXPR : LE_EXPR, type,
arg0, build_real (TREE_TYPE (arg0), max));
 
-  /* The transformation below creates non-gimple code and thus is
-not appropriate if we are in gimple form.  */
-  if (in_gimple_form)
-   return NULL_TREE;
-
   temp = fold_build2 (neg ? LT_EXPR : GT_EXPR, type,
  arg0, build_real (TREE_TYPE (arg0), max));
   return fold_build1 (TRUTH_NOT_EXPR, type, temp);
@@ -11215,8 +11210,7 @@ fold_binary (enum tree_code code, tree t
  break;
}
 
-   else if (!in_gimple_form
-&& TREE_INT_CST_HIGH (arg1) == signed_max_hi
+   else if (TREE_INT_CST_HIGH (arg1) == signed_max_hi
 && TREE_INT_CST_LOW (arg1) == signed_max_lo
 && TYPE_UNSIGNED (TREE_TYPE (arg1))
 /* signed_type does not work on pointer types.  */
Index: gnu/gcc/gcc/tree-ssa-ccp.c
===
RCS file: /cvs/src/gnu/gcc/gcc/tree-ssa-ccp.c,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 tree-ssa-ccp.c
--- gnu/gcc/gcc/tree-ssa-ccp.c  28 Dec 2013 02:27:08 -  1.2
+++ gnu/gcc/gcc/tree-ssa-ccp.c  25 May 2016 10:45:40 -
@@ -2063,13 +2063,15 @@ fold_stmt_r (tree *expr_p, int *walk_sub
  tem = fold_binary (TREE_CODE (op0), TREE_TYPE (op0),
 TREE_OPERAND (op0, 0),
 TREE_OPERAND (op0, 1));
- set = tem && is_gimple_condexpr (tem);
+ set = tem && set_rhs (expr_p, tem);
  fold_undefer_overflow_warnings (set, fold_stmt_r_data->stmt, 0);
  if (set)
-   TREE_OPERAND (expr, 0) = tem;
- t = expr;
-  break;
+   {
+ t = *expr_p;
+ break;
+   }
 }
+  return NULL_TREE;
 
 default:
   return NULL_TREE;
Index: gnu/gcc/gcc/tree-ssa-propagate.c
===
RCS file: /cvs/src/gnu/gcc/gcc/tree-ssa-propagate.c,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 tree-ssa-propagate.c
--- gnu/gcc/gcc/tree-ssa-propagate.c15 Oct 2009 17:11:28 -  1.1.1.1
+++ gnu/gcc/gcc/tree-ssa-propagate.c25 May 2016 10:45:40 -
@@ -571,26 +571,73 @@ set_rhs (tree *stmt_p, tree expr)
   ssa_op_iter iter;
 
   /* Verify the constant folded result is valid gimple.  */
-  if (TREE_CODE_CLASS (code) == tcc_binary)
+  switch (TREE_CODE_CLASS (code))
 {
+case tcc_declaration:
+  if (!is_gimple_variable(expr))
+   return false;
+  break;
+
+case 

Re: Default OpenBSD 5.9 GCC 4.2.1 compiler segfaults when compiling a sample file

[David Coppa]

On Tue, May 24, 2016 at 4:42 PM, Stefan Kempf <sisnk...@gmail.com> wrote:
> David Coppa wrote:
>> On Tue, 24 May 2016, m...@extensibl.com wrote:
>>
>> > >Synopsis:  Default OpenBSD 5.9 GCC 4.2.1 compiler segfaults when 
>> > >compiling a sample file
>> > >Category:  system amd64
>> > >Environment:
>> > System  : OpenBSD 5.9
>> > Details : OpenBSD 5.9 (GENERIC) #1761: Fri Feb 26 01:15:04 MST 
>> > 2016
>> >  
>> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
>> >
>> > Architecture: OpenBSD.amd64
>> > Machine : amd64
>> > >Description:
>> > Default OpenBSD 5.9 GCC compiler segfaults when compiling a sample 
>> > file, included into the repository [1].
>> >
>> > [1]: https://github.com/extensibl/openbsd-gcc-4.2.1-segfault
>> >
>> > >How-To-Repeat:
>> > Follow README instructions in [1]. C sources, header files and GCC 
>> > -save-temps files are included.
>> >
>> > >Fix:
>> > Fix unknown. Workaround - use GCC 4.9.3 from packages.
>>
>> Hi,
>>
>> The gcc diff below fixes this ICE (already tested).
>>
>> I don't know if GPLv3 prevents us from merging this fix... As far
>> as I can see, it should be from before the license change.
>
> Looks like these two files were switched over to GPLv3 already when this
> commit was made :-(
>
> https://github.com/gcc-mirror/gcc/blob/59d1149a45706f3009604aeec8848fcddba13010/gcc/tree-ssa-propagate.c
> https://github.com/gcc-mirror/gcc/blob/59d1149a45706f3009604aeec8848fcddba13010/gcc/tree-ssa-ccp.c

Gosh... Do we have alternatives?

Re: Default OpenBSD 5.9 GCC 4.2.1 compiler segfaults when compiling a sample file

[David Coppa]

On Tue, 24 May 2016, m...@extensibl.com wrote:

> >Synopsis:  Default OpenBSD 5.9 GCC 4.2.1 compiler segfaults when 
> >compiling a sample file
> >Category:  system amd64
> >Environment:
> System  : OpenBSD 5.9
> Details : OpenBSD 5.9 (GENERIC) #1761: Fri Feb 26 01:15:04 MST 
> 2016
>  
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> 
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> Default OpenBSD 5.9 GCC compiler segfaults when compiling a sample 
> file, included into the repository [1].
> 
> [1]: https://github.com/extensibl/openbsd-gcc-4.2.1-segfault
> 
> >How-To-Repeat:
> Follow README instructions in [1]. C sources, header files and GCC 
> -save-temps files are included.
> 
> >Fix:
> Fix unknown. Workaround - use GCC 4.9.3 from packages.

Hi,

The gcc diff below fixes this ICE (already tested).

I don't know if GPLv3 prevents us from merging this fix... As far
as I can see, it should be from before the license change.

Here's the Bugzilla page: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32694

And the ViewVC one: 
https://gcc.gnu.org/viewcvs/gcc?view=revision=128766

Ciao!
David

Index: gnu/gcc/gcc/tree-ssa-ccp.c
===
RCS file: /cvs/src/gnu/gcc/gcc/tree-ssa-ccp.c,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 tree-ssa-ccp.c
--- gnu/gcc/gcc/tree-ssa-ccp.c  28 Dec 2013 02:27:08 -  1.2
+++ gnu/gcc/gcc/tree-ssa-ccp.c  24 May 2016 12:46:53 -
@@ -2063,12 +2063,13 @@ fold_stmt_r (tree *expr_p, int *walk_sub
  tem = fold_binary (TREE_CODE (op0), TREE_TYPE (op0),
 TREE_OPERAND (op0, 0),
 TREE_OPERAND (op0, 1));
- set = tem && is_gimple_condexpr (tem);
+ set = tem && set_rhs (expr_p, tem);
  fold_undefer_overflow_warnings (set, fold_stmt_r_data->stmt, 0);
  if (set)
-   TREE_OPERAND (expr, 0) = tem;
- t = expr;
-  break;
+   {
+ t = *expr_p;
+ break;
+   }
 }
 
 default:
Index: gnu/gcc/gcc/tree-ssa-propagate.c
===
RCS file: /cvs/src/gnu/gcc/gcc/tree-ssa-propagate.c,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 tree-ssa-propagate.c
--- gnu/gcc/gcc/tree-ssa-propagate.c15 Oct 2009 17:11:28 -  1.1.1.1
+++ gnu/gcc/gcc/tree-ssa-propagate.c24 May 2016 12:46:53 -
@@ -571,7 +571,8 @@ set_rhs (tree *stmt_p, tree expr)
   ssa_op_iter iter;
 
   /* Verify the constant folded result is valid gimple.  */
-  if (TREE_CODE_CLASS (code) == tcc_binary)
+  if (TREE_CODE_CLASS (code) == tcc_binary
+  || TREE_CODE_CLASS (code) == tcc_comparison)
 {
   if (!is_gimple_val (TREE_OPERAND (expr, 0))
  || !is_gimple_val (TREE_OPERAND (expr, 1)))

std::ifstream is broken on arm

[David Coppa]

The first bug was already reported three years ago:

http://marc.info/?l=openbsd-bugs=135732012310459

std::ifstream has a bug when linked with libpthread:

$ cat t1.cpp
#include 
#include 

int
main(void)
{
std::ifstream fin("/");
std::cout << (!fin ? "BUG" : "OK") << std::endl;
}

$ c++ t1.cpp -o t1
$ ./t1
OK
$ c++ t1.cpp -o t1 -lpthread
$ ./t1
BUG

And another one I stumbled upon yesterday:

$ cat t2.cpp
#include 
#include 

int
main(void)
{
std::ifstream fin("/tmp/nonexistent.txt");

if (!fin.is_open())
std::cout << "is_open failed!" << std::endl;

if(fin) {
std::cout << "OK!" << std::endl;
} else {
std::cout << "KO :(" << std::endl;
}
}

$ c++ t2.cpp -o t2
$ ./t2
is_open failed!
OK!

Both work fine with g++-4.9.3p3:

$ eg++ t1.cpp -o t1 -lpthread
$ ./t1
OK
$ eg++ t2.cpp -o t2
$ ./t2
is_open failed!
KO :(


The libpthread one breaks building CMake on arm:

---8<---

[100%] Built target pseudo_emulator
make -f Tests/RunCMake/CMakeFiles/pseudo_iwyu.dir/build.make 
Tests/RunCMake/CMakeFiles/pseudo_iwyu.dir/depend
cd /usr/ports/pobj/cmake-3.4.1/build-arm && 
/usr/ports/pobj/cmake-3.4.1/build-arm/Bootstrap.cmk/cmake -E cmake_depends 
"Unix Makefiles" /usr/ports/pobj/cmake-3.4.1/cmake-3.4.1 
/usr/ports/pobj/cmake-3.4.1/cmake-3.4.1/Tests/RunCMake 
/usr/ports/pobj/cmake-3.4.1/build-arm 
/usr/ports/pobj/cmake-3.4.1/build-arm/Tests/RunCMake 
/usr/ports/pobj/cmake-3.4.1/build-arm/Tests/RunCMake/CMakeFiles/pseudo_iwyu.dir/DependInfo.cmake
 --color=
make -f Tests/RunCMake/CMakeFiles/pseudo_iwyu.dir/build.make 
Tests/RunCMake/CMakeFiles/pseudo_iwyu.dir/build
[100%] Built target pseudo_iwyu
/usr/ports/pobj/cmake-3.4.1/build-arm/Bootstrap.cmk/cmake -E 
cmake_progress_start /usr/ports/pobj/cmake-3.4.1/build-arm/CMakeFiles 0
make -f CMakeFiles/Makefile2 preinstall
Install the project...
bin/cmake -P cmake_install.cmake
CMake Error: Could not find CMAKE_ROOT !!!
CMake has most likely not been installed correctly.
Modules directory not found in
/usr/ports/pobj/cmake-3.4.1/build-arm/share/cmake

---8<---

Because the code is as follows:

  // Install tree has "/bin/cmake" and "".
  std::string dir = cmSystemTools::GetFilenamePath(exe_dir);
  cmSystemToolsCMakeRoot = dir + CMAKE_DATA_DIR;
  if(!cmSystemTools::FileExists(
   (cmSystemToolsCMakeRoot+"/Modules/CMake.cmake").c_str()))
{
// Build tree has "/bin[/]/cmake" and
// "/CMakeFiles/CMakeSourceDir.txt".
std::string src_dir_txt = dir + "/CMakeFiles/CMakeSourceDir.txt";
cmsys::ifstream fin(src_dir_txt.c_str());
std::string src_dir;
if(fin && cmSystemTools::GetLineFromStream(fin, src_dir) &&
   cmSystemTools::FileIsDirectory(src_dir))
  {
  cmSystemToolsCMakeRoot = src_dir;
  }
else
  {
  dir = cmSystemTools::GetFilenamePath(dir);
  src_dir_txt = dir + "/CMakeFiles/CMakeSourceDir.txt";
  cmsys::ifstream fin2(src_dir_txt.c_str());
  if(fin2 && cmSystemTools::GetLineFromStream(fin2, src_dir) &&
 cmSystemTools::FileIsDirectory(src_dir))
{
cmSystemToolsCMakeRoot = src_dir;
}
  }
}

...And cmake is linked with -lpthread.

dmesg:

OpenBSD 5.9-beta (GENERIC) #163: Wed Jan  6 23:40:16 AEDT 2016
j...@armv7.jsg.id.au:/usr/src/sys/arch/armv7/compile/GENERIC
real mem  = 536870912 (512MB)
avail mem = 518381568 (494MB)
warning: no entropy supplied by boot loader
mainbus0 at root
cpu0 at mainbus0: ARM Cortex A8 R3 rev 2 (ARMv7 core)
cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu0: 32KB(64b/l,4way) I-cache, 32KB(64b/l,4way) wr-back D-cache
omap0 at mainbus0: TI AM335x BeagleBone
prcm0 at omap0 rev 0.2
sitaracm0 at omap0: control module, rev 1.0
intc0 at omap0 rev 5.0
edma0 at omap0 rev 0.0
dmtimer0 at omap0 rev 3.1
dmtimer1 at omap0 rev 3.1
omdog0 at omap0 rev 0.1
omgpio0 at omap0: rev 0.1
gpio0 at omgpio0: 32 pins
omgpio1 at omap0: rev 0.1
gpio1 at omgpio1: 32 pins
omgpio2 at omap0: rev 0.1
gpio2 at omgpio2: 32 pins
omgpio3 at omap0: rev 0.1
gpio3 at omgpio3: 32 pins
omap0: device tiiic unit 0 not configured
omap0: device tiiic unit 1 not configured
omap0: device tiiic unit 2 not configured
ommmc0 at omap0
sdmmc0 at ommmc0
ommmc1 at omap0
sdmmc1 at ommmc1
com0 at omap0: ti16750, 64 byte fifo
com0: console
cpsw0 at omap0: version 1.12 (0), address 78:a5:04:ca:1e:52
ukphy0 at cpsw0 phy 0: Generic IEEE 802.3u media interface, rev. 1: OUI 
0x0001f0, model 0x000f
scsibus0 at sdmmc1: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0:  SCSI2 0/direct fixed
sd0: 3688MB, 512 bytes/sector, 7553024 sectors
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
boot device: sd0
root on sd0a (39e9e648761e0797.a) swap on sd0b dump on sd0b

Re: System Hangs when Quitting X11 on Lenovo T450s

[David Coppa]

Il 22/set/2015 18:38, "Aaron Poffenberger"  ha scritto:
>
> On 09/22/15 10:34, Philip Guenther wrote:
>>
>> On Tue, 22 Sep 2015, Ted Unangst wrote:
>>>
>>> Aaron Poffenberger wrote:

   > Synopsis:   System Hangs when Quitting X11 on Lenovo T450s
   > Category:   X11
   > Environment:
 System  : OpenBSD 5.8
 Details : OpenBSD 5.8-current (GENERIC.MP) #1374: Sun Sep
20
 19:06:35 MDT 2015
  dera...@amd64.openbsd.org:
/usr/src/sys/arch/amd64/compile/GENERIC.MP

 Architecture: OpenBSD.amd64
 Machine : amd64
   > Description:
 When ending X11 ctrl-alt-backspace or clean quit in cwm via
CMS-q
 keybinding
 system hangs. Doesn't matter whether X11 was started via xdm
or startx
>>>
>>>
>>> until inteldrm supports broadwell video (hopefully not too much longer)
this
>>> is more or less expected.
>>
>>
>> For now the workaround is to switch to another virtual terminal and from
a
>> shell there kill the X server.
>>
>
> On the Lenovo it locks hard enough I can't get to another virtual
terminal. For those rare instances I want to end X switching first and
issuing `rcctl stop xdm` is safe.
>
> Cheers
>

http://marc.info/?l=openbsd-misc=143292037000646

Ciao,
David

Re: cwm CMS-q hang, T450s current

[David Coppa]

Il 27/lug/2015 20:09, Okan Demirmen o...@demirmen.com ha scritto:

 Hi - I gather this is the same if you quit fvwm, right? I suspect this
 is not window manager specific. Mind trying a more recent snapshot?

Indeed.
This is the infamous hang on exit with xserver, the vesa driver and Intel's
Broadwell gpu (it's a ThinkPad T450).

Ciao!
David

Re: fortune(6) attribute

[David Coppa]

On Sun, Dec 7, 2014 at 9:47 AM, Jason McIntyre j...@kerhand.co.uk wrote:
 On Sat, Dec 06, 2014 at 09:26:39AM +0001, Jason McIntyre wrote:
 hi! chasing down netbsd pr 49451:

   http://marc.info/?l=netbsd-bugsm=14121109930

 they've basically added an attribute to the following quote:

   Any sufficiently advanced technology is indistinguishable from a rigged
   demo.
   -- Andy Finkel, Commodore-Amiga Inc.

 the trouble is when i put it in a search engine i get just as many (more
 maybe) hits for a guy called james klass.

 anyone have anything definitive? of course, this may explain why there's
 currently no attribute ;)


 no feedback, so i don;t intend to add any attribute. i did zap the
 duplicate entry though.

Well... James Klass (http://en.wikipedia.org/wiki/James_Klass) passed
away in 2009.

But Andy Finkel is on Twitter (@aflyingcat) so, maybe, we could talk
about this with him in person...

Ciao,
David







-- 
If you try a few times and give up, you'll never get there. But if
you keep at it... There's a lot of problems in the world which can
really be solved by applying two or three times the persistence that
other people will.
-- Stewart Nelson

Re: Freeze when coredump in unexistant directory in tmpfs

[David Coppa]

On Wed, Nov 12, 2014 at 10:21 AM, Pedro Martelletto
pe...@ambientworks.net wrote:
 hi!

 the fix consists of disallowing file allocations on directories that
 have been removed (tn_links == 0). failure to enforce such a check can
 lead to the violation of the assumption that removed directories should
 not contain directory entries -- thus the triggered assertion:

 http://ambientworks.net/tmp/tmpfs_alloc_file.diff 
 http://ambientworks.net/tmp/tmpfs_alloc_file.diff

 thanks for the report!

 -p.

Please, someone should commit this to our tree...

Ciao,
David
-- 
If you try a few times and give up, you'll never get there. But if
you keep at it... There's a lot of problems in the world which can
really be solved by applying two or three times the persistence that
other people will.
-- Stewart Nelson

Re: tor segmentation fault on amd64 current

[David Coppa]

On Mon, Sep 29, 2014 at 10:59 PM, Stuart Henderson st...@openbsd.org wrote:
 As a test (not a permanent solution), try

 ln -s j /etc/malloc.conf

 If this unbreaks things, there is most likely a use-after-free,
 especially because the timing seems to match the time when the
 malloc defaults were toughened in libc.

 If it doesn't change anything (which actually, given your
 backtrace, seems likely) then maybe we should be looking at
 what has changed in libressl in that timeframe.


Still wasn't able to make tor-0.2.4.24 crash on my amd64 box, even
using babut's config file, with both privoxy or dante...

Ciao,
David
-- 
If you try a few times and give up, you'll never get there. But if
you keep at it... There's a lot of problems in the world which can
really be solved by applying two or three times the persistence that
other people will.
-- Stewart Nelson

Re: tor segmentation fault on amd64 current

[David Coppa]

On Tue, Sep 30, 2014 at 9:30 AM,  ba...@yandex.ru wrote:
 it sounds funny, but you are doing something wrong :) i simply have no
 place to make a mistake.
 on virtual machine(i use vmware) install _CURRENT_, install mc, install
 tor(.24 from ports), run tor- this is exactly what i did. crashed
 immediately after bootstrap done

What if you add:

---8---
ExitNodes {us}
StrictNodes 1
---8---

to your Tor configuration file?

Ciao,
David
-- 
If you try a few times and give up, you'll never get there. But if
you keep at it... There's a lot of problems in the world which can
really be solved by applying two or three times the persistence that
other people will.
-- Stewart Nelson

Re: tor segmentation fault on amd64 current

[David Coppa]

On Mon, Sep 29, 2014 at 10:50 AM,  ba...@yandex.ru wrote:

 #0  0x in ?? ()
 #1  0x086c5482561e in tor_free_ () from /usr/local/bin/tor
 #2  0x086c548257d0 in tor_free_ () from /usr/local/bin/tor
 #3  0x086eeb0f48cb in ssl3_get_client_hello (s=0x86f47efe000) at 
 /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s3_srvr.c:1119
 #4  0x086eeb0f5505 in ssl3_accept (s=0x86f47efe000) at 
 /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s3_srvr.c:346
 #5  0x086eeb0ed574 in ssl23_get_client_hello (s=0x86f47efe000) at 
 /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_srvr.c:573
 #6  0x086eeb0edd96 in ssl23_accept (s=0x86f47efe000) at 
 /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_srvr.c:232
 #7  0x086c54825b57 in tor_free_ () from /usr/local/bin/tor
 #8  0x086c547c203d in compare_vote_routerstatus_entries () from 
 /usr/local/bin/tor
 #9  0x086c547c24f0 in compare_vote_routerstatus_entries () from 
 /usr/local/bin/tor
 #10 0x086c547b2b8e in compare_vote_routerstatus_entries () from 
 /usr/local/bin/tor
 #11 0x086c547b3986 in compare_vote_routerstatus_entries () from 
 /usr/local/bin/tor
 #12 0x086c54714181 in ?? () from /usr/local/bin/tor
 #13 0x086e9e99c198 in event_base_loop (base=0x86ecbd78c00, flags=Variable 
 flags is not available.
 ) at /usr/src/lib/libevent/event.c:404
 #14 0x086c54711da2 in ?? () from /usr/local/bin/tor
 #15 0x086c54712155 in ?? () from /usr/local/bin/tor
 #16 0x086c54710311 in ?? () from /usr/local/bin/tor
 #17 0x in ?? ()

Recompiling tor with:

DEBUG=-g -O0 INSTALL_STRIP= make clean repackage reinstall

Would help a lot...

Ciao,
David
-- 
If you try a few times and give up, you'll never get there. But if
you keep at it... There's a lot of problems in the world which can
really be solved by applying two or three times the persistence that
other people will.
-- Stewart Nelson

Re: tor segmentation fault on amd64 current

[David Coppa]

On Mon, Sep 29, 2014 at 4:19 PM,  ba...@yandex.ru wrote:

This bug has already been fixed.

Please update your tor port to the latest version (0.2.4.24)

 Program received signal SIGSEGV, Segmentation fault.
 0x in ?? ()
 (gdb) bt
 #0  0x in ?? ()
 #1  0x18fdd39805a7 in prune_v2_cipher_list () at src/common/tortls.c:1501
 #2  0x18fdd398070d in tor_tls_classify_client_ciphers 
 (ssl=0x18ffe3611000, peer_ciphers=0x19003579a120) at src/common/tortls.c:1532


Ciao!
David
-- 
If you try a few times and give up, you'll never get there. But if
you keep at it... There's a lot of problems in the world which can
really be solved by applying two or three times the persistence that
other people will.
-- Stewart Nelson

Re: tor segmentation fault on amd64 current

[David Coppa]

On Mon, Sep 29, 2014 at 7:03 PM,  ba...@yandex.ru wrote:
 wonderful. it changes everything..

 ..or not?

Strange, since it does not crash on my machine with tor-0.2.4.24

Have you customized your /etc/tor/torrc?

How are you using tor? with polipo proxy or dante (socksify) ?

-- 
If you try a few times and give up, you'll never get there. But if
you keep at it... There's a lot of problems in the world which can
really be solved by applying two or three times the persistence that
other people will.
-- Stewart Nelson

Re: tor segmentation fault on amd64 current

[David Coppa]

On Mon, Sep 29, 2014 at 8:39 PM,  ba...@yandex.ru wrote:
 torrc:

 Nickname PESEC
 User _tor
 RunAsDaemon 0
 DataDirectory /etc/tor

I think this is wrong, because /etc/tor is owned by root (unless
you've changed it). DataDirectory should be /var/tor.

 Log notice stderr
 ControlPort 9052
 HashedControlPassword 
 16:1D8F742028892BCC606F92D4C57DA52D0FD7F8A78BDB77DB0549B5E184
 IPv6Exit 0
 AuthDirHasIPv6Connectivity 0
 ClientPreferIPv6ORPort 0
 ContactInfo ba...@yandex.ru
 RelayBandwidthRate 1 MB
 RelayBandwidthBurst 1.5 MB
 DirPort 9031
 SocksPort 9051
 SocksPolicy accept *
 ORPort 9002
 ExitPolicyRejectPrivate 1
 TrackHostExits .google.com, .google.ru


Another thing you should try is to remove the files under your
DataDirectory (I mean the cached-* files, keys, etc.) before starting
tor.

If even this doesn't work, increase verbosity (Log debug stderr) and
try to understand where/why it segfaults

Re: tor segmentation fault on current

[David Coppa]

On Tue, Sep 16, 2014 at 9:55 AM,  ba...@yandex.ru wrote:
 someone fix current pls. month passed

Congratulations, You won the prize for most useless bug report ever done.

Re: 12 seconds delay when starting X.org

[David Coppa]

On Fri, Apr 25, 2014 at 7:24 AM, Kārlis Miķelsons
karlis.mikels...@lf.lv wrote:
 Great.  Could you compile a kernel with the diff below applied and post
 its dmesg after starting Xorg. I'm guessing that the delay comes from
 the fact that we are re-probing for the touchpad protocol, but having
 this debug output would help.

 Thanks! I did, and this is what it looks like now:
 OpenBSD 5.5-current (GENERIC.MP) #0: Tue Apr 22 20:10:57 EEST 2014
 xxx@xxx:/usr/src/sys/arch/amd64/compile/GENERIC.MP


 Thanks, could you test the diff below and tell me if it fixes your
 issue?


 Thank you, Martin! This seems to have fixed the problem, Xorg starts up
 without any problems on my Dell E4310 after applying your patch.

Then ok dcoppa@, fwiw

cheers
David

Re: 12 seconds delay when starting X.org

[David Coppa]

On Thu, Apr 24, 2014 at 2:58 PM, Martin Pieuchot mpieuc...@nolizard.org wrote:
 On 22/04/14(Tue) 20:30, Kārlis Miķelsons wrote:
 Try to disable pms:
 
 # config -e -f /bsd
 UKCdisable pms
 
 And see if you can reproduce the problem.
 I can, after disabling pms device, X.org starts just fine.
 
 Great.  Could you compile a kernel with the diff below applied and post
 its dmesg after starting Xorg. I'm guessing that the delay comes from
 the fact that we are re-probing for the touchpad protocol, but having
 this debug output would help.

 Thanks! I did, and this is what it looks like now:
 OpenBSD 5.5-current (GENERIC.MP) #0: Tue Apr 22 20:10:57 EEST 2014
 xxx@xxx:/usr/src/sys/arch/amd64/compile/GENERIC.MP

 Thanks, could you test the diff below and tell me if it fixes your
 issue?

Yes, It fixes the issue on my DELL Latitude D630.

thanks  ciao!
David

Re: 12 seconds delay when starting X.org

[David Coppa]

On Tue, Apr 22, 2014 at 10:29 AM, Kārlis Miķelsons
karlis.mikels...@lf.lv wrote:
 It's the pms(4) driver. It happens on some Dell laptops that have a crappy
 non fully standard synaptics (alps?) touchpad.

 It seems so, today this laptop booted up without pms device for some reason,
 and without it X.org started up instantly.

Try to disable pms:

# config -e -f /bsd
UKCdisable pms

And see if you can reproduce the problem.

Re: ftp(1) progress meter mad

[David Coppa]

 From: Roman rsg...@ya.ru
 Date: Wed, Jan 29, 2014 at 12:05 PM
 Subject: ftp(1) progress meter mad
 To: bugs@openbsd.org
 
 
 Synopsis:  output of ftp command is ugly when it reads from pipe
 Category:  user
 Environment:
 System  : OpenBSD 5.5
 Details : OpenBSD 5.5-beta (GENERIC.MP) #225: Fri Jan 24
 12:16:08 MST 2014
 
 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
 
 Architecture: OpenBSD.i386
 Machine : i386
 Description: The progress meter of ftp command misses CR in the end of line
 and output is so ugly! Earlier it was ok, at least in 5.4-release.

 Works both in tty and in wide X terminal emulators.
 
 Fix: Sorry, I'm duck.

Thanks for your report.

The following diff fixes it.
It was a side-effect of the addition of -D to ftp(1).

ok?

Index: util.c
===
RCS file: /cvs/src/usr.bin/ftp/util.c,v
retrieving revision 1.65
diff -u -p -u -p -r1.65 util.c
--- util.c  23 Jan 2014 00:39:15 -  1.65
+++ util.c  29 Jan 2014 13:47:02 -
@@ -825,7 +825,7 @@ progressmeter(int flag, const char *file
overhead += 3;
}
snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf),
-   %-*.*s%s %3d%% , l, l, title,
+   \r%-*.*s%s %3d%% , l, l, title,
dotdot, ratio);
overhead += l + 1;
} else

Re: ftp(1) progress meter mad

[David Coppa]

 From: David Coppa dco...@gmail.com
 Date: Wed, Jan 29, 2014 at 3:01 PM
 Subject: Re: ftp(1) progress meter mad
 To: bugs@openbsd.org
 Cc: rsg...@ya.ru
 
 
 On Wed, Jan 29, 2014 at 2:52 PM, David Coppa dco...@openbsd.org wrote:
  From: Roman rsg...@ya.ru
  Date: Wed, Jan 29, 2014 at 12:05 PM
  Subject: ftp(1) progress meter mad
  To: bugs@openbsd.org
 
 
  Synopsis:  output of ftp command is ugly when it reads from pipe
  Category:  user
  Environment:
  System  : OpenBSD 5.5
  Details : OpenBSD 5.5-beta (GENERIC.MP) #225: Fri Jan 24
  12:16:08 MST 2014
 
  t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
 
  Architecture: OpenBSD.i386
  Machine : i386
  Description: The progress meter of ftp command misses CR in the end of 
  line
  and output is so ugly! Earlier it was ok, at least in 5.4-release.
 
  Works both in tty and in wide X terminal emulators.
 
  Fix: Sorry, I'm duck.
 
  Thanks for your report.
 
  The following diff fixes it.
  It was a side-effect of the addition of -D to ftp(1).
 
  ok?
 
 No. Please, forget this.

This should be ok:

Index: util.c
===
RCS file: /cvs/src/usr.bin/ftp/util.c,v
retrieving revision 1.65
diff -u -p -u -p -r1.65 util.c
--- util.c  23 Jan 2014 00:39:15 -  1.65
+++ util.c  29 Jan 2014 14:28:41 -
@@ -811,7 +811,7 @@ progressmeter(int flag, const char *file
dotdot);
overhead += l + 1;
} else
-   snprintf(buf, sizeof(buf), );
+   snprintf(buf, sizeof(buf), \r);
 
if (!verbose  title != NULL) {
int l = strlen(title);

Re: ftp(1) progress meter mad

[David Coppa]

On Wed, Jan 29, 2014 at 4:47 PM, Ted Unangst t...@tedunangst.com wrote:
 On Wed, Jan 29, 2014 at 08:27, David Coppa wrote:
 This should be ok:

 looks right.

I've committed my fix.

cheers,
David

Re: Kernel panic on current amd64 running under Ubuntu KVM (patch included)

[David Coppa]

On Mon, May 20, 2013 at 6:15 PM, Alexey E. Suslikov
alexey.susli...@gmail.com wrote:
 Mike Larkin mlarkin at azathoth.net writes:

 You're kidding, right?

 Could you guys tell what exactly wrong with FreeBSD/NetBSD approach?


Adding some silly workarounds to the kernel for a bug that is a *KVM bug*.

Re: ksh bug

[David Coppa]

On Thu, 24 Jan 2013, ja...@cieti.lv wrote:

 Hello!
 
 If I type r r in console or xterm, like:
 
 $ r r
 
 I get ksh.core. It works on i386 5.2 and amd64 current.

Sure?

I'm on amd64 -current and don't have this bug:

dcoppa@latitude:~$ r r
rm *orig
rm: *orig: No such file or directory
dcoppa@latitude:~$

Re: I found a 14-year old bug.

[David Coppa]

On Wed, Nov 21, 2012 at 2:57 PM, Bob Beck b...@obtuse.com wrote:
 Dude. There are many old bugs in there to find. Trust me.  Start reading
 code instead of shining turds

+1

cheers,
David

Re: Intel WiFi Link 130

[David Coppa]

diff please

On Sat, Aug 25, 2012 at 3:29 AM, X-user x-user2...@yandex.ru wrote:
 Add code to enable boot-time configuration of this device:

 file: src/sys/dev/pci/if_iwn.c, from line: 93
 [begin code]
 { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_100_2 },
 { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_130_1 },
 { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_130_2 }
 };
 [end code]

Re: intermittent crash

[David Coppa]

Il giorno 21/lug/2012 15:22, Stuart Henderson s...@spacehopper.org ha
scritto:

 On 2012/07/20 14:03, LEVAI Daniel wrote:
  Hi!
 
  It just crashed, didn't do anything fancy with it. I was connected with
  ssh to the machine when suddenly I got disconnected.

 http://marc.info/?l=openbsd-miscm=134072894816852w=2
 http://marc.info/?l=openbsd-miscm=134149317104627w=2
 http://arp.thrush.com/openbsd/pppoe/sys_net_if_spppsubr_c.diff

 Here's a version of the patch without the extra debug printf/logs.

 I don't see any regressions with this, I've manually triggered the
 code a couple of times, but don't really want to keep dropping my
 ADSL for a better test as the telco is likely to drop my sync speed
 if I do that.

 Any OKs?  I think this is safe enough to make release.

Here's one: ok for me.

Ciao,
David


 Index: if_spppsubr.c
 ===
 RCS file: /cvs/src/sys/net/if_spppsubr.c,v
 retrieving revision 1.96
 diff -u -p -r1.96 if_spppsubr.c
 --- if_spppsubr.c   28 Jan 2012 12:14:45 -  1.96
 +++ if_spppsubr.c   21 Jul 2012 13:10:24 -
 @@ -398,7 +398,7 @@ HIDE void sppp_qflush(struct ifqueue *if
  int sppp_update_gw_walker(struct radix_node *rn, void *arg, u_int);
  void sppp_update_gw(struct ifnet *ifp);
  HIDE void sppp_set_ip_addrs(void *, void *);
 -HIDE void sppp_clear_ip_addrs(struct sppp *sp);
 +HIDE void sppp_clear_ip_addrs(void *, void *);
  HIDE void sppp_set_phase(struct sppp *sp);

  /* our control protocol descriptors */
 @@ -3014,6 +3014,10 @@ struct sppp_set_ip_addrs_args {
 u_int32_t hisaddr;
  };

 +struct sppp_clear_ip_addrs_args {
 +   struct sppp *sp;
 +};
 +
  HIDE void
  sppp_ipcp_tlu(struct sppp *sp)
  {
 @@ -3096,9 +3100,22 @@ sppp_ipcp_tls(struct sppp *sp)
  HIDE void
  sppp_ipcp_tlf(struct sppp *sp)
  {
 +   struct ifnet *ifp = sp-pp_if;
 +   struct sppp_clear_ip_addrs_args *args;
 +
 +   args = malloc(sizeof(*args), M_TEMP, M_NOWAIT);
 +   if (args == NULL)
 +   return;
 +
 +   args-sp = sp;
 +
 if (sp-ipcp.flags  (IPCP_MYADDR_DYN|IPCP_HISADDR_DYN))
 /* Some address was dynamic, clear it again. */
 -   sppp_clear_ip_addrs(sp);
 +   if (workq_add_task(NULL, 0, sppp_clear_ip_addrs, args,
NULL)) {
 +   free(args, M_TEMP);
 +   printf(%s: workq_add_task failed, cannot clear 
 +   addresses\n, ifp-if_xname);
 +   }

 /* we no longer need LCP */
 sp-lcp.protos = ~(1  IDX_IPCP);
 @@ -4760,16 +4777,27 @@ sppp_set_ip_addrs(void *arg1, void *arg2
  }

  /*
 - * Clear IP addresses.  Must be called at splnet.
 + * Work queue task clearing addresses from process context.
 + * Clear IP addresses.
   */
  HIDE void
 -sppp_clear_ip_addrs(struct sppp *sp)
 +sppp_clear_ip_addrs(void *arg1, void *arg2)
  {
 +   struct sppp_clear_ip_addrs_args *args = arg1;
 +   struct sppp *sp = args-sp;
 struct ifnet *ifp = sp-pp_if;
 +   int debug = ifp-if_flags  IFF_DEBUG;
 struct ifaddr *ifa;
 struct sockaddr_in *si;
 struct sockaddr_in *dest;

 +   int s;
 +
 +   /* Arguments are now on local stack so free temporary storage. */
 +   free(args, M_TEMP);
 +
 +   s = splsoftnet();
 +
 u_int32_t remote;
 if (sp-ipcp.flags  IPCP_HISADDR_DYN)
 remote = sp-ipcp.saved_hisaddr;
 @@ -4792,6 +4820,7 @@ sppp_clear_ip_addrs(struct sppp *sp)
 }

 if (ifa  si) {
 +   int error;
 struct sockaddr_in new_sin = *si;

 in_ifscrub(ifp, ifatoia(ifa));
 @@ -4800,10 +4829,17 @@ sppp_clear_ip_addrs(struct sppp *sp)
 if (sp-ipcp.flags  IPCP_HISADDR_DYN)
 /* replace peer addr in place */
 dest-sin_addr.s_addr = sp-ipcp.saved_hisaddr;
 -   if (!in_ifinit(ifp, ifatoia(ifa), new_sin, 0, 0))
 +   if (!(error = in_ifinit(ifp, ifatoia(ifa), new_sin, 0,
0)))
 dohooks(ifp-if_addrhooks, 0);
 +   if (debug  error) {
 +   log(LOG_DEBUG, SPP_FMT sppp_clear_ip_addrs:
in_ifinit 
 +failed, error=%d\n, SPP_ARGS(ifp), error);
 +   splx(s);
 +   return;
 +   }
 sppp_update_gw(ifp);
 }
 +   splx(s);
  }


 Index: pf.c
 ===
 RCS file: /cvs/src/sys/net/pf.c,v
 retrieving revision 1.808
 diff -u -p -r1.808 pf.c
 --- pf.c10 Jul 2012 17:33:48 -  1.808
 +++ pf.c21 Jul 2012 13:10:24 -
 @@ -2526,7 +2526,7 @@ pf_send_tcp(const struct pf_rule *r, sa_
 m-m_pkthdr.pf.flags |= PF_TAG_GENERATED;
 m-m_pkthdr.pf.tag = rtag;
 m-m_pkthdr.rdomain = rdom;
 -   if (r  r-set_prio[0] != PF_PRIO_NOTSET)
 +  

Re: intermittent crash

[David Coppa]

Il giorno 21/lug/2012 17:20, David Coppa dco...@gmail.com ha scritto:


 Il giorno 21/lug/2012 15:22, Stuart Henderson s...@spacehopper.org ha
scritto:

 
  On 2012/07/20 14:03, LEVAI Daniel wrote:
   Hi!
  
   It just crashed, didn't do anything fancy with it. I was connected
with
   ssh to the machine when suddenly I got disconnected.
 
  http://marc.info/?l=openbsd-miscm=134072894816852w=2
  http://marc.info/?l=openbsd-miscm=134149317104627w=2
  http://arp.thrush.com/openbsd/pppoe/sys_net_if_spppsubr_c.diff
 
  Here's a version of the patch without the extra debug printf/logs.
 
  I don't see any regressions with this, I've manually triggered the
  code a couple of times, but don't really want to keep dropping my
  ADSL for a better test as the telco is likely to drop my sync speed
  if I do that.
 
  Any OKs?  I think this is safe enough to make release.

 Here's one: ok for me.

 Ciao,
 David


pf bits are bogus btw...

 
  Index: if_spppsubr.c
  ===
  RCS file: /cvs/src/sys/net/if_spppsubr.c,v
  retrieving revision 1.96
  diff -u -p -r1.96 if_spppsubr.c
  --- if_spppsubr.c   28 Jan 2012 12:14:45 -  1.96
  +++ if_spppsubr.c   21 Jul 2012 13:10:24 -
  @@ -398,7 +398,7 @@ HIDE void sppp_qflush(struct ifqueue *if
   int sppp_update_gw_walker(struct radix_node *rn, void *arg, u_int);
   void sppp_update_gw(struct ifnet *ifp);
   HIDE void sppp_set_ip_addrs(void *, void *);
  -HIDE void sppp_clear_ip_addrs(struct sppp *sp);
  +HIDE void sppp_clear_ip_addrs(void *, void *);
   HIDE void sppp_set_phase(struct sppp *sp);
 
   /* our control protocol descriptors */
  @@ -3014,6 +3014,10 @@ struct sppp_set_ip_addrs_args {
  u_int32_t hisaddr;
   };
 
  +struct sppp_clear_ip_addrs_args {
  +   struct sppp *sp;
  +};
  +
   HIDE void
   sppp_ipcp_tlu(struct sppp *sp)
   {
  @@ -3096,9 +3100,22 @@ sppp_ipcp_tls(struct sppp *sp)
   HIDE void
   sppp_ipcp_tlf(struct sppp *sp)
   {
  +   struct ifnet *ifp = sp-pp_if;
  +   struct sppp_clear_ip_addrs_args *args;
  +
  +   args = malloc(sizeof(*args), M_TEMP, M_NOWAIT);
  +   if (args == NULL)
  +   return;
  +
  +   args-sp = sp;
  +
  if (sp-ipcp.flags  (IPCP_MYADDR_DYN|IPCP_HISADDR_DYN))
  /* Some address was dynamic, clear it again. */
  -   sppp_clear_ip_addrs(sp);
  +   if (workq_add_task(NULL, 0, sppp_clear_ip_addrs, args,
NULL)) {
  +   free(args, M_TEMP);
  +   printf(%s: workq_add_task failed, cannot clear

  +   addresses\n, ifp-if_xname);
  +   }
 
  /* we no longer need LCP */
  sp-lcp.protos = ~(1  IDX_IPCP);
  @@ -4760,16 +4777,27 @@ sppp_set_ip_addrs(void *arg1, void *arg2
   }
 
   /*
  - * Clear IP addresses.  Must be called at splnet.
  + * Work queue task clearing addresses from process context.
  + * Clear IP addresses.
*/
   HIDE void
  -sppp_clear_ip_addrs(struct sppp *sp)
  +sppp_clear_ip_addrs(void *arg1, void *arg2)
   {
  +   struct sppp_clear_ip_addrs_args *args = arg1;
  +   struct sppp *sp = args-sp;
  struct ifnet *ifp = sp-pp_if;
  +   int debug = ifp-if_flags  IFF_DEBUG;
  struct ifaddr *ifa;
  struct sockaddr_in *si;
  struct sockaddr_in *dest;
 
  +   int s;
  +
  +   /* Arguments are now on local stack so free temporary storage.
*/
  +   free(args, M_TEMP);
  +
  +   s = splsoftnet();
  +
  u_int32_t remote;
  if (sp-ipcp.flags  IPCP_HISADDR_DYN)
  remote = sp-ipcp.saved_hisaddr;
  @@ -4792,6 +4820,7 @@ sppp_clear_ip_addrs(struct sppp *sp)
  }
 
  if (ifa  si) {
  +   int error;
  struct sockaddr_in new_sin = *si;
 
  in_ifscrub(ifp, ifatoia(ifa));
  @@ -4800,10 +4829,17 @@ sppp_clear_ip_addrs(struct sppp *sp)
  if (sp-ipcp.flags  IPCP_HISADDR_DYN)
  /* replace peer addr in place */
  dest-sin_addr.s_addr = sp-ipcp.saved_hisaddr;
  -   if (!in_ifinit(ifp, ifatoia(ifa), new_sin, 0, 0))
  +   if (!(error = in_ifinit(ifp, ifatoia(ifa), new_sin, 0,
0)))
  dohooks(ifp-if_addrhooks, 0);
  +   if (debug  error) {
  +   log(LOG_DEBUG, SPP_FMT sppp_clear_ip_addrs:
in_ifinit 
  +failed, error=%d\n, SPP_ARGS(ifp), error);
  +   splx(s);
  +   return;
  +   }
  sppp_update_gw(ifp);
  }
  +   splx(s);
   }
 
 
  Index: pf.c
  ===
  RCS file: /cvs/src/sys/net/pf.c,v
  retrieving revision 1.808
  diff -u -p -r1.808 pf.c
  --- pf.c10 Jul 2012 17:33:48 -  1.808
  +++ pf.c21 Jul 2012 13:10:24 -