[Bug 219646] "ls: fts_read: no such file or directory" in zfs snapshot dir

[bugzilla-noreply]

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

--- Comment #1 from Andriy Gapon  ---
Please see if r319096 helps with that issue.
I am going to MFC that change 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 219646] "ls: fts_read: no such file or directory" in zfs snapshot dir

[bugzilla-noreply]

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

Bug ID: 219646
   Summary: "ls: fts_read: no such file or directory" in zfs
snapshot dir
   Product: Base System
   Version: 11.0-STABLE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: g_amana...@yahoo.com

Currenlty in FreeBSD 11.1-PRERELEASE r313908+8edeb87b91f if I take a snapshot
of in a zfs filesystem, then cd into the snapshots dir, and "ls -lR" or "find"
from there (i.e. without cd into the actual snapshot), I get not results. Only
an error with "fts_read: no such file or directory".

Steps to reproduce:
1) zfs snapshot tank@snap1
2) cd /tank/.zfs/snapshot
3) ls -lR
4) Output: 
total 0
ls: fts_read: No such file or directory


I cannot tell how far behind in the code this goes. Could someone test
reproducibility?

Thank you,
George

-- 
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 219606] aarch64: libarchive.so.6 not present, libarchive.so not equivalent @ 318898

[bugzilla-noreply]

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

Mark Millard  changed:

   What|Removed |Added

 CC||mar...@dsl-only.net

--- Comment #5 from Mark Millard  ---
(In reply to Phillip R. Jaenke from comment #4)

> there is no possibility of having a libarchive.so.6 on aarch64 currently

I have not updated yet, and in fact have not
updated in some time. But when I look at the
Pine64+ 2GB I see a /usr/lib/libarchive.so.6 :

# uname -paKU
FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT  r317015M  arm64 aarch64
1200028 1200028

# ls -lTt /usr/lib/libarc*
-r--r--r--  1 root  wheel  1358498 Apr 16 18:16:16 2017 /usr/lib/libarchive.a
lrwxr-xr-x  1 root  wheel   15 Apr 16 18:16:16 2017 /usr/lib/libarchive.so
-> libarchive.so.6
-r--r--r--  1 root  wheel   804776 Apr 16 18:16:16 2017
/usr/lib/libarchive.so.6
-r--r--r--  1 root  wheel  1408466 Apr 16 18:16:16 2017 /usr/lib/libarchive_p.a

So it appears that if nothing else the painful
sequence of getting/building an older vintage
and copying the /usr/lib/libarchive.so.6 from
it to something that has COMPAT_FREEBSD11 and
ino64 might provide a sufficient file.

It might be nice if the last snapshot from before
ino64 stuck around longer than normal to be a
way to provide such older files without having
to do builds to extract such files. This is
for folks that jump versions instead of
incrementally build the update: no old files
around in the first place.

I do not think that updating has mentioned that
avoiding delete-old-libs can be appropriate so
long as:

ABI = "FreeBSD:11:aarch64"

is in use (even implicitly before everything
that was based on it has been replaced). The
likes of:

https://wiki.freebsd.org/arm64/rpi3

that say to use things like:

env ABI=FreeBSD:11:aarch64 pkg bootstrap

could also use notes about new prerequisites
for after head -r318736 / -r 317737 .

These sorts of notes would apply after
manually copying over any older libraries
just like they apply to an incremental
update from before ino64 to after ino64

(I'm still trying to gather evidence for a
periodic/random panic issue for
TARGET_ARCH=powerpc that seems to be strongly
kernel memory layout sensitive. This was
run into before ino64. So it will be
a while before I deal with upgrading
everything to be after -r318735. This means
that I've not tested the above ideas.
If having two libarchive.so.* files around
can not accurately resolve which is needed
when then the above would not work.)

-- 
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 219645] max NFS I/O size is not tunable

[bugzilla-noreply]

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

Rick Macklem  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|rmack...@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 219645] max NFS I/O size is not tunable

[bugzilla-noreply]

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

Bug ID: 219645
   Summary: max NFS I/O size is not tunable
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: rmack...@freebsd.org

Created attachment 183045
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=183045&action=edit
make max NFS client I/O size tunable

The maximum size of an I/O operation done by the NFS client is the
largest buffer cache block size (MAXBCACHEBUF).
This can only be changed by recompiling the kernel.

This patch make it a tunable called vfs.maxbcachebuf and tweaks the
NFS client to use this size for nm_rsize/nm_wsize by default.

