Re: NFSv4 crash of CURRENT

Rick, I can confirm Kostik’s fix works on 13-stable. Peter > On 15 Jan 2024, at 16:13, Peter Blok wrote: > > I can give it a shot on one of my clients. > >> On 15 Jan 2024, at 16:04, Rick Macklem > <mailto:rick.mack...@gmail.com>> wrote: >> >>

Re: NFSv4 crash of CURRENT

I can give it a shot on one of my clients. > On 15 Jan 2024, at 16:04, Rick Macklem wrote: > > On Mon, Jan 15, 2024 at 2:53 AM Peter Blok <mailto:pb...@bsd4all.org>> wrote: >> >> Hi, >> >> Forgot to mention I’m on 13-stable. The fix that is

Re: NFSv4 crash of CURRENT

(cherry picked from commit 70dc6b2ce314a0f32755005ad02802fca7ed186e) When I remove the fix, the problem is gone. Add it back and the crash happens. Peter > On 15 Jan 2024, at 09:31, Peter Blok wrote: > > Hi, > > I do have a crash on a NFS client with

Re: NFSv4 crash of CURRENT

. If I plainly mount ports on /usr/ports and do the same everything works. I am using NFSv3 Peter Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 04 fault virtual address = 0x89 fault code = supervisor read data, page not present instruction pointer = 0x20

Re: Review of patch that uses "volatile sig_atomic_t"

rticles/article.aspx?p=2204014 Ah well, time to relearn C again :-) (K C was simpler :-) - Peter > On 2 Aug 2023, at 10:12, David Chisnall wrote: > > On 2 Aug 2023, at 00:33, Rick Macklem wrote: >> >> Just trying to understand what you are suggesting.

Re: Possible PEBKAC bug for fwget(8)?

l-size PCI or PCIe connector in your laptop, it's very likely that it has a Mini PCIe connector for the WiFi adapter. Even without that, there are virtual PCI buses inside your CPU chip - have a look at the output of "pciconf -lv". -- Peter Jeremy signature.asc Description: PGP signature

Re: panic: ASan: Invalid access, 1-byte read at ...

On Wed, Jun 21, 2023 at 10:06:28AM -0400, Mark Johnston wrote: > On Wed, Jun 21, 2023 at 11:53:44AM +0200, Peter Holm wrote: > > Just got this panic: > > > > 20230621 11:15:23 all (37/912): linux.sh > > panic: ASan: Invalid access, 1-byte read at 0xfe020bd7

panic: ASan: Invalid access, 1-byte read at ...

--- syscall (2, Linux ELF64, linux_open), rip = 0x8012ef7f0, rsp = 0x7fffa238, rbp = 0x7fffa290 --- KDB: enter: panic [ thread pid 31838 tid 100363 ] Stopped at kdb_enter+0x34: movq$0,0x1e3f7c1(%rip) db> Details @ https://people.freebsd.org/~pho/stress/log/log0450.txt - Peter

ntpd fails on recent -current/arm64

nd, beyond much of netinet being roto-tilled, I can't see anything obvious. Is anyone else seeing anything similar? Can anyone suggest where to look next? -- Peter Jeremy signature.asc Description: PGP signature

Re: RFC: nfsd in a vnet jail

Keep the global variables as defaults that apply to all nfsds and allow (at least some subset) to be overridden inside the net jails if some things need to be changed from the defaults? - Peter On Fri, Nov 25, 2022, 4:24 PM Rick Macklem mailto:rick.mack...@gmail.com>> wrote: > Hi

Re: Beadm can't create snapshot

bootfs. (And ideally, a similar check of /etc/fstab, though beadm doesn't touch that). -- Peter Jeremy signature.asc Description: PGP signature

Re: Beadm can't create snapshot

On 2022-Aug-22 10:56:51 +0200, "Patrick M. Hausen" wrote: >> Am 22.08.2022 um 10:45 schrieb Peter Jeremy : >> On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen" wrote: >>> Isn't beadm retired in favour of bectl? >> >> 2) "bectl activat

Re: Beadm can't create snapshot

g) git commit hashes as the name. 2) "bectl activate" doesn't update /boot/loader.conf so the wrong root filesystem is mounted. That said "bectl create" appears to be a workable replacement for "beadm create" and avoids the current "'snapshots_changed' is readonly

Re: recover deleted file

