[Bug 246630] stable/11 regression: base.txz reproducibility depends on number of cpu cores

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246630

--- Comment #22 from Fabian Keil  ---
D'oh. I realized that some of my reproduction attempts were flawed because I
didn't set WITHOUT_SYSTEM_COMPILER and only built the tested release once to
safe time, thus testing the currently installed system compiler.

Normally I build a release, install the release and rebuild the release with
itself.

Anyway, doing it properly with a system based on r361652 with "#define
CLANG_SPAWN_CC1 1" seems to get worse results.

Instead of a completely reproducible build I got an unreproducible /bin/sh,
unreproducible rescue binaries and an unreproducible /usr/bin/printf.

-- 
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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521

--- Comment #149 from Gary Jennejohn  ---
(In reply to hlh from comment #148)
I can report that this change did not affect my 522A.
I now see non-fatal lock order reversals when I remove the SD card.  I don't
remember seeing them last week.  But the kernel contains lots of this type of
lock order reversal, so nothing to worry about.

-- 
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 246889] Kernel panic after upgrading to FreeBSD 12.1

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246889

--- Comment #8 from Andriy Gapon  ---
What source tree did you use when you compiled the modules?
Is it an exact match for the kernel that you have installed?

-- 
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 246889] Kernel panic after upgrading to FreeBSD 12.1

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246889

--- Comment #9 from Eugene Hutorny  ---
What would be a proof for that?

-- 
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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521

--- Comment #150 from h...@restart.be ---
(In reply to Gary Jennejohn from comment #149)

rtsx_handle_card_present() is called in rtsx_intr() with the LOCK active.
This function schedule immediately rtsx_card_task() and this one acquire the
LOCK, make some processing and UNLOCK. maybe during this processing the
rtsx_intr() complete and UNLOCK.

-- 
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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521

--- Comment #151 from h...@restart.be ---
(In reply to hlh from comment #150)

maybe the culprit:

In a commit on May 28 in rtsx_card_task() I put the UNLOCK after
sc->rtsx_mmc_dev = NULL. It seems logical since sc struct is modified.

In your original code, the UNLOCK was before device_delete_child().

-- 
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 244533] [patch] diff(1) --label not honoured for "print_status"

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244533

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

Author: bapt
Date: Mon Jun  1 09:01:14 UTC 2020
New revision: 361688
URL: https://svnweb.freebsd.org/changeset/base/361688

Log:
  Restore compatibility with GNU diff regarding --label

  Various options to "diff(1)" show filenames, and traditionally make use of
the
  "--label" parameter, if set.

  Restore this behaviour in BSD diff.

  While here add a regression test

  PR:   244533
  Submitted by: Jamie Landeg-Jones 
  MFC after:3 days

Changes:
  head/usr.bin/diff/diff.c
  head/usr.bin/diff/tests/diff_test.sh

-- 
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 233402] diff -N: loss of functionality

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233402

--- Comment #3 from commit-h...@freebsd.org ---
A commit references this bug:

Author: bapt
Date: Mon Jun  1 09:09:37 UTC 2020
New revision: 361689
URL: https://svnweb.freebsd.org/changeset/base/361689

Log:
  diff: restore compatibility with GNU diff regarding -N option

  When -N is used the missing files are treated as empty.

  PR:   233402
  Submitted by: Fehmi Noyan Isi 
  Reported by:  Roman Neuhauser 
  MFC after:3 days
  Differential Revision:D25081

Changes:
  head/usr.bin/diff/diff.c
  head/usr.bin/diff/tests/diff_test.sh

-- 
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 244533] [patch] diff(1) --label not honoured for "print_status"

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244533

Baptiste Daroussin  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|New |Closed

--- Comment #6 from Baptiste Daroussin  ---
Thanks for reporting and sorry for the delay

-- 
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 233402] diff -N: loss of functionality

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233402

Baptiste Daroussin  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|New |Closed

--- Comment #4 from Baptiste Daroussin  ---
Fixed, thank you for reporting! sorry it took so long!

-- 
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 234195] diff(1) doesn't document long name for -b

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234195

