From nobody Mon Dec 16 07:01:59 2024 X-Original-To: freebsd-hackers@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 4YBW8c3jLKz5h1tL; Mon, 16 Dec 2024 07:02:08 +0000 (UTC) (envelope-from philipp.takacs@asta.kit.edu) Received: from scc-mailout-kit-02.scc.kit.edu (scc-mailout-kit-02.scc.kit.edu [IPv6:2a00:1398:9:f712::810d:e752]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YBW8c1z9cz4YmY; Mon, 16 Dec 2024 07:02:08 +0000 (UTC) (envelope-from philipp.takacs@asta.kit.edu) Authentication-Results: mx1.freebsd.org; none Received: by scc-mailout-kit-02.scc.kit.edu with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (envelope-from ) id 1tN57E-00383S-0V; Mon, 16 Dec 2024 08:02:04 +0100 Received: from imap-1.asta.kit.edu ([2a00:1398:5:f400::73]) by hekate.asta.kit.edu with esmtp (Exim 4.94.2) (envelope-from ) id 1tN57A-003sR9-On; Mon, 16 Dec 2024 08:02:00 +0100 Received: from localhost ([2a02:8071:7111:c540:62cb:5ce4:5722:8d85]) by imap-1.asta.kit.edu with ESMTPSA id GfhoHGjQX2eWNBQA0pLxkA (envelope-from ); Mon, 16 Dec 2024 08:02:00 +0100 Message-ID: <63a9fdaa4ac204c319a1c1e273a29c18.philipp.takacs@asta.kit.edu> From: Philipp To: Mark Millard Cc: FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-hackers , freebsd-amd64@freebsd.org Subject: Re: What kind of code might generate amd64 addressses like 0xFFFFF80000000007 or be based on 0xFFFFF80000000000 ? In-reply-to: <65B0673C-287A-47E5-A732-17CC5EEE3350@yahoo.com> References: <65B0673C-287A-47E5-A732-17CC5EEE3350.ref@yahoo.com> <65B0673C-287A-47E5-A732-17CC5EEE3350@yahoo.com> Comments: In-reply-to Mark Millard message dated "Sun, 15 Dec 2024 16:03:42 -0800." List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1212416.1734332519.1@hell> Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Dec 2024 08:01:59 +0100 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)[]; TAGGED_FROM(0.00)[freebsd]; ASN(0.00)[asn:34878, ipnet:2a00:1398::/32, country:DE] X-Rspamd-Queue-Id: 4YBW8c1z9cz4YmY X-Spamd-Bar: ---- Hi Mark [2024-12-15 16:03] Mark Millard > 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 crash= es > involved. > > It appears that 0xFFFFF80000000007 is showing up in use and stored in dat= a > structures as a pointer value in fields/arguments that are pointers, wher= e such > a special value would not be expected. Later defrerencing does not go wel= l, 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. 0xFFFFF800= 00000000 (or > near it) might be odd enough to have only a few known likely possible usa= ges. Such > notes in the bugzilla report would be good if such is the case. Thus my q= uestion. By simple grep through sys/ I found following comment in sys/amd64/include/= vmparam.h: > /* > * Virtual addresses of things. Derived from the page directory and > * page table indexes from pmap.h for precision. > [...] > * 0xfffff80000000000 - 0xfffffbffffffffff 4TB direct map The direct map is 4TB of virtuall address space mapping the physical address space 1:1 (minus the base). So I would guess this is caused by an NULL pointer converted by PHYS_TO_DMAP. Philipp > The context has amdgpu raven support in use normally. Reportedly the prob= lem has > never been seen with that disabled. (However, I'm not aware of experiment= s with > alternate card types, for example.) > > Where, when, and if a boot crash occurs is variable, not stable. But use = of the > list found_modules->tqh_first->. . . tends to be involved. > > > > Some other modern 13.4-RELEASE related context notes > ( comments #231 and #233 ): > > The person with the problem reports . . . > > I am not using a stock distribution of the kernel: > > diff -u sys/amd64/conf/{GENERIC,M5P} > --- sys/amd64/conf/GENERIC 2024-07-03 16:23:56.252550000 -0400 > +++ sys/amd64/conf/M5P 2024-07-03 16:25:05.287604000 -0400 > @@ -18,12 +18,13 @@ > # > = > cpu HAMMER > -ident GENERIC > +ident M5P > = > makeoptions DEBUG=3D-g # Build kernel with gdb(1) debug symbols > makeoptions WITH_CTF=3D1 # Run ctfconvert(1) for DTrace support > = > -options SCHED_ULE # ULE scheduler > +#options SCHED_ULE # ULE scheduler > +options SCHED_4BSD # 4BSD scheduler > options NUMA # Non-Uniform Memory Architecture support > options PREEMPTION # Enable kernel thread preemption > options VIMAGE # Subsystem virtualization, e.g. VNET > > > I also noted (for modern 13.4-RELEASE times): > > Also: the build is based on the -p2 source code (hash 3f40d5821): > > # strings boot/kernel/kernel | grep "\-RELEASE" > @(#)FreeBSD 13.4-RELEASE-p2 3f40d5821 M5P > FreeBSD 13.4-RELEASE-p2 3f40d5821 M5P > 13.4-RELEASE-p2 > > Because it is a rebuild, the kernel ends up with -p2 instead > of the official -p1 ( from -p2 not updating boot/kernel/kernel > in the official distributions ). > > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > >