Re: Warning with loader Makefile?

[Andrew Turner]

Nate Lawson wrote:
I get this:
===> i386/cdboot
===> i386/kgzldr
===> i386/libi386
===> i386/loader
"/usr/share/mk/bsd.prog.mk", line 38: warning: duplicate script for target "loader" 
ignored
cc -nostdlib -static -Ttext 0x0 -o loader.sym
/home/obj/home/src/sys/boot/i386/loader/../btx/lib/crt0.o main.o conf.o
bcache.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o
interp_parse.o ls.o misc.o module.o panic.o load_elf32.o load_elf64.o
isapnp.o pnp.o interp_forth.o vers.o
Why is there a duplicate script?
I found this patch worked by removing the secound ${PROG} target if 
there was already one there.

Andrew
--- /usr/src/share/mk/bsd.prog.mk   Mon Jun 30 06:16:26 2003
+++ /usr/share/mk/bsd.prog.mk   Mon Aug  4 17:54:22 2003
@@ -31,11 +31,13 @@
 
 OBJS+=  ${SRCS:N*.h:R:S/$/.o/g}
 
+.if !target(${PROG})
 ${PROG}: ${OBJS}
 .if defined(PROG_CXX)
${CXX} ${CXXFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDADD}
 .else
${CC} ${CFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDADD}
+.endif
 .endif
 
 .else !defined(SRCS)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Kernel option dependency finding

[Andrew Turner]

Hello,

Find attached a script I have started writing to find option dependency 
from the NOTES files.

Would other developers please test this script and submit suggestions 
back to me (on or off the list).

Andrew Turner



find_dependcy
Description: application/java-applet

Re: WARNING: Re: Kernel option dependency finding

[Andrew Turner]

Try this then:

#!/bin/sh

#Default options
LINTCONF=LINT.CONF
LINTCONF1=LINT.CONF1
ARCH=`uname -m`
ARCH1=$ARCH
SRCDIR=/sys
START=0
END=0
NOCLEAN=0
TMPDIR=/tmp/makedepend
WD=`pwd`

#Read the command line
while [ $# -ne 0 ]
do
case "$1" in
--src-dir)
shift
SRCDIR=$1
shift
;;
--conf-dir)
shift
CNFDIR=$1
shift
;;
--compile-dir)
shift
CMPDIR=$1
shift
;;
--arch)
shift
ARCH=$1
shift
;;
--no-copy)
NOCOPY="YES"
shift
;;
--no-clean)
shift
NOCLEAN=1
;;
--start)
shift
START=$1
shift
;;
--end)
shift
END=$1
shift
;;
--clean)
rm -f ${LINTCONF} ${LINTCONF1} bad_list LINT tmp
exit 0
;;
*)
CMD=`basename $0`
echo "USAGE: $CMD [option]"
echo
echo "Where option is any of:"
echo
echo "--help"
echo "  This help"
echo "--clean"
echo "   Clean the work directory"
echo "--no-clean"
echo "   Don't clean up"
echo "--src-dir :"
echo "   The top of the kernel source default: /sys"
echo "--conf-dir :"
echo "   The conf files dir default: //conf"
echo "--compile-dir :"
echo "   The dir the kernel to run make [depend] in default: 
/compile"
echo "--arch :"
echo "   The Arch to build for default: $ARCH1"
echo "--start "
echo "--end "
echo "   Only build kernels numbered between  and "
exit 1
;;
esac
done

# Move the options in the order we wan't them
# This script builds in a decending order so $START is always larger 
then $END
if [ $START -lt $END ]
then
STARTTMP=$START
START=$END
END=$STARTTMP
fi

# If we change end then finish on the one we said to
if [ $END -ne 0 ]
then
END=`expr $END - 1`
fi

# Set the default dir for running make
COMPDIR=$SRCDIR/$ARCH/compile

# If is set as an option change it
if [ $CMPDIR ]
then
COMPDIR=$CMPDIR
fi

# Set the default dir for the config files
CONFDIR=$SRCDIR/$ARCH/conf

# If is set as an option change it
if [ $CNFDIR ]
then
CONFDIR=$CNFDIR
fi

# Clean the build directories
if [ $NOCLEAN -eq 0 ]
then
rm -f ${LINTCONF} ${LINTCONF1} bad_list LINT tmp
rm -f ${CONFDIR}/DEPEND.*
rm -fr ${TMPDIR}
mkdir -p ${TMPDIR}
touch ${TMPDIR}/pass
touch ${TMPDIR}/fail.config
touch ${TMPDIR}/fail.depend
touch ${TMPDIR}/fail.make
fi

# Do the copying on LINT/NOTES
if [ $NOCOPY ]
then
:
else
cd ${CONFDIR}
make LINT
cd $WD
cp ${CONFDIR}/LINT ./
fi

if [ -f LINT ]
then
:
else
echo "Error: No LINT/NOTES File"
exit 1
fi

if [ -f depend ]
then
:
else
touch depend
fi

# The changeable Config Options from LINT/NOTES
cat LINT | grep "^options" > ${LINTCONF}
cat LINT | grep "^device" >> ${LINTCONF}
cat LINT | grep "^pseudo-device" >> ${LINTCONF}

# Make a list of unwanted options
# The first character is always a !
awk '{ if ($1 =="!") print $2 " " $3 }' < depend > bad_list

