It seems there are some additional constraints about non-existent
directories that now count as errors ..
--- sync_file.o ---
cc -O2 -pipe -fno-strict-aliasing -DLINUXKPI_VERSION=60100
'-DKBUILD_MODNAME="dmabuf"' -DCONFIG_DRM_AMDGPU_CIK
-DCONFIG_DRM_AMDGPU_SI -DCONFIG_DRM_AMD_DC -DCONFIG_DRM_
On 9/30/24 14:11, Gleb Smirnoff wrote:
On Sat, Sep 28, 2024 at 11:10:57PM +0100, void wrote:
v> I have found that *only* on arm64, locate errors like so:
v>
v> # sh /etc/periodic/weekly/310.locate
v>
v> Rebuilding locate database:
v> install: /var/db/INS@ArwCNx: Permission denied
v>
v> However, i
On 9/28/24 18:10, void wrote:
I have found that *only* on arm64, locate errors like so:
# sh /etc/periodic/weekly/310.locate
Rebuilding locate database:
install: /var/db/INS@ArwCNx: Permission denied
However, if it's run like this:
# sh /usr/libexec/locate.updatedb
WARNING
Executing updated
After commit aa48259f337100e79933d660fec8856371f761ed to src which
removed security_daily_compat_var, I get these warnings daily..
aaron.protected-networks.net login failures:
aaron.protected-networks.net refused connections:
/usr/local/etc/periodic/security/405.pkg-base-audit:
security_daily_
When a kernel is built without KDB and DDB, it fails with:
--- kernel.full ---
linking kernel.full
ld: error: undefined symbol: db_ctf_lookup_typename
>>> referenced by kern_ctf.c:329 (/usr/src/sys/kern/kern_ctf.c:329)
>>> link_elf_obj.o:(link_elf_ctf_lookup_typename)
>>> referenced
Building
/usr/obj/usr/src/amd64.amd64/sys/VM01-new/modules/usr/src/sys/modules/vmm/machine
machine -> /usr/src/sys/amd64/include
Building
/usr/obj/usr/src/amd64.amd64/sys/VM01-new/modules/usr/src/sys/modules/vmm/x86
x86 -> /usr/src/sys/x86/include
Building
/usr/obj/usr/src/amd64.amd64/sys/VM01
Moving these definitions breaks world outside the kernel :-(
building shared library libmapper_std.so.5
Building
/usr/obj/usr/src/amd64.amd64/lib/libiconv_modules/mapper_zone/libmapper_zone.so.5
building shared library libmapper_zone.so.5
Building /usr/obj/usr/src/amd64.amd64/lib/libstats/tcp
On 2/12/24 13:44, Michael Butler wrote:
On 2/12/24 12:36, John Baldwin wrote:
[ .. trimmed .. ]
Short of a stack trace, you can at least use lldb or gdb to lookup
the source line associated with the faulting instruction pointer (as
long as it isn't in a kernel module), e.g. for gd
On 2/12/24 12:36, John Baldwin wrote:
[ .. trimmed .. ]
Short of a stack trace, you can at least use lldb or gdb to lookup
the source line associated with the faulting instruction pointer (as
long as it isn't in a kernel module), e.g. for gdb you would use 'gdb
/boot/kernel/kernel' and then 'l
On 2/12/24 12:36, John Baldwin wrote:
On 2/10/24 2:09 PM, Michael Butler wrote:
I have stability problems with anything at or after this commit
(b377ff8) on an amd64 laptop. While I see the following panic logged, no
crash dump is preserved :-( It happens after ~5-6 minutes running in KDE
(X
I have stability problems with anything at or after this commit
(b377ff8) on an amd64 laptop. While I see the following panic logged, no
crash dump is preserved :-( It happens after ~5-6 minutes running in KDE
(X).
Reverting to 36efc64 seems to work reliably (after ACPI changes but
before the
I have a couple of RAID arrays attached to an old(-ish) LSI 9285CV-8e
controller and, while doing a backup between them, I seem to be running
into a driver/controller resource issue :-(
Every 5 minutes when a 'health check' runs, it logs a shower of "mrsas0:
Cannot allocate ioctl data mem" mes
On 9/18/23 14:27, Mike Karels wrote:
[ .. snip .. ]
avail memory = 16363008000 (15604 MB)
CPU microcode: updated from 0xc to 0x10
With the most recent microcode update, this device reports ..
CPU microcode: updated from 0xc to 0x11
.. and is now stable with vm.pmap.pcid_enabled=0,
vm.pm
On 8/8/23 13:50, Michael Butler wrote:
On 8/8/23 10:56, Tomoaki AOKI wrote:
On Tue, 8 Aug 2023 17:02:32 +0300
Konstantin Belousov wrote:
[ .. snip .. ]
The workaround is switched on automatically, when kernel detects
'small cores'
reported by CPUID.
If I read the code
On 8/8/23 10:56, Tomoaki AOKI wrote:
On Tue, 8 Aug 2023 17:02:32 +0300
Konstantin Belousov wrote:
[ .. snip .. ]
The workaround is switched on automatically, when kernel detects 'small cores'
reported by CPUID.
If I read the code correctly, vm.pmap.pcid_invlpg_workaround
(precicely, the c
On 4/23/23 07:47, Peter Jeremy wrote:
Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed,
some change in the kernel has made ntpd stop working on my arm64 test
box. (My amd64 test box is a couple of days behind so I'm not sure if
it's arm-specific).
[ .. snip .. ]
While I can'
On 6/15/22 18:47, Masachika ISHIZUKA wrote:
I updated to master-n256084-5dd1f6f1441 (1400061) and this
leads to bc to 5.3.1.
Previosly, 'BC-ENV-APRG=-P' or 'bc -P' were working but it
doesn't work on 5.3.1. Is there any way to supress prompt ?
This is fixed in 5.3.2:
This version is al
After 695052e, the directories compat, dtrace, engines, flua, i18n and
libxo now get created under /usr. This is one level higher than they
should be.
The fix appears to be something like ..
diff --git a/etc/mtree/BSD.usr.dist b/etc/mtree/BSD.usr.dist
index 9f934976b77..95a711a4418 100644
---
On 6/5/22 02:09, Hans Petter Selasky wrote:
On 6/4/22 23:21, Michael Butler wrote:
On a Dell E6430 laptop with an i5-3340M CPU on-board but no additional
video adapter, this commit causes a panic when i915kms is loaded :-(
This adapter does not use any additional firmware.
Does the
On a Dell E6430 laptop with an i5-3340M CPU on-board but no additional
video adapter, this commit causes a panic when i915kms is loaded :-(
This adapter does not use any additional firmware.
Reverting only this change allows me to run way past it - up to commit
00b0158d2ca, so far.
All modul
On 5/23/22 12:49, Dima Panov wrote:
My recent -current jail is also have LLVM_DEFAULT=14 and not hit any
serious issue yet:)
tcberner was initiated exp-run to make llvm13 as default some time ago
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263456
I'd caution against adopting llvm14 fo
On 4/21/22 03:42, Emmanuel Vadot wrote:
Hello Michael,
On Wed, 20 Apr 2022 23:39:12 -0400
Michael Butler wrote:
Seems this new requirement breaks kmod builds too ..
The first of many errors was (I stopped chasing them all for lack of
time) ..
--- amdgpu_cs.o ---
/usr/ports/graphics/drm
Seems this new requirement breaks kmod builds too ..
The first of many errors was (I stopped chasing them all for lack of
time) ..
--- amdgpu_cs.o ---
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.7.19_3/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1210:26:
error: variable 'priority' set
On 4/16/22 01:22, Gleb Smirnoff wrote:
Hi Florian, Hi Michael,
On Fri, Apr 15, 2022 at 06:11:13PM -0400, Michael Butler wrote:
M> >> I can reproduce this locally, will try to figure out what is going on.
M> >> If you can bisect it, it would be great.
M> >
On 4/15/22 17:39, Florian Smeets wrote:
On 15.04.22 21:24, tue...@freebsd.org wrote:
On 15. Apr 2022, at 20:20, Florian Smeets wrote:
Hi,
there seems to be an issue with local IPv6 TCP connections on main. I
have been seeing this for a couple of months at least. pkg upgr on my
webserver ho
On 2/27/22 16:09, Larry Rosenman wrote:
On 02/27/2022 3:03 pm, Michael Butler wrote:
[ cc list trimmed ]
On 2/27/22 14:16, Larry Rosenman wrote:
I was able to export the rest of the datasets, and re-install
14-CURRENT from a recent snapshot, and restore the datasets I care
about.
I'
[ cc list trimmed ]
On 2/27/22 14:16, Larry Rosenman wrote:
I was able to export the rest of the datasets, and re-install 14-CURRENT
from a recent snapshot, and restore the datasets I care about.
I'm now seeing:
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOC
Timecounter "TSC" frequency 701570048 Hz quality 800
.. but before initializing ipfw as it used to,
Michael
On 12/21/21 12:01, Michael Butler via freebsd-current wrote:
I have an old pentium-3 that also won't boot kernels built after Dec 6th.
I suspect the commits l
I have an old pentium-3 that also won't boot kernels built after Dec 6th.
I suspect the commits listed below but, with the device being remote and
having no DRAC, I'm struggling to test this theory.
The relevant commits ..
commit 553af8f1ec71d397b5b4fd5876622b9269936e63
Author: Mark Johnston
I should have been more specific ..
I'm observing that "/usr/src/release/release.sh -c release-i386.conf"
fails when targeting a i386 build on an amd64 host :-(
On 11/16/21 02:33, Warner Losh wrote:
A meta-build worked for me just now...
Warner
On Mon, Nov 15, 2021 at
Haven't had time to identify which change caused this yet but I now get ..
===> lib/libsbuf (obj,all,install)
===> cddl/lib/libumem (obj,all,install)
===> cddl/lib/libnvpair (obj,all,install)
===> cddl/lib/libavl (obj,all,install)
ld: error: /usr/obj/usr/src/i386.i386/tmp/usr/lib/libspl.a(assert.
On 11/3/21 11:13, Konstantin Belousov wrote:
On Wed, Nov 03, 2021 at 11:05:11AM -0400, Michael Butler via freebsd-emulation
wrote:
On 11/3/21 10:36, Ed Maste wrote:
The kgdb back-trace isn't any more enlightening to me :-(
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:
On 11/3/21 10:36, Ed Maste wrote:
On Tue, 2 Nov 2021 at 18:32, Michael Butler via freebsd-emulation
wrote:
Before reporting this, I rebuilt world including kernel, all kmods and
virtualbox itself to no avail :-(
Thanks for confirming.
Now that the WARN_ON noise is disabled by default would
On 11/2/21 17:48, Cy Schubert wrote:
In message <36923A7F-23DE-490D-B1FA-A8B064740BD6@unrelenting.technology>,
Greg
V via freebsd-current writes:
On November 2, 2021 5:16:35 PM GMT+03:00, Michael Butler via freebsd-current
wrote:
On current as of this morning (I haven't tried to
On current as of this morning (I haven't tried to bisect yet) ..
FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD
14.0-CURRENT #42 main-a670e1c13a: Tue Nov 2 09:29:28 EDT 2021
r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI
amd64
.. with eit
But kernel failed to install. I will include log tomorrow, I'm doing a
clean build with /usr/obj/.. deleted.
Michael Butler via freebsd-current <mailto:freebsd-current@freebsd.org>> escreveu no dia quinta, 21/10/2021
à(s) 20:14:
Well this is different .. I did a full rebu
Well this is different .. I did a full rebuild (after "rm -rf
/usr/obj/*") this morning and now see ..
===> linux_common (install)
install -T release -o root -g wheel -m 555 linux_common.ko /boot/kernel/
install -T dbg -o root -g wheel -m 555 linux_common.ko.debug
/usr/lib/debug/boot/kernel
red *active_cred __unused, struct thread *td __unused)
+#endif
{
/* XXX need to define flags for st_mode */
On 10/11/21, Michael Butler via freebsd-current
wrote:
After the latest freebsd version bump in param.h, I tried to rebuild the
DRM modules. It failed with ..
--- dma-bu
After the latest freebsd version bump in param.h, I tried to rebuild the
DRM modules. It failed with ..
--- dma-buf.o ---
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/drivers/dma-buf//dma-buf.c:121:1:
error: conflicting types for 'dma_buf_stat'
dma_buf_stat(struct file *fp, s
On 10/7/21 20:19, Konstantin Belousov wrote:
On Thu, Oct 07, 2021 at 05:43:14PM -0400, Michael Butler wrote:
On 10/7/21 16:52, Mark Johnston wrote:
On Thu, Oct 07, 2021 at 04:18:28PM -0400, Michael Butler via freebsd-current
wrote:
On 10/7/21 15:39, Konstantin Belousov wrote:
On Thu, Oct 07
On 10/7/21 16:52, Mark Johnston wrote:
On Thu, Oct 07, 2021 at 04:18:28PM -0400, Michael Butler via freebsd-current
wrote:
On 10/7/21 15:39, Konstantin Belousov wrote:
On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current
wrote:
While building a local release bundle
On 10/7/21 15:39, Konstantin Belousov wrote:
On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current
wrote:
While building a local release bundle, I sometimes get bsdtar failing (and
dumping core) as follows below. Worse, as can be seen below, it doesn't stop
the
While building a local release bundle, I sometimes get bsdtar failing
(and dumping core) as follows below. Worse, as can be seen below, it
doesn't stop the build unless I happen to notice and it yields an
incomplete package.
a usr/src/sys/netgraph/ng_checksum.h
a usr/src/sys/netgraph/ng_messag
After commit ddedf2a11eb20af1ee52cb3da70a57c21904af8f date fails to
recognize any configured timezone when WITH_DETECT_TZ_CHANGES is not set.
For example ..
imb@vm01:/home/imb> date
Tue Sep 14 01:25:57 2021
Every other daemon also thinks it's running in UTC+0 :-(
When libc is recompiled with
On 7/29/21 6:09 AM, Michael Gmelin wrote:
On Wed, 28 Jul 2021 16:02:30 -0400
Ed Maste wrote:
On Wed, 28 Jul 2021 at 15:15, Michael Butler via freebsd-current
wrote:
What prompted the question was my (obviously poor) attempt to debug
and resolve this failure when attempting to build a
On 7/28/21 1:36 PM, Warner Losh wrote:
On Wed, Jul 28, 2021 at 11:31 AM Michael Butler via freebsd-current <
freebsd-current@freebsd.org> wrote:
I tripped over this while trying to build a local release ..
imb@toshi:/home/imb> pkg --version | awk -F. '{print $$1 * 1 + $
NVM .. it's the escaping of '$' ..
On 7/28/21 1:29 PM, Michael Butler via freebsd-current wrote:
I tripped over this while trying to build a local release ..
imb@toshi:/home/imb> pkg --version | awk -F. '{print $$1 * 1 + $$2 *
100 + $$3}'
10001
imb@toshi:/ho
I tripped over this while trying to build a local release ..
imb@toshi:/home/imb> pkg --version | awk -F. '{print $$1 * 1 + $$2 *
100 + $$3}'
10001
imb@toshi:/home/imb> pkg --version
1.17.1
Is this expected?
imb
On 6/8/21 3:42 PM, Juraj Lutter wrote:
On 8 Jun 2021, at 21:38, bob prohaska wrote:
FWIW, same problem seen here. In an added twist, git pull (hoping for
a fix) fails also:
root@www:/usr/src # git pull
error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/legacy':
'refs/remotes/freeb
This is likely fixed as of ~30 mins ago on commit
e8b9c508b7ae5be618ada089103468c400e465cd
The cause appears to have been commit d36d6816151705907393889
imb
On 4/9/21 4:55 PM, Yasuhiro Kimura wrote:
yasu@rolling-vm-freebsd1[1044]% uname -a
FreeBSD rolling-vm-freebsd1.home.utahime.org
On 3/13/21 3:00 PM, Hartmann, O. wrote:
On Sat, 13 Mar 2021 19:52:47 + (UTC)
Filippo Moretti via freebsd-current wrote:
I had the same problem in console modeFiippo
On Saturday, March 13, 2021, 8:33:57 PM GMT+1, Stefan Esser
wrote:
Am 13.03.21 um 20:17 schrieb Hartmann, O.:
S
Seems there's a typo in this when INVARIANTS is not turned on ..
diff --git a/sys/kern/kern_jail.c b/sys/kern/kern_jail.c
index 48c91a95bf..342af50462 100644
--- a/sys/kern/kern_jail.c
+++ b/sys/kern/kern_jail.c
@@ -2671,7 +2671,7 @@ prison_free_not_last(struct prison *pr)
("prison_fr
Any ideas what broke this?
--
>>> Kernel build for GENERIC completed on Tue Feb 9 20:48:05 UTC 2021
--
>>> Kernel(s) GENERIC built in 465 seconds, ncpu: 8, make -j8
-
I have a few machines on which I've been hesitant to run 'zpool upgrade'
as I'm not sure of the (boot?) implications. They report like this ..
imb@toshi:/home/imb> uname -a
FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD
14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST
Not for me, it's not ..
imb@toshi:/usr/src/usr.sbin/pkg> pkg info -a
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: n
And yet ..
imb@toshi:/home/imb> ll /usr/local/sbin/pkg
-rwxr-xr-x 1 root wheel 2890304 Oct 11 09:54 /usr/loc
On 9/20/20 10:58 AM, Mark Murray wrote:
Hi *
I've been getting these build failures for a while (weeks/months). The machine is a MacchiatoBin
DoubleShot (arm64, Quad core). with SATA disks and zfs filesystem. If I empty out /usr/obj, then
the build works, but takes a few hours. If I do a no-cl
e doesn't generate the error ..
imb@vm01:/home/imb> touch xx
imb@vm01:/home/imb> cp xx yy
imb@vm01:/home/imb>
imb@vm01:/home/imb> cp /dev/null yy
cp: /dev/null: Invalid argument
imb@vm01:/home/imb>
>
> On Thu, Sep 10, 2020 at 11:45 AM Michael Butler
> wrote:
>> It
It seems that SVN r365549 broke "cp /dev/null ..."
imb
On 9/10/20 10:35 AM, Michael Butler wrote:
> Is anyone else seeing failures like this in building world and, in my
> case, cron jobs as well?
>
>
> Building /usr/obj/usr/src/amd64.amd64/stand
Is anyone else seeing failures like this in building world and, in my
case, cron jobs as well?
Building /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr
--- all_subdir_sbin ---
Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel
--- all_subdir_stand ---
--- zfsboot.ldr ---
cp:
On 8/29/20 5:48 PM, Glen Barber wrote:
> On Sat, Aug 29, 2020 at 09:43:25PM +, Glen Barber wrote:
>> On Sat, Aug 29, 2020 at 09:40:17PM +, Glen Barber wrote:
[ .. ]
>>> Nevermind, I see the problem. Standby.
>>>
>>
>> r364966 should fix it. Thank you again for your help here.
>>
>
> S
On 8/29/20 5:17 PM, Glen Barber wrote:
> On Sat, Aug 29, 2020 at 04:38:05PM -0400, Michael Butler wrote:
>> The build-from-existing mode fails with ..
>>
>> imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf
>> fatal: not a git repository (or any
On 8/29/20 12:04 PM, Glen Barber wrote:
> On Sat, Aug 29, 2020 at 03:51:23PM +, Glen Barber wrote:
>> I added a way to update an existing tree in r364959. I have only done
>> very trivial testing on this change, however, so please let me know if
>> it does not work as expected.
>>
> r364960 fu
On 8/29/20 11:14 AM, Glen Barber wrote:
> NOPORTS=yes is the problem, and I forgot to address it before merging
> the project branch back. Please try with r364956.
Trying now but, in the interim, I noted ..
With SVN, I could re-use a previously existing build directory and it
would simply apply
On 8/28/20 1:44 PM, Glen Barber wrote:
> Note, not entirely tested, however, since future snapshots and 13.0 will
> be exclusively built from the git sources.
When building with ..
## Set miscellaneous 'make release' settings.
NODOC=yes
NOPORTS=yes
WITH_DVD=yes
The build fails after building th
Is there any documentation around the changes to the release build
system from SVN to GIT?
I currently keep a mirrored SVN repo and the revised release scripts
seem not to have that as a build option. Can I still use this or do I
need to throw it all out and start over?
With one target machine be
Any thoughts as to why this is happening when I build a (custom) kernel?
kldxref: /boot/kernel/kernel: too many segments
imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe,
When cross-compiling for i386 on amd64 (which has 2 by 4 cores), I get
the error below after a previously successful build.
Running the build again (a 3rd time) completes successfully :-(
This is the output from
cd /usr/src/release; ./release.sh -c release-i386.conf
[ .. ]
===> usr.bi
ake: stopped in /usr/ports/shells/bash
> (bash)5025}
>
>> On Jul 8, 2020, at 5:33 PM, Michael Butler
>> wrote:
>>
>> Did the bmake update break the updating of ports or something else?
>>
>> # sudo -E portmaster -a
>> ===>>> Gathering disti
Did the bmake update break the updating of ports or something else?
# sudo -E portmaster -a
===>>> Gathering distinfo list for installed ports
===>>> Starting check of installed ports for available updates
make: "/usr/ports/Mk/Uses/python.mk" line 384: warning: String
comparison operator should b
I'm seeing this message repeatedly during port builds. Should I be
concerned?
file: File 5.39 supports only version 16 magic files.
`/usr/share/misc/magic.mgc' is version 14
imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.
On 4/15/20 7:19 PM, Michael Butler wrote:
> This instance is/was running in a jail but now fails sometime after SVN
> r359823 .. I'm trying to bisect but any hints appreciated ..
>
> named[98746]:
> named[98746]: BIN
This instance is/was running in a jail but now fails sometime after SVN
r359823 .. I'm trying to bisect but any hints appreciated ..
named[98746]:
named[98746]: BIND 9 is maintained by Internet Systems Consortium,
named[98746]: Inc. (ISC), a non
In case anyone else is seeing this ..
Forwarded Message
Subject: Re: SVN r358655 breaks i386 buildworld :-(
Date: Thu, 5 Mar 2020 09:49:01 -0500
From: Michael Butler
To: Gleb Smirnoff
On 3/4/20 10:00 PM, Michael Butler wrote:
> On i386, I get this ..
>
> Building
&
On 2/21/20 11:49 AM, Ed Maste wrote:
> It seems starting sshd from inetd via tcpd is a reasonable approach
> for folks who want to use it; also, have folks using libwrap looked at
> sshd's Match blocks to see if they provide the desired functionality?
While match blocks can disallow a login from a
Seems there's an issue with freebsd.org's reverse DNS resulting in
refused email, e.g.
Feb 17 08:58:54 mail postfix/smtpd[41811]: NOQUEUE: reject: RCPT from
unknown[2610:1c1:1:606c::19:2]: 550 5.7.25 Client host rejected: cannot
find your hostname, [2610:1c1:1:606c::19:2];
from= to=
proto=ESMTP he
On 2/14/20 6:37 PM, Ben Woods wrote:
> On Sat, 15 Feb 2020 at 4:27 am, Joey Kelly wrote:
>
>> On Friday, February 14, 2020 01:18:44 PM Ed Maste wrote:
>>> Upstream OpenSSH-portable removed libwrap support in version 6.7,
>>> released in October 2014. We've maintained a patch in our tree to
>>> res
-current now fails to build the DRM drivers :-(
Building
/usr/obj/usr/src/amd64.amd64/sys/TOSHI/modules/usr/local/sys/modules/drm-current-kmod/drm/drm_os_freebsd.o
--- drm_os_freebsd.o ---
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_os_freebsd.c:47:3:
error: implicit declaration of
This member removal has other consequences. As follows ..
--- lib/libprocstat__L ---
Building /usr/obj/usr/src/amd64.amd64/lib/libprocstat/smbfs.o
--- libprocstat.o ---
/usr/src/lib/libprocstat/libprocstat.c:620:29: error: no member named
'next' in 'struct vm_map_entry'
for (entryp
Something missing from a header here?
Building /usr/obj/usr/src/amd64.amd64/sys/VM01/uma_core.o
--- uma_core.o ---
/usr/src/sys/vm/uma_core.c:1864:39: error: use of undeclared identifier
'sysctl___vm_uma'
zone->uz_oid = SYSCTL_ADD_NODE(NULL,
SYSCTL_STATIC_CHILDREN(_vm_uma),
The no-relax flag can't be used on all architectures ..
Building /usr/obj/usr/src/amd64.amd64/usr.sbin/jail/jail
--- jail ---
ld: error: unknown argument '--no-relax'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
--- all_subdir_usr.sbin/portsnap ---
--- all_subdir_us
I'm sure I did this yesterday without a failure; any hints as to what
broke/how to fix it?
imb
===> tests/sys/cddl/zfs/tests/threadsappend (all)
===> tests/sys/cddl/zfs/tests/truncate (all)
===> usr.sbin/amd/libamu (all)
===> usr.sbin/audit (all)
===> tests/sys/cddl/zfs/tests/txg_integrit
On 11/2/19 5:15 PM, Toomas Soome wrote:
> Should be fixed by r354265.
The problem has moved .. now the kernel won't build ..
Building /usr/obj/usr/src/amd64.amd64/sys/VM01/avl.o
Building /usr/obj/usr/src/amd64.amd64/sys/VM01/lz4.o
--- lz4.o ---
cc: error: no such file or directory:
'/usr/src/sys/
Something missing from SVN r354253?
Building /usr/obj/usr/src/amd64.amd64/rescue/rescue/rescue
ld: error: undefined symbol: lz4_init
>>> referenced by spa_misc.c:2066
(/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2066)
>>> spa_misc.o:(spa_init) in archive
/usr/o
On 10/24/19 1:56 PM, Gleb Smirnoff wrote:
> On Thu, Oct 24, 2019 at 11:12:10AM -0400, Michael Butler wrote:
> M> The removal of these KPIs yields:
> M>
> M> link_elf_obj: symbol if_multiaddr_array undefined
> M> linker_load_file: /boot/modules/if_em_updated.ko - unsupp
The removal of these KPIs yields:
link_elf_obj: symbol if_multiaddr_array undefined
linker_load_file: /boot/modules/if_em_updated.ko - unsupported file type
imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listi
sys/net/route.c will no longer compile when VIMAGE is removed from the
kernel,
imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr.
In rc.d/sysvipc we see ..
name="sysvipc"
desc="Load SysV IPC modules"
rcvar="sysvipc_enable"
start_cmd="${name}_start"
.. so it won't try to run without explicitly setting sysvipc_enable in
/etc/rc.conf.
However in rc.d/linux, we have only ..
name="linux"
desc="Enable Linux ABI"
start_cmd="${n
On 9/8/19 7:09 PM, Alan Somers wrote:
> On Sun, Sep 8, 2019 at 5:00 PM Clay Daniels Jr.
> wrote:
>
>> I want to view my Windows C: drive on ata0p4.
>> This is what I have:
>> FreeBSD bsd13 13.0-CURRENT FreeBSD 13.0-CURRENT r351901 GENERIC amd64
>> clay@bsd13:~ % pkg info -r fusefs-libs
>> fusefs
On 2019-08-27 19:41, Michael Butler wrote:
> On 2019-08-27 19:15, Niclas Zeising wrote:
>> On 2019-08-28 00:38, Alexander Motin wrote:
>>> Hi.
>>>
>>> On 27.08.2019 18:03, Niclas Zeising wrote:
>>>> I have an issue where the ses driver no longer att
On 2019-08-27 19:15, Niclas Zeising wrote:
> On 2019-08-28 00:38, Alexander Motin wrote:
>> Hi.
>>
>> On 27.08.2019 18:03, Niclas Zeising wrote:
>>> I have an issue where the ses driver no longer attaches. Last known
>>> good version was r351188, r351544 is broken. In that interval,
>>> something
On 2019-08-24 19:09, Michael Butler wrote:
> On 2019-08-24 14:04, Konstantin Belousov wrote:
>> On Sat, Aug 24, 2019 at 11:02:20AM -0600, Warner Losh wrote:
>>> forward declaring struct pcpu; in md_var.h "fixes" this, but I'm not sure
>>> that's the
On 2019-08-24 14:04, Konstantin Belousov wrote:
> On Sat, Aug 24, 2019 at 11:02:20AM -0600, Warner Losh wrote:
>> forward declaring struct pcpu; in md_var.h "fixes" this, but I'm not sure
>> that's the right fix.
> More correct way to fix it is to include sys/pcpu.h before machine/md_var.h,
> same
As follows ..
Building
/usr/obj/usr/src/amd64.amd64/sys/TOSHI/modules/usr/local/sys/modules/drm-current-kmod/linuxkpi/linux_compat.o
--- linux_compat.o ---
In file included from
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_compat.c:5:
./machine/md_var.h:61:34: error: declaratio
As follows ..
--- kern_sysctl.o ---
/usr/src/sys/kern/kern_sysctl.c:1623:19: error: use of undeclared
identifier 'kdb_active'
if (arg2 == 0 || kdb_active) {
^
1 error generated.
*** [kern_sysctl.o] Error code 1
imb
___
On 2019-05-19 23:21, Johannes Lundberg wrote:
>
> On 5/19/19 7:36 PM, Steve Kargl wrote:
>> On Sun, May 19, 2019 at 02:50:54PM -0700, Johannes Lundberg wrote:
>>> LinuxKPI in base have received a lot of updates recently for Linux 5.0,
>>> a couple of them will break drm-current-kmod. So, as of r34
On 2019-05-09 14:38, Gleb Smirnoff wrote:
> On Thu, May 09, 2019 at 02:32:44PM -0400, Michael Butler wrote:
> M> (kgdb) frame 8
> M> #8 0x80a15377 in ip_output (m=, opt= M> optimized out>, ro=0x0, flags=0, imo=0xfe0072b14780, inp=0x0) at
> M> /usr/src/sys/
On 2019-05-09 14:22, Gleb Smirnoff wrote:
> Michael,
>
> On Thu, May 09, 2019 at 10:25:37AM -0500, Kyle Evans wrote:
> K> > #0 doadump () at src/sys/amd64/include/pcpu.h:241
> K> > #1 0x808393c8 in kern_reboot (howto=260) at
> K> > /usr/src/sys/kern/kern_shutdown.c:470
> K> > #2 0xfff
On 2019-05-09 14:03, ossobser...@redchan.it wrote:
> Background: Apparently a FreeBSD developer, a viking looking fellow,
Further miscellaneous dribble elided ..
This has no place on this mailing list. Take your hate someplace else,
imb
___
f
On 2019-05-09 09:07, Kyle Evans wrote:
> On Thu, May 9, 2019 at 7:24 AM Michael Butler
> wrote:
>>
>> Seems there's a lock or tuntap issue after recent changes. Restarting
>> openvpn (configured to use /dev/tap) yields a panic as follows:
>>
>
> Ah, I
Seems there's a lock or tuntap issue after recent changes. Restarting
openvpn (configured to use /dev/tap) yields a panic as follows:
(kgdb) bt
#0 doadump () at src/sys/amd64/include/pcpu.h:241
#1 0x808393c8 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:470
#2 0xff
1 - 100 of 412 matches
Mail list logo
