[Bug 253429] Failed invocation of /usr/sbin/service when going multi-user

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253429

Bug ID: 253429
   Summary: Failed invocation of /usr/sbin/service when going
multi-user
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: conf
  Assignee: b...@freebsd.org
  Reporter: s...@freebsd.org

A few weeks ago I noticed that cron is no longer started on my system after a
reboot.

This is caused by /usr being on a separate ZFS file system that has not been
mounted at the time when the rc script tries to start cron, despite it having a
REQUIRE: FILESYSTEMS condition:

# PROVIDE: cron
# REQUIRE: LOGIN FILESYSTEMS
# BEFORE: securelevel
# KEYWORD: shutdown

According to "service -e", cron is one of the last few services to be started:

$ service -e
/etc/rc.d/rctl
/etc/rc.d/hostid
/etc/rc.d/zpool
/etc/rc.d/zvol
/etc/rc.d/hostid_save
/usr/local/etc/rc.d/microcode_update
/etc/rc.d/zfsbe
/etc/rc.d/zfs
...
/etc/rc.d/cron
/usr/local/etc/rc.d/sa-spamd
/usr/local/etc/rc.d/dovecot
/usr/local/etc/rc.d/postfix
/etc/rc.d/bgfsck

But in fact, starting cron is the first action when going multi-user and before
local file systems (beyond / and /dev) have been mounted:

...
ugen0.6:  at usbus0
ukbd0 on uhub3
ukbd0:  on usbus0
kbd2 at ukbd0
hidraw1 on uhub3
hidraw1:  on usbus0
/etc/rc.d/cron: service: not found
/etc/rc: WARNING: run_rc_command: cannot run /usr/sbin/cron
Setting hostuuid: 1e0028e0-008c-4300-13a1-f46d04d87842.
Setting hostid: 0x3c3b54d6.
Starting file system checks:
Mounting local filesystems:.

The log shows, that the /usr/sbin/service command is not available, yet.
The same is of course true for /usr/sbin/cron.

Before mounting the essential file systems, commands like service are not
available and I understand that this is a contradiction to file systems being
mounted when going multi-user as directed by the output of "service -e".

I'm not aware on any local modifications of my start-up scripts, but I guess
that having a separate /usr partition is not common, anymore.

Moving the "service" command to /sbin might fix this issue (to be verified).

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253429] Failed invocation of /usr/sbin/service when going multi-user

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253429

