FI is in use, then the ESP-ish partition is not from the guest
context but from some place else --unless the man pages are wildly
wrong about what is supported for the gpt*boot 's.
===
Mark Millard
marklmi at yahoo.com
void wrote on
Date: Sat, 07 Sep 2024 17:27:00 UTC :
> On Sat, Sep 07, 2024 at 08:20:07AM -0700, Mark Millard wrote:
>
> >I'm more interested in what is there than just what is not
> >there. May be show something analogous to:
> >
> ># gpart list | grep -E
void wrote on
Date: Sat, 07 Sep 2024 13:19:24 UTC :
> hello again,
>
> On Fri, Sep 06, 2024 at 03:13:59PM -0700, Mark Millard wrote:
> >
> >What shows if you do the likes of (showing an amd64 context example):
> >
> ># ls -lah /boot/efi/efi/*/*
> >-r-xr-xr
/boot/efi/efi/BOOT/bootx64.efi
-rwxr-xr-x 1 root wheel 643K Aug 24 05:32 /boot/efi/efi/FREEBSD/loader.efi
If one is old, then it is probably the one actually being used.
(The name bootx64.efi is amd64 specific: other platforms use
other names.)
In such a case, you might need something like:
# cp -a /boot/loader.efi /boot/efi/efi/BOOT/bootx64.efi
===
Mark Millard
marklmi at yahoo.com
s a duplicate of 16431 and 16431's fix
has been committed to the openzfs master branch:
https://github.com/openzfs/zfs/commit/244ea5c4881f92a9d7c1fb341a49b127fda7539d
===
Mark Millard
marklmi at yahoo.com
itx_metaslab_slog_alloc)!
pid 58 (zpool) is attempting to use unsafe AIO requests - not logging anymore
• [2:13 PM]Flox:
FreeBSD fbsd15.localdomain 15.0-CURRENT FreeBSD 15.0-CURRENT #0
main-aea9dba46b: Sat Aug 10 16:48:02 EDT 2024
mike@fbsd15.localdomain:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64
===
Mark Millard
marklmi at yahoo.com
e done such on amd64
historically, not aarch64, other than possibly one prior
time. On amd64 the drive was internal PCI hardware and
no production of a VHDX file was required. On aarch64
with the USB based drive, direct use of the drive is
blocked, thus the use of a VHDX file produced from th
On Wed, Jul 31, 2024 at 10:48:15AM -0400, John Baldwin wrote:
> On 7/31/24 08:15, void wrote:
> > Hi,
> >
> > Looking at man 4 aesni it appears this pertains to intel and AMD only?
> > is its prescence on arm64 a bug?
> >
> > It seems to be added to /boot/loader.conf by default.
> >
> > The meth
On Jul 27, 2024, at 16:07, Mark Millard wrote:
> The following old files were in the historically incrementally
> updated directory tree but not in the installation to an empty
> directory tree (checked via diff -rq):
>
> /usr/obj/DESTDIRs/main-CA7-poud/rescue/gbde
> /usr/obj
-poud/usr/lib/include/machine/fiq.h
/usr/obj/DESTDIRs/main-CA7-poud/usr/share/man/man4/CAM.4.gz
===
Mark Millard
marklmi at yahoo.com
On Jul 26, 2024, at 21:58, Mark Millard wrote:
> On Jul 26, 2024, at 21:20, Mark Millard wrote:
>
>> The original mount was:
>>
>> mount -onoatime 192.168.1.140:/ /mnt
>>
>> For reference:
>> 192.168.1.140:/ on /usr/obj/DESTDIRs/main-armv7-c
On Jul 26, 2024, at 21:20, Mark Millard wrote:
> The original mount was:
>
> mount -onoatime 192.168.1.140:/ /mnt
>
> For reference:
> 192.168.1.140:/ on /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt
> (nfs, noatime)
>
> gdb reports:
>
>
| grep -v "^l" | sed -E
's@^[^/]*(/.*/pkg/([^-]*-)(.*)(\.snap[^~]*)~[^.]*\.pkg)$@\2\4@' | sort -ru
FreeBSD-.snap20240726112037
After exiting the chroot, the aarch64 environment did the unmount /mnt just
fine.
===
Mark Millard
marklmi at yahoo.com
On Jul 26, 2024, at 16:44, Warner Losh wrote:
> On Fri, Jul 26, 2024, 5:37 PM Mark Millard wrote:
>> On Jul 26, 2024, at 07:56, Philip Paeps wrote:
>>
>> > On 2024-07-26 22:46:57 (+0800), Mark Millard wrote:
>> >> So, it looks like updating the kernel and
On Jul 26, 2024, at 07:56, Philip Paeps wrote:
> On 2024-07-26 22:46:57 (+0800), Mark Millard wrote:
>> So, it looks like updating the kernel and world on ampere2 and
>> enabling builds of main-armv7-default should no longer have
>> main-armv7-default hang-up during grap
On Jul 25, 2024, at 09:48, Mark Millard wrote:
> Michal Meloun has committed a fix in main:
>
> See:
> https://lists.freebsd.org/archives/dev-commits-src-main/2024-July/025399.html
>
> that starts with:
>
> From: Michal Meloun
> Date: Thu, 25 Jul 2024 16:25:09
architecture-specific EABI symbols and
use it on arm for selected EABI functions. These functions can be called
with rtld bind lock write-locked, so they should be resolved in forward.
Reported by: Mark Millard , John F Carr
Reviewed by: kib, imp
MFC after: 1 week
Differential Revision: https
On Jul 22, 2024, at 12:36, Michal Meloun wrote:
> On 22. 7. 2024 19:27, Mark Millard wrote:
>> On Jul 22, 2024, at 09:41, meloun.mic...@gmail.com wrote:
>>
>>
>>> On 22.07.2024 18:26, Mark Millard wrote:
>>>
>>>> On Jul 22, 2024, at 06:40, Mi
On Jul 22, 2024, at 09:41, meloun.mic...@gmail.com wrote:
> On 22.07.2024 18:26, Mark Millard wrote:
>> On Jul 22, 2024, at 06:40, Michal Meloun wrote:
>>> On 22.07.2024 13:46, Mark Millard wrote:
>>>> On Jul 21, 2024, at 22:59, Michal Meloun wrote:
>>>
done on amd64 as well. ("Tegra" models and examples of
ARMv7-A and of ARMv8-A.)
For John Carr, I do not know if amd64 based builds of
the world were systematically in use, never in use,
or some mix in his tests.
===
Mark Millard
marklmi at yahoo.com
On Jul 22, 2024, at 06:40, Michal Meloun wrote:
> On 22.07.2024 13:46, Mark Millard wrote:
>> On Jul 21, 2024, at 22:59, Michal Meloun wrote:
>>> I don't want to hijack the original thread, so I'm replying in a new one.
>>>
>>> My tegra track cur
s that
DEBUG_FLAGS was defined. That in turn likely means that strip is not
being used. In such a case, I expect that the .symtab entry for
_rtld_get_stack_prot (and more) exists for such a context.
===
Mark Millard
marklmi at yahoo.com
On Jul 21, 2024, at 21:08, Mark Millard wrote:
> On Jul 21, 2024, at 20:58, Mark Millard wrote:
>
>> I found a significant difference in my failing vs. working
>> armv7 contexts as installed: Presence vs. Lack of a .symtab
>> entry for the symbol _rtld_get_stack_prot in
On Jul 21, 2024, at 20:58, Mark Millard wrote:
> I found a significant difference in my failing vs. working
> armv7 contexts as installed: Presence vs. Lack of a .symtab
> entry for the symbol _rtld_get_stack_prot in
> /libexec/ld-elf.so.1 .
>
> gdb inspection of operation
.symtab entry problems.
Nor have I figured out why the installed materials are
different for Symbol table '.symtab' . So this is not
yet root-cause information.
===
Mark Millard
marklmi at yahoo.com
[Correction to a rather misleading wording in
my description of the failure sequencing.]
On Jul 21, 2024, at 03:36, Mark Millard wrote:
> On Jul 20, 2024, at 16:42, Mark Millard wrote:
>
>> On Jul 20, 2024, at 01:57, Konstantin Belousov wrote:
>>
>>> [Everythi
On Jul 20, 2024, at 16:42, Mark Millard wrote:
> On Jul 20, 2024, at 01:57, Konstantin Belousov wrote:
>
>> [Everything and everybody in Cc: are stripped for good].
>>
>> On Fri, Jul 19, 2024 at 10:38:36PM -0700, Mark Millard wrote:
>>> 0x201375c0 - 0x201
On Jul 20, 2024, at 01:57, Konstantin Belousov wrote:
> [Everything and everybody in Cc: are stripped for good].
>
> On Fri, Jul 19, 2024 at 10:38:36PM -0700, Mark Millard wrote:
>> 0x201375c0 - 0x2014092c is .bss in /lib/libthr.so.3
>>
>> (g
On Jul 20, 2024, at 01:57, Konstantin Belousov wrote:
> [Everything and everybody in Cc: are stripped for good].
>
> On Fri, Jul 19, 2024 at 10:38:36PM -0700, Mark Millard wrote:
>> 0x201375c0 - 0x2014092c is .bss in /lib/libthr.so.3
>>
>> (g
On Jul 20, 2024, at 01:57, Konstantin Belousov wrote:
> [Everything and everybody in Cc: are stripped for good].
>
> On Fri, Jul 19, 2024 at 10:38:36PM -0700, Mark Millard wrote:
>> 0x201375c0 - 0x2014092c is .bss in /lib/libthr.so.3
>>
>> (g
On Jul 18, 2024, at 01:14, Mark Millard wrote:
> On Jul 16, 2024, at 23:45, Mark Millard wrote:
>
>> On Jul 16, 2024, at 18:41, Mark Millard wrote:
>>
>>> On Jul 16, 2024, at 11:37, Mark Millard wrote:
>>>
>>>> On Jul 16, 2024, at 10:42, M
On Jul 16, 2024, at 23:45, Mark Millard wrote:
> On Jul 16, 2024, at 18:41, Mark Millard wrote:
>
>> On Jul 16, 2024, at 11:37, Mark Millard wrote:
>>
>>> On Jul 16, 2024, at 10:42, Mark Millard wrote:
>>>
>>>> No longer is the problem only o
On Jul 16, 2024, at 18:41, Mark Millard wrote:
> On Jul 16, 2024, at 11:37, Mark Millard wrote:
>
>> On Jul 16, 2024, at 10:42, Mark Millard wrote:
>>
>>> No longer is the problem only observed on ampere2! But this was with
>>> a non-debug, personally
On Jul 16, 2024, at 11:37, Mark Millard wrote:
> On Jul 16, 2024, at 10:42, Mark Millard wrote:
>
>> No longer is the problem only observed on ampere2! But this was with
>> a non-debug, personally built kernel that has some of my now patches.
>> I'll see if I ca
5.0-CURRENT
main-n271137-d68d12481778 GENERIC arm64 aarch64 1500019 1500019
That is from: .snap20240711212638
The armv7 jail directory tree is from: .snap20240711211723
===
Mark Millard
marklmi at yahoo.com
On Jul 16, 2024, at 10:42, Mark Millard wrote:
> No longer is the problem only observed on ampere2! But this was with
> a non-debug, personally built kernel that has some of my now patches.
> I'll see if I can replicate the issue with an official pkgbase debug
> kernel.
It re
12 urdlck IJ0 0:00.02 | | |
`-- /usr/local/bin/dot -c
0 91907 91496 5 68 0 15760 4492 nanslp S 0 1:05.17 | | |--
sh: poudriere[main-armv7-poud-default]: html_json_main (sh)
0 99134 91496 1 40 0 15760 4740 piperd I 0 0:03.22 | | `--
re that lead to 3481 ports not being built, including
graphics/graphviz . But the "bulk -a" completed and 24176 packages
built and were distributed.
graphics/graphviz having BROKEN_armv7 should generaelly build more
packages than that when graphics/giflib builds okay.
===
Mark Millard
marklmi at yahoo.com
On Apr 29, 2024, at 20:16, Mark Millard wrote:
> On Apr 29, 2024, at 20:11, Mark Millard wrote:
>
>> On Apr 29, 2024, at 19:54, Mark Millard wrote:
>>
>>> On Apr 28, 2024, at 18:06, Philip Paeps wrote:
>>>
>>>> On 2024-04-18 23:14:22 (+0800
On May 4, 2024, at 09:59, Mark Millard wrote:
> I recently did some of my rare "poudriere bulk -c -a" high-load-average
> style experiments, here on a 7950X3D (amd64) system and I ended up with
> a couple of stuck builders (one per bulk run of 2 runs). Contexts:
>
>
contexts.
I've no clue how to reduce this to a simple, repeatable context.
===
Mark Millard
marklmi at yahoo.com
On Apr 29, 2024, at 20:11, Mark Millard wrote:
> On Apr 29, 2024, at 19:54, Mark Millard wrote:
>
>> On Apr 28, 2024, at 18:06, Philip Paeps wrote:
>>
>>> On 2024-04-18 23:14:22 (+0800), Mark Millard wrote:
>>>> On Apr 18, 2024, at 08:02, Ma
On Apr 29, 2024, at 19:54, Mark Millard wrote:
> On Apr 28, 2024, at 18:06, Philip Paeps wrote:
>
>> On 2024-04-18 23:14:22 (+0800), Mark Millard wrote:
>>> On Apr 18, 2024, at 08:02, Mark Millard wrote:
>>>> void wrote on
>>>> Date: Thu, 18 Apr 2
On Apr 28, 2024, at 18:06, Philip Paeps wrote:
> On 2024-04-18 23:14:22 (+0800), Mark Millard wrote:
>> 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
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
d from 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?
>
>
f08e41aa and was still broken at 75464941dc .
===
Mark Millard
marklmi at yahoo.com
ne of the turbo 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
On Fri, Mar 29, 2024 at 04:52:55PM +0100, Alexander Leidinger wrote:
> Hi,
>
> sources from 2024-03-11 work. Sources from 2024-03-25 and today don't work
> (see below for the issue). As the monthly stabilisation pass didn't find
> obvious issues, it is something related to my setup:
> - not a gen
e
serial console. (But, thinking about it, I've not used that in some
time.)
===
Mark Millard
marklmi at yahoo.com
via a USB3 adapter for U.2 . The UFS partition
was/is:
537405440 1337979528 da0p9 freebsd-ufs (638G)
===
Mark Millard
marklmi at yahoo.com
e bulk
runs 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
n
has been this 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
nce 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
On Wed, Mar 06, 2024 at 10:51:05AM -0700, John Nielsen wrote:
> Getting a set but not used warning for “td” in sys/kern/kern_condvar.c when
> doing a buildkernel for a config file without “options KTRACE”. I failed to
> copy the full error message/line numbers but I will reproduce this evening if
T spd=SUPER (5.0Gbps)
pwr=SAVE (0mA)
ugen0.1.0: uhub1:
ugen1.1: at usbus1, cfg=0 md=HOST spd=SUPER (5.0Gbps)
pwr=SAVE (0mA)
ugen1.1.0: uhub3:
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 .
sd.compiler.mk /usr/src/share/mk/bsd.endian.mk
> /usr/src/share/mk/bsd.linker.mk /usr/src/share/mk/bsd.test.mk
> /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk
> /usr/src/share/mk/src.init.mk /usr/src/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
Hi folks
Could those folks interested in the math.h library please review
https://reviews.freebsd.org/D44168 ?
It is a fix for 128-bit (IEEE float) tgammal(3), which has been a "stub"
implementation using the 80-bit version to date. The above patch fixes that.
Thanks!
M
--
Mark R V Murray
eek/
for pkgbase (various "aarch64" replacements too)?
===
Mark Millard
marklmi at yahoo.com
blems 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:
>
&g
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
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 program with
> >
> > cc -fsanitize=address
> >
> >
On Wed, Feb 21, 2024 at 09:52:23AM +, hartmut.bra...@dlr.de wrote:
> Hi,
>
> I updated yesterday and now event a minimal program with
>
> cc -fsanitize=address
>
> produces
>
> ld: error: undefined symbol: __elf_aux_vector
> >>> referenced by sanitizer_linux_libcdep.cpp:950
> >>> (/usr/src
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 have b
rupt.
>
> I repeated the "portsnap fetch extract" command,but I always get the same
> error.
>
===
Mark Millard
marklmi at yahoo.com
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
rting
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 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
> and I've had two nvme-triggered panics in the last day.
>
> nvme is be
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 Millard
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:
>>
1 efi (50M)
135168 451809280 da0p2 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 ?
&g
-dresden.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 Mari
image from the parts. The "Pulling 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
On Fri, Feb 09, 2024 at 10:11:14PM +, Matthew L. Dailey wrote:
> On 2/9/24 4:18 PM, Mark Johnston wrote:
> > [You don't often get email from ma...@freebsd.org. Learn why this is
> > important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > On Fri,
On Fri, Feb 09, 2024 at 06:23:08PM +, Matthew L. Dailey wrote:
> I had my first kernel panic with a KASAN kernel after only 01:27. This
> first panic was a "double fault," which isn't anything we've seen
> previously - usually we've seen trap 9 or trap 12, but sometimes others.
> Based on th
On Thu, Feb 08, 2024 at 03:34:52PM +, Matthew L. Dailey wrote:
> Good morning all,
>
> Per Rick Macklem's suggestion, I'm posting this query here in the hopes
> that other may have ideas.
>
> We did do some minimal testing with ufs around this problem back in
> August, but hadn't narrowed t
On Jan 29, 2024, at 02:27, Olivier Certner wrote:
> Hi Mark,
Hello.
Let me start out by indicating that some bike shed sessions
are useful overall, even if not contributing to crucial
matters. I do not see withdrawing from continued participation
with new material as disqualifying of any
ignment(dmat) being < PAGE_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
On Jan 14, 2024, at 15:15, Olivier Certner wrote:
> Hi Mark,
>
>> I seriously care about having a lack of access times.
>
> Then, I think elaborating on your use cases would be valuable to the
> discussion, if by chance you want to and can share about them.
I'm con
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
On Jan 14, 2024, at 08:39, Olivier Certner wrote:
> Hi Mark,
>
>> I never use atime, always noatime, for UFS. That said, I'd never propose
>> changing the long standing defaults for commands and calls.
>
> With this mail, you're giving more detailed obj
ate more parallel activity below each 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 c
such defaults
is not worth the consequences of making a bunch of new distinctions
in a long standing subject area.
===
Mark Millard
marklmi at yahoo.com
1 - 100 of 3007 matches
Mail list logo