# Remove the unwanted options
BADLINES=`awk '{ nlines++ } END { if ( nlines ) { print nlines } else { 
print "0" } }' < bad_list`
while [ ${BADLINES} -ne 0 ]
do
LINE=`cat bad_list | head -n ${BADLINES} | tail -n 1`
BADTYPE=`echo ${LINE} | awk '{print $1}'`
BADDEV=`echo ${LINE} | awk '{print $2}'`

cat ${LINTCONF} | awk "{ if ((\$1 == \"$BADTYPE\") && (\$2 ~ 
\"$BADDEV\")) { } else { print \$0 } }" > ${LINTCONF}2

mv ${LINTCONF}2 ${LINTCONF}
BADLINES=`expr $BADLINES - 1`
done

rm -f bad_list

# Unchangable Config Options from LINT/NOTES
cat LINT | grep "^ident" > ${LINTCONF1}
cat LINT | grep "^machine" >> ${L

Re: The future of ZFS in FreeBSD

[Andrew Turner]

> On 19 Dec 2018, at 08:35, Matthew Macy  wrote:
> 
> On Tue, Dec 18, 2018 at 11:49 PM Enji Cooper  <mailto:yaneurab...@gmail.com>> wrote:
>> 
>> Hello Matthew,
>> 
>> I appreciate the long write up, as someone who still uses FreeBSD ZFS on my 
>> NAS box and knowing some of the history with ZFS on *Solaris, etc. Something 
>> like this was bound to happen with post the Oracle buyout.
>> 
>>> On Dec 18, 2018, at 10:49 PM, Matthew Macy  wrote:
>>> 
>>> The sources for FreeBSD's ZFS support are currently taken directly
>>> from Illumos with local ifdefs to support the peculiarities of FreeBSD
>>> where the Solaris Portability Layer (SPL) shims fall short. FreeBSD
>>> has regularly pulled changes from Illumos and tried to push back any
>>> bug fixes and new features done in the context of FreeBSD. In the past
>>> few years the vast majority of new development in ZFS has taken place
>>> in DelphixOS and zfsonlinux (ZoL). Earlier this year Delphix announced
>>> that they will be moving to ZoL
>>> https://www.delphix.com/blog/kickoff-future-eko-2018 This shift means
>>> that there will be little to no net new development of Illumos. While
>>> working through the git history of ZoL I have also discovered that
>>> many races and locking bugs have been fixed in ZoL and never made it
>>> back to Illumos and thus FreeBSD. This state of affairs has led to a
>>> general agreement among the stakeholders that I have spoken to that it
>>> makes sense to rebase FreeBSD's ZFS on ZoL. Brian Behlendorf
>>> has graciously encouraged me to add FreeBSD support directly to ZoL
>>> https://github.com/zfsonfreebsd/ZoF so that we might all have a single
>>> shared code base.
>>> 
>>> A port for ZoF can be found at https://github.com/miwi-fbsd/zof-port
>>> Before it can be committed some additional functionality needs to be
>>> added to the FreeBSD opencrypto framework. These can be found at
>>> https://reviews.freebsd.org/D18520
>>> 
>>> This port will provide FreeBSD users with multi modifier protection,
>>> project quotas, encrypted datasets, allocation classes, vectorized
>>> raidz, vectorized checksums, and various command line improvements.
>>> 
>>> Before ZoF can be merged back in to ZoL several steps need to be taken:
>>> - Integrate FreeBSD support into ZoL CI
>>> - Have most of the ZFS test suite passing
>>> - Complete additional QA testing at iX
>> 
>> Can you please describe the testing process that will be employed to verify 
>> the sanity of the ZoL on FreeBSD port? Should other large companies who use 
>> ZFS on FreeBSD (Panzura?) chime in and the ZFS on FreeBSD community (as a 
>> whole) collaborate to better suss out issues with the ZoL port?
> 
> The ZFS test suite itself provides ~80% coverage
> https://codecov.io/gh/zfsonlinux/zfs/branch/master 
> <https://codecov.io/gh/zfsonlinux/zfs/branch/master> - FreeBSD currently
> lacks equivalent gcov support, but presumably it would provide
> comparable coverage here. Andrew Turner has some form of kernel gcov
> support that he uses with syzkaller. However, I believe that it isn't
> sufficient for this purpose.

The code I have is to trace the kernel part of a single thread, e.g. what 
happens in the kernel when you make a system call. It can trace function either 
function entry or places in the code with a conditional statement, e.g. an if, 
while, or switch statement. If this is enough for your case a tool could be 
written to track coverage from the tests.

I expect to update the review soon. I’m working on a man page, but have been 
too busy with work and other projects recently to finish writing it.

Andrew

___
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"

Floating-point review

[Andrew Turner]

I'm looking for someone who known more about floating-point than I do
to review one of me changes. The change in question adds 6 new
functions to the ARM libc to perform floating-point comparisons. These
functions are required as part of the ABI spec.

The review is at [1]. I am mostly interested in having someone check
__aeabi_cfcmpeq_helper and __aeabi_cdcmpeq_helper are correct. They
should both return when either argument is a quiet NaN unless one is a
signalling NaN for floats and doubles respectively.

These functions are used by a functions that is defined to not raise a
floating point exception with comparing with quiet NaNs and all
comparisons with signalling NaNs could potentially raise an exception.
Because of this requirement these functions are used to filter out the
cases we have one or more quiet NaNs and no signalling NaNs.

Andrew

[1] https://reviews.freebsd.org/D872
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: System-On-Module

[Andrew Turner]

On Thu, 29 Jan 2015 18:27:08 +0900
"Lundberg, Johannes"  wrote:

> What I'm most worried about is the graphics stack.. Some companies
> don't seem so keen on handing out specs.

The only ARM vendor I know that has released documentation on their 3D
hardware is Broadcom [1]. The only options for this are the Raspberry
Pi or one of the mobile phones with a Broadcom CPU. I neither option to
be applicable for your requirements.

Andrew

[1]
http://www.broadcom.com/docs/support/videocore/VideoCoreIV-AG100-R.pdf
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r294248: boot stuck: EFI loader doesn't proceed

[Andrew Turner]

On Mon, 18 Jan 2016 09:10:33 +0100
Dimitry Andric  wrote:

> On 18 Jan 2016, at 07:20, O. Hartmann 
> wrote:
> > Building NanoBSD images booting off from USB Flash drives and
> > having two GPT partitions, booting is stuck in the UEFI loader,
> > presenting me with something like:
> > 
> > [...]
> > Probing 6 block devices.++. done
> > 
> >  ZFS found no pools
> >  UFS found 2 partitions
> > 
> > And further nothing happens. A RESET is only possible by a
> > hardreset - it seems the system is crashed/stuck/frozen or
> > something similar.
> > 
> > The last images working run r293654. The issue occurs with r294248.
> > 
> > Any suggestions possible? Did I miss something?  
> 
> Looks to me like fallout from the recent modularisation in r294060,
> and/or ZFS support in r294068.  Steven, any clue?
> 
> -Dimitry
> 

I found the same issue while working on nanobsd. I'm not sure it's
due to the recent ZFS changes as I reverted them, but found boot1
still failed to load loader.efi.

Andrew
___
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: r294248: boot stuck: EFI loader doesn't proceed

[Andrew Turner]

On Mon, 18 Jan 2016 12:04:38 +
Steven Hartland  wrote:

> On 18/01/2016 11:34, Andrew Turner wrote:
> > On Mon, 18 Jan 2016 09:10:33 +0100
> > Dimitry Andric  wrote:
> >  
> >> On 18 Jan 2016, at 07:20, O. Hartmann 
> >> wrote:  
> >>> Building NanoBSD images booting off from USB Flash drives and
> >>> having two GPT partitions, booting is stuck in the UEFI loader,
> >>> presenting me with something like:
> >>>
> >>> [...]
> >>> Probing 6 block devices.++. done
> >>>
> >>>   ZFS found no pools
> >>>   UFS found 2 partitions
> >>>
> >>> And further nothing happens. A RESET is only possible by a
> >>> hardreset - it seems the system is crashed/stuck/frozen or
> >>> something similar.
> >>>
> >>> The last images working run r293654. The issue occurs with
> >>> r294248.
> >>>
> >>> Any suggestions possible? Did I miss something?  
> >> Looks to me like fallout from the recent modularisation in r294060,
> >> and/or ZFS support in r294068.  Steven, any clue?
> >>
> >> -Dimitry
> >>  
> > I found the same issue while working on nanobsd. I'm not sure it's
> > due to the recent ZFS changes as I reverted them, but found boot1
> > still failed to load loader.efi.
> >  
> Can you update to > r294265 and test with EFI_DEBUG defined e.g.
> make buildenv -DEFI_DEBUG
> cd sys/boot/efi/boot1
> make clean
> make
> 
> Then install the new boot1.efifat to your efi partition.
> 
> Hopefully this will give some more information on what the problem
> may be.

the issue was we were caching reads from the first filesystem we looked
at. I've committed the fix in r294291 to force the code to re-read on
each filesystem it looks at.

Andrew
___
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: r294248: boot stuck: EFI loader doesn't proceed

[Andrew Turner]

On Mon, 18 Jan 2016 22:46:18 +
Steven Hartland  wrote:

> On 18/01/2016 21:57, Ed Maste wrote:
> > On 18 January 2016 at 15:26, Andrew Turner 
> > wrote:  
> >> the issue was we were caching reads from the first filesystem we
> >> looked at. I've committed the fix in r294291 to force the code to
> >> re-read on each filesystem it looks at.  
> > Thanks Andrew - my QEMU boot failure is not reproducible on a build
> > from a clean tree with this change included.  
> I still think there are issues in there, specifically the lookup call
> in try_load, which calls fsread should be getting bad results.

How? fsread will be called with dsk_meta == 0 so it will call the force
probe path.

Andrew
___
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: EFI boot: can we make loader.efi work as BOOT{x64, aa64, arm, ia32}.efi?

[Andrew Turner]

On Sat, 30 Jul 2016 23:20:55 -0700
Xin Li  wrote:

> Hi,
> 
> I finally got some time to explore the UEFI boot process (kudos to
> everyone who made this work!) and getting myself familiarize with the
> basics.
> 
> One quick question -- Is there some technical restriction that
> prevents us from merging boot1.efi and loader.efi into one binary?

The only issue I know about is loader.efi will use the wrong partition
to load the kernel. This is because it assumes the kernel is to be
loaded from the same filesystem as it was.

Andrew
___
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: FYI: FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw under qemu-system-aarch64 on odroid-c2 under UbuntuMate : No valid device tree blob found!

[Andrew Turner]

> On 30 Apr 2017, at 04:29, Mark Millard  wrote:
> ...
> acpi0: 
> acpi0: Power Button (fixed)
> acpi0: Sleep Button (fixed)

ACPI is not fully supported on arm64.

Andrew

___
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: FYI: FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw under qemu-system-aarch64 on odroid-c2 under UbuntuMate : No valid device tree blob found!

[Andrew Turner]

> On 30 Apr 2017, at 12:02, Mark Millard  wrote:
> 
> On 2017-Apr-30, at 1:57 AM, Andrew Turner  wrote:
> 
>>> On 30 Apr 2017, at 04:29, Mark Millard  wrote:
>>> ...
>>> acpi0: 
>>> acpi0: Power Button (fixed)
>>> acpi0: Sleep Button (fixed)
>> 
>> ACPI is not fully supported on arm64.
> 
> Good to know. Thanks.
> 
> But the messages:
> 
> No valid device tree blob found!
> WARNING! Trying to fire up the kernel, but no device tree blob found!
> 
> were well before the acpi0 messages so I'd expect
> that the lack of a "device tree blob" is a separate,
> earlier issue, likely to do with the content of:
> 
> FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw

No, the device tree blob comes from UEFI. It seems the current UEFI only 
provides the ACPI tables, and not a DTB.

Andrew

___
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: make tinderbox failures

[Andrew Turner]

On Fri, 26 Oct 2012 15:31:50 -0700
m...@freebsd.org wrote:
> Thanks for fixes!  Is the reason the public tinderbox didn't see these
> because it has explicit lists of arch/CONF kernels to build, while
> "make tinderbox" on my machine just builds all the capitalized files
> as configuration files?

I don't know about the MIPS builds but with ARM it is because the
tinderbox only builds for TARGET_ARCH=arm. 2 months ago I updated the
ARM configs to set their machine option correctly. This meant the
kernels sere built with the correct toolchain in "make tinderbox" but
not the public tinderbox.

The correct fix is to update the public tinderbox to build arm,
armv6 and armeb.

Andrew
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr)

