Re: ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)]
On Fri, Nov 26, 2021 at 02:48:03PM -0500, Mark Johnston wrote: > On Fri, Nov 26, 2021 at 02:00:27PM -0500, Mark Johnston wrote: > > On Fri, Nov 26, 2021 at 06:12:49PM +0200, Andriy Gapon wrote: > > > On 26/11/2021 18:06, Mark Johnston wrote: > > > > On Thu, Nov 25, 2021 at 10:48:36PM +0200, Andriy Gapon wrote: > > > >> > > > >> I've just finished builds of yesterday's CURRENT / main for arm and > > > >> arm64. > > > >> In both builds I got lots of messages from ctfconvert: > > > >> ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] > > > >> > > > >> I got an impression that there was a message for each object file, > > > >> that's how > > > >> many of them were there. > > > >> > > > >> I don't recall seeing those messages before. > > > >> > > > >> Should I be concerned? > > > >> Maybe I am doing something wrong or have an unusual configuration? > > > >> Any way to fix the issue? > > > >> > > > >> Thanks! > > > >> > > > >> P.S. > > > >> The builds were done on stable/13, so maybe there is an issue with > > > >> host tools > > > >> not being able to grok something new. > > > > > > > > I haven't seen this before, for what it's worth. I presume this is from > > > > a kernel build? Does the configuration enable generation of debug info > > > > with, e.g., "makeoptions DEBUG=-g"? > > > > > > This is actually from buildworld. > > > buildkernel is silent. > > > > Thanks, I can reproduce it now. > > > > Our libdwarf is complaining that the first compilation unit header in > > .debug_info contains an unsupported DWARF version number (libdwarf only > > supports 2, 3 and 4). In files compiled by clang it ends up being zero. > > For instance, compiling bin/cat and dumping the .debug_info section: > > > > gcc10: > > c125 0400 0801 > >^ DWARF version > > clang: > > 0100 4e23 > > > > llvm-dwarfdump and binutils readelf are somehow still able to find a > > valid-looking unit header, but I haven't yet been able to figure out how > > they do that from reading the DWARF 4/5 specs or the LLVM sources. > > Ah, we recently started configuring clang to compress debug sections by > default, and our libdwarf doesn't know how to handle that. As an > interim workaround this could simply be disabled with WITH_CTF is > configured: ... or give this a try: https://reviews.freebsd.org/D33139
Re: VDSO on amd64
On Thu, 25 Nov 2021 at 00:36, Kurt Jaeger wrote: > > Eleven years ago Giuseppe Cocomazzi posted this: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-April/031553.html > > vdso and shared page patch I see the patch generated a couple of responses on the list when it was posted, including a plan to follow up with a detailed review that appears not to have happened. It's unfortunate, and as a project we definitely have an issue that not all contributions are addressed in a timely manner. One of the goals of the Git working group, and Warner's newer development practices working group, is to make it easier to handle contributions. Of course contributions can be overlooked regardless of whether they're patches on a mailing list, attached to a Bugzilla PR, opened as a Phabricator review, or as a GitHub or Gitlab pull or merge request. There isn't a technical solution that will fully address this, but we can reduce friction as much as possible.
Re: problem with re(4) interface
On 11/22/21 12:55 PM, Warner Losh wrote:
On Mon, Nov 22, 2021 at 10:51 AM Chuck Tuffli wrote:
On Mon, Nov 22, 2021 at 9:34 AM Chris wrote:
On 2021-11-22 08:47, Chuck Tuffli wrote:
Running on a recent-ish -current
# uname -a
FreeBSD stargate.tuffli.net 14.0-CURRENT FreeBSD 14.0-CURRENT
main-81b22a9892 GENERIC amd64
I'm having trouble using the second NIC interface in a bridge to
provide
network connectivity to bhyve VMs and need some help figuring out what
is
wrong.
...
Because there's subtle differences between them; are you using the re
driver
from base, or from ports?
The driver is from base. Didn't realize there was one in ports.
The ports driver is tricky... It's an older, buggier version of the base
driver... *BUT*
a number of issues that aren't fixed in base are fixed in it (mostly
dealing better with
errata)... Ideally, we'd pull in the actual fixes from this driver, but
it's a huge patch-set
where it's unclear which bits are for what thing fixed, so nobody (that I
know of) has
gone through and even come up with an ugly patch for -current.
Warner
I use the Realtek BSD driver; it supports one of their newer 2.5GbE
Ethernet chips on my motherboard.
Aug 22 19:37:29 vickie kernel: re1: Controller> port 0xc000-0xc0ff mem
0xfc20-0xfc20,0xfc21-0xfc213fff at device 0.0 on pci7
Aug 22 19:37:29 vickie kernel: re1: Using Memory Mapping!
Aug 22 19:37:29 vickie kernel: re1: attempting to allocate 1 MSI-X
vectors (32 supported)
Aug 22 19:37:29 vickie kernel: msi: routing MSI-X IRQ 84 to local APIC 2
vector 51
Aug 22 19:37:29 vickie kernel: re1: using IRQ 84 for MSI-X
Aug 22 19:37:29 vickie kernel: re1: Using 1 MSI-X message
Aug 22 19:37:29 vickie kernel: re1: version:1.96.04
Aug 22 19:37:29 vickie kernel: re1: Ethernet address: 2c:f0:5d:**:**:**
Aug 22 19:37:29 vickie kernel:
Aug 22 19:37:29 vickie kernel: This product is covered by one or more of
the following patents:
Aug 22 19:37:29 vickie kernel: US6,570,884, US6,115,776, and US6,327,625.
Aug 22 19:37:29 vickie kernel: re1: bpf attached
Aug 22 19:37:29 vickie kernel: re1: Ethernet address: 2c:f0:5d:**:**:**
The stock re(4) driver doesn't detect it.
The Realtek driver sources are here
https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-pci-express-software
but they're for FreeBSD 7.x and 8.0; I had to patch the driver for my
14.0-CURRENT box (panic on an mtx_lock(9) call; adding flag MTX_RECURSE
to the mtx_init(9) call "fixes" it).
diff --git a/if_rereg.h b/if_rereg.h
index 18592a7..4885063 100755
--- a/if_rereg.h
+++ b/if_rereg.h
@@ -1016,7 +1016,7 @@ enum bits {
#define RE_LOCK(_sc) mtx_lock(&(_sc)->mtx)
#define RE_UNLOCK(_sc) mtx_unlock(&(_sc)->mtx)
-#define RE_LOCK_INIT(_sc,_name)
mtx_init(&(_sc)->mtx,_name,MTX_NETWORK_LOCK,MTX_DEF)
+#define RE_LOCK_INIT(_sc,_name)
mtx_init(&(_sc)->mtx,_name,MTX_NETWORK_LOCK,MTX_DEF | MTX_RECURSE)
#define RE_LOCK_DESTROY(_sc) mtx_destroy(&(_sc)->mtx)
#define RE_LOCK_ASSERT(_sc) mtx_assert(&(_sc)->mtx,MA_OWNED)
Maybe I can try making this into a port - oh great, someone beat me to it!
https://www.freshports.org/net/realtek-re-kmod
Looks like they "properly" fix the locking isue -
https://bugs.freebsd.org/bugzilla/attachment.cgi?id=225980=diff
Anthony
Re: Kernel panic by executing `poudriere bulk`
From: Mateusz Guzik Subject: Re: Kernel panic by executing `poudriere bulk` Date: Fri, 26 Nov 2021 20:33:22 +0100 > On 11/26/21, Yasuhiro Kimura wrote: >> yasu@rolling-vm-freebsd1[1015]% uname -a >> ~ >> FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD >> 14.0-CURRENT #0 main-n251115-ae92ace05fd: Sat Nov 27 01:47:15 JST 2021 >> ro...@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC >> amd64 >> yasu@rolling-vm-freebsd1[1016]% >> >> After regular weekly update of my 14-current amd64 system, kernel >> panic happens when I execute `poudriere bulk`. >> >> Snapshot of console: >> https://www.utahime.org/FreeBSD/FreeBSD-14-CURRENT-amd64-main-n251115-ae92ace05fd.panic.png >> > > Should be fixed by > https://cgit.freebsd.org/src/commit?id=1879021942f56c8b264f4aeb1966b3733908ef62 Confirmed. Thanks for quick fix! --- Yasuhiro Kimura
Re: ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)]
On Fri, Nov 26, 2021 at 02:00:27PM -0500, Mark Johnston wrote:
> On Fri, Nov 26, 2021 at 06:12:49PM +0200, Andriy Gapon wrote:
> > On 26/11/2021 18:06, Mark Johnston wrote:
> > > On Thu, Nov 25, 2021 at 10:48:36PM +0200, Andriy Gapon wrote:
> > >>
> > >> I've just finished builds of yesterday's CURRENT / main for arm and
> > >> arm64.
> > >> In both builds I got lots of messages from ctfconvert:
> > >> ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)]
> > >>
> > >> I got an impression that there was a message for each object file,
> > >> that's how
> > >> many of them were there.
> > >>
> > >> I don't recall seeing those messages before.
> > >>
> > >> Should I be concerned?
> > >> Maybe I am doing something wrong or have an unusual configuration?
> > >> Any way to fix the issue?
> > >>
> > >> Thanks!
> > >>
> > >> P.S.
> > >> The builds were done on stable/13, so maybe there is an issue with host
> > >> tools
> > >> not being able to grok something new.
> > >
> > > I haven't seen this before, for what it's worth. I presume this is from
> > > a kernel build? Does the configuration enable generation of debug info
> > > with, e.g., "makeoptions DEBUG=-g"?
> >
> > This is actually from buildworld.
> > buildkernel is silent.
>
> Thanks, I can reproduce it now.
>
> Our libdwarf is complaining that the first compilation unit header in
> .debug_info contains an unsupported DWARF version number (libdwarf only
> supports 2, 3 and 4). In files compiled by clang it ends up being zero.
> For instance, compiling bin/cat and dumping the .debug_info section:
>
> gcc10:
> c125 0400 0801
>^ DWARF version
> clang:
> 0100 4e23
>
> llvm-dwarfdump and binutils readelf are somehow still able to find a
> valid-looking unit header, but I haven't yet been able to figure out how
> they do that from reading the DWARF 4/5 specs or the LLVM sources.
Ah, we recently started configuring clang to compress debug sections by
default, and our libdwarf doesn't know how to handle that. As an
interim workaround this could simply be disabled with WITH_CTF is
configured:
diff --git a/share/mk/bsd.lib.mk b/share/mk/bsd.lib.mk
index 10262e6bb80c..5a5be3494471 100644
--- a/share/mk/bsd.lib.mk
+++ b/share/mk/bsd.lib.mk
@@ -113,7 +113,7 @@ CXXFLAGS+= -ftrivial-auto-var-init=pattern
.if ${MK_DEBUG_FILES} != "no" && empty(DEBUG_FLAGS:M-g) && \
empty(DEBUG_FLAGS:M-gdwarf*)
-.if !${COMPILER_FEATURES:Mcompressed-debug}
+.if !${COMPILER_FEATURES:Mcompressed-debug} || ${MK_CTF} == "yes"
CFLAGS+= ${DEBUG_FILES_CFLAGS:N-gz*}
CXXFLAGS+= ${DEBUG_FILES_CFLAGS:N-gz*}
.else
diff --git a/share/mk/bsd.prog.mk b/share/mk/bsd.prog.mk
index 437ccf373130..21597128f991 100644
--- a/share/mk/bsd.prog.mk
+++ b/share/mk/bsd.prog.mk
@@ -93,7 +93,7 @@ CFLAGS+=${CRUNCH_CFLAGS}
.else
.if ${MK_DEBUG_FILES} != "no" && empty(DEBUG_FLAGS:M-g) && \
empty(DEBUG_FLAGS:M-gdwarf-*)
-.if !${COMPILER_FEATURES:Mcompressed-debug}
+.if !${COMPILER_FEATURES:Mcompressed-debug} || ${MK_CTF} == "yes"
CFLAGS+= ${DEBUG_FILES_CFLAGS:N-gz*}
.else
CFLAGS+= ${DEBUG_FILES_CFLAGS}
Re: Kernel panic by executing `poudriere bulk`
On 11/26/21, Yasuhiro Kimura wrote: > yasu@rolling-vm-freebsd1[1015]% uname -a > ~ > FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD > 14.0-CURRENT #0 main-n251115-ae92ace05fd: Sat Nov 27 01:47:15 JST 2021 > ro...@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > amd64 > yasu@rolling-vm-freebsd1[1016]% > > After regular weekly update of my 14-current amd64 system, kernel > panic happens when I execute `poudriere bulk`. > > Snapshot of console: > https://www.utahime.org/FreeBSD/FreeBSD-14-CURRENT-amd64-main-n251115-ae92ace05fd.panic.png > Should be fixed by https://cgit.freebsd.org/src/commit?id=1879021942f56c8b264f4aeb1966b3733908ef62 -- Mateusz Guzik
Kernel panic by executing `poudriere bulk`
yasu@rolling-vm-freebsd1[1015]% uname -a ~ FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n251115-ae92ace05fd: Sat Nov 27 01:47:15 JST 2021 ro...@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 yasu@rolling-vm-freebsd1[1016]% After regular weekly update of my 14-current amd64 system, kernel panic happens when I execute `poudriere bulk`. Snapshot of console: https://www.utahime.org/FreeBSD/FreeBSD-14-CURRENT-amd64-main-n251115-ae92ace05fd.panic.png --- Yasuhiro Kimura
Re: ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)]
On Fri, Nov 26, 2021 at 06:12:49PM +0200, Andriy Gapon wrote: > On 26/11/2021 18:06, Mark Johnston wrote: > > On Thu, Nov 25, 2021 at 10:48:36PM +0200, Andriy Gapon wrote: > >> > >> I've just finished builds of yesterday's CURRENT / main for arm and arm64. > >> In both builds I got lots of messages from ctfconvert: > >> ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] > >> > >> I got an impression that there was a message for each object file, that's > >> how > >> many of them were there. > >> > >> I don't recall seeing those messages before. > >> > >> Should I be concerned? > >> Maybe I am doing something wrong or have an unusual configuration? > >> Any way to fix the issue? > >> > >> Thanks! > >> > >> P.S. > >> The builds were done on stable/13, so maybe there is an issue with host > >> tools > >> not being able to grok something new. > > > > I haven't seen this before, for what it's worth. I presume this is from > > a kernel build? Does the configuration enable generation of debug info > > with, e.g., "makeoptions DEBUG=-g"? > > This is actually from buildworld. > buildkernel is silent. Thanks, I can reproduce it now. Our libdwarf is complaining that the first compilation unit header in .debug_info contains an unsupported DWARF version number (libdwarf only supports 2, 3 and 4). In files compiled by clang it ends up being zero. For instance, compiling bin/cat and dumping the .debug_info section: gcc10: c125 0400 0801 ^ DWARF version clang: 0100 4e23 llvm-dwarfdump and binutils readelf are somehow still able to find a valid-looking unit header, but I haven't yet been able to figure out how they do that from reading the DWARF 4/5 specs or the LLVM sources.
Re: ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)]
On 26/11/2021 18:06, Mark Johnston wrote: On Thu, Nov 25, 2021 at 10:48:36PM +0200, Andriy Gapon wrote: I've just finished builds of yesterday's CURRENT / main for arm and arm64. In both builds I got lots of messages from ctfconvert: ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] I got an impression that there was a message for each object file, that's how many of them were there. I don't recall seeing those messages before. Should I be concerned? Maybe I am doing something wrong or have an unusual configuration? Any way to fix the issue? Thanks! P.S. The builds were done on stable/13, so maybe there is an issue with host tools not being able to grok something new. I haven't seen this before, for what it's worth. I presume this is from a kernel build? Does the configuration enable generation of debug info with, e.g., "makeoptions DEBUG=-g"? This is actually from buildworld. buildkernel is silent. I have WITH_CTF=yes in src.conf for both arm and arm64. For completeness, here are all other options in the src.conf (many of them are probably obsolete): WITHOUT_ACCT=yes WITHOUT_ACPI=yes WITHOUT_AMD=yes WITHOUT_APM=yes WITHOUT_ATM=yes WITHOUT_BLACKLIST=yes WITHOUT_BLACKLIST_SUPPORT=yes WITHOUT_BLUETOOTH=yes WITHOUT_BOOTPARAMD=yes WITHOUT_BOOTPD=yes WITHOUT_CCD=yes WITHOUT_CUSE=yes WITHOUT_CXGBETOOL=yes WITHOUT_EXAMPLES=yes WITHOUT_FINGER=yes WITHOUT_FLOPPY=yes WITHOUT_GOOGLETEST=yes WITHOUT_HAST=yes WITHOUT_HTML=yes WITHOUT_HYPERV=yes WITHOUT_IPFILTER=yes WITHOUT_KERBEROS=yes WITHOUT_KERBEROS_SUPPORT=yes WITHOUT_LOADER_GELI=yes WITHOUT_LPR=yes WITHOUT_MLX5TOOL=yes WITHOUT_NDIS=yes WITHOUT_PROFILE=yes WITHOUT_RBOOTD=yes WITHOUT_ROUTED=yes WITHOUT_SHAREDOCS=yes WITHOUT_TALK=yes WITHOUT_TESTS=yes WITHOUT_TESTS_SUPPORT=yes WITHOUT_USB_GADGET_EXAMPLES=yes WITHOUT_ZONEINFO=yes# comes from the misc/zoneinfo port -- Andriy Gapon
Re: ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)]
On Thu, Nov 25, 2021 at 10:48:36PM +0200, Andriy Gapon wrote: > > I've just finished builds of yesterday's CURRENT / main for arm and arm64. > In both builds I got lots of messages from ctfconvert: >ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] > > I got an impression that there was a message for each object file, that's how > many of them were there. > > I don't recall seeing those messages before. > > Should I be concerned? > Maybe I am doing something wrong or have an unusual configuration? > Any way to fix the issue? > > Thanks! > > P.S. > The builds were done on stable/13, so maybe there is an issue with host tools > not being able to grok something new. I haven't seen this before, for what it's worth. I presume this is from a kernel build? Does the configuration enable generation of debug info with, e.g., "makeoptions DEBUG=-g"?
