[Bug 225944] ipfw table destruction exit code and -q option

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|freebsd-i...@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 225946] /usr/bin/make dumps core with simple Makefile

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

Summary|/usr/bin/make   |/usr/bin/make dumps core
   ||with simple Makefile

-- 
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 225946] /usr/bin/make

[bugzilla-noreply]

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

Bug ID: 225946
   Summary: /usr/bin/make
   Product: Base System
   Version: CURRENT
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: bin
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: itsdavidm...@gmail.com

/usr/bin/make core dumps with this Makefile for an archive.
Actually the goal is to have the Makefile work without the
foo.o: foo.c entry, as it does with gmake, but for some reason
I think /usr/bin/make realizes it needs to make lib.a(foo.o) 
but doesn't make it.
For:
% uname -a
FreeBSD metro-6.us.oracle.com 12.0-CURRENT FreeBSD 12.0-CURRENT #10
d26791952(trueos-stable-17.12): Sat Dec  9 18:10:09 UTC 2017
root@chimera:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
% cat foo.c
void
foo (
  void)
{
}
% cat Makefile
all: lib.a

lib.a: lib.a(foo.o)
ranlib lib.a

.c.a:
cc -c foo.c
ar rv lib.a foo.o
rm -f foo.o

foo.o: foo.c
cc -c foo.c

clobber: clean
rm lib.a

clean:
rm -f foo.o
% /usr/bin/make
Segmentation fault
% gdb /usr/bin/make
run
% gdb /usr/bin/make
GNU gdb (GDB) 8.0.1 [GDB v8.0.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-freebsd12.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 /usr/bin/make...Reading symbols from
/usr/lib/debug//usr/bin/make.debug...done.
done.
(gdb) run
Starting program: /usr/bin/make

Program received signal SIGSEGV, Segmentation fault.
strlen (str=0x0) at /usr/src/lib/libc/string/strlen.c:102
102 /usr/src/lib/libc/string/strlen.c: No such file or directory.
(gdb) where
#0  strlen (str=0x0) at /usr/src/lib/libc/string/strlen.c:102
#1  0x0041aba2 in Var_Set (name=, val=,
ctxt=0x800cf6ac0, flags=0) at /usr/src/contrib/bmake/var.c:973
#2  0x00402090 in Compat_Make (gnp=0x800cf6b80, pgnp=0x800cf6ac0)
at /usr/src/contrib/bmake/compat.c:657
#3  0x0041faf6 in Lst_ForEachFrom (l=0x800d700a0, ln=0x800d3e1c0,
proc=0x401fd0 , d=0x800cf6ac0)
at /usr/src/contrib/bmake/lst.lib/lstForEachFrom.c:104
#4  0x00402041 in Compat_Make (gnp=0x800cf6ac0, pgnp=0x800cf6940)
at /usr/src/contrib/bmake/compat.c:544
#5  0x0041faf6 in Lst_ForEachFrom (l=0x800d6fdd0, ln=0x800d3e160,
proc=0x401fd0 , d=0x800cf6940)
at /usr/src/contrib/bmake/lst.lib/lstForEachFrom.c:104
#6  0x00402041 in Compat_Make (gnp=0x800cf6940, pgnp=0x800cf6880)
at /usr/src/contrib/bmake/compat.c:544
#7  0x0041faf6 in Lst_ForEachFrom (l=0x800d6fc20, ln=0x800d71900,
proc=0x401fd0 , d=0x800cf6880)
at /usr/src/contrib/bmake/lst.lib/lstForEachFrom.c:104
#8  0x00402041 in Compat_Make (gnp=0x800cf6880, pgnp=0x800cf67c0)
at /usr/src/contrib/bmake/compat.c:544
#9  0x0041faf6 in Lst_ForEachFrom (l=0x800d6fb00, ln=0x800d718a0,
proc=0x401fd0 , d=0x800cf67c0)
at /usr/src/contrib/bmake/lst.lib/lstForEachFrom.c:104
---Type  to continue, or q  to quit---
#10 0x00402041 in Compat_Make (gnp=0x800cf67c0, pgnp=0x800cf67c0)
at /usr/src/contrib/bmake/compat.c:544
#11 0x004024e6 in Compat_Run (targs=0x800cfa3a0)
at /usr/src/contrib/bmake/compat.c:761
#12 0x0040cce7 in runTargets () at /usr/src/contrib/bmake/main.c:960
#13 main (argc=1, argv=) at /usr/src/contrib/bmake/main.c:1498
(gdb) x/i $rip
=> 0x460b7f :mov(%rcx),%rax
(gdb) x/x $rcx
0x0:Cannot access memory at address 0x0
(gdb)
Appears to be strlen of a null pointer.
Whatever garbage I give make, it should not core dump.
And this does work with gmake.

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 225944] ipfw table destruction exit code and -q option

