Re: panic: VERIFY(ZFS_TEARDOWN_READ_HELD(zfsvfs)) failed

ny mail to "freebsd-current-unsubscr...@freebsd.org" > -- Mateusz Guzik ___ 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"

Re: zfs panic when 'make buildworld buildkernel'

> kern_openat() at kern_openat+0x25a/frame 0xfe004b286ad0 > amd64_syscall() at amd64_syscall+0x135/frame 0xfe004b286bf0 > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe004b286bf0 > --- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x805909caa, rsp = > 0x7

Re: zfs panic when 'make buildworld buildkernel'

On 10/13/20, Mateusz Guzik wrote: > On 10/13/20, YAMAMOTO Shigeru wrote: >> >> Hi, >> >> I try to 'make buildworld buildkernel' at full ZFS environment. >> But I can't finished buildworld/buildkernel without panic. >> Anyone have same trouble? >&

Re: zfs panic when 'make buildworld buildkernel'

hadd_int(, 1); this eventually wraps to 0 and then you get the crash. Probably the thing to do is ot bump it to 64 bit and 0-check on other platforms. -- Mateusz Guzik ___ 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"

Re: RFC: should copy_file_range(2) remain Linux compatible or support special files?

alents. I don't have a strong opinion on VCHR support. I will note there may be Linux code expecting to fail with such argument. If Linux-compatible approach mentioned above is not going to work out, I think the best thing to do is to add another syscall (copy_file_range_np?) which can be tweaked however we see fit. -- Mateusz Guzik ___ 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"

Re: installkernel: install: /usr/lib/debug/boot/kernel/: No such file or directory *** Error code 71

On 9/4/20, O. Hartmann wrote: > On Tue, 1 Sep 2020 19:21:36 +0200 > Mateusz Guzik wrote: > >> It's not my bug but i'll make sure it is taken care of. > > Oh, I'm sorry. But I grasp for every help I can get ... > > The problem is that I do not know whether the process

Re: installkernel: install: /usr/lib/debug/boot/kernel/: No such file or directory *** Error code 71

It's not my bug but i'll make sure it is taken care of. On 8/30/20, Hartmann, O. wrote: > On Fri, 28 Aug 2020 13:16:05 +0200 > Mateusz Guzik wrote: > >> On 8/28/20, Hartmann, O. wrote: >> > On Fri, 28 Aug 2020 12:31:21 +0200 >> > Mateusz Guzik wrote: >&g

Re: installkernel: install: /usr/lib/debug/boot/kernel/: No such file or directory *** Error code 71

On 8/28/20, Hartmann, O. wrote: > On Fri, 28 Aug 2020 12:31:21 +0200 > Mateusz Guzik wrote: > >> Can you show more of the log? >> >> When you installkernel you should see: >> mkdir -p /boot/kernel >> install -p -m 555 -o root -g wheel kernel /boot/kerne

Re: installkernel: install: /usr/lib/debug/boot/kernel/: No such file or directory *** Error code 71

usr/lib/debug/boot/kernel/ > install: /usr/lib/debug/boot/kernel/: No such file or directory *** >Error code 71 > > Stop. > make[4]: stopped in /usr/src/sys/modules/zfs > *** Error code 1 > *** Error code 1 > -- Mateusz Guzik ___ 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"

Re: 'chflags: fts_read: Permission denied' on fresh -CURRENT

Should be fixed with r364769. On 8/25/20, Roman Bogorodskiy wrote: > Yes, it allows to move further and build is currently running. > > Thanks > > Mateusz Guzik wrote: > >> Does: sysctl vfs.cache_fast_lookup=0 clean it up for you? >> >> On 8/25/2

Re: 'chflags: fts_read: Permission denied' on fresh -CURRENT

13.0-CURRENT 1300112 amd64 src=/usr/src 2020-08-25 > 13:17:30 /usr/local/poudriere/jails/current > current13 13.0-CURRENT 1300113 amd64 src=/usr/src 2020-08-25 > 16:19:13 /usr/local/poudriere/jails/current13 > > Any ideas what cou