--- Comment #3 from commit-h...@freebsd.org ---
A commit references this bug:

Author: bapt
Date: Mon Jun  1 09:15:16 UTC 2020
New revision: 361690
URL: https://svnweb.freebsd.org/changeset/base/361690

Log:
  Document long version of -b option

  PR:   234195
  Submitted by: Fehmi Noyan Isi 
  Reported by:  Andras Farkas 
  MFC after:3 days

Changes:
  head/usr.bin/diff/diff.1

-- 
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 234195] diff(1) doesn't document long name for -b

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234195

Baptiste Daroussin  changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |FIXED

--- Comment #2 from Baptiste Daroussin  ---
Fixed, thank your for reporting and the patch submission

-- 
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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521

--- Comment #152 from Jesper Schmitz Mouridsen  ---
(In reply to hlh from comment #151)
lock order reversal: (Giant after non-sleepable)
 1st 0xf80004e0fc00 rtsx0 (rtsx) @ rtsx.c:513
 2nd 0x81802500 Giant (Giant) @ /usr/src/sys/kern/kern_synch.c:228
stack backtrace:
#0 0x80c2acc1 at witness_debugger+0x71
#1 0x80b9c844 at __mtx_lock_flags+0x94
#2 0x80bca5c6 at _sleep+0x366
#3 0x8071c341 at mmcsd_detach+0xe1
#4 0x80bf63ee at device_detach+0x18e
#5 0x80bf60c5 at device_delete_child+0x15
#6 0x8071a0c7 at mmc_delete_cards+0x97
#7 0x80712e43 at mmc_detach+0x23
#8 0x80bf63ee at device_detach+0x18e
#9 0x80bf60c5 at device_delete_child+0x15
#10 0x82322b0f at rtsx_card_task+0x1bf
#11 0x80c1d5fa at taskqueue_run_locked+0xaa
#12 0x80c1d50d at taskqueue_run+0x4d
#13 0x80b7f379 at ithread_loop+0x279
#14 0x80b7bec0 at fork_exit+0x80
#15 0x81031aae at fork_trampoline+0xe
uma_zalloc_debug: zone "256" with the following non-sleepable locks held:
exclusive sleep mutex rtsx0 (rtsx) r = 0 (0xf80004e0fc00) locked @
rtsx.c:513
unlocking before delete_device_child as you noted fixes it

-- 
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"


YinHong Disposable masks and KN95 masks could

2020-06-01 Thread Chou Yang via freebsd-bugs
Good day,
 Glad to let you know that after completing the construction of the Lei 
Shenshan Hospital project, Yin Hong Company, in order to actively
protect the epidemic, Yin Hong mask production line was officially put into 
production, mainly producing disposable masks and KN95 masks, with CE and FDA 
certification, 2 million per day could be exported easily.
 Welcome to order! you can also send your whatsapp number for easy 
conversation,  If you have some face mask questions plz feel free to let me 
know in time.
 --
Best Regards!
 Chou Yang
Sales Department
 +86 186 5280 0885
___
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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521

--- Comment #153 from Gary Jennejohn  ---
(In reply to Jesper Schmitz Mouridsen from comment #152)
Right, so unlock before device_delete_child() and re-lock before the write to
sc->rtsx_mmc_dev.  It tried this change, it works and eliminates the lock
reversal.

-- 
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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521

--- Comment #154 from h...@restart.be ---
(In reply to Gary Jennejohn from comment #153)
LOCK / UNLOCK for sc->rtsx_mmc_dev = NULL; seems useless to me.

-- 
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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521

--- Comment #155 from Gary Jennejohn  ---
(In reply to hlh from commsc->rtsx_mmc_devent #154)
This disagress with your comment in 151, which implies you were worried about
modifying sc->rtsx_mmc_dev when it's not under the lock.  If that's the case
then it should be re-locked beforehand.
IMO reacquiring the lock is no big deal.  It's not like this code is executed
millions of time per second.  And it makes it clear exactly why the lock is
being used.

-- 
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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521

--- Comment #156 from h...@restart.be ---
(In reply to Gary Jennejohn from comment #155)

In this case:

   if (device_delete_child(sc->rtsx_dev, sc->rtsx_mmc_dev))
   device_printf(sc->rtsx_dev, "Detaching MMC bus failed\n");
   sc->rtsx_mmc_dev = NULL;
   RTSX_UNLOCK(sc);

The LOCK try to postpone a new occurrence of rtsx_card_task()
to reconnect a card.

In this case:

   RTSX_UNLOCK(sc);
   if (device_delete_child(sc->rtsx_dev, sc->rtsx_mmc_dev))
   device_printf(sc->rtsx_dev, "Detaching MMC bus failed\n");
   sc->rtsx_mmc_dev = NULL;


A new occurrence of rtsx_card_task() may reconnect a card and then
rtsx_mmc_dev is replace by NULL. And so even if it is bracketed by LOCL/UNLOCK.

-- 
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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521

--- Comment #157 from Gary Jennejohn  ---
(In reply to hlh from comment #156)
OK, I'm convinced.  Now we both know why the original code was correct :)

-- 
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"


Научные публикации

2020-06-01 Thread Интерактив плюс


___
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...

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

John  changed:

   What|Removed |Added

 CC||kabukimas...@gmail.com

--- Comment #287 from John  ---
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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521

--- Comment #158 from Gleb Popov  ---
It is awesome to see progress on this.

I wrote a FreeBSD port that pulls sources from GitHub, compiles the kmod and
installs it. We can use it to gain wider testing audience.

Henri, once you're confident with the code, add a tag and I will use it to
commit the port.

And thanks again everyone involved!

-- 
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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521

--- Comment #159 from Henri Hennebert  ---
(In reply to Gleb Popov from comment #158)

Thank you!

I am waiting for a test by jyoun...@gmail.com about the RTS522A.

Can you test the driver on your notebook and report the
Realtek device and FreeBSD version to complete the README.md

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"


[Bug 246597] Race condition in mountd

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246597

Mark Johnston  changed:

   What|Removed |Added

 CC||ma...@freebsd.org,
   ||rmack...@freebsd.org

--- Comment #1 from Mark Johnston  ---
Does this fully fix the race?  If mountd receives SIGHUP while executing
get_exportlist(), it will block in select without re-reading the exports file,
and the next request will be handled before the export list is re-processed. 
Am I missing something?

-- 
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 246307] Kernel panic when running sysctl -a | grep igb

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246307

Mark Johnston  changed:

   What|Removed |Added

 CC||kak...@freebsd.org,
   ||ma...@freebsd.org

--- Comment #1 from Mark Johnston  ---
Can you reproduce this on the latest HEAD revision?  It looks like a duplicate
of PR 246114, which was fixed by r361113.

-- 
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 246311] [patch] procstat can't view current working directory (affects xfce4-terminal, linprocfs, ...)

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246311

Mark Johnston  changed:

   What|Removed |Added

 CC||ma...@freebsd.org

--- Comment #2 from Mark Johnston  ---
(In reply to Conrad Meyer from comment #1)
Indeed, I can't quite understand why PGET_CANDEBUG is a problem.

Can you see exactly what check is failing?  Does xfce4-terminal run as a
different user than the shell?

-- 
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 246312] make buildkernel fails on sys/dev/kbdmux/kbdmux.c at r360808 (r360560 was ok)

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246312

Mark Johnston  changed:

   What|Removed |Added

 CC||ma...@freebsd.org
 Status|New |Closed
 Resolution|--- |Unable to Reproduce

--- Comment #2 from Mark Johnston  ---
(In reply to Philippe Michel from comment #1)
I will close the bug for now, then.  If it occurs again, please re-open, and
provide the contents of kbdmuxmap.h from the kernel object directory.

-- 
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"


(AD) OSANG HEALTHCARE ., ltd COVID-19 diagnostic kit!

2020-06-01 Thread dennyhan


___
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 246918] audit.log(5) reference to non-existing man pages

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246918

Bug ID: 246918
   Summary: audit.log(5) reference to non-existing man pages
   Product: Documentation
   Version: Latest
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: Manual Pages
  Assignee: b...@freebsd.org
  Reporter: shivankgar...@gmail.com
CC: d...@freebsd.org

There seems to be an issue with the audit.log(5) manpage, under the section
"Expanded Header Token". It says: A 32-bit extended "header" token can be
created using au_to_header32_ex(3); a 64-bit extended "header" token can be
created using au_to_header64_ex(3).
 - There are no man pages associated with the au_to_header32_ex and
au_to_header64_ex.
 - I was able to find the function au_to_header32_ex in the FreeBSD source. But
there was no au_to_header64_ex in the source code.

-- 
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 246918] audit.log(5) reference to non-existing man pages

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246918

Shivank Garg  changed:

   What|Removed |Added

   Keywords||easy
URL||https://www.freebsd.org/cgi
   ||/man.cgi?query=audit.log&ap
   ||ropos=0&sektion=5&manpath=F
   ||reeBSD+12.1-stable&arch=def
   ||ault&format=html

-- 
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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521

--- Comment #160 from Gleb Popov  ---
Loading the driver results in

rtsx0:  mem 0xdf10-0xdf100fff at
device 0.0 on pci4

but nothing else. mmc and mmcsd are already loaded.

-- 
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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521

--- Comment #161 from Gleb Popov  ---
Oh, I inserted a card and new device appeared. I haven't done extensive
testing, though,

-- 
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 246046] boot error in boot/lua/drawer.lua

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246046

--- Comment #2 from gabor.rad...@gmail.com ---
(In reply to Kyle Evans from comment #1)

Ok, it's weird bit ... I was playing with GhostBSD to enable PXE or netboot. I
did not change any filename but used only files with their "as is" name from
GhostBSD's install medium. When the error popped I reported first to GhostBSD
but they closed the ticket being upstream problem see (1). It looks the latest
GhostBSD install image (2) does use logo_* format, and FreeBSD 12.1-RELEASE iso
(3) too!

(1) https://github.com/ghostbsd/ghostbsd-build/issues/50
(2) http://download.us.ghostbsd.org/releases/amd64/latest/GhostBSD-20.04.1.iso
(3) https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.1/

On an installed FreeBSD instance you are right I can indeed see logo-* files,
but not on the aforementioned iso images. I guess it is due to iso9660 standard
naming, so logo_* are they. 

Guess I was doing wrong first of all, I hoped "memdisk" type PXE boot will work
out of the box but I guess it was never intended.

Anyhow, thanks for checking my ticket, please close it.

-- 
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 246046] boot error in boot/lua/drawer.lua

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246046

--- Comment #3 from Kyle Evans  ---
(In reply to gabor.radnai from comment #2)

Hmm, if I mount 12.1 image as cd9660, they do appear as logo-*.lua. Are you
checking after actually writing them to a disk, or how are you checking?

I'm not quite ready to close this just yet, though. We still shouldn't be
raising the alarm just because of a "missing" logo -- we should just not draw
the graphic in question, and maybe indicate in some more subtle way that this
happened.

-- 
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 246046] boot error in boot/lua/drawer.lua

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246046

--- Comment #4 from gabor.rad...@gmail.com ---
I mounted under Windows 10 to be honest first. Read somewhere ISO standard
defines upper case letters, number digits, "_" and "." as valid filenames which
is followed in Windows strangely, so shows as LOGO_*, but you are right,
mounting the 12.1 image under FBSD does show logo-* files.

But I think better error handling would be useful, not drawing a logo is better
than end up with nil pointer.

-- 
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 246046] boot error in boot/lua/drawer.lua

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246046

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

Author: kevans
Date: Mon Jun  1 23:26:37 UTC 2020
New revision: 361709
URL: https://svnweb.freebsd.org/changeset/base/361709

Log:
  lualoader: improve drawer error handling

  At least one user has landed in a scenario where logo files appear to be
  misnamed, and we failed to find them. Our fallback for missing logodefs is
  orb/orbbw, based on the color status. In a scenario where we can't locate
  the logos, though, this is not ideal. Add in one more layer of fallback
  to properly just don't draw any logo if the fan has been jam packed with
  foreign material.

  PR:   246046
  MFC after:3 days

Changes:
  head/stand/lua/drawer.lua

-- 
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 246046] boot error in boot/lua/drawer.lua

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246046

Kyle Evans  changed:

   What|Removed |Added

 Status|New |In Progress
  Flags||mfc-stable12?,
   ||mfc-stable11?

--- Comment #6 from Kyle Evans  ---
Fix committed, will MFC to stable/11 and stable/12; it won't make it to 11.4
because lualoader is just a non-default preview there. Thanks for the report!

-- 
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 246630] stable/11 regression: base.txz reproducibility depends on number of cpu cores

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246630