[bugzilla-noreply]

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

Bug ID: 225944
   Summary: ipfw table destruction exit code and -q option
   Product: Base System
   Version: 11.1-STABLE
  Hardware: Any
OS: Any
Status: New
  Keywords: feature
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: vladimir-...@yandex.ru

This command:

ipfw table sometable destroy

always returns 0 even if 'sometable' does not exist.

This command:

ipfw table sometable create type addr

behaves correctly (0 on creation, 71 if table already exits)

Since autocreating table when adding address is now deprecated, it would be
logical if -q option would also be supported for create/destroy commands.
Currently a ruleset like this would work on boot, but fail on ipfw restart:

-qf flush
table 10 create type addr
-q table 10 add 172.17.2.1/32
add 00010 allow tcp from table(10) to me

Supporting -q option on create/destroy would make this construction workable:

-qf flush
-q table 10 create type addr
-q table 10 add 172.17.2.1/32
add allow tcp from table(10) to me


Another inconsistency is produced when checking the above ruleset (first
variant without -q for create):

# ipfw -n ipfw.rules
Flushed all rules.
Line 3: DEPRECATED: inserting data into non-existing table 10.
(auto-created)
00010 allow tcp from table(10) to me

'ipfw -n' ignores table create line, ignores existence of table 10, makes it
impossible to tell whether the ruleset would work or not.

-- 
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 203366] kevent: EV_CLEAR on fifo does not work correctly

[bugzilla-noreply]

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

--- Comment #10 from Jan Kokemüller  ---
So the EV_EOF flag is 'sticky' in kn_flags and does not get cleared anywhere,
right? Then I was wrong in comment #7.

There is also bug #224615 for an interesting edgecase at FIFO EOF where kevent
and poll differ.

I also wonder why the man page speaks of using EV_CLEAR to clear the EV_EOF
condition. What about level triggered kevent() without EV_CLEAR?
See also this commit from DragonFly[1]. They had the same problem. They still
use the filt_fiforead filter in 'sys/vfs/fifofs/fifo_vnops.c', though.

I'll try to write a test program that reproduces all those EOF related issues.


[1]:
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/acb71b22f1443bd8a34f6e457cf57c4527d7ab52

-- 
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 200079] [patch] Canada Uses ISO 8601 for Dates

[bugzilla-noreply]

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

Ed Maste  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2258
   ||55

-- 
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 225182] devel/powerpc64-xtoolchain-gcc: SLOF Data Storage Exception on boot with kernel built with devel/powerpc64-xtoolchain-gcc

[bugzilla-noreply]

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

--- Comment #13 from Mark Millard  ---
(In reply to Kenneth Salerno from comment #12)

For the explicit record for head: -r328835
was also required to avoid the heap and kernel
from overlapping.

The large MFC (stable/11 -r329183 ) includes
-r328835 from head.

-- 
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 225182] devel/powerpc64-xtoolchain-gcc: SLOF Data Storage Exception on boot with kernel built with devel/powerpc64-xtoolchain-gcc

[bugzilla-noreply]

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