[Andrew Turner]

On Thu, 13 Dec 2012 02:08:50 +0900
"Daisuke Aoyama"  wrote:
> Hi,
> 
> I've created FreeBSD clang world for RPI based on svn 244112 +
> eabi.diff(NOT USE) + few NetBSD code.
> I didn't test with "-mfloat-abi=softfp" but it might work.

If you haven't seen there is the start of FreeBSD ARM support in clang:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20121210/069693.html

I'm testing this with the version of clang we have in head and hope to
bring in support for clang and ARM soon.

Andrew
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [patch] i386 pmap sysmaps_pcpu[] atomic access

[Andrew Turner]

On Thu, 21 Feb 2013 10:43:49 -0500
John Baldwin  wrote:

> On Thursday, February 21, 2013 7:53:52 am Svatopluk Kraus wrote:
> > On Wed, Feb 20, 2013 at 4:22 PM, John Baldwin 
> > wrote:
> > > On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus wrote:
> > >> On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov
> > >>  wrote:
> > >> > On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus
> > >> > wrote:
> > >> >> On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov
> > >> >>  wrote:
> > >> >> Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP
> > >> >> case was simple. SMP case is more complex and rather new for
> > >> >> me. Recently, I was solving a problem with PCPU stuff. For
> > >> >> example, PCPU_GET is implemented by one instruction on i386
> > >> >> arch. So, a need of atomicity with respect to interrupts can
> > >> >> be overlooked. On load-store archs, the implementation which
> > >> >> works in SMP case is not so simple. And what works in UP case
> > >> >> (single PCPU), not works in SMP case. Believe me, mysterious
> > >> >> and sporadic 'mutex not owned' assertions and others ones
> > >> >> caused by curthreads mess, it takes a while ...
> > >> > Note that PCPU_GET() is not needed to be atomic. The reason is
> > >> > that the code which uses its result would not be atomic
> > >> > (single-instruction or whatever, see below). Thus, either the
> > >> > preemption should not matter since the action with the per-cpu
> > >> > data is advisory, as is in the case of i386 pmap you noted. or
> > >> > some external measures should be applied in advance to the
> > >> > containing region (which you proposed, by bracing with
> > >> > sched_pin()).
> > >>
> > >> So, it's advisory in the case of i386 pmap... Well, if you can
> > >> live with that, I can too.
> > >>
> > >> >
> > >> > Also, note that it is not interrupts but preemption which is
> > >> > concern.
> > >>
> > >> Yes and no. In theory, yes, a preemption is a concern. In
> > >> FreeBSD, however, sched_pin() and critical_enter() and their
> > >> counterparts are implemented with help of curthread. And
> > >> curthread definition falls to PCPU_GET(curthread) if not defined
> > >> in other way. So, curthread should be atomic with respect to
> > >> interrupts and in general, PCPU_GET() should be too. Note that
> > >> spinlock_enter() definitions often (always) use curthread too.
> > >> Anyhow, it's defined in MD code and can be defined for each arch
> > >> separately.
> > >
> > > curthread is a bit magic. :)  If you perform a context switch
> > > during an interrupt (which will change 'curthread') you also
> > > change your register state. When you resume, the register state
> > > is also restored.  This means that while something like
> > > 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread'
> > > never is.  However, it is true that actually reading curthread
> > > has to be atomic.  If your read of curthread looks like:
> > >
> > > mov , r0
> > > add , r0
> > > ld r0, r1
> > >
> > > Then that will indeed break.  Alpha used a fixed register for
> > > 'pcpu_reg' (as does ia64 IIRC).  OTOH, you might also be able to
> > > depend on the fact that pc_curthread is the first thing in
> > > 'struct pcpu' (and always will be, you could add a CTASSERT to
> > > future-proof).  In that case, you can remove the 'add'
> > > instruction and instead just do:
> > >
> > > ld , r1
> > >
> > > which is fine.
> > 
> > Just for the record. There are three extra (coprocessor) registers
> > per a core in arm11mpcore (armv6k). Unfortunately only one is
> > Privileged. The other ones are respectively User Read only and User
> > Read Write. For now, we are using the Privileged one to store pcpu
> > pointer (curthread is correctly set during each context switch).
> > Thus, using a coprocessor register means that reading of curthread
> > is not a single instruction implementation now. After we figured
> > out the curthread issue in SMP case, using a fixed (processor)
> > register for pcpu is an option. Meanwhile, we disable interrupts
> > before reading of curthread and enable them after. The same is done
> > for other PCPU stuff. For now we have not stable system enough for
> > profiling, however, when it will be, it would be interesting to
> > learn how various implementations of curthread reading impact
> > system performance.
> 
> curthread is read _a lot_, so I would expect this to hurt.  What we
> did on Alpha was to use a fixed register for pcpu access, but we used
> the equivalent of a coprocessor register to also store the value so
> we could set that fixed register on entry to the kernel (userland was
> free to use the register for its own purposes).
> 

