Re: uniq: add -i option

[Theo Buehler]

> So i really don't feel like adding a BUGS section, but instead i
> think documenting that -i is intended as an ASCII-only feature is
> the way to go.

Yes, sounds reasonable.

> While here, profit from the opportunity to mention that uniq(1) is
> intended to work on the level of codepoints, not on the level of
> fully combined characters.
> 
> OK?

ok, I think that's an improvement. Thanks.

Re: OpenBSD 6.2 (up2date with syspatch) - HANGING

[Stuart Henderson]

On 2017/12/21 23:20, Maxim Bourmistrov wrote:
> 
> Fixed in HEAD?! - my ass. Whom puts HEAD into prod?! Not me any more, that's 
> for sure.
> IS LIKE DROPPING A TURBO ENGINE INTO A CAR WITH NO WHEELS.
> 
> I can dig into this as much as I want/like ON MY OWN TIME.
> But if MONEY are on the table…….

If money is on the table, perhaps you could contract someone to look at
your problems. Though unless you give a bit more information than in your
mails you'll be wasting money while someone figures out what you're
talking about.

> I think I’ll revert to 5.9 all of it.

Your call. Seems hell of a lot easier to take relayd/relayctl up to
-current for a test than reinstall to 5.9 though.

Re: OpenBSD 6.2 (up2date with syspatch) - HANGING

[Maxim Bourmistrov]

6.2-stable is NOT STABLE.
Backport, backport,backport.

6.2-stable is a beta release. 
This is what its IS.

5.9 vs. 6.2 - last one is a major downwards.
I know a lot of stuff done in tcp/ip stack and this is a good job (abt time to 
ack SMP), but
Keep those changes in beta, don’t tell ”we have rel and stable here. Eat it”.

//mxb

> 21 dec. 2017 kl. 23:19 skrev Maxim Bourmistrov :
> 
> 
> Fixed in HEAD?! - my ass. Whom puts HEAD into prod?! Not me any more, that's 
> for sure.
> IS LIKE DROPPING A TURBO ENGINE INTO CAR WITH NO WHEELS.
> 
> I can dig into this as much as I want/like ON MY OWN TIME.
> But if MONEY are on the table…….
> 
> I think I’ll revert to 5.9 all of it.
> 
> //mxb
> 
>> 21 dec. 2017 kl. 23:07 skrev Maxim Bourmistrov :
>> 
>> Solved?1
>> 
>> What abt OPTIONS in relay_http.c ?
>> Solved?
>> Maybe in HEAD.(?)
>> I have to hand-rolle this in src for 6.2 to have it working.
>> —> toread=0;
>> You know.
>> 
>> //mxb
>> 
>>> 21 dec. 2017 kl. 22:40 skrev Janne Johansson >> >:
>>> 
>>> 2017-12-21 21:58 GMT+01:00 Maxim Bourmistrov >> >:
>>> 
>>> Sorry, but I have to say
>>> Releases after 5.9 are NOT production stable.
>>> (Until all bugs are smashed within stack changes and SMP unlock).
>>> After 5.9 - cost money and effort.
>>> MONEY.
>>> 
>>> As long as they get quality reports like this, it would soon be solved.
>>>  
>> 
> 

Re: OpenBSD 6.2 (up2date with syspatch) - HANGING

[Maxim Bourmistrov]

Fixed in HEAD?! - my ass. Whom puts HEAD into prod?! Not me any more, that's 
for sure.
IS LIKE DROPPING A TURBO ENGINE INTO A CAR WITH NO WHEELS.

I can dig into this as much as I want/like ON MY OWN TIME.
But if MONEY are on the table…….

I think I’ll revert to 5.9 all of it.

//mxb

> 21 dec. 2017 kl. 23:07 skrev Maxim Bourmistrov :
> 
> Solved?1
> 
> What abt OPTIONS in relay_http.c ?
> Solved?
> Maybe in HEAD.(?)
> I have to hand-rolle this in src for 6.2 to have it working.
> —> toread=0;
> You know.
> 
> //mxb
> 
>> 21 dec. 2017 kl. 22:40 skrev Janne Johansson > >:
>> 
>> 2017-12-21 21:58 GMT+01:00 Maxim Bourmistrov > >:
>> 
>> Sorry, but I have to say
>> Releases after 5.9 are NOT production stable.
>> (Until all bugs are smashed within stack changes and SMP unlock).
>> After 5.9 - cost money and effort.
>> MONEY.
>> 
>> As long as they get quality reports like this, it would soon be solved.
>>  
> 

Re: OpenBSD 6.2 (up2date with syspatch) - HANGING

[Maxim Bourmistrov]

Solved?1

What abt OPTIONS in relay_http.c ?
Solved?
Maybe in HEAD.(?)
I have to hand-rolle this in src for 6.2 to have it working.
—> toread=0;
You know.

//mxb

> 21 dec. 2017 kl. 22:40 skrev Janne Johansson :
> 
> 2017-12-21 21:58 GMT+01:00 Maxim Bourmistrov  >:
> 
> Sorry, but I have to say
> Releases after 5.9 are NOT production stable.
> (Until all bugs are smashed within stack changes and SMP unlock).
> After 5.9 - cost money and effort.
> MONEY.
> 
> As long as they get quality reports like this, it would soon be solved.
>  

Re: libsndio: Symbols.map for libsndio

[Theo de Raadt]

