Re: r343917 fails into single-user mode at boot - new clang related issue?

From: Mark Millard <>
Date: Sat, 9 Feb 2019 13:11:46 -0800
Alexander Leidinger Alexander at wrote on
Sat Feb 9 17:26:10 UTC 2019 :

> Quoting Alexander Leidinger <Alexander at> (from Sat, 09  
> Feb 2019 13:44:25 +0100):
> > This is after deleting /usr/obj, and cleaning the ccache cache. All  
> > cases are with CPUTYPE=native (Intel Xeon E5620).
> >
> > I remember a commit of a new clang to head. Anything else in the  
> > area of influence for this?
> > My next try is to compile without CPUTYPE=native to see if the new  
> > clang is doing something in this area which it didn't do before. Has  
> > anyone else seen a similar issue or has an idea what to look at next?
> Removing the CPUTYPE setting in make.conf didn't help. Ideas welcome.

I am running:

# uname -apKU
FreeBSD FBSDFSSD 13.0-CURRENT FreeBSD 13.0-CURRENT #9 r343884M: Thu Feb  7 19:22:33 PST 2019     markmi_at_FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG  amd64 amd64 1300010 1300010

but I happen to have been booting the SSD via Hyper-V under Windows 10 Pro
instead of directly in recent times. (Things are configured to allow booting
from the BIOS as well.) Also: My builds are normally with non-debug kernels,
the above included.

I'm not seeing any problems with booting in my context.

But I've been running various FreeBSD versions based on clang 7
for a while. Currently:

# clang -v
FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 7.0.1)
Target: x86_64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin

I'd not expect clang vintage to be the issue.

Mark Millard
marklmi at
( went
away in early 2018-Mar)
Received on Sat Feb 09 2019 - 20:11:58 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:20 UTC