The current code on ARM is not atomic, it loads the base address of the
pcpu data from the coprocessor then loads curthread from this address.
One solution I discussed with Olivier Houchard is to keep the data in
the coprocessor but to then load it into a

ARM pcpu changes, was Re: [patch] i386 pmap sysmaps_pcpu[] atomic access

[Andrew Turner]

On Mon, 25 Feb 2013 13:47:47 +0100
Olivier Houchard  wrote:

> On Mon, Feb 25, 2013 at 07:09:20PM +1300, Andrew Turner wrote:
> > On Thu, 21 Feb 2013 10:43:49 -0500
> > John Baldwin  wrote:
> > 
> > > On Thursday, February 21, 2013 7:53:52 am Svatopluk Kraus wrote:
> > > > On Wed, Feb 20, 2013 at 4:22 PM, John Baldwin 
> > > > wrote:
> > > > > On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus
> > > > > wrote:
> > > > >> On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov
> > > > >>  wrote:
> > > > >> > On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus
> > > > >> > wrote:
> > > > >> >> On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov
> > > > >> >>  wrote:
> > > > >> >> Well, I'm taking a part on porting FreeBSD to
> > > > >> >> ARM11mpcore. UP case was simple. SMP case is more complex
> > > > >> >> and rather new for me. Recently, I was solving a problem
> > > > >> >> with PCPU stuff. For example, PCPU_GET is implemented by
> > > > >> >> one instruction on i386 arch. So, a need of atomicity
> > > > >> >> with respect to interrupts can be overlooked. On
> > > > >> >> load-store archs, the implementation which works in SMP
> > > > >> >> case is not so simple. And what works in UP case (single
> > > > >> >> PCPU), not works in SMP case. Believe me, mysterious and
> > > > >> >> sporadic 'mutex not owned' assertions and others ones
> > > > >> >> caused by curthreads mess, it takes a while ...
> > > > >> > Note that PCPU_GET() is not needed to be atomic. The
> > > > >> > reason is that the code which uses its result would not be
> > > > >> > atomic (single-instruction or whatever, see below). Thus,
> > > > >> > either the preemption should not matter since the action
> > > > >> > with the per-cpu data is advisory, as is in the case of
> > > > >> > i386 pmap you noted. or some external measures should be
> > > > >> > applied in advance to the containing region (which you
> > > > >> > proposed, by bracing with sched_pin()).
> > > > >>
> > > > >> So, it's advisory in the case of i386 pmap... Well, if you
> > > > >> can live with that, I can too.
> > > > >>
> > > > >> >
> > > > >> > Also, note that it is not interrupts but preemption which
> > > > >> > is concern.
> > > > >>
> > > > >> Yes and no. In theory, yes, a preemption is a concern. In
> > > > >> FreeBSD, however, sched_pin() and critical_enter() and their
> > > > >> counterparts are implemented with help of curthread. And
> > > > >> curthread definition falls to PCPU_GET(curthread) if not
> > > > >> defined in other way. So, curthread should be atomic with
> > > > >> respect to interrupts and in general, PCPU_GET() should be
> > > > >> too. Note that spinlock_enter() definitions often (always)
> > > > >> use curthread too. Anyhow, it's defined in MD code and can
> > > > >> be defined for each arch separately.
> > > > >
> > > > > curthread is a bit magic. :)  If you perform a context switch
> > > > > during an interrupt (which will change 'curthread') you also
> > > > > change your register state. When you resume, the register
> > > > > state is also restored.  This means that while something like
> > > > > 'PCPU_GET(cpuid)' might be stale after you read it,
> > > > > 'curthread' never is.  However, it is true that actually
> > > > > reading curthread has to be atomic.  If your read of
> > > > > curthread looks like:
> > > > >
> > > > > mov , r0
> > > > > add , r0
> > > > > ld r0, r1
> > > > >
> > > > > Then that will indeed break.  Alpha used a fixed register for
> > > > > 'pcpu_reg' (as does ia64 IIRC).  OTOH, you might also be able
> > > > > to depend on the fact that pc_curthread is the first thing in
> > > > > 'struct pcpu' (a

Re: -ffunction-sections, -fdata-sections and -Wl,--gc-sections

[Andrew Turner]

On Sun, 15 Sep 2013 19:30:01 -0700
Tim Kientzle  wrote:

> 
> On Sep 15, 2013, at 2:24 PM, Ed Schouten  wrote:
> > GCC and Clang support the -ffunction-sections and -fdata-sections
> > flags. Essentially, these flags force the compiler to put every
> > function and variable in its own section. Though this will blow up
> > the
> ….
> > - devd suddenly becomes 500 KB in size, instead of a megabyte,
> > - init's size drops from 900 KB to 600 KB,
> 
> Can you figure out what functions are getting omitted
> when you make this change?

You can add "-Wl,--print-gc-sections" to LDFLAGS to print which sections
the linker is removing.

Andrew
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: RFC: Removing hpt* drivers from GENERIC

[Andrew Turner]

> On 25 Oct 2017, at 22:43, Colin Percival  wrote:
> 
> Hi developers,
> 
> I'd like to remove the hpt* drivers from GENERIC.  These are the drivers
> for the HighPoint storage hardware -- SATA (hptnr) and RAID (hpt27xx, hptiop,
> hptmv, hptrr).
> 
> My reason for wanting to remove them is that the hpt27xx and hptnr drivers
> spend ~150 ms in their DEVICE_PROBE routines every time the system boots.
> Since they are roughly 1000x slower than the median driver, this is clearly
> excessive; unfortunately the time is being spent inside a binary blob, so
> there is no apparent way to fix the drivers.  (The other three drives from
> the same vendor -- hptiop, hptmv, and hptrr -- don't exhibit this particular
> bug, but I don't see any strong argument in favour of not removing them along
> with the two problem drivers.)
> 
> All of these are available via kernel modules, so the impact upon users
> should be minimal.  Obviously I would not plan on MFCing this change.
> 
> Any objections?

Why are we building these binary blobs into the kernel? We don’t have the 
source for these so it’s more difficult to audit them for security issues. If 
the user wishes to load them as modules they are fine to do that, however I 
don’t think we shouldn’t be linking any of these blobs in a GENERIC kernel.

Andrew

___
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: Booting UEFI ZFS is broken on arm64

[Andrew Turner]

> On 30 Nov 2017, at 00:21, Shawn Webb  wrote:
> 
> It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot,
> booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to
> this line:
> 
> Using DTB provided by EFI at 0x801fe0.
> 
> Then all output stops. I'm in the process of building a custom install
> ISO that has DEBUG turned on in the fdt code. I hope to report back
> soon-ish, unless anyone else has any ideas as to what could be wrong.

This should be fixed in r326525.

Andrew

___
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: arm64 panic: reaper-related?

[Andrew Turner]

> On 13 Jul 2020, at 15:05, Glen Barber  wrote:
> 
> On Mon, Jul 13, 2020 at 01:58:21PM +, Glen Barber wrote:
>> Hi,
>> 
>> This morning, one of our arm64 build machines panicked.  It looks like
>> it is somehow reaper-related, but I am not entirely sure.  Backtrace
>> follows.  Any thoughts?  I'm not quite sure where to go from here...
>> Thanks in advance for any input.
>> 
>> db> set $lines 0
>> db> bt
>> Tracing pid 11 tid 13 td 0xfd0001634000
>> db_trace_self() at db_stack_trace+0xf8
>> pc = 0x0075fdac  lr = 0x00103e78
>> sp = 0x00011eca89b0  fp = 0x00011eca89e0
>> 
>> db_stack_trace() at db_command+0x228
>> pc = 0x00103e78  lr = 0x00103af0
>> sp = 0x00011eca89f0  fp = 0x00011eca8ad0
>> 
>> db_command() at db_command_loop+0x58
>> pc = 0x00103af0  lr = 0x00103898
>> sp = 0x00011eca8ae0  fp = 0x00011eca8b00
>> 
>> db_command_loop() at db_trap+0xf4
>> pc = 0x00103898  lr = 0x00106c0c
>> sp = 0x00011eca8b10  fp = 0x00011eca8d30
>> 
>> db_trap() at kdb pc = 0x00106c0c  lr = 0x00463b0c
>> sp = 0x00011eca8d40  fp = 0x00011eca8df0
>> 
>> kdb_trap() at do_el1h_sync+0xf4
>> pc = 0x00463b0c  lr = 0x0077b448
>> sp = 0x00011eca8e00  fp = 0x00011eca8e30
>> 
>> do_el1h_sync() at handle_el1h_sync+0x78
>> pc = 0x0077b448  lr = 0x00762878
>> sp = 0x00011eca8e40  fp = 0x00011eca8f50
>> 
>> handle_el1h_sync() at kdb_enter+0x34
>> pc = 0x00762878  lr = 0x00463168
>> sp = 0x00011eca8f60  fp = 0x00011eca8ff0
>> 
>> kdb_enter() at vpanic+0x1b0
>> pc = 0x00463168  lr = 0x00417a74
>> sp = 0x00011eca9000  fp = 0x00011eca90b0
>> 
>> vpanic() at panic+0x44
>> pc = 0x00417a74  lr = 0x004178c0
>> sp = 0x00011eca90c0  fp = 0x00011eca9140
>> 
>> panic() at __stack_chk_fail+0x10
>> pc = 0x004178c0  lr = 0x0044ab6c
>> sp = 0x00011eca9150  fp = 0x00011eca9150
>> 
>> __stack_chk_fail() at putchar+0x2bc
>> pc = 0x0044ab6c  lr = 0x00469ce8
>> sp = 0x00011eca9160  fp = 0x00011eca91e0
>> 
>> putchar() at 0x106
>> pc = 0x00469ce8  lr = 0x0106
>> sp = 0x00011eca91f0  fp = 0x
>> 
>> db> show proc 11
>> Process 11 (idle) at 0xfd000163:
>> state: NORMAL
>> uid: 0  gids: 0
>> parent: pid 0 at 0x010fae40
>> ABI: null
>> reaper: 0x010fae40 reapsubtree: 11
>> sigparent: 20
>> vmspace: 0x01109200
>>   (map 0x01109200)
>>   (map.pmap 0x011092c0)
>>   (pmap 0x01109320)
>> threads: 48
>> 13   Run CPU -1  [idle: cpu0]
>> 14   Run CPU 1   [idle: cpu1]
>> 15   Run CPU 2   [idle: cpu2]
>> 16   Run CPU 3   [idle: cpu3]
>> 17   Run CPU 4   [idle: cpu4]
>> 18   Run CPU 5   [idle: cpu5]
>> 19   Run CPU 6   [idle: cpu6]
>> 100010   Run CPU 7   [idle: cpu7]
>> 100011   Run CPU 8   [idle: cpu8]
>> 100012   CanRun  [idle: cpu9]
>> 100013   Run CPU 10  [idle: cpu10]
>> 100014   Run CPU 11  [idle: cpu11]
>> 100015   Run CPU 12  [idle: cpu12]
>> 100016   Run CPU 13  [idle: cpu13]
>> 100017   Run CPU 14  [idle: cpu14]
>> 100018   Run CPU 15  [idle: cpu15]
>> 100019   Run CPU 16  [idle: cpu16]
>> 100020   Run CPU 17  [idle: cpu17]
>> 100021   Run CPU 18  [idle: cpu18]
>> 100022   Run CPU 19  [idle: cpu19]
>> 100023   Run CPU 20  [idle: cpu20]
>> 100024   Run CPU 21  [idle: cpu21]
>> 100025   Run CPU 22  [idle: cpu22]
>> 100026   Run CPU 23  [idle: cpu23]
>> 100027   Run CPU 24  [idle: cpu24]
>> 100028   Run CPU 25  [idle: cpu25]
>> 100029   Run CPU 26  [idle: cpu26]
>> 100030

Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28))