time replication of the MySQL redo logs to another systems - though that won't necessarily protect you from someone accidently doing a "DELETE FROM xxx;" or "DROP TABLE xxx;" -- Peter Jeremy signature.asc Description: PGP signature

Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled?

hang was somewhere between https://cgit.freebsd.org/src/tree/sys/kern/vfs_mountroot.c#n779 and https://cgit.freebsd.org/src/tree/sys/kern/vfs_mountroot.c#n1008 which led me to suspect that the problem might be in the geom layer (eg g_waitidle()) but was still considering where to add my next tranche of printf's when I saw Mark's mail. -- Peter Jeremy signature.asc Description: PGP signature

Panic in pipe_write from syslogd in 12.2?

80c5ce1d at sys_sendto+0x4d #14 0x8108f4c7 at amd64_syscall+0x387 #15 0x8106754e at fast_syscall_common+0xf8 Uptime: 212d21h35m47s - Peter

Re: Install to ZFS root is using device names hence failing when device tree is changed.

ks for ZFS labels on all possible devices. -- Peter Jeremy signature.asc Description: PGP signature

Re: Files in /etc containing empty VCSId header

reis netif netif: /usr/src/libexec/rc/rc.d/netif server% whereis services services: /usr/src/contrib/unbound/services Is your source tree somewhere other than /usr/src? -- Peter Jeremy signature.asc Description: PGP signature

pam_radius fails after the latest libradius security patch...

or pam_radius but the only thing changed is libradius. And if I replace libradius.so.4 with the previous version things work again... (Considering the spagetti code that sudo is I wouldn’t be surprised if the bug is there but still…) Am I the only one seeing this? - Peter

Re: RFC: changing the default NFSv4 minor version?

