[Bug 222215] r323389 breaks the kernel build when WITHOUT_ZFS is defined in src.conf

2017-09-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=15

--- Comment #1 from Toomas Soome  ---
Yep, the update was missing #ifdef EFI_ZFS_BOOT guard.

-- 
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 222201] fgrep / grep -F broken if WITH_BSD_GREP set

2017-09-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=01

--- Comment #1 from Kyle Evans  ---
(In reply to rozhuk.im from comment #0)

Hi,

These commits shouldn't have made it into 11.1-RELEASE -- was this actually on
stable/11? I'll be MFC'ing the fix for this soon.

-- 
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 222215] r323389 breaks the kernel build when WITHOUT_ZFS is defined in src.conf

2017-09-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=15

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

Author: tsoome
Date: Mon Sep 11 07:38:53 UTC 2017
New revision: 323428
URL: https://svnweb.freebsd.org/changeset/base/323428

Log:
  r323389 breaks the kernel build when WITHOUT_ZFS is defined in src.conf

  Need to add #ifdef EFI_ZFS_BOOT guard into efi/loader/main.c

  PR:   15
  Reported by:  Sylvain Garrigues

Changes:
  head/sys/boot/efi/loader/main.c

-- 
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 222215] r323389 breaks the kernel build when WITHOUT_ZFS is defined in src.conf

2017-09-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=15

Bug ID: 15
   Summary: r323389 breaks the kernel build when WITHOUT_ZFS is
defined in src.conf
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: sylv...@sylvaingarrigues.com

/usr/src/sys/boot/efi/loader/main.c:883:8: error: implicit declaration of
function 'efizfs_get_handle_by_guid' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
efizfs_get_handle_by_guid(z_dev->pool_guid);
^  
/usr/src/sys/boot/efi/loader/main.c:883:8: error: this function declaration is
not a prototype [-Werror,-Wstrict-prototypes]
/usr/src/sys/boot/efi/loader/main.c:883:39: error: incomplete definition of
type 'struct zfs_devdesc'
efizfs_get_handle_by_guid(z_dev->pool_guid);
  ~^
/usr/src/sys/boot/efi/loader/main.c:875:10: note: forward declaration of
'struct zfs_devdesc'
struct zfs_devdesc *z_dev;

-- 
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 222215] r323389 breaks the kernel build when WITHOUT_ZFS is defined in src.conf

2017-09-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=15

Toomas Soome  changed:

   What|Removed |Added

 Status|New |In Progress

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

[Bug 222227] ZFS: Confusing error message when attempting to create zpool on too small media

2017-09-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=27

--- Comment #1 from Marie Helene Kvello-Aune  ---
Created attachment 186261
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=186261=edit
truss output

Attaching output of  # truss zpool create floppytest da0p1. I think relevant
output is towards the end, but I'm not too familiar with truss so including all
of 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 222201] fgrep / grep -F broken if WITH_BSD_GREP set

2017-09-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=01

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

Some were after:
FreeBSD rimwks 11.1-STABLE FreeBSD 11.1-STABLE #0 r321762M: Mon Jul 31 13:17:27
MSK 2017
in the middle august.

-- 
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 222227] ZFS: Confusing error message when attempting to create zpool on too small media

2017-09-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=27

Bug ID: 27
   Summary: ZFS: Confusing error message when attempting to create
zpool on too small media
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: mariehelen...@gmail.com

When attempting to create a zpool on a too small media (say, a 1.4MB 3.5"
floppy), the error message is "cannot create 'poolname': no such pool or
dataset"

I'd expect an error message along the lines of 'underlying block device too
small'.

Steps to reproduce:
1) Have a floppy or other ridiculously small r/w media accessible on the system

In this example, the floppy is /dev/da0.

2) Execute following commands to prepare media
# gpart create -s gpt da0
da0 created
# gpart add -t freebsd-zfs da0
da0p1 created
# gpart show da0
=>  40  2800  da0  GPT  (1.4M)
40  28001  freebsd-zfs  (1.4M)

3) Attempt to create pool
# zpool create floppytest /dev/da0p1
cannot create 'floppytest': no such pool or dataset

-- 
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 222215] r323389 breaks the kernel build when WITHOUT_ZFS is defined in src.conf

2017-09-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=15

Toomas Soome  changed:

   What|Removed |Added

 Status|In Progress |Closed
 Resolution|--- |FIXED

-- 
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 222201] fgrep / grep -F broken if WITH_BSD_GREP set

2017-09-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=01

Kyle Evans  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|kev...@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 222201] fgrep / grep -F broken if WITH_BSD_GREP set

2017-09-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=01

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

Author: kevans
Date: Mon Sep 11 15:52:24 UTC 2017
New revision: 323443
URL: https://svnweb.freebsd.org/changeset/base/323443

