Date: Mon, 16 Dec 2024 17:05:55 +1030 From: Daniel O'Connor <darius@dons.net.au> To: Mark Millard <marklmi@yahoo.com> Cc: FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.org>, freebsd-amd64@freebsd.org Subject: Re: What kind of code might generate amd64 addressses like 0xFFFFF80000000007 or be based on 0xFFFFF80000000000 ? Message-ID: <358515C3-C6B0-46C4-BC4F-03DA80598559@dons.net.au> In-Reply-To: <D069E39E-CC3A-4F00-8475-1F6BE10711DB@yahoo.com> References: <65B0673C-287A-47E5-A732-17CC5EEE3350@yahoo.com> <8C32FA41-C0EC-4679-9E26-B7CC3C69ECE6@dons.net.au> <D069E39E-CC3A-4F00-8475-1F6BE10711DB@yahoo.com>
index | next in thread | previous in thread | raw e-mail
> On 16 Dec 2024, at 16:18, Mark Millard <marklmi@yahoo.com> wrote: >>> On 16 Dec 2024, at 10:33, Mark Millard <marklmi@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 Tanenbaumhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?358515C3-C6B0-46C4-BC4F-03DA80598559>