Re: nextafterl(3) possible bug

[Martynas Venckus]

On 6/4/14, Mark Kettenis  wrote:
>> Date: Mon, 2 Jun 2014 21:18:26 -0400
>> From: Daniel Dickman 
>>
>> >
>> > Another bug.  Intel chose an extended precision format with an
>> > explicit integer bit, and the code doesn't handle that.  Assuming we
>> > don't support machines with extended precision format that have an
>> > implicit integer bit, the following diff (an adaptation of the code in
>> > glibc) should fix things.  Not entirely happy with the fix though, so
>> > I'm still thinking about improvements.
>>
>> confirming that this patch fixes the failing numpy regress test on i386.
>>
>> let me know if you want me to test a different diff.
>
> Here's a better diff, inspired by what FreeBSD has.
>
> ok?

I like it better than the other diff;  OK martynas@.

> Index: s_nextafterl.c
> ===
> RCS file: /cvs/src/lib/libm/src/ld80/s_nextafterl.c,v
> retrieving revision 1.4
> diff -u -p -r1.4 s_nextafterl.c
> --- s_nextafterl.c12 Nov 2013 21:07:28 -  1.4
> +++ s_nextafterl.c4 Jun 2014 10:05:17 -
> @@ -32,8 +32,8 @@ nextafterl(long double x, long double y)
>   ix = esx&0x7fff;/* |x| */
>   iy = esy&0x7fff;/* |y| */
>
> - if (((ix==0x7fff)&&((hx|lx)!=0)) ||   /* x is nan */
> - ((iy==0x7fff)&&((hy|ly)!=0))) /* y is nan */
> + if (((ix==0x7fff)&&((hx&0x7fff|lx)!=0)) ||   /* x is nan */
> + ((iy==0x7fff)&&((hy&0x7fff|ly)!=0))) /* y is nan */
>  return x+y;
>   if(x==y) return y;  /* x=y, return y */
>   if((ix|hx|lx)==0) { /* x == 0 */
> @@ -47,31 +47,30 @@ nextafterl(long double x, long double y)
>   if(ix>iy||((ix==iy) && (hx>hy||((hx==hy)&&(lx>ly) {
> /* x > y, x -= ulp */
>   if(lx==0) {
> - if (hx==0) esx -= 1;
> - hx -= 1;
> + if ((hx&0x7fff)==0) esx -= 1;
> + hx = (hx - 1) | (hx & 0x8000);
>   }
>   lx -= 1;
>   } else {/* x < y, x += ulp */
>   lx += 1;
>   if(lx==0) {
> - hx += 1;
> - if (hx==0)
> - esx += 1;
> + hx = (hx + 1) | (hx & 0x8000);
> + if ((hx&0x7fff)==0) esx += 1;
>   }
>   }
>   } else {/* x < 0 */
>   if(esy>=0||(ix>iy||((ix==iy)&&(hx>hy||((hx==hy)&&(lx>ly)){
> /* x < y, x -= ulp */
>   if(lx==0) {
> - if (hx==0) esx -= 1;
> - hx -= 1;
> + if ((hx&0x7fff)==0) esx -= 1;
> + hx = (hx - 1) | (hx & 0x8000);
>   }
>   lx -= 1;
>   } else {/* x > y, x += ulp */
>   lx += 1;
>   if(lx==0) {
> - hx += 1;
> - if (hx==0) esx += 1;
> + hx = (hx + 1) | (hx & 0x8000);
> + if ((hx&0x7fff)==0) esx += 1;
>   }
>   }
>   }
>

Re: exp2(3) bug?

[Martynas Venckus]

On 6/2/14, Mark Kettenis  wrote:
>> Date: Mon, 2 Jun 2014 10:17:53 +0200 (CEST)
>> From: Mark Kettenis 
>>
>> > Date: Mon, 02 Jun 2014 09:34:20 +0200
>> > From: Benjamin Baier 
>> >
>> > You might want to read up on floating point arithmetic. (rounding and
>> > representation)
>>
>> Well, the difference between 4.994404 and 5.0 is a bit large to blame
>> rounding and binary representation.  And other OpenBSD platforms
>> (amd64, sparc64, powerpc) return the expected result.  So I'd say that
>> there is a bug in the i386-specific implementation of exp2(3).
>
> And here is a fix.  There actually isn't any i386-specific code, but
> i386 is "special" and needs STRICT_ALIGN() to work properly for double
> as well as float.  FreeBSD made the same change a while ago:
>
> http://svnweb.FreeBSD.org/base/head/lib/msun/src/math_private.h?revision=240827&view=markup

You are quick.  Thanks for figuring this out.

Ugh ... "it was intentionally left broken as an optimization".  That's crazy.

OK martynas@.

> Haven't run the regression tests yet with this change.
>
>
> Index: src/math_private.h
> ===
> RCS file: /cvs/src/lib/libm/src/math_private.h,v
> retrieving revision 1.16
> diff -u -p -r1.16 math_private.h
> --- src/math_private.h12 Nov 2013 20:35:09 -  1.16
> +++ src/math_private.h2 Jun 2014 09:30:13 -
> @@ -349,7 +349,7 @@ do {  
> \
>  #define  STRICT_ASSIGN(type, lval, rval) do {\
>   volatile type __lval;   \
>   \
> - if (sizeof(type) >= sizeof(double)) \
> + if (sizeof(type) >= sizeof(long double))\
>   (lval) = (rval);\
>   else {  \
>   __lval = (rval);\
>

Re: exp() / expl() on Linux and OpenBSD (expl() bug?)

[Martynas Venckus]

On 2/12/14, Donovan Watteau  wrote:
> On Thu, 6 Feb 2014, Donovan Watteau wrote:
>> David Coppa wrote:
>> > Take the following reduced test-case, adapted from what R's code
>> > does:
>> >
>> > ---8<---
>> >
>> > #include 
>> > #include 
>> > #include 
>> >
>> > int main(void) {
>> >double theta = 1;
>> >long double lambda, pr, pr2;
>> >
>> >lambda = (0.5*theta);
>> >pr = exp(-lambda);
>> >pr2 = expl(-lambda);
>> >
>> >printf("theta == %g, pr == %Lg, pr2 == %Lg\n", theta, pr, pr2);
>> >exit(0);
>> > }
>> >
>> > ---8<---
>> >
>> > This produces the following output on Linux (x86_64):
>> >
>> > theta == 1, pr == 0.606531, pr2 == 0.606531
>> >
>> > While on OpenBSD -current amd64:
>> >
>> > theta == 1, pr == 0.606531, pr2 == nan
>>
>> FWIW, it looks even stranger on loongson:
>>
>> $ cc -o expl expl.c -O2 -pipe -lm
>> $ ./expl
>> theta == 1, pr == -9.15569e-2474, pr2 == 6.10667e-4944
>> $ ./expl
>> theta == 1, pr == 0.606531, pr2 == 0.606531
>> $ ./expl
>> theta == 1, pr == -9.15569e-2474, pr2 == 6.10667e-4944
>>
>> $ sysctl kern.version
>> kern.version=OpenBSD 5.5-beta (GENERIC) #106: Mon Feb  3 01:47:15 MST
>> 2014
>> t...@loongson.openbsd.org:/usr/src/sys/arch/loongson/compile/GENERIC
>
> A fix has been committed, but there's still a problem on loongson with
> libm updated:
>
> $ ls -l /usr/lib/libm.so.*
> -r--r--r--  1 root  bin  926033 Feb 12 12:17 /usr/lib/libm.so.9.0
> $ cc -o expl expl.c -O2 -pipe -lm
> $ for in in 1 2 3 4 5 6 ; do ./expl ; done
> theta == 1, pr == -9.15569e-2474, pr2 == 6.10667e-4944
> theta == 1, pr == 0.606531, pr2 == 0.606531
> theta == 1, pr == 0.606531, pr2 == 0.606531
> theta == 1, pr == 0.606531, pr2 == 0.606531
> theta == 1, pr == -9.15569e-2474, pr2 == 6.10667e-4944
> theta == 1, pr == 0.606531, pr2 == 0.606531

This isn't related to exp/expl.  Looks like a bug in either compiler
or libc/printf/gdtoa.  I don't have the hardware so I couldn't tell
much more.

As usual, there are a few ways to fix it:
1. Debug it and provide a diff,
2. Donate hardware.  Oh, BTW I have a request for loongson in
http://www.openbsd.org/want.html sitting for over a year...

Re: exp() / expl() on Linux and OpenBSD (expl() bug?)

[Martynas Venckus]

> Here's a diff that sticks a bit closer to the original code.  It's
> equivalent to your diff, and admittedly purely a matter of taste which
> version to prefer.

I prefer my version better.  It's not '93 anymore and compilers are
able to convert 0.0L and -1.0L precisely, otherwise we have a huge
problem.  There's no need to obfuscate here by manually converting
to floating point representation.

Here's a diff which also includes same fix for ld128.  OK?

Index: ld128/s_floorl.c
===
RCS file: /cvs/src/lib/libm/src/ld128/s_floorl.c,v
retrieving revision 1.1
diff -u -r1.1 s_floorl.c
--- ld128/s_floorl.c6 Jul 2011 00:02:42 -   1.1
+++ ld128/s_floorl.c11 Feb 2014 05:24:15 -
@@ -34,10 +34,11 @@
jj0 = ((i0>>48)&0x7fff)-0x3fff;
if(jj0<48) {
if(jj0<0) { /* raise inexact if x != 0 */
-   if(huge+x>0.0) {/* return 0*sign(x) if |x|<1 */
-   if(i0>=0) {i0=i1=0;}
+   if(huge+x>0.0) {
+   if(i0>=0)
+   return 0.0L;
else if(((i0&0x7fffLL)|i1)!=0)
-   { i0=0xbfffULL;i1=0;}
+   return -1.0L;
}
} else {
i = (0xULL)>>jj0;
Index: ld80/s_floorl.c
===
RCS file: /cvs/src/lib/libm/src/ld80/s_floorl.c,v
retrieving revision 1.2
diff -u -r1.2 s_floorl.c
--- ld80/s_floorl.c 25 Jul 2011 16:20:09 -  1.2
+++ ld80/s_floorl.c 11 Feb 2014 05:24:01 -
@@ -35,10 +35,11 @@
jj0 = (se&0x7fff)-0x3fff;
if(jj0<31) {
if(jj0<0) { /* raise inexact if x != 0 */
-   if(huge+x>0.0) {/* return 0*sign(x) if |x|<1 */
-   if(sx==0) {se=0;i0=i1=0;}
+   if(huge+x>0.0) {
+   if(sx==0)
+   return 0.0L;
else if(((se&0x7fff)|i0|i1)!=0)
-   { se=0xbfff;i0=i1=0;}
+   return -1.0L;
}
} else {
i = (0x7fff)>>jj0;

Re: exp() / expl() on Linux and OpenBSD (expl() bug?)

[Martynas Venckus]

Yup.Does this diff fix it for you?

On 2/6/14, Daniel Dickman  wrote:
> I think I recently ran into a similar issue but I suspect the root cause
> might be the same. I think the floorl function is wrong for numbers slightly
> larger than -1 to numbers slightly below 0. In this range floorl returns -0
> instead of -1.
>
>> On Feb 5, 2014, at 3:57 AM, David Coppa  wrote:
>>
>>
>> Hi!
>>
>> I hit this problem while working on updating math/R from version
>> 2.15.3 to the latest version (3.0.2).
>>
>> It started happening since upstream switched from double functions
>> to C99 long double functions (expl, fabsl, ...), during the R-3
>> development cycle.
>>
>> Take the following reduced test-case, adapted from what R's code
>> does:
>>
>> ---8<---
>>
>> #include 
>> #include 
>> #include 
>>
>> int main(void) {
>>double theta = 1;
>>long double lambda, pr, pr2;
>>
>>lambda = (0.5*theta);
>>pr = exp(-lambda);
>>pr2 = expl(-lambda);
>>
>>printf("theta == %g, pr == %Lg, pr2 == %Lg\n", theta, pr, pr2);
>>exit(0);
>> }
>>
>> ---8<---
>>
>> This produces the following output on Linux (x86_64):
>>
>> theta == 1, pr == 0.606531, pr2 == 0.606531
>>
>> While on OpenBSD -current amd64:
>>
>> theta == 1, pr == 0.606531, pr2 == nan
>>
>> And indeed R-3's testsuite fails with the error message
>> "NaNs produced":
>>
>> Warning in pchisq(1e-300, df = 0, ncp = lam) : NaNs produced
>>> stopifnot(all.equal(p00, exp(-lam/2)),
>> +   all.equal(p.0, exp(-lam/2)))
>> Error: all.equal(p.0, exp(-lam/2)) is not TRUE
>> Execution halted
>>
>> Is this a bug in our expl() ?
>>
>> Ciao,
>> David
>>
>
Index: s_floorl.c
===
RCS file: /cvs/src/lib/libm/src/ld80/s_floorl.c,v
retrieving revision 1.2
diff -u -r1.2 s_floorl.c
--- s_floorl.c  25 Jul 2011 16:20:09 -  1.2
+++ s_floorl.c  7 Feb 2014 07:01:59 -
@@ -35,10 +35,12 @@
jj0 = (se&0x7fff)-0x3fff;
if(jj0<31) {
if(jj0<0) { /* raise inexact if x != 0 */
-   if(huge+x>0.0) {/* return 0*sign(x) if |x|<1 */
-   if(sx==0) {se=0;i0=i1=0;}
-   else if(((se&0x7fff)|i0|i1)!=0)
-   { se=0xbfff;i0=i1=0;}
+   if(huge+x>0.0) {
+   if(sx==0) {
+return 0.0L;
+} else if(((se&0x7fff)|i0|i1)!=0) {
+   return -1.0L;
+}
}
} else {
i = (0x7fff)>>jj0;

Re: fenv.h support for libm

[Martynas Venckus]

On 4/18/11, Matthew Dempsky  wrote:
> On Sun, Apr 17, 2011 at 5:29 PM, Philip Guenther  wrote:
>> I haven't worked through all the bit-twiddling and asm, but what I
>> have looks good and the abundance of regress tests that keep showing
>> up in "cvs up -d" inspires confidence.  With that x87-->__x87 nit, ok
>> guenther@
>
> ok matthew@ as well; the regress tests run fine on my system, and I
> was able to use it to build my WIP CGAL and OpenSCAD ports.
>
> However, since this is only support for amd64, it can't be linked into
> the build for all platforms just yet.  Can at least the .c and .h
> files be committed now so they're not lost and are easier to continue
> testing until fenv.h support can be turned on everywhere?

I think so;  let's commit fenv.c for each arch till it's complete.
I'll commit the amd64 bits this evening if noone objects.

I can't finish this unless someone provides me with access to other
archs.  If someone can provide remote access to develop and test fp
things, please contact me offlist.

Re: fenv.h support for libm

[Martynas Venckus]

The diff I sent before has been corrupted by Gmail (wrapped diff lines).

I'm re-attaching it below.

Index: include/Makefile
===
RCS file: /cvs/src/include/Makefile,v
retrieving revision 1.157
diff -u -r1.157 Makefile
--- include/Makefile28 Oct 2010 08:34:37 -  1.157
+++ include/Makefile18 Mar 2011 17:20:42 -
@@ -12,8 +12,8 @@
 # Missing: mp.h
 FILES= a.out.h ar.h assert.h bitstring.h blf.h bm.h bsd_auth.h \
complex.h cpio.h ctype.h curses.h db.h dbm.h des.h dirent.h disktab.h \
-   dlfcn.h elf_abi.h err.h errno.h fnmatch.h fstab.h fts.h ftw.h getopt.h \
-   glob.h grp.h ifaddrs.h inttypes.h iso646.h kvm.h langinfo.h \
+   dlfcn.h elf_abi.h err.h errno.h fenv.h fnmatch.h fstab.h fts.h ftw.h \
+   getopt.h glob.h grp.h ifaddrs.h inttypes.h iso646.h kvm.h langinfo.h \
libgen.h limits.h locale.h login_cap.h malloc.h math.h md4.h \
md5.h memory.h mpool.h ndbm.h netdb.h netgroup.h nlist.h nl_types.h \
ohash.h paths.h poll.h pwd.h ranlib.h re_comp.h \
Index: include/fenv.h
===
RCS file: include/fenv.h
diff -N include/fenv.h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ include/fenv.h  16 Apr 2011 21:26:26 -
@@ -0,0 +1,59 @@
+/* $OpenBSD$   */
+/* $NetBSD: fenv.h,v 1.2.4.1 2011/02/08 16:18:55 bouyer Exp $  */
+
+/*
+ * Copyright (c) 2010 The NetBSD Foundation, Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
+ * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+ * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
+ * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef_FENV_H_
+#define_FENV_H_
+
+#include 
+#include 
+
+__BEGIN_DECLS
+
+intfeclearexcept(int);
+intfegetexceptflag(fexcept_t *, int);
+intferaiseexcept(int);
+intfesetexceptflag(const fexcept_t *, int);
+intfetestexcept(int);
+
+intfegetround(void);
+intfesetround(int);
+intfegetenv(fenv_t *);
+intfeholdexcept(fenv_t *);
+intfesetenv(const fenv_t *);
+intfeupdateenv(const fenv_t *);
+
+#if__BSD_VISIBLE
+intfeenableexcept(int mask);
+intfedisableexcept(int mask);
+intfegetexcept(void);
+#endif /* __BSD_VISIBLE */
+
+__END_DECLS
+
+#endif /* ! _FENV_H_ */
Index: sys/arch/amd64/include/fenv.h
===
RCS file: sys/arch/amd64/include/fenv.h
diff -N sys/arch/amd64/include/fenv.h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ sys/arch/amd64/include/fenv.h   18 Mar 2011 20:37:58 -
@@ -0,0 +1,105 @@
+/* $OpenBSD$   */
+/* $NetBSD: fenv.h,v 1.1 2010/07/31 21:47:54 joerg Exp $   */
+
+/*-
+ * Copyright (c) 2004-2005 David Schultz 
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DA

Re: fenv.h support for libm

[Martynas Venckus]

On 3/22/11, Mark Kettenis  wrote:
>> Date: Sun, 20 Mar 2011 03:08:41 +0200
>> From: Martynas Venckus 
>>
>> Index: include/fenv.h
>> ===
>> RCS file: include/fenv.h
>> diff -N include/fenv.h
>> --- /dev/null1 Jan 1970 00:00:00 -
>> +++ include/fenv.h   18 Mar 2011 20:38:10 -
>> @@ -0,0 +1,59 @@
>> +/*  $OpenBSD$   */
>> +/*  $NetBSD: fenv.h,v 1.2.4.1 2011/02/08 16:18:55 bouyer Exp $  */
>> +
>> +/*
>> + * Copyright (c) 2010 The NetBSD Foundation, Inc.
>> + * All rights reserved.
>> + *
>> + * Redistribution and use in source and binary forms, with or without
>> + * modification, are permitted provided that the following conditions
>> + * are met:
>> + * 1. Redistributions of source code must retain the above copyright
>> + *notice, this list of conditions and the following disclaimer.
>> + * 2. Redistributions in binary form must reproduce the above copyright
>> + *notice, this list of conditions and the following disclaimer in the
>> + *documentation and/or other materials provided with the
>> distribution.
>> + *
>> + * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND
>> CONTRIBUTORS
>> + * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>> LIMITED
>> + * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
>> PARTICULAR
>> + * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR
>> CONTRIBUTORS
>> + * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
>> BUSINESS
>> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
>> IN
>> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
>> OTHERWISE)
>> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
>> THE
>> + * POSSIBILITY OF SUCH DAMAGE.
>> + */
>> +
>> +#ifndef _FENV_H_
>> +#define _FENV_H_
>> +
>> +#include 
>> +#include 
>> +
>> +__BEGIN_DECLS
>> +
>> +int feclearexcept(int);
>> +int fegetexceptflag(fexcept_t *, int);
>> +int feraiseexcept(int);
>> +int fesetexceptflag(const fexcept_t *, int);
>> +int fetestexcept(int);
>> +
>> +int fegetround(void);
>> +int fesetround(int);
>> +int fegetenv(fenv_t *);
>> +int feholdexcept(fenv_t *);
>> +int fesetenv(const fenv_t *);
>> +int feupdateenv(const fenv_t *);
>> +
>> +#if __BSD_VISIBLE || defined(_GNU_SOURCE)
>> +int feenableexcept(int mask);
>> +int fedisableexcept(int mask);
>> +int fegetexcept(void);
>> +#endif  /* __BSD_VISIBLE || defined(_GNU_SOURCE) */
>
> I think we should leave off the || defined(_GNU_SOURCE) bit here.
> Nowhere else in our system headers do we care about GNU extensions.
> And if we would care about them, we probably should introduce
> __GNU_VISIBLE and set it appropriately in  based on
> whether _GNU_SOURCE is defined or not.  But since _GNU_SOURCE seems to
> imply BSD extensions on Linux, I think just checking __BSD_VISIBLE is
> the right thing to do.

I agree with Mark here.  Also, I took a second look, and found couple more bugs:

- Fedisableexcept didn't clear non-FE_ALL_EXCEPT bits for mask, making
it possible to corrupt control/mxcsr.
- Values returned by feenableexcept and fedisableexcept weren't quite
right.  They did ~(control&FE_ALL_EXCEPT) instead of
(~control)&FE_ALL_EXCEPT, setting all non-FE_ALL_EXCEPT, breaking apps
testing for equality.

Hopefully, this is the final version for amd64.  (-;

Index: include/Makefile
===
RCS file: /cvs/src/include/Makefile,v
retrieving revision 1.157
diff -u -r1.157 Makefile
--- include/Makefile28 Oct 2010 08:34:37 -  1.157
+++ include/Makefile18 Mar 2011 17:20:42 -
@@ -12,8 +12,8 @@
 # Missing: mp.h
 FILES= a.out.h ar.h assert.h bitstring.h blf.h bm.h bsd_auth.h \
complex.h cpio.h ctype.h curses.h db.h dbm.h des.h dirent.h disktab.h \
-   dlfcn.h elf_abi.h err.h errno.h fnmatch.h fstab.h fts.h ftw.h getopt.h \
-   glob.h grp.h ifaddrs.h inttypes.h iso646.h kvm.h langinfo.h \
+   dlfcn.h elf_abi.h err.h errno.h fenv.h fnmatch.h fstab.h fts.h ftw.h \
+   getopt.h glob.h grp.h ifaddrs.h inttypes.h iso646.h kvm.h langinfo.h \
libgen.h limits.h locale.h login_cap.h malloc.h math.h md4.h \
md5.h memory.h mpool.h ndbm.h netdb.h netgroup.h nlist.h nl_ty

Re: ksh completion

[Martynas Venckus]

> Delivered-To: marty...@venck.us
> Received: by 10.231.147.205 with SMTP id m13cs105662ibv;
> Tue, 15 Mar 2011 01:48:25 -0700 (PDT)
> Received: by 10.43.46.135 with SMTP id uo7mr4936656icb.50.1300178905343;
> Tue, 15 Mar 2011 01:48:25 -0700 (PDT)
> Return-Path: 
> Received: from shear.ucar.edu (lists.openbsd.org [192.43.244.163])
> by mx.google.com with ESMTP id 
> yd20si10108737icb.5.2011.03.15.01.48.25;
> Tue, 15 Mar 2011 01:48:25 -0700 (PDT)
> Received-SPF: pass (google.com: manual fallback record for domain of 
> owner-tech+m23...@openbsd.org designates 192.43.244.163 as permitted sender) 
> client-ip=192.43.244.163;
> Authentication-Results: mx.google.com; spf=pass (google.com: manual fallback 
> record for domain of owner-tech+m23...@openbsd.org designates 192.43.244.163 
> as permitted sender) smtp.mail=owner-tech+m23...@openbsd.org
> Received: from openbsd.org (localhost.ucar.edu [127.0.0.1])
>   by shear.ucar.edu (8.14.3/8.14.3) with ESMTP id p2F8lBju030637;
>   Tue, 15 Mar 2011 02:47:11 -0600 (MDT)
> Received: from clam.khaoz.org (clam.khaoz.org [64.90.163.62])
>   by shear.ucar.edu (8.14.3/8.14.3) with ESMTP id p2F8jjJq003536 
> (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=FAIL); Tue, 15 
> Mar 2011 02:45:46 -0600 (MDT)
> Received: from clam.khaoz.org (okan@localhost [IPv6:::1])
>   by clam.khaoz.org (8.14.3/8.14.3) with ESMTP id p2F8jhx2026590 
> (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 15 
> Mar 2011 04:45:44 -0400 (EDT)
> Date: Tue, 15 Mar 2011 04:45:43 -0400
> From: Okan Demirmen 
> To: tech@openbsd.org
> Cc: r...@openbsd.org
> Subject: ksh completion
> Message-ID: <20110315084543.ga17...@clam.khaoz.org>
> Mail-Followup-To: tech@openbsd.org, r...@openbsd.org
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> List-Help: 
> List-Owner: 
> List-Post: 
> List-Subscribe: 
> List-Unsubscribe: 
> X-Loop: tech@openbsd.org
> Precedence: list
> Sender: owner-t...@openbsd.org
>
> hi,
>
> (this is a re-post)
>
> make tab completion work for '=', '`', '[', ':', and '$' - pulled from
> mksh by Alexander Polakov (also posted to tech recently).
>
> closes pr 6006 too.
>
> comments/ok?

The diff is a workaround and even wrong.  Ksh lexical analyzer
itself has the ability to deal with escapes properly (see yylex).

I believe we shouldn't remove backward slashes before passing it
for analysis, this would fix all cases, including:

$ touch aabbcc aa\*cc
$ echo aa\*cc
aa*cc   aabbcc
$ echo aa\*cc
aa*cc

> Index: edit.c
> ===
> RCS file: /home/okan/hack/open/cvs/src/bin/ksh/edit.c,v
> retrieving revision 1.34
> diff -u -p -r1.34 edit.c
> --- edit.c20 May 2010 01:13:07 -  1.34
> +++ edit.c14 Mar 2011 09:59:27 -
> @@ -365,6 +365,11 @@ x_file_glob(int flags, const char *str,
>   continue;
>   }
>
> + /* specially escape escaped [ or $ or ` for globbing */
> + if (escaping && (toglob[i] == '[' ||
> + toglob[i] == '$' || toglob[i] == '`'))
> + toglob[idx++] = QCHAR;
> +
>   toglob[idx] = toglob[i];
>   idx++;
>   if (escaping) escaping = 0;
> @@ -378,7 +383,7 @@ x_file_glob(int flags, const char *str,
>   s = pushs(SWSTR, ATEMP);
>   s->start = s->str = toglob;
>   source = s;
> - if (yylex(ONEWORD) != LWORD) {
> + if (yylex(ONEWORD|LQCHAR) != LWORD) {
>   source = sold;
>   internal_errorf(0, "fileglob: substitute error");
>   return 0;
> @@ -821,7 +826,7 @@ x_escape(const char *s, size_t len, int
>   int rval = 0;
>
>   for (add = 0, wlen = len; wlen - add > 0; add++) {
> - if (strchr("\"#$&'()*;<=>?[\\]`{|}", s[add]) ||
> + if (strchr("\"#$&'()*:;<=>?[\\]`{|}", s[add]) ||
>   strchr(ifs, s[add])) {
>   if (putbuf_func(s, add) != 0) {
>   rval = -1;
> Index: lex.c
> ===
> RCS file: /home/okan/hack/open/cvs/src/bin/ksh/lex.c,v
> retrieving revision 1.45
> diff -u -p -r1.45 lex.c
> --- lex.c 9 Mar 2011 09:30:39 -   1.45
> +++ lex.c 14 Mar 2011 09:59:27 -
> @@ -411,6 +411,13 @@ yylex(int cf)
>   }
>   }
>   break;
> + case QCHAR:
> + if (cf & LQCHAR) {
> + *wp++ = QCHAR;
> + *wp++ = getsc();
> + br

Re: http gzip support for ftp

[Martynas Venckus]

> Delivered-To: marty...@venck.us
> Received: by 10.100.109.13 with SMTP id h13cs81395anc;
> Sun, 9 Jan 2011 14:09:58 -0800 (PST)
> Received: by 10.42.176.2 with SMTP id bc2mr3471559icb.517.1294610998158;
> Sun, 09 Jan 2011 14:09:58 -0800 (PST)
> Return-Path: 
> Received: from shear.ucar.edu (lists.openbsd.org [192.43.244.163])
> by mx.google.com with ESMTP id
f5si189964icu.33.2011.01.09.14.09.56;
> Sun, 09 Jan 2011 14:09:57 -0800 (PST)
> Received-SPF: pass (google.com: manual fallback record for domain of
owner-tech+m23...@openbsd.org designates 192.43.244.163 as permitted sender)
client-ip=192.43.244.163;
> Authentication-Results: mx.google.com; spf=pass (google.com: manual fallback
record for domain of owner-tech+m23...@openbsd.org designates 192.43.244.163
as permitted sender) smtp.mail=owner-tech+m23...@openbsd.org; dkim=pass (test
mode) header.i=@gmail.com
> Received: from openbsd.org (localhost.ucar.edu [127.0.0.1])
>   by shear.ucar.edu (8.14.3/8.14.3) with ESMTP id p09M9ZNr021431;
>   Sun, 9 Jan 2011 15:09:35 -0700 (MST)
> Received: from mail-qw0-f49.google.com (mail-qw0-f49.google.com
[209.85.216.49])
>   by shear.ucar.edu (8.14.3/8.14.3) with ESMTP id p09M8Qo7030584
>   for ; Sun, 9 Jan 2011 15:08:27 -0700 (MST)
> Received: by qwj9 with SMTP id 9so18728829qwj.8
>   for ; Sun, 09 Jan 2011 14:08:26 -0800 (PST)
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:received:received:date:from:to:cc:subject
:in-reply-to:message-id:references:user-agent:mime-version :content-type;
bh=h/uSItba1mLjBNAbFHi24e9uIaFGrvE/zyzh9me7yYw=;
b=XL2MRc5mQPtKcLk0xcUbEGn9qdUnrl6SeDWu1vs3q6WxC/wpfV2rgJanu5AiWpbf49
wtVrJKYpS9dy1CelkCIVzlg+RPUqnv32G3++umRivu257SvjpOOslVewDoQhQWObt2Ge
rOSbU0xTYAxK1Ed/VpudyiJchjG2z31yWyH+E=
> DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=date:from:to:cc:subject:in-reply-to:message-id:references
:user-agent:mime-version:content-type;
b=vy/Cr6z1/nOya7/ja1dbvBm4ImoKOvIBVNnuY9F9pk7/nk4nX79tDrpqDzmhuQAxtM
NUIjTiMhF4Iqu1yDpP9CxDFrltopI0N2v6zlVhte2HPPW3pumugdFX8PZAuyr8+H+Nxi
TDNAfVeIOfemJkkd/DClpRrGh+GwyqEa8ab+Q=
> Received: by 10.224.11.20 with SMTP id r20mr26905601qar.51.1294610906191;
Sun, 09 Jan 2011 14:08:26 -0800 (PST)
> Received: from mini.t3rl.org (cpe-74-66-19-205.nyc.res.rr.com
[74.66.19.205])
>   by mx.google.com with ESMTPS id nb15sm16014404qcb.2.2011.01.09.14.08.24
(version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 14:08:25 -0800 (PST)
> Date: Sun, 9 Jan 2011 17:08:22 -0500 (EST)
> From: Ted Unangst 
> To: Ted Unangst 
> cc: tech@openbsd.org
> Subject: Re: http gzip support for ftp
> In-Reply-To: 
> Message-ID: 
> References: 
> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23)
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> List-Help: 
> List-Owner: 
> List-Post: 
> List-Subscribe: 
> List-Unsubscribe: 
> X-Loop: tech@openbsd.org
> Precedence: list
> Sender: owner-t...@openbsd.org
>
> On Sun, 9 Jan 2011, Ted Unangst wrote:
>
> > Downloading things can go a lot faster if the server and client support
> > http compression.  This is easily added to the ftp program's http
support.
>
> poopers, I hard coded gzipped to 1 by accident.  3rd time's a charm.
> Please test, as there are obviously lots of different web servers out
> there.
>
> Index: Makefile
> ===
> RCS file: /home/tedu/cvs/src/usr.bin/ftp/Makefile,v
> retrieving revision 1.25
> diff -u -r1.25 Makefile
> --- Makefile  5 May 2009 19:35:30 -   1.25
> +++ Makefile  9 Jan 2011 21:14:51 -
> @@ -17,8 +17,8 @@
>
>  CPPFLAGS+= -DINET6
>
> -LDADD+=  -ledit -lcurses -lutil -lssl -lcrypto
> -DPADD+=  ${LIBEDIT} ${LIBCURSES} ${LIBUTIL}
> +LDADD+=  -ledit -lcurses -lutil -lssl -lcrypto -lz
> +DPADD+=  ${LIBEDIT} ${LIBCURSES} ${LIBUTIL} ${LIBZ}
>  LDSTATIC= ${STATIC}
>
>  #COPTS+= -Wall -Wconversion -Wstrict-prototypes -Wmissing-prototypes
> Index: fetch.c
> ===
> RCS file: /home/tedu/cvs/src/usr.bin/ftp/fetch.c,v
> retrieving revision 1.103
> diff -u -r1.103 fetch.c
> --- fetch.c   25 Aug 2010 20:32:37 -  1.103
> +++ fetch.c   9 Jan 2011 22:07:12 -
> @@ -63,6 +63,7 @@
>  #ifndef SMALL
>  #include 
>  #include 
> +#include 
>  #else /* !SMALL */
>  #define SSL void
>  #endif /* !SMALL */
> @@ -167,6 +168,80 @@
>   return (epath);
>  }
>
> +#ifndef SMALL

Please put this at the end of the file, to avoid yet-another #ifndef
SMALL block.

> +static size_t
> +chunked_read(FILE *fin, SSL *ssl, unsigned char *buf, size_t amt,
> +int chunked, int gzipped)
> +{
> + static int chunksize;
> + static int zinit;
> + static z_stream zctx;
> +  

lrint fix

[Martynas Venckus]

Our lrint, llrint, lrintf, llrintf always return 0 for inputs close
to 0.  However, depending on the rounding mode, they should actually
return -1 or 1.

Here's my test case:

#include 
#include 
#include 

int
main(void)
{
fpsetround(FP_RM);
printf("%ld\n", lrint(-0.2));
fpsetround(FP_RP);
printf("%ld\n", lrint(0.2));
return (0);
}

It returns zero, however they should actually be -1, and 1.  The
assumption that |1.0 * 2^exp| = 0, exp < -1 cannot be made when we
round towards -inf or +inf.

If you're testing it on amd64 or i386 please note, that those
platforms are not affected--they use the assembly versions which do
the right thing.

Index: s_lrint.c
===
RCS file: /cvs/src/lib/libm/src/s_lrint.c,v
retrieving revision 1.1
diff -u -r1.1 s_lrint.c
--- s_lrint.c   25 Sep 2006 20:25:41 -  1.1
+++ s_lrint.c   7 Apr 2011 01:07:20 -
@@ -61,9 +61,6 @@
s = e >> DBL_EXPBITS;
e = (e & 0x7ff) - DBL_EXP_BIAS;

-   /* 1.0 x 2^-1 is the smallest number which can be rounded to 1 */
-   if (e < -1)
-   return (0);
/* 1.0 x 2^31 (or 2^63) is already too large */
if (e >= (int)RESTYPE_BITS - 1)
return (s ? RESTYPE_MIN : RESTYPE_MAX); /* ??? unspecified */
@@ -79,6 +76,9 @@
e = ((i0 >> 20) & 0x7ff) - DBL_EXP_BIAS;
i0 &= 0xf;
i0 |= (1 << 20);
+
+   if (e < 0)
+   return (0);

shift = e - DBL_FRACBITS;
if (shift >=0)
Index: s_lrintf.c
===
RCS file: /cvs/src/lib/libm/src/s_lrintf.c,v
retrieving revision 1.1
diff -u -r1.1 s_lrintf.c
--- s_lrintf.c  25 Sep 2006 20:25:41 -  1.1
+++ s_lrintf.c  7 Apr 2011 01:10:19 -
@@ -61,9 +61,6 @@
s = e >> SNG_EXPBITS;
e = (e & 0xff) - SNG_EXP_BIAS;

-   /* 1.0 x 2^-1 is the smallest number which can be rounded to 1 */
-   if (e < -1)
-   return (0);
/* 1.0 x 2^31 (or 2^63) is already too large */
if (e >= (int)RESTYPE_BITS - 1)
return (s ? RESTYPE_MIN : RESTYPE_MAX); /* ??? unspecified */
@@ -81,6 +78,9 @@
e = ((i0 >> SNG_FRACBITS) & 0xff) - SNG_EXP_BIAS;
i0 &= 0x7f;
i0 |= (1 << SNG_FRACBITS);
+
+   if (e < 0)
+   return (0);

shift = e - SNG_FRACBITS;
if (shift >=0)

Re: nvi diff fixing a display glitch leading to crash

[Martynas Venckus]

> Delivered-To: marty...@venck.us
> Received: by 10.100.125.2 with SMTP id x2cs7548anc;
> Wed, 8 Dec 2010 00:00:53 -0800 (PST)
> Received: by 10.231.32.197 with SMTP id e5mr738073ibd.188.1291795252925;
> Wed, 08 Dec 2010 00:00:52 -0800 (PST)
> Return-Path: 
> Received: from shear.ucar.edu (lists.openbsd.org [192.43.244.163])
> by mx.google.com with ESMTP id 
> gy42si1064435ibb.88.2010.12.08.00.00.52;
> Wed, 08 Dec 2010 00:00:52 -0800 (PST)
> Received-SPF: pass (google.com: manual fallback record for domain of 
> owner-tech+m22...@openbsd.org designates 192.43.244.163 as permitted sender) 
> client-ip=192.43.244.163;
> Authentication-Results: mx.google.com; spf=pass (google.com: manual fallback 
> record for domain of owner-tech+m22...@openbsd.org designates 192.43.244.163 
> as permitted sender) smtp.mail=owner-tech+m22...@openbsd.org
> Received: from openbsd.org (localhost.ucar.edu [127.0.0.1])
>   by shear.ucar.edu (8.14.3/8.14.3) with ESMTP id oB87xxwI017467;
>   Wed, 8 Dec 2010 00:59:59 -0700 (MST)
> Received: from mail.boxsoft.com (dsl092-062-211.lax1.dsl.speakeasy.net 
> [66.92.62.211])
>   by shear.ucar.edu (8.14.3/8.14.3) with ESMTP id oB87we7E023081 
> (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO)
>   for ; Wed, 8 Dec 2010 00:58:42 -0700 (MST)
> Received: from mail.boxsoft.com (sidster@localhost [127.0.0.1])
>   by mail.boxsoft.com (8.14.3/8.14.3) with ESMTP id oB87weGu028472
>   for ; Tue, 7 Dec 2010 23:58:40 -0800 (PST)
> Received: (from sidster@localhost)
>   by mail.boxsoft.com (8.14.3/8.14.3/Submit) id oB87wdB5002430
>   for tech@openbsd.org; Tue, 7 Dec 2010 23:58:40 -0800 (PST)
> X-Authentication-Warning: roppongi.boxsoft.com: sidster set sender to 
> sids...@boxsoft.com using -f
> Date: Tue, 7 Dec 2010 23:58:39 -0800
> From: patrick keshishian 
> To: tech@openbsd.org
> Subject: nvi diff fixing a display glitch leading to crash
> Message-ID: <20101208075839.gc2...@roppongi.boxsoft.com>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> User-Agent: Mutt/1.4.2.3i
> List-Help: 
> List-Owner: 
> List-Post: 
> List-Subscribe: 
> List-Unsubscribe: 
> X-Loop: tech@openbsd.org
> Precedence: list
> Sender: owner-t...@openbsd.org
>
> Hello,
>
> I work with a lot of sources that have strange formatting
> (as do you no doubt). I noticed that sometimes changing the
> tabstop value in search of a reasonable display vi would
> crash.
>
> Took me a bit to figure out the reproducible steps to be
> able to come up with a fix.
>
> Steps to reproduce the crash. Reproducible on i386, amd64,
> and macppc:
>
> 1. Imagine a file edited with a small tabstop value (say 2
>or 3) containing lines long enough so they wrap in default
>tabstop (8), but possibly not in the smaller tabstop values.
>
> 2. While tabstop set to 8, position one of the wrapping lines
>such that the beginning of said line is off screen and the
>tail end of the wrapped portion is the first line on the
>screen with the cursor positioned on same first line.
>
> 3. Change tabstop to 2 (or 3).
>Assuming there were more lines below the line your cursor
>is on, you will notice a drawing glitch where only the
>top line is redrawn and the rest of the screen is blanked
>out.
>
> 4. If at this point you press ^B (page backwards) vi will
>core dump.
>
> A visual of what I experience (series of five screen-shots):
>   http://sidster.com/scratch/nvi/
>
>
> The patch below resets the HMAP->soff (screen offset of line)
> to 1 if the number of lines HMAP->lno spans has changed and is
> now less than HMAP->soff. This essentially forces the entire
> line to be redrawn at the top of the screen, avoids the redraw
> glitch and eventual crash.
>
> Comments?

Thanks for the detailed report.

However, your diff is wrong.

> --patrick
>
>
> Index: vi/vs_smap.c
> ===
> RCS file: /cvs/obsd/src/usr.bin/vi/vi/vs_smap.c,v
> retrieving revision 1.7
> diff -u -p vi/vs_smap.c
> --- vi/vs_smap.c  27 Oct 2009 23:59:49 -  1.7
> +++ vi/vs_smap.c  8 Dec 2010 06:22:09 -
> @@ -224,6 +224,17 @@ top: HMAP->lno = lno;
>   HMAP->coff = 0;
>   HMAP->soff = 1;
>   }
> + else {

This is not the right place to fix this, since it would affect the
other 6 calls with OOBLNO in a bad way.

> + /*
> +  * If number of lines HMAP->lno (top line) spans
> +  * changed due to, say reformatting, and now is
> +  * fewer than HMAP->soff, reset so the line is
> +  * redrawn at the top of the screen.
> +  

Re: acpivideo: do not trust _DOD for brightness

[Martynas Venckus]

On 4/2/11, Paul Irofti  wrote:
> What about devices that should support _DOS and don't support
> brightness? I've tested this on a D620 (which has the methods but does
> brightness through the BIOS) and the relevant dmesg diff is:
>
> -acpivout0 at acpivideo1: TV__
> -acpivout1 at acpivideo1: CRT_
> -acpivout2 at acpivideo1: LCD_
> -acpivout3 at acpivideo1: DVI_
>
> This makes sense I guess because they're useless on this model, but I'm
> not sure about other laptops.

The first revision of the diff I've posted to you (offlist) handles
this, i.e. attaches to all _DOD, and then additionally to all devices
having the brightness methods.

But I don't see a need for complexity in this case--if device doesn't
have the relevant methods, acpivoutX would attach doing nothing (like
in your case).  This way is both simpler and more reliable.

acpivideo: do not trust _DOD for brightness

[Martynas Venckus]

Please test, details below.

We attach acpivout(4) to every device enumerated in _DOD.  However,
if you read ACPI spec. closely, it says that _DOD (unlike _DOS) is
not required if the system supports LCD brightness control.

In my case the situation is even worse--_DOD enumerates only 0x400
(which is non-existent), however there's this DD03 device which is
LCD and perfecly can handle brightness control.

I suggest to trust _DOD less, and search for devices having _BCL,
_BCM, and _BQC instead;  because only such device would be able to
handle brightness control.

We use the same trick in other drivers (look for functions instead
of trusting enumeration crap in acpi).

The following diff fixes my problem (Toshiba L300):

 acpivideo0 at acpi0: OVGA
+acpivout0 at acpivideo0: DD03

 acpivar.h   |8 -
 acpivideo.c |   81

 acpivout.c  |   30 +-
 3 files changed, 20 insertions(+), 99 deletions(-)

Index: acpivar.h
===
RCS file: /cvs/src/sys/dev/acpi/acpivar.h,v
retrieving revision 1.69
diff -u -r1.69 acpivar.h
--- acpivar.h   2 Jan 2011 04:56:57 -   1.69
+++ acpivar.h   31 Mar 2011 07:57:59 -
@@ -49,9 +49,6 @@

struct acpi_softc *sc_acpi;
struct aml_node *sc_devnode;
-
-   int *sc_dod;
-   size_t  sc_dod_len;
 };

 struct acpi_attach_args {
@@ -61,11 +58,6 @@
void*aaa_table;
struct aml_node *aaa_node;
const char  *aaa_dev;
-};
-
-struct acpivideo_attach_args {
-   struct acpi_attach_args aaa;
-   int dod;
 };

 struct acpi_mem_map {
Index: acpivideo.c
===
RCS file: /cvs/src/sys/dev/acpi/acpivideo.c,v
retrieving revision 1.7
diff -u -r1.7 acpivideo.c
--- acpivideo.c 27 Jul 2010 06:12:50 -  1.7
+++ acpivideo.c 31 Mar 2011 07:57:59 -
@@ -54,7 +54,6 @@
 intacpivideo_notify(struct aml_node *, int, void *);

 void   acpivideo_set_policy(struct acpivideo_softc *, int);
-void   acpivideo_get_dod(struct acpivideo_softc *);
 intacpi_foundvout(struct aml_node *, void *);
 intacpivideo_print(void *, const char *);

@@ -101,8 +100,6 @@
acpivideo_set_policy(sc,
DOS_SWITCH_BY_OSPM | DOS_BRIGHTNESS_BY_OSPM);

-   acpivideo_get_dod(sc);
-   aml_find_node(aaa->aaa_node, "_DCS", acpi_foundvout, sc);
aml_find_node(aaa->aaa_node, "_BCL", acpi_foundvout, sc);
 }

@@ -137,7 +134,7 @@
args.type = AML_OBJTYPE_INTEGER;

aml_evalname(sc->sc_acpi, sc->sc_devnode, "_DOS", 1, &args, &res);
-   DPRINTF(("%s: set policy to %d", DEVNAME(sc), aml_val2int(&res)));
+   DPRINTF(("%s: set policy to %X\n", DEVNAME(sc), aml_val2int(&res)));

aml_freevalue(&res);
 }
@@ -145,45 +142,23 @@
 int
 acpi_foundvout(struct aml_node *node, void *arg)
 {
-   struct aml_valueres;
-   int i, addr;
-   charfattach = 0;
-
struct acpivideo_softc *sc = (struct acpivideo_softc *)arg;
struct device *self = (struct device *)arg;
-   struct acpivideo_attach_args av;
+   struct acpi_attach_args aaa;
+   node = node->parent;

-   if (sc->sc_dod == NULL)
-   return (0);
-   DPRINTF(("Inside acpi_foundvout()"));
-   if (aml_evalname(sc->sc_acpi, node->parent, "_ADR", 0, NULL, &res)) {
-   DPRINTF(("%s: no _ADR\n", DEVNAME(sc)));
+   DPRINTF(("Inside acpi_foundvout()\n"));
+   if (node->parent != sc->sc_devnode)
return (0);
-   }
-   addr = aml_val2int(&res);
-   DPRINTF(("_ADR: %X\n", addr));
-   aml_freevalue(&res);

-   for (i = 0; i < sc->sc_dod_len; i++)
-   if (addr == (sc->sc_dod[i]&0x)) {
-   DPRINTF(("Matched: %X\n", sc->sc_dod[i]));
-   fattach = 1;
-   break;
-   }
-   if (fattach) {
-   memset(&av, 0, sizeof(av));
-   av.aaa.aaa_iot = sc->sc_acpi->sc_iot;
-   av.aaa.aaa_memt = sc->sc_acpi->sc_memt;
-   av.aaa.aaa_node = node->parent;
-   av.aaa.aaa_name = "acpivout";
-   av.dod = sc->sc_dod[i];
-   /*
-*  Make sure we don't attach twice if both _BCL and
-* _DCS methods are found by zeroing the DOD address.
-*/
-   sc->sc_dod[i] = 0;
+   if (aml_searchname(node, "_BCM") && aml_searchname(node, "_BQC")) {
+   memset(&aaa, 0, sizeof(aaa));
+   aaa.aaa_iot = sc->sc_acpi->sc_iot;
+   aaa.aaa_memt = sc->sc_acpi->sc_memt;
+   aaa.aaa_node = node;
+   aaa.aaa_name = "acpivout";

-   config_found(self, &av, acpivideo_print);
+   config_found(self, &aaa, acpivideo_print);
}

return (0);
@@ -202,38 +177,6 @@
}

   

Re: make rain(6) use a sane default delay

[Martynas Venckus]

On 3/21/11, Matthieu Herrb  wrote:
> rain(6) is useless. but still it should provide sane defaults
> ihmo. ok?

Or use sane defaults based on terminal speed;  like worms(8) does.

Index: rain.6
===
RCS file: /cvs/src/games/rain/rain.6,v
retrieving revision 1.14
diff -u -r1.14 rain.6
--- rain.6  31 May 2007 19:19:18 -  1.14
+++ rain.6  21 Mar 2011 07:39:02 -
@@ -43,11 +43,18 @@
 is modeled after the
 .Tn VAX/VMS
 program of the same name.
-To obtain the proper effect, either the terminal must be set for 9600 baud
-or the
-.Fl d
-option must be used to specify a delay, in milliseconds, between each update.
-A reasonable delay is 120; the default is 0.
+.Pp
+The options are as follows:
+.Bl -tag -width "-l length"
+.It Fl d Ar delay
+Specifies a delay, in milliseconds, between each update.
+This is useful for fast terminals.
+Reasonable values are around 20-200.
+The default is based on the terminal speed.
+If the terminal is 9600 baud or slower no delay is used.
+Otherwise, the delay is computed via the following formula:
+.Dl delay = speed / 9600 - 1.
+.El
 .Pp
 As with any
 .Xr curses 3
Index: rain.c
===
RCS file: /cvs/src/games/rain/rain.c,v
retrieving revision 1.15
diff -u -r1.15 rain.c
--- rain.c  27 Oct 2009 23:59:26 -  1.15
+++ rain.c  21 Mar 2011 07:31:37 -
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 volatile sig_atomic_t sig_caught = 0;
@@ -55,6 +56,13 @@
u_int delay = 0;
int ch;
int xpos[5], ypos[5];
+   struct termios term;
+   speed_t speed;
+
+   /* set default delay based on terminal baud rate */
+   if (tcgetattr(STDOUT_FILENO, &term) == 0 &&
+   (speed = cfgetospeed(&term)) > B9600)
+   delay = (speed / B9600) - 1;

while ((ch = getopt(argc, argv, "d:h")) != -1)
switch(ch) {

Re: fenv.h support for libm

[Martynas Venckus]

Hi,

I've taken a look at the amd64 part of the diff.  Comments inline.

I'm in the progress of implementing support for the remaining
architectures, if anyone could provide me with remote access that
would speed up the process.

> Delivered-To: marty...@venck.us
> Received: by 10.231.207.5 with SMTP id fw5cs37718ibb;
> Tue, 8 Mar 2011 12:50:47 -0800 (PST)
> Received: by 10.43.51.65 with SMTP id vh1mr6985314icb.435.1299617447631;
> Tue, 08 Mar 2011 12:50:47 -0800 (PST)
> Return-Path: 
> Received: from shear.ucar.edu (lists.openbsd.org [192.43.244.163])
> by mx.google.com with ESMTP id e15si2866420icb.3.2011.03.08.12.50.46;
> Tue, 08 Mar 2011 12:50:46 -0800 (PST)
> Received-SPF: pass (google.com: manual fallback record for domain of 
> owner-tech+m23...@openbsd.org designates 192.43.244.163 as permitted sender) 
> client-ip=192.43.244.163;
> Authentication-Results: mx.google.com; spf=pass (google.com: manual fallback 
> record for domain of owner-tech+m23...@openbsd.org designates 192.43.244.163 
> as permitted sender) smtp.mail=owner-tech+m23...@openbsd.org
> Received: from openbsd.org (localhost.ucar.edu [127.0.0.1])
>   by shear.ucar.edu (8.14.3/8.14.3) with ESMTP id p28Knngv024012;
>   Tue, 8 Mar 2011 13:49:49 -0700 (MST)
> Received: from mail-fx0-f49.google.com (mail-fx0-f49.google.com 
> [209.85.161.49])
>   by shear.ucar.edu (8.14.3/8.14.3) with ESMTP id p28KlIUF020626
>   for ; Tue, 8 Mar 2011 13:47:20 -0700 (MST)
> Received: by fxm16 with SMTP id 16so5702993fxm.8
>   for ; Tue, 08 Mar 2011 12:47:18 -0800 (PST)
> Received: by 10.223.148.83 with SMTP id o19mr1047530fav.52.1299613854399; 
> Tue, 08 Mar 2011 11:50:54 -0800 (PST)
> Received: from mdempsky.mtv.corp.google.com (mdempsky.mtv.corp.google.com 
> [172.17.81.82])
>   by mx.google.com with ESMTPS id n15sm530297fam.36.2011.03.08.11.50.51 
> (version=SSLv3 cipher=OTHER); Tue, 08 Mar 2011 11:50:53 -0800 (PST)
> Date: Tue, 8 Mar 2011 11:50:48 -0800
> From: Matthew Dempsky 
> To: tech@openbsd.org
> Subject: fenv.h support for libm
> Message-ID: <20110308195048.ga18...@mdempsky.mtv.corp.google.com>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> List-Help: 
> List-Owner: 
> List-Post: 
> List-Subscribe: 
> List-Unsubscribe: 
> X-Loop: tech@openbsd.org
> Precedence: list
> Sender: owner-t...@openbsd.org
>
> The diff below adds support for C99's  to libm.  It's based on
> NetBSD's implementation with minimal changes to work on OpenBSD.

I'm not sure how this got into the NetBSD tree, but as far as I can
tell there are some serious problems with it;  at least fesetexceptflag,
and fegetexcept are broken, default floating-point environment is
wrong, fetestexcept could be written in a better fashion.  And I've
only looked at the amd64 implementation so far.

> Currently, the diff only supports amd64, i386, and sparc64 (the only
> arches that NetBSD supports fenv.h on), but I've only tested on amd64
> so far.  Using this diff, I was able to successfully build and run
> OpenSCAD.
>
> I'd appreciate some feedback on what still needs to be done before
> committing this.  I'm unsure what to do about NetBSD's _DIAGASSERTs,

I'd say remove them.

> and I suspect the man pages might need some cleanups, but maybe those
> can be further fixed up in tree?

I'm omitting manual page changes, this part of code is already
complicated enough;  man pages can be worked on in-tree.

> Thoughts?  I'd particularly appreciate test reports on i386 and
> sparc64.

I agree with what Brad and Philip said.  Further comments inline
(from the top of my head).

I'm attaching final amd64 diff--hopefully Gmail doesn't mangle it,
otherwise you can find it on cvs:~martynas/fenv_amd64.diff.

> Index: lib/libm/Makefile
> ===
> RCS file: /cvs/src/lib/libm/Makefile,v
> retrieving revision 1.76
> diff -u -p lib/libm/Makefile
> --- lib/libm/Makefile 19 Jul 2010 12:48:23 -  1.76
> +++ lib/libm/Makefile 23 Feb 2011 02:20:57 -
> @@ -27,6 +27,7 @@ ARCH_SRCS = s_copysign.S s_copysignf.S
>  ARCH_SRCS = e_acos.S e_asin.S e_atan2.S e_exp.S e_fmod.S e_log.S e_log10.S \
>   e_remainder.S e_remainderf.S e_scalb.S e_sqrt.S e_sqrtf.S \
>   e_sqrtl.S \
> + fenv.c \
>   invtrig.c \
>   s_atan.S s_atanf.S s_ceil.S s_ceilf.S s_copysign.S s_copysignf.S \
>   s_cos.S s_cosf.S s_floor.S s_floorf.S \
> @@ -40,6 +41,7 @@ CPPFLAGS+=-I${.CURDIR}/arch/amd64
>  ARCH_SRCS = e_acos.S e_asin.S e_atan2.S e_exp.S e_fmod.S e_log.S e_log10.S \
>   e_remainder.S e_remainderf.S e_scalb.S e_sqrt.S e_sqrtf.S \
>   e_sqrtl.S \
> + fenv.c \
>   invtrig.c \
>   s_atan.S s_atanf.S s_ceil.S s_ceilf.S s_copysign.S s_

Re: ufs_open: don't leak f_buf

[Martynas Venckus]

On 8/24/10, Miod Vallat  wrote:
>> the little operating system we wrote eventually panic'd (overflowed
>> heap);  standalone ufs.c implementation we've used leaks f_buf
>> everytime ufs_open fails
>
> This is correct, but you may be leaking fp->f_blk[] as well. What about
> this instead?

yup i think it's better

ok and thx

> Index: ufs.c
> ===
> RCS file: /cvs/src/sys/lib/libsa/ufs.c,v
> retrieving revision 1.19
> diff -u -p -r1.19 ufs.c
> --- ufs.c 6 Jan 2008 11:17:18 -   1.19
> +++ ufs.c 23 Aug 2010 22:03:12 -
> @@ -98,6 +98,7 @@ static int  read_inode(ino_t, struct open
>  static int   block_map(struct open_file *, daddr_t, daddr_t *);
>  static int   buf_read_file(struct open_file *, char **, size_t *);
>  static int   search_directory(char *, struct open_file *, ino_t *);
> +static int   ufs_close_internal(struct file *);
>  #ifdef COMPAT_UFS
>  static void  ffs_oldfscompat(struct fs *);
>  #endif
> @@ -526,10 +527,9 @@ ufs_open(char *path, struct open_file *f
>  out:
>   if (buf)
>   free(buf, fs->fs_bsize);
> - if (rc) {
> - free(fp->f_fs, SBSIZE);
> - free(fp, sizeof(struct file));
> - }
> + if (rc)
> + (void)ufs_close_internal(fp);
> +
>   return (rc);
>  }
>
> @@ -537,11 +537,18 @@ int
>  ufs_close(struct open_file *f)
>  {
>   struct file *fp = (struct file *)f->f_fsdata;
> - int level;
>
>   f->f_fsdata = (void *)0;
>   if (fp == (struct file *)0)
>   return (0);
> +
> + return (ufs_close_internal(fp));
> +}
> +
> +static void
> +ufs_close_internal(struct file *fp)
> +{
> + int level;
>
>   for (level = 0; level < NIADDR; level++) {
>   if (fp->f_blk[level])

ufs_open: don't leak f_buf

[Martynas Venckus]

the little operating system we wrote eventually panic'd (overflowed
heap);  standalone ufs.c implementation we've used leaks f_buf
everytime ufs_open fails

Index: ufs.c
===
RCS file: /cvs/src/sys/lib/libsa/ufs.c,v
retrieving revision 1.19
diff -u -r1.19 ufs.c
--- ufs.c   6 Jan 2008 11:17:18 -   1.19
+++ ufs.c   21 Aug 2010 19:24:12 -
@@ -527,6 +527,8 @@
if (buf)
free(buf, fs->fs_bsize);
if (rc) {
+   if (fp->f_buf)
+   free(fp->f_buf, fp->f_fs->fs_bsize);
free(fp->f_fs, SBSIZE);
free(fp, sizeof(struct file));
}

ftp double free

[Martynas Venckus]

it crashes for me about 50% of the times like this

$ make install
===>  docbook-4.4p0 depends on: docbook-dsssl-* - not found
===>  Verifying install for docbook-dsssl-* in textproc/docbook-dsssl
===>  Checking files for docbook-dsssl-1.72
>> Fetch http://downloads.sourceforge.net/sourceforge/docbook/docbook-dsssl-1.72
.tar.gz
docbook-dsssl-1.72.tar.gz 100% ||   326 KB00:00
ftp in free(): error: chunk is already free
Abort trap (core dumped)

since url_get is called recursively now, the last call would free
proxyurl and cookie twice (cleanup_url_get);  this diff fixes it

- don't free proxyurl and cookie twice in the last recursive url_get call

Index: fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.102
diff -u -r1.102 fetch.c
--- fetch.c 23 Jul 2010 22:27:16 -  1.102
+++ fetch.c 20 Aug 2010 23:17:00 -
@@ -759,7 +759,9 @@
strncasecmp(cp, LOCATION, sizeof(LOCATION) - 1) == 0) {
cp += sizeof(LOCATION) - 1;
free(proxyurl);
+   proxyurl = NULL;
free(cookie);
+   cookie = NULL;
if (strstr(cp, "://") == NULL) {
 #ifdef SMALL
errx(1, "Relative redirect not supported");

is lvds

[Martynas Venckus]

every time x starts i get "is lvds".  i think this is a debugging
leftover, since the official xf86-video-intel tree never had it?

Index: i830_display.c
===
RCS file: /cvs/xenocara/driver/xf86-video-intel/src/i830_display.c,v
retrieving revision 1.10
diff -u -r1.10 i830_display.c
--- i830_display.c  18 Jul 2010 14:47:47 -  1.10
+++ i830_display.c  21 Aug 2010 19:15:38 -
@@ -2309,7 +2309,6 @@

switch (intel_output->type) {
case I830_OUTPUT_LVDS:
-   ErrorF("is lvds\n");
is_lvds = TRUE;
lvds_bits = intel_output->lvds_bits;
break;

updated urtw diff needs testing

[Martynas Venckus]

this is a diff against latest current.  some stuff has been committed;
to make it as small as possible (shrinks about a half)

some changes that affect 8187 have not been committed;  and are
holding this diff:

- change state properly in urtw_stop.  disable interrupts, rx, and
tx.  fixes scanning, ifconfig down, and some other issues
- fix rxgain;  for ver. 2
- remove delays;  that have been removed 8185 -> 8187

if you have an urtw, please test it, and send your dmesg.

Index: if_urtw.c
===
RCS file: /cvs/src/sys/dev/usb/if_urtw.c,v
retrieving revision 1.20
diff -u -r1.20 if_urtw.c
--- if_urtw.c   5 Jun 2009 01:21:02 -   1.20
+++ if_urtw.c   5 Jun 2009 01:41:34 -
@@ -1,6 +1,7 @@
-/* $OpenBSD: if_urtw.c,v 1.20 2009/06/05 01:21:02 martynas Exp $   */
+/* $OpenBSD: if_urtw.c,v 1.5 2009/02/11 10:44:36 kevlo Exp $   */
 
 /*-
+ * Copyright (c) 2009 Martynas Venckus 
  * Copyright (c) 2008 Weongyo Jeong 
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -79,6 +80,8 @@
 } urtw_devs[] = {
 #defineURTW_DEV_RTL8187(v, p)  \
{ { USB_VENDOR_##v, USB_PRODUCT_##v##_##p }, URTW_HWREV_8187 }
+#defineURTW_DEV_RTL8187B(v, p) \
+   { { USB_VENDOR_##v, USB_PRODUCT_##v##_##p }, URTW_HWREV_8187B }
/* Realtek RTL8187 devices. */
URTW_DEV_RTL8187(DICKSMITH, RTL8187),
URTW_DEV_RTL8187(LOGITEC,   RTL8187),
@@ -86,7 +89,15 @@
URTW_DEV_RTL8187(REALTEK,   RTL8187),
URTW_DEV_RTL8187(SPHAIRON,  RTL8187),
URTW_DEV_RTL8187(SURECOM,   EP9001G2A),
+   /* Realtek RTL8187B devices. */
+   URTW_DEV_RTL8187B(BELKIN,   F5D7050E),
+   URTW_DEV_RTL8187B(NETGEAR,  WG111V3),
+   URTW_DEV_RTL8187B(REALTEK,  RTL8187B_0),
+   URTW_DEV_RTL8187B(REALTEK,  RTL8187B_1),
+   URTW_DEV_RTL8187B(REALTEK,  RTL8187B_2),
+   URTW_DEV_RTL8187B(SITECOMEU,WL168)
 #undef URTW_DEV_RTL8187
+#undef URTW_DEV_RTL8187B
 };
 #defineurtw_lookup(v, p)   \
((const struct urtw_type *)usb_lookup(urtw_devs, v, p))
@@ -175,6 +186,52 @@
uint32_tval;
 };
 
+struct urtw_pair_idx {
+   uint8_t reg;
+   uint8_t val;
+   uint8_t idx;
+};
+
+static struct urtw_pair_idx urtw_8187b_regtbl[] = {
+   { 0xf0, 0x32, 0 }, { 0xf1, 0x32, 0 }, { 0xf2, 0x00, 0 },
+   { 0xf3, 0x00, 0 }, { 0xf4, 0x32, 0 }, { 0xf5, 0x43, 0 },
+   { 0xf6, 0x00, 0 }, { 0xf7, 0x00, 0 }, { 0xf8, 0x46, 0 },
+   { 0xf9, 0xa4, 0 }, { 0xfa, 0x00, 0 }, { 0xfb, 0x00, 0 },
+   { 0xfc, 0x96, 0 }, { 0xfd, 0xa4, 0 }, { 0xfe, 0x00, 0 },
+   { 0xff, 0x00, 0 },
+
+   { 0x58, 0x4b, 1 }, { 0x59, 0x00, 1 }, { 0x5a, 0x4b, 1 },
+   { 0x5b, 0x00, 1 }, { 0x60, 0x4b, 1 }, { 0x61, 0x09, 1 },
+   { 0x62, 0x4b, 1 }, { 0x63, 0x09, 1 }, { 0xce, 0x0f, 1 },
+   { 0xcf, 0x00, 1 }, { 0xe0, 0xff, 1 }, { 0xe1, 0x0f, 1 },
+   { 0xe2, 0x00, 1 }, { 0xf0, 0x4e, 1 }, { 0xf1, 0x01, 1 },
+   { 0xf2, 0x02, 1 }, { 0xf3, 0x03, 1 }, { 0xf4, 0x04, 1 },
+   { 0xf5, 0x05, 1 }, { 0xf6, 0x06, 1 }, { 0xf7, 0x07, 1 },
+   { 0xf8, 0x08, 1 },
+
+   { 0x4e, 0x00, 2 }, { 0x0c, 0x04, 2 }, { 0x21, 0x61, 2 },
+   { 0x22, 0x68, 2 }, { 0x23, 0x6f, 2 }, { 0x24, 0x76, 2 },
+   { 0x25, 0x7d, 2 }, { 0x26, 0x84, 2 }, { 0x27, 0x8d, 2 },
+   { 0x4d, 0x08, 2 }, { 0x50, 0x05, 2 }, { 0x51, 0xf5, 2 },
+   { 0x52, 0x04, 2 }, { 0x53, 0xa0, 2 }, { 0x54, 0x1f, 2 },
+   { 0x55, 0x23, 2 }, { 0x56, 0x45, 2 }, { 0x57, 0x67, 2 },
+   { 0x58, 0x08, 2 }, { 0x59, 0x08, 2 }, { 0x5a, 0x08, 2 },
+   { 0x5b, 0x08, 2 }, { 0x60, 0x08, 2 }, { 0x61, 0x08, 2 },
+   { 0x62, 0x08, 2 }, { 0x63, 0x08, 2 }, { 0x64, 0xcf, 2 },
+   { 0x72, 0x56, 2 }, { 0x73, 0x9a, 2 },
+
+   { 0x34, 0xf0, 0 }, { 0x35, 0x0f, 0 }, { 0x5b, 0x40, 0 },
+   { 0x84, 0x88, 0 }, { 0x85, 0x24, 0 }, { 0x88, 0x54, 0 },
+   { 0x8b, 0xb8, 0 }, { 0x8c, 0x07, 0 }, { 0x8d, 0x00, 0 },
+   { 0x94, 0x1b, 0 }, { 0x95, 0x12, 0 }, { 0x96, 0x00, 0 },
+   { 0x97, 0x06, 0 }, { 0x9d, 0x1a, 0 }, { 0x9f, 0x10, 0 },
+   { 0xb4, 0x22, 0 }, { 0xbe, 0x80, 0 }, { 0xdb, 0x00, 0 },
+   { 0xee, 0x00, 0 }, { 0x91, 0x03, 0 },
+
+   { 0x4c, 0x00, 2 }, { 0x9f, 0x00, 3 }, { 0x8c, 0x01, 0 },
+   { 0x8d, 0x10, 0 }, { 0x8e, 0x08, 0 }, { 0x8f, 0x00, 0 }
+};
+
 static uint8_t urtw_8225_agc[] = {
0x9e, 0x9e, 0x9e, 0x9e, 0x9e, 0x9e, 0x9e, 0x9e, 0x9d, 0x9c, 0x9b,
0x9a, 0x99, 0x98, 0x97, 0x96, 0x95, 0x94, 0x93, 0x92, 0x91, 0x90,
@@ -293,6 +350,36 @@
0x80, 0x90, 0xa2, 0xb5, 0xcb, 0xe4
 };
 
+static uint8_t urtw_8225v2_agc[] = {
+   0x5e, 0x5e, 0x5e, 0x5e, 0x5d, 0x5b, 0x59, 0x57,
+   0x55, 0x53, 0x51, 0x4f, 0x4d, 0x4b, 0x49, 0x47,
+   0x45, 0x43, 0x41, 0x3f, 0x3d, 0x3b, 0x39, 0x37,
+   0x35, 0x33, 0x31, 0x2f, 0x2d, 0x2b, 0x29, 0x27,
+   0x25, 0x23, 0x21, 0x1f, 0