[Bug 237517] ZFS parallel mounting sometimes misses mounting intermediate filesystems

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237517

Bug ID: 237517
   Summary: ZFS parallel mounting sometimes misses mounting
intermediate filesystems
   Product: Base System
   Version: 12.0-STABLE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: trond.endres...@ximalas.info

Both Jim Long and myself experience ZFS parallel mount misses mounting
intermediate filesystems.

As far as I can tell, this behaviour is not deterministic, sometimes the
parallel mounting succeeds and sometimes it doesn't.

See these threads,
https://lists.freebsd.org/pipermail/freebsd-stable/2019-April/090898.html and
https://lists.freebsd.org/pipermail/freebsd-questions/2019-April/284974.html.

Here are a couple of suggestions:

Can we make parallel mounting optional for us that don't need it or want it?
Or, can parallel mounting be changed so that filesystems off the root pool is
completely mounted before all other pools?

This still leaves the possibility of the kernel attempting to mount pool/a/b
before pool/a, even if both filesystems have their canmount properties set to
on, and one being a child of the other.

-- 
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 237447] make buildworld: linker failure on i386 platform

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237447

--- Comment #7 from o...@oz42.eu ---
# ld --version
LLD 6.0.1 (FreeBSD 335540-125) (compatible with GNU linkers)
# make -V LINKER_TYPE
lld

What I have found in the src.conf manpage:
 WITH_LLD_IS_LD
 Set to use LLVM's LLD as the system linker, instead of GNU
 binutils ld.

 This is a default setting on amd64/amd64, arm/armv7 and
 arm64/aarch64.

So this is not default on i386?

-- 
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 237523] freebsd-update erroneously reports EOL for FreeBSD 11.2

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237523

Bug ID: 237523
   Summary: freebsd-update erroneously reports EOL for FreeBSD
11.2
   Product: Base System
   Version: 11.2-STABLE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: m...@matthoran.com

I run freebsd-update cron on a nightly basis. A couple of times this month I
have gotten the following notice by email:

WARNING: FreeBSD 11.2-RELEASE-p9 is approaching its End-of-Life date.

However, so far as I can tell, 11.2 is not EOL. A subsequent manual run of
freebsd-update fetch will not report that 11.2 is reaching its EOL date.

The date and time on the machine seem to be set correctly. They are the same as
on other machines that do not display the message.

-- 
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 237523] freebsd-update erroneously reports EOL for FreeBSD 11.2

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237523

Kubilay Kocak  changed:

   What|Removed |Added

 CC||cperc...@freebsd.org
   Keywords||needs-qa
 Status|New |Open
   Severity|Affects Only Me |Affects Some People
  Flags||maintainer-feedback?(cperci
   ||v...@freebsd.org)

--- Comment #1 from Kubilay Kocak  ---
I believe the key is "approaching" end-of-life, is displayed within a certain
window approaching the End-of-Life date, and is intended behaviour. The system
has not reached the EoL date yet.

The 11.3-RELEASE schedule has been published here:

https://www.freebsd.org/releases/11.3R/schedule.html

If there are suggestions for improving the messaging so that is it clearer that
the warning is *not* that the system has *reached* End-of-Life yet, we're happy
to consider those changes.

-- 
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 237523] freebsd-update erroneously reports EOL for FreeBSD 11.2

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237523

--- Comment #2 from Matthew Horan  ---
(In reply to Kubilay Kocak from comment #1)

That was my initial thought as well (the first time I saw the message, I
noticed that 11.3 was imminent.) However, the behavior is not consistent. I
just ran freebsd-update fetch, and it did not say anything about EOL
approaching. I also run the same command via cron every night, and it only
periodically (maybe every few weeks) says that EOL is approaching.

If that's the intent then no problem -- I am just more concerned about the
inconsistency.

-- 
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 237523] freebsd-update erroneously reports EOL for FreeBSD 11.2

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237523