I vote for this. +1 - Peter > On 14 May 2021, at 01:02, Rick Macklem wrote: > > Hi, > > I believe that NFSv4.1 and NFSv4.2 are now mature in freebsd-current/main. > I also believe that NFSv4.1/4.2 is a better protocol than NFSv4.0. > (In particular, the sessions mechan

panic: general protection fault

() at swi_net+0x1a1/frame 0xfe00e49b0b20 ithread_loop() at ithread_loop+0x279/frame 0xfe00e49b0bb0 fork_exit() at fork_exit+0x80/frame 0xfe00e49b0bf0 https://people.freebsd.org/~pho/stress/log/log0092.txt - Peter ___ freebsd-current

Re: panic: malloc(M_WAITOK) with sleeping prohibited with main-n245383-15565e0a2177

On Thu, Mar 11, 2021 at 12:56:02PM -0500, Mark Johnston wrote: > On Thu, Mar 11, 2021 at 06:32:13PM +0100, Peter Holm wrote: > > I just got this panic: > > > > panic: malloc(M_WAITOK) with sleeping prohibited > > cpuid = 0 > > time = 1615472733 > > KDB: sta

panic: malloc(M_WAITOK) with sleeping prohibited with main-n245383-15565e0a2177

0xfe00e4974b20 ithread_loop() at ithread_loop+0x279/frame 0xfe00e4974bb0 fork_exit() at fork_exit+0x80/frame 0xfe00e4974bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe00e4974bf0 https://people.freebsd.org/~pho/stress/log/log0078.txt - Peter

Re: panic: malloc(M_WAITOK) with sleeping prohibited

On Wed, Mar 10, 2021 at 01:33:34PM +0100, Hans Petter Selasky wrote: > On 3/10/21 12:41 PM, Peter Holm wrote: > > On Wed, Mar 10, 2021 at 10:52:53AM +0100, Hans Petter Selasky wrote: > >> On 3/10/21 10:15 AM, Peter Holm wrote: > >>> I just got this panic: > &g

Re: panic: malloc(M_WAITOK) with sleeping prohibited

On Wed, Mar 10, 2021 at 10:52:53AM +0100, Hans Petter Selasky wrote: > On 3/10/21 10:15 AM, Peter Holm wrote: > > I just got this panic: > > > > igb0: port 0xd020-0xd03f mem > > 0xfb32-0xfb33,0xfb344000-0xfb347fff irq 16 at device 0.0 on pci8 > > igb0: U

panic: malloc(M_WAITOK) with sleeping prohibited

: Wed Mar 10 10:00:29 CET 2021\012 p...@mercat1.netperf.freebsd.org:/usr/src/sys/amd64/compile/PHO\012 db> - Peter ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any m

Re: geli broken in 13.0-BETA4 and later on armv8

On 2021-Mar-06 10:39:02 -0800, Oleksandr Tymoshenko wrote: >Peter Jeremy via freebsd-current (freebsd-current@freebsd.org) wrote: >> [Adding arm@ and making it clearer that this is armv8-only] >> >> On 2021-Mar-06 20:26:19 +1100, Peter Jeremy >> wrote: >> >

Re: geli broken in 13.0-BETA4 and later on armv8

[Adding arm@ and making it clearer that this is armv8-only] On 2021-Mar-06 20:26:19 +1100, Peter Jeremy wrote: >On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable > wrote: >>Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4 >>(releng/13.0-n244592-

Re: geli broken in 13.0-BETA4 and later

On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable wrote: >Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4 >(releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 - >RK3399, arm64) has changed so that a geli-encrypted partition (using >

Re: r367672 broke the NFS server

ll start working on this to-day, but I have no idea how long it might > > take? > > > > >I am sorry I forgot about NFS server when designing this fix, the only > > >mild excuse I can provide is that the change was quite complicated as is. > > >I will start loo

Re: panic: general protection fault from uipc_sockaddr+0x4c

On Tue, Dec 08, 2020 at 10:30:41AM -0500, Mark Johnston wrote: > On Tue, Dec 08, 2020 at 12:47:18PM +0100, Peter Holm wrote: > > I just got this panic: > > > > Fatal trap 9: general protection fault while in kernel mode > > cpuid = 9; apic id = 09 > > instruction

panic: general protection fault from uipc_sockaddr+0x4c

0xfe0698887bf0 --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8003948ea, rsp = 0x7fffc138, rbp = 0x7fffc170 --- https://people.freebsd.org/~pho/stress/log/log0004.txt - Peter ___ freebsd-current@freebsd.org mailing list https

r367927 buildkernel stops on isp.o undeclared ATPDPSIZE

2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG /Peter ___ 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: review of new mountd option disabling use of rpcbind

Suggestion: Add a check for sysctl vfs.nfsd.server_min_nfsvers and if set to 4 or higher - automatically enable the “-R” option. - Peter > On 20 Oct 2020, at 02:56, Rick Macklem wrote: > > Hi, > > I've put a patch up on phabricator that adds a new option to mountd >

Re: vnet/jail crashdump

eebsd.org/bugzilla/show_bug.cgi?id=238326 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238326> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238326 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238326>> The workaround in Bug 238326 comment 7 worked for me. /Peter

Re: CFT: if_bridge performance improvements

Just using pf is enough to provoke this panic. I had the same back trace. This patch from Kristof fixed it for me. diff --git a/sys/net/if_bridge.c b/sys/net/if_bridge.c index 373fa096d70..83c453090bb 100644 --- a/sys/net/if_bridge.c +++ b/sys/net/if_bridge.c @@ -2529,7 +2529,6 @@

Re: New Xorg - different key-codes

ntry says that it's switched from devd to udev. There's no mention of evdev or that the keycodes have been roto-tilled. It's basically a vanilla "things have been changed, see the documentation" entry. Given that entry, it's hardly surprising that people are confused. -- Peter Jer

Re: System clock is slow

g anything else non-standard)? -- Peter Jeremy signature.asc Description: PGP signature

Re: Which AMD CPUs are supported -- temperature

. If you are able to share the two constants (both step size and reference temperature), that would be great. -- Peter Jeremy signature.asc Description: PGP signature

Re: Which AMD CPUs are supported -- temperature

C > ># sysctl -a dev.amdtemp.0.core0.sensor0 >dev.amdtemp.0.core0.sensor0: 63.1C At what ambient temperature? I see a similar value from my (idle) APU3 but don't believe the (implied) ~35K junction-to-ambient difference. -- Peter Jeremy signature.asc Description: PGP signature

Re: head -r356066 reaching kern.ipc.nmbclusters on Rock64 (CortexA53 with 4GiByte of RAM) while putting files on it via nfs: some evidence

* XXX Now what? +* We've got a hole in the rx ring. +*/ + } } } -- Peter Jeremy signature.asc Description: PGP signature

Re: Best way to print something from the kernel at 1s intervals?

se the getnanouptime() call to get a “clock” to look for (it’s used in print_uptime()). As long as the clock isn’t stopped at this time in the shutdown sequence atleast :-) *Time to write some code and test this* :-) - Peter > On 29 Nov 2019, at 22:09, Enji Cooper wrote: > > >>