--- Comment #12 from Kenneth Salerno  ---
(In reply to Breno Leitao from comment #11)
Awesome, took a look at the patch (increase heap space from 64k to 512k) and
this definitely looks promising.

Will test as soon as I get a chance next week.

-- 
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 225933] Read-only sysctl variable "kern.ipc.shmsegs" does not return number of segments

[bugzilla-noreply]

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

Brooks Davis  changed:

   What|Removed |Added

 Status|New |In Progress
 CC||bro...@freebsd.org

--- Comment #1 from Brooks Davis  ---
It looks like this description has been wrong since it was added in 2005. :(

I've added a possible rewording in https://reviews.freebsd.org/D14391

-- 
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 222671] tail(1): tail -r fails on certain piped input

[bugzilla-noreply]

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

Bryan Drewery  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2259
   ||34

-- 
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 225934] FIFOs lack kevent EVFILT_VNODE support

[bugzilla-noreply]

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

Bug ID: 225934
   Summary: FIFOs lack kevent EVFILT_VNODE support
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: bdrew...@freebsd.org

r150074 had a relevant comment here:
+/*
+ * Because fifos are now a file descriptor layer object, EVFILT_VNODE is not
+ * implemented.  Likely, fifo_kqfilter() should be removed, and
+ * fifo_kqfilter_f() should know how to forward the request to the underling
+ * vnode using f_vnode in the file descriptor here.
+ */

My main interest is in having NOTE_DELETE work.

This impacts tail -F as it tries to use NOTE_DELETE|NOTE_RENAME but gets
EINVAL and then falls into a sleep+stat+read loop.

kevent(4,{
3,EVFILT_VNODE,EV_ADD|EV_ENABLE|EV_CLEAR,NOTE_DELETE|NOTE_RENAME,0x0,0x0
3,EVFILT_READ,EV_ADD|EV_ENABLE|EV_CLEAR,0x0,0x0,0x0 },2,0x0,0,{ 0.0 })
ERR#22 'Invalid argument'

-- 
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 225933] Read-only sysctl variable "kern.ipc.shmsegs" does not return number of segments

[bugzilla-noreply]

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

Bug ID: 225933
   Summary: Read-only sysctl variable "kern.ipc.shmsegs" does not
return number of segments
   Product: Base System
   Version: 11.1-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: sblachm...@gmail.com

PROBLEM:

# sysctl -d kern.ipc.shmsegs
kern.ipc.shmsegs: Current number of shared memory segments allocated
# sysctl -Ah kern.ipc.shmsegs

EXPECTED RESULT:
numeric output

ACTUAL RESULT:
garbage output

-- 
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 225932] uplcom Prolific PL2302 doesn't support high baud rates

[bugzilla-noreply]

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

Gabor Simon  changed:

   What|Removed |Added

 Attachment #190667|text/x-c++src   |text/plain
  mime type||

--- Comment #2 from Gabor Simon  ---
Created attachment 190667
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190667=edit
pattern generator for frequency measurements

-- 
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 225932] uplcom Prolific PL2302 doesn't support high baud rates

[bugzilla-noreply]

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

Gabor Simon  changed:

   What|Removed |Added

 Attachment #190666|text/x-csrc |text/plain
  mime type||

--- Comment #1 from Gabor Simon  ---
Created attachment 190666
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190666=edit
modified file for easier review

-- 
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 225932] uplcom Prolific PL2302 doesn't support high baud rates

[bugzilla-noreply]

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

Bug ID: 225932
   Summary: uplcom Prolific PL2302 doesn't support high baud rates
   Product: Base System
   Version: 11.1-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: gabor.simo...@gmail.com

Created attachment 190665
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190665=edit
proposed patch for high baudrate support

1., Current uplcom module supports only the pre-defined baud rates, because
free baudrate setting requires a divisor calculating formula.

