svn commit: r346884 - head/sys/netpfil/ipfw

[Andrey V. Elsukov]

Author: ae
Date: Mon Apr 29 09:33:16 2019
New Revision: 346884
URL: https://svnweb.freebsd.org/changeset/base/346884

Log:
  Add IPv6 support for O_IPLEN opcode.
  
  Obtained from:Yandex LLC
  MFC after:1 week
  Sponsored by: Yandex LLC

Modified:
  head/sys/netpfil/ipfw/ip_fw2.c

Modified: head/sys/netpfil/ipfw/ip_fw2.c
==
--- head/sys/netpfil/ipfw/ip_fw2.c  Mon Apr 29 05:35:52 2019
(r346883)
+++ head/sys/netpfil/ipfw/ip_fw2.c  Mon Apr 29 09:33:16 2019
(r346884)
@@ -2191,9 +2191,11 @@ do { 
\
break;
 
case O_IPID:
-   case O_IPLEN:
case O_IPTTL:
-   if (is_ipv4) {  /* only for IP packets */
+   if (!is_ipv4)
+   break;
+   case O_IPLEN:
+   {   /* only for IP packets */
uint16_t x;
uint16_t *p;
int i;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r346885 - head/sbin/ipfw

[Andrey V. Elsukov]

Author: ae
Date: Mon Apr 29 09:52:53 2019
New Revision: 346885
URL: https://svnweb.freebsd.org/changeset/base/346885

Log:
  Handle HAVE_PROTO flag and print "proto" keyword for O_IP4 and O_IP6
  opcodes when it is needed.
  This should fix the problem, when printed by `ipfw show` rule could not
  be added due to missing "proto" keyword.
  
  MFC after:2 weeks

Modified:
  head/sbin/ipfw/ipfw2.c

Modified: head/sbin/ipfw/ipfw2.c
==
--- head/sbin/ipfw/ipfw2.c  Mon Apr 29 09:33:16 2019(r346884)
+++ head/sbin/ipfw/ipfw2.c  Mon Apr 29 09:52:53 2019(r346885)
@@ -1701,9 +1701,13 @@ print_instruction(struct buf_pr *bp, const struct form
IPFW_TLV_STATE_NAME));
break;
case O_IP6:
+   if (state->flags & HAVE_PROTO)
+   bprintf(bp, " proto");
bprintf(bp, " ip6");
break;
case O_IP4:
+   if (state->flags & HAVE_PROTO)
+   bprintf(bp, " proto");
bprintf(bp, " ip4");
break;
case O_ICMP6TYPE:
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r346888 - head/sys/kern

[Mark Johnston]

Author: markj
Date: Mon Apr 29 13:23:32 2019
New Revision: 346888
URL: https://svnweb.freebsd.org/changeset/base/346888

Log:
  Stop checking TD_IDLETHREAD() in buffer cache routines.
  
  These predicates are vestigal and cannot be true today.  For example,
  idle threads are not allowed to acquire locks.
  
  Also cache curthread in breada().
  
  No functional change intended.
  
  Reviewed by:  kib, mckusick
  MFC after:1 week
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D20066

Modified:
  head/sys/kern/vfs_bio.c

Modified: head/sys/kern/vfs_bio.c
==
--- head/sys/kern/vfs_bio.c Mon Apr 29 13:20:55 2019(r346887)
+++ head/sys/kern/vfs_bio.c Mon Apr 29 13:23:32 2019(r346888)
@@ -2073,8 +2073,11 @@ breada(struct vnode * vp, daddr_t * rablkno, int * rab
 struct ucred * cred, int flags, void (*ckhashfunc)(struct buf *))
 {
struct buf *rabp;
+   struct thread *td;
int i;
 
+   td = curthread;
+
for (i = 0; i < cnt; i++, rablkno++, rabsize++) {
if (inmem(vp, *rablkno))
continue;
@@ -2083,16 +2086,14 @@ breada(struct vnode * vp, daddr_t * rablkno, int * rab
brelse(rabp);
continue;
}
-   if (!TD_IS_IDLETHREAD(curthread)) {
 #ifdef RACCT
-   if (racct_enable) {
-   PROC_LOCK(curproc);
-   racct_add_buf(curproc, rabp, 0);
-   PROC_UNLOCK(curproc);
-   }
-#endif /* RACCT */
-   curthread->td_ru.ru_inblock++;
+   if (racct_enable) {
+   PROC_LOCK(curproc);
+   racct_add_buf(curproc, rabp, 0);
+   PROC_UNLOCK(curproc);
}
+#endif /* RACCT */
+   td->td_ru.ru_inblock++;
rabp->b_flags |= B_ASYNC;
rabp->b_flags &= ~B_INVAL;
if ((flags & GB_CKHASH) != 0) {
@@ -2148,16 +2149,14 @@ breadn_flags(struct vnode *vp, daddr_t blkno, int size
 */
readwait = 0;
if ((bp->b_flags & B_CACHE) == 0) {
-   if (!TD_IS_IDLETHREAD(td)) {
 #ifdef RACCT
-   if (racct_enable) {
-   PROC_LOCK(td->td_proc);
-   racct_add_buf(td->td_proc, bp, 0);
-   PROC_UNLOCK(td->td_proc);
-   }
-#endif /* RACCT */
-   td->td_ru.ru_inblock++;
+   if (racct_enable) {
+   PROC_LOCK(td->td_proc);
+   racct_add_buf(td->td_proc, bp, 0);
+   PROC_UNLOCK(td->td_proc);
}
+#endif /* RACCT */
+   td->td_ru.ru_inblock++;
bp->b_iocmd = BIO_READ;
bp->b_flags &= ~B_INVAL;
if ((flags & GB_CKHASH) != 0) {
@@ -2258,16 +2257,14 @@ bufwrite(struct buf *bp)
bp->b_runningbufspace = bp->b_bufsize;
space = atomic_fetchadd_long(&runningbufspace, bp->b_runningbufspace);
 
-   if (!TD_IS_IDLETHREAD(curthread)) {
 #ifdef RACCT
-   if (racct_enable) {
-   PROC_LOCK(curproc);
-   racct_add_buf(curproc, bp, 1);
-   PROC_UNLOCK(curproc);
-   }
-#endif /* RACCT */
-   curthread->td_ru.ru_oublock++;
+   if (racct_enable) {
+   PROC_LOCK(curproc);
+   racct_add_buf(curproc, bp, 1);
+   PROC_UNLOCK(curproc);
}
+#endif /* RACCT */
+   curthread->td_ru.ru_oublock++;
if (oldflags & B_ASYNC)
BUF_KERNPROC(bp);
bp->b_iooffset = dbtob(bp->b_blkno);
@@ -4019,9 +4016,6 @@ loop:
 */
if (flags & GB_NOCREAT)
return (EEXIST);
-   if (bdomain[bo->bo_domain].bd_freebuffers == 0 &&
-   TD_IS_IDLETHREAD(curthread))
-   return (EBUSY);
 
bsize = vn_isdisk(vp, NULL) ? DEV_BSIZE : bo->bo_bsize;
KASSERT(bsize != 0, ("bsize == 0, check bo->bo_bsize"));
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r346598 - head/sys/modules

[Ed Maste]

On Tue, 23 Apr 2019 at 13:26, Rodney W. Grimes
 wrote:
>
> Very cool, now how do I get a PCIe slot into a RPI3!!! lol  :-)

I know you're joking but the comment does highlight an issue in the
AArch64 world - there's a lack of good mid-range developer platforms.
FreeBSD runs on Cavium/Marvell ThunderX and ThunderX2 and now on
Ampere eMAG with the WIP discussed in PR 237055. These platforms have
room for lots of memory, very high core/thread counts (32 to 256), and
a good complement of PCIe interfaces. The specs go far beyond those of
a typical desktop software development platform, and the price does
too. We also run on small embedded boards like the RPi, Pine64, etc.
just fine, but there's not much in the middle. What we really need is
something like a Mini-ITX form factor 4 to 8 core system that can take
8 to 32GB of RAM, has a PCIe slot or two, and is readily available
selling for well below $1000 US.

> I am hopeing some of that PCIe WIP might include some of the
> bits needed or do we already have PCIe slot on RockPro64 code that works?

I don't think this will do anything for RockPro64, it's just a
workaround for limitations in our current arm64 PCI code for some
functionality unused by ThunderX* but required for eMAG.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r346889 - head/lib/libvgl

[Bruce Evans]

Author: bde
Date: Mon Apr 29 14:13:53 2019
New Revision: 346889
URL: https://svnweb.freebsd.org/changeset/base/346889

Log:
  Refactor and simplify hiding the mouse cursor and fix bugs caused by
  complications in the previous methods.
  
  r346761 broke showing the mouse cursor after changing its state from
  off to on (including initially), since showing the cursor uses the
  state to decide whether to actually show and the state variable was
  not changed until after null showing.  Moving the mouse or copying
  under the cursor fixed the problem.  Fix this and similar problems for
  the on to off transition by changing the state variable before drawing
  the cursor.
  
  r346641 failed to turn off the mouse cursor on exit from vgl.  It hid
  the cursor only temporarily for clearing.  This doesn't change the state
  variable, so unhiding the cursor after clearing restored the cursor if its
  state was on.  Fix this by changing its state to VGL_MOUSEHIDE using the
  application API for changing the state.
  
  Remove the VGLMouseVisible state variable and the extra states given by it.
  This was an optimization that was just an obfuscation in at least the
  previous version.
  
  Staticize VGLMouseAction().  Remove VGLMousePointerShow/Hide() except as
  internals in __VGLMouseMode().  __VGLMouseMouseMode() is the same as the
  application API VGLMouseMouseMode() except it returns the previous mode
  which callers need to know to restore it after hiding the cursor.
  
  Use the refactoring to make minor improvements in a simpler way than was
  possible:
  - in VGLMouseAction(), only hide and and unhide the mouse cursor if the
mouse moved
  - in VGLClear(), only hide and and unhide the mouse cursor if the clearing
method would otherwise clear the cursor.

Modified:
  head/lib/libvgl/main.c
  head/lib/libvgl/mouse.c
  head/lib/libvgl/simple.c
  head/lib/libvgl/vgl.h

Modified: head/lib/libvgl/main.c
==
--- head/lib/libvgl/main.c  Mon Apr 29 13:23:32 2019(r346888)
+++ head/lib/libvgl/main.c  Mon Apr 29 14:13:53 2019(r346889)
@@ -77,7 +77,7 @@ struct vt_mode smode;
   signal(SIGUSR2, SIG_IGN);
   VGLSwitchPending = 0;
   VGLAbortPending = 0;
-  VGLMousePointerHide();
+  VGLMouseMode(VGL_MOUSEHIDE);
 
   if (VGLMem != MAP_FAILED) {
 VGLClear(VGLDisplay, 0);

Modified: head/lib/libvgl/mouse.c
==
--- head/lib/libvgl/mouse.c Mon Apr 29 13:23:32 2019(r346888)
+++ head/lib/libvgl/mouse.c Mon Apr 29 14:13:53 2019(r346889)
@@ -39,6 +39,8 @@ __FBSDID("$FreeBSD$");
 #include 
 #include "vgl.h"
 
+static void VGLMouseAction(int dummy);
+
 #define BORDER 0xff/* default border -- light white in rgb 3:3:2 */
 #define INTERIOR 0xa0  /* default interior -- red in rgb 3:3:2 */
 #define X  0xff/* any nonzero in And mask means part of cursor */
@@ -88,7 +90,6 @@ static VGLBitmap VGLMouseStdAndMask = 
 static VGLBitmap VGLMouseStdOrMask = 
 VGLBITMAP_INITIALIZER(MEMBUF, MOUSE_IMG_SIZE, MOUSE_IMG_SIZE, StdOrMask);
 static VGLBitmap *VGLMouseAndMask, *VGLMouseOrMask;
-static int VGLMouseVisible = 0;
 static int VGLMouseShown = VGL_MOUSEHIDE;
 static int VGLMouseXpos = 0;
 static int VGLMouseYpos = 0;
@@ -102,51 +103,44 @@ static volatile sig_atomic_t VGLMsuppressint;
VGLMouseAction(0);  \
} while (0)
 
-void
-VGLMousePointerShow()
+int
+__VGLMouseMode(int mode)
 {
-  if (!VGLMouseVisible) {
-INTOFF();
-VGLMouseVisible = 1;
-__VGLBitmapCopy(&VGLVDisplay, VGLMouseXpos, VGLMouseYpos, VGLDisplay, 
- VGLMouseXpos, VGLMouseYpos, MOUSE_IMG_SIZE, -MOUSE_IMG_SIZE);
-INTON();
-  }
-}
+  int oldmode;
 
-void
-VGLMousePointerHide()
-{
-  if (VGLMouseVisible) {
-INTOFF();
-VGLMouseVisible = 0;
-__VGLBitmapCopy(&VGLVDisplay, VGLMouseXpos, VGLMouseYpos, VGLDisplay, 
-VGLMouseXpos, VGLMouseYpos, MOUSE_IMG_SIZE, 
MOUSE_IMG_SIZE);
-INTON();
-  }
-}
-
-void
-VGLMouseMode(int mode)
-{
+  INTOFF();
+  oldmode = VGLMouseShown;
   if (mode == VGL_MOUSESHOW) {
 if (VGLMouseShown == VGL_MOUSEHIDE) {
-  VGLMousePointerShow();
   VGLMouseShown = VGL_MOUSESHOW;
+  __VGLBitmapCopy(&VGLVDisplay, VGLMouseXpos, VGLMouseYpos, VGLDisplay, 
+  VGLMouseXpos, VGLMouseYpos,
+  MOUSE_IMG_SIZE, -MOUSE_IMG_SIZE);
 }
   }
   else {
 if (VGLMouseShown == VGL_MOUSESHOW) {
-  VGLMousePointerHide();
   VGLMouseShown = VGL_MOUSEHIDE;
+  __VGLBitmapCopy(&VGLVDisplay, VGLMouseXpos, VGLMouseYpos, VGLDisplay, 
+  VGLMouseXpos, VGLMouseYpos,
+  MOUSE_IMG_SIZE, MOUSE_IMG_SIZE);
 }
   }
+  INTON();
+  return oldmode;
 }
 
 void
+VGLMouseMode(int mode)
+{
+  __VGLMouseMode(mode);
+}
+
+static void
 VGLM

Re: svn commit: r346598 - head/sys/modules

[Rodney W. Grimes]

> On Tue, 23 Apr 2019 at 13:26, Rodney W. Grimes
>  wrote:
> >
> > Very cool, now how do I get a PCIe slot into a RPI3!!! lol  :-)
> 
> I know you're joking but the comment does highlight an issue in the
> AArch64 world - there's a lack of good mid-range developer platforms.

I may of been joking with respect to the RPI3, but at the same
time I do know that the RockPro64 exists and does have that
PCIe slot I want, I also know that Michael Dexter has one he would
loan me should I wish to investigate our state of support.

> FreeBSD runs on Cavium/Marvell ThunderX and ThunderX2 and now on
> Ampere eMAG with the WIP discussed in PR 237055. These platforms have
> room for lots of memory, very high core/thread counts (32 to 256), and
> a good complement of PCIe interfaces. The specs go far beyond those of
> a typical desktop software development platform, and the price does
> too. We also run on small embedded boards like the RPi, Pine64, etc.
> just fine, but there's not much in the middle. What we really need is
> something like a Mini-ITX form factor 4 to 8 core system that can take
> 8 to 32GB of RAM, has a PCIe slot or two, and is readily available
> selling for well below $1000 US.
> 
> > I am hopeing some of that PCIe WIP might include some of the
> > bits needed or do we already have PCIe slot on RockPro64 code that works?
> 
> I don't think this will do anything for RockPro64, it's just a
> workaround for limitations in our current arm64 PCI code for some
> functionality unused by ThunderX* but required for eMAG.

Ok


-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r346598 - head/sys/modules

[Andrew Gallatin]

On 2019-04-29 10:21, Rodney W. Grimes wrote:

On Tue, 23 Apr 2019 at 13:26, Rodney W. Grimes
 wrote:


Very cool, now how do I get a PCIe slot into a RPI3!!! lol  :-)


I know you're joking but the comment does highlight an issue in the
AArch64 world - there's a lack of good mid-range developer platforms.


I may of been joking with respect to the RPI3, but at the same
time I do know that the RockPro64 exists and does have that
PCIe slot I want, I also know that Michael Dexter has one he would
loan me should I wish to investigate our state of support.


Does anybody know what PCIe Generation / speed that slot runs at?
All I can find them saying is "PCIe x4", which implies Gen 1, 2.5GT/s
speeds, which is not terribly useful.  Gen2 or better would be enough
to run 10GbE, which would be fun :)

Drew
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r346598 - head/sys/modules

[Emmanuel Vadot]

On Mon, 29 Apr 2019 10:49:01 -0400
Andrew Gallatin  wrote:

> On 2019-04-29 10:21, Rodney W. Grimes wrote:
> >> On Tue, 23 Apr 2019 at 13:26, Rodney W. Grimes
> >>  wrote:
> >>>
> >>> Very cool, now how do I get a PCIe slot into a RPI3!!! lol  :-)
> >>
> >> I know you're joking but the comment does highlight an issue in the
> >> AArch64 world - there's a lack of good mid-range developer platforms.
> > 
> > I may of been joking with respect to the RPI3, but at the same
> > time I do know that the RockPro64 exists and does have that
> > PCIe slot I want, I also know that Michael Dexter has one he would
> > loan me should I wish to investigate our state of support.
> 
> Does anybody know what PCIe Generation / speed that slot runs at?
> All I can find them saying is "PCIe x4", which implies Gen 1, 2.5GT/s
> speeds, which is not terribly useful.  Gen2 or better would be enough
> to run 10GbE, which would be fun :)
> 
> Drew

 It/s PCIe 2.1 compatible. See
http://rockchip.fr/Rockchip%20RK3399%20TRM%20V1.3%20Part2.pdf for more
info.

-- 
Emmanuel Vadot  
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r346598 - head/sys/modules

[Andrew Gallatin]

On 2019-04-29 10:54, Emmanuel Vadot wrote:

On Mon, 29 Apr 2019 10:49:01 -0400
Andrew Gallatin  wrote:


On 2019-04-29 10:21, Rodney W. Grimes wrote:

On Tue, 23 Apr 2019 at 13:26, Rodney W. Grimes
 wrote:


Very cool, now how do I get a PCIe slot into a RPI3!!! lol  :-)


I know you're joking but the comment does highlight an issue in the
AArch64 world - there's a lack of good mid-range developer platforms.


I may of been joking with respect to the RPI3, but at the same
time I do know that the RockPro64 exists and does have that
PCIe slot I want, I also know that Michael Dexter has one he would
loan me should I wish to investigate our state of support.


Does anybody know what PCIe Generation / speed that slot runs at?
All I can find them saying is "PCIe x4", which implies Gen 1, 2.5GT/s
speeds, which is not terribly useful.  Gen2 or better would be enough
to run 10GbE, which would be fun :)

Drew


  It/s PCIe 2.1 compatible. See
http://rockchip.fr/Rockchip%20RK3399%20TRM%20V1.3%20Part2.pdf



Everything I'm seeing there says Gen1 vs Gen2 depends on 
"PCIE_GENERATION_SEL", and that if its set to 0, you get

Gen1 2.5Gt/s and if it is set to 1, you get Gen2, 5.0Gt/s.
But I don't see anything specifying this value for the
RockPro64 board.

Drew
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r346598 - head/sys/modules

[Ganbold Tsagaankhuu]

On Mon, Apr 29, 2019 at 11:16 PM Andrew Gallatin 
wrote:

> On 2019-04-29 10:54, Emmanuel Vadot wrote:
> > On Mon, 29 Apr 2019 10:49:01 -0400
> > Andrew Gallatin  wrote:
> >
> >> On 2019-04-29 10:21, Rodney W. Grimes wrote:
>  On Tue, 23 Apr 2019 at 13:26, Rodney W. Grimes
>   wrote:
> >
> > Very cool, now how do I get a PCIe slot into a RPI3!!! lol  :-)
> 
>  I know you're joking but the comment does highlight an issue in the
>  AArch64 world - there's a lack of good mid-range developer platforms.
> >>>
> >>> I may of been joking with respect to the RPI3, but at the same
> >>> time I do know that the RockPro64 exists and does have that
> >>> PCIe slot I want, I also know that Michael Dexter has one he would
> >>> loan me should I wish to investigate our state of support.
> >>
> >> Does anybody know what PCIe Generation / speed that slot runs at?
> >> All I can find them saying is "PCIe x4", which implies Gen 1, 2.5GT/s
> >> speeds, which is not terribly useful.  Gen2 or better would be enough
> >> to run 10GbE, which would be fun :)
> >>
> >> Drew
> >
> >   It/s PCIe 2.1 compatible. See
> > http://rockchip.fr/Rockchip%20RK3399%20TRM%20V1.3%20Part2.pdf
> >
>
> Everything I'm seeing there says Gen1 vs Gen2 depends on
> "PCIE_GENERATION_SEL", and that if its set to 0, you get
> Gen1 2.5Gt/s and if it is set to 1, you get Gen2, 5.0Gt/s.
> But I don't see anything specifying this value for the
> RockPro64 board.
>

If you check Rockchip RK3399 TRM V1.3 Part1.pdf
 you can see
PCIe 2.1 in block diagram  (Fig 1-1)

Ganbold



>
> Drew
>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r346598 - head/sys/modules

[Greg V]

On Mon, Apr 29, 2019 at 10:08, Ed Maste  wrote:

On Tue, 23 Apr 2019 at 13:26, Rodney W. Grimes
 wrote:


 Very cool, now how do I get a PCIe slot into a RPI3!!! lol  :-)