Re: "panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341

On 8/18/20, Mark Johnston wrote: > On Tue, Aug 18, 2020 at 03:55:15PM +0200, Mateusz Guzik wrote: >> On 8/18/20, Mark Johnston wrote: >> > On Tue, Aug 18, 2020 at 03:24:52PM +0200, Mateusz Guzik wrote: >> >> Try this: >> >> >> >> diff -

Re: "panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341

On 8/18/20, Mark Johnston wrote: > On Tue, Aug 18, 2020 at 03:24:52PM +0200, Mateusz Guzik wrote: >> Try this: >> >> diff --git a/sys/kern/kern_malloc.c b/sys/kern/kern_malloc.c >> index 46eb1c4347c..7b94ca7b880 100644 >> --- a/sys/kern/kern_malloc.c >> ++

Re: "panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341

->periph_name, periph->unit_number); if (error != 0) { On 8/18/20, David Wolfskill wrote: > On Tue, Aug 18, 2020 at 03:24:52PM +0200, Mateusz Guzik wrote: >> Try this: >> [replacing new KASSERT() with WITNESS_WARN()...] >> > > Thanks; on it. Shoul

Re: "panic: malloc(M_WAITOK) in non-sleepable context" when inserting usb stick

t > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Mateusz Guzik ___ 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"

Re: "panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341

e), RANDOM_UMA); On 8/18/20, David Wolfskill wrote: > On Tue, Aug 18, 2020 at 02:48:47PM +0200, Mateusz Guzik wrote: >> see https://reviews.freebsd.org/D26027 >> > > Right; I was just reviewing the list of updated files and n

Re: "panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341

se that's useful). > > Peace, > david > -- > David H. Wolfskillda...@catwhisker.org > Donald Trump is either ignorant of how to govern or is refusing to do so. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > --

Re: r358503 breaks reroot

Fixed in r360374. On 4/27/20, Mateusz Guzik wrote: > Thanks for bisecting, I'll look into it. > > On 4/27/20, Ross Gohlke wrote: >> As of r358503, *reboot -r* no longer works for me. >> This is only tested on amd64. >> >> I produced a vanilla mini-memstick i

Re: r358503 breaks reroot

roy --vm=reroot > > Any suggested workarounds besides reverting to r358502? > > Any help appreciated, > Ross > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-un

Re: [package - head-amd64-default][sysutils/lsof] Failed for lsof-4.93.2_9,8 in build

process_node((KA_T)fd.fd_jdir); + process_node((KA_T)jdir); if (Lf->sf) link_lfile(); } -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listin

Re: [package - head-amd64-default][sysutils/lsof] Failed for lsof-4.93.2_9,8 in build