--- Comment #3 from Matthew Horan  ---
(In reply to Matthew Horan from comment #2)

Okay, it seems that the inconsistency is purposeful, as per [1].

Regardless, it's a bit surprising to be warned of an approaching EOL when 11.3
has not yet been released. According to [2], FreeBSD 11.2 will be supported
until the release of 11.3 + 3 months. According to [3] I shouldn't be warned
outside of 3 months of EOL, so there seems to be a bug in the data source that
freebsd-update is using for this warning.

[1]
https://svnweb.freebsd.org/base/stable/11/usr.sbin/freebsd-update/freebsd-update.sh?view=markup#l2063
[2] https://www.freebsd.org/security/#sup
[3]
https://svnweb.freebsd.org/base/stable/11/usr.sbin/freebsd-update/freebsd-update.sh?view=markup#l2058

-- 
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 234209] regression: audit_warn(5) loops indefinitely if script /etc/security/audit_warn takes longer than 0.87s to execute

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234209

--- Comment #1 from Marie Helene Kvello-Aune  ---
For information: This bug still exists with 12.0-RELEASE-p3 and 13-CURRENT
r346594.

Complete reproduction example: (this will overwrite /etc/security/audit_warn)
at << EOF >/etc/security/audit_warn

#!/bin/sh  
   
echo "audit warning: $@" | wall
   
sleep 1
EOF 

# audit -n

expected behaviour: For the script to be executed once
actual behaviour: script is repeatedly executed, seemingly forever.
Remove "sleep 1" from the above script and it's called exactly one.

Real-world case: actions performed by this script take more than 1s to do their
thing, and end up being called repeatedly for the same message.

-- 
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 236961] [VFS] vfs_bio_getpages: infinite loop

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236961

--- Comment #6 from Alexandre martins  ---
Hello,

The problem disappear when I put the /tmp folder (via symlink) in the same
partition than /home (where the build run)

To recap my disk configuration:
 - the build (source + objects) runs on /home partition
 - the /tmp is on the same disk as /home, but before (/tmp is quicker than
/home)
 - Both /home and /tmp are "async + noatime"
 - I use ccache (but seems not relevant)
 - The swap is not the problem (freeze occurs when I disable it)
 - When /tmp is a symlink to a folder in /home, the problem disappear.

-- 
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 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #280 from Sara Taylor  ---
root@asbach:/var/crash/#kgdb7121 /boot/kernel/kernel /var/crash/vmcore.3
GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Reading symbols from /boot/kernel/vmm.ko...Reading symbols from
/usr/lib/debug//boot/kernel/vmm.ko.debug...done.
done.
Reading symbols from /boot/kernel/ums.ko...Reading symbols from
/usr/lib/debug//boot/kernel/ums.ko.debug...done.
done.
Reading symbols from /boot/kernel/pflog.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pflog.ko.debug...done.
done.
Reading symbols from /boot/kernel/pf.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pf.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux64.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux64.ko.debug...done.
done.
Reading symbols from /boot/modules/nvidia.ko...(no debugging symbols
found)...done.
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/nullfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linprocfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/tmpfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/fdescfs.ko.debug...done.
done.
No thread selected.
(kgdb) info threads
No threads.


I'm using KDE all the time; and when the crash happens the screen garbles a
little bit, and after a while my system reboots - please give me some more time
to build a DDB-enabled kernel and switch to the VT console


when the crash happens the screen garbles a little bit, and after a while my
system reboots - please give me some more time to build a DDB-enabled kernel
and switch to the VT console

-- 
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 237271] Radeon video card no longer works on 12-STABLE (after r345105) / CURRENT (after r345932)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237271

Johannes Lundberg  changed:

   What|Removed |Added

 CC||joha...@freebsd.org

--- Comment #4 from Johannes Lundberg  ---
Hi

The port needs to be updated. Latest version in git repo should be working:

https://github.com/FreeBSDDesktop/kms-drm/tree/drm-v4.16-fbsd12.0

-- 
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 237271] Radeon video card no longer works on 12-STABLE (after r345105) / CURRENT (after r345932)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237271

