> On 16 Dec 2024, at 16:18, Mark Millard <mark...@yahoo.com> wrote:
>>> 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
Oops, my mistake!
> However, kern.base_address might be something that varies from
> system to system in some way.
Your value is the same as mine on this amd64 system - I don't think it varies
(for a given architecture anyway)
> 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"];
I assume these addresses are pointers to the internal GEOM objects (because
they must be unique) - ie they are actual memory location.
Hmm, perhaps 0xfffff80000000000 is where kernel RAM starts?
--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
