On Dec 15, 2024, at 20:13, Daniel O'Connor <dar...@dons.net.au> wrote:
> Hi Mark,
Hello Daniel,
>> On 16 Dec 2024, at 10:33, Mark Millard <mark...@yahoo.com> wrote:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267028 is for a crash
>> problem
>> someone has been having over more than 2 years. There are boot time crashes
>> involved.
>>
>> It appears that 0xFFFFF80000000007 is showing up in use and stored in data
>> structures as a pointer value in fields/arguments that are pointers, where
>> such
>> a special value would not be expected. Later defrerencing does not go well,
>> at
>> least when the dererefenced data is then in-turn put to use.
>>
>> The small offset from 0xFFFFF80000000000 suggests to me that the special
>> value likely
>> is inappropriately left around and somehow picked up and used.
>> 0xFFFFF80000000000 (or
>> near it) might be odd enough to have only a few known likely possible
>> usages. Such
>> notes in the bugzilla report would be good if such is the case. Thus my
>> question.
>
> That value (0xffffffff80000000) is kernbase (see sysctl kern.base_address).
On an amd64 system that I have access to:
# sysctl -x kern.base_address
kern.base_address: 0xffffffff80000000
But, while looking similar, it is not the same base number:
0xfffff80000000007 (copied and pasted from the kgdb session on the vmcore.*)
0xffffffff80000000
However, kern.base_address might be something that varies from
system to system in some way.
The closest examples I see in sysctl -ax output, start with
0xfffff801. . ., such as shown by:
kern.geom.confdot: digraph geom {
z0xfffff80105633a00 [shape=box,label="ZFS::VDEV\nzfs::vdev\nr#4"];
z0xfffff827c9e7dc80 [label="r1w1e1"];
z0xfffff827c9e7dc80 -> z0xfffff827c9e6d800;
z0xfffff80105633a00 -> z0xfffff827c9e7dc80;
z0xfffff8255c020300 [shape=box,label="SWAP\nswap\nr#4"];
z0xfffff80e3c0bed00 [label="r1w1e0"];
z0xfffff80e3c0bed00 -> z0xfffff80105633e00;
z0xfffff8255c020300 -> z0xfffff80e3c0bed00;
z0xfffff8010553c300 [shape=box,label="PART\nda0\nr#2"];
z0xfffff80105531700 [label="r0w0e0"];
z0xfffff80105531700 -> z0xfffff80105337c00;
z0xfffff8010553c300 -> z0xfffff80105531700;
. . .
z0xfffff80105afa080 [label="r0w0e0"];
z0xfffff80105afa080 -> z0xfffff80105631000;
z0xfffff827c9f56400 -> z0xfffff80105afa080;
z0xfffff8013806b800 [shape=box,label="DEV\nnda0\nr#2"];
z0xfffff827c992f580 [label="r0w0e0"];
z0xfffff827c992f580 -> z0xfffff80105931200;
z0xfffff8013806b800 -> z0xfffff827c992f580;
. . .
kern.geom.confxml: <mesh>
. . .
<class id="0xffffffff82461c78">
<name>ZFS::VDEV</name>
<geom id="0xfffff80105633a00">
<class ref="0xffffffff82461c78"/>
<name>zfs::vdev</name>
<rank>4</rank>
<consumer id="0xfffff827c9e7dc80">
<geom ref="0xfffff80105633a00"/>
<provider ref="0xfffff827c9e6d800"/>
<mode>r1w1e1</mode>
</consumer>
</geom>
</class>
<class id="0xffffffff819375f8">
<name>SWAP</name>
<geom id="0xfffff8255c020300">
<class ref="0xffffffff819375f8"/>
<name>swap</name>
<rank>4</rank>
<consumer id="0xfffff80e3c0bed00">
<geom ref="0xfffff8255c020300"/>
<provider ref="0xfffff80105633e00"/>
<mode>r1w1e0</mode>
</consumer>
</geom>
</class>
. . .
<geom id="0xfffff8013806b800">
<class ref="0xffffffff818b7560"/>
<name>nda0</name>
<rank>2</rank>
<consumer id="0xfffff827c992f580">
<geom ref="0xfffff8013806b800"/>
<provider ref="0xfffff80105931200"/>
<mode>r0w0e0</mode>
</consumer>
</geom>
So: Only seen in such kern.geom.* related sysctl -ax output.
Thanks: I'd not considered looking at sysctl output.
> However it is hard to think of why that value (or a small offset to it) is
> getting put in places it shouldn't be..
Certainly does seem odd.
===
Mark Millard
marklmi at yahoo.com