Best way to print something from the kernel at 1s intervals?

to do that from the kernel? In user space I’d just call time() at some convenient points and only print something if “t” has changed. :-) - Peter ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-cu

buildworld has mandatory dependency on optional executable.

s - it just reports "*** Error code 1" in bootstrap-tools. Having trace the failure, I now see ".ERROR_TARGET='_bootstrap-tools-link-kbdcontrol'" but that was only obvious in hindsight. -- Peter Jeremy signature.asc Description: PGP signature

Re: Reproducable deadlock in NFS client

listed here: >https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html Thanks for the pointer and sorry for leaving that out. -- Peter Jeremy signature.asc Description: PGP signature

Reproduceable deadlock in NFS Client

30aba0 fp = 0x0000 -- Peter Jeremy signature.asc Description: PGP signature

Re: panic: sleeping thread on r352386

ther. Thank you for your efforts. -- Peter Jeremy signature.asc Description: PGP signature

Re: panic: sleeping thread on r352386

;index 63ea4736707..16dc7745c77 100644 >--- a/sys/fs/nfsclient/nfs_clport.c >+++ b/sys/fs/nfsclient/nfs_clport.c ... With that patch, I'm back to "Sleeping thread (...) owns a non-sleepable lock" panics. -- Peter Jeremy signature.asc Description: PGP signature

Re: "Sleeping with non-sleepable lock" in NFS on recent -current

On 2019-Sep-16 11:19:02 +0300, Konstantin Belousov wrote: >diff --git a/sys/fs/nfsclient/nfs_clport.c b/sys/fs/nfsclient/nfs_clport.c >index 471e029a8b5..63ea4736707 100644 ... Thanks, that patch seems much more stable. -- Peter Jeremy signature.asc Description: PGP signature

Re: "Sleeping with non-sleepable lock" in NFS on recent -current

On 2019-Sep-16 09:32:52 +0300, Konstantin Belousov wrote: >On Mon, Sep 16, 2019 at 04:12:05PM +1000, Peter Jeremy wrote: >> I'm consistently seeing panics in the NFS code on recent -current on aarm64. >> The panics are one of the following two: >> Sleeping on "vmop

"Sleeping with non-sleepable lock" in NFS on recent -current

e [***] change to: sleepq_wait() at vm_page_sleep_if_busy+0x80 vm_page_sleep_if_busy() at vm_object_page_remove+0xfc -- Peter Jeremy signature.asc Description: PGP signature

Re: "panic: Duplicate alloc" in dwmmc_attach on Rock64

On 2019-Jun-21 20:59:39 +1000, Peter Jeremy wrote: >Since r349169, my Rock64 has consistently panic'd whilst attaching >rockchip_dwmmc1. A kernel built at r349135 works OK. The relevant >output looks like: >rockchip_dwmmc0: (RockChip)> mem 0xff50-0xff503fff ir

"panic: Duplicate alloc" in dwmmc_attach on Rock64

... I've looked through all the intervening commits and don't see any smoking gun. Does anyone have any suggestions? -- Peter Jeremy signature.asc Description: PGP signature

Re: error: yacc.h: No such file or directory

On 2019-Jun-18 07:01:31 -0700, Enji Cooper wrote: > >> On Jun 18, 2019, at 06:59, Enji Cooper wrote: >> PS This is one of the reasons why I wasn’t quick to discount Peter Jeremy’s >> reported build issue. > >Correction: I meant Julian Stacey. I'm not sure how

Re: FreeBSD 12 kernel broken

.c:60) >>>> g_uzip_lzma.o:(g_uzip_lzma_free) >--- kernel.full --- >*** [kernel.full] Error code 1 Are you talking about FreeBSD 12 or FreeBSD 13? -- Peter Jeremy signature.asc Description: PGP signature

Re: Optimization bug with floating-point?

rec() before main() and add a note in the man pages that libm is built to use the default FPU configuration and changing the configuration (precision or rounding) may result in larger errors. -- Peter Jeremy signature.asc Description: PGP signature

Re: r340343 triggers kernel assertion if file is opened with O_BENEATH flag set through symlink

() at kern_openat+0x2e9/frame 0xfe00c71888e0 sys_openat() at sys_openat+0x69/frame 0xfe00c7188910 syscallenter() at syscallenter+0x4e3/frame 0xfe00c71889f0 amd64_syscall() at amd64_syscall+0x4d/frame 0xfe00c7188ab0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00c7188ab0

