[Bug 225337] z_teardown_inactive_lock held inordinately long

[bugzilla-noreply]

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

Bug ID: 225337
   Summary: z_teardown_inactive_lock held inordinately long
   Product: Base System
   Version: 11.1-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: woll...@freebsd.org

On one of our large NFS servers, it seems that some process holds
zfsvfs->z_teardown_inactive_lock far too long -- on the order of ten minutes or
more -- causing all filesystem activity to hang.  The exact same configuration
and activity patterns did not have such a hang under 10.3  I believe from web
searches that this lock is implicated in zfs dataset rollback and consequently
zfs recv -F, but the hang only seems to take place when we have both pull
replication (zfs recv) *and* active (through-the-filesystem) backups running at
the same time, which usually only happens late at night.  There are no console
messages or other indications of faults in the underlying storage system.  The
system as a whole becomes completely unusable, our monitoring system raises
alarms, but it doesn't actually crash, and whatever it was eventually does
complete without visible errors.

I'm temporarily disabling the replication job to see if that truly is the
smoking gun.  Or rather, I'm going to do that once I get access to the
filesystem again.

Example, taken from my ssh session over the past hour (these are all waiting
for the same shell script to *begin executing*):

load: 0.82  cmd: bash 56646 [zfsvfs->z_teardown_inactive_lock] 7.42r 0.00u
0.00s 0% 3624k
load: 0.71  cmd: bash 56646 [zfsvfs->z_teardown_inactive_lock] 23.00r 0.00u
0.00s 0% 3624k
load: 0.59  cmd: bash 56646 [zfsvfs->z_teardown_inactive_lock] 38.85r 0.00u
0.00s 0% 3624k
load: 1.02  cmd: bash 56646 [zfsvfs->z_teardown_inactive_lock] 88.32r 0.00u
0.00s 0% 3624k
load: 0.81  cmd: bash 56646 [zfsvfs->z_teardown_inactive_lock] 149.97r 0.00u
0.00s 0% 3624k
load: 0.76  cmd: bash 56646 [zfsvfs->z_teardown_inactive_lock] 181.17r 0.00u
0.00s 0% 3624k
load: 1.51  cmd: bash 56646 [zfsvfs->z_teardown_inactive_lock] 243.76r 0.00u
0.00s 0% 3624k
load: 0.96  cmd: bash 56646 [zfsvfs->z_teardown_inactive_lock] 282.39r 0.00u
0.00s 0% 3624k
load: 1.50  cmd: bash 56646 [zfsvfs->z_teardown_inactive_lock] 333.94r 0.00u
0.00s 0% 3624k
load: 0.93  cmd: bash 56646 [zfsvfs->z_teardown_inactive_lock] 392.77r 0.00u
0.00s 0% 3624k
load: 0.84  cmd: bash 56646 [zfsvfs->z_teardown_inactive_lock] 457.04r 0.00u
0.00s 0% 3624k
load: 0.85  cmd: bash 56646 [zfsvfs->z_teardown_inactive_lock] 526.06r 0.00u
0.00s 0% 3624k
load: 0.40  cmd: bash 56646 [zfsvfs->z_teardown_inactive_lock] 588.82r 0.00u
0.00s 0% 3624k

My suspicion is that the primary vector is zfs recv on a dataset that is
currently being backed up, but why this causes all other filesystem activity to
become blocked is a bit unclear to me.  (Race to the root?  I think the backup
software uses openat(2) and shouldn't cause that sort of problem, but maybe
random NFS clients can.)

-- 
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 225325] RealTek 8169 network devices don't seem to work with memory mapped registers

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|freebsd-...@freebsd.org
   Keywords||patch

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

[Bug 225330] clang bug can incorrectly enable or disable interrupts on amd64

[bugzilla-noreply]

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

Jonathan T. Looney  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|freebsd-toolchain@FreeBSD.o
   ||rg

-- 
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 225330] clang bug can incorrectly enable or disable interrupts on amd64

[bugzilla-noreply]

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

Bug ID: 225330
   Summary: clang bug can incorrectly enable or disable interrupts
on amd64
   Product: Base System
   Version: CURRENT
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: bin
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: j...@freebsd.org

