Re: missing "struct socket;" in netinet/ip_var.h prevents compiling kernel without MROUTING option

[Nick Briggs]

I'm good with that.

> On Jul 13, 2017, at 7:37 PM, Ted Unangst  wrote:
> 
> Nick Briggs wrote:
>> because netinet/ip_var.h, which it includes, depends on
>>   #ifdef MROUTING
>>   extern struct socket *ip_mrouter[]; /* multicast routing daemon */
>>   #endif
>> to get a declaration of struct socket outside of any parameter lists.
> 
> I think this is a better fix. Two parts.
> 
> 1. pfkeyv2_parsemessage.c doesn't even need this header. remove it.
> 
> 2. to prevent this from happening again, move the forward declaration in
> ip_var.h to the end, so that it will fail regardless of compile options. i
> think this is better than deliberately exporting another type here.
> 
> tested with and without MROUTING set.
> 
> Index: net/pfkeyv2_parsemessage.c
> ===
> RCS file: /cvs/src/sys/net/pfkeyv2_parsemessage.c,v
> retrieving revision 1.52
> diff -u -p -r1.52 pfkeyv2_parsemessage.c
> --- net/pfkeyv2_parsemessage.c26 Jun 2017 09:17:55 -  1.52
> +++ net/pfkeyv2_parsemessage.c14 Jul 2017 02:35:13 -
> @@ -76,7 +76,6 @@
> #include 
> #include 
> #include 
> -#include 
> #include 
> 
> #if NPF > 0
> Index: netinet/ip_var.h
> ===
> RCS file: /cvs/src/sys/netinet/ip_var.h,v
> retrieving revision 1.79
> diff -u -p -r1.79 ip_var.h
> --- netinet/ip_var.h  26 Jun 2017 19:06:12 -  1.79
> +++ netinet/ip_var.h  14 Jul 2017 02:34:17 -
> @@ -193,9 +193,6 @@ struct ipq {
> extern struct ipstat ipstat;
> extern LIST_HEAD(ipqhead, ipq)ipq;/* ip reass. queue */
> extern int ip_defttl; /* default IP ttl */
> -#ifdef MROUTING
> -extern struct socket *ip_mrouter[];  /* multicast routing daemon */
> -#endif
> 
> #define IPMTUDISCTIMEOUT (10 * 60)/* as per RFC 1191 */
> 
> @@ -259,6 +256,10 @@ int   rip_output(struct mbuf *, struct so
> intrip_usrreq(struct socket *,
>   int, struct mbuf *, struct mbuf *, struct mbuf *, struct proc *);
> intrip_attach(struct socket *, int);
> +
> +#ifdef MROUTING
> +extern struct socket *ip_mrouter[];  /* multicast routing daemon */
> +#endif
> 
> #endif /* _KERNEL */
> #endif /* _NETINET_IP_VAR_H_ */

Re: missing "struct socket;" in netinet/ip_var.h prevents compiling kernel without MROUTING option

[Ted Unangst]

Nick Briggs wrote:
>  because netinet/ip_var.h, which it includes, depends on
>#ifdef MROUTING
>extern struct socket *ip_mrouter[]; /* multicast routing daemon */
>#endif
> to get a declaration of struct socket outside of any parameter lists.

I think this is a better fix. Two parts.

1. pfkeyv2_parsemessage.c doesn't even need this header. remove it.

2. to prevent this from happening again, move the forward declaration in
ip_var.h to the end, so that it will fail regardless of compile options. i
think this is better than deliberately exporting another type here.

tested with and without MROUTING set.

Index: net/pfkeyv2_parsemessage.c
===
RCS file: /cvs/src/sys/net/pfkeyv2_parsemessage.c,v
retrieving revision 1.52
diff -u -p -r1.52 pfkeyv2_parsemessage.c
--- net/pfkeyv2_parsemessage.c  26 Jun 2017 09:17:55 -  1.52
+++ net/pfkeyv2_parsemessage.c  14 Jul 2017 02:35:13 -
@@ -76,7 +76,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #if NPF > 0
Index: netinet/ip_var.h
===
RCS file: /cvs/src/sys/netinet/ip_var.h,v
retrieving revision 1.79
diff -u -p -r1.79 ip_var.h
--- netinet/ip_var.h26 Jun 2017 19:06:12 -  1.79
+++ netinet/ip_var.h14 Jul 2017 02:34:17 -
@@ -193,9 +193,6 @@ struct ipq {
 extern struct ipstat ipstat;
 extern LIST_HEAD(ipqhead, ipq) ipq;/* ip reass. queue */
 extern int ip_defttl;  /* default IP ttl */
-#ifdef MROUTING
-extern struct socket *ip_mrouter[];/* multicast routing daemon */
-#endif
 
 #define IPMTUDISCTIMEOUT (10 * 60) /* as per RFC 1191 */
 
@@ -259,6 +256,10 @@ int rip_output(struct mbuf *, struct so
 int rip_usrreq(struct socket *,
int, struct mbuf *, struct mbuf *, struct mbuf *, struct proc *);
 int rip_attach(struct socket *, int);
+
+#ifdef MROUTING
+extern struct socket *ip_mrouter[];/* multicast routing daemon */
+#endif
 
 #endif /* _KERNEL */
 #endif /* _NETINET_IP_VAR_H_ */

missing "struct socket;" in netinet/ip_var.h prevents compiling kernel without MROUTING option

[Nick Briggs]

>Synopsis:  missing "struct socket;" in netinet/ip_var.h prevents compiling 
>without MROUTING option
>Category:  system
>Environment:
System  : OpenBSD 6.1
Details : OpenBSD 6.1-stable (PIGEON) #5: Thu Jul 13 17:09:51 PDT 
2017
 briggs@pigeon:/usr/obj/sys/arch/i386/compile/PIGEON

Architecture: OpenBSD.i386
Machine : i386
>Description:

If the MROUTING option is not included in the kernel configuration, code such 
as ./sys/net/pfkeyv2_parsemessage.c does not compile, failing with:

cc1: warnings being treated as errors
In file included from /usr/src/sys/net/pfkeyv2_parsemessage.c:79:
/usr/src/sys/netinet/ip_var.h:223: warning: 'struct socket' declared inside 
parameter list
/usr/src/sys/netinet/ip_var.h:223: warning: its scope is only this definition 
or declaration, which is probably not what you want
/usr/src/sys/netinet/ip_var.h:254: warning: 'struct socket' declared inside 
parameter list
/usr/src/sys/netinet/ip_var.h:258: warning: 'struct socket' declared inside 
parameter list
/usr/src/sys/netinet/ip_var.h:260: warning: 'struct socket' declared inside 
parameter list
/usr/src/sys/netinet/ip_var.h:261: warning: 'struct socket' declared inside 
parameter list

 because netinet/ip_var.h, which it includes, depends on
   #ifdef MROUTING
   extern struct socket *ip_mrouter[]; /* multicast routing daemon */
   #endif
to get a declaration of struct socket outside of any parameter lists.

This was also reported 25-Jun-2014 by Ivan Solonin on the OpenBSD-misc list, 
but there was no follow-up or fix.

>How-To-Repeat:
remove option MROUTING from kernel configuration, rebuild the kernel.
>Fix:

One possibility:

cvs server: Diffing sys/netinet
Index: sys/netinet/ip_var.h
===
RCS file: /cvs/src/sys/netinet/ip_var.h,v
retrieving revision 1.70
diff -u -p -r1.70 ip_var.h
--- sys/netinet/ip_var.h13 Mar 2017 20:18:21 -  1.70
+++ sys/netinet/ip_var.h14 Jul 2017 01:11:48 -
@@ -216,6 +216,7 @@ extern int la_hold_total;
 
 extern struct rttimer_queue *ip_mtudisc_timeout_q;
 extern struct pool ipqent_pool;
+struct socket;
 struct route;
 struct inpcb;
 

Re: regression using vncviewer (net/ssvnc) on inteldrm

[Stuart Henderson]

On 2017/07/13 19:57, Mark Kettenis wrote:
> > Date: Wed, 12 Jul 2017 13:11:25 +0100
> > From: Stuart Henderson 
> > 
> > On 2017/07/12 07:46, Paul de Weerd wrote:
> > > Note that vncviewer was never really blazing fast, but at least it was
> > > workable.  Obviously, vncviewer is doing something weird because other
> > > programs don't seem affected by whatever changed (I'm guessing it's
> > > the switch to using the modesetting driver on my hardware).
> > 
> > Confirmed here. Switching back to the intel driver fixes it:
> > 
> > Section "Device"
> >Identifier  "Intel Graphics"
> >Driver  "intel"
> > EndSection
> 
> Is this regression important enough to hold off the commit of the
> driver selection change until we have a better understanding of what
> is going wrong here?

I don't think it's important enough to hold off at this point. We have
a viable workaround for now, imho we should get more people running with
modesetting to give us more experience with it.

> And does this only affect Haswell or are others also affected?

I don't have much of a range of hardware to test with, but I've just
tried on an X201 (i7-620M - Ironlake), which is now using the modesetting
driver by default too, and doesn't have a problem with vncviewer.

Re: resume from suspend fails from time to time

[Mark Kettenis]

> Date: Fri, 7 Jul 2017 23:07:35 +0200
> From: Jesper Wallin 
> 
> >Synopsis:  resume from suspend fails from time to time.
> >Category:  inteldrm or acpi (guessing)
> >Environment:
>   System  : OpenBSD 6.1
>   Details : OpenBSD 6.1-current (GENERIC.MP) #0: Fri Jul  7 13:09:46 
> CEST 2017
>
> jes...@nostromo.ifconfig.se:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   When I closed the lid on my Lenovo X1 Carbon (Broadwell) or run zzz, it 
> suspends normally.
>   However, from time to time (50/50), when I open the lid again or press 
> the power button, 
>   the led starts blinking as it always does when resuming, but nothing 
> happens.
> 
>   The led keeps blinking and fans speed up, but I must restart it by 
> holding down the
>   power-button until it turns off and then reboot and run fsck.
> 
>   This worked fine in 6.0, 6.1 and -current, up to about a week ago.
> >Fix:
>   Unknown

I have an x1 gen3 as well, and it resumes reliably as far as I can
tell.  Can't rule out that there are bugs in the new inteldrm code,
but there are also some fresh network stack locking diffs in the tree
that created some fallout.  Those are slowly getting fixed so please
keep trying new kernels.

Re: regression using vncviewer (net/ssvnc) on inteldrm

[Mark Kettenis]

> Date: Wed, 12 Jul 2017 13:11:25 +0100
> From: Stuart Henderson 
> 
> On 2017/07/12 07:46, Paul de Weerd wrote:
> > Note that vncviewer was never really blazing fast, but at least it was
> > workable.  Obviously, vncviewer is doing something weird because other
> > programs don't seem affected by whatever changed (I'm guessing it's
> > the switch to using the modesetting driver on my hardware).
> 
> Confirmed here. Switching back to the intel driver fixes it:
> 
> Section "Device"
>Identifier  "Intel Graphics"
>Driver  "intel"
> EndSection

Is this regression important enough to hold off the commit of the
driver selection change until we have a better understanding of what
is going wrong here?

And does this only affect Haswell or are others also affected?

coredump of ..., write failed: errno 14

[Stuart Henderson]

I've seen this a lot recently (14 = EFAULT)

2017-07-13T16:05:57.935Z symphytum /bsd: coredump of Xorg(62706), write failed: 
errno 14
2017-07-13T16:05:57.993Z symphytum /bsd: coredump of chrome(46797), write 
failed: errno 14
2017-07-13T16:05:58.081Z symphytum /bsd: coredump of vi(26461), write failed: 
errno 14
2017-07-13T16:05:58.124Z symphytum /bsd: coredump of ksh(24425), write failed: 
errno 14

partial coredumps get saved but they aren't usable with gdb..
This is with kern.nosuidcoredump=2, there's plenty of space in /var/crash.

Any ideas?

Re: multicast reception fails for certain groups on interfaces with TI ThunderLAN chip

[Nick Briggs]

Yeah, I'm good with that, and in fact enm_addrlo is defined as u_int8_t which I 
hadn't gone to check.

../sys/netinet/if_ether.h:  u_int8_t enm_addrlo[ETHER_ADDR_LEN]; /* low  or 
only address of range */

I've verified the code works:

# tcpdump -e -s 1500 -p multicast and not broadcast
tcpdump: listening on tl0, link-type EN10MB
08:49:37.903615 00:25:00:3e:ae:2d 01:00:5e:00:00:fb ip 72: 192.168.42.64.mdns > 
224.0.0.251.mdns: 0 A (QU)? nobody.local. (30)
08:49:38.936298 00:25:00:3e:ae:2d 01:00:5e:00:00:fb ip 72: 192.168.42.64.mdns > 
224.0.0.251.mdns: 0 A? nobody.local. (30)
08:49:41.963983 00:25:00:3e:ae:2d 01:00:5e:00:00:fb ip 72: 192.168.42.64.mdns > 
224.0.0.251.mdns: 0 A? nobody.local. (30)

Thanks.

-- Nick Briggs

> On Jul 13, 2017, at 7:44 AM, Christian Weisgerber  wrote:
> 
> Nick Briggs:
> 
>>  The code in if_tl.c, tl_calchash() is wrong in that it doesn't 
>> compensate for signed char type so that the XOR operations to generate the 
>> multicast hash index are polluted by sign extension if the MSbit of the 1st 
>> and 4th or 2nd and 5th bytes of the multicast destination ethernet address 
>> are not equal.  This is the patch for that problem:
> 
> We should just use unsigned chars.
> Kill a prototype for a nonexisting function in a neighboring file,
> while here.
> 
> Index: if_tl.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_tl.c,v
> retrieving revision 1.70
> diff -u -p -r1.70 if_tl.c
> --- if_tl.c   22 Jan 2017 10:17:38 -  1.70
> +++ if_tl.c   13 Jul 2017 14:39:09 -
> @@ -272,7 +272,7 @@ void tl_miibus_writereg(struct device *,
> void tl_miibus_statchg(struct device *);
> 
> void tl_setmode(struct tl_softc *, uint64_t);
> -int tl_calchash(caddr_t);
> +int tl_calchash(u_int8_t *);
> void tl_iff(struct tl_softc *);
> void tl_setfilt(struct tl_softc *, caddr_t, int);
> void tl_softreset(struct tl_softc *, int);
> @@ -747,7 +747,7 @@ tl_setmode(struct tl_softc *sc, uint64_t
>  * the folded 24-bit value is split into 6-bit portions and XOR'd.
>  */
> int
> -tl_calchash(caddr_t addr)
> +tl_calchash(u_int8_t *addr)
> {
>   int t;
> 
> Index: if_wb.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_wb.c,v
> retrieving revision 1.68
> diff -u -p -r1.68 if_wb.c
> --- if_wb.c   22 Jan 2017 10:17:38 -  1.68
> +++ if_wb.c   13 Jul 2017 14:36:07 -
> @@ -154,7 +154,6 @@ int wb_mii_readreg(struct wb_softc *, st
> int wb_mii_writereg(struct wb_softc *, struct wb_mii_frame *);
> 
> void wb_setcfg(struct wb_softc *, uint64_t);
> -u_int8_t wb_calchash(caddr_t);
> void wb_setmulti(struct wb_softc *);
> void wb_reset(struct wb_softc *);
> void wb_fixmedia(struct wb_softc *);
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de

Re: multicast reception fails for certain groups on interfaces with TI ThunderLAN chip

[Christian Weisgerber]

Nick Briggs:

>   The code in if_tl.c, tl_calchash() is wrong in that it doesn't 
> compensate for signed char type so that the XOR operations to generate the 
> multicast hash index are polluted by sign extension if the MSbit of the 1st 
> and 4th or 2nd and 5th bytes of the multicast destination ethernet address 
> are not equal.  This is the patch for that problem:

We should just use unsigned chars.
Kill a prototype for a nonexisting function in a neighboring file,
while here.

Index: if_tl.c
===
RCS file: /cvs/src/sys/dev/pci/if_tl.c,v
retrieving revision 1.70
diff -u -p -r1.70 if_tl.c
--- if_tl.c 22 Jan 2017 10:17:38 -  1.70
+++ if_tl.c 13 Jul 2017 14:39:09 -
@@ -272,7 +272,7 @@ void tl_miibus_writereg(struct device *,
 void tl_miibus_statchg(struct device *);
 
 void tl_setmode(struct tl_softc *, uint64_t);
-int tl_calchash(caddr_t);
+int tl_calchash(u_int8_t *);
 void tl_iff(struct tl_softc *);
 void tl_setfilt(struct tl_softc *, caddr_t, int);
 void tl_softreset(struct tl_softc *, int);
@@ -747,7 +747,7 @@ tl_setmode(struct tl_softc *sc, uint64_t
  * the folded 24-bit value is split into 6-bit portions and XOR'd.
  */
 int
-tl_calchash(caddr_t addr)
+tl_calchash(u_int8_t *addr)
 {
int t;
 
Index: if_wb.c
===
RCS file: /cvs/src/sys/dev/pci/if_wb.c,v
retrieving revision 1.68
diff -u -p -r1.68 if_wb.c
--- if_wb.c 22 Jan 2017 10:17:38 -  1.68
+++ if_wb.c 13 Jul 2017 14:36:07 -
@@ -154,7 +154,6 @@ int wb_mii_readreg(struct wb_softc *, st
 int wb_mii_writereg(struct wb_softc *, struct wb_mii_frame *);
 
 void wb_setcfg(struct wb_softc *, uint64_t);
-u_int8_t wb_calchash(caddr_t);
 void wb_setmulti(struct wb_softc *);
 void wb_reset(struct wb_softc *);
 void wb_fixmedia(struct wb_softc *);
-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: Hang since inteldrm works when stopping X or running xrandr

[Frank Groeneveld]

On Wed, Jul 12, 2017, at 22:54, Mark Kettenis wrote:
> Unless you have a serial console (possibly through Intel AMT), there's
> probably not much you can do yourself.  Given the CPU model, I don't
> think your machine has Intel AMT support.
> 
> If you have a displayport (male) to mini displayport (female) convert
> or a displayport to VGA converter lying around I might be able to test
> this myself.

Hi Mark,

Unfortunately I only have mini-displayport (male) to displayport, VGA or
DVI. I do have a USB serial console adapter though. Would it be possible
to start something useful with that?

Frank

Re: link fix in help.1

[Jeremie Courreges-Anglas]

Andras Farkas  writes:

> Evening!  Noticed the link in help.1 to the FAQ was missing a slash at the 
> end.
> diff is also attached in case it gets mangled

Committed, thanks.

> --- help.1  Thu Jul 13 03:56:58 2017
> +++ fixdhelp.1  Thu Jul 13 03:57:31 2017
> @@ -53,7 +53,7 @@ option.
>  Other
>  .Ox
>  references include the FAQ (Frequently Asked Questions) located at
> -.Lk https://www.openbsd.org/faq ,
> +.Lk https://www.openbsd.org/faq/ ,
>  which is mostly intended for administrators and assumes the reader possesses
>  a working knowledge of
>  .Ux .
>
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

link fix in help.1

[Andras Farkas]

Evening!  Noticed the link in help.1 to the FAQ was missing a slash at the end.
diff is also attached in case it gets mangled

--- help.1  Thu Jul 13 03:56:58 2017
+++ fixdhelp.1  Thu Jul 13 03:57:31 2017
@@ -53,7 +53,7 @@ option.
 Other
 .Ox
 references include the FAQ (Frequently Asked Questions) located at
-.Lk https://www.openbsd.org/faq ,
+.Lk https://www.openbsd.org/faq/ ,
 which is mostly intended for administrators and assumes the reader possesses
 a working knowledge of
 .Ux .


help1diff
Description: Binary data

Re: Hang since inteldrm works when stopping X or running xrandr

[Frank Groeneveld]

Mark Kettenis  schreef op 12 juli 2017 19:50:50 CEST:
>> Date: Wed, 12 Jul 2017 10:08:42 +0200 (CEST)
>> From: fr...@frankgroeneveld.nl
>> 
>> >Synopsis:   System hangs when X is stopped or xrandr is run after
>disabling builtin screen
>> >Category:   system
>> >Environment:
>>  System  : OpenBSD 6.1
>>  Details : OpenBSD 6.1-current (GENERIC.MP) #93: Thu Jul  6
>15:41:21 MDT 2017
>>  
>dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> 
>>  Architecture: OpenBSD.amd64
>>  Machine : amd64
>> >Description:
>>  Since the inteldrm update I now have a much better working display
>on this system, thanks!
>>  I'm only experiencing one problem. When I have attached an external
>monitor to my laptop,
>>  I disable the builtin screen using: xrandr --output eDP-1 --off
>>  After that, the whole systems hangs when I shutdown X (halt -p or
>pkill X) or when I run any xrandr command
>> >How-To-Repeat:
>>  xrandr --output eDP-1 --off
>>  pkill X
>> >Fix:
>>  I haven't found any workarounds
>
>Unfortunately I don't have a hardware setup that could reproduce this.

Is there anything I can try or send you to debug it?

Frank