> > The symbols in Symbols.map are ordered after decls in sndio.h.  Diff
> > already discussed with ratchov@, who gave his ok and is confident that
> > nothing actually uses those symbols.
> > 
> > Anyone else with a shared lib version crank?
> > 
> 
> Thanks; AFAICS, this could go in without the crank (though it wouldn't
> hurt). The symbols the diff removes are all internal "hidden"
> functions (prefixed with '_' which is reserved in C).

In this project that is incorrect.  If it changes in such a way that
an illegal program is affected, noone wants to debug that.  So we
crank.  Cranks are a tiny pinprick, rather than unknown problems.

Re: uniq: add -i option

[Claus Assmann]

On Thu, Dec 21, 2017, Theo Buehler wrote:

> I committed a minimally tweaked version of your diff:

Thanks for the fixes and the commit, I will try to do
better next time.

Re: uniq: add -i option

[Ingo Schwarze]

Hi Theo,

Theo Buehler wrote on Thu, Dec 21, 2017 at 11:06:02AM +0100:
> On Thu, Dec 21, 2017 at 01:50:37AM -0800, Claus Assmann wrote:
>> On Fri, Dec 15, 2017, Todd C. Miller wrote:
>>> On Fri, 15 Dec 2017 03:41:25 -0800, Claus Assmann wrote:

 I use uniq for some log file analysis and it contained "duplicate"
 lines which only differ in lower/upper case (user input). Hence I
 added an -i flag which also exists on FreeBSD at least.
 Maybe it's useful to add to OpenBSD?

>>> Linux has this as well.  It's OK by me.

>> So would it be ok for you to commit it or does it have to be someone
>> else (with the proper rights and some spare time) based on your "OK"?

> I committed a minimally tweaked version of your diff:
> * put the -c and -i flags together in the manual and sync usage()
> * add a sentence that i is an extension of POSIX to the STANDARDS
>   section
> * use alphabetic order of the globals iflag and uflag

I don't object to what you committed even though it is rather
half-baked.  I see how it may be useful as it stands.

Making the new feature fully UTF-8 aware would require major changes
to the code, making it substantially more complicated, which is exactly
what, as a rule, we want to avoid while maintaining POSIX utilities.
In particular, non-standard features are usually expected to not cause
major complications of standard utilities if that can be avoided.

So i really don't feel like adding a BUGS section, but instead i
think documenting that -i is intended as an ASCII-only feature is
the way to go.

While here, profit from the opportunity to mention that uniq(1) is
intended to work on the level of codepoints, not on the level of
fully combined characters.

OK?
  Ingo


Index: uniq.1
===
RCS file: /cvs/src/usr.bin/uniq/uniq.1,v
retrieving revision 1.20
diff -u -r1.20 uniq.1
--- uniq.1  21 Dec 2017 10:05:59 -  1.20
+++ uniq.1  21 Dec 2017 14:51:04 -
@@ -74,7 +74,7 @@
 by blanks, with blanks considered part of the following field.
 Field numbers are one based, i.e., the first field is field one.
 .It Fl i
-Case insensitive comparison of lines.
+Regard lower and upper case ASCII characters as identical.
 .It Fl s Ar chars
 Ignore the first
 .Ar chars
@@ -128,6 +128,10 @@
 .Qq POSIX ,
 or an unsupported value, each byte is treated as a character,
 and only space and tab are considered blank.
+.Pp
+This variable is ignored for case comparisons.
+Lower and upper case versions of non-ASCII characters are always
+considered different.
 .El
 .Sh EXIT STATUS
 .Ex -std uniq
@@ -155,3 +159,10 @@
 and
 .Fl Ns Ar number
 options have been deprecated but are still supported in this implementation.
+.Sh CAVEATS
+The
+.Nm
+utility does no Unicode normalization.
+For example, a character followed by a combining accent is considered
+different from the canonically equivalent combined character,
+and the order of combining accents is significant.

Re: bug in inteldrm on braswell

[Martin Ziemer]

> Sorry.  I want to test this myself before I commit it, but I keep
> getting distracted with other stuff.
No Sorry. I think its cool, you find the time to test everything
yourself. (Everybody knows the Problem of no time and too much things
to do)

I just repeated my mail, because there was no response and I thought,
it was not seen by those, who can submit fixes.

> That said, the first bit (pt_vaddr) looks correct, but the second bit
> doesn't make sense.  Have you actually seen the WARM_ON(!pt) being
> triggered?
No, i have not seen the Warning triggered. I just copied this Line
from DragonflyBSD, because it was in Matt Dillons fix. (Perhaps he
fixed two Issues there)

I will today compile a kernel with only the first part of the patch and
try it. If it does not fail until after christmas i assume the first
part is enough.

Re: drm: fix debug build

[Paul Irofti]

On Thu, Dec 21, 2017 at 02:25:41PM +0100, Mark Kettenis wrote:
> > Date: Thu, 21 Dec 2017 13:01:31 +0200
> > From: Paul Irofti 
> > 
> > If no one objects, I will commit this tomorrow.
> 
> Fix is wrong since it will break with gcc.  Probably best to just use
> %02x, just like we did for printing duids.

Sure thing.


