ices
don't. So adding `option FILEMON` to your kernel config will cause
filemon to be compiled into the kernel, but it will also generate an
unneeded opt_filemon.h with `#define FILEMON 1`. Or it would, if it
weren't for this:
% git annotate sys/conf/options |& grep -i filemon
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:
>>
>>
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 cau
(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
. 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
rticles/article.aspx?p=2204014
Ah well, time to relearn C again :-)
(K&R 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...
>&
have a full-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
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
--- 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
hrough the commits and, 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
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
.mountfrom that points to a
BE that's different to bootfs. (And ideally, a similar check of
/etc/fstab, though beadm doesn't touch that).
--
Peter Jeremy
signature.asc
Description: PGP signature
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 ac
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_chang
ht like to consider real-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
at the 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
f80c5ce1d at sys_sendto+0x4d
#14 0x8108f4c7 at amd64_syscall+0x387
#15 0x8106754e at fast_syscall_common+0xf8
Uptime: 212d21h35m47s
- Peter
s - it looks for ZFS labels on all
possible devices.
--
Peter Jeremy
signature.asc
Description: PGP signature
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
us 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
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
() 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
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
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
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
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
: 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
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:
>> >
[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-
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
>AES-X
t; > I'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
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
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
o
2 errors
make[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"
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
>
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
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 @@ bridge_input(st
ING entry 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
ng your CPU (or doing anything else non-standard)?
--
Peter Jeremy
signature.asc
Description: PGP signature
f 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
.0.temperature: 62.6C
>
># 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
/*
+* XXX Now what?
+ * We've got a hole in the rx ring.
+*/
+ }
}
}
--
Peter Jeremy
signature.asc
Description: PGP signature
to use 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:
>
>
>&
to do that from the kernel? In user space I’d just
call time(&t) 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-c
he cause obvious - 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
stuff 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
0004030aba0 fp = 0x0000
--
Peter Jeremy
signature.asc
Description: PGP signature
7) either. Thank you for your efforts.
--
Peter Jeremy
signature.asc
Description: PGP signature
;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
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
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 "
c, the [***] 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
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-0xff503f
10a80
...
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
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
.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
psetprec() 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
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
, 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
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:
>
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
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:
>
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
sion, you can
check (eg) https://svnweb.freebsd.org/base?view=revision&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
gt; 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 version for
&g
1104.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
_runtime->rt_gettime" (and is still a
phys addr here).
--peter
>
> On Thu, 22 Mar 2018 08:22:13 -0500
> Kyle Evans wrote:
>
>> On Thu, Mar 22, 2018 at 5:13 AM, Jakob Alvermark wrote:
>>> Hi!
>>>
>>>
>>> Just updated to r331345.
>
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
side 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
s
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 wrote:
>
> Wotcha Gang!
>
> In my travels through the arm64
On 2/19/18 5:48 PM, Kyle Evans wrote:
>
>
> On Feb 19, 2018 5:44 PM, "Peter Lei" <mailto:peter@ieee.org>> wrote:
>
>
>
> On 2/19/18 2:21 PM, Kyle Evans wrote:
> > Hello!
> >
> > On Mon, Feb 19, 2018 at 8:21 AM, J
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: running without device
put of "find
/usr/lib/clang -name emmintrin.h" ?
--
Peter Jeremy
signature.asc
Description: PGP signature
On 2017-Dec-23 13:42:40 +0100, Dimitry Andric wrote:
>On 23 Dec 2017, at 10:56, Peter Jeremy wrote:
>>
>> Since r326496, buildworld on my 12-current/amd64 system has consistently
>> died as follows.
>...
>> /usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManage
Stop.
make[4]: stopped in /usr/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 relyin
t 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
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
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
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
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:
>> On 06/04/17 09:39,
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
On 2017-May-24 18:01:42 -0700, "Simon J. Gerraty" wrote:
>Peter Jeremy 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 causing make
>> to incorrectly skip steps
k /usr/src/tools/build/mk/Makefile.boot'
.PATH='. /usr/src/usr.bin/mkesdb_static /usr/src/lib/libc/iconv
/usr/src/usr.bin/mkesdb'
*** Error code 1
I've done a "find /usr/obj -name \*.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
ebsd.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 wrote:
>>
>> On 10 Apr 2017, at 12:10, peter.b...@bsd4all.org wrote:
>&
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 Provo
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:
>> Well, in my case i
es
>> 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
the time to test this on current.
Peter
> On 10 Apr 2017, at 08:50, Pavel Timofeev wrote:
>
> 31 марта 2017 г. 17:40 пользователь "Bjoern A. Zeeb" <
> bzeeb-li...@lists.zabbadoz.net> написал:
>
> On 31 Mar 2017, at 13:57, Pavel Timofeev wrote:
>
> Hello,
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
he 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
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 Jeremy
signature.asc
D
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 wrote:
>
> On 11.12.2016 02:07, And
This is with an igb interface.
Peter
> On 18 Jan 2017, at 15:31, Sean Bruno wrote:
>
>
>
> On 01/18/17 03:37, peter.b...@bsd4all.org <mailto:peter.b...@bsd4all.org>
> wrote:
>> Hi,
>>
>> A kernel without option EARLY_AP_STARTUP crashes in i
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
art
}
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
ht
> 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...@fre
ng 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
signature.asc
Description: PGP signature
environment?
- What is the output leading up to that error (what is being built?
--
Peter Jeremy
signature.asc
Description: PGP signature
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.
>
> Gl
le 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 both the host and user keys.
--
Peter Jeremy
signature.asc
Description: PGP signature
1 - 100 of 1673 matches
Mail list logo