I know you're joking but the comment does highlight an issue in the
AArch64 world - there's a lack of good mid-range developer platforms.
FreeBSD runs on Cavium/Marvell ThunderX and ThunderX2 and now on
Ampere eMAG with the WIP discussed in PR 237055. These platforms have
room for lots of memory, very high core/thread counts (32 to 256), and
a good complement of PCIe interfaces. The specs go far beyond those of
a typical desktop software development platform, and the price does
too. We also run on small embedded boards like the RPi, Pine64, etc.
just fine, but there's not much in the middle. What we really need is
something like a Mini-ITX form factor 4 to 8 core system that can take
8 to 32GB of RAM, has a PCIe slot or two, and is readily available
selling for well below $1000 US.


SolidRun/Marvell MACCHIATObin is probably the best option available 
now, but SolidRun is working on new stuff:


https://www.solid-run.com/nxp-lx2160a-family/clearfog-itx/

NXP LX2160A — SoC with 16 Cortex-A72 cores, dual-channel DDR4 (MCbin 
is single channel), 18 lanes of PCIe Gen 4, and as usual a huge 
built-in network card we don't have a driver for. Though NXP advertises 
that it's possible to reconfigure the SFP+ ports to turn them into more 
PCIe.


They even confirmed that overclocking is possible for both CPU and RAM:

