Re: r324353: boot failure: failed with error 19
On Fri, 2017-10-06 at 22:33 +0200, O. Hartmann wrote: > First of all, I think something has changed, since /dev/ufs doesn't get > populated anymore > by usage of "gpart label" command. Second, there is a high chance that I > messed up > NanoBSD a bit, a couple of days ago I tried to sync with the code base > changes and I made > most changes effectively what is now "legacy.sh". Here is the crucial error... Labels created with glabel are in /dev/label, they have never been in /dev/ufs. /dev/ufs is populated by the contents of ufs filesystem labels, which are created using "newfs -L" or "tunefs -L". To see what label (if any) is on your root filesystem, use: # dumpfs / | grep vol volname roots1 swuid 0 providersize262135 If nothing appears between "volname" and "swuid" it has no label. I'm not disputing something may have changed that is causing you problems, I'm just trying to point out that you are chasing the wrong cause based on some kind of misunderstanding of the symptoms. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r324353: boot failure: failed with error 19
Am Fri, 6 Oct 2017 15:27:52 +0200 (CEST)
Trond Endrestøl schrieb:
> On Fri, 6 Oct 2017 15:10+0200, O. Hartmann wrote:
>
> > I run a small appliance on an APU from PCengines. This box is bootet via SD
> > card, the
> > image is created by a modified NanoBSD, which creates GPT/UEFI partitioning
> > and
> > booting images.
> >
> > That worked until two days ago (I do not track the revision numer) when I
> > wrote (via
> > dd) the last image out. Today, I tried to boot r324353 and it fails at tthe
> > boot
> > loader:
> >
> >
> > mountroot: waiting for device /dev/ufs/dsks1a...
> > Mounting from ufs:/dev/ufs/dsks1a failed with error 19.
> >
> >
> > I can proceed by manually issuing at the loader propmpt
> >
> > ufs:/dev/gpt/dsks1a
> >
> > and booting proceeds as expected.
> >
> >
> > Something seems wrong with the UFS labeling lately.
> >
>
> > The gpt layout looks like this:
> >
> > gpart show -l:
> >
> > => 40 60751792 mmcsd0 GPT (29G)
> > 40 130 1 boot (65K)
> >170 6 - free - (3.0K)
> >176 2057288 2 dsks1a [bootme] (1.0G)
> >2057464 2061725 3 dsks2a (1.0G)
> >4119189 1048576 4 dsks3 (512M)
> >5167765 55584067 - free - (27G)
>
> For one, these are the GPT labels.
>
> Can you verify the UFS labels (volnames)?
>
> Try: dumpfs /dev/gpt/dsks1a
>
> > From dmesg. I can provide this last output:
> >
> > [...]
> > mmcsd0: 31GB at mmc0
> > 50.0MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/dsks1a
> > [ro]...
> > uhub0: 4 ports with 4 removable, self powered
> > Root mount waiting for: usbus1
> > uhub1: 2 ports with 2 removable, self powered
> > Root mount waiting for: usbus1
> > ugen1.2: at usbus1
> > uhub2 on uhub1
> > uhub2: on
> > usbus1
> > uhub2: 4 ports with 4 removable, self powered
> > mountroot: waiting for device /dev/ufs/dsks1a...
> > Mounting from ufs:/dev/ufs/dsks1a failed with error 19.
> >
> > Loader variables:
> > vfs.root.mountfrom=ufs:/dev/ufs/dsks1a
> > vfs.root.mountfrom.options=ro
> >
> > Manual root filesystem specification:
> > : [options]
> > Mount using filesystem
> > and with the specified (optional) option list.
> >
> > eg. ufs:/dev/da0s1a
> > zfs:tank
> > cd9660:/dev/cd0 ro
> > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
> >
> > ? List valid disk boot devices
> > . Yield 1 second (for background tasks)
> > Abort manual input
> >
> > mountroot> Trying to mount root from
> > ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs []...
> > mountroot: waiting for device /dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs...
> > random: unblocking device.
> > arc4random: no preloaded entropy cache
>
> > Mounting from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs failed with error 19.
> >
This is because me stupid hit the backspace key in the boot loader console :-(
>
> This surely indicates a mangled UFS volname.
>
> Maybe you should rewrite the volname:
>
> tunefs -L dsk1a /dev/gpt/dsks1a
NanoBSD, the original one, defines a "NANO_DRIVE", which is the expansion
of /ufs/"NANO_LABEL". When creating the memory backed filesystem via gpart, the
label is
given by the option "-l ${NANO_LABEL}${NANO_CFG_LBL}". NANO_LABEL is set to
"dsk".
NANO_CFG_LBL is an extension of my own - I needed for a project GPT/UEFI
booting NanoBSD
images and I wanted to stay compatible with the code given by Kamp et al., so
NANO_CFG_LBL is set to s3. This should then provide the fstab entry
"/dev/ufs/dsks3" for
the cfg partition. Accordingly, the primary boot partition has
"/dev/ufs/dsks1a". It is a
bit messy, since I was in a hurry and had to deal with this crappy MBR slice
style s1a
through s1h.
This is what I setup in "defaults-add.sh", just to give the impression, what I
intended
to do:
[...]
# Set NANO_LABEL to non-blank to form the basis for using /dev/ufs/label
# in preference to /dev/${NANO_DRIVE}
# Root partition will be ${NANO_LABEL}s{1,2}
# /cfg partition will be ${NANO_LABEL}s3
# /data partition will be ${NANO_LABEL}s4
: ${NANO_LABEL="dsk"}
#
# Labels for the boot and EFI boot partitions
: ${NANO_BOOT_LBL="boot0"}
: ${NANO_EFI_LBL="efiboot0"}
#
# Label extensions: form, i.e., ${NANO_LABEL}${NANO_ROOT_LBL}
: ${NANO_ROOT_LBL="s1a"}
: ${NANO_ALTROOT_LBL="s2a"}
: ${NANO_CFG_LBL="s3"}
: ${NANO_DATA_LBL="s4"}
#
: ${NANO_SLICE_ROOT="s1"}
: ${NANO_SLICE_ALTROOT="s2"}
: ${NANO_SLICE_CFG="s3"}
: ${NANO_SLICE_DATA="s4"}
[...]
The file "defaults-add.sh" is read by "nanobsd.sh" before "defaults.sh" is
read. In
"defaults.sh" I altered also all initially set variables to be of the form
": $VARIABLE=Setting}" so my own settings aren't overwritten by accident and
later, when
the driver script of nanobsd is setup, one can set his own variables like
VARIABLE=Setting to overwrite the initial settings. The above should give in
case of a
vacant NANO_LABEL the devic
Re: r324353: boot failure: failed with error 19
Am Fri, 6 Oct 2017 07:10:44 -0700 Warner Losh schrieb: > On Fri, Oct 6, 2017 at 6:10 AM, O. Hartmann wrote: > > > I run a small appliance on an APU from PCengines. This box is bootet via > > SD card, the > > image is created by a modified NanoBSD, which creates GPT/UEFI > > partitioning and booting > > images. > > > > That worked until two days ago (I do not track the revision numer) when I > > wrote (via dd) > > the last image out. Today, I tried to boot r324353 and it fails at tthe > > boot loader: > > > > > > mountroot: waiting for device /dev/ufs/dsks1a... > > Mounting from ufs:/dev/ufs/dsks1a failed with error 19. > > > > That's odd... But likely a race It could be that dd'ing the new > partition, however, was made from an image that didn't have the proper ufs > label. The images I write out seem to have the correct /dev/gpt/ entries, but the /dev/ufs entries are missing. Writing labels with glabel produces entries in /dev/label/, but I still miss those in /dev/ufs/. This is more than confusing. > > What's the rev of the last version that worked? As I wrote before, I do not track and since the image has been overwritten, I do not know. But it isn't older than two days. > > Warner > > > > I can proceed by manually issuing at the loader propmpt > > > > ufs:/dev/gpt/dsks1a > > > > and booting proceeds as expected. > > > > > > Something seems wrong with the UFS labeling lately. > > > > The gpt layout looks like this: > > > > gpart show -l: > > > > => 40 60751792 mmcsd0 GPT (29G) > > 40 130 1 boot (65K) > >170 6 - free - (3.0K) > >176 2057288 2 dsks1a [bootme] (1.0G) > >2057464 2061725 3 dsks2a (1.0G) > >4119189 1048576 4 dsks3 (512M) > >5167765 55584067 - free - (27G) > > > > From dmesg. I can provide this last output: > > > > [...] > > mmcsd0: 31GB at mmc0 > > 50.0MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/dsks1a > > [ro]... > > uhub0: 4 ports with 4 removable, self powered > > Root mount waiting for: usbus1 > > uhub1: 2 ports with 2 removable, self powered > > Root mount waiting for: usbus1 > > ugen1.2: at usbus1 > > uhub2 on uhub1 > > uhub2: on > > usbus1 > > uhub2: 4 ports with 4 removable, self powered > > mountroot: waiting for device /dev/ufs/dsks1a... > > Mounting from ufs:/dev/ufs/dsks1a failed with error 19. > > > > Loader variables: > > vfs.root.mountfrom=ufs:/dev/ufs/dsks1a > > vfs.root.mountfrom.options=ro > > > > Manual root filesystem specification: > > : [options] > > Mount using filesystem > > and with the specified (optional) option list. > > > > eg. ufs:/dev/da0s1a > > zfs:tank > > cd9660:/dev/cd0 ro > > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) > > > > ? List valid disk boot devices > > . Yield 1 second (for background tasks) > > Abort manual input > > > > mountroot> Trying to mount root from > > ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs > > []... > > mountroot: waiting for device /dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs... > > random: unblocking device. > > arc4random: no preloaded entropy cache > > Mounting from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs failed with error > > 19. > > > > mountroot> Invalid file system specification. > > > > mountroot> Trying to mount root from ufs:/dev/gpt/dsks1a []... > > arc4random: no preloaded entropy cache > > GEOM_ELI: Device gpt/swap.eli created. > > GEOM_ELI: Encryption: AES-XTS 128 > > GEOM_ELI: Crypto: hardware > > Link state changed to up > > > > [...] > > > > > > Can someone look into this? > > > > Kind regards, > > > > Oliver > > -- > > O. Hartmann > > > > Ich widerspreche der Nutzung oder Übermittlung meiner Daten für > > Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). pgpueu5pLSLGU.pgp Description: OpenPGP digital signature
Re: RFC how to use kernel procs/threads efficiently
On Fri, 2017-10-06 at 19:02 +, Rick Macklem wrote: > Hi, > > I have now dropped the client side of Flexible File Layout for pNFS into head > and I believe it is basically working. > Currently when talking to mirrored DS servers, it does the Write and Commit > RPCs to the mirrors serially. This works, but is inefficient w.r.t. elapsed > to to > completion. > > To do them concurrently, I need separate kernel processes/threads to do them. > I can think of two ways to do this: > 1 - The code that I have running in projects/pnfs-planb-server for the pNFS > server > side does a kproc_create() to create a kernel process that does the RPC > and > then krpc_exit()s. > - This was easy to code and works. However, I am concerned that there is > going to be excessive overheads from doing all the kproc_create()s and > kproc_exit()s? > Anyone know if these calls will result in large overheads? > 2 - I haven't coded this, but the other way I can think of to do this is to > create a pool of threads (kthread_create() is sufficient in this case, I > think?) and then hand each RPC to an available thread so it can do the > RPC. > - Other than a little more complex coding, the main issue I see with > this one > is "How many threads and when to create more/less of them.". > > Anyhow, any comments w.r.t. the merits of either of the above approaches > (or a suggestion of other ways to do this) would be appreciated, rick taskqueue(9) is an existing mechanism to enqueue functions to execute asynch using a pool of threads, but it doesn't answer the scalability questions. In fact it may make them harder, inasmuch as I don't think there's a mechanism to dynamically adjust the number of threads after first calling taskqueue_start_threads(). -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RFC how to use kernel procs/threads efficiently
Hi, I have now dropped the client side of Flexible File Layout for pNFS into head and I believe it is basically working. Currently when talking to mirrored DS servers, it does the Write and Commit RPCs to the mirrors serially. This works, but is inefficient w.r.t. elapsed to to completion. To do them concurrently, I need separate kernel processes/threads to do them. I can think of two ways to do this: 1 - The code that I have running in projects/pnfs-planb-server for the pNFS server side does a kproc_create() to create a kernel process that does the RPC and then krpc_exit()s. - This was easy to code and works. However, I am concerned that there is going to be excessive overheads from doing all the kproc_create()s and kproc_exit()s? Anyone know if these calls will result in large overheads? 2 - I haven't coded this, but the other way I can think of to do this is to create a pool of threads (kthread_create() is sufficient in this case, I think?) and then hand each RPC to an available thread so it can do the RPC. - Other than a little more complex coding, the main issue I see with this one is "How many threads and when to create more/less of them.". Anyhow, any comments w.r.t. the merits of either of the above approaches (or a suggestion of other ways to do this) would be appreciated, rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
On 2017-Oct-6, at 9:58 AM, Conrad Meyer wrote: > On Fri, Oct 6, 2017 at 9:17 AM, Ian Lepore wrote: >> It isn't about "a broken port". All C++ code is broken if exceptions >> don't work. That means devd is broken. Not to mention clang itself. >> It may be that neither of those relies on exceptions for routine >> operation and uses them only for error handling, and errors mostly >> don't happen. There is plenty of C++ code in the world where >> exceptions are used in non-fatal-error cases and where the applications >> just don't work at all without them. > > Then use G++ for C++ on those second-tier architectures. We've got a > working C++ toolchain. g++'s toolchain (such as via devel/powerpc64-xtoolchain-gcc ) has its own problems: A) For targeting powerpc64 it fails to build a working lib32. (This may well be better than clang's status overall.) B) For targeting powerpc (32-bit): what toolchain? === Mark Millard markmi at dsl-only.net ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
On Fri, Oct 6, 2017 at 9:17 AM, Ian Lepore wrote: > It isn't about "a broken port". All C++ code is broken if exceptions > don't work. That means devd is broken. Not to mention clang itself. > It may be that neither of those relies on exceptions for routine > operation and uses them only for error handling, and errors mostly > don't happen. There is plenty of C++ code in the world where > exceptions are used in non-fatal-error cases and where the applications > just don't work at all without them. Then use G++ for C++ on those second-tier architectures. We've got a working C++ toolchain. Conrad ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
On Fri, 2017-10-06 at 09:04 -0700, Conrad Meyer wrote: > On Thu, Oct 5, 2017 at 9:58 PM, Mark Millard > wrote: > > > > Luckily most kernel and world code that I actively use > > does not throw C++ exceptions in my use. > > > > But devel/kyua is majorly broken by the C++ exception > > issue: It makes extensive use of C++ exceptions. In my > > view that disqualifies clang as being "close": I view > > my activity as a hack until devel/kyua is generally > > operable and so available for use in testing. > I don't think that is a major roadblock; a broken port is a broken > port. Kyua is a relatively unimportant one for most users. In this > particular case, maybe kyua (a leaf binary) could be built with GCC > instead of Clang on any platform with broken C++ exceptions. > > Best, > Conrad It isn't about "a broken port". All C++ code is broken if exceptions don't work. That means devd is broken. Not to mention clang itself. It may be that neither of those relies on exceptions for routine operation and uses them only for error handling, and errors mostly don't happen. There is plenty of C++ code in the world where exceptions are used in non-fatal-error cases and where the applications just don't work at all without them. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
On 2017-Oct-6, at 7:15 AM, Justin Hibbits wrote:
> Hi Mark,
>
> On Thu, Oct 5, 2017 at 11:58 PM, Mark Millard wrote:
>> Warner Losh imp at bsdimp.com wrote on
>> Thu Oct 5 21:01:26 UTC 2017 :
>>
>>> Starting in FreeBSD 11, arm and powerpc are supported by clang,
>>> but not super well. For FreeBSD 12, we're getting close for everything
>>> except sparc64 (whose fate has not yet been finally decided).
>>
>> My understanding of the powerpc and powerpc64 status
>> follows. This is based on my use of head via clang
>> as much as I can for them.
>>
>> For TARGET_ARCH=powerpc64 and TARGET_ARCH=powerpc :
>>
>> lld is far from working last I knew. (I've focused
>> more on the compilers for testing, using other
>> linkers and such.) [lldb may be in a similar state
>> for powerpc64. It does not build for powerpc.]
>>
>> clang 5 (and 4) generated code crashes on any thrown
>> C++ exception. For example:
>>
>> #include
>>
>> int main(void)
>> {
>>try { throw std::exception(); }
>>catch (std::exception& e) {}
>>return 0;
>> }
>>
>> crashes.
>>
>> Luckily most kernel and world code that I actively use
>> does not throw C++ exceptions in my use.
>
> Do you see this problem using libstdc++, et al, from base gcc 4.2.1?
> Or using libc++?
gcc 4.2.1 buildkernel buildworld work fine for anything that I've
tried. They are libstdc++ based.
I've not tried clang with libstdc++, just libc++. (Note: clang 3.8,
3.9, 4.0, and 5.0 all have had the problem. My llvm bug submittals
tend to be from the earlier time frame. Many of my submittals for
other types of issues have been addressed. )
But my llvm bugzilla submittals for C++ exceptions indicate
errors/incompletenesses in the DW_CFA_ generation, such as
for scratch register handling. (Warning: I've not been through
the details in some time so this is from a vague memory.) 26844
and 26856 are the relevant ones if I remember right. 31590 might
be relevant depending on what linunwind is to be used.
Be warned that I do not believe Roman Divacky agrees with my
interpretation and I'd never studied the exception handling
techniques prior to these investigations. Still I think that
I was correct about there being problems in the DW_CFA_
sequences generated.
For a separate issue llvm 31716 is relevant for .plt and the
function descriptor layout. I use Roman Divacky's patch listing in
Comment 1. Included below as well.
The llvm patches that I have are both from Roman as I remember:
Index: /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
===
--- /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
(revision 324071)
+++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
(working copy)
@@ -1178,7 +1178,7 @@
// For SVR4, don't emit a move for the CR spill slot if we haven't
// spilled CRs.
if (isSVR4ABI && (PPC::CR2 <= Reg && Reg <= PPC::CR4)
- && !MustSaveCR)
+ && (!MustSaveCR && isPPC64))
continue;
// For 64-bit SVR4 when we have spilled CRs, the spill location
Index: /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp
===
--- /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp (revision 324071)
+++ /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp (working copy)
@@ -60,7 +60,8 @@
static uint16_t applyPPCHighesta(uint64_t V) { return (V + 0x8000) >> 48; }
PPC64::PPC64() {
- PltRel = GotRel = R_PPC64_GLOB_DAT;
+ GotRel = R_PPC64_GLOB_DAT;
+ PltRel = R_PPC64_JMP_SLOT;
RelativeRel = R_PPC64_RELATIVE;
GotEntrySize = 8;
GotPltEntrySize = 8;
> I don't have the time right now to look into it, but if no one else is
> able to in the next couple months I'll try to make the time when
> higher priorities are done.
Are you familiar with what the DQ_CFA_ sequences should
be like given the powerpc scratch register usage and the
like?
>> But devel/kyua is majorly broken by the C++ exception
>> issue: It makes extensive use of C++ exceptions. In my
>> view that disqualifies clang as being "close": I view
>> my activity as a hack until devel/kyua is generally
>> operable and so available for use in testing.
>>
>> clang 5 currently can not build the TARGET_ARCH=powerpc
>> kernel. (I was able to back in clang 4 days --but the
>> resultant build failed to execute init fully after
>> finishing the prior boot activity.) For the 32-bit
>> context I use gcc 4.2.1 for building the kernel and
>> clang 5 for building the world, system binutils
>> in use in both cases.
>
> What problem(s) do you see with this? If they're just compile time
> failures they can be fixed pretty readily.
I submitted FreeBSD bugzilla 221107 for the:
R_PPC_PLTREL24 reloc against local symbol
failures. This was using system binutils.
In a parallel builds it is a race between agp.* vs.
aha.* reporting this and stopping the build.
>> I do build the kernel and
Re: C++ in jemalloc
On Fri, Oct 6, 2017 at 9:17 AM, Ian Lepore wrote: > On Fri, 2017-10-06 at 09:04 -0700, Conrad Meyer wrote: > > On Thu, Oct 5, 2017 at 9:58 PM, Mark Millard > > wrote: > > > > > > Luckily most kernel and world code that I actively use > > > does not throw C++ exceptions in my use. > > > > > > But devel/kyua is majorly broken by the C++ exception > > > issue: It makes extensive use of C++ exceptions. In my > > > view that disqualifies clang as being "close": I view > > > my activity as a hack until devel/kyua is generally > > > operable and so available for use in testing. > > I don't think that is a major roadblock; a broken port is a broken > > port. Kyua is a relatively unimportant one for most users. In this > > particular case, maybe kyua (a leaf binary) could be built with GCC > > instead of Clang on any platform with broken C++ exceptions. > > > > Best, > > Conrad > > It isn't about "a broken port". All C++ code is broken if exceptions > don't work. That means devd is broken. Not to mention clang itself. > It may be that neither of those relies on exceptions for routine > operation and uses them only for error handling, and errors mostly > don't happen. There is plenty of C++ code in the world where > exceptions are used in non-fatal-error cases and where the applications > just don't work at all without them. > I'm with Ian: Broken C++ exceptions means a broken C++ compiler. It's best to think of it like the tertiary operator being wonky in 'C'... Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
On Thu, Oct 5, 2017 at 9:58 PM, Mark Millard wrote: > Luckily most kernel and world code that I actively use > does not throw C++ exceptions in my use. > > But devel/kyua is majorly broken by the C++ exception > issue: It makes extensive use of C++ exceptions. In my > view that disqualifies clang as being "close": I view > my activity as a hack until devel/kyua is generally > operable and so available for use in testing. I don't think that is a major roadblock; a broken port is a broken port. Kyua is a relatively unimportant one for most users. In this particular case, maybe kyua (a leaf binary) could be built with GCC instead of Clang on any platform with broken C++ exceptions. Best, Conrad ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
Hi Mark,
On Thu, Oct 5, 2017 at 11:58 PM, Mark Millard wrote:
> Warner Losh imp at bsdimp.com wrote on
> Thu Oct 5 21:01:26 UTC 2017 :
>
>> Starting in FreeBSD 11, arm and powerpc are supported by clang,
>> but not super well. For FreeBSD 12, we're getting close for everything
>> except sparc64 (whose fate has not yet been finally decided).
>
> My understanding of the powerpc and powerpc64 status
> follows. This is based on my use of head via clang
> as much as I can for them.
>
> For TARGET_ARCH=powerpc64 and TARGET_ARCH=powerpc :
>
> lld is far from working last I knew. (I've focused
> more on the compilers for testing, using other
> linkers and such.) [lldb may be in a similar state
> for powerpc64. It does not build for powerpc.]
>
> clang 5 (and 4) generated code crashes on any thrown
> C++ exception. For example:
>
> #include
>
> int main(void)
> {
> try { throw std::exception(); }
> catch (std::exception& e) {}
> return 0;
> }
>
> crashes.
>
> Luckily most kernel and world code that I actively use
> does not throw C++ exceptions in my use.
Do you see this problem using libstdc++, et al, from base gcc 4.2.1?
Or using libc++?
I don't have the time right now to look into it, but if no one else is
able to in the next couple months I'll try to make the time when
higher priorities are done.
>
> But devel/kyua is majorly broken by the C++ exception
> issue: It makes extensive use of C++ exceptions. In my
> view that disqualifies clang as being "close": I view
> my activity as a hack until devel/kyua is generally
> operable and so available for use in testing.
>
> clang 5 currently can not build the TARGET_ARCH=powerpc
> kernel. (I was able to back in clang 4 days --but the
> resultant build failed to execute init fully after
> finishing the prior boot activity.) For the 32-bit
> context I use gcc 4.2.1 for building the kernel and
> clang 5 for building the world, system binutils
> in use in both cases.
What problem(s) do you see with this? If they're just compile time
failures they can be fixed pretty readily.
>
> I do build the kernel and world for
> TARGET_ARCH=powerpc64 via system clang 5. But I
> use ports binutils as well in order for this to
> finish and work overall.
>
>
> As for more modern devel/powerpc64-xtoolchain-gcc
> (so devel/powerpc64-gcc) versions being used to
> build the world and kernel for powerpc64 I've never
> been able to get lib32 on powerpc64 to work via
> such a build: it builds but fails to execute from
> dereferencing via an R30 that has an inappropriate
> value for the attempt ( lib32/crtbeginS.o code in
> _init in /usr/lib32/libc.so.* ). (The clang-based
> builds do not have this problem.) It has been a
> while since I've done devel/powerpc64-gcc
> experiments.
>
> I'm not aware of a devel/powerpc-xtoolchain-gcc
> as an alternative for 32-bit powerpc targeting.
There's documentation floating around (on the wiki maybe?) for doing
this. I won't check now, but it's not difficult (not trivial, but not
difficult). With the proposal to eliminate gcc 4.2.1 from our tree by
the end of the year, we need to get everything in place to make a
seamless transition, whether it be to external toolchain or to finish
up clang for powerpc. I really hope we can finish up clang. Please
continue to file bugs with as much detail as necessary to track down
and fix the problems--both in FreeBSD and upstream LLVM.
- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r324353: boot failure: failed with error 19
On Fri, Oct 6, 2017 at 6:10 AM, O. Hartmann wrote: > I run a small appliance on an APU from PCengines. This box is bootet via > SD card, the > image is created by a modified NanoBSD, which creates GPT/UEFI > partitioning and booting > images. > > That worked until two days ago (I do not track the revision numer) when I > wrote (via dd) > the last image out. Today, I tried to boot r324353 and it fails at tthe > boot loader: > > > mountroot: waiting for device /dev/ufs/dsks1a... > Mounting from ufs:/dev/ufs/dsks1a failed with error 19. > That's odd... But likely a race It could be that dd'ing the new partition, however, was made from an image that didn't have the proper ufs label. What's the rev of the last version that worked? Warner > I can proceed by manually issuing at the loader propmpt > > ufs:/dev/gpt/dsks1a > > and booting proceeds as expected. > > > Something seems wrong with the UFS labeling lately. > > The gpt layout looks like this: > > gpart show -l: > > => 40 60751792 mmcsd0 GPT (29G) > 40 130 1 boot (65K) >170 6 - free - (3.0K) >176 2057288 2 dsks1a [bootme] (1.0G) >2057464 2061725 3 dsks2a (1.0G) >4119189 1048576 4 dsks3 (512M) >5167765 55584067 - free - (27G) > > From dmesg. I can provide this last output: > > [...] > mmcsd0: 31GB at mmc0 > 50.0MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/dsks1a > [ro]... > uhub0: 4 ports with 4 removable, self powered > Root mount waiting for: usbus1 > uhub1: 2 ports with 2 removable, self powered > Root mount waiting for: usbus1 > ugen1.2: at usbus1 > uhub2 on uhub1 > uhub2: on > usbus1 > uhub2: 4 ports with 4 removable, self powered > mountroot: waiting for device /dev/ufs/dsks1a... > Mounting from ufs:/dev/ufs/dsks1a failed with error 19. > > Loader variables: > vfs.root.mountfrom=ufs:/dev/ufs/dsks1a > vfs.root.mountfrom.options=ro > > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. > > eg. ufs:/dev/da0s1a > zfs:tank > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) > > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input > > mountroot> Trying to mount root from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs > []... > mountroot: waiting for device /dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs... > random: unblocking device. > arc4random: no preloaded entropy cache > Mounting from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs failed with error > 19. > > mountroot> Invalid file system specification. > > mountroot> Trying to mount root from ufs:/dev/gpt/dsks1a []... > arc4random: no preloaded entropy cache > GEOM_ELI: Device gpt/swap.eli created. > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Crypto: hardware > Link state changed to up > > [...] > > > Can someone look into this? > > Kind regards, > > Oliver > -- > O. Hartmann > > Ich widerspreche der Nutzung oder Übermittlung meiner Daten für > Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r324353: boot failure: failed with error 19
On Fri, 6 Oct 2017 15:10+0200, O. Hartmann wrote: > I run a small appliance on an APU from PCengines. This box is bootet via SD > card, the > image is created by a modified NanoBSD, which creates GPT/UEFI partitioning > and booting > images. > > That worked until two days ago (I do not track the revision numer) when I > wrote (via dd) > the last image out. Today, I tried to boot r324353 and it fails at tthe boot > loader: > > > mountroot: waiting for device /dev/ufs/dsks1a... > Mounting from ufs:/dev/ufs/dsks1a failed with error 19. > > > I can proceed by manually issuing at the loader propmpt > > ufs:/dev/gpt/dsks1a > > and booting proceeds as expected. > > > Something seems wrong with the UFS labeling lately. > > The gpt layout looks like this: > > gpart show -l: > > => 40 60751792 mmcsd0 GPT (29G) > 40 130 1 boot (65K) >170 6 - free - (3.0K) >176 2057288 2 dsks1a [bootme] (1.0G) >2057464 2061725 3 dsks2a (1.0G) >4119189 1048576 4 dsks3 (512M) >5167765 55584067 - free - (27G) For one, these are the GPT labels. Can you verify the UFS labels (volnames)? Try: dumpfs /dev/gpt/dsks1a > From dmesg. I can provide this last output: > > [...] > mmcsd0: 31GB at mmc0 > 50.0MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/dsks1a [ro]... > uhub0: 4 ports with 4 removable, self powered > Root mount waiting for: usbus1 > uhub1: 2 ports with 2 removable, self powered > Root mount waiting for: usbus1 > ugen1.2: at usbus1 > uhub2 on uhub1 > uhub2: on > usbus1 > uhub2: 4 ports with 4 removable, self powered > mountroot: waiting for device /dev/ufs/dsks1a... > Mounting from ufs:/dev/ufs/dsks1a failed with error 19. > > Loader variables: > vfs.root.mountfrom=ufs:/dev/ufs/dsks1a > vfs.root.mountfrom.options=ro > > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. > > eg. ufs:/dev/da0s1a > zfs:tank > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) > > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input > > mountroot> Trying to mount root from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs > []... > mountroot: waiting for device /dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs... > random: unblocking device. > arc4random: no preloaded entropy cache > Mounting from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs failed with error 19. This surely indicates a mangled UFS volname. Maybe you should rewrite the volname: tunefs -L dsk1a /dev/gpt/dsks1a Or is the volname misspelled? tunefs -L dsks1a /dev/gpt/dsks1a Or is /etc/fstab on the SD card corrupted? > mountroot> Invalid file system specification. > > mountroot> Trying to mount root from ufs:/dev/gpt/dsks1a []... > arc4random: no preloaded entropy cache > GEOM_ELI: Device gpt/swap.eli created. > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Crypto: hardware > Link state changed to up > > [...] > > > Can someone look into this? > > Kind regards, > > Oliver -- Trond. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r324353: boot failure: failed with error 19
I run a small appliance on an APU from PCengines. This box is bootet via SD card, the image is created by a modified NanoBSD, which creates GPT/UEFI partitioning and booting images. That worked until two days ago (I do not track the revision numer) when I wrote (via dd) the last image out. Today, I tried to boot r324353 and it fails at tthe boot loader: mountroot: waiting for device /dev/ufs/dsks1a... Mounting from ufs:/dev/ufs/dsks1a failed with error 19. I can proceed by manually issuing at the loader propmpt ufs:/dev/gpt/dsks1a and booting proceeds as expected. Something seems wrong with the UFS labeling lately. The gpt layout looks like this: gpart show -l: => 40 60751792 mmcsd0 GPT (29G) 40 130 1 boot (65K) 170 6 - free - (3.0K) 176 2057288 2 dsks1a [bootme] (1.0G) 2057464 2061725 3 dsks2a (1.0G) 4119189 1048576 4 dsks3 (512M) 5167765 55584067 - free - (27G) From dmesg. I can provide this last output: [...] mmcsd0: 31GB at mmc0 50.0MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/dsks1a [ro]... uhub0: 4 ports with 4 removable, self powered Root mount waiting for: usbus1 uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus1 ugen1.2: at usbus1 uhub2 on uhub1 uhub2: on usbus1 uhub2: 4 ports with 4 removable, self powered mountroot: waiting for device /dev/ufs/dsks1a... Mounting from ufs:/dev/ufs/dsks1a failed with error 19. Loader variables: vfs.root.mountfrom=ufs:/dev/ufs/dsks1a vfs.root.mountfrom.options=ro Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> Trying to mount root from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs []... mountroot: waiting for device /dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs... random: unblocking device. arc4random: no preloaded entropy cache Mounting from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs failed with error 19. mountroot> Invalid file system specification. mountroot> Trying to mount root from ufs:/dev/gpt/dsks1a []... arc4random: no preloaded entropy cache GEOM_ELI: Device gpt/swap.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: hardware Link state changed to up [...] Can someone look into this? Kind regards, Oliver -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). pgpqb6O84sepd.pgp Description: OpenPGP digital signature
Re: C++ in jemalloc
On Thu, Oct 05, 2017 at 11:59:03AM -0700, David Goldblatt wrote: > Hi all, > > The jemalloc developers have wanted to start using C++ for a while, to > enable some targeted refactorings of code we have trouble maintaining due > to brittleness or complexity (e.g. moving thousand line macro definitions > to templates, changing the build->extract symbols->rebuild mangling scheme > for internal symbols to one using C++ namespaces). We'd been holding off > because we thought that FreeBSD base all had to compile on GCC 4.2, in > order to support some esoteric architectures[1]. > > The other day though, I noticed that there is some C++ shipping with > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the HACKING > document that C++11 is a minimum for FreeBSD 11). This, combined with the > fact that ports now points to a modern gcc, makes me think we were > incorrect, and can turn on C++ without breaking FreeBSD builds. Note that these are just usermode utilities, which implementation language is not too important. If we considered ghc or rustc to be acceptable dependency for utilities, then they could be implemented in Haskell or Rust as well. > > Am I right? Will anything break if jemalloc needs a C++ compiler to build? > We will of course not use exceptions, RTTI, global constructors, the C++ > stdlib, or anything else that might affect C source or link compatibility. I wonder how can you guarantee that for current and future compilers without having the standard saying and compiler facilities to ensure that. See below. > > Thanks, > David (on behalf of the jemalloc developers > > [1] That being said, we don't compile or test on those architectures, and > so probably don't work there in the first place if I'm being honest. But > we'd also like to avoid making that a permanent state of affairs that can't > be changed. On Thu, Oct 05, 2017 at 04:50:32PM -0700, David Goldblatt wrote: > We can avoid it in the short term without a ton of pain. In the long run it > would be nice to have, but I wouldn't want to tie our release schedule to > FreeBSD's too tightly (our CI is improving to the point where the tip of > the dev branch gets tested about as well as releases would be, so we're > trying to de-emphasize release vs. non-release versions). Do you have a > sense of when the situation might change (if only so I know when to check > back)? > > Thanks for the replies on this, they've been super helpful. I do not think so. You are talking about importing C++ code into libc. Libc _implements_ C runtime, which is a dependency of any C++ runtime. That is, we cannot allow C++ runtime to be dragged into libc. C++ freestanding implementation, by the standard, is required to provide the runtime typeinfo, exceptions, intialization and termination support (i.e. atexit/cxa_atexit and most important cxa_thread_atexit, if you use TLS) and so on. It clearly gives the cycle in the dependencies. There is no requirement on the compilers to not use these features in unexpected ways, and looking at the current compiler evolution, I do expect that these features would bite us simply because we allowed C++ code in libc. We already have some issues die to the jemalloc reliance on pthreads, which makes the bootstraping a problem. We have to maintain the ugly fake init trick to postpone malloc for the mutexes backing store inside libthr to allow jemalloc to initialize without causing cyclic dependencies. Also, our C runtime (rtld/libc/libthr and perhaps libm) is currently only requires C compiler (and assembler and linker) to compile. Having C++ requirement for compilation, assuming the runtime issues I noted above are somewhat avoided, is also not a move I consider useful. Summary is that, in my opinion, requiring C++ compiler and working runtime for malloc(3) implementation is not desirable. If this goes in, low-level parts of the libc and whole libthr must grow private malloc implementation to not depend on libc malloc. Currently only rtld has private malloc (for similar reasons). ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