--- Comment #1 from Andriy Gapon  ---
You can try to use rcorder /etc/rc.d/* /usr/local/etc/rc.d/* to investigate why
your system tries to start cron so early.
Here, it is started much later, after LOGIN.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253313] lib/msun: hypotl(3) mishandles subnormal numbers

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253313

--- Comment #5 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=25120662284466ecef976df8f86e97bafdedf991

commit 25120662284466ecef976df8f86e97bafdedf991
Author: Dimitry Andric 
AuthorDate: 2021-02-11 11:01:10 +
Commit: Dimitry Andric 
CommitDate: 2021-02-11 11:01:10 +

Fix lib/msun/test builds on platforms without 80-bit long doubles

After d3338f3355a612cf385632291f46c5777bba8d18, the lib/msun test case
'hypotl_near_underflow' would fail to compile on platforms where long
doubles weren't 80 bit, like on x86. Disable this particular test on
such platforms for now.

PR: 253313
MFC after:  1 week
X-MFC-With: d3338f3355a612cf385632291f46c5777bba8d18

 contrib/netbsd-tests/lib/libm/t_hypot.c | 4 
 1 file changed, 4 insertions(+)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253435] Jail do not create tunnel (wireguard) interface alias.

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253435

Bug ID: 253435
   Summary: Jail do not create tunnel (wireguard) interface alias.
   Product: Base System
   Version: 12.2-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: robert.david.pub...@gmail.com

When adding wireguard tunnel interface alias address to the jail I need to
specify it without the interface name and create the address staticly before
jail startup.

Examples that does not work:

1)
no wgnet0 address created
jail.conf:
ip4.addr = "wgnet0|192.168.0.10"; 

2)
wgnet0 address created using
ifconfig wgnet0 inet 192.168.0.10 192.168.0.10 alias
jail.conf:
ip4.addr = "wgnet0|192.168.0.10";


Example that works:
when I create the alias and remove the interface name from ip4.addr

wgnet0 address created using
ifconfig wgnet0 inet 192.168.0.10 192.168.0.10 alias
jail.conf:
ip4.addr = "192.168.0.10";

Seems like the last one works by accident, because it assigns to the correct
interface if the address is defined.

I don't know if this affects only wireguard or generic tunnel interface. But
the solution would be make the first example working by using different
ifconfig arguments in the jail starting procedure.

Eg:
ifconfig wgnet0 inet 192.168.0.10 192.168.0.10 alias

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253435] Jail does not create tunnel (wireguard) interface alias.

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253435

Robert David  changed:

   What|Removed |Added

Summary|Jail do not create tunnel   |Jail does not create tunnel
   |(wireguard) interface   |(wireguard) interface
   |alias.  |alias.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253350] Grep regression with --after-context (-A) and --max-count (-m) switches

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253350

--- Comment #4 from commit-h...@freebsd.org ---
A commit in branch releng/13.0 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=dc57f212526d25e8ef036e768b816a7fdae5707b

commit dc57f212526d25e8ef036e768b816a7fdae5707b
Author: Kyle Evans 
AuthorDate: 2021-02-11 15:11:24 +
Commit: Kyle Evans 
CommitDate: 2021-02-11 15:12:17 +

grep: fix -A handling in conjunction with -m match limitation

The basic issue here is that grep, when given -m 1, would stop all
line processing once it hit the match count and exit immediately.  The
problem with exiting immediately is that -A processing only happens when
subsequent lines are processed and do not match.

The fix here is relatively easy; when bsdgrep matches a line, it resets
the 'tail' of the matching context to the value supplied to -A and
dumps anything that's been queued up for -B. After the current line has
been printed and tail is reset, we check our mcount and do what's
needed. Therefore, at the time that we decide we're doing nothing, we
know that 'tail' of the context is correct and we can simply continue
on if there's still more to pick up.

With this change, we still bail out immediately if there's been no -A
flag. If -A was supplied, we signal that we should continue on. However,
subsequent lines will not even bothere to try and process the line.  We
have reached the match count, so even if the next line would match then
we must process it if it hadn't. Thus, the loop in procfile() can
short-circuit and just process the line as a non-match until
procmatches() indicates that it's safe to stop.

A test has been added to reflect both that we should be picking up the
next line and that the next line should be considered a non-match even
if it should have been.

PR: 253350
Approved by:re (gjb)

(cherry picked from commit 3e2d96ac974db823255a6f40b90eeffa6e38d022)
(cherry picked from commit 08f25b50dbd332e5c5c9380fd90c516e9af1ab36)

 contrib/netbsd-tests/usr.bin/grep/t_grep.sh | 17 +
 usr.bin/grep/util.c | 21 -
 2 files changed, 37 insertions(+), 1 deletion(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253209] grep -v -f some-empty-file -- does the wrong thing

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253209

--- Comment #4 from commit-h...@freebsd.org ---
A commit in branch releng/13.0 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=f28ccd8d95954134cec93db482fb0bd4ce93f36e

commit f28ccd8d95954134cec93db482fb0bd4ce93f36e
Author: Kyle Evans 
AuthorDate: 2021-02-11 15:10:44 +
Commit: Kyle Evans 
CommitDate: 2021-02-11 15:12:10 +

grep: fix null pattern and empty pattern file behavior

The null pattern semantics were terrible because I tried to match gnugrep,
but I got it wrong.  Let's unwind that:

- The null pattern should match every line if neither -w nor -x.
- The null pattern should match empty lines if -x.
- The null pattern should not match any lines if -w.

The first two will stop processing (shortcut) even if additional patterns
are specified. In any other case, we will continue processing other
patterns.  If no other patterns are specified beside a null pattern, then
we match if neither -w nor -x or set and do not match if either of those
are specified.

The justification for -w is that it should match on a whole word, but the
null pattern does not have a whole word to match on.

Empty pattern files should never match anything, and more importantly, -v
should cause everything to be written.

PR: 253209
Approved by:re (gjb)

(cherry picked from commit f823c6dc730b0dd08b54a53be1d8fd587eee7021)
(cherry picked from commit 574d0dfae5011a766aa967f1d1675ddf7b535936)

 contrib/netbsd-tests/usr.bin/grep/t_grep.sh | 22 +++---
 usr.bin/grep/grep.c | 11 -
 usr.bin/grep/util.c | 35 +
 3 files changed, 35 insertions(+), 33 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253350] Grep regression with --after-context (-A) and --max-count (-m) switches

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253350

--- Comment #5 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=ad488c9793fd5040f8267620f370f319df31af2d

commit ad488c9793fd5040f8267620f370f319df31af2d
Author: Kyle Evans 
AuthorDate: 2021-02-08 18:31:17 +
Commit: Kyle Evans 
CommitDate: 2021-02-11 15:20:26 +

grep: fix -A handling in conjunction with -m match limitation

The basic issue here is that grep, when given -m 1, would stop all
line processing once it hit the match count and exit immediately.  The
problem with exiting immediately is that -A processing only happens when
subsequent lines are processed and do not match.

The fix here is relatively easy; when bsdgrep matches a line, it resets
the 'tail' of the matching context to the value supplied to -A and
dumps anything that's been queued up for -B. After the current line has
been printed and tail is reset, we check our mcount and do what's
needed. Therefore, at the time that we decide we're doing nothing, we
know that 'tail' of the context is correct and we can simply continue
on if there's still more to pick up.

With this change, we still bail out immediately if there's been no -A
flag. If -A was supplied, we signal that we should continue on. However,
subsequent lines will not even bothere to try and process the line.  We
have reached the match count, so even if the next line would match then
we must process it if it hadn't. Thus, the loop in procfile() can
short-circuit and just process the line as a non-match until
procmatches() indicates that it's safe to stop.

A test has been added to reflect both that we should be picking up the
next line and that the next line should be considered a non-match even
if it should have been.

PR: 253350

(cherry picked from commit 3e2d96ac974db823255a6f40b90eeffa6e38d022)

 contrib/netbsd-tests/usr.bin/grep/t_grep.sh | 17 +
 usr.bin/grep/util.c | 21 -
 2 files changed, 37 insertions(+), 1 deletion(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253209] grep -v -f some-empty-file -- does the wrong thing

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253209

--- Comment #5 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=92ddb6090b0c5091a64855a514676a452c10750c

commit 92ddb6090b0c5091a64855a514676a452c10750c
Author: Kyle Evans 
AuthorDate: 2021-02-04 21:26:45 +
Commit: Kyle Evans 
CommitDate: 2021-02-11 15:19:26 +

grep: fix null pattern and empty pattern file behavior

The null pattern semantics were terrible because I tried to match gnugrep,
but I got it wrong.  Let's unwind that:

- The null pattern should match every line if neither -w nor -x.
- The null pattern should match empty lines if -x.
- The null pattern should not match any lines if -w.

The first two will stop processing (shortcut) even if additional patterns
are specified. In any other case, we will continue processing other
patterns.  If no other patterns are specified beside a null pattern, then
we match if neither -w nor -x or set and do not match if either of those
are specified.

The justification for -w is that it should match on a whole word, but the
null pattern deos not have a whole word to match on.

Empty pattern files should never match anything, and more importantly, -v
should cause everything to be written.

PR: 253209

(cherry picked from commit f823c6dc730b0dd08b54a53be1d8fd587eee7021)

 contrib/netbsd-tests/usr.bin/grep/t_grep.sh | 22 +++---
 usr.bin/grep/grep.c | 11 -
 usr.bin/grep/util.c | 35 +
 3 files changed, 35 insertions(+), 33 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253209] grep -v -f some-empty-file -- does the wrong thing

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253209

Kyle Evans  changed:

   What|Removed |Added

  Flags||mfc-stable13+,
   ||mfc-stable12+,
   ||mfc-stable11-
 Resolution|--- |FIXED
 Status|In Progress |Closed

--- Comment #6 from Kyle Evans  ---
This should be in -BETA2. Thanks for the report!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253350] Grep regression with --after-context (-A) and --max-count (-m) switches

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253350

Kyle Evans  changed:

   What|Removed |Added

 Status|In Progress |Closed
  Flags|mfc-stable13?,  |mfc-stable13+,
   |mfc-stable12?   |mfc-stable12+
 Resolution|--- |FIXED

--- Comment #6 from Kyle Evans  ---
This should be in -BETA2. Thanks for the report!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253288] hwpstate_intel: Wedges under any kind of load on ThinkPad Carbon X1 Gen 8

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253288

--- Comment #13 from Yuri Pankov  ---
Just for the record, I'm not seeing any issues on P51, "Intel(R) Core(TM)
i7-7820HQ CPU @ 2.90GHz".

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253288] hwpstate_intel: Wedges under any kind of load on ThinkPad Carbon X1 Gen 8

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253288

--- Comment #14 from Sreehari S  ---
(In reply to Yuri Pankov from comment #13)
Maybe it only effects intel U processors? That's the only thing I can think of
that the effected people's machines have in common that you don't (you've got
HQ). Again could be completely wrong

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253288] hwpstate_intel: Wedges under any kind of load on ThinkPad Carbon X1 Gen 8

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253288

--- Comment #15 from Sreehari S  ---
(In reply to Sreehari S from comment #14)
I've got an i7-8565U and some hw probes:
http://bsd-hardware.info/?probe=77e80759a0
http://bsd-hardware.info/?probe=8d1c80c2cb

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253435] Jail does not create tunnel (wireguard) interface alias.

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253435

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|j...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253288] hwpstate_intel: Wedges under any kind of load on ThinkPad Carbon X1 Gen 8

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253288

Yuri Pankov  changed:

   What|Removed |Added

 CC||yur...@freebsd.org

--- Comment #16 from Yuri Pankov  ---
(In reply to Sreehari S from comment #14)
I also have Intel NUC7i7BNH featuring "Intel(R) Core(TM) i7-7567U CPU", and I
don't remember seeing any issues with it either.  The system does not have any
storage device at the moment, but I'll get one shortly and re-check to confirm
(or disprove) the U series guess.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 243174] mq_unlink(3) manual page is missing

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243174

Fernando ApesteguĂ­a  changed:

   What|Removed |Added

 CC||fern...@freebsd.org
   Assignee|b...@freebsd.org|fern...@freebsd.org
 Status|Open|In Progress

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253440] dtrace failing to resolve some fbt probe argument types

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253440

Mark Johnston  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|ma...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253440] dtrace failing to resolve some fbt probe argument types

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253440

Bug ID: 253440
   Summary: dtrace failing to resolve some fbt probe argument
types
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: ma...@freebsd.org

We have:

> dtrace -lv -n fbt::ifa_alloc:entry
   ID   PROVIDERMODULE  FUNCTION NAME
52703fbtkernel ifa_alloc entry

Probe Description Attributes
Identifier Names: Private
Data Semantics:   Private
Dependency Class: Unknown

Argument Attributes
Identifier Names: Private
Data Semantics:   Private
Dependency Class: ISA

Argument Types
args[0]: (unknown)
args[1]: int

But:

> ctfdump -f /boot/kernel/kernel | grep ifa_alloc
  [28508] FUNC (ifa_alloc) returns: 533 args: (35, 66)
> ctfdump -t /boot/kernel/kernel | grep -B3 '<35>'
  <32> INTEGER unsigned long encoding=0x0 offset=0 bits=64
  <33> TYPEDEF __uint64_t refers to 32
  <34> TYPEDEF __size_t refers to 33
  <35> TYPEDEF size_t refers to 34

So the type info is there.  DTRACE_DEBUG shows

libdtrace DEBUG: discovering probe fbt:kernel:ifa_alloc:entry id=52703
libdtrace DEBUG: failed to resolve input type size_t for
fbt:kernel:ifa_alloc:entry arg #1: syntax error near "

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253288] hwpstate_intel: Wedges under any kind of load on ThinkPad Carbon X1 Gen 8

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253288

--- Comment #17 from Sreehari S  ---
(In reply to Yuri Pankov from comment #16)
>From what I can tell only Lenovo/thinkpad users have complained about this bug,
though it's worth checking out if it affects all U processors or something. In
all likeliness it could be some differences in MSR writes through some edge
case not covered in FreeBSD that is covered in linux and others. I tried
checking for deadlocks in the new code through printf debugging (that's all I
know) and I couldn't find any myself, but I'm no expert so I wouldn't
completely rule that out unless someone else can confirm.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253288] hwpstate_intel: Wedges under any kind of load on ThinkPad Carbon X1 Gen 8

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253288

--- Comment #18 from Sreehari S  ---
(In reply to Sreehari S from comment #17)
I might try to wrap my head around remote gdb or ddb or even trying to find
crash dumps if they're created, but I'm not too familiar with all that yet.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253251] Hardware Revision Realtek 8117

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253251

Christian Gutzler  changed:

   What|Removed |Added

 CC||christiangutz...@gmail.com

--- Comment #1 from Christian Gutzler  ---
Created attachment 222373
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=222373&action=edit
Patch

My first patch ever, hope I did everything right.
Please review.

THX

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253251] Hardware Revision Realtek 8117

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253251

--- Comment #2 from Christian Gutzler  ---
Comment on attachment 222373
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=222373
Patch

My first patch ever. Hope I did everything right. Pls review. THX. Christian

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253445] bectl: does not function in two-level zfs datasets

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253445

Bug ID: 253445
   Summary: bectl: does not function in two-level zfs datasets
   Product: Base System
   Version: 12.2-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: do...@dawnsign.com

I used mfsbsd to set up default datasets. If using non-raid, by default, mfsbsd
formats its zfs datasets for a single disk as follows:

Filesystem 1K-blocks Used Avail Capacity Mounted on
tank/root 302305222 9711156 292594065 3% /
devfs 1 1 0 100% /dev
tank/root/tmp 292594102 37 292594065 0% /tmp
tank/root/var 292924432 330366 292594065 0% /var

When I attempt to list bootable environments, it comes back empty.

[root@squid 11.Feb 12:20pm /usr]# bectl list
[root@squid 11.Feb 12:20pm /usr]#

bectl check does not return anything:

[root@squid 11.Feb 12:20pm /usr]# bectl check
[root@squid 11.Feb 12:20pm /usr]#

I would like to implement boot environments using two level datasets.

Is the three level datasets a requirement for using bectl?

See
https://forums.freebsd.org/threads/boot-environments-with-non-standard-dataset-layout-and-bectl-beadm.74925/
for additional details.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253445] bectl: does not function in two-level zfs datasets

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253445

Wes Maag  changed:

   What|Removed |Added

 CC||jwm...@gmail.com

--- Comment #1 from Wes Maag  ---
(In reply to do...@dawnsign.com from comment #0)

Out of curiosity, what happens if you specify the root as tank?

i.e bectl -r tank list?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253445] bectl: does not function in two-level zfs datasets

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253445

--- Comment #2 from do...@dawnsign.com  ---
[root@squid 11.Feb 12:32pm /]# bectl -r tank list
[root@squid 11.Feb 2:36pm /]#

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253445] bectl: does not function in two-level zfs datasets

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253445

--- Comment #3 from do...@dawnsign.com  ---
Out of curiosity, I did this:

[root@squid 11.Feb 2:36pm /usr]# bectl -r tank/root list
BE  Active Mountpoint Space Created
tmp -  /tmp   58K   2021-02-06 13:49
var -  /var   336M  2021-02-06 13:49
[root@squid 11.Feb 2:37pm /usr]#

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253445] bectl: does not function in two-level zfs datasets

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253445

--- Comment #4 from Wes Maag  ---
Created attachment 222379
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=222379&action=edit
diff to allow the pool dataset to be the BE root when specified

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 253445] bectl: does not function in two-level zfs datasets

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253445

--- Comment #5 from Wes Maag  ---
Yeah, libbe really wants there to be at least two levels. It checks for the
existence of a '/' in the root name and errors out if it does not exist.

Attached is a diff that I scratched together which seems to work

works[wes]:/home/wes $ zfs list -r test
   
   
[16:27:06]
NAME USED  AVAIL REFER  MOUNTPOINT
test 246K   832M   24K  none
test/root124K   832M   24K  /tmp/bectl_test_75GY
test/root224K   832M   24K  /tmp/bectl_test_75GY

works[wes]:/home/wes $ bectl -r test list  
   
   
[16:16:30]
BEActive Mountpoint Space Created
root1 -  -  24K   2021-02-11 15:46
root2 -  -  24K   2021-02-11 15:46

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 252132] mergemaster: needs to cope with empty $FreeBSD$ tags or /etc files must have $FreeBSD: number$

2021-02-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252132

Katsuyuki Miyoshi  changed:

   What|Removed |Added

 CC||katsu...@gmail.com

--- Comment #3 from Katsuyuki Miyoshi  ---
Created attachment 222381
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=222381&action=edit
id_tools.tar.gz

This is my personal solution.

My solution is to replace "$FreeBSD$" with "$FreeBSD: MD5 $".
(MD5 is the MD5 checksum of the source file.)

"$FreeBSD: MD5 $" is not the original "$FreeBSD$" format, but it is useful
enough for mergemaster.

I'm happy with these. However, I don't know if these are enough for everyone
who does various tasks. And, I don't even know what will happen to "$FreeBSD$"
in the future.

I hope that a better response will be made.

Here are the steps:

===
[Provides 3 files]
 replace_id.sh: This is a script that replaces "$FreeBSD ... $" in files
installed by "make distribution" with "$FreeBSD: MD5 $".

 src_id.sh: This is a git filter script.

 post-commit: This is a git hook script.

--
[0] Start with the mergemaster completed by the traditional way.
 It doesn't matter if you use a subversion repository, a git repository, or any
revision of the source files. 

--
[1-1] Backup the files installed by "make distribution" (That is, /etc/*,
/root/*, and /boot/device.hints)
 It's not mandatory to do this, but I recommend that you back up your /etc,
/root, /boot/device.hints files so that you can restore them in case of an
accident.

[1-2] # sh replace_id.sh
   Make sure the SOURCEDIR and DESTDIR in replace_id.sh are correct and run
replace_id.sh.

With the above, "$FreeBSD ... $" in files installed by "make distribution" will
be replaced with "$FreeBSD: MD5 $". Make sure those files are not corrupted.

--
[2-1] Now let /usr/src be the new git repository.

[2-2] Install "src_id.sh" in the appropriate directory in the ${PATH}. (ex:
/usr/local/bin/src_id.sh)

And, in the git repository:

[2-3] # git config filter.src_id.smudge 'src_id.sh add'
[2-4] # git config filter.src_id.clean 'src_id.sh del'
[2-5] # echo '* filter=src_id' >> .git/info/attributes
[2-6] (After checking that your post-commit file doesn't exist in .git/hooks)
  # /bin/cp post-commit .git/hooks

[2-7] # git ls-files -z | /usr/bin/xargs -0 /bin/rm -f
[2-8] # git checkout -f

>From now on, even if you update the source files, mergemaster will work fine.
--
[Notes]
When you first run mergemaster after the above work, you will be asked to merge
the following four files.

/etc/mail/freebsd.cf
/etc/mail/freebsd.submit.cf
/etc/mail/sendmail.cf
/etc/mail/submit.cf

For these, please merge at that time.
(This is because replace_id.sh doesn't support cases for those files.)
===

That's all. Thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"