https://www.phoronix.com/forums/forum/hardware/motherboards-chipsets/1090102-solidrun-clearfog-a-16-core-arm-itx-workstation-board-aiming-for-500~750-usd?p=1090905#post1090905

Let's hope they implement ACPI fully and correctly :)


 I am hopeing some of that PCIe WIP might include some of the
 bits needed or do we already have PCIe slot on RockPro64 code that 
works?


I don't think this will do anything for RockPro64, it's just a
workaround for limitations in our current arm64 PCI code for some
functionality unused by ThunderX* but required for eMAG.


RK3399 seems to need a custom driver, OpenBSD has one:

https://github.com/openbsd/src/blob/master/sys/dev/fdt/rkpcie.c

And I've heard bad things about the controller, apparently no one has 
got a GPU working on Linux because the controller doesn't support 
enough address space or some other features.



___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r346890 - head/lib/libvgl

[Bruce Evans]

Author: bde
Date: Mon Apr 29 15:58:05 2019
New Revision: 346890
URL: https://svnweb.freebsd.org/changeset/base/346890

Log:
  Oops, r346889 broke showing of the mouse cursor after clearing, by
  forgetting to tell the bitmap-copying clearing method to preserve the
  cursor.

Modified:
  head/lib/libvgl/simple.c

Modified: head/lib/libvgl/simple.c
==
--- head/lib/libvgl/simple.cMon Apr 29 14:13:53 2019(r346889)
+++ head/lib/libvgl/simple.cMon Apr 29 15:58:05 2019(r346890)
@@ -496,7 +496,7 @@ VGLClear(VGLBitmap *object, u_long color)
 for (i = 0; i < object->VXsize; i++)
   bcopy(&color, src.Bitmap + i * object->PixelBytes, object->PixelBytes);
 for (i = 0; i < object->VYsize; i++)
-  __VGLBitmapCopy(&src, 0, 0, object, 0, i, object->VXsize, 1);
+  __VGLBitmapCopy(&src, 0, 0, object, 0, i, object->VXsize, -1);
 break;
 
   case VIDBUF8X:
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r346896 - in head/sys/dev: altera/atse altera/softdma xdma

[Ruslan Bukin]

Author: br
Date: Mon Apr 29 16:27:15 2019
New Revision: 346896
URL: https://svnweb.freebsd.org/changeset/base/346896

Log:
  o Rewrite softdma_process_tx() of Altera SoftDMA engine driver
so it does not require a bounce buffer. The only need for this was
to align the buffer address. Implement unaligned access and we don't
need to copy data twice.
  o Remove contigmalloc-based bounce buffer from xDMA code since it is
not suitable for arbitrary memory provided by platform, which is
sometimes a dedicated piece of memory that is not managed by OS at all.
  
  Sponsored by: DARPA, AFRL

Modified:
  head/sys/dev/altera/atse/if_atse.c
  head/sys/dev/altera/softdma/softdma.c
  head/sys/dev/xdma/xdma.h
  head/sys/dev/xdma/xdma_mbuf.c
  head/sys/dev/xdma/xdma_sg.c

Modified: head/sys/dev/altera/atse/if_atse.c
==
--- head/sys/dev/altera/atse/if_atse.c  Mon Apr 29 16:26:29 2019
(r346895)
+++ head/sys/dev/altera/atse/if_atse.c  Mon Apr 29 16:27:15 2019
(r346896)
@@ -1290,7 +1290,7 @@ atse_attach(device_t dev)
 * Chapter 15. On-Chip FIFO Memory Core.
 * Embedded Peripherals IP User Guide.
 */
-   caps = XCHAN_CAP_BUSDMA_NOSEG;
+   caps = XCHAN_CAP_NOSEG;
 
/* Alloc xDMA virtual channel. */
sc->xchan_tx = xdma_channel_alloc(sc->xdma_tx, caps);
@@ -1456,6 +1456,11 @@ atse_detach(device_t dev)
}
 
mtx_destroy(&sc->atse_mtx);
+
+   xdma_channel_free(sc->xchan_tx);
+   xdma_channel_free(sc->xchan_rx);
+   xdma_put(sc->xdma_tx);
+   xdma_put(sc->xdma_rx);
 
