Re: svn commit: r352558 - head/usr.bin/top

2020-07-10 Thread Mark Millard
On 2020-Jul-10, at 16:12, Yuri Pankov wrote: > Mark Millard wrote: >> On 2020-Jul-10, at 11:05, Yuri Pankov wrote: >>> Steve Wills wrote: On 11/28/19 4:08 PM, Mark Millard via svn-src-head wrote: >> Author: daichi >> Date: Fri Sep 20 17:37:23 2019 >> New Revision: 352558

Re: svn commit: r352558 - head/usr.bin/top

2020-07-10 Thread Mark Millard
On 2020-Jul-10, at 15:25, Mark Millard wrote: > On 2020-Jul-10, at 11:05, Yuri Pankov wrote: > >> Steve Wills wrote: >>> On 11/28/19 4:08 PM, Mark Millard via svn-src-head wrote: > Author: daichi > Date: Fri Sep 20 17:37:23 2019 > New Revision: 352558 > URL: >

Re: svn commit: r352558 - head/usr.bin/top

2020-07-10 Thread Mark Millard
On 2020-Jul-10, at 11:05, Yuri Pankov wrote: > Steve Wills wrote: >> On 11/28/19 4:08 PM, Mark Millard via svn-src-head wrote: Author: daichi Date: Fri Sep 20 17:37:23 2019 New Revision: 352558 URL: https://svnweb.freebsd.org/changeset/base/352558

Re: svn commit: r352558 - head/usr.bin/top

2020-07-10 Thread Yuri Pankov
Mark Millard wrote: On 2020-Jul-10, at 16:12, Yuri Pankov wrote: Mark Millard wrote: On 2020-Jul-10, at 11:05, Yuri Pankov wrote: Steve Wills wrote: On 11/28/19 4:08 PM, Mark Millard via svn-src-head wrote: Author: daichi Date: Fri Sep 20 17:37:23 2019 New Revision: 352558 URL:

Re: svn commit: r352558 - head/usr.bin/top

2020-07-10 Thread Yuri Pankov
Mark Millard wrote: On 2020-Jul-10, at 11:05, Yuri Pankov wrote: Steve Wills wrote: On 11/28/19 4:08 PM, Mark Millard via svn-src-head wrote: Author: daichi Date: Fri Sep 20 17:37:23 2019 New Revision: 352558 URL: https://svnweb.freebsd.org/changeset/base/352558 Log: top(1): support

Re: -CURRENT and drm-devel-kmod

2020-07-10 Thread Emmanuel Vadot
On Fri, 10 Jul 2020 23:57:52 +0200 Andreas Nilsson wrote: > Hello, > > I've been running -CURRENT on my x1 yoga 1st gen for a long time, with > drm-current-kmod. As I understand it that port is no longer recommended and > one should run drm-devel-kmod . I don't think that somebody ever said

-CURRENT and drm-devel-kmod

2020-07-10 Thread Andreas Nilsson
Hello, I've been running -CURRENT on my x1 yoga 1st gen for a long time, with drm-current-kmod. As I understand it that port is no longer recommended and one should run drm-devel-kmod . However, when I load i915kms from -devel the console stops refreshing. It only refreshes when I switch

Re: DRM Project report (week of July 6th)

2020-07-10 Thread Emmanuel Vadot
On Sat, 11 Jul 2020 00:41:53 +0300 Yuri Pankov wrote: > Emmanuel Vadot wrote: > [...] > > Hi Emmanuel, > > Sorry for somewhat hijacking the thread, but as you mentioned (IIRC) > testing the vmwgfx in one of the previous mails, I'd like to ask if any > work/fixes is done for that. Currently

Re: DRM Project report (week of July 6th)

2020-07-10 Thread Yuri Pankov
Emmanuel Vadot wrote: [...] Hi Emmanuel, Sorry for somewhat hijacking the thread, but as you mentioned (IIRC) testing the vmwgfx in one of the previous mails, I'd like to ask if any work/fixes is done for that. Currently I don't have a VM with X11 installed as all my attempts didn't succeed

DRM Project report (week of July 6th)

2020-07-10 Thread Emmanuel Vadot
Hello, Last report was more than a month ago so a lot have happened. 5.3 is done and is in the ports tree since June 30th. This bring us support for NAVI10 card in the kernel, but if you have this card you will need mesa-devel port or wait that we update the mesa* port to 20.1 when they

Re: CFT for vendor openzfs

2020-07-10 Thread Evilham
Hey, thank you for this. On dc., jul. 08 2020, Matthew Macy wrote: Checkout updated HEAD: % git clone https://github.com/mattmacy/networking.git -b projects/openzfs_vendor freebsd Checkout updated openzfs in to sys/contrib: % git clone https://github.com/zfsonfreebsd/ZoF.git -b

Re: Geli encryption issue on r362779