-DHASFDESCFS=2 > -DHASPSEUDOFS -DHASNULLFS -DHASIPv6 -DHASUTMPX -DHAS_STRFTIME > -DLSOF_VSTR="13.0-CURRENT" -I/usr/src/sys -O2 -c lkud.c -o lkud.o > --- dproc.o --- > dproc.c:350:24: error: no member named 'fd_cdir' in 'struct filedesc' > if (!ckscko && f

Re: Panic with ataintel and not ready CD on a Dell r710@r357958

c/sys/cam/cam_xpt.c:5515 >> #11 0x80483200 in fork_exit (callout=0x823d0cc0 >> , >> arg=0x8243d780 , frame=0xfe01fb9a1d40) >> at /usr/src/sys/kern/kern_fork.c:1059 >> #12 >> (kgdb) >> >> >> Core IS available as

Re: option KDTRACE_HOOKS non-optional after r357912?

later but preferably someone familiar with the build system would take care of it. It comes with some overhead of course since there is no hot patching, but it is unlikely you will be able to measure it because of other factors. -- Mateusz Guzik ___ freebsd-

Re: r357907 seems to have broken sys/kern/vfs_default.c

What if McConnell had voted to convict Trump in the impeachment "trial?" > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > -- Mateusz Guzik ___ 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"

Re: Can't cross-compile HEAD

being treated as errors > --- opendir.o --- > *** [opendir.o] Error code 1 > > make[4]: stopped in /usr/home/pavel.timofeev/mips/head/libexec/rtld-elf > 1 error > This one is mine. You are one revision short of the build fix in r356832 -- Mateusz Guzik

Re: FreeBSD-head-amd64-test - Build #13912 (r356671) - Failure

Fixed in r356683. On 1/13/20, Mateusz Guzik wrote: > On 1/13/20, Li-Wen Hsu wrote: >> On Mon, Jan 13, 2020 at 1:10 PM wrote: >>> >>> FreeBSD-head-amd64-test - Build #13912 (r356671) - Failure >>> >>> Build information: >>> https://ci.f

Re: FreeBSD-head-amd64-test - Build #13912 (r356671) - Failure

xf80003e35120 > tssp = 0x82211384 > rsp0 = 0xfe0038a71580 > kcr3 = 0x8f2ab405 > ucr3 = 0x8f287c05 > scr3 = 0xf287c05 > gs32p= 0x82211404 > ldt =

Re: DRM-current-kmod is still a problem at r353339

This can happen if there is a mismatch between the kernel and the module itself. > > On ds., oct. 12 2019, Mateusz Guzik wrote: > >> Try this: >> >> https://people.freebsd.org/~mjg/pmap-fict-invl.diff > > > I tested this patch on top of r353449 and a panic is st

Re: DRM-current-kmod is still a problem at r353339

-ec52-11e9-9c3b-902f49e311de.png > > As of now, I'm using an older kernel. > > -Neel > > === > > https://www.neelc.org/ > > On 2019-10-11 10:28, Thomas Laus wrote: >> On 2019-10-10 13:44, Mateusz Guzik wrote: >>> Probably whitespace issues from copypasting. I use

Re: DRM-current-kmod is still a problem at r353339

Probably whitespace issues from copypasting. I used dpaste since people.freebsd.org was down. It's up, so: https://people.freebsd.org/~mjg/pmap-fict3.diff On 10/10/19, Thomas Laus wrote: > On 2019-10-10 12:21, Mateusz Guzik wrote: >> Try this: >> >> http://dpaste.com/0P2M

Re: DRM-current-kmod is still a problem at r353339

have a photo of the panic that I can send. > > Tom > > > -- > Public Keys: > PGP KeyID = 0x5F22FDC1 > GnuPG KeyID = 0x620836CF > ___________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman

Re: DRM (i915kms) panic on r353303

owner-freebsd-curr...@freebsd.org] Meghatalmazó Mateusz Guzik > Küldve: 2019. október 8. 15:15 > Címzett: Renato Botelho > Másolatot kap: freebsd-current > Tárgy: Re: DRM (i915kms) panic on r353303 > > Try this: > > https://people.freebsd.org/~mjg/pmap-nosparse.diff > > On 1

Re: DRM (i915kms) panic on r353303

t; 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" > -- Mateusz Guzik ___ freebsd-current@freebsd.org m

Re: pseudofs broken(?) with r351741

h (sleepable after non-sleepable) > >     Sponsored by:   The FreeBSD Foundation > > Notes: >     svn path=/head/; revision=351741 > > > > -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.

Re: panic: No vop_need_inactive

--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80049f2da, rsp = > 0x7fffc948, rbp = 0x7fffc9c0 --- > KDB: enter: panic > > > Anyone can help? > > > -- > Guido Falsi > _______ > freebsd-current@freebsd.org mailing list > h

funny pathname lookups from the compiler

course, but it does look like a waste. -- Mateusz Guzik ___ 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"

Re: "df /" output missing "Filesystem" after r351187 -> r351211

lesystem" data to be elided. > Should be fixed with r351215 https://svnweb.freebsd.org/base?view=revision=351215 -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To

Re: userret: assert td_lk_slocks == 0