The product page of the vendor refers to the Linux module source as a reference
application (http://lxr.free-electrons.com/source/drivers/usb/serial/pl2303.c),
in which the formula is implemented clearly.

(The baseline frequency constant is about 1/1000 off from the one actually used
by the binary drivers though.)

After porting the formula, the baud rate can be set to any arbitrary value.


2., The current chip type detection is kind of black magic, while the ID values
of the bcdDevice[0] are officially documented in the product datasheets
(http://www.prolific.com.tw/US/ShowProduct.aspx?pcid=41=0017-0037-0041)

The current detection could not identify the type HXD chips, so disables the
baud rates above 6 Mbaud, while the chip supports up to 12Mbaud.


3., The current interrupt callback doesn't process neither the
overrun/parity/frame/break error flags, nor the RI and DSR status flags.


As I needed the high bitrates, ported the baudrate formula from the Linux code
, please decide if it is legal or not, there already was a "Determine the chip
type.  This algorithm is taken from Linux." comment in the code.

I also checked the formula against the values used by the binary driver and
corrected the baseline frequency.

Also checked the so-called standard baudrates (that shall work by directly
writing them to dwDTERate register) on a PL2303HX, and removed the non-working
ones.

(For those who want to play with the values: writing 0xf0-s with 8bit no parity
produces one square wave per 10 bits (1 start, 8 data, 1 stop), so measuring
the freqency on TxD gives 1/10th of the actual baud rate :D)

I've attached the patch, the changed file (for an easier review) and the small
freqency test I used.

NOTE: I have only a PL2303HX (bcdDevice[0]==3) at hand now, so it would be
great if someone with other models could test at least the detection 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 194204] getentropy(2): sys call from openbsd

[bugzilla-noreply]

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

--- Comment #11 from Mateusz Guzik  ---
> I think that's the wrong way to look at it; if we have a weak CSPRNG that 
> needs to be fixed, regardless of the mechanism by which userland obtains 
> entropy from kernel.

The way of looking at it was that if the compatibility mechanism is to be
provided it has to be not weaker than OpenBSD equivalent.

Entropy for the rest of the kernel is a very different issue.

> Seems like it could be implemented as a thin shim around the sysctl, no?  Why 
> do we need a syscall for it?

sysctls are very slow, but that may be a somewhat weak point given the nature
of the request. given the abundance of free syscall numbers and the fact other
systems (OpenBSD, Linux) do it as a syscall I don't see a good reason to do it
differently.

-- 
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 203366] kevent: EV_CLEAR on fifo does not work correctly

[bugzilla-noreply]

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

--- Comment #9 from Bryan Drewery  ---
r232055 dropped the fifo filter:
-static int
-filt_fiforead(struct knote *kn, long hint)
-{
-   struct socket *so = (struct socket *)kn->kn_hook;
-
-   SOCKBUF_LOCK_ASSERT(>so_rcv);
-   kn->kn_data = so->so_rcv.sb_cc;
-   if (so->so_rcv.sb_state & SBS_CANTRCVMORE) {
-   kn->kn_flags |= EV_EOF;
-   return (1);
-   } else {
-   kn->kn_flags &= ~EV_EOF;
-   return (kn->kn_data > 0);
-   }
-}

in fifo_open (for writer) this change was made:
if (fip->fi_writers == 1) {
-   SOCKBUF_LOCK(>fi_readsock->so_rcv);
-   fip->fi_readsock->so_rcv.sb_state &= ~SBS_CANTRCVMORE;
-   SOCKBUF_UNLOCK(>fi_readsock->so_rcv);
-   if (fip->fi_readers > 0) {
+   fpipe->pipe_state &= ~PIPE_EOF;
+   if (fip->fi_readers > 0)
wakeup(>fi_readers);
-   sorwakeup(fip->fi_readsock);
-   }

The filter used is:
static int   
filt_piperead(struct knote *kn, long hint)   
{
struct pipe *rpipe = kn->kn_hook;
struct pipe *wpipe = rpipe->pipe_peer;   
int ret; 

PIPE_LOCK_ASSERT(rpipe, MA_OWNED);   
kn->kn_data = rpipe->pipe_buffer.cnt;
if ((kn->kn_data == 0) && (rpipe->pipe_state & PIPE_DIRECTW))
kn->kn_data = rpipe->pipe_map.cnt;   

if ((rpipe->pipe_state & PIPE_EOF) ||
wpipe->pipe_present != PIPE_ACTIVE ||
(wpipe->pipe_state & PIPE_EOF)) {
kn->kn_flags |= EV_EOF;  
return (1);  
}
ret = kn->kn_data > 0;   
return ret;  
}

So it seems we just need to clear EV_EOF again if PIPE_EOF is not set.

-- 
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 225918] msk: excessive latency on arm64

