Re: nvme controller reset failures on recent -CURRENT

On 12 Feb, Warner Losh wrote: > On Mon, Feb 12, 2024 at 9:15 PM Don Lewis wrote: > >> On 12 Feb, Maxim Sobolev wrote: >> > Might be an overheating. Today's nvme drives are notoriously flaky if you >> > run them without proper heat sink attached to it. >> >

Re: nvme controller reset failures on recent -CURRENT

while. > On Mon, Feb 12, 2024, 4:28 PM Don Lewis wrote: > >> I just upgraded my package build machine to: >> FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e >> from: >> FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38 >> and I've had two nvme-triggered p

Re: nvme controller reset failures on recent -CURRENT

On 12 Feb, Mark Johnston wrote: > On Mon, Feb 12, 2024 at 04:28:10PM -0800, Don Lewis wrote: >> I just upgraded my package build machine to: >> FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e >> from: >> FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38 >>

nvme controller reset failures on recent -CURRENT

I just upgraded my package build machine to: FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e from: FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38 and I've had two nvme-triggered panics in the last day. nvme is being used for swap and L2ARC. I'm not able to get a crash dump, probably

Re: ssh connections break with "Fssh_packet_write_wait" on 13 [SOLVED]

On 8 Jun, Michael Gmelin wrote: > > > On Thu, 3 Jun 2021 15:09:06 +0200 > Michael Gmelin wrote: > >> On Tue, 1 Jun 2021 13:47:47 +0200 >> Michael Gmelin wrote: >> >> > Hi, >> > >> > Since upgrading servers from 12.2 to 13.0, I get >> > >> > Fssh_packet_write_wait: Connection to 1.2.3.4

Re: Getting /usr/src to match specific git hash?

On 24 Jan, Yasuhiro Kimura wrote: > From: Steve Kargl > Subject: Getting /usr/src to match specific git hash? > Date: Sat, 23 Jan 2021 19:58:52 -0800 > >> Suppose one has an empty /usr/src. >> >> Suppose further that one had to re-install a 32-bit >> i386-*-freebsd with the 24 Dec 2020 image

Re: MRSAS Panic during Install.

On 9 Jun, Andriy Gapon wrote: > On 09/06/2020 03:42, Santiago Martinez wrote: >> Hi Everyone, today I tested with 12.1 and it works without any issues (at >> least >> for now). >> >> I will sync against current and see if it fails. >> >> Santiago >> >> On 2020-06-08 17:41, Santiago Martinez

FreeBSD CURRENT buildworld in virtualbox guest crashes FreeBSD host

Please forgive the crosspost, I don't know where the problem actually belongs. For the last several months I've had a problem where doing a buildworld on FreeBSD CURRENT running as a virtualbox guest is crashing a the FreeBSD current host. This doesn't always happen, but there is a pattern. The

Re: poudriere, swap full and top says memory is free ?

On 14 Sep, John-Mark Gurney wrote: > Kurt Jaeger wrote this message on Sat, Sep 14, 2019 at 19:38 +0200: >> - a poudriere build >> - of a list of ports >> - on 12.0-RELEASE-p10 >> - on a 4 core+4 hyperthreads CPU, an Intel(R) Xeon(R) CPU E3-1230 v6 >> @ 3.50GHz >> - with 32 GB RAM >> - zpool

Re: spurious out of swap kills

On 13 Sep, Mark Millard wrote: > Don Lewis truckman at FreeBSD.org wrote on > Thu Sep 12 23:00:19 UTC 2019 : > > . . . >> Nevertheless, I see these errors, >> with rustc being the usual victim: >> >> Sep 11 23:21:43 zipper kernel: pid 16581 (rustc), jid 43, ui

Re: spurious out of swap kills

On 13 Sep, Konstantin Belousov wrote: > On Thu, Sep 12, 2019 at 05:42:00PM -0700, Don Lewis wrote: >> On 12 Sep, Mark Johnston wrote: >> > On Thu, Sep 12, 2019 at 04:00:17PM -0700, Don Lewis wrote: >> >> My poudriere machine is running 13.0-CURRENT and gets updat

Re: spurious out of swap kills

On 12 Sep, Don Lewis wrote: > On 12 Sep, Mark Johnston wrote: >> On Thu, Sep 12, 2019 at 04:00:17PM -0700, Don Lewis wrote: >>> My poudriere machine is running 13.0-CURRENT and gets updated to the >>> latest version of -CURRENT periodically. At least in the last week

Re: spurious out of swap kills