--- Comment #5 from rozhuk...@gmail.com ---
(In reply to Johannes Lundberg from comment #4)

I think should not.

4.16.g20190305 = git commit 4192575 = "lkpi: Allow recursive calls to
i2c_transfer"

I see no commit after this that affect driver initialization or sysctl() code.


PS:
https://github.com/FreeBSDDesktop/kms-drm/commit/b5ef47b82bbcd127f82b60f40b3efd3f065cf756
probably this should be fixed in linuxkpi code, some where in
sysctl_handle_attr() / sysctl_root_handler_locked(), zero buffer on error, this
will prevent many bugs in other places.

-- 
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 237271] Radeon video card no longer works on 12-STABLE (after r345105) / CURRENT (after r345932)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237271

--- Comment #6 from Johannes Lundberg  ---
https://github.com/FreeBSDDesktop/kms-drm/commit/70ef5ae8f30f8734bd8c85b41d30c23ef956d78b

-- 
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 237271] Radeon video card no longer works on 12-STABLE (after r345105) / CURRENT (after r345932)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237271

--- Comment #7 from Johannes Lundberg  ---
It has been fixed in linuxkpi which is why it fails. Before it was silently
failing. Drivers needs to be updated to do things correctly.

-- 
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 237538] [patch] cron: add log suppression and mail suppression for successful runs

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237538

Bug ID: 237538
   Summary: [patch] cron: add log suppression and mail suppression
for successful runs
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: free...@t.lastninja.net

Created attachment 203978
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203978&action=edit
Add crontab support for -q (log suppression) and -n (mail suppression for
successful run).