[bugzilla-noreply]

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

Ed Maste  changed:

   What|Removed |Added

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

--- Comment #1 from Ed Maste  ---
Fixed by cognet in r329317 https://svnweb.freebsd.org/changeset/base/329317

-- 
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 194204] getentropy(2): sys call from openbsd

[bugzilla-noreply]

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

--- Comment #10 from Conrad Meyer  ---
Btw, our kernel random has used chacha20 since 2017 -- r317015.  I realize
comment #5 dates from 2014, 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 57045] trpt(8) option -t was disabled on -current

[bugzilla-noreply]

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

Conrad Meyer  changed:

   What|Removed |Added

 CC||c...@freebsd.org
   Assignee|freebsd-bugs@FreeBSD.org|c...@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 194204] getentropy(2): sys call from openbsd

[bugzilla-noreply]

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

Conrad Meyer  changed:

   What|Removed |Added

 CC||c...@freebsd.org

--- Comment #9 from Conrad Meyer  ---
Seems like it could be implemented as a thin shim around the sysctl, no?  Why
do we need a syscall for 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"

trpt(8) bug with patch attached

[Fernando Apesteguía]

Hi,

Can anyone have a look at this PR?

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

It basically removes from the man a program option no longer present
in the code.

Cheers.
___
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 225927] [panic] NULL pointer dereference in nd6_llinfo_timer()

[bugzilla-noreply]

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

Andrey V. Elsukov  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|freebsd-...@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 217149] seq(1) inconsistently omits 'last' when using float increment

[bugzilla-noreply]

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

--- Comment #6 from fernando.apesteg...@gmail.com ---
Created attachment 190657
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190657=edit
seq output from FreeBSD current

seq output generated in FreeBSD current with patches applied.

-- 
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 217149] seq(1) inconsistently omits 'last' when using float increment

[bugzilla-noreply]

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

--- Comment #7 from fernando.apesteg...@gmail.com ---
Created attachment 190658
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190658=edit
seq output generator

generator of different seq executions.

-- 
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 217149] seq(1) inconsistently omits 'last' when using float increment

[bugzilla-noreply]

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

--- Comment #5 from fernando.apesteg...@gmail.com ---
Created attachment 190656
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190656=edit
seq output from ubuntu

Output generated in an Ubuntu system

-- 
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 225927] [panic] NULL pointer dereference in nd6_llinfo_timer()

[bugzilla-noreply]

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

Bug ID: 225927
   Summary: [panic] NULL pointer dereference in nd6_llinfo_timer()
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: a...@freebsd.org

We got this panic several times already. I filled this PR in case someone else
can put here "we have this panic too".

The panic happens when network configuration is being changed (i.e. some vlan
interfaces destroyed, IPv6 prefixes removed, etc.)

The system usually has 5-20 thousands of NDP entries.