On 12 Sep, Mark Johnston wrote: > On Thu, Sep 12, 2019 at 04:00:17PM -0700, Don Lewis wrote: >> My poudriere machine is running 13.0-CURRENT and gets updated to the >> latest version of -CURRENT periodically. At least in the last week or >> so, I've been seeing occasional por

spurious out of swap kills

My poudriere machine is running 13.0-CURRENT and gets updated to the latest version of -CURRENT periodically. At least in the last week or so, I've been seeing occasional port build failures when building my default set of ports, and I finally had some time to do some investigation. It's a

Re: Reducing UFS corruption from unclean shutdowns?

On 21 Jun, Scott Long wrote: > > >> On Jun 21, 2019, at 4:37 PM, Warner Losh wrote: >> >> On Fri, Jun 21, 2019, 3:33 PM Conrad Meyer wrote: >> >>> On Fri, Jun 21, 2019 at 2:55 PM Alan Somers wrote: I would've thought that immediately following a sync(8), the filesystem would be

Re: Reducing UFS corruption from unclean shutdowns?

On 21 Jun, Scott Long wrote: > >> On Jun 21, 2019, at 2:09 PM, Alan Somers wrote: >> >> On Fri, Jun 21, 2019 at 1:56 PM Scott Long wrote: >>> >>> >>> On Jun 21, 2019, at 1:49 PM, Alan Somers wrote: I panic my development VM regularly. Each time, I need to fsck the

Re: error when updating 13.0-CURRENT i386 poudriere jail to r347606

On 14 May, Don Lewis wrote: > I just ran into this error when updating my 13.0-CURRENT i386 jail to > r347606. I did not run into this problem when I upgraded by amd64 jail, > or when I updated the i386 jail to r347549. This doesn't seem to be very repeatable. I tried to upgrade the j

error when updating 13.0-CURRENT i386 poudriere jail to r347606

I just ran into this error when updating my 13.0-CURRENT i386 jail to r347606. I did not run into this problem when I upgraded by amd64 jail, or when I updated the i386 jail to r347549. --- lib/libgcc_s__L --- sh /var/poudriere/jails/13CURRENTi386/usr/src/tools/install.sh -l rs -o root -g wheel

recent 13.0-CURRENT double panic near start of poudriere run

I've been doing a bunch of packing building today on my Ryzen box and just got this kernel panic near the start of a poudriere run: 13.0-CURRENT FreeBSD 13.0-CURRENT r340358 GENERIC amd64 [00:00:08] Processing PRIORITY_BOOST [00:00:08] Balancing pool [00:00:08] Recording filesystem state for

Re: virtualbox 5.2.20 triggers panic with FreeBSD 12.0-ALPHA10 r339432

On 19 Oct, Matthew D. Fuller wrote: > On Fri, Oct 19, 2018 at 03:47:40PM -0700 I heard the voice of > Don Lewis, and lo! it spake thus: >> >> The first is that when I attempt to start a Virtualbox VM, the >> system panics. > > Perhaps https://bugs.freebsd.org/b

Re: virtualbox 5.2.20 triggers panic with FreeBSD 12.0-ALPHA10 r339432

On 19 Oct, Don Lewis wrote: > On 20 Oct, Graham Perrin wrote: >> On 19/10/2018 23:47, Don Lewis wrote: >> >>> … when I attempt to start a Virtualbox VM, the system panics. … (guest) >>> Windows 7 with >> networking configured as > NAT and the underly

Re: virtualbox 5.2.20 triggers panic with FreeBSD 12.0-ALPHA10 r339432