Index: dev/pci/drm/i915/intel_dp.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_dp.c,v
retrieving revision 1.29
diff -u -p -u -p -r1.29 intel_dp.c
--- dev/pci/drm/i915/intel_dp.c 30 Sep 2017 07:36:56 -  1.29
+++ dev/pci/drm/i915/intel_dp.c 21 Dec 2017 14:10:45 -
@@ -4056,11 +4056,11 @@ intel_dp_probe_oui(struct intel_dp *inte
return;
 
if (intel_dp_dpcd_read_wake(_dp->aux, DP_SINK_OUI, buf, 3) == 3)
-   DRM_DEBUG_KMS("Sink OUI: %02hx%02hx%02hx\n",
+   DRM_DEBUG_KMS("Sink OUI: %02x%02x%02x\n",
  buf[0], buf[1], buf[2]);
 
if (intel_dp_dpcd_read_wake(_dp->aux, DP_BRANCH_OUI, buf, 3) == 3)
-   DRM_DEBUG_KMS("Branch OUI: %02hx%02hx%02hx\n",
+   DRM_DEBUG_KMS("Branch OUI: %02x%02x%02x\n",
  buf[0], buf[1], buf[2]);
 }
 
Index: dev/pci/drm/radeon/atombios_dp.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon/atombios_dp.c,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 atombios_dp.c
--- dev/pci/drm/radeon/atombios_dp.c1 Jul 2017 16:14:10 -   1.7
+++ dev/pci/drm/radeon/atombios_dp.c21 Dec 2017 14:10:45 -
@@ -373,11 +373,11 @@ static void radeon_dp_probe_oui(struct r
return;
 
if (drm_dp_dpcd_read(_connector->ddc_bus->aux, DP_SINK_OUI, buf, 
3) == 3)
-   DRM_DEBUG_KMS("Sink OUI: %02hx%02hx%02hx\n",
+   DRM_DEBUG_KMS("Sink OUI: %02x%02x%02x\n",
  buf[0], buf[1], buf[2]);
 
if (drm_dp_dpcd_read(_connector->ddc_bus->aux, DP_BRANCH_OUI, 
buf, 3) == 3)
-   DRM_DEBUG_KMS("Branch OUI: %02hx%02hx%02hx\n",
+   DRM_DEBUG_KMS("Branch OUI: %02x%02x%02x\n",
  buf[0], buf[1], buf[2]);
 }
 

Re: uniq: add -i option

[Craig Skinner]

On Thu, 21 Dec 2017 11:06:02 +0100 Theo Buehler wrote:
> I committed a minimally tweaked version of your diff...

Thanks everybody.

Re: bug in inteldrm on braswell

[Jonathan Gray]

On Thu, Dec 21, 2017 at 02:44:44PM +0100, Mark Kettenis wrote:
> > Date: Thu, 21 Dec 2017 13:06:00 +0100
> > From: Martin Ziemer 
> > 
> > My system crashed regularly on usage of graphical Browsers. Other
> > people had the same issues:
> > https://marc.info/?l=openbsd-misc=150916174632762=2
> > 
> > After searching for the problem I found the solution in DragonflyBSD
> > and ported those changes to our inteldrm:
> > https://www.mail-archive.com/misc@openbsd.org/msg157533.html
> > 
> > The patch fixed the issue not only for me, but for at least two other
> > users.
> > 
> > Could someone please apply those changes to our inteldrm? (Or tell me,
> > why those changes are not fitting)
> 
> Sorry.  I want to test this myself before I commit it, but I keep
> getting distracted with other stuff.
> 
> That said, the first bit (pt_vaddr) looks correct, but the second bit
> doesn't make sense.  Have you actually seen the WARM_ON(!pt) being
> triggered?

Only the first bit is in the linux commit

commit 44a7102484db0ddfa6f855b57ffe0566f739b55a
Author: Matthew Auld 
Date:   Tue Apr 12 16:57:42 2016 +0100

drm/i915: call kunmap_px on pt_vaddr

We need to kunmap pt_vaddr and not pt itself, otherwise we end up
mapping a bunch of pages without ever unmapping them.

Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Fixes: d1c54acd67dc ("drm/i915/gtt: Introduce kmap|kunmap for dma page")
Signed-off-by: Matthew Auld 
Reviewed-by: Joonas Lahtinen 
Signed-off-by: Mika Kuoppala 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1460476663-24890-4-git-send-email-matthew.a...@intel.com

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 9f165feb54ae..eebdb28acfa9 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -745,7 +745,7 @@ static void gen8_ppgtt_clear_pte_range(struct 
i915_address_space *vm,
num_entries--;
}
 
-   kunmap_px(ppgtt, pt);
+   kunmap_px(ppgtt, pt_vaddr);
 
pte = 0;
if (++pde == I915_PDES) {

> 
> > Index: i915_gem_gtt.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_gem_gtt.c,v
> > retrieving revision 1.15
> > diff -u -p -r1.15 i915_gem_gtt.c
> > --- i915_gem_gtt.c  1 Jul 2017 16:14:10 -   1.15
> > +++ i915_gem_gtt.c  16 Nov 2017 15:51:02 -
> > @@ -778,7 +778,10 @@ static void gen8_ppgtt_clear_pte_range(s
> > num_entries--;
> > }
> >  
> > -   kunmap_px(ppgtt, pt);
> > +   kunmap_px(ppgtt, pt_vaddr); /* XXX dillon, out of order
> > + * patch from linux
> > + * 44a71024 12-Apr-2016
> > + */
> >  
> > pte = 0;
> > if (++pde == I915_PDES) {
> > @@ -1317,6 +1320,8 @@ static int gen8_alloc_va_range_3lvl(stru
> > gen8_for_each_pde(pt, pd, pd_start, pd_len, temp, pde) {
> > /* Same reasoning as pd */
> > WARN_ON(!pt);
> > +if (pt == NULL) /* XXX dillon hack */
> > +continue;   /* XXX dillon hack */
> > WARN_ON(!pd_len);
> > WARN_ON(!gen8_pte_count(pd_start, pd_len));
> > 
> > 
> 

Re: bug in inteldrm on braswell

[Mark Kettenis]

> Date: Thu, 21 Dec 2017 13:06:00 +0100
> From: Martin Ziemer 
> 
> My system crashed regularly on usage of graphical Browsers. Other
> people had the same issues:
> https://marc.info/?l=openbsd-misc=150916174632762=2
> 
> After searching for the problem I found the solution in DragonflyBSD
> and ported those changes to our inteldrm:
> https://www.mail-archive.com/misc@openbsd.org/msg157533.html
> 
> The patch fixed the issue not only for me, but for at least two other
> users.
> 
> Could someone please apply those changes to our inteldrm? (Or tell me,
> why those changes are not fitting)

Sorry.  I want to test this myself before I commit it, but I keep
getting distracted with other stuff.

That said, the first bit (pt_vaddr) looks correct, but the second bit
doesn't make sense.  Have you actually seen the WARM_ON(!pt) being
triggered?

> Index: i915_gem_gtt.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_gem_gtt.c,v
> retrieving revision 1.15
> diff -u -p -r1.15 i915_gem_gtt.c
> --- i915_gem_gtt.c1 Jul 2017 16:14:10 -   1.15
> +++ i915_gem_gtt.c16 Nov 2017 15:51:02 -
> @@ -778,7 +778,10 @@ static void gen8_ppgtt_clear_pte_range(s
>   num_entries--;
>   }
>  
> - kunmap_px(ppgtt, pt);
> + kunmap_px(ppgtt, pt_vaddr); /* XXX dillon, out of order
> + * patch from linux
> + * 44a71024 12-Apr-2016
> + */
>  
>   pte = 0;
>   if (++pde == I915_PDES) {
> @@ -1317,6 +1320,8 @@ static int gen8_alloc_va_range_3lvl(stru
>   gen8_for_each_pde(pt, pd, pd_start, pd_len, temp, pde) {
>   /* Same reasoning as pd */
>   WARN_ON(!pt);
> +if (pt == NULL) /* XXX dillon hack */
> +continue;   /* XXX dillon hack */
>   WARN_ON(!pd_len);
>   WARN_ON(!gen8_pte_count(pd_start, pd_len));
> 
> 

Re: drm: fix debug build

[Mark Kettenis]

> Date: Thu, 21 Dec 2017 13:01:31 +0200
> From: Paul Irofti 
> 
> If no one objects, I will commit this tomorrow.

Fix is wrong since it will break with gcc.  Probably best to just use
%02x, just like we did for printing duids.

> On Tue, Dec 19, 2017 at 11:14:19PM +0200, Paul Irofti wrote:
> > Hi,
> > 
> > I am currently trying to fix dual-monitor support for Intel HD Graphics 520.
> > The following fixes the build when DRM_DEBUG is enabled. OK?
> > 
> > Paul
> > 
> > 
> > Index: dev/pci/drm/i915/intel_dp.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_dp.c,v
> > retrieving revision 1.29
> > diff -u -p -u -p -r1.29 intel_dp.c
> > --- dev/pci/drm/i915/intel_dp.c 30 Sep 2017 07:36:56 -  1.29
> > +++ dev/pci/drm/i915/intel_dp.c 19 Dec 2017 21:10:42 -
> > @@ -4056,11 +4056,11 @@ intel_dp_probe_oui(struct intel_dp *inte
> > return;
> >  
> > if (intel_dp_dpcd_read_wake(_dp->aux, DP_SINK_OUI, buf, 3) == 3)
> > -   DRM_DEBUG_KMS("Sink OUI: %02hx%02hx%02hx\n",
> > +   DRM_DEBUG_KMS("Sink OUI: %02hhx%02hhx%02hhx\n",
> >   buf[0], buf[1], buf[2]);
> >  
> > if (intel_dp_dpcd_read_wake(_dp->aux, DP_BRANCH_OUI, buf, 3) == 3)
> > -   DRM_DEBUG_KMS("Branch OUI: %02hx%02hx%02hx\n",
> > +   DRM_DEBUG_KMS("Branch OUI: %02hhx%02hhx%02hhx\n",
> >   buf[0], buf[1], buf[2]);
> >  }
> >  
> > Index: dev/pci/drm/radeon/atombios_dp.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/drm/radeon/atombios_dp.c,v
> > retrieving revision 1.7
> > diff -u -p -u -p -r1.7 atombios_dp.c
> > --- dev/pci/drm/radeon/atombios_dp.c1 Jul 2017 16:14:10 -   
> > 1.7
> > +++ dev/pci/drm/radeon/atombios_dp.c19 Dec 2017 21:10:42 -
> > @@ -373,11 +373,11 @@ static void radeon_dp_probe_oui(struct r
> > return;
> >  
> > if (drm_dp_dpcd_read(_connector->ddc_bus->aux, DP_SINK_OUI, buf, 
> > 3) == 3)
> > -   DRM_DEBUG_KMS("Sink OUI: %02hx%02hx%02hx\n",
> > +   DRM_DEBUG_KMS("Sink OUI: %02hhx%02hhx%02hhx\n",
> >   buf[0], buf[1], buf[2]);
> >  
> > if (drm_dp_dpcd_read(_connector->ddc_bus->aux, DP_BRANCH_OUI, 
> > buf, 3) == 3)
> > -   DRM_DEBUG_KMS("Branch OUI: %02hx%02hx%02hx\n",
> > +   DRM_DEBUG_KMS("Branch OUI: %02hhx%02hhx%02hhx\n",
> >   buf[0], buf[1], buf[2]);
> >  }
> >  
> 
> 

bug in inteldrm on braswell

[Martin Ziemer]

My system crashed regularly on usage of graphical Browsers. Other
people had the same issues:
https://marc.info/?l=openbsd-misc=150916174632762=2

After searching for the problem I found the solution in DragonflyBSD
and ported those changes to our inteldrm:
https://www.mail-archive.com/misc@openbsd.org/msg157533.html

The patch fixed the issue not only for me, but for at least two other
users.

Could someone please apply those changes to our inteldrm? (Or tell me,
why those changes are not fitting)

Index: i915_gem_gtt.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_gem_gtt.c,v
retrieving revision 1.15
diff -u -p -r1.15 i915_gem_gtt.c
--- i915_gem_gtt.c  1 Jul 2017 16:14:10 -   1.15
+++ i915_gem_gtt.c  16 Nov 2017 15:51:02 -
@@ -778,7 +778,10 @@ static void gen8_ppgtt_clear_pte_range(s
num_entries--;
}
 
-   kunmap_px(ppgtt, pt);
+   kunmap_px(ppgtt, pt_vaddr); /* XXX dillon, out of order
+ * patch from linux
+ * 44a71024 12-Apr-2016
+ */
 
pte = 0;
if (++pde == I915_PDES) {
@@ -1317,6 +1320,8 @@ static int gen8_alloc_va_range_3lvl(stru
gen8_for_each_pde(pt, pd, pd_start, pd_len, temp, pde) {
/* Same reasoning as pd */
WARN_ON(!pt);
+if (pt == NULL) /* XXX dillon hack */
+continue;   /* XXX dillon hack */
WARN_ON(!pd_len);
WARN_ON(!gen8_pte_count(pd_start, pd_len));

Re: drm: fix debug build

[Jonathan Gray]

On Thu, Dec 21, 2017 at 10:54:50PM +1100, Jonathan Gray wrote:
> This appears to break the gcc DRMDEBUG build
> 
> $ make atombios_dp.o CC=gcc COMPILER_VERSION=gcc4 
> gcc -g -Werror -Wall -Wimplicit-function-declaration  -Wno-uninitialized 
> -Wno-pointer-sign  -Wno-address-of-packed-member -Wno-constant-conversion  
> -Wframe-larger-than=2047 -mcmodel=kernel -mno-red-zone -mno-sse2 -mno-sse 
> -mno-3dnow  -mno-mmx -msoft-float -fno-omit-frame-pointer -ffreestanding 
> -fno-pie -msave-args -O2 -pipe -nostdinc -I/usr/src/sys 
> -I/usr/src/sys/arch/amd64/compile/GENERIC.MP/obj -I/usr/src/sys/arch -DDDB 
> -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DPOOL_DEBUG -DCRYPTO 
> -DSYSVMSG -DSYSVSEM -DSYSVSHM -DUVM_SWAP_ENCRYPT -DFFS -DFFS2 
> -DFFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT 
> -DNFSSERVER -DCD9660 -DUDF -DMSDOSFS -DFIFO -DFUSE -DSOCKET_SPLICE -DTCP_ECN 
> -DTCP_SIGNATURE -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX 
> -DMROUTING -DMPLS -DBOOT_CONFIG -DUSER_PCICONF -DAPERTURE -DMTRR -DNTFS 
> -DHIBERNATE -DDRMDEBUG -DPCIVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL 
> -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS="6" -DX86EMU 
> -DONEWIREVERBOSE -DMULTIPROCESSOR -DMAXUSERS=80 -D_KERNEL -MD -MP  -c 
> /usr/src/sys/dev/pci/drm/radeon/atombios_dp.c
> cc1: warnings being treated as errors
> /usr/src/sys/dev/pci/drm/radeon/atombios_dp.c: In function 
> 'radeon_dp_probe_oui':
> /usr/src/sys/dev/pci/drm/radeon/atombios_dp.c:376: warning: unknown 
> conversion type character 'h' in format
> /usr/src/sys/dev/pci/drm/radeon/atombios_dp.c:376: warning: unknown 
> conversion type character 'h' in format
> /usr/src/sys/dev/pci/drm/radeon/atombios_dp.c:376: warning: unknown 
> conversion type character 'h' in format
> /usr/src/sys/dev/pci/drm/radeon/atombios_dp.c:376: warning: too many 
> arguments for format
> /usr/src/sys/dev/pci/drm/radeon/atombios_dp.c:380: warning: unknown 
> conversion type character 'h' in format
> /usr/src/sys/dev/pci/drm/radeon/atombios_dp.c:380: warning: unknown 
> conversion type character 'h' in format
> /usr/src/sys/dev/pci/drm/radeon/atombios_dp.c:380: warning: unknown 
> conversion type character 'h' in format
> /usr/src/sys/dev/pci/drm/radeon/atombios_dp.c:380: warning: too many 
> arguments for format
> 
> $ make intel_dp.o CC=gcc COMPILER_VERSION=gcc4
> gcc -g -Werror -Wall -Wimplicit-function-declaration  -Wno-uninitialized 
> -Wno-pointer-sign  -Wno-address-of-packed-member -Wno-constant-conversion  
> -Wframe-larger-than=2047 -mcmodel=kernel -mno-red-zone -mno-sse2 -mno-sse 
> -mno-3dnow  -mno-mmx -msoft-float -fno-omit-frame-pointer -ffreestanding 
> -fno-pie -msave-args -O2 -pipe -nostdinc -I/usr/src/sys 
> -I/usr/src/sys/arch/amd64/compile/GENERIC.MP/obj -I/usr/src/sys/arch -DDDB 
> -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DPOOL_DEBUG -DCRYPTO 
> -DSYSVMSG -DSYSVSEM -DSYSVSHM -DUVM_SWAP_ENCRYPT -DFFS -DFFS2 
> -DFFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT 
> -DNFSSERVER -DCD9660 -DUDF -DMSDOSFS -DFIFO -DFUSE -DSOCKET_SPLICE -DTCP_ECN 
> -DTCP_SIGNATURE -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX 
> -DMROUTING -DMPLS -DBOOT_CONFIG -DUSER_PCICONF -DAPERTURE -DMTRR -DNTFS 
> -DHIBERNATE -DDRMDEBUG -DPCIVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL 
> -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS="6" -DX86EMU 
> -DONEWIREVERBOSE -DMULTIPROCESSOR -DMAXUSERS=80 -D_KERNEL -MD -MP  -c 
> /usr/src/sys/dev/pci/drm/i915/intel_dp.c
> cc1: warnings being treated as errors
> /usr/src/sys/dev/pci/drm/i915/intel_dp.c: In function 
> 'intel_dp_source_supports_hbr2':
> /usr/src/sys/dev/pci/drm/i915/intel_dp.c:1202: warning: comparison is always 
> true due to limited range of data type
> /usr/src/sys/dev/pci/drm/i915/intel_dp.c: In function 'intel_dp_probe_oui':
> /usr/src/sys/dev/pci/drm/i915/intel_dp.c:4059: warning: unknown conversion 
> type character 'h' in format
> /usr/src/sys/dev/pci/drm/i915/intel_dp.c:4059: warning: unknown conversion 
> type character 'h' in format
> /usr/src/sys/dev/pci/drm/i915/intel_dp.c:4059: warning: unknown conversion 
> type character 'h' in format
> /usr/src/sys/dev/pci/drm/i915/intel_dp.c:4059: warning: too many arguments 
> for format
> /usr/src/sys/dev/pci/drm/i915/intel_dp.c:4063: warning: unknown conversion 
> type character 'h' in format
> /usr/src/sys/dev/pci/drm/i915/intel_dp.c:4063: warning: unknown conversion 
> type character 'h' in format
> /usr/src/sys/dev/pci/drm/i915/intel_dp.c:4063: warning: unknown conversion 
> type character 'h' in format
> /usr/src/sys/dev/pci/drm/i915/intel_dp.c:4063: warning: too many arguments 
> for format
> /usr/src/sys/dev/pci/drm/i915/intel_dp.c: In function 
> 'intel_dp_init_connector':
> /usr/src/sys/dev/pci/drm/i915/intel_dp.c:6059: warning: comparison is always 
> true due to limited range of data type
> 
> kprintf_length_specs in src/gnu/gcc/gcc/c-format.c has
> { "h", FMT_LEN_h, STD_C89, NULL, 0, 0 },
> 
> 

Re: drm: fix debug build

[Jonathan Gray]

This appears to break the gcc DRMDEBUG build

$ make atombios_dp.o CC=gcc COMPILER_VERSION=gcc4 
gcc -g -Werror -Wall -Wimplicit-function-declaration  -Wno-uninitialized 
-Wno-pointer-sign  -Wno-address-of-packed-member -Wno-constant-conversion  
-Wframe-larger-than=2047 -mcmodel=kernel -mno-red-zone -mno-sse2 -mno-sse 
-mno-3dnow  -mno-mmx -msoft-float -fno-omit-frame-pointer -ffreestanding 
-fno-pie -msave-args -O2 -pipe -nostdinc -I/usr/src/sys 
-I/usr/src/sys/arch/amd64/compile/GENERIC.MP/obj -I/usr/src/sys/arch -DDDB 
-DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DPOOL_DEBUG -DCRYPTO 
-DSYSVMSG -DSYSVSEM -DSYSVSHM -DUVM_SWAP_ENCRYPT -DFFS -DFFS2 -DFFS_SOFTUPDATES 
-DUFS_DIRHASH -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT -DNFSSERVER -DCD9660 -DUDF 
-DMSDOSFS -DFIFO -DFUSE -DSOCKET_SPLICE -DTCP_ECN -DTCP_SIGNATURE -DINET6 
-DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX -DMROUTING -DMPLS -DBOOT_CONFIG 
-DUSER_PCICONF -DAPERTURE -DMTRR -DNTFS -DHIBERNATE -DDRMDEBUG -DPCIVERBOSE 
-DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD 
-DWSDISPLAY_DEFAULTSCREENS="6" -DX86EMU -DONEWIREVERBOSE -DMULTIPROCESSOR 
-DMAXUSERS=80 -D_KERNEL -MD -MP  -c 
/usr/src/sys/dev/pci/drm/radeon/atombios_dp.c
cc1: warnings being treated as errors
/usr/src/sys/dev/pci/drm/radeon/atombios_dp.c: In function 
'radeon_dp_probe_oui':
/usr/src/sys/dev/pci/drm/radeon/atombios_dp.c:376: warning: unknown conversion 
type character 'h' in format
/usr/src/sys/dev/pci/drm/radeon/atombios_dp.c:376: warning: unknown conversion 
type character 'h' in format
/usr/src/sys/dev/pci/drm/radeon/atombios_dp.c:376: warning: unknown conversion 
type character 'h' in format
/usr/src/sys/dev/pci/drm/radeon/atombios_dp.c:376: warning: too many arguments 
for format
/usr/src/sys/dev/pci/drm/radeon/atombios_dp.c:380: warning: unknown conversion 
type character 'h' in format
/usr/src/sys/dev/pci/drm/radeon/atombios_dp.c:380: warning: unknown conversion 
type character 'h' in format
/usr/src/sys/dev/pci/drm/radeon/atombios_dp.c:380: warning: unknown conversion 
type character 'h' in format
/usr/src/sys/dev/pci/drm/radeon/atombios_dp.c:380: warning: too many arguments 
for format

$ make intel_dp.o CC=gcc COMPILER_VERSION=gcc4
gcc -g -Werror -Wall -Wimplicit-function-declaration  -Wno-uninitialized 
-Wno-pointer-sign  -Wno-address-of-packed-member -Wno-constant-conversion  
-Wframe-larger-than=2047 -mcmodel=kernel -mno-red-zone -mno-sse2 -mno-sse 
-mno-3dnow  -mno-mmx -msoft-float -fno-omit-frame-pointer -ffreestanding 
-fno-pie -msave-args -O2 -pipe -nostdinc -I/usr/src/sys 
-I/usr/src/sys/arch/amd64/compile/GENERIC.MP/obj -I/usr/src/sys/arch -DDDB 
-DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DPOOL_DEBUG -DCRYPTO 
-DSYSVMSG -DSYSVSEM -DSYSVSHM -DUVM_SWAP_ENCRYPT -DFFS -DFFS2 -DFFS_SOFTUPDATES 
-DUFS_DIRHASH -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT -DNFSSERVER -DCD9660 -DUDF 
-DMSDOSFS -DFIFO -DFUSE -DSOCKET_SPLICE -DTCP_ECN -DTCP_SIGNATURE -DINET6 
-DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX -DMROUTING -DMPLS -DBOOT_CONFIG 
-DUSER_PCICONF -DAPERTURE -DMTRR -DNTFS -DHIBERNATE -DDRMDEBUG -DPCIVERBOSE 
-DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD 
-DWSDISPLAY_DEFAULTSCREENS="6" -DX86EMU -DONEWIREVERBOSE -DMULTIPROCESSOR 
-DMAXUSERS=80 -D_KERNEL -MD -MP  -c /usr/src/sys/dev/pci/drm/i915/intel_dp.c
cc1: warnings being treated as errors
/usr/src/sys/dev/pci/drm/i915/intel_dp.c: In function 
'intel_dp_source_supports_hbr2':
/usr/src/sys/dev/pci/drm/i915/intel_dp.c:1202: warning: comparison is always 
true due to limited range of data type
/usr/src/sys/dev/pci/drm/i915/intel_dp.c: In function 'intel_dp_probe_oui':
/usr/src/sys/dev/pci/drm/i915/intel_dp.c:4059: warning: unknown conversion type 
character 'h' in format
/usr/src/sys/dev/pci/drm/i915/intel_dp.c:4059: warning: unknown conversion type 
character 'h' in format
/usr/src/sys/dev/pci/drm/i915/intel_dp.c:4059: warning: unknown conversion type 
character 'h' in format
/usr/src/sys/dev/pci/drm/i915/intel_dp.c:4059: warning: too many arguments for 
format
/usr/src/sys/dev/pci/drm/i915/intel_dp.c:4063: warning: unknown conversion type 
character 'h' in format
/usr/src/sys/dev/pci/drm/i915/intel_dp.c:4063: warning: unknown conversion type 
character 'h' in format
/usr/src/sys/dev/pci/drm/i915/intel_dp.c:4063: warning: unknown conversion type 
character 'h' in format
/usr/src/sys/dev/pci/drm/i915/intel_dp.c:4063: warning: too many arguments for 
format
/usr/src/sys/dev/pci/drm/i915/intel_dp.c: In function 'intel_dp_init_connector':
/usr/src/sys/dev/pci/drm/i915/intel_dp.c:6059: warning: comparison is always 
true due to limited range of data type

kprintf_length_specs in src/gnu/gcc/gcc/c-format.c has
{ "h", FMT_LEN_h, STD_C89, NULL, 0, 0 },

not

{ "h", FMT_LEN_h, STD_C89, "hh", FMT_LEN_hh, STD_C99 },

like printf_length_specs does.

printf(9) documents %hh as
"Argument of char type.  This format specifier is accepted by the
kernel but will be handled as %h."

It also documents 

Re: drm: fix debug build

[Paul Irofti]

If no one objects, I will commit this tomorrow.

On Tue, Dec 19, 2017 at 11:14:19PM +0200, Paul Irofti wrote:
> Hi,
> 
> I am currently trying to fix dual-monitor support for Intel HD Graphics 520.
> The following fixes the build when DRM_DEBUG is enabled. OK?
> 
> Paul
> 
> 
> Index: dev/pci/drm/i915/intel_dp.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_dp.c,v
> retrieving revision 1.29
> diff -u -p -u -p -r1.29 intel_dp.c
> --- dev/pci/drm/i915/intel_dp.c   30 Sep 2017 07:36:56 -  1.29
> +++ dev/pci/drm/i915/intel_dp.c   19 Dec 2017 21:10:42 -
> @@ -4056,11 +4056,11 @@ intel_dp_probe_oui(struct intel_dp *inte
>   return;
>  
>   if (intel_dp_dpcd_read_wake(_dp->aux, DP_SINK_OUI, buf, 3) == 3)
> - DRM_DEBUG_KMS("Sink OUI: %02hx%02hx%02hx\n",
> + DRM_DEBUG_KMS("Sink OUI: %02hhx%02hhx%02hhx\n",
> buf[0], buf[1], buf[2]);
>  
>   if (intel_dp_dpcd_read_wake(_dp->aux, DP_BRANCH_OUI, buf, 3) == 3)
> - DRM_DEBUG_KMS("Branch OUI: %02hx%02hx%02hx\n",
> + DRM_DEBUG_KMS("Branch OUI: %02hhx%02hhx%02hhx\n",
> buf[0], buf[1], buf[2]);
>  }
>  
> Index: dev/pci/drm/radeon/atombios_dp.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/radeon/atombios_dp.c,v
> retrieving revision 1.7
> diff -u -p -u -p -r1.7 atombios_dp.c
> --- dev/pci/drm/radeon/atombios_dp.c  1 Jul 2017 16:14:10 -   1.7
> +++ dev/pci/drm/radeon/atombios_dp.c  19 Dec 2017 21:10:42 -
> @@ -373,11 +373,11 @@ static void radeon_dp_probe_oui(struct r
>   return;
>  
>   if (drm_dp_dpcd_read(_connector->ddc_bus->aux, DP_SINK_OUI, buf, 
> 3) == 3)
> - DRM_DEBUG_KMS("Sink OUI: %02hx%02hx%02hx\n",
> + DRM_DEBUG_KMS("Sink OUI: %02hhx%02hhx%02hhx\n",
> buf[0], buf[1], buf[2]);
>  
>   if (drm_dp_dpcd_read(_connector->ddc_bus->aux, DP_BRANCH_OUI, 
> buf, 3) == 3)
> - DRM_DEBUG_KMS("Branch OUI: %02hx%02hx%02hx\n",
> + DRM_DEBUG_KMS("Branch OUI: %02hhx%02hhx%02hhx\n",
> buf[0], buf[1], buf[2]);
>  }
>  

Re: uniq: add -i option

[Theo Buehler]

On Thu, Dec 21, 2017 at 01:50:37AM -0800, Claus Assmann wrote:
> On Fri, Dec 15, 2017, Todd C. Miller wrote:
> > On Fri, 15 Dec 2017 03:41:25 -0800, Claus Assmann wrote:
> 
> > > I use uniq for some log file analysis and it contained "duplicate"
> > > lines which only differ in lower/upper case (user input). Hence I
> > > added an -i flag which also exists on FreeBSD at least.
> > > Maybe it's useful to add to OpenBSD?
> 
> > Linux has this as well.  It's OK by me.
> 
> So would it be ok for you to commit it or does it have to be someone
> else (with the proper rights and some spare time) based on your "OK"?
> 

I committed a minimally tweaked version of your diff:
* put the -c and -i flags together in the manual and sync usage()
* add a sentence that i is an extension of POSIX to the STANDARDS
  section
* use alphabetic order of the globals iflag and uflag

Re: uniq: add -i option

[Claus Assmann]

On Fri, Dec 15, 2017, Todd C. Miller wrote:
> On Fri, 15 Dec 2017 03:41:25 -0800, Claus Assmann wrote:

> > I use uniq for some log file analysis and it contained "duplicate"
> > lines which only differ in lower/upper case (user input). Hence I
> > added an -i flag which also exists on FreeBSD at least.
> > Maybe it's useful to add to OpenBSD?

> Linux has this as well.  It's OK by me.

So would it be ok for you to commit it or does it have to be someone
else (with the proper rights and some spare time) based on your "OK"?

Re: libsndio: Symbols.map for libsndio

[Alexandre Ratchov]

On Wed, Dec 20, 2017 at 03:55:30PM +0100, Jeremie Courreges-Anglas wrote:
> 
> Hi,
> 
> Here's a simple diff to tighten things up.
> 
> check_sym output:
> /usr/lib/libsndio.so.6.1 --> obj/libsndio.so.7.0
> Dynamic export changes:
> removed:
>   __bss_start
>   __data_start
>   _aucat_close
>   _aucat_open
>   _aucat_pollfd
>   _aucat_rdata
>   _aucat_revents
>   _aucat_rmsg
>   _aucat_setfl
>   _aucat_wdata
>   _aucat_wmsg
>   _edata
>   _end
>   _fini
>   _init
>   _mio_aucat_open
>   _mio_create
>   _mio_rmidi_open
>   _sio_aucat_open
>   _sio_create
>   _sio_onmove_cb
>   _sio_onvol_cb
>   _sio_printpos
>   _sio_sun_open
>   _sndio_debug
>   _sndio_debug_init
>   _sndio_parsenum
>   _sndio_parsetype
> 
> PLT removed:
>   _aucat_close
>   _aucat_open
>   _aucat_pollfd
>   _aucat_rdata
>   _aucat_rmsg
>   _aucat_setfl
>   _aucat_wdata
>   _aucat_wmsg
>   _mio_aucat_open
>   _mio_create
>   _mio_rmidi_open
>   _sio_aucat_open
>   _sio_create
>   _sio_onmove_cb
>   _sio_onvol_cb
>   _sio_printpos
>   _sio_sun_open
>   _sndio_debug_init
>   _sndio_parsenum
>   _sndio_parsetype
> 
> 
> The symbols in Symbols.map are ordered after decls in sndio.h.  Diff
> already discussed with ratchov@, who gave his ok and is confident that
> nothing actually uses those symbols.
> 
> Anyone else with a shared lib version crank?
> 

Thanks; AFAICS, this could go in without the crank (though it wouldn't
hurt). The symbols the diff removes are all internal "hidden"
functions (prefixed with '_' which is reserved in C).

> ok?
> 

sure