prevent more readers from showing up. However, this can lead to deadlocks so if someone already has a read lock on something, they can bypass the bit and grab the extra read lock anyway. No locks are allowed to leak back to userspace and witness should already handles checking this for readers

Re: Do the pidhashtbl_locks added by r340742 need to be sx locks?

On 4/11/19, Rick Macklem wrote: > Mateusz Guzik wrote: >>On 4/11/19, Rick Macklem wrote: >>> Hi, >>> >>> I finally got around to looking at what effect replacing pfind_locked() >>> with >>> pfind() has for the NFSv4 client and it is broken.

Re: Do the pidhashtbl_locks added by r340742 need to be sx locks?

manner and just performs a timestamp check to see if it got the one it expected (with pid reuse in mind). So I think a temporary hack which will do the trick will take the current approach further: rely on struct proc being type-stable (i.e. never being freed) and also store the pointer. You can alw

Re: head -r3418363: top -opid process list order is rather odd (top -Saopid example shown)

atch. >> > > I'm a long term top user and it used to work. For example, when I was > running > head -r340287 it worked as I remember. (I recreated such a vintage recently > for a test of something else. The -opid ordering was coherent as I > remember, > unlike the above.) > > It historically seemed to track the time order of process creation, even > around the PID > number wrapping around. (So not a strict PID sort, at least for the PID > shown.) This > was handy for monitoring buildworld buidkernel and port builds (all > parallel). > > I'll probably try the patch when I have a chance, even if it does strict PID > number > order. Thanks. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > ___ > 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" > -- Mateusz Guzik ___ 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"

Re: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system

on? Most importantly, does this show up with a 12.0 kernel? I'm running one amd box and a number of intel boxes with various cpus, no issues. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/lis

Re: rm cannot recursively delete directory on tmpfs on RPi2

On 12/7/18, Michal Meloun wrote: > > > On 07.12.2018 7:25, Mateusz Guzik wrote: >> On 12/7/18, Jia-Shiun Li wrote: >>> On Fri, Dec 7, 2018 at 12:36 AM Alan Somers wrote: >>> >>>> On Wed, Dec 5, 2018 at 10:18 PM Jia-Shiun Li >>>>

Re: rm cannot recursively delete directory on tmpfs on RPi2

/systm.h @@ -523,7 +523,7 @@ int alloc_unr_specific(struct unrhdr *uh, u_int item); int alloc_unrl(struct unrhdr *uh); void free_unr(struct unrhdr *uh, u_int item); -#if defined(__mips__) || defined(__powerpc__) +#ifndef __LP64__ #define UNR64_LOCKED #endif -- Mateusz Guzik ___ 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"

Re: fuser does not list id of processes that have a file

does not resolve the problem for me. > Are you sure you recompiled and reinstalled the tool with the patch applied? You can recompile and install like this: # make -j 3 clean all install If this indeed still does not work, can you show output of: uname -m mount I tested on

Re: fuser does not list id of processes that have a file

name; STAILQ_HEAD(, consumer) consumers; -- Mateusz Guzik ___ 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"

Re: Strange panic at boot with vmm in loader.conf vs manually loading it

to pop in another drive or can I do a netdump at this point ? > This should be fixed with https://svnweb.freebsd.org/changeset/base/339355 i.e. just update. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org

Re: vmstat -m and netstat -m dumping core when run on vmcores

crt1.c:74 >> >> Wonder if it's just me or something is broken here? > > I think this is due to r338899. libmemstat needs an adjustments to handle > that. > Indeed, I'll take care of it. Thanks for the report. -- Mateusz Guzik ___ 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"

Re: Panic from ipfw_alloc_rule() after r334769 -> r334832

his bug and needs to get a working system in the > meantime, you'll need to revert the following commits which implemented (or > updated) this change: > > r334830 > r334829 > r334824 > > Jonathan > -- Mateusz Guzik ___ 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"

Re: r334533 renders head unbootable on XenServer 7.4