panic: mtx_lock() by idle thread ... mutex igb0 @ ../../../net/iflib.c:2084

, rbp = 0 --- KDB: enter: panic [ thread pid 11 tid 17 ] Stopped at kdb_enter+0x3b: movq$0,kdb_why db> x/s version version:FreeBSD 13.0-CURRENT r339638 PHO-GENERIC\012 db> -- Peter ___ freebsd-current@freebsd.org mailing list

Re: Page fault in midi/sequencer.c

On Mon, Oct 22, 2018 at 11:00:41AM +0200, Hans Petter Selasky wrote: > On 10/20/18 6:56 PM, Peter Holm wrote: > > I can trigger this on 13.0-CURRENT r339445 with a non-root test program: > > > > Hi, > > The following commits should fix the issues you experience: >

Page fault in midi/sequencer.c

0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2356 (xxx) [ thread pid 2356 tid 100278 ] Stopped at copyin_nosmap_erms+0xdd:movl(%rsi),%edx db> -- Pe

Re: Page fault in udp_usrreq.c:823

On Thu, Jun 21, 2018 at 06:42:41PM -0700, Matthew Macy wrote: > I made changes this morning / early afternoon. > -M > With r335501 I no longer see any of the issues I reported. Thank you for the fix! - Peter > On Thu, Jun 21, 2018 at 6:41 PM, Cy Schubert > wrote: >

Page fault in udp_usrreq.c:823

tid 100069 ] Stopped at udp_common_ctlinput+0x263: cmpq$0,0x8(%rax) db> Details @ https://people.freebsd.org/~pho/stress/log/udp_usrreq.txt -- Peter ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listi

Re: how to browse svnweb source?

ck (eg) https://svnweb.freebsd.org/base?view=revision=333926 If you want a sequential list of commits, you might be better off with (eg) https://lists.freebsd.org/pipermail/svn-src-all/ -- Peter Jeremy signature.asc Description: PGP signature

Re: IGNORE_OSVERSION=yes -- can't install pkg

f. > > IMO, this new version checking done by pkg(8) is just bad Bad BAD. The > only control you get is a knob that tells you to ignore any version > mismatch. There appears to be no option to get the historical worked- > really-well behavior of ignoring mismatches of the minor ver

Re: g_handleattr: md0 bio_length 24 len 31 -> EFAULT

txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT [pho@freefall ~/public_html/stress/log]$

Re: Call for Testing: UEFI Changes

ntime->rt_gettime" (and is still a phys addr here). --peter > > On Thu, 22 Mar 2018 08:22:13 -0500 > Kyle Evans <kev...@freebsd.org> wrote: > >> On Thu, Mar 22, 2018 at 5:13 AM, Jakob Alvermark <ja...@alvermark.net> wrote: >>> Hi! >>> >>

Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

331053. I've seen it in my main server (32GB RAM) but haven't managed to reproduce it in smaller VBox guests - one difficulty I faced was artificially filling ARC. -- Peter Jeremy signature.asc Description: PGP signature

amd64: panic on -CURRENT @r330539 for certain UEFI hosts

ide the implementation, but CR0_WP is definitely left enabled before the kernel is booted. I have patched my kernel build to explicitly clear CR0_WP (e.g. in initializecpu) prior to creating the page tables to get around this, but someone might have a cleaner/better solution... --peter smime.

Re: INTRNG

While on the subject INTRNG - does anybody know the status of handling GPIO interrupts with queue/kevent? There were some patches before INTRNG, but they require some work. Peter > On 23 Feb 2018, at 07:25, Jon Brawn <j...@brawn.org> wrote: > > Wotcha Gang! > >

Re: ACPI panic on boot with new Lua loader and other minor issues

On 2/19/18 5:48 PM, Kyle Evans wrote: > > > On Feb 19, 2018 5:44 PM, "Peter Lei" <peter@ieee.org > <mailto:peter@ieee.org>> wrote: > > > > On 2/19/18 2:21 PM, Kyle Evans wrote: > > Hello! > > > > On

Re: ACPI panic on boot with new Lua loader and other minor issues

On 2/19/18 2:21 PM, Kyle Evans wrote: > Hello! > > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor > wrote: >> I have done a full build of r329555 to test the new Lua boot loader. >> >> Both the new and the old kernels panic after being loaded with: >> >> panic:

Re: Build error: 'emmintrin.h' file not found

? E.g. what is the output of "find /usr/lib/clang -name emmintrin.h" ? -- Peter Jeremy signature.asc Description: PGP signature

Re: Unable to build 12-current/amd64

On 2017-Dec-23 13:42:40 +0100, Dimitry Andric <d...@freebsd.org> wrote: >On 23 Dec 2017, at 10:56, Peter Jeremy <pe...@rulingia.com> wrote: >> >> Since r326496, buildworld on my 12-current/amd64 system has consistently >> died as follows. >... >> /

Unable to build 12-current/amd64

sr/src/lib/clang/libclang I'm building on a 12.0-CURRENT VirtualBox guest at r326430. I've checked that my /usr/src is clean and deleted /usr/obj to no effect. I have dug into SourceManager.cpp and the #include is protected by a #if __SSE2__, which is relying on clang internal checks to define (an

Re: get_swap_pager(x) failed

t he is running but I would point the finger at r325851. I have discovered that, in 11-stable, r326619 (which is the MFC of r325851) stops ARC responding to memory backpressure. -- Peter Jeremy signature.asc Description: PGP signature

Re: Install FreeBSD from source into VM image

Error return from kevent monitor: Not permitted in capability mode ... This sounds like an issue with the bhyve capsicum work. I've cc'd Allan and Peter who might be able to help track that down. It might be useful if you can run bhyve under ktrace, e.g.: sudo ktrace -i -t p sh /usr

Caveat emptor: Beware of ZFS on HEAD

apologize for being vague - I do not know more. Folks running HEAD should take appropritate precautions (eg: keeping a known-good kernel.old and modules around). This is always advisable when running HEAD anyway, particularly so now. For us, a kernel.old from June 18th worked fine. -- Peter

Re: dump trying to access incorrect block numbers?

xact dump and fsck commands you ran? >I now have two UFS-based systems showing the same symptoms - what's up >with this? Was there anything you did on either filesystem that might have triggered it? -- Peter Jeremy signature.asc Description: PGP signature

Re: Time to increase MAXPHYS?

One area that breaks after changing MAXPHYS from 128K to 1MB is the iscsi target. I don’t have details, because that server is semi-production and I reverted it back ASAP > On 5 Jun 2017, at 19:49, Edward Tomasz Napierała wrote: > > On 0604T0952, Hans Petter Selasky wrote:

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

ng under all circumstances. It's blatently breaking in this scenario but could be causing more subtle (and unnoticed) breakage in other cases. This makes me feel that this is worth investigating further. -- Peter Jeremy signature.asc Description: PGP signature

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On 2017-May-24 18:01:42 -0700, "Simon J. Gerraty" <s...@juniper.net> wrote: >Peter Jeremy <pe...@rulingia.com> wrote: >> as follows. My suspicion is that meta mode isn't seeing enough of the >> differences between the bootstrap and main build steps and so caus

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

.meta -print0 | xargs -0 rm" and am still waiting for that to complete, though it has passed the above failure point. -- Peter Jeremy signature.asc Description: PGP signature

panic with jail bug_id 213673 was: VNET branch destiny

reebsd.org/bugzilla/show_bug.cgi?id=213673>. It is unrelated > to epair or ng_eiface (my case). > > I’ll dig some more. > > Peter > > >> On 11 Apr 2017, at 08:47, Kristof Provost <kris...@sigsegv.be> wrote: >> >> On 10 Apr 2017, at 12:10, peter.b.

Re: VNET branch destiny

Hi Kristof, I’m prety sure it is the same as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213673 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213673>. It is unrelated to epair or ng_eiface (my case). I’ll dig some more. Peter > On 11 Apr 2017, at 08:47, Kristof Prov

Re: VNET branch destiny

No problem. Although pf is not used the vnet_destroy seems to be the issue. Some parts are not virtualized and the vnet_destroy->vnet_pf_uninit teardown happens on the host vnet so to speak. > On 10 Apr 2017, at 22:11, Ernie Luzar wrote: > > peter.b...@bsd4all.org wrote:

Re: VNET branch destiny

; when an interface is moved to a different vnet. >> Does anyone no if there is a specific fix for this that hasn’t been ported >> to stable? I haven’t had the time to test this on current. >> Peter > > PF was fixed in 11.0 to not panic when run on a host that has vimage compiled

