On Apr 26, 2024, at 18:55, Philip Paeps wrote:
> On 2024-04-18 23:02:30 (+0800), Mark Millard wrote:
>> void wrote on
>> Date: Thu, 18 Apr 2024 14:08:36 UTC :
>>
>>> Not sure where to post this..
>>>
>>> The last bulk build for arm64 appears
On Apr 19, 2024, at 07:16, Philip Paeps wrote:
> On 2024-04-18 23:02:30 (+0800), Mark Millard wrote:
>
>> void wrote on
>> Date: Thu, 18 Apr 2024 14:08:36 UTC :
>>
>>> Not sure where to post this..
>>>
>>> The last bulk build for arm64 appea
m the same
build.)
Note, I noticed because of a message from an etcupdate run: I do not use the
file for anything.
===
Mark Millard
marklmi at yahoo.com
64/tmp/usr/lib/clang/17/lib/freebsd/libclang_rt.asan_static-aarch64.a
-r--r--r-- 1 root wheel - 998 Mar 2 19:39:47 2024
/usr/obj/BUILDs/main-CA76-nodbg-clang/usr/main-src/arm64.aarch64/tmp/usr/lib/clang/17/lib/freebsd/libclang_rt.fuzzer_interceptors-aarch64.a
===
Mark Millard
marklmi at yahoo.com
On Apr 18, 2024, at 08:02, Mark Millard wrote:
> void wrote on
> Date: Thu, 18 Apr 2024 14:08:36 UTC :
>
>> Not sure where to post this..
>>
>> The last bulk build for arm64 appears to have happened around
>> mid-March on ampere2. Is it broken?
&
t 75464941dc .
===
Mark Millard
marklmi at yahoo.com
settings, the
more modern RPI firmware is varying the speed of the clock in the early
boot time frame and FreeBSD is working in a way that requires more
uniformity for such. (May be delays based on just loop counting?)
===
Mark Millard
marklmi at yahoo.com
hinking about it, I've not used that in some
time.)
===
Mark Millard
marklmi at yahoo.com
apter for U.2 . The UFS partition
was/is:
537405440 1337979528 da0p9 freebsd-ufs (638G)
===
Mark Millard
marklmi at yahoo.com
s out of packages it can build, absent building boost-libs .
Side note:
As far as I can tell, how to identify a context that allows
identification of what commit vintage a PkgBase world is based on
is unspecified so far. For a PkgBase kernel uname -apKU may well
report the kernel-commit identifica
way.
Is there a way for it to automatically use the likes of the
nfsd.ko from the same directory as the kernel in all cases,
where I pick the default kernel place via loader.conf ? Do
I need to do more manual steps in the loader, not just use
the menu selections to override the defaults for this
sufficiently to have the likes of the matching nfsd.ko load?
===
Mark Millard
marklmi at yahoo.com
ce work that is going on where the caching was having
negative consequences when nullfs was also in use.)
kib's wording when I asked about the display-of-mode-status
issue was:
QUOTE
Mount uses getfsstat(2) which has no knowledge of nmount(2).
END QUOTE
===
Mark Millard
marklmi at yahoo.com
hub3:
ugen2.1: at usbus2, cfg=0 md=HOST spd=SUPER (5.0Gbps)
pwr=SAVE (0mA)
ugen2.1.0: uhub4:
ugen3.1: at usbus3, cfg=0 md=HOST spd=SUPER (5.0Gbps)
pwr=SAVE (0mA)
ugen3.1.0: uhub2:
ugen3.2: at usbus3, cfg=0 md=HOST spd=SUPER
(5.0Gbps) pwr=ON (72mA)
ugen3.2.0: ure0:
. .
ugen1.2: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps)
pwr=ON (500mA)
ugen1.2.0: ubt0:
. .
(I omitted the CORSAIR related lines.)
>> USB ID 0x17ef/0x7205
>> rgephy1: PHY 0 on miibus1
>> I tried using the cdce driver, it gives me < 100Mb/s, while the ure driver
>> gets > 500Mb/s
>
> Right, I saw about the same.
===
Mark Millard
marklmi at yahoo.com
On Mar 3, 2024, at 23:25, Jakob Alvermark wrote:
> On 12/4/23 09:16, Mark Millard wrote:
>> The following sort of thing is happening a lot:
>>
>> Ryzen 9 7950X3D using a USB Ethernet dongle that I've historically
>> used on occasion, sometimes for long periods .
rc/tests/sys/capsicum/../Makefile.inc
> /usr/src/tests/Makefile.inc0 /usr/src/share/mk/googletest.test.mk
> /usr/src/share/mk/googletest.test.inc.mk /usr/src/share/mk/plain.test.mk
> /usr/src/share/mk/tap.test.mk
> make[2]: stopped in /usr/src
===
Mark Millard
marklmi at yahoo.com
/stabweek/
for pkgbase (various "aarch64" replacements too)?
===
Mark Millard
marklmi at yahoo.com
similar to
the __elf_aux_vector move to libsys --that might also lead
to needing -lsys (for things as the are now)?
For reference:
https://lists.freebsd.org/archives/dev-commits-src-main/2024-February/022025.html
===
Mark Millard
marklmi at yahoo.com
[Brooks' activity related to commit 99ea67573164637d633e8051eb0a5d52f1f9488e
looks likely for what changed the status: "lib{c,sys}: move auxargs more
firmly into libsys".]
On Feb 21, 2024, at 09:02, Mark Millard wrote:
> On Feb 21, 2024, at 08:38, Mark Millard wrote:
>
>>
On Feb 21, 2024, at 08:38, Mark Millard wrote:
> Mark Johnston wrote on
> Date: Wed, 21 Feb 2024 13:33:43 UTC :
>
>> On Wed, Feb 21, 2024 at 09:52:23AM +, hartmut.bra...@dlr.de wrote:
>>> Hi,
>>>
>>> I updated yesterday and now event a minimal p
>> (/home/bapt/worktrees/main/contrib/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp:950)
>>> sanitizer_linux_libcdep.o:(__sanitizer::ReExec()) in archive
>>> /usr/lib/clang/17/lib/freebsd/libclang_rt.asan-aarch64.a
cc: error: linker command failed with exit code 1 (use -v to see invocation)
===
Mark Millard
marklmi at yahoo.com
On Feb 14, 2024, at 18:19, Mark Millard wrote:
> Your changes have the RPi4B that previously got the
> panic to boot all the way instead. Details:
>
> I have updated my pkg base environment to have the
> downloaded kernels (and kernel source) with your
> changes and hav
>
> I repeated the "portsnap fetch extract" command,but I always get the same
> error.
>
===
Mark Millard
marklmi at yahoo.com
For reference:
# uname -apKU
FreeBSD aarch64-main-pkgs 15.0-CURRENT FreeBSD 15.0-CURRENT
main-n268300-d79b6b8ec267 GENERIC-NODEBUG arm64 aarch64 1500014 1500012
Thanks for the fix.
Now I'll update the rest of pkg base materials.
===
Mark Millard
marklmi at yahoo.com
[Added at bottom: EDK2 notes referencing the non-ECAM compliant
PCie in the BCM2711.]
On Feb 14, 2024, at 10:23, John Baldwin wrote:
> On 2/14/24 10:16 AM, Mark Millard wrote:
>> Top posting a related but separate item:
>> I looked up some old (2022-Dec-17) lspci -v output from
eporting
Kernel driver in use: xhci_hcd
"Memory at 6 (64-bit, non-prefetchable)":
Violation of a PCIe standard?
On Feb 14, 2024, at 09:57, Mark Millard wrote:
> On Feb 14, 2024, at 08:08, John Baldwin wrote:
>
>> On 2/12/24 5:57 PM, Mark Millard wrote
On Feb 14, 2024, at 08:08, John Baldwin wrote:
> On 2/12/24 5:57 PM, Mark Millard wrote:
>> On Feb 12, 2024, at 16:36, Mark Millard wrote:
>>> On Feb 12, 2024, at 16:10, Mark Millard wrote:
>>>
>>>> On Feb 12, 2024, at 12:00, Mark Millard wrote:
>&g
On Feb 12, 2024, at 16:36, Mark Millard wrote:
> On Feb 12, 2024, at 16:10, Mark Millard wrote:
>
>> On Feb 12, 2024, at 12:00, Mark Millard wrote:
>>
>>> [Gack: I was looking at the wrong vintage of source code, predating
>>> your changes: wrong system
On Feb 12, 2024, at 16:10, Mark Millard wrote:
> On Feb 12, 2024, at 12:00, Mark Millard wrote:
>
>> [Gack: I was looking at the wrong vintage of source code, predating
>> your changes: wrong system used.]
>>
>>
>> On Feb 12, 2024, at 10:41, Mark Mil
On Feb 12, 2024, at 12:00, Mark Millard wrote:
> [Gack: I was looking at the wrong vintage of source code, predating
> your changes: wrong system used.]
>
>
> On Feb 12, 2024, at 10:41, Mark Millard wrote:
>
>> On Feb 12, 2024, at 09:32, John Baldwin wrote:
>>
freebsd-ufs (215G)
45198 16916480 da0p3 freebsd-swap (8.1G)
468860928 1160 - free - (580K)
So, the panic may be before dumping is set up, at
least for USB3 media.
===
Mark Millard
marklmi at yahoo.com
[Gack: I was looking at the wrong vintage of source code, predating
your changes: wrong system used.]
On Feb 12, 2024, at 10:41, Mark Millard wrote:
> On Feb 12, 2024, at 09:32, John Baldwin wrote:
>
>> On 2/9/24 8:13 PM, Mark Millard wrote:
>>> Summary:
>>&g
On Feb 12, 2024, at 09:32, John Baldwin wrote:
> On 2/9/24 8:13 PM, Mark Millard wrote:
>> Summary:
>> pcib0: mem 0x7d50-0x7d50930f
>> irq 80,81 on simplebus2
>> pcib0: parsing FDT for ECAM0:
>> pcib0: PCI addr: 0xc000, CPU ad
On Feb 11, 2024, at 12:00, Mark Millard wrote:
> [Only replying to what I've subscribed to --and I dropped
> Warner as well.]
>
> On Feb 11, 2024, at 11:43, Mario Marietto wrote:
>
>> ok. But what does this mean ? That I can use whatever Linux distro I want ?
>>
den.de/download/snapshots/pre-built-images/arm64/bootstrap_vm-basic_rpi4.elf
http://os.inf.tu-dresden.de/download/snapshots/pre-built-images/arm64/bootstrap_vm-basic_rpi4.uimage
> On Sun, Feb 11, 2024 at 7:59 PM Mark Millard wrote:
>
>
> On Feb 11, 2024, at 05:44, Mario Marietto
it together" section is about combining the
parts (including the microkernel and the user-level software) to make the
overall image that does not include Linux or FreeBSD code.
===
Mark Millard
marklmi at yahoo.com
On Feb 9, 2024, at 23:44, Bakul Shah wrote:
> $ git bisect good
> b377ff8110e3489eb6e6b920b51a2384dfc4eb0b is the first bad commit
>
>> On Feb 9, 2024, at 8:13 PM, Mark Millard wrote:
>>
>> Summary:
>>
>> pcib0: mem 0x7d50-0x7d50930f
>>
h+0x3fc
device_probe_and_attach() at device_probe_and_attach+0x80
bus_generic_new_pass() at bus_generic_new_pass+0x100
bus_generic_new_pass() at bus_generic_new_pass+0xb0
bus_generic_new_pass() at bus_generic_new_pass+0xb0
bus_generic_new_pass() at bus_generic_new_pass+0xb0
bus_set_pass() at bus_set_pass+0x50
mi_startup() at mi_startup+0x1e0
virtdone() at virtdone+0x68
KDB: enter: panic
[ thread pid 0 tid 10 ]
Stopped at kdb_enter+0x4c: str xzr, [x19, #1280]
db>
===
Mark Millard
marklmi at yahoo.com
duces the need for tweaks, which
> serves both beginners but *also* seasoned administrators. This is in
> isolation a very small step in this direction, but there have been others and
> more will come. Collectively, they can build up to significant additional
> value for the project.
===
Mark Millard
marklmi at yahoo.com
_SIZE, tiny even.
But the bz->alignment was forced to a PAGE_SIZE
as a minimum value in the first call. The comparison
is not based on a common value-standard for the 2
sides.
===
Mark Millard
marklmi at yahoo.com
On Jan 15, 2024, at 00:07, Lexi Winter wrote:
> Mark Millard:
>> You seem to be under the impression that "Inact" means "page is not
>> dirty" and so can be freed without being written out to the swap
>> space.
>
> indeed, i was, because this is ho
On Jan 15, 2024, at 01:27, Tomoaki AOKI wrote:
> On Sun, 14 Jan 2024 16:13:06 -0800
> Mark Millard wrote:
>
>> On Jan 14, 2024, at 14:27, Tomoaki AOKI wrote:
>>
>>> On Sun, 14 Jan 2024 10:53:34 -0800
>>> Mark Millard wrote:
>>>
>&g
h things and changing their
behavior without requiring changing the notation already in
place in various files.
(I've tried to word the above without making new points,
avoiding contributing more to the bike shed material.)
END QUOTE
===
Mark Millard
marklmi at yahoo.com
On Jan 14, 2024, at 14:27, Tomoaki AOKI wrote:
> On Sun, 14 Jan 2024 10:53:34 -0800
> Mark Millard wrote:
>
>> On Jan 14, 2024, at 08:39, Olivier Certner wrote:
>>
>>> Hi Mark,
>>>
>>>> I never use atime, always noatime, for UFS. That said
social/political aspects.)
And, hopefully, this is my last contribution to this particular
bike shed.
===
Mark Millard
marklmi at yahoo.com
ch make-job, outside
make's control. I've seen an 8 hardware thread system with
the maximum observed for each of the 3 load average time
frames being the likes of: 43.21, 40.44, 33.70 (from
different times during the bulk run, not simulateously).
===
Mark Millard
marklmi at yahoo.com
On Jan 12, 2024, at 09:57, Doug Rabson wrote:
> On Sat, 30 Sept 2023 at 08:47, Mark Millard wrote:
> ram_attach is based on regions_to_avail but that is a problem for
> its later bus_alloc_resource use --and that can lead to:
>
> panic("ram_attach: resource %d fa
Rodney W. Grimes wrote on
Date: Thu, 11 Jan 2024 17:15:19 UTC :
> > Am 2024-01-10 22:49, schrieb Mark Millard:
> >
> > > I never use atime, always noatime, for UFS. That said, I'd never
> > > propose
> > > changing the long standing defaults for comman
f making a bunch of new distinctions
in a long standing subject area.
===
Mark Millard
marklmi at yahoo.com
> Streamlining the process for ENs (automating them so that there’s a simple
> flow from review request for a commit on a stable branch to generating the
> binaries and sending out the announcement) would help a lot and would almost
> certainly make Colin happier about his workload.
===
Mark Millard
marklmi at yahoo.com
such official builds if they existed. I like to avoid
submitting notes based on my personal builds if official
builds show the behavior of interest. Setting up such an
amd64 install the normal way is just busy work for this
purpose. I do the same sort of thing for aarch64 and armv7,
testing if I can avoid my personal builds that I normally
use, including with the HoneyComb and MACCHIATObin Double
Shot that are not small arm boards.)
===
Mark Millard
marklmi at yahoo.com
On Dec 22, 2023, at 01:36, Toomas Soome wrote:
>
>
>
>> On 22. Dec 2023, at 11:09, Mark Millard wrote:
>>
>> Tomoaki AOKI wrote on
>> Date: Thu, 21 Dec 2023 23:21:00 UTC :
>>
>>> On Thu, 21 Dec 2023 14:22:14 +0100
>>> Dimitry Andric
e earlier point about aarch64 and armv7 not using
/boot/* files while loading the FreeBSD loader: the
FreeBSD loader variant used is the first stage able to
look inside UFS or ZFS file systems. Loading and
starting the FreeBSD loader happens before that stage
in those types of contexts.
> . . .
On Dec 7, 2023, at 01:19, Dimitry Andric wrote:
> On 7 Dec 2023, at 05:31, Mark Millard wrote:
>>
>> man arch reports:
>>
>> QUOTE
>>Some machines support more than one FreeBSD ABI. Typically these are
>>64-bit machines, where
ernatives did not work. I see that I
forgot various quote (") symbols.
This note was prompted by:
https://lists.freebsd.org/archives/freebsd-hackers/2023-December/002728.html
that mentions "the list of valid MACHINE_ARCH" that reminded me
of this old issue.
===
Mark Millard
marklmi at yahoo.com
30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP
. . . (lots more) . . .
Other FreeBSD system on the Ethernet are not getting such but none
of them are currently using such a dongle.
Note: The ASUS X670-P WiFi board's built in Ethernet is not
supported.
===
Mark Millard
marklmi
On Nov 23, 2023, at 13:28, Mark Millard wrote:
> On Nov 21, 2023, at 21:43, Mark Millard wrote:
>
>> While my kernel/world build procedures build both DBG and NODBG
>> kernels and worlds, I normally run the NODBG kernel and world,
>> using DBG only when I need to f
On Nov 21, 2023, at 21:43, Mark Millard wrote:
> While my kernel/world build procedures build both DBG and NODBG
> kernels and worlds, I normally run the NODBG kernel and world,
> using DBG only when I need to for problem investigation.
>
> I recently had reason to use the DBG k
arent --count for merge-base)
===
Mark Millard
marklmi at yahoo.com
o the promoted clone, so enough space must be
available to accommodate these snapshots. No new space is consumed by
this operation, but the space accounting is adjusted. The promoted clone
must not have any conflicting snapshot names of its own. The zfs rename
subcommand can be used to rename any conflicting snapshots.
===
Mark Millard
marklmi at yahoo.com
ulk -a compared to the hardware thread count. Largest
swap space use observed was 123513 MiBytes, observed via a
hacked top that tracks some "Maximum Observed" figures for
some of top's monitoring data. For reference:
245564Mi MaxObs(Act+Wir+Lndry+SwapUsed)
Note: max(A+B) <= max(A) + max(B)
===
Mark Millard
marklmi at yahoo.com
0:00:30 1.28 GiB[14]
00:00:32 math/giacxcas | giacxcas-1.9.0.55
starting 00:00:32 1.28 GiB=>> Logs:
/usr/local/poudriere/data/logs/bulk/main-amd64-bulk_a-default/2023-11-02_21h44m56s
===
Mark Millard
marklmi at yahoo.com
Depending on the results, my next question might have been: "What
happened for block cloning being disabled now to make it worse than
before block cloning existed?"
> He suggested a workaround of 'sysctl
> vfs.zfs.dmu_offset_next_sync=0' but we should probably sort this out
> for 14.0-RELEASE.
===
Mark Millard
marklmi at yahoo.com
GiByte RPI4B's. (The smaller capacity
systems [all aarch64/armv7] basically just boot UFS media --that I
normally produce from the HoneyCmb's bectl based boot context.)
If such ends up as unsupportable, it will effectively eliminate my
reason for using bectl (and, so, zfs): the sharing is important to
my use.
===
Mark Millard
marklmi at yahoo.com
Graham Perrin wrote on
Date: Mon, 02 Oct 2023 03:57:59 UTC :
> On 01/10/2023 23:41, Mark Millard wrote:
> > That indicates that __FreeBSD_version was 150 when the uname that
> > was run was built but the running kernel was built when
> > __FreeBSD_version was 15000
files.)
There may be more alternatives that I've not covered.
===
Mark Millard
marklmi at yahoo.com
rently RPi*
specific for possibly ending up with an analogous panic. So
I expect the example is sufficient context to identify a
problem is present, despite EDK2 use not being normal for
RPi4B's and the like as far as FreeBSD is concerned.
===
Mark Millard
marklmi at yahoo.com
5:06:44 db> Build timed out (after 1,200 minutes). Marking the build as failed.
. . .
===
Mark Millard
marklmi at yahoo.com
See: https://lists.freebsd.org/archives/freebsd-arm/2023-September/003071.html
for details. (It is not my activity.)
===
Mark Millard
marklmi at yahoo.com
such, if any, not just system
files), thus avoiding references to the old files.
(There also could be the issue of non-debug build vs. debug-build
matching.)
I'm left with using, say, a 13.0-RELEASE to build an old 14.0-CURRENT
vintage similar to your starting point and then copying the file(s)
needed from that 14.0-CURRENT build.
Hopefully there is a nicer to deal with answer.
===
Mark Millard
marklmi at yahoo.com
On Sep 18, 2023, at 17:05, Alexander Motin wrote:
> On 18.09.2023 19:21, Mark Millard wrote:
>> On Sep 18, 2023, at 15:51, Mark Millard wrote:
>>> Alexander Motin wrote on
>>> Date: Mon, 18 Sep 2023 13:26:56 UTC :
>>>> block_cloning feature
On Sep 18, 2023, at 15:51, Mark Millard wrote:
> Alexander Motin wrote on
> Date: Mon, 18 Sep 2023 13:26:56 UTC :
>
>> block_cloning feature is marked as READONLY_COMPAT. It should not
>> require any special handling from the boot code.
>
> From stand/lib
t;nv_size, nvp_name->nv_data);
rc = EIO;
}
nvp = (nvp_header_t *)((uint8_t *)nvp + nvp->encoded_size);
}
nvlist_destroy(features);
return (rc);
}
I do not know if vfs.zfs.bclone_enabled=0 leads the loader
to see vs. not-see a "com.fudosecurity:block_cloning".
===
Mark Millard
marklmi at yahoo.com
t:
# find /boot/efi/EFI/ -print
/boot/efi/EFI/
/boot/efi/EFI/FREEBSD
/boot/efi/EFI/FREEBSD/loader.efi
/boot/efi/EFI/BOOT
/boot/efi/EFI/BOOT/bootx64.efi
There may well be only:
EFI/BOOT/bootx64.efi
for all I know.
(I set things up to have the EFI capitalization
so that referencing efi/ vs. EFI/
x60
#5 0x0054c318 at dounmount+0x714
#6 0x0054bb94 at kern_unmount+0x298
#7 0x007fe6ac at do_el0_sync+0x520
#8 0x007da110 at handle_el0_sync+0x44
It happens to be on aarch64, in case that matters for some
odd reason.
===
Mark Millard
marklmi at yahoo.com
To: Mark Millard
Cc: Current FreeBSD
>
> Hi Mark,
>
> On 14 Sep 2023, at 7:37, Mark Millard wrote:
>> This change leads the port net/py-libdnet to be broken:
>>
>> --- fw-pf.lo ---
>> fw-pf.c:212:22: error: use of undeclared identifier 'DIOCGETRULE'
>
@py39 | py39-libdnet-1.13_4 failed
net/scapy is used by parts of the kyua testsuite (when installed,
anyway). So the kyua testsuite is now has damaged functionality
on main [so: 15].
===
Mark Millard
marklmi at yahoo.com
reported vs. what code
involved using the value.
I will say that I've not managed to produce the crash with
14.0-BETA1. But I have produced the crash in my personal
non-debug kernel builds and with the main snapshots dd'd to
media and booted and used.
===
Mark Millard
marklmi at yahoo.com
On Sep 11, 2023, at 19:40, Mark Millard wrote:
> On Sep 11, 2023, at 01:13, Mark Millard wrote:
>
>> It will be some time before I can try this with
>> an official snapshot instead of a personal build.
>> The build is based on b6ce41118bb1 :
>>
>> # uname -
On Sep 11, 2023, at 01:13, Mark Millard wrote:
> It will be some time before I can try this with
> an official snapshot instead of a personal build.
> The build is based on b6ce41118bb1 :
>
> # uname -apKU
> FreeBSD CA78C-WDK23-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT aarch64 1
On Sep 11, 2023, at 00:03, Mark Millard wrote:
> On Sep 10, 2023, at 23:57, Dag-Erling Smørgrav wrote:
>
>> Mark Millard writes:
>>> I'm not aware of there being other documentation for what
>>> is appropriate for setting up such for kyua runs.
>>
>
md4.dat -u md4
mdconfig -f /var/tmp/for-md5.dat -u md5
I also did a:
# kldload linux64
before doing:
# /usr/bin/kyua test -k /usr/tests/Kyuafile
(Not true of linux64.ko in 14.0-CURRENT days.)
===
Mark Millard
marklmi at yahoo.com
On Sep 10, 2023, at 23:57, Dag-Erling Smørgrav wrote:
> Mark Millard writes:
>> I'm not aware of there being other documentation for what
>> is appropriate for setting up such for kyua runs.
>
> https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/build-test_
On Sep 10, 2023, at 11:21, Warner Losh wrote:
> On Sun, Sep 10, 2023, 11:10 AM Mark Millard wrote:
>> On Sep 10, 2023, at 00:31, Mark Millard wrote:
>>
>> > kyua tests that use the:
>> >
>> > /usr/tests/sys/cddl/zfs/bin/mkfile
>> >
>>
On Sep 10, 2023, at 00:31, Mark Millard wrote:
> kyua tests that use the:
>
> /usr/tests/sys/cddl/zfs/bin/mkfile
>
> program like so (for example):
>
> mkfile 500M /testpool.1861/bigfile.0
>
> (which should be valid) end up with mkfile
> instead reporting
On Sep 10, 2023, at 05:58, Mike Karels wrote:
> On 10 Sep 2023, at 2:31, Mark Millard wrote:
>
>> kyua tests that use the:
>>
>> /usr/tests/sys/cddl/zfs/bin/mkfile
>>
>> program like so (for example):
>>
>> mkfile 500M /testpool.1861
arch64, powerpc64,
powerpc64le, armv7, powerpc, and powerpcspe. That, in
turn, suggests that kyua test inspection for the likes
of aarch64 is not historically a part of the release
process for openzfs or for operating systems that include
openzfs.
===
Mark Millard
marklmi at yahoo.com
On Sep 8, 2023, at 21:54, Mark Millard wrote:
> On Sep 8, 2023, at 18:19, Mark Millard wrote:
>
>> On Sep 8, 2023, at 17:03, Mark Millard wrote:
>>
>>> On Sep 8, 2023, at 15:30, Martin Matuska wrote:
>>>
>>>> I can confirm that the pat
On Sep 8, 2023, at 18:19, Mark Millard wrote:
> On Sep 8, 2023, at 17:03, Mark Millard wrote:
>
>> On Sep 8, 2023, at 15:30, Martin Matuska wrote:
>>
>>> I can confirm that the patch fixes the panic caused by the provided script
>>> on my test systems.
&
On Sep 8, 2023, at 17:03, Mark Millard wrote:
> On Sep 8, 2023, at 15:30, Martin Matuska wrote:
>
>> I can confirm that the patch fixes the panic caused by the provided script
>> on my test systems.
>> Mark, would it be possible to try poudriere on your system w
Tobuild: 33800 Time: 00:30:41
So 414 and and still building.
More later. (It may be a while.)
===
Mark Millard
marklmi at yahoo.com
test.nl conftest.out
. . . (history removed) . . .
# uname -apKU
FreeBSD amd64-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT amd64 150 #0
main-n265205-03a7c36ddbc0: Thu Sep 7 03:10:34 UTC 2023
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
amd64 150 150
In my test environment with yesterday's snapshot kernel
in use and with vfs.zfs.bclone_enabled=1 :
# ~/bclone_panic.sh
count: 1
count: 2
count: 3
count: 4
count: 5
count: 6
count: 7
count: 8
then panic: no 9.
===
Mark Millard
marklmi at yahoo.com
[Today's main-snapshot kernel panics as well.]
On Sep 7, 2023, at 16:32, Mark Millard wrote:
> On Sep 7, 2023, at 13:07, Alexander Motin wrote:
>
>> Thanks, Mark.
>>
>> On 07.09.2023 15:40, Mark Millard wrote:
>>> On Sep 7, 2023, at 11:48, Glen Barber wrote
On Sep 7, 2023, at 13:07, Alexander Motin wrote:
> Thanks, Mark.
>
> On 07.09.2023 15:40, Mark Millard wrote:
>> On Sep 7, 2023, at 11:48, Glen Barber wrote:
>>> On Thu, Sep 07, 2023 at 11:17:22AM -0700, Mark Millard wrote:
>>>> When I next have time, s
On Sep 7, 2023, at 11:48, Glen Barber wrote:
> On Thu, Sep 07, 2023 at 11:17:22AM -0700, Mark Millard wrote:
>> When I next have time, should I retry based on a more recent
>> vintage of main that includes 969071be938c ?
>>
>
> Yes, please, if you can.
As stan
[Drat, the request to rerun my tests did not not mention
the more recent change:
vfs: copy_file_range() between multiple mountpoints of the same fs type
and I'd not noticed on my own and ran the test without updating.]
On Sep 7, 2023, at 11:02, Mark Millard wrote:
> I was requested to
3 - stable/14 - zfs: merge openzfs/zfs@32949f256
(zfs-2.2-release) into stable/14
that has required fixes for other issues.
===
Mark Millard
marklmi at yahoo.com
fs.per_txg_dirty_frees_percent=5 allowed more overall
progress on that aarch64 system. The big cleanout of all the
builders at the end is not the only consideration in setting
vfs.zfs.per_txg_dirty_frees_percent (for at least some systems).
===
Mark Millard
marklmi at yahoo.com
On Sep 5, 2023, at 08:58, Cy Schubert wrote:
> In message <20230830204406.24fd...@slippy.cwsent.com>, Cy Schubert writes:
>> In message <20230830184426.gm1...@freebsd.org>, Glen Barber writes:
>>>
>>>
>>> On Mon, Aug 28, 2023 at 06:06:09PM -
On Sep 5, 2023, at 00:00, Mark Millard wrote:
> On Sep 4, 2023, at 22:06, Mark Millard wrote:
>
>> . . .
>
> So I tried 30 for per_txg_dirty_frees_percent for 2 contexts:
> autotrim on
> vs.
> autotrim off
>
> where there was 100 GiByte+ to delete after a po
On Sep 4, 2023, at 22:06, Mark Millard wrote:
> On Sep 4, 2023, at 18:39, Mark Millard wrote:
>
>> On Sep 4, 2023, at 10:05, Alexander Motin wrote:
>>
>>> On 04.09.2023 11:45, Mark Millard wrote:
>>>> On Sep 4, 2023, at 06:09, Alexander Motin w
1 - 100 of 1284 matches
Mail list logo
