WiFi NIC driver
wifi-firmware-mt7601u-kmod-20241017.1500043_2 Firmware modules for the mt7601u
(mt7601u) WiFi NIC driver
wifi-firmware-rtw88-kmod-20241017.1500043_2 Firmware modules for the rtw88
(rtw88) WiFi NIC driver
wifi-firmware-rtw89-kmod-20241017.1500043_2 Firmware modules for the rtw89
(rtw89) WiFi NIC driver
Adding such a package somewhat later after installing
FreeBSD-base, when FreeBSD-base happens to have been
updated between, could be problematical.
===
Mark Millard
marklmi at yahoo.com
On Jun 24, 2025, at 20:08, Mark Millard wrote:
> [This is based on what I eventually noticed in the material
> of my reply to a different message on freebsd-current .]
>
> Modern https://cgit.freebsd.org/src/blame/sys/sys/param.h has:
>
> #define __FreeBSD_version 150004
ain and handled separately.
NOTE: I've not checked any context but main. But it may well
be that 14.3-STABLE's PkgBase has some similar issues to what
main has.
===
Mark Millard
marklmi at yahoo.com
“comconsole”) if the
/usr/share/man/man8/loader_simp.8.gz: console variable, or set it to serial
console (“comconsole”) if the
/usr/share/man/man5/loader.conf.5.gz: console (“vidconsole”)
“comconsole” selects serial console,
vs. the lack of any reference to eficom:
# man -K efi
g the likes, of, for example, llvm, including the likes
of 20 -> 21 and such? (More generally: Update some contributed
materials that are not normally security updates but tend to get
updates over time, even if not much else changes part of the
time?)
===
Mark Millard
marklmi at yahoo.com
I normally expand the likes of kernel.txz somewhere
(empty directory) and then mv its boot/kernel to a
/boot/NEWuniqueNAME . Similar issue for
kernel-dbg.txz for its paths involved, matching
NewuniqueNAME . Then I use the name for booting
that specific kernel.
My wording does not get into using zfs to advantage
or the like. [I only use ZFS on the biggest system
configuration (RAM, media capacity, media speed,
FreeBSD-cpus count, and cpu speed combination).]
> Normally, not a problem. Simply rebuild install(1)
> with -static added to CFLAGS. Unfortunately, this
> leads to a bunch of linker errors about relocations
> and rebuilding a few libraries wtih -fPIC.
===
Mark Millard
marklmi at yahoo.com
IRPREFIX
changes.
That leads me to expect that it is really setting up overall
use of .MAKE.META.IGNORE* variables that you want to learn about,
with SB_OBJROOT use just being a (new) smaller detail involved in
that.
Sound right?
> Thanks
>
>> Simon J. Gerraty escreveu (terça, 13/05
ream
> Issues are appearing. . . .
> . . .
I've never had troubles with my issue submittals on
github, including the one today about the bug
referenced above. (Not that I submit such very often.)
The submittal shows up just fine (#2450).
===
Mark Millard
marklmi at yahoo.com
[I managed to not send the original to the list.]
On May 26, 2025, at 07:14, Mark Millard wrote:
>
> Dennis Clarke wrote on
> Date: Mon, 26 May 2025 12:25:50 UTC :
>
>> On 5/24/25 21:47, Mark Millard wrote:
>>> Dennis Clarke wrote on
>>> Date: Sat, 24 M
d64.amd64/sys/GENERIC amd64 amd64 1500043
1500043
t#
t# cc --version
FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git
llvmorg-19.1.7-0-gcd708029e0b2)
Target: x86_64-unknown-freebsd15.0
Thread model: posix
InstalledDir: /usr/bin
Build config: +assertions
===
Mark Millard
marklmi at yahoo.com
On May 23, 2025, at 12:13, Dennis Clarke wrote:
> On 5/23/25 15:00, Mark Millard wrote:
>> Dennis Clarke wrote on
>> Date: Fri, 23 May 2025 17:45:17 UTC :
>>> I have been watching qt6-webengine-6.8.3 fail over and over and over
>>> for some days now and it ta
the amount of RAM). (For 64-bit contexts, the system
tends to complain somewhat above, say, SWAP=3.6*RAM,
so above RAM+SWAP=4.6*RAM . The detailed figure varies
some from build to build and the "3.6" has some margin
to avoid detailed tracking of the variations.)
===
Mark Millard
marklmi at yahoo.com
ed by DSO
The error is tied to statically linked contexts, which is involved
in building lang/gcc14.
This is tied the main-* having libsys now, which is why
13*releng-armv7 and 14*releng-armv7 do not have the issue.
===
Mark Millard
marklmi at yahoo.com
On May 20, 2025, at 08:34, Dennis Clarke wrote:
> On 5/20/25 01:51, Mark Millard wrote:
>> Dennis Clarke wrote on
>> Date: Tue, 20 May 2025 02:33:58 UTC:
>>> Just an odd message to see on the console :
>>>
>>> # witness_lock_list_get: w
return (NULL);
> }
> w_lock_list_free = lle->ll_next;
> mtx_unlock_spin(&w_mtx);
> bzero(lle, sizeof(*lle));
> return (lle);
> }
>
> Where it seems that indeed witness_watch has been flipped to -1 and that
> functionality is now gone?
Until the next boot, anyway.
===
Mark Millard
marklmi at yahoo.com
ot;pkg add" in the code. Ignoring
$FreeBSD$ removals, the script was last modified on
2021-06-30 .
(I ran into this while looking for something else via
a fairly general grep. I'm not using the script.)
===
Mark Millard
marklmi at yahoo.com
On May 13, 2025, at 12:37, Mark Johnston wrote:
>
> On Mon, May 12, 2025 at 09:10:54PM -0700, Mark Millard wrote:
>> To test the status of a couple of old armv7 networking bugzilla
>> submittal I'd done, I ran my old script for preloading various
>> kernel modules us
On May 13, 2025, at 08:43, Simon J. Gerraty wrote:
> Mark Millard wrote:
>>> Use of a:
>>>
>>> env __MAKE_CONF="/usr/home/root/src.configs/make.conf"
>>>
>>> prefix for each make command and the file content
>>> like show
PRIO loaded
load_dn_sched dn_sched FQ_CODEL loaded
load_dn_sched dn_sched FQ_PIE loaded
load_dn_aqm dn_aqm CODEL loaded
load_dn_aqm dn_aqm PIE loaded
Loaded dummynet.ko, id=46
# uname -apKU
FreeBSD OPiP2E-RPi2v1p1 15.0-CURRENT FreeBSD 15.0-CURRENT
main-n277207-62f55b34ec42 GENERIC arm armv7 1500042 1500042
(So that is an official PkgBase installation, having booted
kernel instead of kernel-NODEBUG .)
===
Mark Millard
marklmi at yahoo.com
wc xargs
> .MAKE.META.IGNORE_PATHS+=
> ${IGNORELEGACY_NOSYMLINKPREFIX}/sbin/${ignore_legacy_tool}
> .endfor
> #
> .for ignore_other_tool in ctfconvert objcopy nm
> .MAKE.META.IGNORE_PATHS+= ${IGNOREOTHER_NOSYMLINKPREFIX}/${ignore_other_tool}
> .endfor
> #
> .MAKE.META.IG
ng on?
> > I can do some testing on my side too.
>
> https://reviews.freebsd.org/D50313
>
> buildworld is happy.
>
> > > > I think you could use something like this, which should be safe to
> > > > commit:
> > >
> > > I do not have a commit bit. Should I submit a bugzilla
> > > entry or something for its eventual commit?
> >
> > That's ok. Confirm it works for you and I'll see if I can break
> > anything with it
===
Mark Millard
marklmi at yahoo.com
On May 6, 2025, at 16:07, Simon J. Gerraty wrote:
> Mark Millard wrote:
>> Yes, if the value of MAKEOBJDIRPREFIX isn't consistent that's going to
>> cause problems (I'd call it a bug). If so don't use MAKEOBJDIRPREFIX
>> directly, set some other variab
On May 6, 2025, at 13:14, Simon J. Gerraty wrote:
> Mark Millard wrote:
>>> Of course trying to get too clever can end up being counter productive,
>>> but the tools are there...
>>
>> I still have the addition that we found was needed
>> in my exp
On May 6, 2025, at 11:09, Simon J. Gerraty wrote:
> Mark Millard wrote:
>>>> # cd /usr/src
>>>> # make buildworld-jobs buildkernel-jobs
>>
>> The above used older commands and files from before
>> the following install. META_MODE recorded the us
LANG_FULL:
WITHOUT_CLANG_FULL
Avoid building the ARCMigrate, Rewriter and StaticAnalyzer
components of the Clang C/C++ compiler.
Again, possibly avoiding the RPi4B spending the time
building what is not used.
> Cheers,
>
> Mark Millard escreveu (te
xts and
have never used FreeBSD on an actual i386 class system.)
> My first concern is to speed up builds expecially on rpi4.
Per some prior questions: What other constraints must
also be met?
> Any hints are welcome.
>
> Thanks,
>
>
> Mark Millard escreveu (segunda, 5/
of these. But, in the end, it
involved use of experimental code in
share/mk/src.sys.obj.mk to provide a new
definition to use to build some paths with.
The experiments were an unsupported activity that
produced an unsupported change to allow
configurable enabling of taking risks with not
updating files that possibly should be updated.
===
Mark Millard
marklmi at yahoo.com
On Apr 22, 2025, at 21:29, Mark Millard wrote:
> On Apr 22, 2025, at 20:27, Mark Millard wrote:
>
>> Sulev-Madis Silber wrote
>> on
>> Date: Wed, 23 Apr 2025 02:04:28 UTC :
>>
>>> yes, 2 * 8g partitions on separate disks, so i have 16g swap
>>>
Sulev-Madis Silber wrote on
Date: Wed, 23 Apr 2025 06:55:06 UTC :
>
> On April 23, 2025 8:34:36 AM GMT+03:00, Mark Millard
> wrote:
> >On Apr 22, 2025, at 21:59, Mark Millard wrote:
> >
> >> Sulev-Madis Silber
> >> wrote on
&
On Apr 22, 2025, at 21:59, Mark Millard wrote:
> Sulev-Madis Silber wrote
> on
> Date: Wed, 23 Apr 2025 04:31:41 UTC :
>
> https://forums.freebsd.org/threads/server-freezes-when-using-git-to-update-ports-tree.88651/
>
> That, in turn mentions:
>
> the remote co
that that is why you lost control but
it may be a possibility.)
(main [FreeBSD 15] no longer does such swapping out of any
process kernel stacks and the 2 settings have been removed.)
===
Mark Millard
marklmi at yahoo.com
On Apr 22, 2025, at 20:27, Mark Millard wrote:
> Sulev-Madis Silber wrote
> on
> Date: Wed, 23 Apr 2025 02:04:28 UTC :
>
>> yes, 2 * 8g partitions on separate disks, so i have 16g swap
>>
>> . . .
>>
>>>>> Van: Sulev-Madi
oss various updates.)
3.6 * 4 GiBytes == 14.4 GiBytes SWAP, as an example.
Then RAM+SWAP == 4.6*RAM, so 18.4 GiBytes or so as a
memory space.
===
Mark Millard
marklmi at yahoo.com
at ithread_loop+0x29c
#17 0x0046a2b0 at fork_exit+0x78
Starting Network: lo0 vtnet0.
. . .
===
Mark Millard
marklmi at yahoo.com
[Note: Your Email handling rejects my Emails, probably
because of Yahoo being involved.]
On Apr 16, 2025, at 23:46, Chris wrote:
> On 2025-04-16 22:40, Mark Millard wrote:
>> Chris wrote on
>> Date: Thu, 17 Apr 2025 05:06:35 UTC :
>>> In an attempt to take advantage
ontrollers/imcsmb/smbus_if.h
(Some of the naming and upper-level path structure is
unusual. See what is normal in your context.)
So it appears that sys/modules/i2c/controllers/imcsmb/smbus_if.h
needs to have been built first and that a -I PATH or such needs
to be used to find the file.
===
Mark Millard
marklmi at yahoo.com
On Apr 9, 2025, at 07:38, Mark Millard wrote:
> On Apr 9, 2025, at 06:41, Mark Millard wrote:
>
>> On Apr 9, 2025, at 05:05, Mark Millard wrote:
>>
>>> On Apr 6, 2025, at 19:29, Mark Millard wrote:
>>>
>>>> [Somewhat hand correcte
have been fixed when I
did a quick test but I reported a different problem.
(Once a "bulk -a" finishes, there is is the time for
distribution of the build to the distribution servers
around the world.)
===
Mark Millard
marklmi at yahoo.com
s the change for avoiding
the extra time.]
On Apr 15, 2025, at 03:17, Mark Millard wrote:
> On Apr 14, 2025, at 16:43, Mark Millard wrote:
>
>> On Apr 11, 2025, at 23:55, Mark Millard wrote:
>>
>>> On Apr 11, 202
On Apr 14, 2025, at 16:43, Mark Millard wrote:
> On Apr 11, 2025, at 23:55, Mark Millard wrote:
>
>> On Apr 11, 2025, at 19:28, Mark Millard wrote:
>>>
>>>> . . .
>>>>
>>> . . .
>>>
>>
>> . . .
>>
>>
On Apr 11, 2025, at 23:55, Mark Millard wrote:
> On Apr 11, 2025, at 19:28, Mark Millard wrote:
>>
>>> . . .
>>>
>> . . .
>>
>
> . . .
>
>>
>>
>> Back to the originally intended content . . .
>>
>>
>>
76 Inspected: 12949 Ignored: 981 Built: 1675 Failed: 229
Skipped: 1299 Fetched: 0 Remaining: 1243
ID TOTAL ORIGIN PKGNAME
PHASE TIME TMPFS CPU% MEM%
[01] 12:02:30 graphics/blender | blender-4.2.0_7
build 11:37:29 5.21 GiB
. . .
===
Mark Millard
marklmi at yahoo.com
On Apr 11, 2025, at 19:28, Mark Millard wrote:
>
>> NOTE on something newly noticed while preparing this
>> (a top post to keep it separate):
>>
> . . .
> NOTE on something newly noticed while preparing this
> (a top post to keep it separate):
>
> In loo
uming
compression technique or some such?
Back to the originally intended content . . .
On Apr 11, 2025, at 14:04, Mark Millard wrote:
>
> On Apr 11, 2025, at 11:39, Mark Millard wrote:
>
>> On Apr 7, 2025, at 08:14, Baptiste Daroussin wrote:
>>
>>> . . .
>
On Apr 11, 2025, at 11:39, Mark Millard wrote:
> On Apr 7, 2025, at 08:14, Baptiste Daroussin wrote:
>
>> . . .
>> the problem we have is the
>> performance changes depending on what is happening in parallel on the
>> machines.
>
> In separate list mess
ples of lib-depends
with non-parallel timings.
> I know what is new and what causes the performance penalty, but not
> which part is causing the super extra penalty on the cluster.
Various examples reproduce the timing issues
outside the cluster and without the parallel
builds.
===
Mark Millard
marklmi at yahoo.com
On Apr 10, 2025, at 15:36, Mark Millard wrote:
> On Apr 10, 2025, at 10:14, Mark Millard wrote:
>
>> On Apr 10, 2025, at 09:25, Mark Millard wrote:
>>
>>> The following data are from later in the builder seqeunce.
>>> Here I'm not looki
On Apr 10, 2025, at 10:14, Mark Millard wrote:
> On Apr 10, 2025, at 09:25, Mark Millard wrote:
>
>> The following data are from later in the builder seqeunce.
>> Here I'm not looking at builder activity with large Elapsed
>> multiplication factors for the
On Apr 7, 2025, at 10:15, Mark Millard wrote:
> On Apr 7, 2025, at 09:44, Mark Millard wrote:
>
>> On Apr 7, 2025, at 08:14, Baptiste Daroussin wrote:
>>
>>> On Mon 07 Apr 08:07, Mark Millard wrote:
>>>> . . .
>>>
>>> Listing like t
On Apr 10, 2025, at 09:25, Mark Millard wrote:
> The following data are from later in the builder seqeunce.
> Here I'm not looking at builder activity with large Elapsed
> multiplication factors for the build. It is more of a random
> sampling showing examples of build-depends,
devel) during my
investigations and ended up using a non-debug kernel. So the
times on the left below are from when it queued 26014 and then
inspected 7111, not from the start of the original "bulk -c -a"
on the Apple silicon M4 MAX under Parallels on macOS.
===
Mark Millard
marklmi at yahoo.com
On Apr 9, 2025, at 06:41, Mark Millard wrote:
> On Apr 9, 2025, at 05:05, Mark Millard wrote:
>
>> On Apr 6, 2025, at 19:29, Mark Millard wrote:
>>
>>> [Somewhat hand corrected "OCR" conversion of some console image content.]
>>>
>>> VN
On Apr 9, 2025, at 05:05, Mark Millard wrote:
> On Apr 6, 2025, at 19:29, Mark Millard wrote:
>
>> [Somewhat hand corrected "OCR" conversion of some console image content.]
>>
>> VNASSERT failed: vp->v_holdcnt > 0 not true at
>> /home/pk
On Apr 6, 2025, at 19:29, Mark Millard wrote:
> [Somewhat hand corrected "OCR" conversion of some console image content.]
>
> VNASSERT failed: vp->v_holdcnt > 0 not true at
> /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref)
> 0xff
s run
debug kernels vs. non-debug ones (15000??).
Any idea how someone with access could find out what
the issue is during official builds?
===
Mark Millard
marklmi at yahoo.com
On Apr 7, 2025, at 13:15, Mark Millard wrote:
> On Apr 7, 2025, at 10:15, Mark Millard wrote:
>
>> On Apr 7, 2025, at 09:44, Mark Millard wrote:
>>
>>> On Apr 7, 2025, at 08:14, Baptiste Daroussin wrote:
>>>
>>>> On Mon 07 Apr 08:07, Mark Mi
On Apr 7, 2025, at 09:44, Mark Millard wrote:
> On Apr 7, 2025, at 08:14, Baptiste Daroussin wrote:
>
>> On Mon 07 Apr 08:07, Mark Millard wrote:
>>> . . .
>>
>> Listing like this is clearly not any useful, the problem we have is the
>> performance ch
On Apr 7, 2025, at 08:14, Baptiste Daroussin wrote:
> On Mon 07 Apr 08:07, Mark Millard wrote:
>> . . .
>
> Listing like this is clearly not any useful, the problem we have is the
> performance changes depending on what is happening in parallel on the
> machines.
I'
On Apr 6, 2025, at 21:11, Gleb Popov <6year...@gmail.com> wrote:
> On Mon, Apr 7, 2025 at 2:44 AM Mark Millard wrote:
>>
>> So: 2 min 31 sec or so difference for overall somewhat over an
>> hour, i.e., 151 sec or so. That is under 1 sec per package
>> built
the rest of the cores are like:
#0 0x008703b0 in ipi_stop (dummy=)
at /home/pkgbuild/worktrees/main/sys/arm64/arm64/mp_machdep.c:342
#1 0xd2e900866b68 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
===
Mark Millard
marklmi at yahoo.com
s, although the factor may be somewhat
smaller than 2 for a non-debug kernel and world being
used.
===
Mark Millard
marklmi at yahoo.com
[Correcting a dumb mistaken reference.]
On Apr 6, 2025, at 16:43, Mark Millard wrote:
> [For the most part the prior history of my notes is not
> important so they are mostly omitted this time.]
>
> It looks like my notes about official bulk package builds
> taking lon
[I thought of another question.]
On Apr 6, 2025, at 10:53, Mark Millard wrote:
> On Apr 6, 2025, at 08:39, Baptiste Daroussin wrote:
>
>> Le 5 avril 2025 06:58:12 GMT+02:00, Mark Millard a écrit
>> :
>>> [This is an update of earlier notes, now that I've n
On Apr 6, 2025, at 08:39, Baptiste Daroussin wrote:
> Le 5 avril 2025 06:58:12 GMT+02:00, Mark Millard a écrit :
>> [This is an update of earlier notes, now that I've noticed what
>> is different for the contexts that not seeing larger time frames
>> in the Mar-29/A
[Attempting to send to the right FreeBSD list this time.]
On Apr 5, 2025, at 09:02, Mark Millard wrote:
Steve Kargl wrote on
Date: Sat, 05 Apr 2025 01:45:53 UTC :
> Anyone using a Samsung T7 external SSD with FreeBSD current?
>
> If I plug the drive into a USB 2.0 po
, and beefy22 had:
(mix of little vs. large time changes)
Host OSVERSION: 1500035
Jail OSVERSION: 1402000
ampere2's main-arm64 has:
(has large time changes)
Host OSVERSION: 1500035
Jail OSVERSION: 1500035
So: The new Host 1500035 use is not the cause. Nor is Jail 1402000 .
===
Mark Millard
On Apr 4, 2025, at 09:04, Mark Millard wrote:
> Longest ever prior bulk build of main-arm64-default (HHH:MM:SS): 171:50:51
> (Host OSVERSION: 1500019)
>
> On going bulk build: Built 11348 Remaining 23676(HHH:MM:SS): 85:57:28
>
> This suggests possibly more lik
Apr 4, 2025, at 20:25, Mark Millard wrote:
> On Apr 4, 2025, at 09:04, Mark Millard wrote:
>
>
>> Longest ever prior bulk build of main-arm64-default (HHH:MM:SS): 171:50:51
>> (Host OSVERSION: 1500019)
>>
>> On going bulk build: Built 11348 Remaining 23676(
s
for:
Host OSVERSION: 1500019
Jail OSVERSION: 1500023
===
Mark Millard
marklmi at yahoo.com
| 25 +++++++++
2 files changed, 32 insertions(+)
. . .
===
Mark Millard
marklmi at yahoo.com
s://cgit.freebsd.org/src/commit/?id=74361d69
shows:
Bad object id: 74361d69
> . . .
===
Mark Millard
marklmi at yahoo.com
On Mar 21, 2025, at 17:43, Konstantin Belousov wrote:
> On Fri, Mar 21, 2025 at 02:30:40PM -0700, Mark Millard wrote:
>> Under:
>>
>> # uname -apKU
>> FreeBSD 7950X3D-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT #4
>> main-n275926-a54a240c1b57-dirty: Thu Mar 13 00:44
lude
#include
. . .
(So "libc, -lc" is still referenced for errno in the man page.)
(errno is just used as an example above.)
===
Mark Millard
marklmi at # man -K "libc, -l" | more
[Just a resend with the current and stable lists included.]
On Mar 19, 2025, at 13:49, Mark Millard wrote:
Bjoern A. Zeeb wrote on
Date: Wed, 19 Mar 2025 17:55:17 UTC :
> Hi,
>
> I pushed an update to the iwlwifi firmware port today[1] and with the last
> release of FreeBSD 13 b
ev/md10 10485760 3448
> /dev/md11 10485760 2924
>
> I checked all swap devices with (example):
>
> # dd if=/dev/md10 of=/dev/null bs=8m
>
> all "devices" are fine.
>
> The box has 16 GByte RAM.
>
> What else could I check/do?
===
Mark Millard
marklmi at yahoo.com
longer had a libz.so.6
reference but instead:
libmd.so.7 => /lib/libmd.so.7
Thus, overall, pkg ended up with both:
libmd.so.6 => not found (0)
libmd.so.7 => /lib/libmd.so.7
or, if BACKUP_LIBRARIES=true was in use for PkgBase, there ended
up being 2 libmd.so bindings around, which of itself is also
problem such that they can not both be in use.
pkg-static, of course, does not have this problem. But some
scripting in use references pkg instead of pkg-static and so is
subject to this kind of breakage when system updates happen.
===
Mark Millard
marklmi at yahoo.com
-9ef38a01aea8-dirty: Tue Feb 18 19:42:12 PST 2025
root@aarch64-main-pbase:/usr/obj/BUILDs/main-CA76-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA76
arm64 aarch64 1500031 1500031
So a personal build, not an official one.
===
Mark Millard
marklmi at yahoo.com
On Feb 19, 2025, at 09:42, Olivier Cochard-Labbé wrote:
> On Wed, Feb 19, 2025 at 6:05 PM Mark Millard wrote:
>>
>> Another example might be if new VM contexts should be added,
>> such as UTM for macOS. What do kenv smbios.system.product ,
>> sysctl kern.vm_guest
On Feb 19, 2025, at 05:24, Jason Bacon wrote:
>
> On 2/18/25 20:13, Mark Millard wrote:
>> Something I possibly should have done --but did not do was to set:
>> kern.hz=100
>
> I stopped doing this under VirtualBox a few years ago, because it was causing
> clock skew
On Feb 18, 2025, at 16:04, Warner Losh wrote:
> On Tue, Feb 18, 2025 at 4:57 PM Mark Millard wrote:
>> On Feb 18, 2025, at 14:01, Warner Losh wrote:
>> >
>> > On Tue, Feb 18, 2025 at 2:56 PM Warner Losh wrote:
>> >>
>> >> On Sat, Feb 15,
On Feb 18, 2025, at 14:01, Warner Losh wrote:
>
> On Tue, Feb 18, 2025 at 2:56 PM Warner Losh wrote:
>>
>> On Sat, Feb 15, 2025 at 10:04 AM Mark Millard wrote:
>>> [This seems likely to not be limited to main [so: 15 as stands].
>>> But I'
nts
/usr/src/sys/arm/conf/GENERIC.hints
/usr/src/sys/riscv/conf/GENERIC.hints
with no aarch64 , armv7 , powerpc64* , powerpcspe , or
riscv64 examples?
===
Mark Millard
marklmi at yahoo.com
[I've now tried my UFS context as well.]
On Feb 12, 2025, at 18:24, Mark Millard wrote:
> I use pkg and poudriere-devel in areas that I've chroot'ed into. (This
> may be unusual and so is noted just in case it turns out to be involved.
> I've been doing that for
usr/obj/DESTDIRs/main-ZNV4-chroot-ports-local/
is a personal world build that was installed there. (The system boots
to an official PkgBase installed world.) So this is not just official
materials involved in the activity, unfortunately.
===
Mark Millard
marklmi at yahoo.com
> kernel module old way, and that whole pipeline is broken if it's loaded at
> boot time or included in the kernel directly. There isn't a nice way to defer
> the firmware load attempt until /after/ rootfs is up.
>
Yep.
===
Mark Millard
marklmi at yahoo.com
On Jan 25, 2025, at 02:24, Mark Millard wrote:
> On Jan 25, 2025, at 02:10, Stefan Esser wrote:
>
>> Am 25.01.25 um 10:54 schrieb Mark Millard:
>>> Unfortunately, for now my reporting is based on my personal build
>>> environment,
>>> not on anoffici
On Jan 25, 2025, at 02:10, Stefan Esser wrote:
> Am 25.01.25 um 10:54 schrieb Mark Millard:
>> Unfortunately, for now my reporting is based on my personal build
>> environment,
>> not on anofficial FreeBSD build.
>> Context doing the building:
>
> Hi Mark,
>
'
.PATH='.
/usr/obj/BUILDs/main-amd64-dbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-DBG'
37.06 real 108.72 user 5.50 sys
make[1]: stopped making "buildkernel" in /usr/main-src
make: stopped making "buildkernel" in /usr/main-src
Script done, output file is
/usr/obj/BUILDs/main-amd64-dbg-clang/sys-typescripts/typescript-make-amd64-dbg-clang-amd64-host-2025-01-25:01:25:05
===
Mark Millard
marklmi at yahoo.com
o (1-deep or whatever), bare if src.txz was
> also unpacked.
> - add a simple script to download as above.
> - people can install whatever git client they want for further work.
>
> git9 doesn't require any kernel code but on freebsd you'd have to
> use plan9port. It is far simpler but has a different interface.
===
Mark Millard
marklmi at yahoo.com
I realise this takes me
> into uncharted waters, as the testing base for these non-default package
> builds is lower than for the default package builds. I am assuming that risk
> on myself by electing to build my own packages via Poudriere.
>
> Straying off the beaten path can sometimes take you to lonely places. :-)
===
Mark Millard
marklmi at yahoo.com
On Jan 17, 2025, at 10:30, Dennis Clarke wrote:
> On 1/15/25 21:20, Mark Millard wrote:
>> Dennis Clarke wrote on
>> Date: Wed, 15 Jan 2025 15:16:58 UTC :
>>> Over the past month or so I see endless fails in builds for the big
>>> three user facing window
webengine-5.15.18p5_1
x11-wm/xfcebeing blocked by vte3-0.70.2_5
x11/xfce4-goodies being blocked by vte3-0.70.2_5
x11/xfce4-terminal being blocked by vte3-0.70.2_5
But I did not see LXDE being blocked.
Note: So far, 134releng-armv7-default had a very early,
global build failure where nothing built.
But I've no clue if any of this matches your example
build failures.
===
Mark Millard
marklmi at yahoo.com
On Dec 15, 2024, at 20:13, Daniel O'Connor wrote:
> Hi Mark,
Hello Daniel,
>> On 16 Dec 2024, at 10:33, Mark Millard wrote:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267028 is for a crash
>> problem
>> someone has been having over more than 2 ye
rnel | grep "\-RELEASE"
@(#)FreeBSD 13.4-RELEASE-p2 3f40d5821 M5P
FreeBSD 13.4-RELEASE-p2 3f40d5821 M5P
13.4-RELEASE-p2
Because it is a rebuild, the kernel ends up with -p2 instead
of the official -p1 ( from -p2 not updating boot/kernel/kernel
in the official distributions ).
===
Ma
On Dec 14, 2024, at 06:21, Ed Maste wrote:
> On Fri, 13 Dec 2024 at 19:42, Mark Millard wrote:
>>
>> I tend to use https://artifact.ci.freebsd.org/snapshot/*/*/*/*/*.txz
>> for crude bisecting without needing to do builds.
>>
>> Are you saying that such will
We can separately consider
> compression on the release media images themselves.
>
> Feedback Requested:
>
> Is there support for this idea? Are there objections to pursuing this?
> Are there other factors I should consider, especially compatibility concerns?
===
Mark Millard
marklmi at yahoo.com
ntext of -current on Raspberry Pi2,-3 and -4
> if it matters.
===
Mark Millard
marklmi at yahoo.com
On Nov 28, 2024, at 19:54, Sean C. Farley wrote:
> On Thu, 28 Nov 2024, Mark Millard wrote:
>
>> . . .
>
>>> System setup:
>>> - FreeBSD 14.2-STABLE
>>
>> The context that I investigated --and what was fixed by a commit only
>>
ompressed, 3.39:1 Ratio
> Swap: 32G Total, 32G Free
>
> THR USERNAME THR PRI NICE SIZE RES STATE C TIME CPU
> COMMAND
> 13 root 40 187 ki31 0B 640K RUN 0 486.9H 792.70%
> [idle]
> 103554 root 1 156 i0 786M 632M CPU37 37 0:44 99.82%
> /usr/bi
> 101148 root 1 156 i0 1317M 822M CPU2 2 2:20 99.82%
> /usr/bi
I do not understand what about the above indicates any
problem. May be more context about the prior activity
that lead to the above needs to be reported?
===
Mark Millard
marklmi at yahoo.com
Sean C. Farley wrote on
Date: Thu, 28 Nov 2024 18:16:16 UTC :
> On Mon, 25 Nov 2024, Mark Millard wrote:
>
> > On Nov 25, 2024, at 18:05, Mark Millard wrote:
> >
> >> Top posting going in a different direction that
> >> established a way to con
1 - 100 of 1135 matches
Mail list logo