Created attachment 189922
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=189922=edit
Patch to make clang do a slightly better job at restoring the EFLAGS register

While making a change to kernel code, I recently discovered a compiler bug that
can incorrectly enable or disable interrupts on amd64.

Imagine this code:

void
fx(void)
{
_Bool needtocall;

mtx_lock_spin();
needtocall = (--count == 0);
mtx_unlock_spin();
if (needtocall)
otherfx();
}


If you compile this code in clang (5.0.0, 5.0.1, or 6.0.0 all behave similarly
in the critical respect) either in a kernel module or with mutex inlining
disabled, you get this assembly (dumped with `objdump -S` to interleave the
assembly and source code):

void
fx(void)
{
   0:   55  push   %rbp
   1:   48 89 e5mov%rsp,%rbp
_Bool needtocall;

mtx_lock_spin();
   4:   53  push   %rbx
   5:   50  push   %rax
   6:   48 c7 c7 00 00 00 00mov$0x0,%rdi
   d:   31 f6   xor%esi,%esi
   f:   48 c7 c2 00 00 00 00mov$0x0,%rdx
  16:   b9 18 00 00 00  mov$0x18,%ecx
  1b:   e8 00 00 00 00  callq  20 
needtocall = (--count == 0);
  20:   ff 0c 25 00 00 00 00decl   0x0
  27:   9c  pushfq 
  28:   5b  pop%rbx
mtx_unlock_spin();
  29:   48 c7 c7 00 00 00 00mov$0x0,%rdi
  30:   31 f6   xor%esi,%esi
  32:   48 c7 c2 00 00 00 00mov$0x0,%rdx
  39:   b9 1a 00 00 00  mov$0x1a,%ecx
  3e:   e8 00 00 00 00  callq  43 
if (needtocall)
otherfx();
  43:   48 83 c4 08 add$0x8,%rsp
  47:   53  push   %rbx
  48:   9d  popfq  
_Bool needtocall;

mtx_lock_spin();
needtocall = (--count == 0);
mtx_unlock_spin();
if (needtocall)
  49:   74 03   je 4e 
otherfx();
}
  4b:   5b  pop%rbx
  4c:   5d  pop%rbp
  4d:   c3  retq   

mtx_lock_spin();
needtocall = (--count == 0);
mtx_unlock_spin();
if (needtocall)
otherfx();
  4e:   5b  pop%rbx
  4f:   5d  pop%rbp
  50:   e9 00 00 00 00  jmpq   55 



The critical part is the way that clang handles the conditional:

1. Decrement the value. This will set ZF if count reaches 0:

  20:   ff 0c 25 00 00 00 00decl   0x0


2. Now, save the status flags (particularly, ZF) using pushfq. Critically,
pushfq saves the entire EFLAGS value, which includes the interrupt flag.
Because we are holding a spin mutex, interrupts are disabled at this point:

  27:   9c  pushfq 
  28:   5b  pop%rbx


3. Now, call the function to unlock the spin mutex, which will potentially
enable interrupts.


4. Now, restore the status flags. Critically, popfq restores the entire EFLAGS
value, which includes the interrupt flag. Because interrupts were disabled when
the flags were stored, these instructions will disable them again:

  43:   48 83 c4 08 add$0x8,%rsp
  47:   53  push   %rbx
  48:   9d  popfq  


5. Now, use the status flags to determine whether to call the function:

  49:   74 03   je 4e 



After running this code, interrupts may remain erroneously disabled.

(This is a contrived minimal test case, but I did run into this bug while
testing a code change in the kernel. Interrupts remained erroneously disabled
after dropping a spin lock. And, in that case, the code was in the actual
kernel -- not a module.)

By now, the bug should be obvious: clang shouldn't save and restore the entire
EFLAGS register. It doesn't know what changes these other function calls make
to the values of the EFLAGS register about which clang doesn't care (e.g. IF,
IOPL, AC, etc.). By saving and restoring EFLAGS across function calls, it can
load incorrect values for these other flags.