The backtrace is the following: 
Fatal trap 12: page fault while in kernel mode
cpuid = 45; apic id = 33
fault virtual address   = 0x330
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80cc3c65
stack pointer   = 0x28:0xfe104a3da890
frame pointer   = 0x28:0xfe104a3da900
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (swi4: clock (0))
trap number = 12
panic: page fault
cpuid = 45
time = 1518707404
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe104a3da470
vpanic() at vpanic+0x19c/frame 0xfe104a3da4f0
panic() at panic+0x43/frame 0xfe104a3da550
trap_fatal() at trap_fatal+0x34d/frame 0xfe104a3da5a0
trap_pfault() at trap_pfault+0x49/frame 0xfe104a3da600
trap() at trap+0x2a9/frame 0xfe104a3da7c0
calltrap() at calltrap+0x8/frame 0xfe104a3da7c0
--- trap 0xc, rip = 0x80cc3c65, rsp = 0xfe104a3da890, rbp =
0xfe104a3da900 ---
nd6_llinfo_timer() at nd6_llinfo_timer+0x75/frame 0xfe104a3da900
softclock_call_cc() at softclock_call_cc+0x12f/frame 0xfe104a3da9b0
softclock() at softclock+0xb9/frame 0xfe104a3da9e0
intr_event_execute_handlers() at intr_event_execute_handlers+0xec/frame
0xfe104a3daa20
ithread_loop() at ithread_loop+0xd6/frame 0xfe104a3daa70
fork_exit() at fork_exit+0x85/frame 0xfe104a3daab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe104a3daab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Uptime: 18d20h16m49s
Dumping 17367 out of 65386 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

__curthread () at ./machine/pcpu.h:232
232 ./machine/pcpu.h: No such file or directory.

