Re: Kernel Panic on 6.2 amd64 when run0 RT3070 based device is attached during boot

[Denis]

Last tests shows that 6.2amd64 system goes reboot in a random manner
with run0 driver is loaded. Reboots mainly caused when data is
transferred other run0 device but absolutely sporadically. No dmesg
messages provided with these reboots.

It has been tested on two different laptops with the same configuration
as in dmesg listed before. Different USB ports has been used for test.

I've changed usb cable length, RT3070 based cards from different
manufacturers, but behavior is the same.

Hope this helps to improve the run0 driver.

Thanks

On 1/18/2018 12:23 PM, Denis wrote:
> Hi All,
>
> From time to time I receive Kernel Panic on OpenBSD 6.2 amd64 when run0
> driver for RT3070 based device is attached to the Lenovo X220 laptop
> during boot.
> It appears just after file system is mounted. Next boot I receive that
> file system was not properly unmounted.
> But after FS checking is completed the same run0 device usually works as
> expected.  
>
> The same thing when I connected RT3070 device to the fully booted
> OpenBSD6.2 amd64. Three times out of ten I got kernel panic issue.
>
> I have tested two RT3070 adapters on other systems. Both works smoothly.
> But on 6.2 amd64 each of them produces panic issue with the same
> probability.
>
> I can implement any patches and test it if necessary to make it work.
>
> The boot time kernel trap (if you need a full 3000+ lines kernel panic
> message please let me know) and self explanatory dmesg are shown below:
>
> panic() at panic+0x123
> _rw_exit_write(8139e3be) at _rw_exit_write+0x6e
> pf_purge(800032d81590) at pf_purge+0x148
> taskq_thread(0) at taskq_thread+0x67
> end trace frame: 0x0, count: 91
> End of stack trace.
> splassert: if_down: want 1 have 256
> panic: spl assertion failure in if_down
> Starting stack trace...
> panic() at panic+0x11b
> splassert_fail(80218000,100,810b9707) at splassert_fail+0x67
> if_down(80218000) at if_down+0x39
> if_downall() at if_downall+0x51
> boot(104) at boot+0x76
> reboot(815b79ce) at reboot+0x4b
> panic() at panic+0x123
> splassert_fail(80218000,100,810b9707) at splassert_fail+0x67
> if_down(80218000) at if_down+0x39
> if_downall() at if_downall+0x51
> boot(104) at boot+0x76
> reboot(815b79ce) at reboot+0x4b
> panic() at panic+0x123
> splassert_fail(80218000,100,810b9707) at splassert_fail+0x67
> if_down(80218000) at if_down+0x39
> if_downall() at if_downall+0x51
> boot(104) at boot+0x76
> reboot(815b79ce) at reboot+0x4b
> panic() at panic+0x123
> splassert_fail(80218000,100,810b9707) at splassert_fail+0x67
> if_down(80218000) at if_down+0x39
> if_downall() at if_downall+0x51
> boot(104) at boot+0x76
> reboot(815b79ce) at reboot+0x4b
> panic() at panic+0x123
> splassert_fail(80218000,100,810b9707) at splassert_fail+0x67
> if_down(80218000) at if_down+0x39
> if_downall() at if_downall+0x51
> boot(104) at boot+0x76
> reboot(815b79ce) at reboot+0x4b
> panic() at panic+0x123
> splassert_fail(80218000,100,810b9707) at splassert_fail+0x67
> if_down(80218000) at if_down+0x39
> if_downall() at if_downall+0x51
> boot(104) at boot+0x76
> reboot(815b79ce) at reboot+0x4b
> panic() at panic+0x123
> splassert_fail(80218000,100,810b9707) at splassert_fail+0x67
> if_down(80218000) at if_down+0x39
> if_downall() at if_downall+0x51
> boot(104) at boot+0x76
> reboot(815b79ce) at reboot+0x4b
> panic() at panic+0x123
> splassert_fail(80218000,100,810b9707) at splassert_fail+0x67
> if_down(80218000) at if_down+0x39
> if_downall() at if_downall+0x51
> boot(104) at boot+0x76
> ...
>
> OpenBSD 6.2 (GENERIC.MP) #1: Thu Jan 18 11:09:28 UTC 2018
> r...@machine.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8451125248 (8059MB)
> avail mem = 8192278528 (7812MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (64 entries)
> bios0: vendor LENOVO version "8DET72WW (1.42 )" date 02/18/2016
> bios0: LENOVO 5491C51
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF!
> TCPA SSDT SSDT DMAR UEFI UEFI UEFI
> acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4)
> EHC1(S3) EHC2(S3) HDEF(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2791.33 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu0: 256KB 64b/lin

Re: Zap PF_TRANS_ALTQ

[Lawrence Teo]

On Fri, Jan 19, 2018 at 02:18:08PM -0700, Theo de Raadt wrote:
> > > On Fri, Jan 19, 2018 at 08:24:23PM +, Stuart Henderson wrote:
> > > > To be honest though, unless it's in the way of something, I'm not sure 
> > > > it's
> > > > worth removing.
> > > 
> > > If those constatns are in ports and require revision bumps, we can
> > > leave it in the header.  Rebuilding base is one thing, but doing
> > > manual work with ports is not worth it.
> > 
> > This seems overblown.
> > 
> > The PF API is frozen.
> > 
> > It is only an ABI between the kernel and pfctl -- that is the sticky
> > and tricky upgrade position.  Everything else can must be able to
> > handle change.
> 
> 
> I meant to say: the PF API is *NOT* frozen.  We can change it at any time!
> 
> It is just a tiny bit uncomfortable to incompatibly change the bsd:pfctl
> interface.  The timing just has to be right.
> 
> ports?  Who cares!

Thank you all for the feedback, and thanks sthen@ for searching the
ports tree.

I will coordinate with Theo regarding a suitable time to commit this.

Re: snmpd trap.c uninitialized variable

[Jeremie Courreges-Anglas]

On Sat, Jan 20 2018, Rob Pierce  wrote:
> The pid_t confused me, but I believe this is correct - i.e. referring to the
> packet id as oppose to a process id.
>
> Comments?  Ok?

Makes sense, ok.  Would you mind converting the %zd to %zu, while here?

> Index: trap.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/trap.c,v
> retrieving revision 1.29
> diff -u -p -r1.29 trap.c
> --- trap.c21 Apr 2017 13:46:15 -  1.29
> +++ trap.c20 Jan 2018 16:41:25 -
> @@ -65,7 +65,6 @@ trap_agentx(struct agentx_handle *h, str
>   int  ret = AGENTX_ERR_NONE;
>   int  seensysuptime, seentrapoid;
>   size_t   len = 0;
> - pid_tpid = -1;
>   char*v = NULL;
>  
>   *varcpy = NULL;
> @@ -125,8 +124,8 @@ trap_agentx(struct agentx_handle *h, str
>  
>   if (varbind != NULL)
>   len = ber_calc_len(varbind);
> - log_debug("trap_agentx: from pid %u len %zd elements %d",
> - pid, len, x);
> + log_debug("trap_agentx: from packetid %d len %zd elements %d",
> + pdu->hdr->packetid, len, x);
>  
>   trap_send(&o, varbind);
>  
>

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

Re: tcp reaper timeout

[Mike Belopuhov]

On Sat, Jan 20, 2018 at 15:17 +0100, Alexander Bluhm wrote:
> Hi,
>

Hi,

While I'm not against making all TCP timeouts look similar, I'd like
to understand if there's any other reason to do it other than
"consistency".

> The tcp reaper timeout is still imlemented as soft timeout.  So it
> can run while net lock is held by others and it is not synchronized
> with the other tcp timeouts.

Am I right to say that this is not an issue?  Neither pool_put nor
tcpstat_inc requre a NET_LOCK, correct?

> Convert it to an ordinary tcp timeout
> so it is scheduled on the same timeout thread.  It grabs the net
> lock to make sure that softnet has finished its work.
>

This just makes other threads who want to grab NET_LOCK wait for
a pool_put to finish, but where's the benefit?

> ok?
> 
> bluhm
> 

What's up with the diagnostics?  Do you suspect a race of some sorts?

> @@ -462,5 +464,26 @@ tcp_timer_2msl(void *arg)
>   tp = tcp_close(tp);
>  
>   out:
> + NET_UNLOCK();
> +}
> +
> +void
> +tcp_timer_reaper(void *arg)
> +{
> + struct tcpcb *tp = arg;
> + int i;
> +
> + NET_LOCK();
> +#ifdef DIAGNOSTIC
> + if ((tp->t_flags & TF_DEAD) == 0)
> + panic("%s: tcpcb %p is not dead", __func__, tp);
> + for (i = 0; i < TCPT_NTIMERS; i++) {
> + if (TCP_TIMER_ISARMED(tp, i))
> + panic("%s: tcpcb %p timer %d is armed",
> + __func__, tp, i);
> + }
> +#endif
> + pool_put(&tcpcb_pool, tp);
> + tcpstat_inc(tcps_closed);
>   NET_UNLOCK();
>  }

snmpd trap.c uninitialized variable

[Rob Pierce]

The pid_t confused me, but I believe this is correct - i.e. referring to the
packet id as oppose to a process id.

Comments?  Ok?

Index: trap.c
===
RCS file: /cvs/src/usr.sbin/snmpd/trap.c,v
retrieving revision 1.29
diff -u -p -r1.29 trap.c
--- trap.c  21 Apr 2017 13:46:15 -  1.29
+++ trap.c  20 Jan 2018 16:41:25 -
@@ -65,7 +65,6 @@ trap_agentx(struct agentx_handle *h, str
int  ret = AGENTX_ERR_NONE;
int  seensysuptime, seentrapoid;
size_t   len = 0;
-   pid_tpid = -1;
char*v = NULL;
 
*varcpy = NULL;
@@ -125,8 +124,8 @@ trap_agentx(struct agentx_handle *h, str
 
if (varbind != NULL)
len = ber_calc_len(varbind);
-   log_debug("trap_agentx: from pid %u len %zd elements %d",
-   pid, len, x);
+   log_debug("trap_agentx: from packetid %d len %zd elements %d",
+   pdu->hdr->packetid, len, x);
 
trap_send(&o, varbind);
 

Re: inteldrm(4) tests needed

[Mike Belopuhov]

On Mon, Jan 15, 2018 at 01:02 +0100, Mark Kettenis wrote:
> The diff below adopts more of the Linux code to manage i2c
> transactions on hardware supported by inteldrm(4).  The i2c stuff is
> reponsible for detecting panels and monitors, so it is somewhat
> important that this works right.  And the Linux code developed some
> quirks over the years that my rewrite of the code to use OpenBSD APIs
> didn't have.
> 
> So I'm looking for testers.  I'm especially interested in tests of
> external displays on all sorts of connector types (VGA, DVI, HDMI,
> DP).  It would be really great to get some tests on older stuff with
> (S)DVO.  Please let me know if there are regressions or if this fixes
> things that are currently broken.  But all reports are welcome.
> Please include a dmesg and some information about the display and
> connector type.
> 

Hi,

I've been running with this since it hit the tree and it has fixed
a major issue for me: an external HDMI output was marked 'disconnected'
only a few minutes after being connected.  The output worked fine,
but I presume X was notified that something changed and my window
manager would restrict the area for popups and drop down menus to the
main screen, as in they would only appear on the panel of the laptop,
regardless of where the actual window was.  So huge thanks for that!

In the meantime (somewhere around Mesa update and a backout), another
issue got fixed.  If a test 60fps video would've been displayed on the
panel, a visible tearing artefact would be visible in the upper portion
of the screen.  And now it's gone.  Thanks Jonathan and Mark for your
work on this, it's greatly appreciated!

My hardware is an X1 Carbon 2017 (Kaby Lake) with a WQHD (2560x1440)
panel and a 1920x1080 external monitor.

Cheers,
Mike

Re: disabled code in ksh tree.c

[Anton Lindqvist]

On Tue, Jan 16, 2018 at 04:29:59PM +0100, Jeremie Courreges-Anglas wrote:
> On Mon, Jan 15 2018, "Michael W. Bombardieri"  wrote:
> > On Sun, Jan 14, 2018 at 05:47:43PM +0100, Jeremie Courreges-Anglas wrote:
> >> On Sun, Jan 14 2018, Anton Lindqvist  wrote:
> >> > On Thu, Jan 11, 2018 at 03:25:15PM +0800, Michael W. Bombardieri wrote:
> >> >> Hello,
> >> >> 
> >> >> Revision 1.9 of tree.c (from 1999) added the disabled code and it
> >> >> is still disabled. Would it be better to remove it?
> >> >
> >> > Fine with me. Anyone else willing OK?
> >> 
> >> I'd rather understand exactly what this code does and what the comment
> >> actually means.  The TEXEC case can definitely be reached.
> >
> > The TEXEC case in ptree() happens if fptreef() or snptreef() are called with
> > format specifier %T.
> > From what I see it is called like this:
> >
> > exchild() -> snptreef() -> vfptreef() -> ptree().
> >
> > Here snptreef() is used to copy the command string to be executed into 
> > a new Proc structure before exchild() forks and calls execute().
> >
> > When calling ptree() by running shell command "ls -l", t->type is first 
> > TEXEC,
> > then after the goto t->type is TCOM.
> > So the switch statement appears to happen twice.
> >
> > The comment "print original vars" does happen, but after the goto in TCOM 
> > case.
> > The if(t->vars) code in TCOM case is the same as the disabled 
> > if(t->left->vars)
> > code in TEXEC case.
> > Also, t->vars appears to be NULL in TEXEC case, but t->vars is set in TCOM 
> > case.
> > In terms of how the code is structured, vars belongs to TCOM not TEXEC.
> > So afaics the disabled code doesn't do anything useful.
> 
> Thanks for the explanation, ok jca@

This has now been committed, thanks!

tcp reaper timeout

[Alexander Bluhm]

Hi,

The tcp reaper timeout is still imlemented as soft timeout.  So it
can run while net lock is held by others and it is not synchronized
with the other tcp timeouts.  Convert it to an ordinary tcp timeout
so it is scheduled on the same timeout thread.  It grabs the net
lock to make sure that softnet has finished its work.

ok?

bluhm

Index: netinet/tcp_subr.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/tcp_subr.c,v
retrieving revision 1.167
diff -u -p -r1.167 tcp_subr.c
--- netinet/tcp_subr.c  7 Dec 2017 16:52:21 -   1.167
+++ netinet/tcp_subr.c  19 Jan 2018 23:05:37 -
@@ -436,7 +436,6 @@ tcp_newtcpcb(struct inpcb *inp)
TCP_INIT_DELACK(tp);
for (i = 0; i < TCPT_NTIMERS; i++)
TCP_TIMER_INIT(tp, i);
-   timeout_set(&tp->t_reap_to, tcp_reaper, tp);
 
tp->sack_enable = tcp_do_sack;
tp->t_flags = tcp_do_rfc1323 ? (TF_REQ_SCALE|TF_REQ_TSTMP) : 0;
@@ -532,21 +531,12 @@ tcp_close(struct tcpcb *tp)
m_free(tp->t_template);
 
tp->t_flags |= TF_DEAD;
-   timeout_add(&tp->t_reap_to, 0);
+   TCP_TIMER_ARM(tp, TCPT_REAPER, 0);
 
-   inp->inp_ppcb = 0;
+   inp->inp_ppcb = NULL;
soisdisconnected(so);
in_pcbdetach(inp);
return (NULL);
-}
-
-void
-tcp_reaper(void *arg)
-{
-   struct tcpcb *tp = arg;
-
-   pool_put(&tcpcb_pool, tp);
-   tcpstat_inc(tcps_closed);
 }
 
 int
Index: netinet/tcp_timer.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/tcp_timer.c,v
retrieving revision 1.60
diff -u -p -r1.60 tcp_timer.c
--- netinet/tcp_timer.c 29 Oct 2017 14:56:36 -  1.60
+++ netinet/tcp_timer.c 20 Jan 2018 12:36:04 -
@@ -70,12 +70,14 @@ voidtcp_timer_rexmt(void *);
 void   tcp_timer_persist(void *);
 void   tcp_timer_keep(void *);
 void   tcp_timer_2msl(void *);
+void   tcp_timer_reaper(void *);
 
 const tcp_timer_func_t tcp_timer_funcs[TCPT_NTIMERS] = {
tcp_timer_rexmt,
tcp_timer_persist,
tcp_timer_keep,
tcp_timer_2msl,
+   tcp_timer_reaper,
 };
 
 /*
@@ -462,5 +464,26 @@ tcp_timer_2msl(void *arg)
tp = tcp_close(tp);
 
  out:
+   NET_UNLOCK();
+}
+
+void
+tcp_timer_reaper(void *arg)
+{
+   struct tcpcb *tp = arg;
+   int i;
+
+   NET_LOCK();
+#ifdef DIAGNOSTIC
+   if ((tp->t_flags & TF_DEAD) == 0)
+   panic("%s: tcpcb %p is not dead", __func__, tp);
+   for (i = 0; i < TCPT_NTIMERS; i++) {
+   if (TCP_TIMER_ISARMED(tp, i))
+   panic("%s: tcpcb %p timer %d is armed",
+   __func__, tp, i);
+   }
+#endif
+   pool_put(&tcpcb_pool, tp);
+   tcpstat_inc(tcps_closed);
NET_UNLOCK();
 }
Index: netinet/tcp_timer.h
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/tcp_timer.h,v
retrieving revision 1.14
diff -u -p -r1.14 tcp_timer.h
--- netinet/tcp_timer.h 4 Oct 2016 13:54:32 -   1.14
+++ netinet/tcp_timer.h 20 Jan 2018 12:35:44 -
@@ -39,12 +39,13 @@
  * Definitions of the TCP timers.  These timers are counted
  * down PR_SLOWHZ times a second.
  */
-#defineTCPT_NTIMERS4
+#defineTCPT_NTIMERS5
 
 #defineTCPT_REXMT  0   /* retransmit */
 #defineTCPT_PERSIST1   /* retransmit persistence */
 #defineTCPT_KEEP   2   /* keep alive */
 #defineTCPT_2MSL   3   /* 2*msl quiet time timer */
+#defineTCPT_REAPER 4   /* delayed cleanup timeout */
 
 /*
  * The TCPT_REXMT timer is used to force retransmissions.
@@ -108,8 +109,8 @@
 #defineTCP_DELACK_TICKS (hz / PR_FASTHZ)   /* time to delay ACK */
 
 #ifdef TCPTIMERS
-const char *tcptimers[] =
-{ "REXMT", "PERSIST", "KEEP", "2MSL" };
+const char *tcptimers[TCPT_NTIMERS] =
+{ "REXMT", "PERSIST", "KEEP", "2MSL", "REAPER" };
 #endif /* TCPTIMERS */
 
 /*
Index: netinet/tcp_var.h
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/tcp_var.h,v
retrieving revision 1.128
diff -u -p -r1.128 tcp_var.h
--- netinet/tcp_var.h   2 Nov 2017 14:01:18 -   1.128
+++ netinet/tcp_var.h   19 Jan 2018 23:01:00 -
@@ -193,8 +193,6 @@ struct tcpcb {
u_short t_pmtud_ip_hl;  /* IP header length from ICMP payload */
 
int pf;
-
-   struct  timeout t_reap_to;  /* delayed cleanup timeout */
 };
 
 #defineintotcpcb(ip)   ((struct tcpcb *)(ip)->inp_ppcb)
@@ -679,6 +677,7 @@ tcpstat_pkt(enum tcpstat_counters pcount
counters_pkt(tcpcounters, pcounter, bcounter, v);
 }
 
+extern struct pool tcpcb_pool;
 extern struct inpcbtable tcbtable; /* head of queue of active tcpcb's */
 extern u_int32_t tcp_now;  /

Re: fix xserver build with clang on armv7

[Matthieu Herrb]

On Sat, Jan 20, 2018 at 10:50:58PM +1100, Jonathan Gray wrote:
> On Sat, Jan 20, 2018 at 11:19:22AM +0100, Matthieu Herrb wrote:
> > Hi,
> > 
> > I'm not sure if the __VFP_FP__ section below was still useful for gcc
> > builds, at lead it doesn't build and doesn't look needed with clang
> > (the functions are all provied by libcompiler_rt, which is included).
> > 
> > ok ?
> 
> The __VFP_FP__ block seems to be a local change that predates
> xenocara 1.1 can we just remove it?
> 
> Added in XF4 1.4
> 
> 
> revision 1.4
> date: 2004/06/16 16:04:12;  author: todd;  state: Exp;  lines: +113 -574;
> add cats support from drahn@ (thanks!)
> 

Yes I think it wasn't needed with recent gcc on armv7. Just never took
the time to verify whether it could be removed or not.
I'll remove it since we don't care about building /usr/xenocara wrt
older /usr/src. 

> 
> > 
> > Index: hw/xfree86/os-support/bsd/arm_video.c
> > ===
> > RCS file: 
> > /cvs/OpenBSD/xenocara/xserver/hw/xfree86/os-support/bsd/arm_video.c,v
> > retrieving revision 1.14
> > diff -u -p -u -r1.14 arm_video.c
> > --- hw/xfree86/os-support/bsd/arm_video.c   28 Sep 2015 07:14:00 -  
> > 1.14
> > +++ hw/xfree86/os-support/bsd/arm_video.c   20 Jan 2018 10:17:09 -
> > @@ -88,7 +88,8 @@ xf86PrivilegedInit(void)
> >  xf86OpenConsole();
> >  }
> >  
> > -#ifdef __VFP_FP__
> > +
> > +#if defined(__VFP_FP__) && !defined(__clang__)
> >  /*
> >   * force softfloat functions into binary,
> >   * yes the protos/ret are all bogus.
> > @@ -149,4 +150,5 @@ __subdf3();
> >  __subsf3();
> >  __truncdfsf2();
> >  }
> > -#endif /* __VFP_FP__ */
> > +#endif /* __VFP_FP__ && !__clang__ */
> > +
> > 
> > -- 
> > Matthieu Herrb
> > 

-- 
Matthieu Herrb

Re: fix xserver build with clang on armv7

[Jeremie Courreges-Anglas]

On Sat, Jan 20 2018, Jonathan Gray  wrote:
> On Sat, Jan 20, 2018 at 11:19:22AM +0100, Matthieu Herrb wrote:
>> Hi,
>> 
>> I'm not sure if the __VFP_FP__ section below was still useful for gcc
>> builds, at lead it doesn't build and doesn't look needed with clang
>> (the functions are all provied by libcompiler_rt, which is included).
>> 
>> ok ?
>
> The __VFP_FP__ block seems to be a local change that predates
> xenocara 1.1 can we just remove it?
>
> Added in XF4 1.4
>
> 
> revision 1.4
> date: 2004/06/16 16:04:12;  author: todd;  state: Exp;  lines: +113 -574;
> add cats support from drahn@ (thanks!)
> 

fwiw, I just "fixed" the existing code in my local copy, keeping in mind
that softfloat on arm should get away soon...

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

Re: fix xserver build with clang on armv7

[Jonathan Gray]

On Sat, Jan 20, 2018 at 11:19:22AM +0100, Matthieu Herrb wrote:
> Hi,
> 
> I'm not sure if the __VFP_FP__ section below was still useful for gcc
> builds, at lead it doesn't build and doesn't look needed with clang
> (the functions are all provied by libcompiler_rt, which is included).
> 
> ok ?

The __VFP_FP__ block seems to be a local change that predates
xenocara 1.1 can we just remove it?

Added in XF4 1.4


revision 1.4
date: 2004/06/16 16:04:12;  author: todd;  state: Exp;  lines: +113 -574;
add cats support from drahn@ (thanks!)


> 
> Index: hw/xfree86/os-support/bsd/arm_video.c
> ===
> RCS file: 
> /cvs/OpenBSD/xenocara/xserver/hw/xfree86/os-support/bsd/arm_video.c,v
> retrieving revision 1.14
> diff -u -p -u -r1.14 arm_video.c
> --- hw/xfree86/os-support/bsd/arm_video.c 28 Sep 2015 07:14:00 -  
> 1.14
> +++ hw/xfree86/os-support/bsd/arm_video.c 20 Jan 2018 10:17:09 -
> @@ -88,7 +88,8 @@ xf86PrivilegedInit(void)
>  xf86OpenConsole();
>  }
>  
> -#ifdef __VFP_FP__
> +
> +#if defined(__VFP_FP__) && !defined(__clang__)
>  /*
>   * force softfloat functions into binary,
>   * yes the protos/ret are all bogus.
> @@ -149,4 +150,5 @@ __subdf3();
>  __subsf3();
>  __truncdfsf2();
>  }
> -#endif /* __VFP_FP__ */
> +#endif /* __VFP_FP__ && !__clang__ */
> +
> 
> -- 
> Matthieu Herrb
> 