2020-07-10 Thread Toomas Soome
> On 10. Jul 2020, at 18:05, Thomas Laus wrote: > >> On 2020-07-10 03:56, Toomas Soome wrote: >>> >>> ok, then next one is r363042. By nature it is an safeguard against read >>> past disk end. >>> >>> If that does not do, we really need to insert checkpoints in code and >>> see where exactly

Re: Boot failure on refreshed Dell Precision 7550

2020-07-10 Thread Toomas Soome
> On 10. Jul 2020, at 16:43, Shawn Webb wrote: > > On Fri, Jul 10, 2020 at 04:36:41PM +0300, Toomas Soome wrote: >> >> >>> On 10. Jul 2020, at 16:25, Shawn Webb wrote: >>> >>> Hey all, >>> >>> I just got in a new Dell Precision 7550 laptop. Tried booting FreeBSD >>> on it and UEFI boot

Re: svn commit: r352558 - head/usr.bin/top

2020-07-10 Thread Yuri Pankov
Steve Wills wrote: On 11/28/19 4:08 PM, Mark Millard via svn-src-head wrote: Author: daichi Date: Fri Sep 20 17:37:23 2019 New Revision: 352558 URL: https://svnweb.freebsd.org/changeset/base/352558 Log:    top(1): support multibyte characters in command names (ARGV array)    depending on

Re: Boot failure on refreshed Dell Precision 7550

2020-07-10 Thread Toomas Soome
> On 10. Jul 2020, at 16:25, Shawn Webb wrote: > > Hey all, > > I just got in a new Dell Precision 7550 laptop. Tried booting FreeBSD > on it and UEFI boot failed. The screen goes black immedately when > selecting the memstick and around ten to twenty seconds later, the > system reboots. >

A proposal to redefine RB trees

2020-07-10 Thread Doug Moore
I have a change ready to commit at https://reviews.freebsd.org/D25480 that would redefine the tree-balancing criteria for the RB tree macros, changing them from red-black trees to the weak-AVL trees described in the paper "Rank-balanced trees" by Haeupler, Sen and Tarjan.  By happy coincidence (or

Re: svn commit: r352558 - head/usr.bin/top

2020-07-10 Thread Steve Wills
On 11/28/19 4:08 PM, Mark Millard via svn-src-head wrote: Author: daichi Date: Fri Sep 20 17:37:23 2019 New Revision: 352558 URL: https://svnweb.freebsd.org/changeset/base/352558 Log: top(1): support multibyte characters in command names (ARGV array) depending on locale. - add

Re: Geli encryption issue on r362779

2020-07-10 Thread Thomas Laus
> On 2020-07-10 03:56, Toomas Soome wrote: >> >> ok, then next one is r363042. By nature it is an safeguard against read >> past disk end. >> >> If that does not do, we really need to insert checkpoints in code and >> see where exactly this reset will happen. Also note I >> have

Re: Boot failure on refreshed Dell Precision 7550

2020-07-10 Thread Shawn Webb
On Fri, Jul 10, 2020 at 09:43:59AM -0400, Shawn Webb wrote: > On Fri, Jul 10, 2020 at 04:36:41PM +0300, Toomas Soome wrote: > > > > > > > On 10. Jul 2020, at 16:25, Shawn Webb wrote: > > > > > > Hey all, > > > > > > I just got in a new Dell Precision 7550 laptop. Tried booting FreeBSD > > >

Re: Boot failure on refreshed Dell Precision 7550

2020-07-10 Thread Shawn Webb
On Fri, Jul 10, 2020 at 04:36:41PM +0300, Toomas Soome wrote: > > > > On 10. Jul 2020, at 16:25, Shawn Webb wrote: > > > > Hey all, > > > > I just got in a new Dell Precision 7550 laptop. Tried booting FreeBSD > > on it and UEFI boot failed. The screen goes black immedately when > > selecting

Boot failure on refreshed Dell Precision 7550

2020-07-10 Thread Shawn Webb
Hey all, I just got in a new Dell Precision 7550 laptop. Tried booting FreeBSD on it and UEFI boot failed. The screen goes black immedately when selecting the memstick and around ten to twenty seconds later, the system reboots. I'm thinking there might be a bug in the UEFI loader. I have zero

Re: Geli encryption issue on r362779

2020-07-10 Thread Toomas Soome
> On 7. Jul 2020, at 19:18, Thomas Laus wrote: > > On 2020-07-07 08:26, Toomas Soome wrote: >> Hi! >> >> I believe, 362989 should fix your issue. Please do let me know. >> > I updated to r362989. I built world and kernel after clearing out > /usr/obj and this problem still exists. It

Re: Geli encryption issue on r362779

2020-07-10 Thread Thomas Laus
On 2020-07-10 03:56, Toomas Soome wrote: > > ok, then next one is�r363042. By nature it is an safeguard against read > past disk end. > > If that does not do, we really need to insert checkpoints in code and > see where exactly this reset will happen. Also note I >