Re: VNET branch destiny

the time to test this on current. Peter > On 10 Apr 2017, at 08:50, Pavel Timofeev <tim...@gmail.com> wrote: > > 31 марта 2017 г. 17:40 пользователь "Bjoern A. Zeeb" < > bzeeb-li...@lists.zabbadoz.net> написал: > > On 31 Mar 2017, at 13:57, Pavel Timofeev

Re: effect of strip(1) on du(1)

r it being stable, consider a (hypothetical) filesystem that can transparently migrate data between different storage media, with different compression algorithms etc (ZFS will be able to do this once the mythical block rewrite code is written). -- Peter Jeremy signature.asc Description: PGP signature

Re: effect of strip(1) on du(1)

t file and du(1) reports the number of blocks reported by stat(2). It seems that you are hitting a situation where the file metadata isn't immediately updated. -- Peter Jeremy signature.asc Description: PGP signature

Re: removing SVR4 binary compatibilty layer

be shipped without it. There is no intention of merge of the removal. >The stable@ mailing list added for wider audience. Can I suggest that we put some warnings into the SVr4 image activation code and MFC that to at least 11 to try and smoke out anyone who might actually be using it. -- Peter J

Re: [RFC/RFT] projects/ipsec

Andrey, Is this going to MFC'ed to stable-11 in the future? I have tested with current and found no issues, but I would like to add it to a semi-production environment running stable-11 Peter > On 6 Feb 2017, at 10:07, Andrey V. Elsukov <a...@freebsd.org> wrote: > > On 1

Re: crash in iflib_fast_intr

This is with an igb interface. Peter > On 18 Jan 2017, at 15:31, Sean Bruno <sbr...@freebsd.org> wrote: > > > > On 01/18/17 03:37, peter.b...@bsd4all.org <mailto:peter.b...@bsd4all.org> > wrote: >> Hi, >> >> A kernel without option EAR

crash in iflib_fast_intr

at intr_execute_handlers+0x48 #10 0x8096b1cf at lapic_handle_intr+0x3f #11 0x808f3cc7 at Xapic_isr1+0xb7 #12 0x805b994a at sched_idletd+0x37a #13 0x805460f5 at fork_exit+0x85 #14 0x808f3b1e at fork_trampoline+0xe Peter

Re: CURRENT: "service netif restart" looses default route

} network_stop() { /etc/rc.d/netif stop /etc/rc.d/routing stop } load_rc_config $name run_rc_command $* -- Oliver PETER oli...@gfuzz.de 0x456D688F ___ freebsd-current@freebsd.org mailing list https:/

Re: commits between r305191 - r305211 broke zfs list

> On 03/09/2016 21:50, Subbsd wrote: > > Hi. > > > > Can anybody test of output for: > > > > zfs list > > > > command on FreeBSD current after r305211 ? On my hosts his leads to > > zfs segfault. -- Peter Wemm - pe...@wemm.org; pe

Re: Somethign missing in my environment?

uggest trying without the "-DNOCLEAN -DNO_CLEAN" - they are shortcuts that aren't guaranteed to work under all circumstances. And if that still fails, skip the '-j8' because it's possible there are still race conditions in buildworld (though that is very unlikely). -- Peter Jeremy

Re: Somethign missing in my environment?

at is your current environment? - What is the output leading up to that error (what is being built? -- Peter Jeremy signature.asc Description: PGP signature

Re: FreeBSD 11.0-RC1 Now Available

; > I've waited a day to see if the issue would disappear after mirrors > > catch up but no joy, even via Tor. > > > > [...] > > Thanks for letting us know. This isn't an re@ issue, it's an admins@ > issue, and we thought this was fixed. Give me a bit to investigate. >

Re: Mosh regression between 10.x and 11-stable

you try and identify a more >> portable repro or at least figure out why it fails on your system? >> >> Please try applying this patch, too. It's a shot in the dark, though. > >Dumb question: what ssh key type(s) (dsa, rsa, etc) are you using Peter :)? I'm using ECDSA for

Re: Mosh regression between 10.x and 11-stable

t;Please try applying this patch, too. It's a shot in the dark, though. That patch seems to fix the problem I'm seeing. Not waiting for output to drain is consistent with the symptoms I'm seeing, though I have no idea why only my Linux client is affected. -- Peter Jeremy signature.asc Description: PGP signature

  1   2   3   4   5   6   7   8   9   10   >