Alexandre Ganea  changed:

   What|Removed |Added

 CC||alexandre.ga...@ubisoft.com

--- Comment #23 from Alexandre Ganea  ---
Hello everyone,
I am the author of the change pointed out by Dimitry above. I am really sorry
for all the wasted time on this. This seems to unearth a determinism issue in
the register allocation in LLVM. It could be the -fintegrated-cc1 change or it
could be a latent bug.
Could you possibly C-Reduce the printf.c bug please? Additionally, can the bug
be reproduced with the latest LLVM?
Many 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"


[Bug 246597] Race condition in mountd

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246597

Rick Macklem  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|rmack...@freebsd.org
 Status|New |Open

--- Comment #2 from Rick Macklem  ---
Well, handling of SIGHUP to reload the exports file is asynchronous,
so I don't think the race Patryk is referring to is affected by handling
the next request before reloading the exports file.

I think he is referring to a case where:
- exports file is updated, sighup posted
- mountd is in get_exportslist();
  --> while mountd is in getexport_list()…
  - exports file is updated and sighup is posted
- mountd completes get_exportlist(), but does not
  do so again, since it set got_sighup = 0 after
  the last sighup posted was handled.

Patryk, do I have the above correct?

Now, your fix will fix this problem, but it introduces another one.
- Some file servers (Peter Eriksson) have 8+ file systems exported
  on them. Yes, I did type the correct number above. He creates a
  separate file system for each student, etc. (Most of his servers have
  2+, but one is over 8.)