On 20 Oct, Graham Perrin wrote: > On 19/10/2018 23:47, Don Lewis wrote: > >> … when I attempt to start a Virtualbox VM, the system panics. … (guest) >> Windows 7 with > networking configured as > NAT and the underlying adapter being Intel PRO/1000 > MT Desktop (82540EM

virtualbox 5.2.20 triggers panic with FreeBSD 12.0-ALPHA10 r339432

It looks like there are a couple of problems here. The first is that when I attempt to start a Virtualbox VM, the system panics. The DDB backtrace seems to indicate that the panic is occuring inside the ng_ether module, which was being called due to a virtualbox doing an ioctl call. The VM

Re: OpenSSL 1.1.1 libssl.so version number

On 12 Oct, Don Lewis wrote: > Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was > /usr/lib/libssl.so.8. The security/openssl port (1.0.2p) installed > ${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port > (1.1.0i) installed ${LOCALBASE}/lib/libssl.s

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

On 11 Oct, Don Lewis wrote: > On 11 Oct, Don Lewis wrote: >> On 11 Oct, freebsd.curr...@clogic.com.ua wrote: >>> On 2018-10-10 06:14, Michael Butler wrote: >>>> On 10/9/18 5:34 PM, Glen Barber wrote: >>>>> OpenSSL has been updated to version 1.1.

OpenSSL 1.1.1 libssl.so version number

Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was /usr/lib/libssl.so.8. The security/openssl port (1.0.2p) installed ${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port (1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11. After the import, the base OpenSSL library is

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

On 11 Oct, Don Lewis wrote: > On 11 Oct, freebsd.curr...@clogic.com.ua wrote: >> On 2018-10-10 06:14, Michael Butler wrote: >>> On 10/9/18 5:34 PM, Glen Barber wrote: >>>> OpenSSL has been updated to version 1.1.1 as of r339270. >>>> >>>>

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

On 11 Oct, freebsd.curr...@clogic.com.ua wrote: > On 2018-10-10 06:14, Michael Butler wrote: >> On 10/9/18 5:34 PM, Glen Barber wrote: >>> OpenSSL has been updated to version 1.1.1 as of r339270. >>> >>> It is important to rebuild third-party packages before running: >>> >>> # make -C /usr/src

Re: error: undefined symbol: main in poudriere jail

On 24 Sep, blubee blubeeme wrote: > This issue seemed to have come up in the past: > https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068870.html > > > Jail name: amd64_cur > Jail version: 12.0-ALPHA7 1200084 > Jail vcs version: r338898 > Jail arch: amd64 >

Re: review of nfsd rc.d script patch

On 15 Jun, Rick Macklem wrote: > Hi, > > For the pNFS service MDS machine, the nfsd can't be started until all nfs > mounts > in /etc/fstab are done. > I think that adding "mountcritremote" to the "# REQUIRE:" line is sufficient > to do this? > > I don't think delaying the startup of the nfsd

Re: Is kern.sched.preempt_thresh=0 a sensible default?

On 9 Jun, Stefan Esser wrote: > 3) Programs that evenly split the load on all available cores have been >suffering from sub-optimal assignment of threads to cores. E.g. on a >CPU with 8 (virtual) cores, this resulted in 6 cores running the load >in nominal time, 1 core taking twice

Re: rndc: connect failed: 127.0.0.1#953: permission denied

On 2 Jun, O. Hartmann wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On CURRENT, running on an APU as router/firewall service, out of the blue > after an update > I receive this weird message when trying to restart "named" (BIND 9.12, > latest from the > ports): > > service

Re: [RFC] Deprecation and removal of the drm2 driver

On 18 May, Warner Losh wrote: > On Fri, May 18, 2018 at 1:30 PM, Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > >> On Fri, May 18, 2018 at 09:14:24PM +0200, Andreas Nilsson wrote: >> > On Fri, May 18, 2018, 20:00 Niclas Zeising wrote: >> > >> > > I propose that

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

esses in wait channel btalloc. >>> >>> You don't really have the same symptoms that Don is reporting. >> >> Okay. I latched onto the thread because it seemed similar. >> >>> Threads being stuck in btalloc implies a KVA shortage. So: >>> - What do you

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

On 4 Apr, Mark Johnston wrote: > On Tue, Apr 03, 2018 at 09:42:48PM -0700, Don Lewis wrote: >> On 3 Apr, Don Lewis wrote: >> > I reconfigured my Ryzen box to be more similar to my default package >> > builder by disabling SMT and half of the RAM, to limit i

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

On 4 Apr, Don Lewis wrote: > On 4 Apr, Mark Johnston wrote: >> On Tue, Apr 03, 2018 at 09:42:48PM -0700, Don Lewis wrote: >>> On 3 Apr, Don Lewis wrote: >>> > I reconfigured my Ryzen box to be more similar to my default package >>> > builder by d

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

On 4 Apr, Mark Johnston wrote: > On Tue, Apr 03, 2018 at 09:42:48PM -0700, Don Lewis wrote: >> On 3 Apr, Don Lewis wrote: >> > I reconfigured my Ryzen box to be more similar to my default package >> > builder by disabling SMT and half of the RAM, to limit i

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

On 3 Apr, Cy Schubert wrote: > Try arbitrarily reducing arc_max through sysctl. ARC is immediately > reduced and free memory increased however wired pages remains the > same. One thing that I've noticed is that with r329844 and earlier is that there can be a difference of multiple GB between the

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

On 3 Apr, Don Lewis wrote: > On 1 Apr, Don Lewis wrote: >> On 27 Mar, Andriy Gapon wrote: >>> On 24/03/2018 01:21, Bryan Drewery wrote: >>>> On 3/20/2018 12:07 AM, Peter Jeremy wrote: >>>>> >>>>> On 2018-Mar-11 10:43:58 -1000, Jeff

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

On 1 Apr, Don Lewis wrote: > On 27 Mar, Andriy Gapon wrote: >> On 24/03/2018 01:21, Bryan Drewery wrote: >>> On 3/20/2018 12:07 AM, Peter Jeremy wrote: >>>> >>>> On 2018-Mar-11 10:43:58 -1000, Jeff Roberson <jrober...@jroberson.net> >>>&g

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

On 27 Mar, Andriy Gapon wrote: > On 24/03/2018 01:21, Bryan Drewery wrote: >> On 3/20/2018 12:07 AM, Peter Jeremy wrote: >>> >>> On 2018-Mar-11 10:43:58 -1000, Jeff Roberson >>> wrote: Also, if you could try going back to r328953 or r326346 and let me know if

Re: 11.1-jail on CURRENT: sh: lint: not found *** [llib-lposix.ln] Error code 127

There doesn't appear to be a knob to disable building lint for FreeBSD 11.x. Linking or copying /usr/bin/true to /usr/bin/lint works for cross building 11 on on a 12.0-CURRENT machine, but I was not able to get it to work when rebuilding a poudriere jail. On 8 Jan, Warner Losh wrote: > Does

Re: 11.1-jail on CURRENT: sh: lint: not found *** [llib-lposix.ln] Error code 127

Put the following in /usr/local/etc/poudriere.d/src.conf: LINT=/usr/bin/false That skips the attempt to build the lint library because of this: .if ${LINT} == "lint" _llib= llib .else _llib= .endif SUBDIR= lint1 lint2 xlint ${_llib} in /usr/src/usr.bin/xlint/Makefile On 8 Jan,

more fallout from removal of lint

Since lint was removed from 12.0-CURRENT, it is not possible to build 11.1-STABLE on a 12.0-CURRENT host, but I was able to work around that by copying /usr/bin/true to /usr/bin/lint. Unfortunately, that trick doesn't work when updating a 11.1-STABLE poudriere jail on a 12.0-CURRENT host. ===>

Re: r320183 (rpc.lockd cleanup) breaks virtualbox-ose build

On 21 Jul, Ed Maste wrote: > On 11 July 2017 at 12:44, Don Lewis <truck...@freebsd.org> wrote: >> This is a really strange problem ... >> >> Last week I upgraded my 12.0-CURRENT package build box from r318774 to >> r320570. I also upgraded the poudriere jail t

Re: jemalloc_arena.c:821: Failed assertion: "nstime_compare(>epoc h, ) <= 0")

On 12 Jul, Jason Evans wrote: > On Tue, 11 Jul 2017 18:12:58 -0700 (PDT) > Don Lewis <truck...@freebsd.org> wrote: >> I'm trying to stabilize my new-ish Ryzen package build box. I've run >> into this error a couple of times: >> (: jemalloc_arena.c:821: Failed asser

jemalloc_arena.c:821: Failed assertion: "nstime_compare(>epoc h, ) <= 0")

I'm trying to stabilize my new-ish Ryzen package build box. I've run into this error a couple of times: (: jemalloc_arena.c:821: Failed assertion: "nstime_compare(>epoc h, ) <= 0") most recently today when building llvm40. It seems to happen somewhat randomly. I don't remember seeing it

r320183 (rpc.lockd cleanup) breaks virtualbox-ose build

This is a really strange problem ... Last week I upgraded my 12.0-CURRENT package build box from r318774 to r320570. I also upgraded the poudriere jail to match. When I went to build packages, the virtualbox-ose build failed due to ar segfaulting. To debug I created a new 12.0-CURRENT

Re: ino64 package fallout

On 24 May, Konstantin Belousov wrote: > On Wed, May 24, 2017 at 10:05:22AM -0700, Don Lewis wrote: >> I just upgraded by package build box and its poudriere jail to r318776 >> and ran into some significant package build fallout. > > There are several reviews that fix ports

ino64 package fallout

I just upgraded by package build box and its poudriere jail to r318776 and ran into some significant package build fallout. devel/llvm40:build: /usr/bin/c++ -DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -isystem

Re: ELF binary type "3" not known.

On 20 Mar, Chris H wrote: > I'm not sure which of the two lists I'm directing > this to is the best/correct one. So I picked both. > > To the point; I received this message during a big > build session. I was only able to catch the one from > x11/nvidia-driver in such a way as to actually get >

Re: ntpd dies nightly on a server with jails

On 17 Mar, O. Hartmann wrote: > Just some strange news: > > I left the server the whole day with ntpd disabled and I didn't watch > a gain of the RTC by one second, even stressing the machine. > > But soon after restarting ntpd, I realised immediately a 30 minutes > off! This morning, the

Re: ntpd dies nightly on a server with jails

On 16 Mar, O. Hartmann wrote: > Am Wed, 15 Mar 2017 13:12:37 -0700 > Cy Schubert schrieb: >> > >> > When the clock is floating that wild, in all cases ntpd isn't >> > running any mor e. >> > I try to restart with options -g and -G to adjust the time quickly >> > at the

Re: I/O semantics of pipe and FIFO.

On 8 Mar, Devin Teske wrote: > Problem we had found was: > > Executing dd with a closed stdout and stderr would cause the summary > messages printed at the end to go into the destination output file. > > For example, > > dd if=/dev/zero of=/tmp/foo bs=1m count=1 > > Works fine, but the

Re: malloc() call somehow calling the rtld malloc() implementaion

On 27 Jan, Alexander Kabaev wrote: > On Fri, 27 Jan 2017 10:47:20 -0800 (PST) > Don Lewis <truck...@freebsd.org> wrote: > >> On 27 Jan, Alexander Kabaev wrote: >> > On Fri, 27 Jan 2017 00:31:30 -0800 (PST) >> > Don Lewis <truck...@freebsd.org> wrote:

Re: malloc() call somehow calling the rtld malloc() implementaion

On 27 Jan, Konstantin Belousov wrote: > On Fri, Jan 27, 2017 at 12:19:16PM -0500, Alexander Kabaev wrote: >> On Fri, 27 Jan 2017 00:31:30 -0800 (PST) >> Don Lewis <truck...@freebsd.org> wrote: >> > If I create a simple test program that calls malloc() and s

Re: malloc() call somehow calling the rtld malloc() implementaion

On 28 Jan, Jan Mikkelsen wrote: > Hi, > > Are you being affected by this rtld behaviour: > > https://lists.freebsd.org/pipermail/freebsd-hackers/2016-July/049769.html > > >

Re: malloc() call somehow calling the rtld malloc() implementaion

On 27 Jan, Konstantin Belousov wrote: > On Fri, Jan 27, 2017 at 12:19:16PM -0500, Alexander Kabaev wrote: >> On Fri, 27 Jan 2017 00:31:30 -0800 (PST) >> Don Lewis <truck...@freebsd.org> wrote: >> >> > I've been attempting to get OpenOffice to build properly

Re: malloc() call somehow calling the rtld malloc() implementaion

On 27 Jan, Alexander Kabaev wrote: > On Fri, 27 Jan 2017 00:31:30 -0800 (PST) > Don Lewis <truck...@freebsd.org> wrote: >> If I create a simple test program that calls malloc() and set a >> breakpoint in malloc(), the breakpoint gets set in the rtld version, >> but

malloc() call somehow calling the rtld malloc() implementaion

I've been attempting to get OpenOffice to build properly in a clang400-import poudriere jail and have run into a mystery. The build procedure creates a c++ executable "idlc", which is used to build other stuff. The new operator has been overrriden to call a custom memory allocator, which I have

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

On 13 Nov, Mateusz Guzik wrote: > On Sat, Nov 12, 2016 at 05:11:57PM -0800, Don Lewis wrote: >> What protects nc_flag, the lock for the list that it resides on? >> > > It is supposed to be the hot list lock and I think this uncovers a bug > here. > > Consider

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

Sat, Nov 12, 2016 at 05:11:57PM -0800, Don Lewis wrote: >> This !neg_locked code in cache_negative_remove() looks suspicious to me: >> >> if (!neg_locked) { >> if (ncp->nc_flag & NCF_HOTNEGATIVE) { >> hot_locked = t

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

On 12 Nov, Mateusz Guzik wrote: > On Fri, Nov 11, 2016 at 11:29:48PM -0800, Don Lewis wrote: >> On 11 Nov, To: freebsd-current@FreeBSD.org wrote: >> > Yesterday I upgraded my ports builder box from r306349 to r308477. It >> > crashed overnight during a poudriere r

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

On 12 Nov, Mateusz Guzik wrote: > On Fri, Nov 11, 2016 at 11:29:48PM -0800, Don Lewis wrote: >> On 11 Nov, To: freebsd-current@FreeBSD.org wrote: >> > Yesterday I upgraded my ports builder box from r306349 to r308477. It >> > crashed overnight during a poudriere r

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

On 11 Nov, To: freebsd-current@FreeBSD.org wrote: > Yesterday I upgraded my ports builder box from r306349 to r308477. It > crashed overnight during a poudriere run. > > panic: mutex ncnegl not owned at /usr/src/sys/kern/vfs_cache.c:743 > cpuid = 2 > KDB: stack backtrace: >

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

Yesterday I upgraded my ports builder box from r306349 to r308477. It crashed overnight during a poudriere run. panic: mutex ncnegl not owned at /usr/src/sys/kern/vfs_cache.c:743 cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe085c2a4100

Re: PORTS_MODULES breakage on HEAD

On 12 Aug, Bryan Drewery wrote: > On 8/10/2016 4:20 PM, Bryan Drewery wrote: >> On 8/7/16 5:44 PM, Don Lewis wrote: >>> Adding PORTS_MODULES=emulators/virtualbox-ose-kmod recently broke on >>> HEAD. When I do that I get this failure: >>> >>> ===>

Re: kernel panic caused by virtualbox(?)

On 11 Aug, Konstantin Belousov wrote: > On Wed, Aug 10, 2016 at 04:47:15PM -0700, Don Lewis wrote: >> On 10 Aug, Jung-uk Kim wrote: >> > On 08/09/16 05:12 AM, Konstantin Belousov wrote: >> >> On Mon, Aug 08, 2016 at 04:44:20PM -0700, Don Lewis wrote: >> >

Re: kernel panic caused by virtualbox(?)

On 10 Aug, Jung-uk Kim wrote: > On 08/09/16 05:12 AM, Konstantin Belousov wrote: >> On Mon, Aug 08, 2016 at 04:44:20PM -0700, Don Lewis wrote: >>> On 8 Aug, Konstantin Belousov wrote: >>>> On Mon, Aug 08, 2016 at 10:22:44AM -0700, John Baldwin wrote: >>>>

Re: kernel panic caused by virtualbox(?)

On 8 Aug, Konstantin Belousov wrote: > On Mon, Aug 08, 2016 at 10:22:44AM -0700, John Baldwin wrote: >> On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote: >> > Reposted to -current to get some more eyes on this ... >> > >> > I just got a kernel p

Re: kernel panic caused by virtualbox(?)

On 8 Aug, Konstantin Belousov wrote: > On Mon, Aug 08, 2016 at 10:22:44AM -0700, John Baldwin wrote: >> On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote: >> > Reposted to -current to get some more eyes on this ... >> > >> > I just got a kernel p

Re: kernel panic caused by virtualbox(?)

On 8 Aug, John Baldwin wrote: > On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote: >> Reposted to -current to get some more eyes on this ... >> >> I just got a kernel panic when I started up a CentOS 7 VM in virtualbox. >> The host is: >> FreeBSD

PORTS_MODULES breakage on HEAD

Adding PORTS_MODULES=emulators/virtualbox-ose-kmod recently broke on HEAD. When I do that I get this failure: ===> Ports module emulators/virtualbox-ose-kmod (all) cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod; PATH=/usr/obj/usr/src/

kernel panic caused by virtualbox(?)

Reposted to -current to get some more eyes on this ... I just got a kernel panic when I started up a CentOS 7 VM in virtualbox. The host is: FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64 The virtualbox version is: virtualbox-ose-5.0.26 virtualbox-ose-kmod-5.0.26_1 The

Re: UTF-8 by default?

On 20 Jul, Tim Čas wrote: > On 20 July 2016 at 20:33, Don Lewis <truck...@freebsd.org> wrote: >> wc(1) has problems with its multibyte support pointed out by Coverity >> as I recall. > > Not sure how critical that issue is (e.g. byte counts [`-c`], line > counts [`-l

Re: UTF-8 by default?

On 20 Jul, Baptiste Daroussin wrote: > On Wed, Jul 20, 2016 at 10:47:45AM -0230, Jonathan Anderson wrote: >> On 20 Jul 2016, at 9:13, Tim Čas wrote: >> >> > So, without further ado: >> > 1) What are the reasons that UTF-8 isn't the default yet? >> > 2) Would it be possible to make this the

Re: zfs solaris assert panic in 11.0-ALPHA5 r302256

On 18 Jul, Andriy Gapon wrote: > On 18/07/2016 20:40, Don Lewis wrote: >> On 18 Jul, Andriy Gapon wrote: >>> On 08/07/2016 07:13, Don Lewis wrote: >>>> My package buiding machine just crashed with this panic during a >>>> poudriere run: >>>>

Re: zfs solaris assert panic in 11.0-ALPHA5 r302256

On 18 Jul, Andriy Gapon wrote: > On 08/07/2016 07:13, Don Lewis wrote: >> My package buiding machine just crashed with this panic during a >> poudriere run: >> >> panic: solaris assert: (dn->dn_phys->dn_nlevels == 0 && db->db_level == 0) >&g

Re: zfs solaris assert panic in 11.0-ALPHA5 r302256

On 7 Jul, To: freebsd-current@FreeBSD.org wrote: > My package buiding machine just crashed with this panic during a > poudriere run: > > panic: solaris assert: (dn->dn_phys->dn_nlevels == 0 && db->db_level == 0) || > dn->dn_phys->dn_nlevels > db->db_level || dn->dn_next_nlevels[txgoff] > >

zfs solaris assert panic in 11.0-ALPHA5 r302256

My package buiding machine just crashed with this panic during a poudriere run: panic: solaris assert: (dn->dn_phys->dn_nlevels == 0 && db->db_level == 0) || dn->dn_phys->dn_nlevels > db->db_level || dn->dn_next_nlevels[txgoff] > db->db_level || dn->dn_next_nlevels[(tx->tx_txg-1) & TXG_MASK] >

Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt

ul 2016 23:28:40 -0700 Andrey Chernov > > > <a...@freebsd.org> wrote > > > > On 07.07.2016 7:52, K. Macy wrote: > > > > > On Wednesday, July 6, 2016, Don Lewis <truck...@freebsd.org> > > > > > wrote: > > > > >

Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt

On 6 Jul, Matthew Macy wrote: > As a first step towards managing linux user space in a chrooted > /compat/linux, initially for i915 testing with intel gpu tools, later > on to get widevine and steam to work I'm trying to get apt to work. > I've fixed a number of issues to date in

Re: FreeBSD 11.0-ALPHA5 r302256 kernel panic in filt_proc()

On 30 Jun, Konstantin Belousov wrote: > On Wed, Jun 29, 2016 at 03:03:54PM -0700, Don Lewis wrote: >> On 30 Jun, Konstantin Belousov wrote: >> > On Wed, Jun 29, 2016 at 02:44:08PM -0700, Don Lewis wrote: >> >> #10 0x80a02ddc in filt_proc (kn=0xf803c5679

Re: FreeBSD 11.0-ALPHA5 r302256 kernel panic in filt_proc()

On 30 Jun, Konstantin Belousov wrote: > On Wed, Jun 29, 2016 at 02:44:08PM -0700, Don Lewis wrote: >> #10 0x80a02ddc in filt_proc (kn=0xf803c5679a80, >> hint=) at /usr/src/sys/kern/kern_event.c:473 >> #11 0x80a0173b in knote (list=, >> hint=21

FreeBSD 11.0-ALPHA5 r302256 kernel panic in filt_proc()

My package building machine just got this panic during a poudriere run: zipper.catspoiler.org dumped core - see /var/crash/vmcore.4 Wed Jun 29 14:28:21 PDT 2016 FreeBSD zipper.catspoiler.org 11.0-ALPHA5 FreeBSD 11.0-ALPHA5 #13 r302256: Tue Jun 28 15:00:17 PDT 2016

patch for potential race-condition triggered panic in dummynet PIE AQM

There is a race in the PIE AQM code that can cause a panic. A patch is up for review here: . I'd appreciate it if some callout gurus could take a look. ___ freebsd-current@freebsd.org mailing list

Re: VirtualBox network connectivity broken on recent -CURRENT

On 4 Jun, To: mm...@nextbsd.org wrote: > On 4 Jun, Matthew Macy wrote: >> >> >> >> On Sat, 04 Jun 2016 19:04:42 -0700 Randy Westlund >> <rwest...@gmail.com> wrote >> > On Fri, Jun 03, 2016 at 05:11:24PM -0700, Don Lewis wrote: >

Re: VirtualBox network connectivity broken on recent -CURRENT

On 5 Jun, Otacílio wrote: > Em 04/06/2016 23:04, Randy Westlund escreveu: >> On Fri, Jun 03, 2016 at 05:11:24PM -0700, Don Lewis wrote: >>> It looks like something changed in -CURRENT to break network >>> connectivity to VirtualBox guests. This was last known to wor

Re: VirtualBox network connectivity broken on recent -CURRENT

On 4 Jun, Matthew Macy wrote: > > > > On Sat, 04 Jun 2016 19:04:42 -0700 Randy Westlund > <rwest...@gmail.com> wrote > > On Fri, Jun 03, 2016 at 05:11:24PM -0700, Don Lewis wrote: > > > It looks like something changed in -CURRENT t

Re: VirtualBox network connectivity broken on recent -CURRENT

On 4 Jun, Alan Somers wrote: > On Fri, Jun 3, 2016 at 6:43 PM, Don Lewis <truck...@freebsd.org> wrote: >> On 3 Jun, Don Lewis wrote: >>> It looks like something changed in -CURRENT to break network >>> connectivity to VirtualBox guests. This was last known

Re: VirtualBox network connectivity broken on recent -CURRENT

On 3 Jun, Don Lewis wrote: > It looks like something changed in -CURRENT to break network > connectivity to VirtualBox guests. This was last known to work with > r299139 (May 6th) and is definitely broken with r301229. The VirtualBox > port revisions are: > virtualb

VirtualBox network connectivity broken on recent -CURRENT

It looks like something changed in -CURRENT to break network connectivity to VirtualBox guests. This was last known to work with r299139 (May 6th) and is definitely broken with r301229. The VirtualBox port revisions are: virtualbox-ose-4.3.38_1 virtualbox-ose-kmod-4.3.38 It looks

Re: r299512 breaks dhclient on some networks

On 18 May, Conrad Meyer wrote: > On Wed, May 18, 2016 at 5:19 PM, Don Lewis <truck...@freebsd.org> wrote: >> >> It looks to me like r299512 is changing the format of the client >> identifier by inserting the struct hardware hlen field into it. > > Yes. The proble

Re: r299512 breaks dhclient on some networks

On 18 May, Ian FREISLICH wrote: > On 05/18/16 20:19, Don Lewis wrote >> It looks to me like r299512 is changing the format of the client >> identifier by inserting the struct hardware hlen field into it. That's >> not valid if htype is non-zero the way I interpret RFC 2132.

Re: r299512 breaks dhclient on some networks

On 18 May, To: c...@freebsd.org wrote: > On 18 May, Conrad Meyer wrote: >> Hey Ian, >> >> r299512 incorrectly encoded client identifiers because I misunderstood >> the intent of the sizeof()-scaled client_id. I reverted that change >> and replaced it with r300174, which I believe fixes the first

Re: r299512 breaks dhclient on some networks

On 18 May, Conrad Meyer wrote: > Hey Ian, > > r299512 incorrectly encoded client identifiers because I misunderstood > the intent of the sizeof()-scaled client_id. I reverted that change > and replaced it with r300174, which I believe fixes the first overrun > more correctly. > > (Coverity may

Re: r299512 breaks dhclient on some networks

On 18 May, Ian FREISLICH wrote: > Hi > > I cannot for the life of me figure out why the change in r299512 breaks > DHCP on one network I use but not on another network. > > The only clue I can find is that the request whose response is ignored > has the following client ID: >

Re: CURRENT slow and shaky network stability

On 1 Apr, O. Hartmann wrote: > Am Wed, 30 Mar 2016 00:28:39 -0700 (PDT) > Don Lewis <truck...@freebsd.org> schrieb: >> Do you use tmpfs? Anything stored in there will get stashed in inactive >> memory and/or swap. > [...] > > Yes, /var/run and /tmp are on tmp

Re: CURRENT slow and shaky network stability

On 29 Mar, To: ohart...@zedat.fu-berlin.de wrote: > On 28 Mar, Don Lewis wrote: >> On 28 Mar, O. Hartmann wrote: > >> If I get a chance, I try booting my FreeBSD 11 machine with less RAM to >> see if that is a trigger. > > I just tried cranking hw.physmen down t

Re: CURRENT slow and shaky network stability

On 28 Mar, Don Lewis wrote: > On 28 Mar, O. Hartmann wrote: > If I get a chance, I try booting my FreeBSD 11 machine with less RAM to > see if that is a trigger. I just tried cranking hw.physmen down to 8 GB on 11.0-CURRENT r297204, GENERIC kernel. /boot/loader.conf

  1   2   3   4   5   >