[Andrew Turner]

> On 7 Mar 2022, at 15:13, Mark Johnston  wrote:
> ...
> A (the?) problem is that the compiler is treating "pc" as an alias
> for x18, but the rmlock code assumes that the pcpu pointer is loaded
> once, as it dereferences "pc" outside of the critical section.  On
> arm64, if a context switch occurs between the store at _rm_rlock+144 and
> the load at +152, and the thread is migrated to another CPU, then we'll
> end up using the wrong CPU ID in the rm->rm_writecpus test.
> 
> I suspect the problem is unique to arm64 as its get_pcpu()
> implementation is different from the others in that it doesn't use
> volatile-qualified inline assembly.  This has been the case since
> https://cgit.freebsd.org/src/commit/?id=63c858a04d56529eddbddf85ad04fc8e99e73762
>  
> 
> .
> 
> I haven't been able to reproduce any crashes running poudriere in an
> arm64 AWS instance, though.  Could you please try the patch below and
> confirm whether it fixes your panics?  I verified that the apparent
> problem described above is gone with the patch.

Alternatively (or additionally) we could do something like the following. There 
are only a few MI users of get_pcpu with the main place being in rm locks.

diff --git a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h
index 09f6361c651c..59b890e5c2ea 100644
--- a/sys/arm64/include/pcpu.h
+++ b/sys/arm64/include/pcpu.h
@@ -58,7 +58,14 @@ struct pcpu;

 register struct pcpu *pcpup __asm ("x18");