the committer - not everyone watches mailing lists too closely. I set it up on FreeBSD as dom0 and verified the problem exists. I fixed it with the following: https://svnweb.freebsd.org/changeset/base/334820 -- Mateusz Guzik ___ freebsd-current@free

Re: Error build nvidia-driver with r334555

memcmp +#undefmemmove +#undefmemcpy +#undef memset #include -- Mateusz Guzik ___ 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"

Re: top: sysctl(vfs.bufspace...) expected 8, got 4

_handle_long(oidp, , 0, req)); > } > #endif Thanks for testing, committed in r329837. -- Mateusz Guzik ___ 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"

Re: top: sysctl(vfs.bufspace...) expected 8, got 4

On Thu, Feb 22, 2018 at 6:41 PM, O. Hartmann wrote: > Am Wed, 21 Feb 2018 20:05:24 +0100 > "O. Hartmann" schrieb: > > > On CURRENT ( 12.0-CURRENT FreeBSD 12.0-CURRENT #196 r329679: Tue Feb 20 > 23:06:15 CET > > 2018 amd64) I'm honored by this

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

Committed in https://svnweb.freebsd.org/base?view=revision=329660 thanks for reporting On Tue, Feb 20, 2018 at 6:06 PM, Mateusz Guzik <mjgu...@gmail.com> wrote: > I missed a consumer, try this: > > diff --git a/sys/kern/sys_procdesc.c b/sys/kern/sys_procdesc.c > index 5e8928cb

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

e1aaef in acpi_cpu_idle_mwait (mwait_hint=0) at > cpufunc.h:611 > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > > kgdb is over my head, but I can provide more details under some guidance. > > Hope it helps, > Juan > > -- Mateusz Guzik ___ 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"

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

I committed the fix in https://svnweb.freebsd.org/base?view=revision=329542 i.e. should be stable from this point on. On Sun, Feb 18, 2018 at 11:55 PM, Mateusz Guzik <mjgu...@gmail.com> wrote: > On Sun, Feb 18, 2018 at 11:24 PM, Trond Endrestøl < > trond.endres...@fagskolen.g

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

On Sun, Feb 18, 2018 at 11:24 PM, Trond Endrestøl < trond.endres...@fagskolen.gjovik.no> wrote: > On Sun, 18 Feb 2018 22:33+0100, Mateusz Guzik wrote: > > > On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrestøl < > > trond.endres...@fagskolen.gjovik.no> wrote: > >

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

On Sun, Feb 18, 2018 at 10:50 PM, Mark Millard <marklmi26-f...@yahoo.com> wrote: > > > On 2018-Feb-18, at 1:46 PM, Mark Millard <marklmi26-f...@yahoo.com> wrote: > > > On 2018-Feb-18, at 1:33 PM, Mateusz Guzik <mjgu...@gmail.com> wrote: > > > >&g

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

29447 works then the issue should be already fixed and in particular fresh head should work fine. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

t; sys_vfork() at sys_vfork+0x4c/frame 0xfe00f1130980 > amd64_syscall() at amd64_syscall+0xa48/frame 0xfe00f1130ab0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffc5a0 > > > > > === > Mark Millard > marklmi at yahoo.com > ( markmi at dsl-only.net is > going away in 2018-Feb, late) > > ___ > 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" > -- Mateusz Guzik ___ 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"

Re: witness_lock_list_get: witness exhausted

U's to a guest and as > much > RAM as I want, I do like to help with edge cases if I can make them occur > pushing > boundaries as I can towards additianional improvements in FreeBSD. > Can you apply this and re-run the test? https://people.freebsd.org/~mjg/witness.diff It bumps the

Re: SVN r325920 breaks build

_mutex.c:1015:6: error: use of undeclared > identifier 'v' > if (v & MTX_RECURSED) { > ^ > /usr/src/sys/kern/kern_mutex.c:1024:6: error: use of undeclared > identifier 'v' > if (v == tid && _mtx_release_lock(m, tid)) > ^ >

Re: There is *NO* abi stability in -head

On Tue, Oct 24, 2017 at 10:47 AM, Hans Petter Selasky <h...@selasky.org> wrote: > On 10/23/17 22:35, Mateusz Guzik wrote: > >> This is your friendly reminder that in head struct layouts can change >> and each update requires you to rebuild *all* modules (including ones

There is *NO* abi stability in -head

to be evicted. For interested parties I can't recommend enough: https://www.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo

Re: Build failure: non-SMP after SVN r324778

nction declaration is > not a prototype [-Werror,-Wstrict-prototypes] > 2 errors generated. > *** [kern_mutex.o] Error code 1 > > oops, fixed in r324803. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org

Re: pfind_locked(pid) fails when in a jail?

calling it in the first place. The calls I grepped in nfscl_procdoesntexist are highly suspicious - there is no guarantee the process you found here is the same you had at the time you were saving the pid. There is no usable process exit notification right now, but it can be added if necessary. -- Mateu

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

On Wed, Mar 01, 2017 at 09:45:07AM -0800, Mark Millard wrote: > > On 2017-Feb-28, at 10:13 PM, Mateusz Guzik wrote: > > On Sat, Feb 25, 2017 at 08:31:04PM +0100, Mateusz Guzik wrote: > >> On Sat, Feb 25, 2017 at 09:58:39AM -0800, Mark Millard wrote: > >>> Thu

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

On Sat, Feb 25, 2017 at 08:31:04PM +0100, Mateusz Guzik wrote: > On Sat, Feb 25, 2017 at 09:58:39AM -0800, Mark Millard wrote: > > Thus the PowerMac G5 so-called "Quad Core" is back to > > -r313254 without your patches. (The "Quad Core" really has &g

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

k what to do with it, worst case I'll #ifdef changes with powerpc. -- Mateusz Guzik ___ 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"

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

On Tue, Feb 21, 2017 at 01:37:25AM -0800, Mark Millard wrote: > [Back to the powerpc64 context.] > > On 2017-Feb-20, at 11:10 AM, Mateusz Guzik <mjgu...@gmail.com> wrote: > > > On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard wrote: > >> [Note: I expe

Re: Laptop very sluggish diring smoke-test @r314036

> magnitude of a slowdown overall. > Can you check if the problem IS NOT present on r313995 but IS present on r313996? Only rebuilding the kernel + modules is necessary. If the problem was not introduced by r313996 I'm afraid you will have to bisect. -- Mateusz Guzik ___

Re: weird panic at mount

you recompile your modules? Several fields seem off by a multiply of 8 bytes, which coincidently fits r313992. -- Mateusz Guzik ___ 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"

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

gt; and 2100021 for the kernel and world for -r313999, > just like for -r313864. > I think this is r313992. I don't see why __FreeBSD_version would be modified for this. You are expected to always recompilel your modules while tracking -curren

Re: drm2, i915kms cause instant lock-up

On Mon, Feb 20, 2017 at 04:43:40PM -0800, Steve Kargl wrote: > On Tue, Feb 21, 2017 at 12:58:07AM +0100, Mateusz Guzik wrote: > > On Mon, Feb 20, 2017 at 03:52:24PM -0800, Steve Kargl wrote: > > > With a kernel and world from r313943 sources (circa > > > Feb 19, 2017)

Re: drm2, i915kms cause instant lock-up

ches/complete-locks.diff and check if it breaks If it does not break, revert the patch and bisect the kernel please. Otherwise I'll devise smaller diffs to narrow this down. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.free

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

On Mon, Feb 20, 2017 at 03:10:44PM -0800, Mark Millard wrote: > On 2017-Feb-20, at 2:58 PM, Mark Millard <mar...@dsl-only.net> wrote: > > > On 2017-Feb-20, at 11:10 AM, Mateusz Guzik wrote: > > > >> On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

spin mutexes were not properly handling this, fixed in r313996. Locally I added a if (cpu_tick() % 2) return (0); snipped to amd64 fcmpset to simulate failures. Everything works, while it would easily fail without the patch. That said, I hope this concludes the 'missing check for not-reread v

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

On Sat, Feb 18, 2017 at 01:58:49PM -0800, Mark Millard wrote: > On 2017-Feb-18, at 12:58 PM, Mateusz Guzik wrote: > > Well either the primitive itself is buggy or the somewhat (now) unusual > > condition of not providing the failed value (but possibly a stale one) > > is

Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

might be exposed by > the extra checks). > Well either the primitive itself is buggy or the somewhat (now) unusual condition of not providing the failed value (but possibly a stale one) is not handled correctly in locking code. That said, I would start with putting barriers "on bot

Re: Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

On Thu, Oct 27, 2016 at 09:09:16PM +0800, Ben Woods wrote: > On 24 September 2016 at 18:13, Ben Woods <woods...@gmail.com> wrote: > > > On 22 September 2016 at 21:01, Mateusz Guzik <mjgu...@gmail.com> wrote: > > > >> On Thu, Sep 22, 2016 at 08:48:

Re: r312602: panic: Panic String: __lockmgr_args: unknown lockmgr request 0x0

On Sat, Jan 21, 2017 at 08:45:55PM +0100, O. Hartmann wrote: > The most recent CURRENT panics spontanously and crashes with the error > message: > > > Panic String: __lockmgr_args: unknown lockmgr request 0x0 > That's a braino in r312600, will be fixed shortly.

Re: panic: mutex ncnegl not owned at /usr/src/sys/kern/vfs_cache.c:743 in 12.0-CURRENT r308447

} } - if (!(ncp->nc_flag & NCF_NEGATIVE)) { - TAILQ_REMOVE(>nc_vp->v_cache_dst, ncp, nc_dst); - if (ncp == ncp->nc_vp->v_cache_dd) - ncp->nc_vp->v_cac

Re: panic: mutex ncnegl not owned at /usr/src/sys/kern/vfs_cache.c:743 in 12.0-CURRENT r308447

race where the entry is demoted and loses the HOTNEGATIVE. But the demotion code has the hot list locked and so does this code if it spots the flag. What's more, the race is handled by re-checking the flag after the lock was taken. That said, there is something seriously fishing going on here. -- Mateusz Guzik ___ 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"

Re: Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

On Thu, Sep 22, 2016 at 03:01:41PM +0200, Mateusz Guzik wrote: > On Thu, Sep 22, 2016 at 08:48:29PM +0800, Ben Woods wrote: > > #13 0x80b4d91c in turnstile_broadcast (ts=0x0, queue=1) at > > /usr/src/sys/kern/subr_turnstile.c:837 > > #14 0x80ae5e1f in

Re: Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

at /usr/src/sys/kern/kern_rwlock.c:1027 can you please: f 14 x/xg c -- Mateusz Guzik ___ 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"

Re: Panic @r305116 in transition to multi-user mode

x7fffe7f0 --- > db> dump > Dumping 1299 out of 32687 MB:..2%..12%..21%..31%..41%..51%..61%..71%..81%..92% > Dump complete > db> > This is most likely r305091 which I reverted in r305124, i.e. just upgrade and see if it helps. Sorry for trouble, -- Mateusz Guzik _

Re: SVN r303643 breaks non-SMP compilation

or reporting. -- Mateusz Guzik ___ 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"

Re: [PATCH] randomized delay in locking primitives, take 2

On Mon, Aug 01, 2016 at 11:37:50AM -0700, John Baldwin wrote: > On Sunday, July 31, 2016 02:41:13 PM Mateusz Guzik wrote: > > On Sun, Jul 31, 2016 at 01:49:28PM +0300, Konstantin Belousov wrote: > > [snip] > > > > After an irc discussion, the following was produced (a

Re: [PATCH] randomized delay in locking primitives, take 2

On Mon, Aug 01, 2016 at 09:38:09AM -0700, Maxim Sobolev wrote: > On Sun, Jul 31, 2016 at 1:36 PM, Mateusz Guzik <mjgu...@gmail.com> wrote: > > > On Sun, Jul 31, 2016 at 07:03:08AM -0700, Adrian Chadd wrote: > > > Hi, > > > > > > Did you tes

Re: [PATCH] randomized delay in locking primitives, take 2

ere. > The patch is the simplest hack possible so that this has a chance of getting into 11.0 as it helps /a lot/ even in the simplest form. Revamping this stuff in a more "here to stay" manner is a much longer endeavor. -- Mateusz Guzik ___ free

Re: [PATCH] randomized delay in locking primitives, take 2

% operation acts a randomizer. It is optional and I'm happy to ifdef it based on the architecture. It does seem to be useful at least on amd64. As a side note, exponential backoff is not used to keep things smaller (see above). It is definitely subject to ch

Re: [PATCH] randomized delay in locking primitives, take 2

On Sun, Jul 31, 2016 at 01:49:28PM +0300, Konstantin Belousov wrote: [snip] After an irc discussion, the following was produced (also available at: https://people.freebsd.org/~mjg/lock_backoff_complete4.diff): Differences: - uint64_t usage was converted to u_int (also see r303584) - currently

[PATCH] randomized delay in locking primitives, take 2

The patch can be found inline below and also here: https://people.freebsd.org/~mjg/lock_backoff_complete.diff The previous version of the patch was posted here: https://lists.freebsd.org/pipermail/freebsd-current/2016-July/062320.html This time around instead of a total hack I have something of

Re: [PATCH] microoptimize locking primitives by introducing randomized delay between atomic ops

On Sun, Jul 10, 2016 at 08:32:01AM -0600, Ian Lepore wrote: > On Sun, 2016-07-10 at 13:13 +0200, Mateusz Guzik wrote: > > If the lock is contended, primitives like __mtx_lock_sleep will spin > > checking if the owner is running or the lock was freed. The problem >

Re: [PATCH] microoptimize locking primitives by introducing randomized delay between atomic ops

On Sun, Jul 10, 2016 at 03:22:47PM +0300, Konstantin Belousov wrote: > On Sun, Jul 10, 2016 at 01:13:26PM +0200, Mateusz Guzik wrote: > > If the lock is contended, primitives like __mtx_lock_sleep will spin > > checking if the owner is running or the lock was freed. The problem i

[PATCH] microoptimize locking primitives by introducing randomized delay between atomic ops

If the lock is contended, primitives like __mtx_lock_sleep will spin checking if the owner is running or the lock was freed. The problem is that once it is discovered that the lock is free, multiple CPUs are likely to try to do the atomic op which will make it more costly for everyone and

Re: [PATCH] microoptimize locking primitives by avoiding unnecessary atomic ops

On Fri, May 27, 2016 at 04:21:11PM -0700, John Baldwin wrote: > On Friday, May 27, 2016 09:17:01 PM Mateusz Guzik wrote: > > Hello there, > > > > quite some time ago I posted a trivial patch to locking primitives. What > > they do is the inline part tries an

[PATCH] microoptimize locking primitives by avoiding unnecessary atomic ops

Hello there, quite some time ago I posted a trivial patch to locking primitives. What they do is the inline part tries an atomic op and if that fails the actual function is called, which immediately tries the same op. The obvious optimisation checks for the availability of the lock first. There

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

er the systems remain stable. > Thanks, fix committed in https://svnweb.freebsd.org/base?view=revision=292440 -- Mateusz Guzik ___ 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"

Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode

On Thu, Dec 17, 2015 at 02:33:46PM -0800, Don Lewis wrote: > On 17 Dec, Mateusz Guzik wrote: > > On Thu, Dec 17, 2015 at 11:48:08AM -0800, Don Lewis wrote: > >> On 17 Dec, Konstantin Belousov wrote: > >> > On Wed, Dec 16, 2015 at 11:08:02AM -0800, Don Lewis wrote:

<    1   2   3   >