fix xserver build with clang on armv7

[Matthieu Herrb]

Hi,

I'm not sure if the __VFP_FP__ section below was still useful for gcc
builds, at lead it doesn't build and doesn't look needed with clang
(the functions are all provied by libcompiler_rt, which is included).

ok ?

Index: hw/xfree86/os-support/bsd/arm_video.c
===
RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/os-support/bsd/arm_video.c,v
retrieving revision 1.14
diff -u -p -u -r1.14 arm_video.c
--- hw/xfree86/os-support/bsd/arm_video.c   28 Sep 2015 07:14:00 -  
1.14
+++ hw/xfree86/os-support/bsd/arm_video.c   20 Jan 2018 10:17:09 -
@@ -88,7 +88,8 @@ xf86PrivilegedInit(void)
 xf86OpenConsole();
 }
 
-#ifdef __VFP_FP__
+
+#if defined(__VFP_FP__) && !defined(__clang__)
 /*
  * force softfloat functions into binary,
  * yes the protos/ret are all bogus.
@@ -149,4 +150,5 @@ __subdf3();
 __subsf3();
 __truncdfsf2();
 }
-#endif /* __VFP_FP__ */
+#endif /* __VFP_FP__ && !__clang__ */
+

-- 
Matthieu Herrb

[patch] resolv.h lacked definition for in{6}_addr

[Alexander Traud]

found via GNU autoconf and its AC_CHECK_HEADERS
Kudos go to .
As workaround, I am going to change my configure script to use
AC_HEADER_RESOLV.

--- src/include/resolv.h
+++ src/include/resolv.h
@@ -92,2 +92,3 @@
 #include 
+#include 
 #include