-#defineget_pcpu()  pcpup
+static inline struct pcpu *
+get_pcpu(void)
+{
+   struct pcpu *pcpu;
+
+   __asm __volatile("mov   %0, x18" : "=&r"(pcpu));
+   return (pcpu);
+}

 static inline struct thread *
 get_curthread(void)

Andrew

Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28))

[Andrew Turner]

> On 7 Mar 2022, at 19:04, Mark Johnston  wrote:
> 
> On Mon, Mar 07, 2022 at 10:03:51AM -0800, Mark Millard wrote:
>> 
>> 
>> On 2022-Mar-7, at 08:45, Mark Johnston  wrote:
>> 
>>> On Mon, Mar 07, 2022 at 04:25:22PM +, Andrew Turner wrote:
>>>> 
>>>>> On 7 Mar 2022, at 15:13, Mark Johnston  wrote:
>>>>> ...
>>>>> A (the?) problem is that the compiler is treating "pc" as an alias
>>>>> for x18, but the rmlock code assumes that the pcpu pointer is loaded
>>>>> once, as it dereferences "pc" outside of the critical section.  On
>>>>> arm64, if a context switch occurs between the store at _rm_rlock+144 and
>>>>> the load at +152, and the thread is migrated to another CPU, then we'll
>>>>> end up using the wrong CPU ID in the rm->rm_writecpus test.
>>>>> 
>>>>> I suspect the problem is unique to arm64 as its get_pcpu()
>>>>> implementation is different from the others in that it doesn't use
>>>>> volatile-qualified inline assembly.  This has been the case since
>>>>> https://cgit.freebsd.org/src/commit/?id=63c858a04d56529eddbddf85ad04fc8e99e73762
>>>>>  
>>>>> <https://cgit.freebsd.org/src/commit/?id=63c858a04d56529eddbddf85ad04fc8e99e73762>
>>>>> .
>>>>> 
>>>>> I haven't been able to reproduce any crashes running poudriere in an
>>>>> arm64 AWS instance, though.  Could you please try the patch below and
>>>>> confirm whether it fixes your panics?  I verified that the apparent
>>>>> problem described above is gone with the patch.
>>>> 
>>>> Alternatively (or additionally) we could do something like the following. 
>>>> There are only a few MI users of get_pcpu with the main place being in rm 
>>>> locks.
>>>> 
>>>> diff --git a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h
>>>> index 09f6361c651c..59b890e5c2ea 100644
>>>> --- a/sys/arm64/include/pcpu.h
>>>> +++ b/sys/arm64/include/pcpu.h
>>>> @@ -58,7 +58,14 @@ struct pcpu;
>>>> 
>>>> register struct pcpu *pcpup __asm ("x18");
>>>> 
>>>> -#defineget_pcpu()  pcpup
>>>> +static inline struct pcpu *
>>>> +get_pcpu(void)
>>>> +{
>>>> +   struct pcpu *pcpu;
>>>> +
>>>> +   __asm __volatile("mov   %0, x18" : "=&r"(pcpu));
>>>> +   return (pcpu);
>>>> +}
>>>> 
>>>> static inline struct thread *
>>>> get_curthread(void)
>>> 
>>> Indeed, I think this is probably the best solution.