It also generates a console log message if kern.ipc.maxsockbuf needs
to be increased.

-- 
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 219644] FreeBSD 11 + nginx + apache delay +0.1 second on files greater than 32768 bytes

[bugzilla-noreply]

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

--- Comment #2 from free...@ihead.ru ---
Created attachment 183043
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=183043&action=edit
kdump -E -f apache > apache.txt

-- 
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 219644] FreeBSD 11 + nginx + apache delay +0.1 second on files greater than 32768 bytes

[bugzilla-noreply]

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

--- Comment #1 from free...@ihead.ru ---
Created attachment 183042
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=183042&action=edit
kdump -E -f nginx > nginx.txt

-- 
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 219644] FreeBSD 11 + nginx + apache delay +0.1 second on files greater than 32768 bytes

[bugzilla-noreply]

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

Bug ID: 219644
   Summary: FreeBSD 11 + nginx + apache delay +0.1 second on files
greater than 32768 bytes
   Product: Base System
   Version: 11.0-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: free...@ihead.ru

Created attachment 183041
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=183041&action=edit
test file (size large than 32768 bytes)

FreeBSD freebsd11.build.ihead.ru 11.0-RELEASE-p8 FreeBSD 11.0-RELEASE-p8 #0:
Wed Feb 22 06:12:04 UTC 2017
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

Proxy requests from nginx to apache.
If apache response more than 32768 bytes (with headers) the request longed on
~0.1 second.

How to reproduce.
1. In httpd.conf add
Listen 127.0.0.1:80
MaxClients 1

2. Add ihead.txt in DocumentRoot (/usr/local/www/apache24/data).
It may be any file larger than 32768 bytes.

3. In nginx.conf in server {...} add 
location /ihead.txt {
proxy_pass http://127.0.0.1:80;
}

4. find nginx and apache PIDs
ps -aux | grep nginx
ps -aux | grep httpd

5. run ktrace on finded PIDs 
ktrace -p 42260 -t cfinpstuwy -f nginx
ktrace -p 42184 -t cfinpstuwy -f apache

6. Request http://IP_nginx/ihead.txt

7. Stop ktrace
ktrace -C

8. Make dumps readable
kdump -E -f nginx > nginx.txt
kdump -E -f apache > apache.txt

9. There is +0.1 second delay
 42260 nginx0.004903 CSW   stop kernel "kqread"
 42260 nginx0.110929 CSW   resume kernel "kqread" 

 42184 httpd0.000591 CSW   stop kernel "select"
 42184 httpd0.199081 CSW   resume kernel "select"


Problem not reproduced on FreeBSD 10.

-- 
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 219606] aarch64: libarchive.so.6 not present, libarchive.so not equivalent @ 318898

[bugzilla-noreply]

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

--- Comment #4 from Phillip R. Jaenke  ---
I certainly won't disagree there; it's a terrible idea. It's also what they're
going to do, whether or not you or I like it. What's an even WORSE idea is the
fact that nothing is throwing an error here. At the MINIMUM something should be
screaming. Neither libarchive nor pkg should just sit there and go 'oh,
somebody did a bad symlink, I'll just corrupt silently.'

That also does not address the fact that there is no possibility of having a
libarchive.so.6 on aarch64 currently. Once a user goes to r318898 or later,
their existing installation is going to get hosed in one way or another. At the
minimum, aarch64 needs COMPAT_FREEBSD11 to build and install libarchive.so.6 to
prevent blowing up pkgbase.

-- 
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 219606] aarch64: libarchive.so.6 not present, libarchive.so not equivalent @ 318898

[bugzilla-noreply]

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

--- Comment #3 from Ed Maste  ---
> That's the behavior I'd expect a reasonable user to try first to work around 
> this issue.

Symlinking shared libraries that are "missing" because of a version bump is a
terrible idea: it's precisely because the libraries are not compatible that the
version number is bumped, and any time it's "fixed" with a symlink the results
are going to be unpredictable and potentially disastrous.  In some specific
cases it may work as a last-effort workaround (to recover files if a backup is
missing, for example), but is very dangerous.

I've posted an update on the ino64 change to the current and ports mailing
lists, and will copy the important paragraphs here:

> In addition, some users have created a libarchive.so.6 symlink to
> libarchive.so.7, in an attempt to run older binaries on a fresh post-
> ino64 install. Do not do this: libarchive.so.6 and libarchive.so.7
> have an incompatible ABI and this will result in incorrect and
> unpredictable behaviour.
>
> The most recent -CURRENT package set was built prior to the ino64
> commit, and thus will not work on a fresh ino64 install or snapshot
> image. Until the next package set is available please build from ports,
> or use Poudriere to build your own package set.

https://lists.freebsd.org/pipermail/freebsd-current/2017-May/066136.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 219606] aarch64: libarchive.so.6 not present, libarchive.so not equivalent @ 318898

[bugzilla-noreply]

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

--- Comment #2 from Phillip R. Jaenke  ---
That's the behavior I'd expect a reasonable user to try first to work around
this issue. And that's exactly why it's a very big problem. This does NOT throw
any sort of error or warning; it just APPEARS to work. There is no warning of
incompatibility and nothing in UPDATING.

And on aarch64, there is no libarchive.so.6. At all. I confirmed with brd@ that
he built the RaspBSD image with GENERIC that contains COMPAT_FREEBSD11. Which
means anyone who attempts to go from a pre-318898 installation to >=318898 is
going to have a broken system at best. If they used pkgbase, it's going to be a
lot worse.

-- 
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 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

[bugzilla-noreply]

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

--- Comment #31 from Cassiano Peixoto  ---
Hi Mateusz,

After some time i had a server with FreeBSD 11-p1 crashed with your patch
applied. 

See bellow: 

(kgdb) list *0x80b317ac
0x80b317ac is in turnstile_broadcast
(/usr/src/sys/kern/subr_turnstile.c:837).
832 
833 /*
834  * Transfer the blocked list to the pending list.
835  */
836 mtx_lock_spin(&td_contested_lock);
837 TAILQ_CONCAT(&ts->ts_pending, &ts->ts_blocked[queue],
td_lockq);
838 mtx_unlock_spin(&td_contested_lock);
839 
840 /*
841  * Give a turnstile to each thread.  The last thread gets
Current language:  auto; currently minimal
(kgdb) bt
#0  doadump (textdump=) at pcpu.h:221
#1  0x80acfd69 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:366
#2  0x80ad031b in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:759
#3  0x80ad0153 in panic (fmt=0x0) at
/usr/src/sys/kern/kern_shutdown.c:690
#4  0x80ee2d21 in trap_fatal (frame=0xfe02378e0850, eva=32) at
/usr/src/sys/amd64/amd64/trap.c:841
#5  0x80ee2f13 in trap_pfault (frame=0xfe02378e0850, usermode=0) at
/usr/src/sys/amd64/amd64/trap.c:691
#6  0x80ee24bc in trap (frame=0xfe02378e0850) at
/usr/src/sys/amd64/amd64/trap.c:442
#7  0x80ec5951 in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:236
#8  0x80b317ac in turnstile_broadcast (ts=0x0, queue=0) at
/usr/src/sys/kern/subr_turnstile.c:837
#9  0x80aabb70 in __mtx_unlock_sleep (c=0x81cab130, opts=, file=0x1 , line=1) at
/usr/src/sys/kern/kern_mutex.c:865
#10 0x80d42dd1 in swap_reserve_by_cred (incr=,
cred=) at /usr/src/sys/vm/swap_pager.c:224
#11 0x80d58f49 in kmap_alloc_wait (map=0xf800061d7c30, size=266240)
at /usr/src/sys/vm/vm_kern.c:437
#12 0x80a7cf5c in exec_copyin_args (args=0xfe02378e0a70,
fname=0x801436b58 , segflg=UIO_USERSPACE,
argv=0x801436a98, envv=0x801436b20)
at /usr/src/sys/kern/kern_exec.c:1326
#13 0x80a7cdb8 in sys_execve (td=0xf8013d03ba00,
uap=0xfe02378e0b80) at /usr/src/sys/kern/kern_exec.c:215
#14 0x80ee367e in amd64_syscall (td=, traced=0) at
subr_syscall.c:135
#15 0x80ec5c3b in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:396
#16 0x000800b45daa in ?? ()

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

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

[bugzilla-noreply]

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

--- Comment #6 from Nils Beyer  ---
Providing backtraces from the screen while crashing is a little bit complicated
right now because 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
for a poudriere session during night...

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

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

[bugzilla-noreply]

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

--- Comment #5 from Nils Beyer  ---
1) what kind of stress test from a bootable CD/USB stick do you suggest?

2) kgdb from ports wasn't successful, either:

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.


Maybe my minidumps are corrupted, so I've disabled minidumps via:

sysctl debug.minidump=0

and have started a poudriere bulk build again...

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

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

[bugzilla-noreply]

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

--- Comment #4 from Andriy Gapon  ---
Regarding the hardware vs software problem.  I can tell from my personal
experience that the synthetic tests do not cover everything that the FreeBSD
can exercise.  So, I wouldn't take it for granted that the hardware is not at
fault.

You also need to provide backtraces from your crashes.
They should be printed on the screen when the system crashes.
Also, please try to use kgdb that comes with the gdb port/package.
And use it on /boot/kernel/kernel.

-- 
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 219606] aarch64: libarchive.so.6 not present, libarchive.so not equivalent @ 318898

[bugzilla-noreply]

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

Ed Maste  changed:

   What|Removed |Added

 CC||ema...@freebsd.org

--- Comment #1 from Ed Maste  ---
> lrwxr-xr-x  1 root  wheel  22 May 27 22:14 /usr/lib/libarchive.so.6 -> 
> /usr/lib/libarchive.so

Where did this symlink come from? libarchive.so.7 is indeed not compatible with
libarchive.so.6. Attempting to use libarchive.so.7 in its place, via a symlink
or copy etc., will result in bizarre behaviour like that observed here.

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

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

[bugzilla-noreply]

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

--- Comment #3 from Nils Beyer  ---
Unfortunately, it seems it's not relevant; I've inserted the code from the
first link:

root@asbach:/usr/src/#svnlite diff
Index: sys/amd64/amd64/sigtramp.S
===
--- sys/amd64/amd64/sigtramp.S  (revision 319101)
+++ sys/amd64/amd64/sigtramp.S  (working copy)
@@ -47,6 +47,13 @@
 0: hlt /* trap priviliged instruction */