return (0);
 }

Modified: head/sys/dev/altera/softdma/softdma.c
==
--- head/sys/dev/altera/softdma/softdma.c   Mon Apr 29 16:26:29 2019
(r346895)
+++ head/sys/dev/altera/softdma/softdma.c   Mon Apr 29 16:27:15 2019
(r346896)
@@ -190,6 +190,18 @@ softdma_fill_level(struct softdma_softc *sc)
return (val);
 }
 
+static uint32_t
+fifo_fill_level_wait(struct softdma_softc *sc)
+{
+   uint32_t val;
+
+   do
+   val = softdma_fill_level(sc);
+   while (val == AVALON_FIFO_TX_BASIC_OPTS_DEPTH);
+
+   return (val);
+}
+
 static void
 softdma_intr(void *arg)
 {
@@ -287,86 +299,96 @@ static int
 softdma_process_tx(struct softdma_channel *chan, struct softdma_desc *desc)
 {
struct softdma_softc *sc;
-   uint32_t src_offs, dst_offs;
+   uint64_t addr;
+   uint64_t buf;
+   uint32_t word;
+   uint32_t missing;
uint32_t reg;
-   uint32_t fill_level;
-   uint32_t leftm;
-   uint32_t tmp;
-   uint32_t val;
-   uint32_t c;
+   int got_bits;
+   int len;
 
sc = chan->sc;
 
-   fill_level = softdma_fill_level(sc);
-   while (fill_level == AVALON_FIFO_TX_BASIC_OPTS_DEPTH)
-   fill_level = softdma_fill_level(sc);
+   fifo_fill_level_wait(sc);
 
/* Set start of packet. */
-   if (desc->control & CONTROL_GEN_SOP) {
-   reg = 0;
-   reg |= A_ONCHIP_FIFO_MEM_CORE_SOP;
-   softdma_mem_write(sc, A_ONCHIP_FIFO_MEM_CORE_METADATA, reg);
-   }
+   if (desc->control & CONTROL_GEN_SOP)
+   softdma_mem_write(sc, A_ONCHIP_FIFO_MEM_CORE_METADATA,
+   A_ONCHIP_FIFO_MEM_CORE_SOP);
 
-   src_offs = dst_offs = 0;
-   c = 0;
-   while ((desc->len - c) >= 4) {
-   val = *(uint32_t *)(desc->src_addr + src_offs);
-   bus_write_4(sc->res[0], A_ONCHIP_FIFO_MEM_CORE_DATA, val);
-   if (desc->src_incr)
-   src_offs += 4;
-   if (desc->dst_incr)
-   dst_offs += 4;
-   fill_level += 1;
+   got_bits = 0;
+   buf = 0;
 
-   while (fill_level == AVALON_FIFO_TX_BASIC_OPTS_DEPTH) {
-   fill_level = softdma_fill_level(sc);
-   }
-   c += 4;
+   addr = desc->src_addr;
+   len = desc->len;
+
+   if (addr & 1) {
+   buf = (buf << 8) | *(uint8_t *)addr;
+   got_bits += 8;
+   addr += 1;
+   len -= 1;
}
 
-   val = 0;
-   leftm = (desc->len - c);
+   if (len >= 2 && addr & 2) {
+   buf = (buf << 16) | *(uint16_t *)addr;
+   got_bits += 16;
+   addr += 2;
+   len -= 2;
+   }
 
-   switch (leftm) {
-   case 1:
-   val = *(uint8_t *)(desc->src_addr + src_offs);
-   val <<= 24;
-   src_offs += 1;
-   break;
-   case 2:
-   case 3:
-   val = *(uint16_t *)(desc->src_addr + src_offs);
-   val <<= 16;
-   src_offs += 2;
+   while (len >= 4) {
+   buf = (buf << 32) | (uint64_t)*(uint32_t *)addr;
+   addr += 4;

svn commit: r346895 - head/lib/libvgl

[Bruce Evans]

Author: bde
Date: Mon Apr 29 16:26:29 2019
New Revision: 346895
URL: https://svnweb.freebsd.org/changeset/base/346895

Log:
  Support all reasonable cursor sizes.  Reduce the size of the standard
  cursor from 16x16 (with 6 columns unused) to 10x16 and rename it to
  the "small" cursor.  Add a "large" 19x32 cursor and use it for screen
  widths larger than 800 pixels.  Use libvgl's too-small indentation for
  the large data declarations.
  
  MOUSE_IMG_SIZE = 16 is still part of the API.  If an application supplies
  invalid bitmaps for the cursor, then the results may be different from
  before.

Modified:
  head/lib/libvgl/mouse.c

Modified: head/lib/libvgl/mouse.c
==
--- head/lib/libvgl/mouse.c Mon Apr 29 16:24:51 2019(r346894)
+++ head/lib/libvgl/mouse.c Mon Apr 29 16:26:29 2019(r346895)
@@ -43,52 +43,132 @@ static void VGLMouseAction(int dummy);
 
 #define BORDER 0xff/* default border -- light white in rgb 3:3:2 */
 #define INTERIOR 0xa0  /* default interior -- red in rgb 3:3:2 */
+#define LARGE_MOUSE_IMG_XSIZE  19
+#define LARGE_MOUSE_IMG_YSIZE  32
+#define SMALL_MOUSE_IMG_XSIZE  10
+#define SMALL_MOUSE_IMG_YSIZE  16
 #define X  0xff/* any nonzero in And mask means part of cursor */
 #define B  BORDER
 #define I  INTERIOR
-static byte StdAndMask[MOUSE_IMG_SIZE*MOUSE_IMG_SIZE] = {
-   X,X,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
-   X,X,X,0,0,0,0,0,0,0,0,0,0,0,0,0,
-   X,X,X,X,0,0,0,0,0,0,0,0,0,0,0,0,
-   X,X,X,X,X,0,0,0,0,0,0,0,0,0,0,0,
-   X,X,X,X,X,X,0,0,0,0,0,0,0,0,0,0,
-   X,X,X,X,X,X,X,0,0,0,0,0,0,0,0,0,
-   X,X,X,X,X,X,X,X,0,0,0,0,0,0,0,0,
-   X,X,X,X,X,X,X,X,X,0,0,0,0,0,0,0,
-   X,X,X,X,X,X,X,X,X,X,0,0,0,0,0,0,
-   X,X,X,X,X,X,X,X,X,X,0,0,0,0,0,0,
-   X,X,X,X,X,X,X,0,0,0,0,0,0,0,0,0,
-   X,X,X,0,X,X,X,X,0,0,0,0,0,0,0,0,
-   X,X,0,0,X,X,X,X,0,0,0,0,0,0,0,0,
-   0,0,0,0,0,X,X,X,X,0,0,0,0,0,0,0,
-   0,0,0,0,0,X,X,X,X,0,0,0,0,0,0,0,
-   0,0,0,0,0,0,X,X,0,0,0,0,0,0,0,0,
+static byte LargeAndMask[] = {
+  X,X,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+  X,X,X,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+  X,X,X,X,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+  X,X,X,X,X,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+  X,X,X,X,X,X,0,0,0,0,0,0,0,0,0,0,0,0,0,
+  X,X,X,X,X,X,X,0,0,0,0,0,0,0,0,0,0,0,0,
+  X,X,X,X,X,X,X,X,0,0,0,0,0,0,0,0,0,0,0,
+  X,X,X,X,X,X,X,X,X,0,0,0,0,0,0,0,0,0,0,
+  X,X,X,X,X,X,X,X,X,X,0,0,0,0,0,0,0,0,0,
+  X,X,X,X,X,X,X,X,X,X,X,0,0,0,0,0,0,0,0,
+  X,X,X,X,X,X,X,X,X,X,X,X,0,0,0,0,0,0,0,
+  X,X,X,X,X,X,X,X,X,X,X,X,X,0,0,0,0,0,0,
+  X,X,X,X,X,X,X,X,X,X,X,X,X,X,0,0,0,0,0,
+  X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,0,0,0,0,
+  X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,0,0,0,
+  X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,0,0,
+  X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,0,
+  X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,
+  X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,
+  X,X,X,X,X,X,X,X,X,X,X,X,0,0,0,0,0,0,0,
+  X,X,X,X,X,X,X,X,X,X,X,X,0,0,0,0,0,0,0,
+  X,X,X,X,X,X,0,X,X,X,X,X,X,0,0,0,0,0,0,
+  X,X,X,X,X,0,0,X,X,X,X,X,X,0,0,0,0,0,0,
+  X,X,X,X,0,0,0,0,X,X,X,X,X,X,0,0,0,0,0,
+  X,X,X,0,0,0,0,0,X,X,X,X,X,X,0,0,0,0,0,
+  X,X,0,0,0,0,0,0,0,X,X,X,X,X,X,0,0,0,0,
+  0,0,0,0,0,0,0,0,0,X,X,X,X,X,X,0,0,0,0,
+  0,0,0,0,0,0,0,0,0,0,X,X,X,X,X,X,0,0,0,
+  0,0,0,0,0,0,0,0,0,0,X,X,X,X,X,X,0,0,0,
+  0,0,0,0,0,0,0,0,0,0,0,X,X,X,X,X,X,0,0,
+  0,0,0,0,0,0,0,0,0,0,0,X,X,X,X,X,X,0,0,
+  0,0,0,0,0,0,0,0,0,0,0,0,X,X,X,X,0,0,0,
 };
-static byte StdOrMask[MOUSE_IMG_SIZE*MOUSE_IMG_SIZE] = {
-   B,B,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
-   B,I,B,0,0,0,0,0,0,0,0,0,0,0,0,0,
-   B,I,I,B,0,0,0,0,0,0,0,0,0,0,0,0,
-   B,I,I,I,B,0,0,0,0,0,0,0,0,0,0,0,
-   B,I,I,I,I,B,0,0,0,0,0,0,0,0,0,0,
-   B,I,I,I,I,I,B,0,0,0,0,0,0,0,0,0,
-   B,I,I,I,I,I,I,B,0,0,0,0,0,0,0,0,
-   B,I,I,I,I,I,I,I,B,0,0,0,0,0,0,0,
-   B,I,I,I,I,I,I,I,I,B,0,0,0,0,0,0,
-   B,I,I,I,I,I,B,B,B,B,0,0,0,0,0,0,
-   B,I,I,B,I,I,B,0,0,0,0,0,0,0,0,0,
-   B,I,B,0,B,I,I,B,0,0,0,0,0,0,0,0,
-   B,B,0,0,B,I,I,B,0,0,0,0,0,0,0,0,
-   0,0,0,0,0,B,I,I,B,0,0,0,0,0,0,0,
-   0,0,0,0,0,B,I,I,B,0,0,0,0,0,0,0,
-   0,0,0,0,0,0,B,B,0,0,0,0,0,0,0,0,
+static byte LargeOrMask[] = {
+  B,B,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+  B,I,B,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+  B,I,I,B,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+  B,I,I,I,B,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+  B,I,I,I,I,B,0,0,0,0,0,0,0,0,0,0,0,0,0,
+  B,I,I,I,I,I,B,0,0,0,0,0,0,0,0,0,0,0,0,
+  B,I,I,I,I,I,I,B,0,0,0,0,0,0,0,0,0,0,0,
+  B,I,I,I,I,I,I,I,B,0,0,0,0,0,0,0,0,0,0,
+  B,I,I,I,I,I,I,I,I,B,0,0,0,0,0,0,0,0,0,
+  B,I,I,I,I,I,I,I,I,I,B,0,0,0,0,0,0,0,0,
+  B,I,I,I,I,I,I,I,I,I,I,B,0,0,0,0,0,0,0,
+  B,I,I,I,I,I,I,I,I,I,I,I,B,0,0,0,0,0,0,
+  B,I,I,I,I,I,I,I,I,I,I,I,I,B,0,0,0,0,0,
+  B,I,I,I,I,I,I,I,I,I,I,I,I,I,B,0,0,0,0,
+  B,I,I,I,I,I,I,I,I,I,I,I,I,I,I,B,0,0,0,
+  B,I,I,I,I,I,I,I,I,I,I,I,I,I,I,I,B,0,0,
+  B,I,I,I,I,I,I,I,I,I,I,I,I,I,I,I,I,B,0,
+  B,I,I,I,I,I,I,I,I,I,I,I,I,I,I,I,I,I,B,
+  B,I,I,I,I,I,I,I,I,I,I,B,B,B,B,B,

svn commit: r346897 - in head/sys: conf powerpc/conf

[Leandro Lupori]

Author: luporl
Date: Mon Apr 29 16:50:33 2019
New Revision: 346897
URL: https://svnweb.freebsd.org/changeset/base/346897

Log:
  [PPC64] Turn opal_flash.c into a device
  
  This change makes it easier to enable/disable the inclusion of
  OPAL flash in the kernel.
  
  Reviewed by:  jhibbits
  Differential Revision:https://reviews.freebsd.org/D20098

Modified:
  head/sys/conf/files.powerpc
  head/sys/powerpc/conf/GENERIC64

Modified: head/sys/conf/files.powerpc
==
--- head/sys/conf/files.powerpc Mon Apr 29 16:27:15 2019(r346896)
+++ head/sys/conf/files.powerpc Mon Apr 29 16:50:33 2019(r346897)
@@ -191,7 +191,7 @@ powerpc/powernv/opal.c  optionalpowernv
 powerpc/powernv/opal_async.c   optionalpowernv
 powerpc/powernv/opal_console.c optionalpowernv
 powerpc/powernv/opal_dev.c optionalpowernv
-powerpc/powernv/opal_flash.c   optionalpowernv
+powerpc/powernv/opal_flash.c   optionalpowernv opalflash
 powerpc/powernv/opal_hmi.c optionalpowernv
 powerpc/powernv/opal_i2c.c optionaliicbus fdt powernv
 powerpc/powernv/opal_i2cm.coptionaliicbus fdt powernv

Modified: head/sys/powerpc/conf/GENERIC64
==
--- head/sys/powerpc/conf/GENERIC64 Mon Apr 29 16:27:15 2019
(r346896)
+++ head/sys/powerpc/conf/GENERIC64 Mon Apr 29 16:50:33 2019
(r346897)
@@ -236,6 +236,7 @@ device  powermac_nvram  # Open Firmware 
configuration N
 device smu # Apple System Management Unit
 device atibl   # ATI-based backlight driver for 
PowerBooks/iBooks
 device nvbl# nVidia-based backlight driver for 
PowerBooks/iBooks
+device opalflash   # PowerNV embedded flash memory
 
 # ADB support
 device adb
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r346898 - head/sys/netinet

[Alexander Motin]

Author: mav
Date: Mon Apr 29 18:09:55 2019
New Revision: 346898
URL: https://svnweb.freebsd.org/changeset/base/346898

Log:
  ip multicast debug: fix strings vs defines
  
  Turning on multicast debug made multicast failure worse
  because the strings and #define values no longer matched
  up.  Fix them, and make sure they stay matched-up.
  
  Submitted by: torek
  MFC after:1 week
  Sponsored by: iXsystems, Inc.

Modified:
  head/sys/netinet/in_mcast.c

Modified: head/sys/netinet/in_mcast.c
==
--- head/sys/netinet/in_mcast.c Mon Apr 29 16:50:33 2019(r346897)
+++ head/sys/netinet/in_mcast.c Mon Apr 29 18:09:55 2019(r346898)
@@ -3067,7 +3067,14 @@ sysctl_ip_mcast_filters(SYSCTL_HANDLER_ARGS)
 
 #if defined(KTR) && (KTR_COMPILE & KTR_IGMPV3)
 
-static const char *inm_modestrs[] = { "un", "in", "ex" };
+static const char *inm_modestrs[] = {
+   [MCAST_UNDEFINED] = "un",
+   [MCAST_INCLUDE] = "in",
+   [MCAST_EXCLUDE] = "ex",
+};
+_Static_assert(MCAST_UNDEFINED == 0 &&
+  MCAST_EXCLUDE + 1 == nitems(inm_modestrs),
+  "inm_modestrs: no longer matches #defines");
 
 static const char *
 inm_mode_str(const int mode)
@@ -3079,16 +3086,20 @@ inm_mode_str(const int mode)
 }
 
 static const char *inm_statestrs[] = {
-   "not-member",
-   "silent",
-   "idle",
-   "lazy",
-   "sleeping",
-   "awakening",
-   "query-pending",
-   "sg-query-pending",
-   "leaving"
+   [IGMP_NOT_MEMBER] = "not-member",
+   [IGMP_SILENT_MEMBER] = "silent",
+   [IGMP_REPORTING_MEMBER] = "reporting",
+   [IGMP_IDLE_MEMBER] = "idle",
+   [IGMP_LAZY_MEMBER] = "lazy",
+   [IGMP_SLEEPING_MEMBER] = "sleeping",
+   [IGMP_AWAKENING_MEMBER] = "awakening",
+   [IGMP_G_QUERY_PENDING_MEMBER] = "query-pending",
+   [IGMP_SG_QUERY_PENDING_MEMBER] = "sg-query-pending",
+   [IGMP_LEAVING_MEMBER] = "leaving",
 };
+_Static_assert(IGMP_NOT_MEMBER == 0 &&
+  IGMP_LEAVING_MEMBER + 1 == nitems(inm_statestrs),
+  "inm_statetrs: no longer matches #defines");
 
 static const char *
 inm_state_str(const int state)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r346899 - head

[Niclas Zeising]

Author: zeising (doc,ports committer)
Date: Mon Apr 29 18:20:51 2019
New Revision: 346899
URL: https://svnweb.freebsd.org/changeset/base/346899

Log:
  Add a note to MAINTAINERS for lkpi for graphics
  
  Add a note to MAINTAINERS requesting pre-commit review from the graphics
  team, using phabricator, for changes to the lkpi subsystem.  This is done in
  order to give us a chance to test the graphics drivers (drm drivers) for
  regressions, and to try to avoid breakage, errors and issues with the
  graphics drivers.
  The review is done via the #x11 group on phabricator.
  
  Please note that hselasky also want to review changes.
  
  Discussed with:   hselasky, imp
  Approved by:  imp

Modified:
  head/MAINTAINERS

Modified: head/MAINTAINERS
==
--- head/MAINTAINERSMon Apr 29 18:09:55 2019(r346898)
+++ head/MAINTAINERSMon Apr 29 18:20:51 2019(r346899)
@@ -90,6 +90,10 @@ share/mk/*.test.mk   freebsd-testing,ngie (same list as 
 stand/forthdteske  Pre-commit review requested.
 stand/lua  kevans  Pre-commit review requested
 sys/compat/linuxkpihselaskyIf in doubt, ask.
+   zeising, johalunpre-commit review requested via
+   #x11 phabricator group.
+   (to avoid drm graphics drivers
+   inpact)
 sys/contrib/ipfilter   cy  Pre-commit review requested.
 sys/dev/e1000  erj Pre-commit phabricator review requested.
 sys/dev/ixgbe  erj Pre-commit phabricator review requested.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r346904 - head

[Enji Cooper]

Author: ngie
Date: Mon Apr 29 18:48:43 2019
New Revision: 346904
URL: https://svnweb.freebsd.org/changeset/base/346904

Log:
  Update/reformat maintainer entries that I am a part of
  
  * Replace all instances of freebsd-testing with `#test`. `#test` is the
Phabricator group that focuses on test-related reviews.
  * Replace `atf` with contrib/atf, as that's the actual location for the test
framework.
  * Remove jmmv@ from the maintainers list for atf. He is the upstream project
owner, but was moved to alumni status after r345787.
  * Fix a typo accidentally introduced in r346899 (inpact -> impact).

Modified:
  head/MAINTAINERS

Modified: head/MAINTAINERS
==
--- head/MAINTAINERSMon Apr 29 18:37:39 2019(r346903)
+++ head/MAINTAINERSMon Apr 29 18:48:43 2019(r346904)
@@ -35,17 +35,19 @@ makes a commit to the specified subtree.
 
 subsystem  login   notes
 -
-atffreebsd-testing,jmmv,ngie   Pre-commit review 
requested.
 ath(4) adrian  Pre-commit review requested, send to 
freebsd-wirel...@freebsd.org
+contrib/atfngie,#test  Pre-commit review requested.
+contrib/capsicum-test  ngie,#capsicum,#testPre-commit review requested.
 contrib/compiler-rtdim Pre-commit review preferred.
+contrib/googletest ngie,#test  Pre-commit review requested.
 contrib/ipfilter   cy  Pre-commit review requested.
 contrib/libc++ dim Pre-commit review preferred.
 contrib/libcxxrt   dim Pre-commit review preferred.
 contrib/libunwind  dim,emaste,jhb  Pre-commit review preferred.
 contrib/llvm   dim Pre-commit review preferred.
 contrib/llvm/tools/lldbdim,emaste  Pre-commit review preferred.
-contrib/netbsd-tests   freebsd-testing,ngiePre-commit review requested.
-contrib/pjdfstest  freebsd-testing,asomers,ngie,pjdPre-commit 
review requested.
+contrib/netbsd-tests   ngie,#test  Pre-commit review requested.
+contrib/pjdfstest  asomers,ngie,pjd,#test  Pre-commit review requested.
 *env(3)secteam Due to the problematic security history of this
code, please have patches reviewed by secteam.
 etc/mail   gshapiroPre-commit review requested.  Keep in sync with 
-STABLE.
@@ -86,14 +88,15 @@ sh(1)   jilles  Pre-commit review 
requested. This also 
to kill(1), printf(1) and test(1) which are
compiled in as builtins.
 share/mk   imp, bapt, bdrewery, emaste, sjgMake is hard.
-share/mk/*.test.mk freebsd-testing,ngie (same list as share/mk too)
Pre-commit review requested.
+share/mk/*.test.mk imp,bapt,bdrewery,  Pre-commit review requested.
+   emaste,ngie,sjg,#test
 stand/forthdteske  Pre-commit review requested.
 stand/lua  kevans  Pre-commit review requested
-sys/compat/linuxkpihselaskyIf in doubt, ask.
+sys/compat/linuxkpihselaskyIf in doubt, ask.
zeising, johalunpre-commit review requested via
#x11 phabricator group.
(to avoid drm graphics drivers
-   inpact)
+   impact)
 sys/contrib/ipfilter   cy  Pre-commit review requested.
 sys/dev/e1000  erj Pre-commit phabricator review requested.
 sys/dev/ixgbe  erj Pre-commit phabricator review requested.
@@ -105,7 +108,7 @@ sys/netinet/ip_carp.c   glebius Pre-commit review recomm
 sys/netpfil/pf kp,glebius  Pre-commit review recommended.
 sys/x86/xenroyger  Pre-commit review recommended.
 sys/xenroyger  Pre-commit review recommended.
-tests  freebsd-testing,ngiePre-commit review requested.
+tests  ngie,#test  Pre-commit review requested.
 tools/buildimp Pre-commit review requested, especially to fix 
bootstrap issues.
 top(1) eadler  Pre-commit review requested.
 usr.sbin/bsdconfig dteske  Pre-commit phabricator review requested.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r346904 - head

[Enji Cooper]

> On Apr 29, 2019, at 11:48 AM, Enji Cooper  wrote:
> 
> Author: ngie
> Date: Mon Apr 29 18:48:43 2019
> New Revision: 346904
> URL: https://svnweb.freebsd.org/changeset/base/346904
> 
> Log:
>  Update/reformat maintainer entries that I am a part of
> 
>  * Replace all instances of freebsd-testing with `#test`. `#test` is the
>Phabricator group that focuses on test-related reviews.
>  * Replace `atf` with contrib/atf, as that's the actual location for the test
>framework.
>  * Remove jmmv@ from the maintainers list for atf. He is the upstream project
>owner, but was moved to alumni status after r345787.
>  * Fix a typo accidentally introduced in r346899 (inpact -> impact).

I failed to mention:
* Add pre-commit maintainer entries for contrib/capsicum-test and 
contrib/googletest .
Cheers,
-Enji
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r341586 - head/sys/dev/mlx5/mlx5_en

[John Baldwin]

On 4/25/19 12:10 AM, Slava Shwartsman wrote:
> 
> 
> On 17-Apr-19 00:28, John Baldwin wrote:
>> On 4/16/19 8:32 AM, Hans Petter Selasky wrote:
>>> On 4/16/19 4:39 PM, Andrey V. Elsukov wrote:
 On 05.12.2018 17:25, Slava Shwartsman wrote:
> Author: slavash
> Date: Wed Dec  5 14:25:03 2018
> New Revision: 341586
> URL: https://svnweb.freebsd.org/changeset/base/341586
>
> Log:
> mlx5en: Implement backpressure indication.
> 
> The backpressure indication is implemented using an unlimited rate 
> type of
> mbuf send tag. When the upper layers typically the socket layer has 
> obtained such
> a tag, it can then query the destination driver queue for the current
> amount of space available in the send queue.
> 
> A single mbuf send tag may be referenced multiple times and a 
> refcount has been added
> to the mlx5e_priv structure to track its usage. Because the send tag 
> resides
> in the mlx5e_channel structure, there is no need to wait for 
> refcounts to reach
> zero until the mlx4en(4) driver is detached. The channels structure 
> is persistant
> during the lifetime of the mlx5en(4) driver it belongs to and can so 
> be accessed
> without any need of synchronization.
> 
> The mlx5e_snd_tag structure was extended to contain a type field, 
> because there are now
> two different tag types which end up in the driver which need to be 
> distinguished.
> 
> Submitted by:   hselasky@
> Approved by:hselasky (mentor)
> MFC after:  1 week
> Sponsored by:   Mellanox Technologies
> @@ -587,27 +609,33 @@ mlx5e_xmit(struct ifnet *ifp, struct mbuf *mb)
>   struct mlx5e_sq *sq;
>   int ret;
>
> - sq = mlx5e_select_queue(ifp, mb);
> - if (unlikely(sq == NULL)) {
> -#ifdef RATELIMIT
> - /* Check for route change */
> - if (mb->m_pkthdr.snd_tag != NULL &&
> - mb->m_pkthdr.snd_tag->ifp != ifp) {
> + if (mb->m_pkthdr.snd_tag != NULL) {
> + sq = mlx5e_select_queue_by_send_tag(ifp, mb);
> + if (unlikely(sq == NULL)) {
> + /* Check for route change */
> + if (mb->m_pkthdr.snd_tag->ifp != ifp) {
> + /* Free mbuf */
> + m_freem(mb);
> +
> + /*
> +  * Tell upper layers about route
> +  * change and to re-transmit this
> +  * packet:
> +  */
> + return (EAGAIN);
> + }

 Hi,

 I just discovered something strange and found that this commit is the
 cause.
 The test system has mlx5en 100G interface. It has two vlans: vlan500 and
 vlan100.
 Via vlan500 it receives some packets flows. Then it routes these packets
 into vlan100.
 But packets are dropped in mlx5e_xmit() with EAGAIN error code.

 # dtrace -n 'fbt::ip6_output:return {printf("%d", arg1);}'
 dtrace: description 'fbt::ip6_output:return ' matched 1 probe
 CPU IDFUNCTION:NAME
23  54338ip6_output:return 35
16  54338ip6_output:return 35
21  54338ip6_output:return 35
22  54338ip6_output:return 35
24  54338ip6_output:return 35
23  54338ip6_output:return 35
14  54338ip6_output:return 35
 ^C

 # dtrace -n 'fbt::mlx5e_xmit:return {printf("%d", arg1);}'
 dtrace: description 'fbt::mlx5e_xmit:return ' matched 1 probe
 CPU IDFUNCTION:NAME
16  69030mlx5e_xmit:return 35
23  69030mlx5e_xmit:return 35
26  69030mlx5e_xmit:return 35
25  69030mlx5e_xmit:return 35
24  69030mlx5e_xmit:return 35
21  69030mlx5e_xmit:return 35
26  69030mlx5e_xmit:return 35
 ^C

 The kernel config is GENERIC.
 13.0-CURRENT #9 r345758+82f3d57(svn_head)-dirty

>>>
>>> Hi,
>>>
>>> This might be a case where rcvif in the mbuf's pktheader is not cleared
>>> before the packet is fed back on the wire.
>>>
>>> John Baldwin is working on the send tags implementation, to eliminate
>>> the EAGAIN handling in the network drivers.
>>
>> I will try to push this branch sooner then since it affects more than just
>> TLS.  Part of the change includes a new flag we can use to assert that we
> Thanks John!
>> aren't just getting a stale rcvif (though there are also now assertions in
>> ip_output that should catch this case I think).
>>
> 

svn commit: r346931 - head/share/man/man4

[John Baldwin]

Author: jhb
Date: Mon Apr 29 22:00:45 2019
New Revision: 346931
URL: https://svnweb.freebsd.org/changeset/base/346931

Log:
  Note that ccr(4) now supports AES-CCM.

Modified:
  head/share/man/man4/ccr.4

Modified: head/share/man/man4/ccr.4
==
--- head/share/man/man4/ccr.4   Mon Apr 29 21:55:39 2019(r346930)
+++ head/share/man/man4/ccr.4   Mon Apr 29 22:00:45 2019(r346931)
@@ -24,7 +24,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd March 11, 2019
+.Dd April 29, 2019
 .Dt CCR 4
 .Os
 .Sh NAME
@@ -34,7 +34,7 @@
 To compile this driver into the kernel,
 place the following lines in your
 kernel configuration file:
-.Bd -ragged -offset indeunt
+.Bd -ragged -offset indent
 .Cd "device ccr"
 .Ed
 .Pp
@@ -49,7 +49,7 @@ The
 .Nm
 driver provides support for the crypto accelerator engine included on
 PCI Express Ethernet adapters based on the Chelsio Terminator 6 ASIC (T6).
-The driver accelerates AES-CBC, AES-CTR, AES-GCM, AES-XTS, SHA1, SHA2-224,
+The driver accelerates AES-CBC, AES-CCM, AES-CTR, AES-GCM, AES-XTS, SHA1, 
SHA2-224,
 SHA2-256, SHA2-384, SHA2-512, SHA1-HMAC, SHA2-224-HMAC,
 SHA2-256-HMAC, SHA2-384-HMAC, and SHA2-512-HMAC operations for
 .Xr crypto 4
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r346931 - head/share/man/man4

[Enji Cooper]

> On Apr 29, 2019, at 15:00, John Baldwin  wrote:
> 
> Author: jhb
> Date: Mon Apr 29 22:00:45 2019
> New Revision: 346931
> URL: https://svnweb.freebsd.org/changeset/base/346931
> 
> Log:
>  Note that ccr(4) now supports AES-CCM.

Hi John,
Should this change be MFCed (including, just maybe the typo you fixed in 
the mdoc)?
Thank you :)!
-Enji
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r346932 - head/sys/ufs/ufs

[Mark Johnston]

Author: markj
Date: Mon Apr 29 22:05:26 2019
New Revision: 346932
URL: https://svnweb.freebsd.org/changeset/base/346932

Log:
  Optimize lseek(SEEK_DATA) on UFS.
  
  This version fixes the problems identified in r345244.
  
  Reviewed by:  kib
  MFC after:1 month
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D19598

Modified:
  head/sys/ufs/ufs/ufs_bmap.c
  head/sys/ufs/ufs/ufs_extern.h
  head/sys/ufs/ufs/ufs_vnops.c

Modified: head/sys/ufs/ufs/ufs_bmap.c
==
--- head/sys/ufs/ufs/ufs_bmap.c Mon Apr 29 22:00:45 2019(r346931)
+++ head/sys/ufs/ufs/ufs_bmap.c Mon Apr 29 22:05:26 2019(r346932)
@@ -56,6 +56,9 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
+static ufs_lbn_t lbn_count(struct ufsmount *, int);
+static int readindir(struct vnode *, ufs_lbn_t, ufs2_daddr_t, struct buf **);
+
 /*
  * Bmap converts the logical block number of a file to its physical block
  * number on the disk. The conversion is done by using the logical block
@@ -90,6 +93,51 @@ ufs_bmap(ap)
return (error);
 }
 
+static int
+readindir(vp, lbn, daddr, bpp)
+   struct vnode *vp;
+   ufs_lbn_t lbn;
+   ufs2_daddr_t daddr;
+   struct buf **bpp;
+{
+   struct buf *bp;
+   struct mount *mp;
+   struct ufsmount *ump;
+   int error;
+
+   mp = vp->v_mount;
+   ump = VFSTOUFS(mp);
+
+   bp = getblk(vp, lbn, mp->mnt_stat.f_iosize, 0, 0, 0);
+   if ((bp->b_flags & B_CACHE) == 0) {
+   KASSERT(daddr != 0,
+   ("readindir: indirect block not in cache"));
+
+   bp->b_blkno = blkptrtodb(ump, daddr);
+   bp->b_iocmd = BIO_READ;
+   bp->b_flags &= ~B_INVAL;
+   bp->b_ioflags &= ~BIO_ERROR;
+   vfs_busy_pages(bp, 0);
+   bp->b_iooffset = dbtob(bp->b_blkno);
+   bstrategy(bp);
+#ifdef RACCT
+   if (racct_enable) {
+   PROC_LOCK(curproc);
+   racct_add_buf(curproc, bp, 0);
+   PROC_UNLOCK(curproc);
+   }
+#endif
+   curthread->td_ru.ru_inblock++;
+   error = bufwait(bp);
+   if (error != 0) {
+   brelse(bp);
+   return (error);
+   }
+   }
+   *bpp = bp;
+   return (0);
+}
+
 /*
  * Indirect blocks are now on the vnode for the file.  They are given negative
  * logical block numbers.  Indirect blocks are addressed by the negative
@@ -212,35 +260,10 @@ ufs_bmaparray(vp, bn, bnp, nbp, runp, runb)
 */
if (bp)
bqrelse(bp);
+   error = readindir(vp, metalbn, daddr, &bp);
+   if (error != 0)
+   return (error);
 
-   bp = getblk(vp, metalbn, mp->mnt_stat.f_iosize, 0, 0, 0);
-   if ((bp->b_flags & B_CACHE) == 0) {
-#ifdef INVARIANTS
-   if (!daddr)
-   panic("ufs_bmaparray: indirect block not in 
cache");
-#endif
-   bp->b_blkno = blkptrtodb(ump, daddr);
-   bp->b_iocmd = BIO_READ;
-   bp->b_flags &= ~B_INVAL;
-   bp->b_ioflags &= ~BIO_ERROR;
-   vfs_busy_pages(bp, 0);
-   bp->b_iooffset = dbtob(bp->b_blkno);
-   bstrategy(bp);
-#ifdef RACCT
-   if (racct_enable) {
-   PROC_LOCK(curproc);
-   racct_add_buf(curproc, bp, 0);
-   PROC_UNLOCK(curproc);
-   }
-#endif /* RACCT */
-   curthread->td_ru.ru_inblock++;
-   error = bufwait(bp);
-   if (error) {
-   brelse(bp);
-   return (error);
-   }
-   }
-
if (I_IS_UFS1(ip)) {
daddr = ((ufs1_daddr_t *)bp->b_data)[ap->in_off];
if (num == 1 && daddr && runp) {
@@ -301,6 +324,111 @@ ufs_bmaparray(vp, bn, bnp, nbp, runp, runb)
*bnp = -1;
}
return (0);
+}
+
+static ufs_lbn_t
+lbn_count(ump, level)
+   struct ufsmount *ump;
+   int level;
+{
+   ufs_lbn_t blockcnt;
+
+   for (blockcnt = 1; level > 0; level--)
+   blockcnt *= MNINDIR(ump);
+   return (blockcnt);
+}
+
+int
+ufs_bmap_seekdata(vp, offp)
+   struct vnode *vp;
+   off_t *offp;
+{
+   struct buf *bp;
+   struct indir a[UFS_NIADDR + 1], *ap;
+   struct inode *ip;
+   struct mount *mp;
+   struct ufsmount *ump;
+   ufs2_daddr_t bn, daddr, nextbn;
+   uint64_t bsize;
+   off_t numblks;
+   int error, num, num1, off;
+
+  

Re: svn commit: r346931 - head/share/man/man4

[John Baldwin]

On 4/29/19 3:04 PM, Enji Cooper wrote:
> 
>> On Apr 29, 2019, at 15:00, John Baldwin  wrote:
>>
>> Author: jhb
>> Date: Mon Apr 29 22:00:45 2019
>> New Revision: 346931
>> URL: https://svnweb.freebsd.org/changeset/base/346931
>>
>> Log:
>>  Note that ccr(4) now supports AES-CCM.
> 
> Hi John,
> Should this change be MFCed (including, just maybe the typo you fixed in 
> the mdoc)?
> Thank you :)!

Only when AES-CCM support is merged.

-- 
John Baldwin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r346933 - head/share/man/man4

[John Baldwin]

Author: jhb
Date: Mon Apr 29 22:15:51 2019
New Revision: 346933
URL: https://svnweb.freebsd.org/changeset/base/346933

Log:
  Rewrap some long lines.
  
  Whitespace only change.

Modified:
  head/share/man/man4/ccr.4

Modified: head/share/man/man4/ccr.4
==
--- head/share/man/man4/ccr.4   Mon Apr 29 22:05:26 2019(r346932)
+++ head/share/man/man4/ccr.4   Mon Apr 29 22:15:51 2019(r346933)
@@ -49,9 +49,10 @@ The
 .Nm
 driver provides support for the crypto accelerator engine included on
 PCI Express Ethernet adapters based on the Chelsio Terminator 6 ASIC (T6).
-The driver accelerates AES-CBC, AES-CCM, AES-CTR, AES-GCM, AES-XTS, SHA1, 
SHA2-224,
-SHA2-256, SHA2-384, SHA2-512, SHA1-HMAC, SHA2-224-HMAC,
-SHA2-256-HMAC, SHA2-384-HMAC, and SHA2-512-HMAC operations for
+The driver accelerates AES-CBC, AES-CCM, AES-CTR, AES-GCM, AES-XTS,
+SHA1, SHA2-224, SHA2-256, SHA2-384, SHA2-512,
+SHA1-HMAC, SHA2-224-HMAC, SHA2-256-HMAC, SHA2-384-HMAC, and SHA2-512-HMAC
+operations for
 .Xr crypto 4
 and
 .Xr ipsec 4 .
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r346935 - head/sys/powerpc/powerpc

[Justin Hibbits]

Author: jhibbits
Date: Mon Apr 29 22:37:35 2019
New Revision: 346935
URL: https://svnweb.freebsd.org/changeset/base/346935

Log:
  powerpc64: Fix switch panic from cpu_throw()
  
  r18 is used to hold the old PCB flags, but cpu_throw doesn't populate r18
  with PCB flags, since the old thread is gone.  This can lead to panics on
  cores that don't have the registers guarded by these flags.

Modified:
  head/sys/powerpc/powerpc/swtch64.S

Modified: head/sys/powerpc/powerpc/swtch64.S
==
--- head/sys/powerpc/powerpc/swtch64.S  Mon Apr 29 22:16:33 2019
(r346934)
+++ head/sys/powerpc/powerpc/swtch64.S  Mon Apr 29 22:37:35 2019
(r346935)
@@ -78,6 +78,7 @@ TOC_ENTRY(blocked_lock)
 ENTRY(cpu_throw)
mr  %r13, %r4
li  %r14,0  /* Tell cpu_switchin not to release a thread */
+   li  %r18,0  /* No old pcb flags.  The old thread is extinguished. */
 
b   cpu_switchin
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r346941 - head/sys/powerpc/booke

[Justin Hibbits]

Author: jhibbits
Date: Tue Apr 30 03:45:46 2019
New Revision: 346941
URL: https://svnweb.freebsd.org/changeset/base/346941

Log:
  powerpc: Stop pretending we run on e500v1 cores
  
  Unconditional writing to MAS7, which doesn't exist on the e500v1 core, in a
  TLB miss handler has been in the code for several years now.  Since this has
  gone unnoticed for so long, it's easily concluded that e500v1 is not in use
  with FreeBSD.  Simplify the code path a bit, by unconditionally zeroing MAS7
  instead of calling a subroutine to do it.

Modified:
  head/sys/powerpc/booke/locore.S
  head/sys/powerpc/booke/trap_subr.S

Modified: head/sys/powerpc/booke/locore.S
==
--- head/sys/powerpc/booke/locore.S Tue Apr 30 01:25:02 2019
(r346940)
+++ head/sys/powerpc/booke/locore.S Tue Apr 30 03:45:46 2019
(r346941)
@@ -250,7 +250,8 @@ __start:
ori %r4, %r4, (MAS3_SX | MAS3_SW | MAS3_SR)@l
mtspr   SPR_MAS3, %r4   /* Set RPN and protection */
isync
-   bl  zero_mas7
+   li  %r4, 0
+   mtspr   SPR_MAS7, %r4
bl  zero_mas8
isync
tlbwe
@@ -505,7 +506,8 @@ bp_kernload:
ori %r3, %r3, (MAS3_SX | MAS3_SW | MAS3_SR)@l
mtspr   SPR_MAS3, %r3
isync
-   bl  zero_mas7
+   li  %r4, 0
+   mtspr   SPR_MAS7, %r4
bl  zero_mas8
isync
tlbwe
@@ -696,7 +698,8 @@ tlb1_temp_mapping_as1:
mtspr   SPR_MAS1, %r5
isync
mflr%r3
-   bl  zero_mas7
+   li  %r4, 0
+   mtspr   SPR_MAS7, %r4
bl  zero_mas8
mtlr%r3
isync
@@ -736,20 +739,8 @@ tlb1_inval_all_but_current:
blr
 
 /*
- * MAS7 and MAS8 conditional zeroing.
+ * MAS8 conditional zeroing.
  */
-.globl zero_mas7
-zero_mas7:
-   mfpvr   %r20
-   rlwinm  %r20, %r20, 16, 16, 31
-   cmpli   0, 0, %r20, FSL_E500v1
-   beq 1f
-
-   li  %r20, 0
-   mtspr   SPR_MAS7, %r20
-1:
-   blr
-
 .globl zero_mas8
 zero_mas8:
mfpvr   %r20

Modified: head/sys/powerpc/booke/trap_subr.S
==
--- head/sys/powerpc/booke/trap_subr.S  Tue Apr 30 01:25:02 2019
(r346940)
+++ head/sys/powerpc/booke/trap_subr.S  Tue Apr 30 03:45:46 2019
(r346941)
@@ -765,7 +765,8 @@ search_failed:
mtspr   SPR_MAS2, %r27
mtspr   SPR_MAS3, %r23
 
-   bl  zero_mas7
+   li  %r23, 0
+   mtspr   SPR_MAS7, %r23
bl  zero_mas8
 
isync
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r346932 - head/sys/ufs/ufs

[Alexey Dokuchaev]

On Mon, Apr 29, 2019 at 10:05:26PM +, Mark Johnston wrote:
> New Revision: 346932
> URL: https://svnweb.freebsd.org/changeset/base/346932
> 
> Log:
>   Optimize lseek(SEEK_DATA) on UFS.
>   
>   This version fixes the problems identified in r345244.
>   
>   Reviewed by:kib
> @@ -56,6 +56,9 @@ __FBSDID("$FreeBSD$");
>  #include 
>  #include 
>  
> +static ufs_lbn_t lbn_count(struct ufsmount *, int);
> +static int readindir(struct vnode *, ufs_lbn_t, ufs2_daddr_t, struct buf **);

Is the prototype for static readindir() really needed here?

> +static int
> +readindir(vp, lbn, daddr, bpp)
> + struct vnode *vp;
> + ufs_lbn_t lbn;
> + ufs2_daddr_t daddr;
> + struct buf **bpp;

Don't we prefer ASNI declarations over K&R these days?

> +static ufs_lbn_t
> +lbn_count(ump, level)
> + struct ufsmount *ump;
> + int level;

Ditto.

> +int
> +ufs_bmap_seekdata(vp, offp)
> + struct vnode *vp;
> + off_t *offp;

./danfe
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r341586 - head/sys/dev/mlx5/mlx5_en

[Andrey V. Elsukov]

On 30.04.2019 00:14, John Baldwin wrote:
>> Yes, we were able to reproduce this issue in house. If you don't mind, I 
>> prefer to wait for John's update - where he eliminates the EAGAIN 
>> handling in the network drivers.
> 
> I have rebased the branch for this, but for now it will just panic sooner
> I believe by tripping an assertion.  Can you grab the diff (or just the 
> branch)
> from the 'send_tags' branch at github/bsdjhb/freebsd and reproduce under a
> kernel with INVARIANTS?  I think we will have to explicitly clear the 'rcvif'
> pointer somewhere, but I want to see what the stack trace looks like so I can
> think about the "right" place to clear it.

Hi,

please note, that rcvif is used by firewall to track inbound interface
and clearing it can be unexpected in some cases, and can break firewall
rules.

-- 
WBR, Andrey V. Elsukov
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"