I’ve pushed the above to git in ed3066342660 & will MFC in a few days.

> 
> Thinking a bit more, even with that patch, code like this may not behave
> the same on arm64 as on other platforms:
> 
> critical_enter();
> ptr = &PCPU_GET(foo);
> critical_exit();
> bar = *ptr;
> 
> since as far as I can see the compiler may translate it to
> 
> critical_enter();
> critical_exit();
> bar = PCPU_GET(foo);

If we think this will be a problem we could change the PCPU_PTR macro to use 
get_pcpu again, however I only see two places it’s used in the MI code in 
subr_witness.c and kern_clock.c. Neither of these appear to be problematic from 
a quick look as there are no critical sections, although I’m not familiar 
enough with the code to know for certain.

Andrew

Re: RockPRO64 exception 22 esr_el1 8a000000

[Andrew Turner]

> On 19 May 2022, at 07:26, Poul-Henning Kamp  wrote:
> 
> I managed to capture the full console output this time:
> 
>   Fatal data abort:
> x0:0
> x1:6
> x2:0
> x3:0
> x4:0
> x5: a000beeb9b98
> x6:   ff
> x7: a0c2e100
> x8: a000b79305a8
> x9:0
>x10:2
>x11:0
>x12:0
>x13:0
>x14: a0ce3700
>x15:0
>x16: e5cbfff8 (_DYNAMIC + 4a0)
>x17: 00589828 (sosend + 0)
>x18: e6707490 (ratelimit_v6 + a37280)
>x19:0
>x20: e6707518 (ratelimit_v6 + a37308)
>x21:0
>x22:0
>x23:   14
>x24:   40
>x25: e6707538 (ratelimit_v6 + a37328)
>x26:0
>x27:0
>x28: a00081055d3c
>x29: e6707490 (ratelimit_v6 + a37280)
> sp: e6707490
> lr: 00657724 (fib4_lookup + 40)
>elr:0
>   spsr: 6045
>far:0
>esr: 8604
>   panic: vm_fault failed: 0 error 1
>   cpuid = 4
>   time = 1652940940
>   KDB: stack backtrace:
>   db_trace_self() at db_trace_self
>   db_trace_self_wrapper() at db_trace_self_wrapper+0x30
>   vpanic() at vpanic+0x174
>   panic() at panic+0x44
>   data_abort() at data_abort+0x2c4
>   handle_el1h_sync() at handle_el1h_sync+0x10
>   --- exception, esr 0x8604
>   (null)() at 0
>   ip_output() at ip_output+0x9a4
>   udp_send() at udp_send+0xb5c
>   sosend_dgram() at sosend_dgram+0x4a4
>   sosend() at sosend+0x2c
>   wg_send() at wg_send+0x108
>   wg_deliver_out() at wg_deliver_out+0x17c
>   gtaskqueue_run_locked() at gtaskqueue_run_locked+0x17c
>   gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0x130
>   fork_exit() at fork_exit+0x88
>   fork_trampoline() at fork_trampoline+0x14
>   KDB: enter: panic
>   [ thread pid 0 tid 100280 ]
>   Stopped at  kdb_enter+0x40: undefined   f907827f
>   db> 

This looks like the kernel is jumping to a NULL pointer.

Looking at fib4_lookup + 40 on a recent kernel leads me to believe the issue is 
likely due to dp->f being invalid.

Andrew