a76d349b6b1 uma: Deduplicate uma_small_alloc
On one failed boot I saw a failed MPASS
panic: Assertion size != 0 && qsize != 0 failed at
/usr/src/freebsd/sys/kern/subr_vmem.c:427
Followed by about 1000 stack frames with 7 frames repeating, presumably
deep/infinite recursion.
Probably want to back this out until stabilized.
Ryan
9F2772BF
It looks like tmpfs_node_init ought to pass the MTX_NEW flag, but I am
not seeing what may have changed recently that would explain why this
hasn't been hit before or more often on INVARIANTS kernels.
For future debugging, maybe uma should do an initial trashing of memory
even for zones that have an init procedure.
Ryan
On Thu, May 16, 2024 at 9:56 PM Emmanuel Vadot wrote:
>
> On Thu, 16 May 2024 10:27:40 -0700
> Ryan Libby wrote:
>
> > On Thu, May 16, 2024 at 6:00?AM David Wolfskill
> > wrote:
> > >
> > > This is running main-n270174-abb1a1340e3f (built in-place f
for "conservative" -- or vice versa.
>
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.
Maybe regression from ae38a1a1bfdf320089c254e4dbffdf4769d89110 by manu.
It looks like spin_lock_init was changed to no longer zero out the
mutex before calling mtx_init, but the MTX_NEW flag was not added.
Ryan
On Tue, May 14, 2024 at 9:09 AM Ryan Libby wrote:
>
> On Tue, May 14, 2024 at 1:14 AM Alexander Leidinger
> wrote:
> >
> > Am 2024-05-14 03:54, schrieb Ryan Libby:
> > > That was a long winded way of saying: the "UMA bucket" axis is
> > > actually
On Tue, May 14, 2024 at 1:14 AM Alexander Leidinger
wrote:
>
> Am 2024-05-14 03:54, schrieb Ryan Libby:
> > That was a long winded way of saying: the "UMA bucket" axis is
> > actually "vm phys free list order".
> >
> > That said, I find that di
; > I didn't consider landing D40575 because of that, but I guess it could
> > be useful on its own.
>
> It at least gives a way to quantify with numbers resp. qualitatively
> visualize. And as such it may help in visualizing differences like with
> your guard-pages commit. I wonder if the segregation of nofree
> allocations may result in a similar improvement for long-running
> systems.
>
> Bye,
> Alexander.
>
> --
> http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF
Ryan
Are you sure that the system isn't actually booting or are you saying
that because you get no console output after going to userland? It's
possible that /etc/ttys is not in sync with your console configuration
in loader.conf. If that happened, nothing from /etc/rc would print to
console during bo
unsubscribe
On 8/29/22 11:28 AM, Ryan Moeller wrote:
On 8/29/22 10:14 AM, Thomas Laus wrote:
On 8/17/22 10:35, Thomas Laus wrote:
I attempted to create a ZFS snapshot after upgrading this morning
and received this error
After all of the discussion to compare and contrast beadm vs. bectl
my read only
ogether a temporary patch that will remove it.
-Ryan
Now fixed as of
https://github.com/openzfs/zfs/commit/518b4876022eee58b14903da09b99c01b8caa754
-Ryan
Whoops, here's the correct link
https://cgit.freebsd.org/src/commit/?id=08aba0aec7b7f676ccc3f7886f59f277d668d5b4
On 8/17/22 12:16 PM, Ryan Moeller wrote:
On 8/17/22 12:05 PM, Ryan Moeller wrote:
On 8/17/22 10:35 AM, Thomas Laus wrote:
I attempted to create a ZFS snapshot after upgrading this morning
and received this error
# beadm create n257443
cannot create 'zroot/ROOT/n2
On 8/17/22 12:05 PM, Ryan Moeller wrote:
On 8/17/22 10:35 AM, Thomas Laus wrote:
I attempted to create a ZFS snapshot after upgrading this morning and
received this error
# beadm create n257443
cannot create 'zroot/ROOT/n257443': 'snapshots_changed' is readonly
#
T
be trying to set the
snapshots_changed property when cloning the snapshot for the BE, but the
property is of course readonly.
-Ryan
My version info:
14.0-CURRENT FreeBSD 14.0-CURRENT #9 main-n257443-f7413197245: Wed Aug
17 08:15:27 EDT 2022
There was not any information in UPDATING ab
On 7/11/22 11:43 AM, Ryan Moeller wrote:
On 7/9/22 1:56 PM, Evgeniy Khramtsov wrote:
I can reproduce via:
$ truncate -s 10G /tmp/test
$ mdconfig -f /tmp/test -S 4096
$ zpool create test /dev/md1
$ zfs create -o checksum=blake3 test/b
$ dd if=/dev/random of=/test/b/noise bs=1M count=4096
cannot reproduce this on openzfs/zfs@cb01da68057 (the commit that was
most recently merged) built out of tree on either stable/13 70fd40edb86
or main 9aa02d5120a.
I'll update a system and see if I can reproduce it with the in-tree ZFS.
- Ryan
You could "git cherry-pick -n 37f604b49d4a; git restore --unstaged
sys/net/vnet.h" to apply the fix to your local tree without committing
it or leaving it staged for commit.
On Thu, Jul 7, 2022 at 10:50 AM Steve Kargl
wrote:
>
> On Thu, Jul 07, 2022 at 10:38:43AM -0400,
Okay, update your tree and it should be fixed then.
Do you have VNET disabled in your kernel config? I believe that this
was fixed by 37f604b49d4a.
On Thu, Jul 7, 2022 at 1:07 AM Steve Kargl
wrote:
>
> -std=iso9899:1999 -Werror /usr/src/sys/netinet/tcp_input.c
> --- modules-all ---
> /usr/src/sys/netpfil/ipfw/ip_dn_io.c:674:4: error: 'continue' s
I happened to trip over this after doing a source upgrade on a machine
running -HEAD. A fresh VM build from -HEAD that was done this morning
shows the same issue.
root@test:~ # uname -a
FreeBSD test 14.0-CURRENT FreeBSD 14.0-CURRENT #0
main-n253973-8f1543785f77: Sat Mar 26 02:40:01 EDT 2022
build
I've definitely experienced the issue about different buffers rolling
over faster than others and producing confusing schedgraph data. I'm
away from home this week, but I believe that I have a script that
tries to chop off the schedgraph data at the point where the most
recent CPU to roll over has
On Mon, Sep 13, 2021 at 2:13 PM Guido Falsi via freebsd-current
wrote:
> I'm not sure how to get the verbose data for the old boot, since I've
> been unable to revert the machine to the old state. I'll try anyway though.
Do you have physical access to the machine? It might be easiest to
grab a s
On 8/27/21 11:35 AM, Ryan Moeller wrote:
zfs_deleteextattr_sa() at zfs_deleteextattr_sa+0x1e/frame
0xfe0147380360
zfs_setextattr() at zfs_setextattr+0x1e3/frame 0xfe01473804e0
Panic String: VERIFY(zp->z_is_sa) failed
I see the issue, thanks!
-Ryan
https://github.
zfs_deleteextattr_sa() at zfs_deleteextattr_sa+0x1e/frame 0xfe0147380360
zfs_setextattr() at zfs_setextattr+0x1e3/frame 0xfe01473804e0
Panic String: VERIFY(zp->z_is_sa) failed
I see the issue, thanks!
-Ryan
w features
that aren't present in 13. It won't happen automatically, you'd have to
manually run zpool upgrade.
-Ryan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe,
is a few days ago, am I the only one
with this problem?
The generated files live only in the obj dir, so after cleaning you'll
need to rebuild libifconfig (and not clean) before you can build
ifconfig again.
make -C lib/libifconfig
make -C sbin/ifconfig
Hi Lars,
Do you see the TSO6 option enabled on your vtnet interface? Do you
see normal packet sizes if you disable it with "ifconfig vtnet0
-tso6"? Does it actually fix your IPv6 issue?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd
ted features enabled.
Should be fixed now, see https://reviews.freebsd.org/D28935
-Ryan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
anity. Is it true that this particular commit is
_not_ in stable/12?
Correct, the commit is in main not stable/12.
-Ryan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send an
On Mon, Jan 4, 2021 at 3:44 PM Poul-Henning Kamp wrote:
> Shattered is less impressive when you take into account that you
> can stuff as much much garbage into a PDF file as you need, without
> affecting the files normal function.
>
> Compact data formats, formats which leave no wiggle-room and d
On Mon, Jan 4, 2021 at 11:00 AM Franco Fichtner wrote:
>
>
> > On 4. Jan 2021, at 7:52 PM, Enji Cooper wrote:
> >
> > The point is to stop looking at git like svn: commits should be done as
> > larger bodies of work (merge commits), as opposed to single atomic commits.
>
> Er, uh, no. ;)
>
> Th
On Mon, Jan 4, 2021 at 10:08 AM Warner Losh wrote:
...
> As for date order, we could also add a commit hook that requires the date
> to be properly set, but that creates friction for developers. Is that
> friction worth the benefits? I don't think so, but as you say we could also
> add notes... bu
aren't needed, the base zfs
is at least less likely to break from kernel changes that haven't been
coordinated well with the openzfs upstream and the port, which does
happen from time to time.
-Ryan
___
freebsd-current@freebsd.org mailing
d I open a bug for this?
Is the issue exposed by my choice of gzip-9 for e.g. /usr/ and if so,
can I avoid it by (now) reverting to lz4 for that part, and/or any
other part, of the file system?
Unfortunately I don't have an answer for you at this time, but ACK.
-Ryan
in OpenZFS. It is likely not building the ZFS support code on
13-current, and it is not expected to work on 12 with openzfs from
ports, either.
-Ryan
How else might I tell why the device is busy?
Mobile hard disk drive, USB.
--
root@momh167-gjp4-8570p:~ # zpool export Transcend
cann
On Sun, Nov 29, 2020 at 9:12 AM David Wolfskill wrote:
> OK, and demonstrated some long RTTs about every 11 packets or so, but we
> see thing come to a screeching halt with:
>
> ...
> 64 bytes from 172.16.8.13: icmp_seq=534 ttl=63 time=0.664 ms
> lockstat: dtrace_status(): Abort due to systemic un
On 10/17/20 9:02 AM, Graham Perrin wrote:
root@momh167-gjp4-8570p:~ # date ; uname -v ; uptime
Sat Oct 17 14:00:10 BST 2020
FreeBSD 13.0-CURRENT #69 r366648: Tue Oct 13 05:49:05 BST 2020
root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
2:00PM up 9 mins, 5 users, load
On 10/17/20 5:55 AM, Graham Perrin wrote:
On 17/10/2020 08:40, Ryan Moeller wrote:
This is intentional. The pool can be imported but the filesystem is
not mounted until the key is loaded.
Thanks, the file system mounts without me entering a passphrase; is
this intentional?
It
intentional. The pool can be imported but the filesystem is not
mounted until the key is loaded.
See zfs-load-key(8)
-Ryan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail
1250[1]: Creating ZVOL p0/testvol...
So something is preventing zv_free from being called by
zvol_remove_minors_impl.
-Ryan
13.0-CURRENT r366500+84ccaf49083c-c272054 GENERIC
#8
#9 zvol_geom_bio_getattr (bp=0xf80376132900)
at /usr/src/sys/contrib/openzfs/module/os/free
f it isn't, and that will fail if you aren't root.
-Ryan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
I'm curious: does this give a similar issue?
touch /tmp/foo
cp /tmp/foo /tmo/foo2
I'm wondering if the issue is that copy_file_range isn't handling
empty files, or if it's a devfs issue.
On Thu, Sep 10, 2020 at 11:45 AM Michael Butler
wrote:
>
> It seems that SVN r365549 broke "cp /dev/null ..
On 9/9/20 5:40 PM, Slawa Olhovchenkov wrote:
On Wed, Sep 09, 2020 at 11:55:14AM -0400, Ryan Moeller wrote:
On 9/8/20 4:31 PM, Niclas Zeising wrote:
On 2020-05-02 02:20, Matthew Macy wrote:
OpenZFS doesn't have the same ashift optimization logic that FreeBSD
has. It's something
does work now.
-Ryan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On 9/6/20 11:49 AM, marco wrote:
On Sun, Sep 06, 2020 at 10:22:33AM -0400, you (Ryan Moeller) sent the following
to [freebsd-current] :
I switched back to base ZFS whilst on r364030 and upgraded to r365336 and
deinstalled
openzfs and openzfs-kmod for now.
ZFS in base nicely auto-imported
talled
openzfs and openzfs-kmod for now.
ZFS in base nicely auto-imported both zroot and backup pools for the 1st
time.
I need to update the port, it's a little behind what's in base now.
-Ryan
___
freebsd-current@freebsd.org ma
On 9/5/20 4:23 PM, Ruslan Makhmatkhanov wrote:
Mark Johnston wrote on 9/4/20 9:55 PM:
[...]
The zfs.ko Makefile unconditionally enables creation of a debug file.
Could you verify that the problem is gone with this patch?
This patch indeed fixes the install. Thank you!
Committed in r3653
like this. It seems to
resolve this particular issue. Expect it to be a few days until the
commit gets pulled in through the vendor branch.
-Ryan
Prior to the update today, everything worked fine and the jail was able to
mount its pool; "enforce_statfs= "1";" worked so far,
On 9/1/20 7:42 PM, Julian H. Stacey wrote:
Hi curr...@freebsd.org,
With .ctm_status src-cur 14656 .svn_revision 364986 /usr/src/cddl/sbin/zfs
# bmake[4]: don't know how to make zfs-change-key.8. Stop
Thanks, fixed it: https://svnweb.freebsd.org/changeset/base/365250
-Ryan
Av
On 9/1/20 2:13 PM, Ryan Moeller wrote:
On 9/1/20 1:32 PM, Thomas Laus wrote:
Group:
Whenever I perform a major upgrade to any of my ZFS pools, I make a
habit of sending the most recent snapshot to a file and then to a DLT
tape or DVD. I run the zstreamdump utility on the file and record the
e to
look into that.
-Ryan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
t few weeks.
https://svnweb.freebsd.org/base?view=revision&revision=364746
If you encounter problems please report them to me, Ryan Moeller, and -
current.
___
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
On 8/25/20 2:09 PM, Jakob Alvermark wrote:
On 2020-08-25 20:06, Ryan Moeller wrote:
On 8/25/20 2:00 PM, Jakob Alvermark wrote:
On 2020-08-25 17:42, Ryan Moeller wrote:
On 8/25/20 9:58 AM, Jakob Alvermark wrote:
Hi,
I updated from r364605 to r364768
'make buildkernel' fails
On 8/25/20 2:00 PM, Jakob Alvermark wrote:
On 2020-08-25 17:42, Ryan Moeller wrote:
On 8/25/20 9:58 AM, Jakob Alvermark wrote:
Hi,
I updated from r364605 to r364768
'make buildkernel' fails like this:
Building
/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/modules/u
tal
error: 'immintrin.h' file not found
# include /* support for bextr (experimental) */
^
1 error generated.
*** Error code 1
Stop.
I'm trying to figure out how to reproduce this. Are you perhaps building
with GCC?
-Ryan
Best,
Jakob
On 2020-
.
It is on by default.
-Ryan
I caution against 'zpool upgrade' for the next few weeks.
https://svnweb.freebsd.org/base?view=revision&revision=364746
If you encounter problems please report them to me, Ryan Moeller, and -current.
--
Bob Bishop
On 8/22/20 7:39 PM, marco wrote:
On Sat, Aug 22, 2020 at 10:10:14PM +, you (marco) sent the following to
[freebsd-current] :
On Sat, Aug 22, 2020 at 04:48:48PM +, you (marco) sent the following to
[freebsd-current] :
On Sat, Aug 22, 2020 at 12:31:24PM -0400, you (Ryan Moeller) sent
On 8/22/20 12:27 PM, marco wrote:
On Sat, Aug 22, 2020 at 09:47:49AM -0400, you (Ryan Moeller) sent the following
to [freebsd-current] :
On 8/22/20 9:29 AM, Ryan Moeller wrote:
When switching from base ZFS to sysutils/openzfs 2020080800 the boot
process fails.
The most recent version
On 8/22/20 9:29 AM, Ryan Moeller wrote:
On 8/22/20 7:49 AM, marco wrote:
I'm running r364030.
[~] uname -apKU
FreeBSD harbinger 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r364030: Tue
Aug
11 07:15:59 UTC 2020
root@harbinger:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64
base ZFS to sysutils/openzfs 2020080800 the boot process
fails.
The most recent version (2020081800) fixes this.
-Ryan
These are the steps I took:
- bectl create r364030-OpenZFS
- bectl mount r364030-OpenZFS /mnt
- edit /mnt/boot/loader.conf to use openzfs_load="YES" instead of zf
I've reproduced this on the latest snapshot build of stable/12 and
created a PR here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248046
On 7/16/20 6:26 PM, Daniel Dettlaff wrote:
On 17.07.2020, at 00:16, Daniel Dettlaff wrote:
Hello, I heard it's known?
I built recent system from stab
t we used to do. I'm not sure how much benefit we would see from
option 3, but it's more work.
Ryan
>
>
> From: owner-freebsd-curr...@freebsd.org
> on behalf of Rick Macklem
> Sent: Thursday, June 18, 2020 11:42 PM
> To: Rya
e is changing the types of
the arguments.
freqlabs@ volunteered to do this upstream, but I don't know if/when
that gets applied to the port?
The port has already been updated, so update the ports tree checkout and
you should be good.
-Ryan
If you can fix this, simply replace:
zfs_che
please do upstream this! The FreeBSD snapshot for head used by the
CI bot was broken this week (in libc) so your change to the KPI has
managed to fly under the radar. We'll need this merged upstream before I
update the FreeBSD ports for OpenZFS. Thanks for the reminder!
test r358097 and earlier, to try and see what
> hangs
> occur. (I've done 8 cycles of testing of r356776 without difficulties, but
> that
> doesn't guarantee it isn't broken.)
>
> There is a bunch more of the stuff I got for Kostik and Ryan below.
> I can
On Wed, May 20, 2020 at 6:04 PM Rick Macklem wrote:
>
> Hi,
>
> Since I hadn't upgraded a kernel through the winter, it took me a while
> to bisect this, but r358252 seems to be the culprit.
>
> If I do a kernel build over NFS using my not so big Pentium 4 (single core,
> 1.25Gbytes RAM, i386), ab
> On Apr 17, 2020, at 4:56 PM, Pete Wright wrote:
>
> On 4/17/20 11:35 AM, Ryan Moeller wrote:
>> FreeBSD support has been merged into the master branch of the openzfs/zfs
>> repository, and the FreeBSD ports have been switched to this branch.
> Congratulations on thi
+ fi
+ done
zfs mount -va
zfs share -a
if [ ! -r /etc/zfs/exports ]; then
This will probably not be needed long-term. It is not necessary if the boot
pool is the only pool.
Happy testing :)
- Ryan
___
freebsd-c
t
causes a tunable to be set?
It looks like there's just an ordering bug in kern_sysctl.c, where we
call sysctl_register_all() with SI_SUB_KMEM, SI_ORDER_FIRST but we do
MALLOC_DEFINE() with SI_SUB_KMEM, SI_ORDER_THIRD. If
sysctl_register_all() is going to malloc(), it needs to run after
mall
On Thu, Jan 23, 2020 at 12:25 AM Rares Aioanei wrote:
>
> My bad, here's the link : https://imgur.com/45He1iy
>
> On Wed, Jan 22, 2020 at 8:04 PM Johan Hendriks wrote:
> >
> > These is no file attached. I think the mailing list stripped it off.
> > But i had an kernel panic also with Freebsd curr
I've noticed that on head, if I directly execute rtld to run an
executable, AT_EXECPATH contains the path to rtld on head (on
12.0-RELEASE it will contain nothing). This is causing me a problem
because clang uses AT_EXECPATH to preferentially locate where it's
installed, which it uses to locate it
On Fri, Dec 20, 2019 at 10:15 AM Konstantin Belousov
wrote:
>
> On Fri, Dec 20, 2019 at 09:51:15AM -0800, Ryan Libby wrote:
> > On Fri, Dec 20, 2019 at 9:31 AM Konstantin Belousov
> > wrote:
> > >
> > > On Fri, Dec 20, 2019 at 09:24:00AM -0800, John Baldwin
On Fri, Dec 20, 2019 at 9:31 AM Konstantin Belousov wrote:
>
> On Fri, Dec 20, 2019 at 09:24:00AM -0800, John Baldwin wrote:
> > On 12/19/19 12:06 PM, Ryan Libby wrote:
> > > On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote:
> > >>
> > >> In the int
On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote:
>
> In the interest of supporting newer versions of GCC for a base system
> toolchain, I've renamed the external GCC packages from -gcc
> to -gcc6. These are built as flavors of a new devel/freebsd-gcc6
> port. The xtoolchain package is not use
If I do a "make toolchain" with WITH_LLVM_TARGET_BPF=yes set in
/etc/src.conf on the latest head I get the following errors when it
tries to link clang. I believe that this was broken by the recent'ish
llvm update; it worked as of r351363 back in August.
ld: error: undefined symbol:
llvm::initial
I have a bhyve VM guest on my laptop where dtrace just constantly
aborts whenever I try to use it:
[rstone@ebpf dtrace]sudo dtrace -s fdcopy.d
Assertion failed: (buf->dtbd_timestamp >= first_timestamp), file
/usr/home/rstone/git/bsd-worktree/ebpf-import/cddl/contrib/opensolaris/lib/libdtrace/commo
On Wed, Nov 27, 2019 at 7:23 PM Ryan Libby wrote:
>
> On Wed, Nov 27, 2019 at 6:44 PM Michael Butler
> wrote:
> >
> > Something missing from a header here?
> >
> > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/uma_core.o
> > --- uma_core.o ---
> > /
On Wed, Nov 27, 2019 at 6:44 PM Michael Butler
wrote:
>
> Something missing from a header here?
>
> Building /usr/obj/usr/src/amd64.amd64/sys/VM01/uma_core.o
> --- uma_core.o ---
> /usr/src/sys/vm/uma_core.c:1864:39: error: use of undeclared identifier
> 'sysctl___vm_uma'
> zone->uz_oid =
I haven't found any good references on the subject, but here's my understanding:
- epoch_enter() and epoch_exit() are very inexpensive operations
(cheaper than mtx, rw_lock or rm_lock operations) that are use to mark
read-only critical sections
- epoch_wait() guarantees that no threads that were i
I notice that the following files have multiple entries in sys/conf/files:
$ cut -f 1 -w files | sort | uniq -c | egrep -v '^[[:space:]]+1[[:space:]]'
1373
100 #
2 crypto/chacha20/chacha.c
2 dev/iicbus/rtc8583.c
2 dev/uart/uart_dev_sab82532.c
2 dev/uart/uart_dev_z8530.c
The following patc
I have written a short test program that runs unlinkat(2) in
capability mode and fails due to not having the write capabilities:
https://people.freebsd.org/~rstone/src/unlink.c
If I run the binary under ktrace and look at the kdump output, it
gives the following incorrect output:
43775 unlink
Apply the patch and playing with increasing the value does allow
direct exec of ld via rtld to work. so thank you. The patch probably
shouldn't be applied as-is, though, as executables will just segfault
right away if the sysctl is tuned to a non-page aligned value.
___
If I try direct exec ld via rtld, I get the following failure:
# /libexec/ld-elf.so.1 /usr/bin/ld
ld-elf.so.1: /usr/bin/ld: mmap of entire address space failed: Cannot
allocate memory
Is there some sysctl limit I need to bump up to get around this? I
presume that the binary is just too large giv
As Conrad has pointed out, it's an explicit PID. The test completes
successfully when not run under truss -f.
On Fri, Sep 13, 2019 at 2:37 PM Mark Johnston wrote:
>
> On Fri, Sep 13, 2019 at 02:12:56PM -0400, Ryan Stone wrote:
> > This gets me a little further but now the
TDNAME KSTACK
705 100077 truss - mi_switch+0x174
sleepq_switch+0x110 sleepq_catch_signals+0x417 slee
pq_wait_sig+0xf _sleep+0x2d0 kern_wait6+0x48f sys_wait6+0x9f
amd64_syscall+0x337 fast_syscall_common+0x101
On Fri, Sep 13, 2019
I've hit an issue with a simple use of pdfork(). I have a process
that calls pdfork() and the parent immediately does a wait4() on the
child pid. This works fine under normal conditions, but if the parent
is run under truss -f, the three processes deadlock. If I switch out
pdfork() for fork(), t
On Wed, Aug 28, 2019 at 6:40 PM Ian Lepore wrote:
> Or maybe in your case the files are fine and it really is a uid
> problem. But a "pkg check -s -a" as suggested in the PR couldn't hurt.
> :)
I did have some problems here, but unfortunately re-installing the
affected packages (and confirming t
28, 2019 at 5:20 PM Gary Palmer wrote:
>
> On Wed, Aug 28, 2019 at 05:09:35PM -0400, Ryan Stone wrote:
> > Hi everybody,
> >
> > I lost /etc/master.passwd and friends while trying to recover from an
> > src upgrade gone wrong. I'm trying to run "pkg upgrade -f
Hi everybody,
I lost /etc/master.passwd and friends while trying to recover from an
src upgrade gone wrong. I'm trying to run "pkg upgrade -f" to get all
of the users and groups created by packages recreating, but pkg is
hitting an assert related to uids:
Checking integrity...Assertion failed: (
Historically when processing callchain events from hwpmc, you could
use PMC_CALLCHAIN_CPUFLAGS_TO_USERMODE(ev..pl_u.pl_cc.pl_cpuflags) to
distinguish callchains that were captured in user mode from those
captured in kernel mode. However, on 12.0-RELEASE and a month-old
head, I have noticed that th
Does this mean that it's currently impossible to build a world with
debug symbols?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebs
I'm trying to update an old (~May 2018) -head system to the latest,
but I'm getting a persistent error during buildworld:
ld: error: /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a:
could not get the member for symbol
_ZN5clang17MultiplexConsumerC1ENSt3__16vectorINS1_10unique_ptrINS_11A
How many VFs are you trying to create? Getting ENOSPC either
indicates that you tried to allocate more VFs than the hardware
supports, or the system could not allocate enough MMIO space for the
VFs.
On Thu, Aug 9, 2018 at 10:41 PM Pete Wright wrote:
>
> hello,
>
> i have a newly provisioned VPS s
On Sat, Aug 4, 2018 at 9:17 PM Erich Dollansky
wrote:
>
> Hi,
>
> I compiled me yesterday this system:
>
> 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r337285:
>
> When restarting fortune core dumps. When trying to load the core dump,
> gdb core dumps.
>
> The message is always:
>
> Bad system call (core
[Re-sending from my subscription address, sorry for the spam]
On Fri, Jun 29, 2018 at 1:26 PM, John Baldwin wrote:
> On 6/28/18 7:54 PM, Mark Millard wrote:
>> On 2018-Jun-28, at 6:04 PM, Mark Millard wrote:
>>
>>> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote:
>>>
[ ci.free.bsd.org jumpe
On Fri, Jun 29, 2018 at 1:26 PM, John Baldwin wrote:
> On 6/28/18 7:54 PM, Mark Millard wrote:
>> On 2018-Jun-28, at 6:04 PM, Mark Millard wrote:
>>
>>> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote:
>>>
[ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed)
for FreeBSD-h
I would guess that the calibration can fail because when running under
the hypervisor, the FreeBSD guest code can be descheduled at the wrong
time. As I recall, the current algorithm looks like:
1. Sample rdtsc
2. Use a fixed-frequency timer to busy-wait for exactly 1 second
3. Sample rdtsc again
Are you building with WITH_LD_IS_LLD=no? -CURRENT can no longer be
built with a GPLv2 ld. You either have to use ldd or install a newer
(GPLv3) binutils package.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/fre
On Tue, Apr 24, 2018 at 4:55 AM, Konstantin Belousov
wrote:
> +#ifndef MLX5E_MAX_RX_BYTES
> +#defineMLX5E_MAX_RX_BYTES MCLBYTES
> +#endif
Why do you use a 2KB buffer rather than a PAGE_SIZE'd buffer?
MJUMPAGESIZE should offer significantly better performance for jumbo
frames without incre
1 - 100 of 349 matches
Mail list logo
