From nobody Mon Dec 16 06:35:55 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YBVZs5VSTz5h0NW; Mon, 16 Dec 2024 06:36:21 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (midget.dons.net.au [IPv6:2403:580d:ae98:0:225:90ff:fe47:39b4]) by mx1.freebsd.org (Postfix) with ESMTP id 4YBVZs2J3cz4TYH; Mon, 16 Dec 2024 06:36:21 +0000 (UTC) (envelope-from darius@dons.net.au) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2001:44b8:1d2:8900:1876:809f:8906:ef38]) by midget.dons.net.au (Postfix) with ESMTPSA id 578E3738668; Mon, 16 Dec 2024 17:06:13 +1030 (ACDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dons.net.au; s=default; t=1734330974; bh=SaTxBtUxsyP0HBLCkOEmO+jkXtZDSAXyypzjGo1X5eo=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=CfTiiUmK1b10j3PBaNqK+Ggw+l/MM5lcvFasxR7xJ1DVTx0psGAUAXzbQ3Ya/J+4P crLr2rXKfHxcHOLwmfmdlJGNevUdtJRKvkOeEGilQXbWjPowM3bOX9ECamdrBA5Zsg RVcIfu8zk5BFHcu3KOCypaL/Ybrl2qUqK5dKER+yvKHiTVAoZp0IUqh/XHkvGRX6Tp JIceJ7D+eBd50EuYql7eqOddHcamA4OsHHfn/H56nCfqOgzAz5A5PAXT6Hd89VFiWq YWbZI8mSpQGxjaIq1VGTSq7TRDMSE1eoH00Hl1IK01csibisuu49FAku4IcMEwkJyp yQofUz/t/a8PA== Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.200.121\)) Subject: Re: What kind of code might generate amd64 addressses like 0xFFFFF80000000007 or be based on 0xFFFFF80000000000 ? From: Daniel O'Connor In-Reply-To: Date: Mon, 16 Dec 2024 17:05:55 +1030 Cc: FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-hackers , freebsd-amd64@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <358515C3-C6B0-46C4-BC4F-03DA80598559@dons.net.au> References: <65B0673C-287A-47E5-A732-17CC5EEE3350.ref@yahoo.com> <65B0673C-287A-47E5-A732-17CC5EEE3350@yahoo.com> <8C32FA41-C0EC-4679-9E26-B7CC3C69ECE6@dons.net.au> To: Mark Millard X-Mailer: Apple Mail (2.3826.200.121) X-Rspamd-Action: no action X-Rspamd-Server: midget.dons.net.au X-Spam-Status: No, score=-0.09 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800::/27, country:AU] X-Rspamd-Queue-Id: 4YBVZs2J3cz4TYH X-Spamd-Bar: ---- > On 16 Dec 2024, at 16:18, Mark Millard wrote: >>> On 16 Dec 2024, at 10:33, Mark Millard wrote: >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D267028 is for a = crash problem >>> someone has been having over more than 2 years. There are boot time = crashes >>> involved. >>>=20 >>> 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. >>>=20 >>> 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. >>=20 >> That value (0xffffffff80000000) is kernbase (see sysctl = kern.base_address). >=20 > On an amd64 system that I have access to: >=20 > # sysctl -x kern.base_address > kern.base_address: 0xffffffff80000000 >=20 > But, while looking similar, it is not the same base number: >=20 > 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: >=20 > kern.geom.confdot: digraph geom { > z0xfffff80105633a00 [shape=3Dbox,label=3D"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