(kgdb) bt
#0  __curthread () at ./machine/pcpu.h:232
#1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:318
#2  0x80a8bdd6 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:386
#3  0x80a8c2c6 in vpanic (fmt=, ap=0xfe104a3da530)
at /usr/src/sys/kern/kern_shutdown.c:779
#4  0x80a8c0e3 in panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:710
#5  0x80f1376d in trap_fatal (frame=0xfe104a3da7d0, eva=816) at
/usr/src/sys/amd64/amd64/trap.c:799
#6  0x80f137c9 in trap_pfault (frame=0xfe104a3da7d0, usermode=0) at
/usr/src/sys/amd64/amd64/trap.c:653
#7  0x80f13019 in trap (frame=0xfe104a3da7d0) at
/usr/src/sys/amd64/amd64/trap.c:420
#8  
#9  nd6_llinfo_timer (arg=0xf808285af000) at
/usr/src/sys/netinet6/nd6.c:781
#10 0x80aa44af in softclock_call_cc (c=,
cc=0x81dbff80 , direct=) at
/usr/src/sys/kern/kern_timeout.c:729
#11 0x80aa49d9 in softclock (arg=0x81dbff80 ) at
/usr/src/sys/kern/kern_timeout.c:867
#12 0x80a50d4c in intr_event_execute_handlers (p=,
ie=0xf8000b60d000) at /usr/src/sys/kern/kern_intr.c:1336
#13 0x80a51416 in ithread_execute_handlers (ie=,
p=) at /usr/src/sys/kern/kern_intr.c:1349
#14 ithread_loop (arg=0xf8000b54b980) at /usr/src/sys/kern/kern_intr.c:1430
#15 0x80a4e095 in fork_exit (callout=0x80a51340 ,
arg=0xf8000b54b980, frame=0xfe104a3daac0)
at /usr/src/sys/kern/kern_fork.c:1038
#16 
(kgdb) f 9
#9  nd6_llinfo_timer (arg=0xf808285af000) at
/usr/src/sys/netinet6/nd6.c:781
781 /usr/src/sys/netinet6/nd6.c: No such file or directory.
(kgdb) i lo
ln = 0xf808285af000
ifp = 0x0
ndi = 
send_ns = 
pdst = 
delay = 
do_switch = 
src = 
psrc = 
(kgdb) p *ln
$1 = {lle_next = {le_next = 0xf8054ff07200, le_prev = 0xf80408aa8e70},
r_l3addr = {addr4 = {s_addr = 3087401514}, addr6 = {__u6_addr = {
__u6_addr8 =
"*\002\006\270\000\000\032\001\230\370\036\370\203\253\036X", __u6_addr16 =
{554, 47110, 0, 282, 63640, 63518, 43907, 22558}, __u6_addr32 = {
  3087401514, 18481152, 4162779288, 1478404995, r_linkdata =
"\000%\220\353\223|$\212\a\021P\204\206\335\000\000\000\000\000\000\000\000\000",
 
  r_hdrlen = 14 '\016', spare0 = "\000\000", r_flags = 1, r_skip_req = 1,
lle_tbl = 0xf80cfead8e00, lle_head = 

[Bug 225923] ZFS lock order reversal in vfs_subr.c:2157 vfs_subr.c:2607

[bugzilla-noreply]

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

Andriy Gapon  changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |Not A Bug

--- Comment #2 from Andriy Gapon  ---
(In reply to vidwer+fbsdbugs from comment #0)

Have you experienced any real problem?
A diagnostic message is not a bug.

-- 
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 225923] ZFS lock order reversal in vfs_subr.c:2157 vfs_subr.c:2607

[bugzilla-noreply]

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

--- Comment #1 from vidwer+fbsdb...@gmail.com ---
zpool version: 5000

Bug #128633 or #142878 or #210906 don't seem to match, when looking at the
reported line numbers or OS versions.

-- 
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 225923] ZFS lock order reversal in vfs_subr.c:2157 vfs_subr.c:2607

[bugzilla-noreply]

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

Bug ID: 225923
   Summary: ZFS lock order reversal in vfs_subr.c:2157
vfs_subr.c:2607
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: vidwer+fbsdb...@gmail.com

build: 12.0-CURRENT r329245
hardware: amd64

lock order reversal:
 1st 0xf800098945f0 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2157
 2nd 0xf80025048240 zfs (zfs) @ /usr/src/sys/kern/vfs_subr.c:2607
stack backtrace:
#0 0x80b2e403 at witness_debugger+0x73
#1 0x80b2e284 at witness_checkorder+0xe34
#2 0x80a9e4d1 at lockmgr_lock_fast_path+0x1b1
#3 0x810fdc09 at VOP_LOCK1_APV+0xd9
#4 0x80ba99b6 at _vn_lock+0x66
#5 0x80b9834f at vget+0x7f
#6 0x80b9a3e6 at vfs_msync+0xa6
#7 0x80b9f0c6 at sync_fsync+0xc6
#8 0x810fcb79 at VOP_FSYNC_APV+0xd9
#9 0x80b9cf34 at sched_sync+0x284
#10 0x80a89ec4 at fork_exit+0x84
#11 0x80f5acde at fork_trampoline+0xe

-- 
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 225918] msk: excessive latency on arm64

[bugzilla-noreply]

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

Bug ID: 225918
   Summary: msk: excessive latency on arm64
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: ema...@freebsd.org

More details to come - PR submitted to track working/failing revisions/dates.
Observed on my Softiron Overdrive 1000, running a kernel from r329060:

root@od1000:~ # ping 192.168.11.1
PING 192.168.11.1 (192.168.11.1): 56 data bytes
64 bytes from 192.168.11.1: icmp_seq=0 ttl=64 time=297.339 ms
64 bytes from 192.168.11.1: icmp_seq=1 ttl=64 time=314.382 ms
64 bytes from 192.168.11.1: icmp_seq=2 ttl=64 time=303.234 ms
64 bytes from 192.168.11.1: icmp_seq=3 ttl=64 time=356.380 ms
64 bytes from 192.168.11.1: icmp_seq=4 ttl=64 time=379.047 ms
64 bytes from 192.168.11.1: icmp_seq=5 ttl=64 time=402.130 ms
64 bytes from 192.168.11.1: icmp_seq=6 ttl=64 time=464.899 ms
64 bytes from 192.168.11.1: icmp_seq=7 ttl=64 time=493.329 ms
64 bytes from 192.168.11.1: icmp_seq=8 ttl=64 time=537.635 ms
64 bytes from 192.168.11.1: icmp_seq=9 ttl=64 time=570.663 ms
64 bytes from 192.168.11.1: icmp_seq=10 ttl=64 time=621.863 ms
64 bytes from 192.168.11.1: icmp_seq=11 ttl=64 time=660.115 ms
64 bytes from 192.168.11.1: icmp_seq=12 ttl=64 time=701.733 ms
64 bytes from 192.168.11.1: icmp_seq=13 ttl=64 time=744.956 ms
64 bytes from 192.168.11.1: icmp_seq=14 ttl=64 time=791.934 ms
64 bytes from 192.168.11.1: icmp_seq=15 ttl=64 time=845.377 ms
64 bytes from 192.168.11.1: icmp_seq=16 ttl=64 time=898.613 ms
64 bytes from 192.168.11.1: icmp_seq=17 ttl=64 time=954.177 ms
64 bytes from 192.168.11.1: icmp_seq=18 ttl=64 time=1014.196 ms
64 bytes from 192.168.11.1: icmp_seq=19 ttl=64 time=1056.473 ms
64 bytes from 192.168.11.1: icmp_seq=20 ttl=64 time=1059.959 ms
64 bytes from 192.168.11.1: icmp_seq=21 ttl=64 time=1062.538 ms
64 bytes from 192.168.11.1: icmp_seq=22 ttl=64 time=1062.954 ms
64 bytes from 192.168.11.1: icmp_seq=23 ttl=64 time=1052.935 ms
64 bytes from 192.168.11.1: icmp_seq=24 ttl=64 time=1064.865 ms
64 bytes from 192.168.11.1: icmp_seq=25 ttl=64 time=1056.929 ms
64 bytes from 192.168.11.1: icmp_seq=26 ttl=64 time=1062.470 ms
^C
--- 192.168.11.1 ping statistics ---
28 packets transmitted, 27 packets received, 3.6% packet loss
round-trip min/avg/max/stddev = 297.339/734.486/1064.865/283.196 ms

cognet@ reports a Dec 3 kernel worked.

Feb 15 09:38:17 od1000 kernel: mskc0: 
port 0x1000-0x10ff mem 0x4000-0x40003fff at device 0.0 on pci2
Feb 15 09:38:17 od1000 kernel: msk0:  on mskc0
Feb 15 09:38:17 od1000 kernel: msk0: Using defaults for TSO: 65518/35/2048
Feb 15 09:38:17 od1000 kernel: msk0: Ethernet address: 
Feb 15 09:38:17 od1000 kernel: miibus0:  on msk0
Feb 15 09:38:17 od1000 kernel: e1000phy0:  PHY 0
on miibus0
Feb 15 09:38:17 od1000 kernel: e1000phy0:  none, 10baseT, 10baseT-FDX,
100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX,
1000baseT-FDX-master, auto, auto-flow

-- 
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 225911] [asmc] [patch] Add support for mid-2011 Macmini 5,2

[bugzilla-noreply]

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

Bug ID: 225911
   Summary: [asmc] [patch] Add support for mid-2011 Macmini 5,2
   Product: Base System
   Version: 11.1-STABLE
  Hardware: amd64
OS: Any
Status: New
  Keywords: patch
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: fbsdbu...@sentry.org
  Keywords: patch

Created attachment 190643
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190643=edit
Adds support for Macmini 5,2 hardware to asmc kernel module

The asmc module lacks details for the Macmini 5,2 hardware version.

Fix: See attached patches for asmc.c and asmcvar.h which have been running
successfully on my system since FreeBSD 10.2-STABLE.

How-To-Repeat: kldload supplied asmc.ko

Note: Patch also includes two cosmetic textual changes to my original Macmini
3,1 patch referenced in closed bug 190195 at
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190195 

Patch against FreeBSD 11.1-STABLE r329296 attached.

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