I would like to see FreeBSD provide the crontab extensions found in OpenBSD
that implement `-n` to suppress mail on successful run and ``q` to suppress
logging of command execution.

The `-q` option appears decades old, but the `-n` is relatively new. The
original proposal by Job Snijder can be found here [1], and gives very
convincing reasons for inclusion in base.

This patch is a nearly identical port of OpenBSD cron for `-q` and `-n`
features. It is written to follow existing conventions and style of the
existing codebase. I'm also not good at writing manpages but I gave it my best
shot.


[1]: https://marc.info/?l=openbsd-tech&m=152874866117948&w=2

-- 
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 237538] [patch] cron: add log suppression and mail suppression for successful runs

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237538

--- Comment #1 from Naveen Nathan  ---
Comment on attachment 203978
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203978
Add crontab support for -q (log suppression) and -n (mail suppression for
successful run).

diff --git a/usr.sbin/cron/cron/cron.h b/usr.sbin/cron/cron/cron.h
index bb4f5287daea..f0f9e88d6b59 100644
--- a/usr.sbin/cron/cron/cron.h
+++ b/usr.sbin/cron/cron/cron.h
@@ -191,6 +191,8 @@ typedef struct _entry {
 #defineNOT_UNTIL   0x10
 #defineSEC_RES 0x20
 #defineINTERVAL0x40
+#defineDONT_LOG0x80
+#defineMAIL_WHEN_ERR   0x100
time_t  lastrun;
 } entry;

@@ -257,7 +259,7 @@ user*load_user(int, struct passwd *, char
*),
 entry  *load_entry(FILE *, void (*)(char *),
 struct passwd *, char **);

-FILE   *cron_popen(char *, char *, entry *);
+FILE   *cron_popen(char *, char *, entry *, PID_T *);


/* in the C tradition, we only create
diff --git a/usr.sbin/cron/cron/do_command.c b/usr.sbin/cron/cron/do_command.c
index 13d14e442a27..93e3f4311ebe 100644
--- a/usr.sbin/cron/cron/do_command.c
+++ b/usr.sbin/cron/cron/do_command.c
@@ -41,6 +41,7 @@ static const char rcsid[] =
 static voidchild_process(entry *, user *),
do_univ(user *);

+static WAIT_T  wait_on_child(PID_T, char *);

 void
 do_command(e, u)
@@ -94,7 +95,12 @@ child_process(e, u)
int stdin_pipe[2], stdout_pipe[2];
register char   *input_data;
char*usernm, *mailto, *mailfrom;
-   int children = 0;
+   PID_T   jobpid, stdinjob, mailpid;
+
+   register FILE   *mail;
+   register intbytes = 1;
+   int status = 0;
+
 # if defined(LOGIN_CAP)
struct passwd   *pwd;
login_cap_t *lc;
@@ -216,7 +222,8 @@ child_process(e, u)

/* fork again, this time so we can exec the user's command.
 */
-   switch (vfork()) {
+
+   switch (jobpid = vfork()) {
case -1:
log_it("CRON",getpid(),"error","can't vfork");
exit(ERROR_EXIT);
@@ -237,7 +244,7 @@ child_process(e, u)
 * the actual user command shell was going to get and the
 * PID is part of the log message.
 */
-   /*local*/{
+   if ((e->flags & DONT_LOG) == 0) {
char *x = mkprints((u_char *)e->cmd, strlen(e->cmd));

log_it(usernm, getpid(), "CMD", x);
@@ -359,8 +366,6 @@ child_process(e, u)
break;
}

-   children++;
-
/* middle process, child of original cron, parent of process running
 * the user's command.
 */
@@ -384,7 +389,7 @@ child_process(e, u)
 * we would block here.  thus we must fork again.
 */

-   if (*input_data && fork() == 0) {
+   if (*input_data && (stdinjob = fork()) == 0) {
register FILE   *out = fdopen(stdin_pipe[WRITE_PIPE], "w");
register intneed_newline = FALSE;
register intescaped = FALSE;
@@ -440,8 +445,6 @@ child_process(e, u)
 */
close(stdin_pipe[WRITE_PIPE]);

-   children++;
-
/*
 * read output from the grandchild.  it's stderr has been redirected to
 * it's stdout, which has been redirected to our pipe.  if there is any
@@ -462,10 +465,6 @@ child_process(e, u)

ch = getc(in);
if (ch != EOF) {
-   register FILE   *mail;
-   register intbytes = 1;
-   int status = 0;
-
Debug(DPROC|DEXT,
("[%d] got data (%x:%c) from grandchild\n",
getpid(), ch, ch))
@@ -500,7 +499,7 @@ child_process(e, u)
hostname[sizeof(hostname) - 1] = '\0';
(void) snprintf(mailcmd, sizeof(mailcmd),
   MAILARGS, MAILCMD);
-   if (!(mail = cron_popen(mailcmd, "w", e))) {
+   if (!(mail = cron_popen(mailcmd, "w", e,
&mailpid))) {
warn("%s", MAILCMD);
(void) _exit(ERROR_EXIT);
}
@@ -538,28 +537,54 @@ child_process(e, u)
if (mailto)
putc(ch, mail);
}
+   } /*if data from grandchild*/

-   /* only close pipe if we opened it -- i.e., we're
-* mailing...
-*/
+   Debug(DPROC, ("[%d] got EOF from grandch

[Bug 237538] [patch] cron: add log suppression and mail suppression for successful runs

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237538

--- Comment #2 from Naveen Nathan  ---
Comment on attachment 203978
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203978
Add crontab support for -q (log suppression) and -n (mail suppression for
successful run).

diff --git a/usr.sbin/cron/cron/cron.h b/usr.sbin/cron/cron/cron.h
index bb4f5287daea..f0f9e88d6b59 100644
--- a/usr.sbin/cron/cron/cron.h
+++ b/usr.sbin/cron/cron/cron.h
@@ -191,6 +191,8 @@ typedef struct _entry {
 #defineNOT_UNTIL   0x10
 #defineSEC_RES 0x20
 #defineINTERVAL0x40
+#defineDONT_LOG0x80
+#defineMAIL_WHEN_ERR   0x100
time_t  lastrun;
 } entry;

@@ -257,7 +259,7 @@ user*load_user(int, struct passwd *, char
*),
 entry  *load_entry(FILE *, void (*)(char *),
 struct passwd *, char **);

-FILE   *cron_popen(char *, char *, entry *);
+FILE   *cron_popen(char *, char *, entry *, PID_T *);


/* in the C tradition, we only create
diff --git a/usr.sbin/cron/cron/do_command.c b/usr.sbin/cron/cron/do_command.c
index 13d14e442a27..93e3f4311ebe 100644
--- a/usr.sbin/cron/cron/do_command.c
+++ b/usr.sbin/cron/cron/do_command.c
@@ -41,6 +41,7 @@ static const char rcsid[] =
 static voidchild_process(entry *, user *),
do_univ(user *);

+static WAIT_T  wait_on_child(PID_T, char *);

 void
 do_command(e, u)
@@ -94,7 +95,12 @@ child_process(e, u)
int stdin_pipe[2], stdout_pipe[2];
register char   *input_data;
char*usernm, *mailto, *mailfrom;
-   int children = 0;
+   PID_T   jobpid, stdinjob, mailpid;
+
+   register FILE   *mail;
+   register intbytes = 1;
+   int status = 0;
+
 # if defined(LOGIN_CAP)
struct passwd   *pwd;
login_cap_t *lc;
@@ -216,7 +222,8 @@ child_process(e, u)

/* fork again, this time so we can exec the user's command.
 */
-   switch (vfork()) {
+
+   switch (jobpid = vfork()) {
case -1:
log_it("CRON",getpid(),"error","can't vfork");
exit(ERROR_EXIT);
@@ -237,7 +244,7 @@ child_process(e, u)
 * the actual user command shell was going to get and the
 * PID is part of the log message.
 */
-   /*local*/{
+   if ((e->flags & DONT_LOG) == 0) {
char *x = mkprints((u_char *)e->cmd, strlen(e->cmd));

log_it(usernm, getpid(), "CMD", x);
@@ -359,8 +366,6 @@ child_process(e, u)
break;
}

-   children++;
-
/* middle process, child of original cron, parent of process running
 * the user's command.
 */
@@ -384,7 +389,7 @@ child_process(e, u)
 * we would block here.  thus we must fork again.
 */

-   if (*input_data && fork() == 0) {
+   if (*input_data && (stdinjob = fork()) == 0) {
register FILE   *out = fdopen(stdin_pipe[WRITE_PIPE], "w");
register intneed_newline = FALSE;
register intescaped = FALSE;
@@ -440,8 +445,6 @@ child_process(e, u)
 */
close(stdin_pipe[WRITE_PIPE]);

-   children++;
-
/*
 * read output from the grandchild.  it's stderr has been redirected to
 * it's stdout, which has been redirected to our pipe.  if there is any
@@ -462,10 +465,6 @@ child_process(e, u)

ch = getc(in);
if (ch != EOF) {
-   register FILE   *mail;
-   register intbytes = 1;
-   int status = 0;
-
Debug(DPROC|DEXT,
("[%d] got data (%x:%c) from grandchild\n",
getpid(), ch, ch))
@@ -500,7 +499,7 @@ child_process(e, u)
hostname[sizeof(hostname) - 1] = '\0';
(void) snprintf(mailcmd, sizeof(mailcmd),
   MAILARGS, MAILCMD);
-   if (!(mail = cron_popen(mailcmd, "w", e))) {
+   if (!(mail = cron_popen(mailcmd, "w", e,
&mailpid))) {
warn("%s", MAILCMD);
(void) _exit(ERROR_EXIT);
}
@@ -538,28 +537,54 @@ child_process(e, u)
if (mailto)
putc(ch, mail);
}
+   } /*if data from grandchild*/

-   /* only close pipe if we opened it -- i.e., we're
-* mailing...
-*/
+   Debug(DPROC, ("[%d] got EOF from grandch

[Bug 237538] [patch] cron: add log suppression and mail suppression for successful runs

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237538

--- Comment #3 from Naveen Nathan  ---
Comment on attachment 203978
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203978
Add crontab support for -q (log suppression) and -n (mail suppression for
successful run).

diff --git a/usr.sbin/cron/cron/cron.h b/usr.sbin/cron/cron/cron.h
index bb4f5287daea..f0f9e88d6b59 100644
--- a/usr.sbin/cron/cron/cron.h
+++ b/usr.sbin/cron/cron/cron.h
@@ -191,6 +191,8 @@ typedef struct _entry {
 #defineNOT_UNTIL   0x10
 #defineSEC_RES 0x20
 #defineINTERVAL0x40
+#defineDONT_LOG0x80
+#defineMAIL_WHEN_ERR   0x100
time_t  lastrun;
 } entry;

@@ -257,7 +259,7 @@ user*load_user(int, struct passwd *, char
*),
 entry  *load_entry(FILE *, void (*)(char *),
 struct passwd *, char **);

-FILE   *cron_popen(char *, char *, entry *);
+FILE   *cron_popen(char *, char *, entry *, PID_T *);


/* in the C tradition, we only create
diff --git a/usr.sbin/cron/cron/do_command.c b/usr.sbin/cron/cron/do_command.c
index 13d14e442a27..b54297c02cb2 100644
--- a/usr.sbin/cron/cron/do_command.c
+++ b/usr.sbin/cron/cron/do_command.c
@@ -41,6 +41,7 @@ static const char rcsid[] =
 static voidchild_process(entry *, user *),
do_univ(user *);

+static WAIT_T  wait_on_child(PID_T, char *);

 void
 do_command(e, u)
@@ -94,7 +95,12 @@ child_process(e, u)
int stdin_pipe[2], stdout_pipe[2];
register char   *input_data;
char*usernm, *mailto, *mailfrom;
-   int children = 0;
+   PID_T   jobpid, stdinjob, mailpid;
+
+   register FILE   *mail;
+   register intbytes = 1;
+   int status = 0;
+
 # if defined(LOGIN_CAP)
struct passwd   *pwd;
login_cap_t *lc;
@@ -216,7 +222,8 @@ child_process(e, u)

/* fork again, this time so we can exec the user's command.
 */
-   switch (vfork()) {
+
+   switch (jobpid = vfork()) {
case -1:
log_it("CRON",getpid(),"error","can't vfork");
exit(ERROR_EXIT);
@@ -237,7 +244,7 @@ child_process(e, u)
 * the actual user command shell was going to get and the
 * PID is part of the log message.
 */
-   /*local*/{
+   if ((e->flags & DONT_LOG) == 0) {
char *x = mkprints((u_char *)e->cmd, strlen(e->cmd));

log_it(usernm, getpid(), "CMD", x);
@@ -359,8 +366,6 @@ child_process(e, u)
break;
}

-   children++;
-
/* middle process, child of original cron, parent of process running
 * the user's command.
 */
@@ -384,7 +389,9 @@ child_process(e, u)
 * we would block here.  thus we must fork again.
 */

-   if (*input_data && fork() == 0) {
+   stdinjob = 0;
+
+   if (*input_data && (stdinjob = fork()) == 0) {
register FILE   *out = fdopen(stdin_pipe[WRITE_PIPE], "w");
register intneed_newline = FALSE;
register intescaped = FALSE;
@@ -440,8 +447,6 @@ child_process(e, u)
 */
close(stdin_pipe[WRITE_PIPE]);

-   children++;
-
/*
 * read output from the grandchild.  it's stderr has been redirected to
 * it's stdout, which has been redirected to our pipe.  if there is any
@@ -462,10 +467,6 @@ child_process(e, u)

ch = getc(in);
if (ch != EOF) {
-   register FILE   *mail;
-   register intbytes = 1;
-   int status = 0;
-
Debug(DPROC|DEXT,
("[%d] got data (%x:%c) from grandchild\n",
getpid(), ch, ch))
@@ -500,7 +501,7 @@ child_process(e, u)
hostname[sizeof(hostname) - 1] = '\0';
(void) snprintf(mailcmd, sizeof(mailcmd),
   MAILARGS, MAILCMD);
-   if (!(mail = cron_popen(mailcmd, "w", e))) {
+   if (!(mail = cron_popen(mailcmd, "w", e,
&mailpid))) {
warn("%s", MAILCMD);
(void) _exit(ERROR_EXIT);
}
@@ -538,28 +539,54 @@ child_process(e, u)
if (mailto)
putc(ch, mail);
}
+   } /*if data from grandchild*/

-   /* only close pipe if we opened it -- i.e., we're
-* mailing...
-*/
+   Debug(DPROC, ("[

[Bug 237271] Radeon video card no longer works on 12-STABLE (after r345105) / CURRENT (after r345932)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237271

--- Comment #8 from rozhuk...@gmail.com ---
(In reply to Johannes Lundberg from comment #7)

Ok, I will test in next few days.
I was thinking that main goal of linuxkpi (like webcamd) is minimizing patch
size for linux drivers.

-- 
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 237538] [patch] cron: add log suppression and mail suppression for successful runs

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237538

Naveen Nathan  changed:

   What|Removed |Added

 Attachment #203978|0   |1
is obsolete||

--- Comment #4 from Naveen Nathan  ---
Created attachment 203979
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203979&action=edit
Add crontab support for -q (log suppression) and -n (mail suppression for
successful run).

Two fixes to the original patch:

1. stdinjob wasn't being reaped because of a bad condition.

2. proc debug output when reaping the command and stdin job grandchilds is now
consistent with how it was done originally.

-- 
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 237538] [patch] cron: add log suppression and mail suppression for successful runs

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237538

Mark Linimon  changed:

   What|Removed |Added

   Keywords||patch

-- 
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 237517] ZFS parallel mounting sometimes misses mounting intermediate filesystems

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237517

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|f...@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 237538] [patch] cron: add log suppression and mail suppression for successful runs

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237538

Naveen Nathan  changed:

   What|Removed |Added

 Attachment #203979|0   |1
is obsolete||

--- Comment #5 from Naveen Nathan  ---
Created attachment 203994
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203994&action=edit
Add crontab support for -q (log suppression) and -n (mail suppression for
successful run).

Added a more useful example for -n in crontab(5).

-- 
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 237544] panic on 12-STABLE with Radeon HD 7450 under drm-fbsd12.0-kmod but not drm-fbsd11.2-kmod

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237544

Bug ID: 237544
   Summary: panic on 12-STABLE with Radeon HD 7450 under
drm-fbsd12.0-kmod but not drm-fbsd11.2-kmod
   Product: Base System
   Version: 12.0-STABLE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: sig...@gmail.com

I have a computer with a Radeon HD 7450 that panics when using the
drm-fbsd12.0-kmod driver but works OK with the drm-fbsd11.2-kmod one.  It
usually takes a few days to panic (after which I revert it to the older kmod). 
Can't tell if it's doing something in particular that triggers it (but that's
with browsers and media players always opened).  It did this under 12.0-RELEASE
as well.  I tried the newer kmod after upgrading to 12-STABLE to see if that
fixed it, but it still panics.

That's with radeonkms. amdgpu doesn't work with it (loading it does not
recognize any video card it seems).  I did not have the xf86-video-ati or
xf86-video-amdgpu Xorg drivers installed.  I take it they are not needed
anymore?

Also oddly enough the screen has a bright gray background after the module
loads.  The text is still readable but very difficult to read. It fixes itself
after starting Xorg (then switching back to a console VT has a black
background).

[66314]
[66314]
[66314] Fatal trap 12: page fault while in kernel mode
[66314] cpuid = 3; apic id = 03
[66314] fault virtual address   = 0x0
[66314] fault code  = supervisor write data  , page not present
[66314] instruction pointer = 0x20:0x8334d93c
[66314] stack pointer   = 0x28:0xfe004132b610
[66314] frame pointer   = 0x28:0xfe004132b640
[66314] code segment= base 0x0, limit 0xf, type 0x1b
[66314] = DPL 0, pres 1, long 1, def32 0, gran 1
[66314] processor eflags= interrupt enabled, resume, IOPL = 3
[66314] current process = 23751 (X:rcs0)
[66314] trap number = 12
[66314] panic: page fault
[66314] cpuid = 3
[66314] time = 1555971829
[66314] KDB: stack backtrace:
[66314] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe004132b2c0
[66314] vpanic() at vpanic+0x19d/frame 0xfe004132b310
[66314] panic() at panic+0x43/frame 0xfe004132b370
[66314] trap_fatal() at trap_fatal+0x394/frame 0xfe004132b3d0
[66314] trap_pfault() at trap_pfault+0x49/frame 0xfe004132b430
[66314] trap() at trap+0x29f/frame 0xfe004132b540
[66314] calltrap() at calltrap+0x8/frame 0xfe004132b540
[66314] --- trap 0xc, rip = 0x8334d93c, rsp = 0xfe004132b610, rbp =
0xfe004132b640 ---
[66314] rb_erase_color() at rb_erase_color+0x8c/frame
0xfe004132b640
[66314] drm_mm_remove_node() at drm_mm_remove_node+0x2bc/frame
0xfe004132b680
[66314] ttm_bo_man_put_node() at ttm_bo_man_put_node+0x3c/frame
0xfe004132b6a0
[66314] ttm_bo_cleanup_refs_or_queue() at
ttm_bo_cleanup_refs_or_queue+0x202/frame 0xfe004132b6f0
[66314] ttm_bo_unref() at ttm_bo_unref+0x7e/frame 0xfe004132b720
[66314] radeon_bo_unref() at radeon_bo_unref+0x22/frame 0xfe004132b740
[66314] radeon_gem_object_free() at radeon_gem_object_free+0x1e/frame
0xfe004132b760
[66314] drm_gem_object_release_handle() at
drm_gem_object_release_handle+0xd3/frame 0xfe004132b790
[66314] drm_gem_handle_delete() at drm_gem_handle_delete+0x8c/frame
0xfe004132b7d0
[66314] drm_ioctl_kernel() at drm_ioctl_kernel+0xf5/frame 0xfe004132b820
[66314] drm_ioctl() at drm_ioctl+0x27f/frame 0xfe004132b910
[66314] linux_file_ioctl() at linux_file_ioctl+0x298/frame 0xfe004132b970
[66314] kern_ioctl() at kern_ioctl+0x274/frame 0xfe004132b9e0
[66314] sys_ioctl() at sys_ioctl+0x15d/frame 0xfe004132bab0
[66314] amd64_syscall() at amd64_syscall+0x364/frame 0xfe004132bbf0
[66314] fast_syscall_common() at fast_syscall_common+0x101/frame
0xfe004132bbf0
[66314] --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800cb560a, rsp =
0x7fffdfffddf8, rbp = 0x7fffdfffde20 ---
[66314] Uptime: 18h25m14s

I'll try again next time the driver gets updated.

-- 
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 237544] graphics/drm-fbsd12.0-kmod: panic on 12-STABLE with Radeon HD 7450 (but not with drm-fbsd11.2-kmod)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237544

Kubilay Kocak  changed:

   What|Removed |Added

   Keywords||crash, needs-qa
Summary|panic on 12-STABLE with |graphics/drm-fbsd12.0-kmod:
   |Radeon HD 7450 under|panic on 12-STABLE with
   |drm-fbsd12.0-kmod but not   |Radeon HD 7450 (but not
   |drm-fbsd11.2-kmod   |with drm-fbsd11.2-kmod)
 CC||j...@freebsd.org
 Status|New |Open
  Flags||maintainer-feedback?(jmd@fr
   ||eebsd.org)
   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"