It looks like the correct solutions are to either not save EFLAGS across
function calls, or to just save the individual flag(s) that need to be
evaluated across the function call. (For example, a simple setz/test would

[Bug 225324] errno.h does not define ETIME

[bugzilla-noreply]

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

Ed Maste  changed:

   What|Removed |Added

 CC||ema...@freebsd.org

--- Comment #1 from Ed Maste  ---
Other userland software doesn't compile for this reason, e.g.
https://github.com/IAIK/meltdown/issues/14

The "solution" there was:

#ifndef ETIME
#define ETIME 62
#endif

which seems strictly worse than either of the two options you describe.

Debian Code Search returns 3470 (Debian) packages referencing ETIME,
https://codesearch.debian.net/search?q=ETIME
Some of these are going to cause grief if we start defining ETIME, e.g.:
libreoffice_1:5.4.3-4/sal/osl/unx/system.hxx

#ifdef FREEBSD
#   define  ETIME ETIMEDOUT
#   include 
#   include 

so it seems like the first thing we'll want to do is perform a ports exp-run
with ETIME defined

-- 
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 224875] kldxref fails if a mod_depend md_cval is too close to the end of allocated sections

[bugzilla-noreply]

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

Ed Maste  changed:

   What|Removed |Added

  Flags||mfc-stable10-,
   ||mfc-stable11?

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

Jilles Tjoelker  changed:

   What|Removed |Added

 CC||jil...@freebsd.org

--- Comment #3 from Jilles Tjoelker  ---
This patch looks like an improvement but will not fix everything. In some
cases, a single addition causes an unexpected result: "seq 1.1 0.1 1.2" prints
just 1.1, and the patch will not fix that. GNU seq prints both 1.1 and 1.2.

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

[Bug 225323] powerpc64: loader regression (corrupt memlist2)

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

 CC||i...@freebsd.org
   Keywords||regression
   Assignee|freebsd-bugs@FreeBSD.org|freebsd-...@freebsd.org
   Hardware|Any |powerpc

-- 
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 225323] powerpc64: loader regression (corrupt memlist2)

[bugzilla-noreply]

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

--- Comment #1 from Breno Leitao  ---
This error message seems to come from the libsa:

This is the code that is detecting this problem:


if ((char *)ptr < (char *)mn + mn->mr_Bytes) {
panic("zfree(%p,%ju): corrupt memlist2", ptr,
(uintmax_t)bytes);
}

-- 
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 225325] RealTek 8169 network devices don't seem to work with memory mapped registers

[bugzilla-noreply]

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

--- Comment #1 from aaron.s...@baesystems.com ---
Created attachment 189913
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=189913=edit
re 8169 fix

-- 
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 225325] RealTek 8169 network devices don't seem to work with memory mapped registers

[bugzilla-noreply]

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

Bug ID: 225325
   Summary: RealTek 8169 network devices don't seem to work with
memory mapped registers
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: aaron.s...@baesystems.com

I came across a RealTek network device (device id 0x8169) that doesn't work
with memory mapped registers. Reverting to using IO space as is already being
done for the 8169SC (0x8167) devices solved the problem. Patch is 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"

[Bug 225324] errno.h does not define ETIME

[bugzilla-noreply]

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

Bug ID: 225324
   Summary: errno.h does not define ETIME
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: greg@unrelenting.technology

We do not define the XSI STREAMS errors that are defined in NetBSD, Linux and
illumos:

https://github.com/IIJ-NetBSD/netbsd-src/blob/9df6a19369157a3aee2c2f9009ce074aab939a16/sys/sys/errno.h#L161-L165

https://github.com/torvalds/linux/blob/dda3e15231b35840fe6f0973f803cc70ddb86281/include/uapi/asm-generic/errno.h#L43-L46

https://github.com/illumos/illumos-gate/blob/4b8ee424cacf91875c8edca00ba30e7371c5f230/usr/src/uts/common/sys/errno.h#L118-L122

Of course no one cares about XSI STREAMS, but e.g. drivers originating from
Linux have (ab)used ETIME to mean whatever arbitrary timeout they wanted.

Currently, we have #define ETIME ETIMEDOUT in LinuxKPI (and
cddl/contrib/opensolaris/uts/common/fs/zfs/zcp.c).

