Re: Geli encryption issue on r362779

[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�https://reviews.freebsd.org/D25605�waiting in the queue.
>
I updated to r363042 and should complete building in a few hours.  I'll
post the results when complete.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Geli encryption issue on r362779

[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 works fine on my i5 desktop,
> but still has a problem reading my Geli encrypted partition.  I copied
> my old gptzfsboot file to ada0p1 from a live filesystem and it works.
> 
> Tom
> 


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 
https://reviews.freebsd.org/D25605  waiting 
in the queue.

rgds,
toomas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Geli encryption issue on r362779

[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 https://reviews.freebsd.org/D25605 waiting in the queue.
>>
> I updated to r363042 and should complete building in a few hours.  I'll
> post the results when complete.
>
I updated my source to r363042 and the results on my laptop were a
little worse.  I tried to boot 5 times and none were successful.  All of
them killed the kernel and 4 left a stack trace.  I took a photograph of
the stack trace, if it is any help.  If you need the stack trace, let me
know where to post.  I don't think that this mailing list allows
attachments.

This is the same laptop that you helped me with a 'Geli Taste' issue a
few months ago.  That problem never went completely away but was
tolerable.  It only happens about once every 2 weeks instead of daily
and always boots on the second attempt.

Tom


-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot failure on refreshed Dell Precision 7550

[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 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
> > experience in this area, but would love to learn. Can someone punish
> > me with ideas on how to debug this? ;P
> > 
> > I'll try to get whatever patches/fixes that come out of this effort
> > upstreamed.
> 
> Just in case, is secure boot turned off?

It is. FWIW, the laptop shipped with Ubuntu.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

GPG Key ID:  0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2
https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc


signature.asc
Description: PGP signature

Re: Boot failure on refreshed Dell Precision 7550

[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
> > > 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
> > > experience in this area, but would love to learn. Can someone punish
> > > me with ideas on how to debug this? ;P
> > > 
> > > I'll try to get whatever patches/fixes that come out of this effort
> > > upstreamed.
> > 
> > Just in case, is secure boot turned off?
> 
> It is. FWIW, the laptop shipped with Ubuntu.

I just built HardenedBSD 13-CURRENT install media from HardenedBSD
commit 4fd20919a535d41571f0b4140a6ec953f1bb38b2 and that booted fine.

I used the latest FreeBSD snapshot image, so I wonder what changed
between that snapshot image and today that would allow it to boot.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

GPG Key ID:  0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2
https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc


signature.asc
Description: PGP signature

Boot failure on refreshed Dell Precision 7550

[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
experience in this area, but would love to learn. Can someone punish
me with ideas on how to debug this? ;P

I'll try to get whatever patches/fixes that come out of this effort
upstreamed.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

GPG Key ID:  0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2
https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc


signature.asc
Description: PGP signature

Re: Boot failure on refreshed Dell Precision 7550

[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 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
>>> experience in this area, but would love to learn. Can someone punish
>>> me with ideas on how to debug this? ;P
>>> 
>>> I'll try to get whatever patches/fixes that come out of this effort
>>> upstreamed.
>> 
>> Just in case, is secure boot turned off?
> 
> It is. FWIW, the laptop shipped with Ubuntu.
> 

The stick… what is on it?:) I mean, boot1.efi or loader.efi?

rgds,
toomas

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

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

[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 locale.
    - add setlocale()
    - remove printable() function
    - add VIS_OCTAL and VIS_SAFE to the flag of strvisx() to display
  non-printable characters that do not use C-style backslash 
sequences

  in three digit octal sequence, or remove it
   This change allows multibyte characters to be displayed according to
   locale. If it is recognized as a non-display character according 
to the

   locale, it is displayed in three digit octal sequence.



Initially picking on tab characters as an example of what is
probably a somewhat broader issue . . .

Ever since this change, characters like tabs that do not fit
in the next character cell when output, but for which they
are !isprintable(...), now mess up the top display. Again
using tab as an example: line wrapping from the text having
been shifted over by more than one character cell. top does
not track the line wrapping result in how it decides what
to output for the following display updates.



Apologies for the way late reply here, but I just now bothered tracking 
this down. This commit seems to be the cause of some corruption I'm 
seeing in long running top(1) as well. As Mark mentions, if I use "hh" 
it clears up. Should I open a bugzilla bug? I can share screenshots of 
the corruption, such as:


https://i.imgur.com/Xqlwf9h.png
https://i.imgur.com/Jv0d5NU.png


Does removing VIS_SAFE fixes the issue for you?

As for original Mark's report (which I missed), removing isprintable() 
doesn't look wrong as vis(3) should take of its functionality (and in 
multibyte-aware way).


Also, is there an easy way to reproduce this?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

A proposal to redefine RB trees

[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 the authors' deliberate scheme), the letters RB can
represent "Rank-balanced" as easily as "red-black", so no global
renaming is required.

This change does not add or remove fields.  It does keep a tighter
balance constraint than red-black trees, so that in conditions where
balancing really matters (for example, when inserting tree nodes in
sorted order), weak-avl trees produce a better balanced tree and faster
lookups.  That same tighter balance constraint means that an insert
operation is more likely to lead to restructuring of the tree than
before, for which there is a small performance cost.

The original paper at
http://sidsen.azurewebsites.net/papers/rb-trees-talg.pdf provides more
analysis of the relative benefits of weak-avl trees.

Are there any objections?

Doug Moore (do...@freebsd.org)

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

Re: Boot failure on refreshed Dell Precision 7550

[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.
> 
> I'm thinking there might be a bug in the UEFI loader. I have zero
> experience in this area, but would love to learn. Can someone punish
> me with ideas on how to debug this? ;P
> 
> I'll try to get whatever patches/fixes that come out of this effort
> upstreamed.

Just in case, is secure boot turned off?

rgds,
toomas

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

Re: CFT for vendor openzfs

[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
projects/openzfs_vendor freebsd/sys/contrib/openzfs



A success compile and boot story here, will be alert and report 
oddities if I find any; otherwise this would be one person who is 
testing for whom things aren't utterly broken :-).


Just an addendum to your instructions:

If someone is already using git to manage FreeBSD's source, this 
would be the way:

# Change working dir to the git repository
% cd ${FREEBSD_GIT_SOURCE}
# Add Matthew's remote
% git add remote mattmacy 
 https://github.com/mattmacy/networking.git

# This will make it easier to follow HEAD
% git config pull.rebase true
# Merge Matthew's changes into curent branch
% git merge mattmacy/projects/openzfs_vendor
# Get OpenZFS's code
% git clone https://github.com/zfsonfreebsd/ZoF.git -b 
 projects/openzfs_vendor sys/contrib/openzfs

# Build, install as usual, maybe use a checkpoint ;-)
--
Evilham
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[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 setlocale()

- remove printable() function
- add VIS_OCTAL and VIS_SAFE to the flag of strvisx() to display
  non-printable characters that do not use C-style backslash sequences
  in three digit octal sequence, or remove it
   
   This change allows multibyte characters to be displayed according to

   locale. If it is recognized as a non-display character according to the
   locale, it is displayed in three digit octal sequence.



Initially picking on tab characters as an example of what is
probably a somewhat broader issue . . .

Ever since this change, characters like tabs that do not fit
in the next character cell when output, but for which they
are !isprintable(...), now mess up the top display. Again
using tab as an example: line wrapping from the text having
been shifted over by more than one character cell. top does
not track the line wrapping result in how it decides what
to output for the following display updates.



Apologies for the way late reply here, but I just now bothered tracking 
this down. This commit seems to be the cause of some corruption I'm 
seeing in long running top(1) as well. As Mark mentions, if I use "hh" 
it clears up. Should I open a bugzilla bug? I can share screenshots of 
the corruption, such as:


https://i.imgur.com/Xqlwf9h.png
https://i.imgur.com/Jv0d5NU.png

Thanks,
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Geli encryption issue on r362779

[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 this reset will happen. Also note I
>>> have https://reviews.freebsd.org/D25605 waiting in the queue.
>>> 
>> I updated to r363042 and should complete building in a few hours.  I'll
>> post the results when complete.
>> 
> I updated my source to r363042 and the results on my laptop were a
> little worse.  I tried to boot 5 times and none were successful.  All of
> them killed the kernel and 4 left a stack trace.  I took a photograph of
> the stack trace, if it is any help.  If you need the stack trace, let me
> know where to post.  I don't think that this mailing list allows
> attachments.
> 
> This is the same laptop that you helped me with a 'Geli Taste' issue a
> few months ago.  That problem never went completely away but was
> tolerable.  It only happens about once every 2 weeks instead of daily
> and always boots on the second attempt.
> 
> Tom
> 

You can mail it directly, thats no problem. But if you get kernel killed and 
stack trace… stack trace from kernel? So it does mean you do get loader running 
and kernel loaded? could you get to loader prompt and get output of command: 
smap ?

thanks,
toomas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[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
>> URL:
>> https://svnweb.freebsd.org/changeset/base/352558
>> 
>> 
>> Log:
>>top(1): support multibyte characters in command names (ARGV array)
>>depending on locale.
>> - add setlocale()
>> - remove printable() function
>> - add VIS_OCTAL and VIS_SAFE to the flag of strvisx() to display
>>   non-printable characters that do not use C-style backslash 
>> sequences
>>   in three digit octal sequence, or remove it
>>This change allows multibyte characters to be displayed according to
>>locale. If it is recognized as a non-display character according to 
>> the
>>locale, it is displayed in three digit octal sequence.
>> 
> 
> Initially picking on tab characters as an example of what is
> probably a somewhat broader issue . . .
> 
> Ever since this change, characters like tabs that do not fit
> in the next character cell when output, but for which they
> are !isprintable(...), now mess up the top display. Again
> using tab as an example: line wrapping from the text having
> been shifted over by more than one character cell. top does
> not track the line wrapping result in how it decides what
> to output for the following display updates.
> 
 Apologies for the way late reply here, but I just now bothered tracking 
 this down. This commit seems to be the cause of some corruption I'm seeing 
 in long running top(1) as well. As Mark mentions, if I use "hh" it clears 
 up. Should I open a bugzilla bug? I can share screenshots of the 
 corruption, such as:
 https://i.imgur.com/Xqlwf9h.png
 https://i.imgur.com/Jv0d5NU.png
>>> 
>>> Does removing VIS_SAFE fixes the issue for you?
>>> 
>>> As for original Mark's report (which I missed), removing isprintable() 
>>> doesn't look wrong as vis(3) should take of its functionality (and in 
>>> multibyte-aware way).
>> vis (as used) and the old isprintable logic are not
>> equivalent when multi-byte is not needed/involved.
>> Otherwise I'd not have had anything to ever report.
>> If vis can do what is needed, more work needed to
>> be done when the change was made in order to avoid
>> msesed up displays in single-byte contexts.
>>> Also, is there an easy way to reproduce this?
>> The following sort of command (the empty space inside quoted
>> text are tab characters):
>> # tr '0\n  1\n 2\n 3\n 4\n 5\n 6\n 7\n 8\n' 
>> '\t0   \t1 \t2 \t3 \t4 \t5 \t6 \t7 \t8' < 
>> /dev/zero > /dev/null
>> causes my 200 character wide window running top to show:
>> 32920 root1000  12764Ki2420Ki CPU3 3   2:22  99.87% tr 
>> 0\\n  1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n \\t0  
>>  \\t1\\t2\\t3\\t4\\t5\\t6\\t733   \\t8   20  
>>   7172  5448Ki CPU23   23   0:00   0.04% top -HiSCazopid
>> But that does not show where the lines wrap at the edges of the window,
>> so breaking it up explicitly after the first "\" in \\7:
>> 32920 root1000  12764Ki2420Ki CPU3 3   2:22  99.87% tr 
>> 0\\n  1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n \\t0  
>>  \\t1\\t2\\t3\\t4\\t5\\t6\
>> \t733   \\t8   207172  5448Ki CPU23   23   0:00   0.04% top 
>> -HiSCazopid
>> Note how \n turned into \\n , taking an extra character for
>> each \n . Similarly for \t vs. \\t . (Other examples do
>> similarly.)
>> The tab characters really do use more than one character cell
>> on the display (sometimes).
>> The text from the tr command ends up spread across 2 lines
>> as things look like in the window where top is running.
>> I ran top in another ssh session first and then the tr command.
>> Before running the tr command, top showed as:
>> 33019 root 200  17172Ki5448Ki CPU24   24   0:00   0.05% top 
>> -HiSCazopid
>> If you do not end up with top listed just after tr in top's output,
>> then it will not be top's line that ends up partially overwritten.
>> If you have wider windows, you may need more text in the tr quoted
>> strings.
>> In another experiment I inserted a large number of backspace characters
>> (control-H's) at the front of the first quoted string in the tr command.
>> The top output displayed:
>> 0\\n5 ro1\\n2\\93   3\\n12764\\n   25\\ni CP6\\n   97\\n:12 100.00\t0r 
>> \nHiS\\t1pid \\t2 \\t3\\t4\\t5\\t6\\t
>> 33094 root 200  17172Ki5488Ki CPU21   21   0:00   0.06% top 
>> -HiSCazopid
>> In other words, backspace moved the cursor position back over prior
>> 

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

[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
 
 
 Log:
top(1): support multibyte characters in command names (ARGV array)
depending on locale.
 - add setlocale()
 - remove printable() function
 - add VIS_OCTAL and VIS_SAFE to the flag of strvisx() to display
   non-printable characters that do not use C-style backslash sequences
   in three digit octal sequence, or remove it
This change allows multibyte characters to be displayed according to
locale. If it is recognized as a non-display character according to the
locale, it is displayed in three digit octal sequence.
 
>>> 
>>> Initially picking on tab characters as an example of what is
>>> probably a somewhat broader issue . . .
>>> 
>>> Ever since this change, characters like tabs that do not fit
>>> in the next character cell when output, but for which they
>>> are !isprintable(...), now mess up the top display. Again
>>> using tab as an example: line wrapping from the text having
>>> been shifted over by more than one character cell. top does
>>> not track the line wrapping result in how it decides what
>>> to output for the following display updates.
>>> 
>> Apologies for the way late reply here, but I just now bothered tracking this 
>> down. This commit seems to be the cause of some corruption I'm seeing in 
>> long running top(1) as well. As Mark mentions, if I use "hh" it clears up. 
>> Should I open a bugzilla bug? I can share screenshots of the corruption, 
>> such as:
>> https://i.imgur.com/Xqlwf9h.png
>> https://i.imgur.com/Jv0d5NU.png
> 
> Does removing VIS_SAFE fixes the issue for you?
> 
> As for original Mark's report (which I missed), removing isprintable() 
> doesn't look wrong as vis(3) should take of its functionality (and in 
> multibyte-aware way).

vis (as used) and the old isprintable logic are not
equivalent when multi-byte is not needed/involved.
Otherwise I'd not have had anything to ever report.
If vis can do what is needed, more work needed to
be done when the change was made in order to avoid
msesed up displays in single-byte contexts.

> Also, is there an easy way to reproduce this?

The following sort of command (the empty space inside quoted
text are tab characters):

# tr '0\n  1\n 2\n 3\n 4\n 5\n 6\n 7\n 8\n' 
'\t0   \t1 \t2 \t3 \t4 \t5 \t6 \t7 \t8' < 
/dev/zero > /dev/null

causes my 200 character wide window running top to show:

32920 root1000  12764Ki2420Ki CPU3 3   2:22  99.87% tr 0\\n 
1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n \\t0   \\t1
\\t2\\t3\\t4\\t5\\t6\\t733   \\t8   207172  
5448Ki CPU23   23   0:00   0.04% top -HiSCazopid

But that does not show where the lines wrap at the edges of the window,
so breaking it up explicitly after the first "\" in \\7:

32920 root1000  12764Ki2420Ki CPU3 3   2:22  99.87% tr 0\\n 
1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n \\t0   \\t1
\\t2\\t3\\t4\\t5\\t6\
\t733   \\t8   207172  5448Ki CPU23   23   0:00   0.04% top 
-HiSCazopid

Note how \n turned into \\n , taking an extra character for
each \n . Similarly for \t vs. \\t . (Other examples do
similarly.)

The tab characters really do use more than one character cell
on the display (sometimes).

The text from the tr command ends up spread across 2 lines
as things look like in the window where top is running.

I ran top in another ssh session first and then the tr command.
Before running the tr command, top showed as:

33019 root 200  17172Ki5448Ki CPU24   24   0:00   0.05% top 
-HiSCazopid

If you do not end up with top listed just after tr in top's output,
then it will not be top's line that ends up partially overwritten.

If you have wider windows, you may need more text in the tr quoted
strings.

In another experiment I inserted a large number of backspace characters
(control-H's) at the front of the first quoted string in the tr command.
The top output displayed:

0\\n5 ro1\\n2\\93   3\\n12764\\n   25\\ni CP6\\n   97\\n:12 100.00\t0r 
\nHiS\\t1pid \\t2\\t3\\t4\\t5\\t6\\t
33094 root 200  17172Ki5488Ki CPU21   21   0:00   0.06% top 
-HiSCazopid

In other words, backspace moved the cursor position back over prior
fields on the line and then the later line content overwrote those
fields instead of being after "tr" someplace (or truncated off).

Note that part of "-HiSCazopid" shows up on both lines. The extra
is from when top was running but tr had not started yet. top is
not managing text replacement correctly for output 

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

[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:
https://svnweb.freebsd.org/changeset/base/352558


Log:
top(1): support multibyte characters in command names (ARGV array)
depending on locale.
 - add setlocale()
 - remove printable() function
 - add VIS_OCTAL and VIS_SAFE to the flag of strvisx() to display
   non-printable characters that do not use C-style backslash sequences
   in three digit octal sequence, or remove it
This change allows multibyte characters to be displayed according to
locale. If it is recognized as a non-display character according to the
locale, it is displayed in three digit octal sequence.



Initially picking on tab characters as an example of what is
probably a somewhat broader issue . . .

Ever since this change, characters like tabs that do not fit
in the next character cell when output, but for which they
are !isprintable(...), now mess up the top display. Again
using tab as an example: line wrapping from the text having
been shifted over by more than one character cell. top does
not track the line wrapping result in how it decides what
to output for the following display updates.


Apologies for the way late reply here, but I just now bothered tracking this down. This 
commit seems to be the cause of some corruption I'm seeing in long running top(1) as 
well. As Mark mentions, if I use "hh" it clears up. Should I open a bugzilla 
bug? I can share screenshots of the corruption, such as:
https://i.imgur.com/Xqlwf9h.png
https://i.imgur.com/Jv0d5NU.png


Does removing VIS_SAFE fixes the issue for you?

As for original Mark's report (which I missed), removing isprintable() doesn't 
look wrong as vis(3) should take of its functionality (and in multibyte-aware 
way).

vis (as used) and the old isprintable logic are not
equivalent when multi-byte is not needed/involved.
Otherwise I'd not have had anything to ever report.
If vis can do what is needed, more work needed to
be done when the change was made in order to avoid
msesed up displays in single-byte contexts.

Also, is there an easy way to reproduce this?

The following sort of command (the empty space inside quoted
text are tab characters):
# tr '0\n  1\n 2\n 3\n 4\n 5\n 6\n 7\n 8\n' '\t0  
 \t1 \t2 \t3 \t4 \t5 \t6 \t7 \t8' < /dev/zero > 
/dev/null
causes my 200 character wide window running top to show:
32920 root1000  12764Ki2420Ki CPU3 3   2:22  99.87% tr 0\\n 
1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n \\t0   \\t1
\\t2\\t3\\t4\\t5\\t6\\t733   \\t8   207172  
5448Ki CPU23   23   0:00   0.04% top -HiSCazopid
But that does not show where the lines wrap at the edges of the window,
so breaking it up explicitly after the first "\" in \\7:
32920 root1000  12764Ki2420Ki CPU3 3   2:22  99.87% tr 0\\n 
1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n \\t0   \\t1
\\t2\\t3\\t4\\t5\\t6\
\t733   \\t8   207172  5448Ki CPU23   23   0:00   0.04% top 
-HiSCazopid
Note how \n turned into \\n , taking an extra character for
each \n . Similarly for \t vs. \\t . (Other examples do
similarly.)
The tab characters really do use more than one character cell
on the display (sometimes).
The text from the tr command ends up spread across 2 lines
as things look like in the window where top is running.
I ran top in another ssh session first and then the tr command.
Before running the tr command, top showed as:
33019 root 200  17172Ki5448Ki CPU24   24   0:00   0.05% top 
-HiSCazopid
If you do not end up with top listed just after tr in top's output,
then it will not be top's line that ends up partially overwritten.
If you have wider windows, you may need more text in the tr quoted
strings.
In another experiment I inserted a large number of backspace characters
(control-H's) at the front of the first quoted string in the tr command.
The top output displayed:
0\\n5 ro1\\n2\\93   3\\n12764\\n   25\\ni CP6\\n   97\\n:12 100.00\t0r 
\nHiS\\t1pid \\t2\\t3\\t4\\t5\\t6\\t
33094 root 200  17172Ki5488Ki CPU21   21   0:00   0.06% top 
-HiSCazopid
In other words, backspace moved the cursor position back over prior
fields on the line and then the later line content overwrote those
fields instead of being after "tr" someplace (or truncated off).
Note that part of "-HiSCazopid" shows up on both lines. The extra
is from when top was running but tr had not started yet. top is
not managing text replacement correctly for output characters that
end up not being just "in" the next character-cell on the terminal.
The same 

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

[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:
> https://svnweb.freebsd.org/changeset/base/352558
> 
> 
> Log:
>   top(1): support multibyte characters in command names (ARGV array)
>   depending on locale.
>- add setlocale()
>- remove printable() function
>- add VIS_OCTAL and VIS_SAFE to the flag of strvisx() to display
>  non-printable characters that do not use C-style backslash sequences
>  in three digit octal sequence, or remove it
>   This change allows multibyte characters to be displayed according to
>   locale. If it is recognized as a non-display character according to the
>   locale, it is displayed in three digit octal sequence.
> 
 
 Initially picking on tab characters as an example of what is
 probably a somewhat broader issue . . .
 
 Ever since this change, characters like tabs that do not fit
 in the next character cell when output, but for which they
 are !isprintable(...), now mess up the top display. Again
 using tab as an example: line wrapping from the text having
 been shifted over by more than one character cell. top does
 not track the line wrapping result in how it decides what
 to output for the following display updates.
 
>>> Apologies for the way late reply here, but I just now bothered tracking 
>>> this down. This commit seems to be the cause of some corruption I'm seeing 
>>> in long running top(1) as well. As Mark mentions, if I use "hh" it clears 
>>> up. Should I open a bugzilla bug? I can share screenshots of the 
>>> corruption, such as:
>>> https://i.imgur.com/Xqlwf9h.png
>>> https://i.imgur.com/Jv0d5NU.png
>> 
>> Does removing VIS_SAFE fixes the issue for you?
>> 
>> As for original Mark's report (which I missed), removing isprintable() 
>> doesn't look wrong as vis(3) should take of its functionality (and in 
>> multibyte-aware way).
> 
> vis (as used) and the old isprintable logic are not
> equivalent when multi-byte is not needed/involved.
> Otherwise I'd not have had anything to ever report.
> If vis can do what is needed, more work needed to
> be done when the change was made in order to avoid
> msesed up displays in single-byte contexts.
> 
>> Also, is there an easy way to reproduce this?
> 
> The following sort of command (the empty space inside quoted
> text are tab characters):
> 
> # tr '0\n  1\n 2\n 3\n 4\n 5\n 6\n 7\n 8\n' 
> '\t0   \t1 \t2 \t3 \t4 \t5 \t6 \t7 \t8' < 
> /dev/zero > /dev/null
> 
> causes my 200 character wide window running top to show:
> 
> 32920 root1000  12764Ki2420Ki CPU3 3   2:22  99.87% tr 
> 0\\n   1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n \\t0  
>  \\t1\\t2\\t3\\t4\\t5\\t6\\t733   \\t8   20   
>  7172  5448Ki CPU23   23   0:00 0.04% top -HiSCazopid
> 
> But that does not show where the lines wrap at the edges of the window,
> so breaking it up explicitly after the first "\" in \\7:
> 
> 32920 root1000  12764Ki2420Ki CPU3 3   2:22  99.87% tr 
> 0\\n   1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n \\t0  
>  \\t1\\t2\\t3\\t4\\t5\\t6\
> \t733   \\t8   207172  5448Ki CPU23   23   0:00   0.04% top 
> -HiSCazopid
> 
> Note how \n turned into \\n , taking an extra character for
> each \n . Similarly for \t vs. \\t . (Other examples do
> similarly.)
> 
> The tab characters really do use more than one character cell
> on the display (sometimes).
> 
> The text from the tr command ends up spread across 2 lines
> as things look like in the window where top is running.
> 
> I ran top in another ssh session first and then the tr command.
> Before running the tr command, top showed as:
> 
> 33019 root 200  17172Ki5448Ki CPU24   24   0:00   0.05% top 
> -HiSCazopid
> 
> If you do not end up with top listed just after tr in top's output,
> then it will not be top's line that ends up partially overwritten.
> 
> If you have wider windows, you may need more text in the tr quoted
> strings.
> 
> In another experiment I inserted a large number of backspace characters
> (control-H's) at the front of the first quoted string in the tr command.
> The top output displayed:
> 
> 0\\n5 ro1\\n2\\93   3\\n12764\\n   25\\ni CP6\\n   97\\n:12 100.00\t0r 
> \nHiS\\t1pid \\t2  \\t3\\t4\\t5\\t6\\t
> 33094 root 200  17172Ki5488Ki CPU21   21   0:00   0.06% top 
> -HiSCazopid
> 
> In other words, backspace moved the cursor position back over prior
> fields on the line and then the later line content overwrote those
> fields instead of 

DRM Project report (week of July 6th)

[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 release.
 Speaking of mesa the first merge request for FreeBSD related patches
was merged on July 4th
(https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3559), since
reduce a lot the number of patches that we will need in the ports tree
when 20.1 will be release. Other merge requests are still opened :
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests?scope=all=%E2%9C%93=opened=freebsd
 and after talking to upstream they would really like some FreeBSD
support in their CI, the ideal would be to have a gitlab-runner
somewhere but for now I've took the road of creating a CI compliant
image that have sshd allowed without root password that will work with
QEMU, see https://reviews.freebsd.org/D25598, we'll see how it goes but
I hope that it will allow us to have more CI support in freedesktop
projects (mesa, libdrm, xorg, wayland etc ...), don't forget that DRM
drivers are a bit useless without proper support for FreeBSD on
userland libs and program :)

 To have testing easier for me and others I've added into poudriere a
mode to create a pkgbase image, this allow me to create small usb disk
image that have all the necessary userland program for testing drm
drivers. I've also started an image that will test various graphics
related stuff like trying some drm driver sysctl tweaks etc ... all
done with a dialog based program. The image is intended to be used to
generate a wiki page that users could just upload and also quick
testing FreeBSD on desktops/laptops.
 https://github.com/freebsd/poudriere/pull/756
 I intend to publish scripts for creating the image at the end of next
week and will possibly generate one image per week that people could
download.

 Back on DRM I've started 5.4 update, for now it's ~20% done and I
expect the sync to be finish at the end of July.
 https://github.com/freebsd/drm-kmod/tree/5.4

 I don't think that I've forgotten something, if I did it will be
included in next week reports :)

 All this work is under sponsorship from the FreeBSD Foundation.

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

-CURRENT and drm-devel-kmod

[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
(Ctrl+alt+Fx). I see it refresh and display the new content just before
switching to the requested console.

X behaves the same way. Has anyone experienced this?

Best regards
Andreas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[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 multibyte characters in command names (ARGV array)
depending on locale.
 - add setlocale()
 - remove printable() function
 - add VIS_OCTAL and VIS_SAFE to the flag of strvisx() to display
   non-printable characters that do not use C-style backslash sequences
   in three digit octal sequence, or remove it
This change allows multibyte characters to be displayed according to
locale. If it is recognized as a non-display character according to the
locale, it is displayed in three digit octal sequence.



Initially picking on tab characters as an example of what is
probably a somewhat broader issue . . .

Ever since this change, characters like tabs that do not fit
in the next character cell when output, but for which they
are !isprintable(...), now mess up the top display. Again
using tab as an example: line wrapping from the text having
been shifted over by more than one character cell. top does
not track the line wrapping result in how it decides what
to output for the following display updates.


Apologies for the way late reply here, but I just now bothered tracking this down. This 
commit seems to be the cause of some corruption I'm seeing in long running top(1) as 
well. As Mark mentions, if I use "hh" it clears up. Should I open a bugzilla 
bug? I can share screenshots of the corruption, such as:
https://i.imgur.com/Xqlwf9h.png
https://i.imgur.com/Jv0d5NU.png


Does removing VIS_SAFE fixes the issue for you?

As for original Mark's report (which I missed), removing isprintable() doesn't 
look wrong as vis(3) should take of its functionality (and in multibyte-aware 
way).


vis (as used) and the old isprintable logic are not
equivalent when multi-byte is not needed/involved.
Otherwise I'd not have had anything to ever report.
If vis can do what is needed, more work needed to
be done when the change was made in order to avoid
msesed up displays in single-byte contexts.


Also, is there an easy way to reproduce this?


The following sort of command (the empty space inside quoted
text are tab characters):

# tr '0\n  1\n 2\n 3\n 4\n 5\n 6\n 7\n 8\n' '\t0  
 \t1 \t2 \t3 \t4 \t5 \t6 \t7 \t8' < /dev/zero > 
/dev/null

causes my 200 character wide window running top to show:

32920 root1000  12764Ki2420Ki CPU3 3   2:22  99.87% tr 0\\n 
1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n \\t0   \\t1
\\t2\\t3\\t4\\t5\\t6\\t733   \\t8   207172  
5448Ki CPU23   23   0:00   0.04% top -HiSCazopid

But that does not show where the lines wrap at the edges of the window,
so breaking it up explicitly after the first "\" in \\7:

32920 root1000  12764Ki2420Ki CPU3 3   2:22  99.87% tr 0\\n 
1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n \\t0   \\t1
\\t2\\t3\\t4\\t5\\t6\
\t733   \\t8   207172  5448Ki CPU23   23   0:00   0.04% top 
-HiSCazopid

Note how \n turned into \\n , taking an extra character for
each \n . Similarly for \t vs. \\t . (Other examples do
similarly.)

The tab characters really do use more than one character cell
on the display (sometimes).

The text from the tr command ends up spread across 2 lines
as things look like in the window where top is running.

I ran top in another ssh session first and then the tr command.
Before running the tr command, top showed as:

33019 root 200  17172Ki5448Ki CPU24   24   0:00   0.05% top 
-HiSCazopid

If you do not end up with top listed just after tr in top's output,
then it will not be top's line that ends up partially overwritten.

If you have wider windows, you may need more text in the tr quoted
strings.

In another experiment I inserted a large number of backspace characters
(control-H's) at the front of the first quoted string in the tr command.
The top output displayed:

0\\n5 ro1\\n2\\93   3\\n12764\\n   25\\ni CP6\\n   97\\n:12 100.00\t0r 
\nHiS\\t1pid \\t2\\t3\\t4\\t5\\t6\\t
33094 root 200  17172Ki5488Ki CPU21   21   0:00   0.06% top 
-HiSCazopid

In other words, backspace moved the cursor position back over prior
fields on the line and then the later line content overwrote those
fields instead of being after "tr" someplace (or truncated off).

Note that part of "-HiSCazopid" shows up on both lines. The extra
is from when top was running but tr had not started yet. top is
not managing text replacement correctly for output characters that
end up not being just "in" the next character-cell on the terminal.

The same sort of result happens when instead adding just one

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

[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 -- it's either a hard hang, 
panic, or VM dying with exception, even with a workaround of 1 CPU 
(core) provided in the Wiki.  I can reinstall and provide panic info if 
you are interested in looking into it.

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

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

[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 I don't have a VM with X11 
> installed as all my attempts didn't succeed -- it's either a hard hang, 
> panic, or VM dying with exception, even with a workaround of 1 CPU 
> (core) provided in the Wiki.  I can reinstall and provide panic info if 
> you are interested in looking into it.

 Hi,

 I haven't tested vmwgfx or vboxvideo yet, iirc someone told me that at
least vboxvideo used to work, I have no idea if vmwgfx used to.
 If you have any panic please open an issue there :
https://github.com/freebsd/drm-kmod/
 To be honest with you intel and amd are my priorities and already
occupy most of my time for testing. The plan that I have is to be sure
to have for vboxvideo and vmwgfx when I reach 5.4

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

Re: -CURRENT and drm-devel-kmod

[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 that.
 For now use current if that works for you.

> However, when I load i915kms from -devel
> the console stops refreshing. It only refreshes when I switch
> (Ctrl+alt+Fx). I see it refresh and display the new content just before
> switching to the requested console.

 add hw.i915kms.enable_psr=0 to /boot/loader.conf
 This is a bug that none of my hardware have and I don't really know
what's happening for now.

> X behaves the same way. Has anyone experienced this?
> 
> Best regards
> Andreas
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


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