Log:
  bsdgrep: add a primitive literal matcher to unbreak fgrep in some scenarios

  MFC r322825: bsdgrep: add some additional tests for fgrep

  Previously added tests only check that fgrep is somewhat sane and works. Add
  some more tests that check that the implementation is basically functional
  and not producing incorrect results with various flags.

  MFC r322826: bsdgrep: add a primitive literal matcher

  fgrep/grep -F will error out at runtime if compiled with a regex(3)
  that does not define REG_NOSPEC or REG_LITERAL. glibc is one such regex(3)
  implementation, and as it turns out they don't support literal matching at
  all.

  Provide a primitive literal matcher for use with glibc and other
  implementations that don't support literal matching so that we don't
  completely lose fgrep/grep -F if compiled against libgnuregex on stable/10,
  stable/11, or other systems that we don't necessarily support.

  This is a wholly unoptimized implementation with no plans to optimize it as
  of now. This is due to both its use-case being primarily on unsupported
  systems in the near-distant future and that it's reinventing the wheel that
  we already have available as a feature of regex(3).

  PR:   01
  Approved by:  emaste (mentor, blanket MFC)

Changes:
_U  stable/11/
  stable/11/contrib/netbsd-tests/usr.bin/grep/t_grep.sh
  stable/11/usr.bin/grep/grep.c
  stable/11/usr.bin/grep/grep.h
  stable/11/usr.bin/grep/util.c

-- 
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 221350] Unable to boot/install on HPE Proliant MicroServer Gen10 (AMD Opteron X3000): Hangs/Panics

2017-09-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221350

Jussi Hagman  changed:

   What|Removed |Added

 CC||juhag...@gmail.com

--- Comment #7 from Jussi Hagman  ---
I can confirm this too. Trying to install FreeBSD (and FreeNAS) hang as
described by Rafal.

I would love to provide more information to help debugging and fixing this
problem.


I can run Linux on the box, but would really prefer FreeNAS.

-- 
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 222234] head -r323246 aarch64 (Pine64+ 2GB) boot time context, sometimes: acquiring blockable sleep lock with spinlock or critical section held

2017-09-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=34

Bug ID: 34
   Summary: head -r323246 aarch64 (Pine64+ 2GB) boot time context,
sometimes: acquiring blockable sleep lock with
spinlock or critical section held
   Product: Base System
   Version: CURRENT
  Hardware: arm64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: mar...@dsl-only.net

Based on a head -r323246 debug kernel build:

Occasionally when I boot the Pine64+ 2GB I get:

panic: acquiring blockable sleep lock with spinlock or critical section held
(sleep mutex) pmap @ /usr/src/sys/arm64/arm64/pmap.c:4710

This is the PMAP_LOCK in:

int
pmap_fault(pmap_t pmap, uint64_t esr, uint64_t far)
. . .

It reports:

[ thread pid 0 tid 100058 ]
Stopped at  sched_switch+0x2b8: ldrbw9, [x8, #894]

It turns our that x8 is reported as holding the value zero:

db> show reg
. . .
x8   0
. . .

The back trace is:

. . .
CPU  1: (null) (null) r0p0 affinity:  0
CPU  2: (null) (null) r0p0 affinity:  0
CPU  3: (null) (null) r0p0 affinity:  0
panic: acquiring blockable sleep lock with spinlock or critical section held
(sleep mutex) pmap @ /usr/src/sys/arm64/arm64/pmap.c:4710
cpuid = 0
time = 13
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x28
 pc = 0x005efc78  lr = 0x00088094
 sp = 0x69850080  fp = 0x69850290

db_trace_self_wrapper() at vpanic+0x164
 pc = 0x00088094  lr = 0x0031764c
 sp = 0x698502a0  fp = 0x69850310

vpanic() at kassert_panic+0x15c
 pc = 0x0031764c  lr = 0x003174e4
 sp = 0x69850320  fp = 0x698503e0

kassert_panic() at witness_checkorder+0x160
 pc = 0x003174e4  lr = 0x00374990
 sp = 0x698503f0  fp = 0x69850470

witness_checkorder() at __mtx_lock_flags+0xa8
 pc = 0x00374990  lr = 0x002f8b7c
 sp = 0x69850480  fp = 0x698504b0

__mtx_lock_flags() at pmap_fault+0x40
 pc = 0x002f8b7c  lr = 0x00606994
 sp = 0x698504c0  fp = 0x698504e0

pmap_fault() at data_abort+0xb8
 pc = 0x00606994  lr = 0x00608a9c
 sp = 0x698504f0  fp = 0x698505a0

data_abort() at do_el1h_sync+0xfc
 pc = 0x00608a9c  lr = 0x006088f0
 sp = 0x698505b0  fp = 0x698505e0

do_el1h_sync() at handle_el1h_sync+0x74
 pc = 0x006088f0  lr = 0x005f1874
 sp = 0x698505f0  fp = 0x69850700

handle_el1h_sync() at sched_switch+0x2a8
 pc = 0x005f1874  lr = 0x0033f0c8
 sp = 0x69850710  fp = 0x698507f0

sched_switch() at mi_switch+0x1b8
 pc = 0x0033f0c8  lr = 0x0032161c
 sp = 0x69850800  fp = 0x69850820

mi_switch() at taskqgroup_binder+0x7c
 pc = 0x0032161c  lr = 0x0035510c
 sp = 0x69850830  fp = 0x69850860

taskqgroup_binder() at gtaskqueue_run_locked+0x104
 pc = 0x0035510c  lr = 0x00354f74
 sp = 0x69850870  fp = 0x698508e0

gtaskqueue_run_locked() at gtaskqueue_thread_loop+0x9c
 pc = 0x00354f74  lr = 0x00354d10
 sp = 0x698508f0  fp = 0x69850910

gtaskqueue_thread_loop() at fork_exit+0x7c
 pc = 0x00354d10  lr = 0x002dbd3c
 sp = 0x69850920  fp = 0x69850950

fork_exit() at fork_trampoline+0x10
 pc = 0x002dbd3c  lr = 0x00608664
 sp = 0x69850960  fp = 0x


See:

https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-September/003300.html

for more details.

In the console output this seem to be about the same
place that the non-debug kernel (typically?) fails.

-- 
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 222240] multiple ICMP echo requests reported when ping broadcast