- When exports are (re)loaded on his servers, it can take minutes.
  I think r348590 reduced the time from something like 20minutes to
  5minutes, but it is still minutes.
--> What happens if a sighup is posted to mountd once every couple
of minutes with your patch? All mountd does is reload exports
over and over and over again (lyrics of an old Beatles toon?).
The current code can suffer from this too, but it ignores sighups
posted while it is in get_exportlist() which at least partially
avoids this.
- Part of the problem is that FreeBSD's mount command posts a
  sighup to mountd every time a mount is done, just in case that
  new file system needs to be exported. (/etc/exports hasn't
  changed, but it does not know if this new file system needs
  to be exported. I've never liked this, but it is a long
  standing FreeBSD tradition, so I dare not change it.;-)

So, what can be done to make sure the updated exports file gets
processed without just doing get_exportlist() over and over..?

I think I'll post somewhere like FreeBSD-net@, since it is somewhat
like a networking problem where a delay avoids congestion.

An example solution might be:
- time how long get_exportlist() takes.
- note that sighup(s) have been posted.
- do get_exportlist() again, but only after a delay at least as large
  as the time the last get_exportlist() took.
--> That way, the updated exports would be processed, but mountd
would still do other RPC work as well.
--> It might be that even a delay of 1sec between get_exportlist() calls
would be sufficient to allow it to do the Mount RPC requests.
(There shouldn't be that many of them.)

I've actually known about this for quite a while, but since I didn't
have a good solution, I left it as is.

-- 
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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD

2020-06-01 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521

--- Comment #162 from Henri Hennebert  ---
(In reply to Gleb Popov from comment #161)

It is the first test for RTS5229.

Can you try read and write operation on /dec/mmcsd0

eg:

Create a zpool, populate it and then a zpool scrub.

If the content of the card is precious, at least create a file and check it.

Thanks in advance!

-- 
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"