The most notable drivers that rely on this are DRM/KMS graphics drivers. So
currently, Mesa has to do the #define ETIME ETIMEDOUT thing too, e.g.:

https://github.com/freebsd/freebsd-ports/blob/d778bff61a11b8062802417099e1d7b34256fb6a/graphics/mesa-dri/files/patch-src_intel_vulkan_anv__gem.c

This is pretty bad, and Mesa upstream does not want to do that.

We need to either #define ETIME ETIMEDOUT in errno.h, or define it as a new
error number and get rid of #define ETIME ETIMEDOUT everywhere. The latter is
more "proper" (same distinction between the two as on other systems), but
slightly more painful (-CURRENT users would have to upgrade both
kernel/drm-next-kmod AND Mesa at the same time once).

-- 
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 225323] powerpc64: loader regression (corrupt memlist2)

[bugzilla-noreply]

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

Breno Leitao  changed:

   What|Removed |Added

Summary|powerpc64: loader   |powerpc64: loader
   |regeression |regression (corrupt
   ||memlist2)

-- 
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 225323] powerpc64: loader regeression

[bugzilla-noreply]

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

Bug ID: 225323
   Summary: powerpc64: loader regeression
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: breno.lei...@gmail.com

There is a new commit on HEAD that broke the loader on powerpc64 on KVM. I
tested on both Power8 and Power9.

This break the loader once the kernel is loaded:

Loading /boot/defaults/loader.conf
/boot/kernel/kernel data=0x11ef978+0x4c6e48 syms=[0x8+0x1684e0panic:
zfree(0x183c0c0,4224): corrupt memlist2
--> Press a key on the console to reboot <--


Since this crash is in the loader, it break the whole machine, and I am not
able to load the old kernel.

This is the current kernel I built:

  /boot ls -la kernel
total 84388
drwxr-xr-x   2 root  wheel 15872 Jan 19 19:30 .
drwxr-xr-x  11 root  wheel  1024 Jan 19 19:30 ..
-r-xr-xr-x   1 root  wheel  7968 Jan 19 19:29 accf_data.ko
-r-xr-xr-x   1 root  wheel  9208 Jan 19 19:29 accf_dns.ko
-r-xr-xr-x   1 root  wheel 14032 Jan 19 19:29 accf_http.ko
-r-xr-xr-x   1 root  wheel 21728 Jan 19 19:29 acl_nfs4.ko
-r-xr-xr-x   1 root  wheel 13256 Jan 19 19:29 acl_posix1e.ko
-r-xr-xr-x   1 root  wheel 63448 Jan 19 19:29 agp.ko
-r-xr-xr-x   1 root  wheel 62304 Jan 19 19:29 aha.ko
-r-xr-xr-x   1 root  wheel210952 Jan 19 19:29 ahc.ko
-r-xr-xr-x   1 root  wheel 29608 Jan 19 19:29 ahc_isa.ko
-r-xr-xr-x   1 root  wheel 73472 Jan 19 19:29 ahc_pci.ko
-r-xr-xr-x   1 root  wheel136064 Jan 19 19:29 ahci.ko
-r-xr-xr-x   1 root  wheel304160 Jan 19 19:29 ahd.ko
-r-xr-xr-x   1 root  wheel 16144 Jan 19 19:29 alias_cuseeme.ko
-r-xr-xr-x   1 root  wheel 14904 Jan 19 19:29 alias_dummy.ko
-r-xr-xr-x   1 root  wheel 22696 Jan 19 19:29 alias_ftp.ko
-r-xr-xr-x   1 root  wheel 19024 Jan 19 19:29 alias_irc.ko
-r-xr-xr-x   1 root  wheel 19760 Jan 19 19:29 alias_nbt.ko
-r-xr-xr-x   1 root  wheel 20464 Jan 19 19:29 alias_pptp.ko
-r-xr-xr-x   1 root  wheel 16440 Jan 19 19:29 alias_skinny.ko
-r-xr-xr-x   1 root  wheel 4 Jan 19 19:29 alias_smedia.ko
-r-xr-xr-x   1 root  wheel 28408 Jan 19 19:29 alpm.ko
-r-xr-xr-x   1 root  wheel 41616 Jan 19 19:29 alq.ko
-r-xr-xr-x   1 root  wheel 28304 Jan 19 19:29 amdpm.ko
-r-xr-xr-x   1 root  wheel 25824 Jan 19 19:29 amdsmb.ko
-r-xr-xr-x   1 root  wheel 82648 Jan 19 19:29 amr.ko
-r-xr-xr-x   1 root  wheel 30080 Jan 19 19:29 amr_cam.ko
-r-xr-xr-x   1 root  wheel 81504 Jan 19 19:29 ata.ko
-r-xr-xr-x   1 root  wheel 22272 Jan 19 19:29 ataacard.ko
-r-xr-xr-x   1 root  wheel 28136 Jan 19 19:29 ataacerlabs.ko
-r-xr-xr-x   1 root  wheel 21000 Jan 19 19:29 ataamd.ko
-r-xr-xr-x   1 root  wheel 25768 Jan 19 19:29 ataati.ko
-r-xr-xr-x   1 root  wheel 16464 Jan 19 19:29 atacard.ko
-r-xr-xr-x   1 root  wheel 15336 Jan 19 19:29 atacenatek.ko
-r-xr-xr-x   1 root  wheel 18560 Jan 19 19:29 atacypress.ko
-r-xr-xr-x   1 root  wheel 19104 Jan 19 19:29 atacyrix.ko
-r-xr-xr-x   1 root  wheel 25360 Jan 19 19:29 atahighpoint.ko
-r-xr-xr-x   1 root  wheel 45408 Jan 19 19:29 ataintel.ko
-r-xr-xr-x   1 root  wheel 16080 Jan 19 19:29 ataisa.ko
-r-xr-xr-x   1 root  wheel 25128 Jan 19 19:29 ataite.ko
-r-xr-xr-x   1 root  wheel 21808 Jan 19 19:29 atajmicron.ko
-r-xr-xr-x   1 root  wheel 21136 Jan 19 19:29 atamarvell.ko
-r-xr-xr-x   1 root  wheel 15560 Jan 19 19:29 atamicron.ko
-r-xr-xr-x   1 root  wheel 20768 Jan 19 19:29 atanational.ko
-r-xr-xr-x   1 root  wheel 18336 Jan 19 19:29 atanetcell.ko
-r-xr-xr-x   1 root  wheel 29704 Jan 19 19:29 atanvidia.ko
-r-xr-xr-x   1 root  wheel 67272 Jan 19 19:29 atapci.ko
-r-xr-xr-x   1 root  wheel 55008 Jan 19 19:29 atapromise.ko
-r-xr-xr-x   1 root  wheel 30376 Jan 19 19:29 ataserverworks.ko
-r-xr-xr-x   1 root  wheel 30848 Jan 19 19:29 atasiliconimage.ko
-r-xr-xr-x   1 root  wheel 29832 Jan 19 19:29 atasis.ko
-r-xr-xr-x   1 root  wheel 35696 Jan 19 19:29 atavia.ko
-r-xr-xr-x   1 root  wheel 48784 Jan 19 19:29 ath_dfs.ko
-r-xr-xr-x   1 root  wheel123056 Jan 19 19:29 ath_hal.ko
-r-xr-xr-x   1 root  wheel 96792 Jan 19 19:29 ath_hal_ar5210.ko
-r-xr-xr-x   1 root  wheel115352 Jan 19 19:29 ath_hal_ar5211.ko
-r-xr-xr-x   1 root  wheel246416 Jan 19 19:29 ath_hal_ar5212.ko
-r-xr-xr-x   1 root  wheel344640 Jan 19 19:29 ath_hal_ar5416.ko
-r-xr-xr-x   1 root  wheel583808 Jan 19 19:29 ath_hal_ar9300.ko
-r-xr-xr-x   1 root  wheel363416 Jan 19 19:29 ath_main.ko
-r-xr-xr-x   1 root  wheel 66224 Jan 19 19:29 ath_rate.ko
-r-xr-xr-x   1 root  wheel 53776 Jan 19 19:30 atp.ko
-r-xr-xr-x   1 root  wheel 75880 Jan 19 19:29 autofs.ko
-r-xr-xr-x   1 root  wheel 69400 Jan 19 19:29 bcma.ko

[Bug 225321] dtrace/powerpc64: System crash

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|freebsd-...@freebsd.org
   Hardware|Any |powerpc

-- 
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 225321] dtrace/powerpc64: System crash