jmp 0b

+   /*
+   * Work around a Ryzen bug (say whut?).  There appears to be an
+   * issue with the kernel iretq'ing to a %rip near the end of the
+   * user address space (top of stack).
+   */
+   .space  1088
+
ALIGN_TEXT
 esigcode:


compiled the kernel, rebooted and started a poudriere bulk build. Crashed after
3h34min with:

panic: vm_fault: fault on nofault entry, addr: fe00131fb000

-- 
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 219476] [i386] 11.1-PRERELEASE double faults due to low kern.kstack_pages default

[bugzilla-noreply]

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

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

Author: ae
Date: Mon May 29 09:30:39 UTC 2017
New revision: 319118
URL: https://svnweb.freebsd.org/changeset/base/319118

Log:
  Disable IPsec debugging code by default when IPSEC_DEBUG kernel option
  is not specified.

  Due to the long call chain IPsec code can produce the kernel stack
  exhaustion on the i386 architecture. The debugging code usually is not
  used, but it requires a lot of stack space to keep buffers for strings
  formatting. This patch conditionally defines macros to disable building
  of IPsec debugging code.

  IPsec currently has two sysctl variables to configure debug output:
   * net.key.debug variable is used to enable debug output for PF_KEY
 protocol. Such debug messages are produced by KEYDBG() macro and
 usually they can be interesting for developers.
   * net.inet.ipsec.debug variable is used to enable debug output for
 DPRINTF() macro and ipseclog() function. DPRINTF() macro usually
 is used for development debugging. ipseclog() function is used for
 debugging by administrator.

  The patch disables KEYDBG() and DPRINTF() macros, and formatting buffers
  declarations when IPSEC_DEBUG is not present in kernel config. This reduces
  stack requirement for up to several hundreds of bytes.
  The net.inet.ipsec.debug variable still can be used to enable ipseclog()
  messages by administrator.

  PR:   219476
  Reported by:  eugen
  No objection from:#network
  MFC after:1 week
  Differential Revision:https://reviews.freebsd.org/D10869

Changes:
  head/sys/netipsec/ipsec.h
  head/sys/netipsec/ipsec_input.c
  head/sys/netipsec/ipsec_output.c
  head/sys/netipsec/key_debug.h
  head/sys/netipsec/xform_ah.c
  head/sys/netipsec/xform_esp.c
  head/sys/netipsec/xform_ipcomp.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 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

[bugzilla-noreply]

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

--- Comment #2 from Nils Beyer  ---
Is that probably related to that Ryzen bug:

  
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/b48dd28447fc8ef62fbc963accd301557fd9ac20

or that

  
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/79c04d9c6ef6c8cf1780587129be432cd483d42e

?

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