2017-09-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=40

George V. Neville-Neil  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|g...@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 222242] [patch] allow masks smaller than cpuset_t, if large enough for mp_maxid

2017-09-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=42

Bug ID: 42
   Summary: [patch] allow masks smaller than cpuset_t, if large
enough for mp_maxid
   Product: Base System
   Version: 11.1-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Keywords: patch
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: free...@ruka.org
  Keywords: patch

Created attachment 186278
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=186278=edit
patch to check that mask is actually too small, not just smaller than the
kernel compiled type

As mentioned in Bug 200802, increasing MAXCPUS breaks compatibility for
software setting cpu affinity compiled on earlier versions of FreeBSD.

With this patch, the calls will only fail with ERANGE if the mask size is
actually too small.

In case of running old binaries on new systems with more cpus than fit in the
mask, that's still not going to work with this patch. 

In response to a comment on that bug:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200802#c4

> Shouldn't cpuset users be querying the cpuset size from sysctl and using that 
> as their allocation base?

Possibly, but then the calling code wouldn't be able to use cpuset_t types, or
CPU_SET macros.

Some updates of documentation would be required too, as the documentation
currently says when using a too small mask, get returns an error, and set runs
without error (which doesn't appear to be 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"

[Bug 222240] multiple ICMP echo requests reported when ping broadcast

2017-09-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=40

Bug ID: 40
   Summary: multiple ICMP echo requests reported when ping
broadcast
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: han...@mehnert.org

When I send a broadcast ping, and run tcpdump on the same host, I see multiple
ICMP echo requests in tcpdump (with slightly different timestamps).  Running a
tcpdump on a different host in the same broadcast domain only sees one ICMP
echo request!.

# ping 192.168.0.255
PING 192.168.0.255 (192.168.0.255): 56 data bytes
...

# tcpdump -lni wlan0 icmp
21:45:41.833915 IP 192.168.0.6 > 192.168.0.255: ICMP echo request, id 22192,
seq 0, length 64
21:45:41.833927 IP 192.168.0.6 > 192.168.0.255: ICMP echo request, id 22192,
seq 0, length 64
21:45:42.896747 IP 192.168.0.6 > 192.168.0.255: ICMP echo request, id 22192,
seq 1, length 64
21:45:42.896758 IP 192.168.0.6 > 192.168.0.255: ICMP echo request, id 22192,
seq 1, length 64


I reported this earlier on transport@
(https://lists.freebsd.org/pipermail/freebsd-transport/2016-September/000145.html)
and it was cross-posted to net@
(https://lists.freebsd.org/pipermail/freebsd-net/2016-September/046105.html)

gnn@ reported he can reproduce this on 11 as well.

I just checked, and it this behaviour is still present in CURRENT (r322062)

-- 
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 221557] Kernel does not compile with options DEBUG

2017-09-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221557

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

Author: ian
Date: Mon Sep 11 22:32:38 UTC 2017
New revision: 323469
URL: https://svnweb.freebsd.org/changeset/base/323469

Log:
  MFC r322580:

  Fix compile error with option DEBUG.  This is fallout from some long-ago
  INTRNG refactoring that didn't get caught at the time because code in a
  debugf() statement isn't compiled unless DEBUG is defined.

  PR:   221557

Changes:
_U  stable/11/
  stable/11/sys/kern/subr_intr.c

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