[bugzilla-noreply]

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

Bug ID: 225321
   Summary: dtrace/powerpc64: System crash
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: breno.lei...@gmail.com

When running dtrace function on powerpc64 it crashes:


Dtrace line:
# dtrace -n 'sched:::off-cpu { @[stack(8)] = count(); }'


# Meanwhile you can run some workload as compiling the kernel. You are going to
hit:


panic: acquiring blockable sleep lock with spinlock or critical section
held (sleep mutex) vm map (system) @
/root/kernel/freebsd/sys/vm/vm_map.c:4086
cpuid = 2
time = 1516383953
KDB: stack backtrace:
0xc00042f7c160: at .kdb_backtrace+0x5c
0xc00042f7c290: at .vpanic+0x1a4
0xc00042f7c350: at .kassert_panic+0x8c
0xc00042f7c3f0: at .witness_checkorder+0xf8
0xc00042f7c4e0: at .__mtx_lock_flags+0xfc
0xc00042f7c590: at ._vm_map_lock_read+0x34
0xc00042f7c610: at .vm_map_lookup+0x94
0xc00042f7c740: at .vm_fault_hold+0x158
0xc00042f7c950: at .vm_fault+0x9c
0xc00042f7ca00: at .trap_pfault+0xd8
0xc00042f7caa0: at .trap+0xec0
0xc00042f7cc60: at .powerpc_interrupt+0x1e0
0xc00042f7cd00: kernel DSI read trap @ 0x9b90 by
.dtrace_getpcstack+0x138: srr1=0x80001032
r1=0xc00042f7cfb0 cr=0x28202024 xer=0
ctr=0xc00043290788 r2=0xc000432d66e8 sr=0x4000
0xc00042f7cfb0: at 0x1dffe3fc
0xc00042f7d050: at .dtrace_probe+0xd70
0xc00042f7d300: at .sched_switch+0x530
0xc00042f7d3b0: at .mi_switch+0x2c4
0xc00042f7d440: at .critical_exit+0xb4
0xc00042f7d4c0: at .powerpc_interrupt+0xb4
0xc00042f7d560: kernel EXI trap by .powerpc_interrupt+0x1f0:
srr1=0x80009032
r1=0xc00042f7d810 cr=0x2000f032 xer=0 ctr=0x1
r2=0x1015e38
0xc00042f7d810: user DSI write trap @ 0x810a59008 by 0x104a29a8:
srr1=0x8000f032
r1=0x9b80 cr=0x22044028 xer=0 ctr=0x104b357c
r2=0x1071b970 sr=0x4200
KDB: enter: panic
[ thread pid 8219 tid 100089 ]
Stopped at  .kdb_enter+0x60:ld  r2, r1, 0x28

-- 
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 225312] panic: Assertion if_getdrvflags(ifp) == i failed at /usr/src/sys/net/iflib.c:2201

[bugzilla-noreply]

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

Conrad Meyer  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 225197] `make buildkernel' fails on a machine with 1GB RAM

[bugzilla-noreply]

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

--- Comment #9 from Mark Millard  ---
(In reply to Mark Millard from comment #8)

I probably should have noted that with the
much larger swap that a 1 GiByte RPi3 (aarch64)
allows without the complaint about "exceeds
maximum recommended amount", I'm not aware of
examples of the problems I and others have had
with RPi2B V1.1's. (I also experiment with an
RPi3.)

Apparently, there is an advantage to the
infrastructure for larger addresses, even with
just the same amount of RAM (1 GiByte).


Note: I've had pfault and vmwait mixture hangups
building ports on the RPi2B V1.1. It is not just
buildworld and buildkernel. I've not seen such for
the RPi3 for the swap size I use there, somewhat
under what would produce a "exceeds maximum
recommended amount" notice.

-- 
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 211771] kernel panic when loading ix interface ( was kernel panic on boot PowerEdge R720xd )

[bugzilla-noreply]

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

Justin Opotzner  changed:

   What|Removed |Added

 CC||jus...@opotzner.org

--- Comment #15 from Justin Opotzner  ---
I have a pair of 82598 based intel NICs I can setup on a test bench if that
would be helpful.

Can confirm that I am also experiencing this issue on a FreeNAS 11.1
installation, and it occurs as soon as the interface is brought 'up'.

Using DAC cables, happens when not connected at remote end.

-- 
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 225197] `make buildkernel' fails on a machine with 1GB RAM

[bugzilla-noreply]

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

--- Comment #8 from Mark Millard  ---
(In reply to Pedro F. Giffuni from comment #7)

Relative to increasing swap on a RPi2B V1.1 and
its 1 GiByte of RAM, I'll reference:

https://lists.freebsd.org/pipermail/freebsd-hackers/2018-January/052165.html

which is an example of pfault/vmwait mixure hangups during buildworld
when top shows:

Swap: 2048M Total, 52M Used, 1996M Free, 2% Inuse

The RPi2B V1.1 was getting the report:

warning: total configured swap (524288 pages) exceeds maximum recommended
amount (405460 pages).

So, the hangup is apparently an example of the "man 8 loader" note:

  Note that swap metadata can be fragmented, which means that
  the system can run out of space before it reaches the
  theoretical limit.  Therefore, care should be taken to not
  configure more swap than approximately half of the
  theoretical maximum.

ctfmerge is not the only place that people have trouble with
self-hosting based on 1 GiByte of RAM for a 32-bit architecture.

-- 
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 225197] `make buildkernel' fails on a machine with 1GB RAM

[bugzilla-noreply]

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

Pedro F. Giffuni  changed:

   What|Removed |Added

 CC|p...@freebsd.org |

--- Comment #7 from Pedro F. Giffuni  ---
Did you check that your kernel configuration doesn't have WITH_CTF=1?

I agree such ever increasing memory requirements are bad, but there's not much
to do, other than add more swap.

-- 
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 225312] panic: Assertion if_getdrvflags(ifp) == i failed at /usr/src/sys/net/iflib.c:2201

[bugzilla-noreply]

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

Hans Petter Selasky  changed:

   What|Removed |Added

 CC||hsela...@freebsd.org

--- Comment #1 from Hans Petter Selasky  ---
Can you add a print in the kernel to get the values of:

if_getdrvflags(ifp) and "i" ?

--HPS

-- 
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 225312] panic: Assertion if_getdrvflags(ifp) == i failed at /usr/src/sys/net/iflib.c:2201

[bugzilla-noreply]

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

Bug ID: 225312
   Summary: panic: Assertion if_getdrvflags(ifp) == i failed at
/usr/src/sys/net/iflib.c:2201
   Product: Base System
   Version: CURRENT
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: bhug...@freebsd.org

I am getting this panic on boot on an m4.xlarge EC2 instance running a
12.0-CURRENT snapshot:

panic: Assertion if_getdrvflags(ifp) == i failed at
/usr/src/sys/net/iflib.c:2201
cpuid = 3
time = 1516352386
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00882cc610
vpanic() at vpanic+0x18d/frame 0xfe00882cc670
vpanic() at vpanic/frame 0xfe00882cc6f0
iflib_init_locked() at iflib_init_locked+0x770/frame 0xfe00882cc750
iflib_if_ioctl() at iflib_if_ioctl+0x744/frame 0xfe00882cc7b0
ifioctl() at ifioctl+0x190f/frame 0xfe00882cc850
kern_ioctl() at kern_ioctl+0x2b9/frame 0xfe00882cc8b0
sys_ioctl() at sys_ioctl+0x15c/frame 0xfe00882cc980
amd64_syscall() at amd64_syscall+0x79b/frame 0xfe00882ccab0
fast_syscall_common() at fast_syscall_common+0xfc/frame 0x7fffe480

The snapshot is using this kernel:

FreeBSD 12.0-CURRENT #0 r328126: Thu Jan 18 15:25:44 UTC 2018
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

This seems to be related to the recent changes to make the ixl driver use
iflib.

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