Re: I get odd time reports from poudriere on armv7 system, under a (non-debug) main [so: 14] FreeBSD.

[Ian Lepore]

On Sun, 2021-09-26 at 02:27 -0700, Mark Millard via freebsd-current
wrote:
> On 2021-Sep-25, at 23:25, Mark Millard  wrote:
> 
> 
> [...]
> if (argc == 3 && strcmp(argv[2], "-nsec") == 0)
> printf("%ld.%ld\n", ts.tv_sec, ts.tv_nsec);

There are two problems with this, both the seconds and nanos are
printed incorrectly.  The correct incantation would be

  printf("%jd.%09ld\n", (intmax_t)ts.tv_sec, ts.tv_nsec);

-- Ian

Re: PATH: /usr/local before or after /usr ?

[Ian Lepore]

On Fri, 2021-07-16 at 09:01 -0600, Alan Somers wrote:
> FreeBSD has always placed /usr/local/X after /usr/X in the default PATH.
> AFAICT that convention began with SVN revision 37 "Initial import of 386BSD
> 0.1 othersrc/etc".  Why is that?  It would make sense to me that
> /usr/local/X should come first.  That way programs installed from ports can
> override FreeBSD's defaults.  Is there a good reason for this convention,
> or is it just inertia?
> -Alan

I have a hierarchy on my machines rooted at /local and /local/bin is
before /bin and /usr/bin in my PATH, so I can override system tools
when I explicitly want to without suffering any problems of an
unexpected override from installing a port or package.

If you're using ports as a development environment to work on a new
gstat replacement, you could do something similar and put PREFIX=/local
in your port makefile while you're developing on it.

-- Ian

Re: Files in /etc containing empty VCSId header

[Ian Lepore]

On Wed, 2021-06-09 at 18:54 +1000, Peter Jeremy via freebsd-current
wrote:
> On 2021-Jun-08 17:13:45 -0600, Ian Lepore  wrote:
> > On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote:
> > > There is a command for that which does or use to do a pretty
> > > decent job of it called whereis(1).
> 
> Thanks.  That looks useful.
> 
> > revolution > whereis ntp.conf
> > ntp.conf:
> > revolution > whereis netif
> > netif:
> > revolution > whereis services
> > services:
> > 
> > So how does that help me locate the origin of these files in the
> > source
> > tree?
> 
> It works for me™:
> server% whereis ntp.conf
> ntp.conf: /usr/src/usr.sbin/ntp/ntpd/ntp.conf
> server% whereis netif   
> netif: /usr/src/libexec/rc/rc.d/netif
> server% whereis services
> services: /usr/src/contrib/unbound/services
> 
> Is your source tree somewhere other than /usr/src?
> 

My /usr/src is a symlink to the actual source tree on a different
filesystem (but it is the source tree the running system was built
from).  It seems odd that that would make whereis(1) not work.

-- Ian

Re: Files in /etc containing empty VCSId header

[Ian Lepore]

On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote:
> > On Tue, 8 Jun 2021 09:41:34 +
> > Mark Linimon  wrote:
> > 
> > > On Mon, Jun 07, 2021 at 01:58:01PM -0600, Ian Lepore wrote:
> > > > Sometimes it's a real interesting exercise to figure out where
> > > > a
> > > > file on your runtime system comes from in the source world.  
> 
> There is a command for that which does or use to do a pretty
> decent job of it called whereis(1).
> 

revolution > whereis ntp.conf
ntp.conf:
revolution > whereis netif
netif:
revolution > whereis services
services:

So how does that help me locate the origin of these files in the source
tree?

-- Ian

> > > 
> > > A tangential problem I trip over is "what is on this SD card?"
> > > 
> > > It generally takes me 5-10 minutes to remember:
> > > 
> > >   strings //boot/kernel/kernel | tail
> > > 
> > > AFIAK it's the only way to be sure; nothing in //* seems
> > > to have that data.
> > > 
> > > (Yes, in theory they all live in their own little box each of
> > > which is labeled but things happen ...)
> > > 
> > 
> > I use locate for this kind of search, e.g.
> > 
> > locate netoptions
> > /etc/rc.d/netoptions
> > /usr/src/libexec/rc/rc.d/netoptions
> > 
> > -- 
> > Gary Jennejohn
> > 
> > 
> 
> 

Re: Files in /etc containing empty VCSId header

[Ian Lepore]

On Tue, 2021-06-08 at 13:47 +0200, Gary Jennejohn wrote:
> On Tue, 8 Jun 2021 09:41:34 +
> Mark Linimon  wrote:
> 
> > On Mon, Jun 07, 2021 at 01:58:01PM -0600, Ian Lepore wrote:
> > > Sometimes it's a real interesting exercise to figure out where a
> > > file on your runtime system comes from in the source world.  
> > 
> > A tangential problem I trip over is "what is on this SD card?"
> > 
> > It generally takes me 5-10 minutes to remember:
> > 
> >   strings //boot/kernel/kernel | tail
> > 
> > AFIAK it's the only way to be sure; nothing in //* seems
> > to have that data.
> > 
> > (Yes, in theory they all live in their own little box each of
> > which is labeled but things happen ...)
> > 
> 
> I use locate for this kind of search, e.g.
> 
> locate netoptions
> /etc/rc.d/netoptions
> /usr/src/libexec/rc/rc.d/netoptions
> 

Not a useful technique on my machine:

revolution > locate netoptions | wc -l
 192

I have dozens of build chroots for various products for $work.

-- Ian

Re: Files in /etc containing empty VCSId header

[Ian Lepore]

On Mon, 2021-06-07 at 13:53 -0600, Warner Losh wrote:
> On Mon, Jun 7, 2021 at 12:26 PM John Baldwin  wrote:
> 
> > On 5/20/21 9:37 AM, Michael Gmelin wrote:
> > > Hi,
> > > 
> > > After a binary update using freebsd-update, all files in /etc
> > > contain
> > > "empty" VCS Id headers, e.g.,
> > > 
> > >  $ head  /etc/nsswitch.conf
> > >  #
> > >  # nsswitch.conf(5) - name service switch configuration file
> > >  # $FreeBSD$
> > >  #
> > >  group: compat
> > >  group_compat: nis
> > >  hosts: files dns
> > >  netgroup: compat
> > >  networks: files
> > >  passwd: compat
> > > 
> > > After migrating to git, I would've expected those to contain
> > > something
> > > else or disappear completely. Is this expected and are there any
> > > plans
> > > to remove them completely?
> > 
> > I believe we might eventually remove them in the future, but doing
> > so
> > right now would introduce a lot of churn and the conversion to git
> > had enough other churn going on.
> > 
> 
> We'd planned on not removing things that might be merged to stable/12
> since
> those releases (12.3 only I think) will be built out of svn. We'll
> likely
> start to
> remove things more widely as the stable/12 branch reaches EOL and
> after.
> 
> Warner

It would be really nice if, instead of just deleting the $FreeBSD$
markers, they could be replaced with the path/filename of the file in
the source tree.  Sometimes it's a real interesting exercise to figure
out where a file on your runtime system comes from in the source world.
All the source tree layout changes that happened for packaged-base
makes it even more interesting.

-- Ian

Re: Arm64 Tier 1 FreeBSD 13 Phones

[Ian Lepore]

On Sat, 2021-04-10 at 04:07 -0400, grarpamp wrote:
> FreeBSD Phones...
> 
> https://en.wikipedia.org/wiki/Librem_5
> NXP i.MX 8M Quad core Cortex-A53, 64bit ARM
> 
> https://en.wikipedia.org/wiki/PinePhone
> Allwinner A64 ARM Quad core Cortex-A53
> 
> https://www.youtube.com/watch?v=c32-QOrI4cw
> https://www.youtube.com/watch?v=fCKMxzz9cjs
> https://www.youtube.com/watch?v=lVJo9faE1fM
> https://www.youtube.com/watch?v=NV0RnWorPpQ
> 
> Happy hacking :)
> 

Dream on.  FreeBSD lacks the power-management infrastructure to run on
battery-operated devices.  The amount of work required to get there
from here is almost unimaginable, and there are no big companies
funding that kind of work (which is how linux got all that code).

-- 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: Rationalizing sed -i/-I (in-place editing) argument handling

[Ian Lepore]

On Mon, 2021-03-08 at 15:13 -0500, Ed Maste wrote:
> A relatively minor but longstanding incompatibility between FreeBSD
> and many other systems is the way sed handles backup files for
> in-place editing -- sed's -I and -i options. GNU sed and other BSDs
> accept an optional argument: -I.bak will save a backup file with a
> .bak extension, and -I with no argument will not create a backup
> file.
> FreeBSD currently accepts either -I.bak or -I .bak to save a backup
> with the given extension, and -I "" (an empty argument) to specify no
> backup.
> 
> I've been tripped up by this in the past and I know many others have.
> Most recently tobik@  filed PR 254091 for this. Now, I think a single
> change to make -i/-I to be compatible with other sed implementations
> in one step is too much of a POLA violation, but I think it can
> reasonably be done in stages:
> 
> 1. Update the man page to indicate that -i/-I should not have a space
> between the flag and the extension. This is compatible with current
> FreeBSD sed, other BSDs sed, GNU sed, and my proposed changes below.
> No backup is still a special case and remains as -I "".
> 
> I've opened https://reviews.freebsd.org/D29128 with proposed man page
> changes.
> 
> 2. Continue accepting -I .bak, but emit a warning suggesting the use
> of -I.bak instead.
> 
> 3. Change -I/-i to getopt optional arguments, but keep a special case
> for -I/-i "". At this point -I .bak becomes invalid as with other
> seds, and specifying no backup can be done with either -I "" or -I
> with no argument. This relies on an empty argument having no other
> sensible interpretation.
> 
> 4. Continue accepting -I "" to specify no backup, but emit a warning
> suggesting the use of -I with no argument.
> 
> 5. Retire the special case for -I "".
> 
> These steps could be done over an extended period of time (such as
> one
> major release to another) - this is most important between steps 2
> and
> 3.
> 
> Please let me know what you think, and if there's something I've
> missed.
> 

As someone who has to take care of common software that runs on
everything from freebsd 8 through -current, I HATE the very idea of
this.  If we keep whittling away at the backwards compatibility freebsd
is so famous for, I'll have abosolutely zero arguments left for why
$work shouldn't just switch to the much more popular and better-
supported linux.

I also hate the idea of requiring no space between -I and its related
value.  That seems like a huge POLA violation compared to how virtually
every other command's options and arguments work.

-- 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: Panic after updating

[Ian Lepore]

On Wed, 2021-01-13 at 10:37 +0100, Jakob Alvermark wrote:
> On 1/13/21 10:07 AM, Hans Petter Selasky wrote:
> > > 
> > > Yes! That works! Thank you!
> > > 
> > 
> > See:
> > 
> > 
https://cgit.freebsd.org/src/commit/?id=bafb682656724d06045fa494efb83a4312036f1f
> >  
> > 
> 
> 
> Nice! Thanks again!
> 
> 
> Jakob
> 

Indeed, thank you for taking care of this, my $job has me way too busy
these days.

-- 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: Panic after updating

[Ian Lepore]

On Tue, 2021-01-12 at 19:56 +0100, Hans Petter Selasky wrote:
> On 1/12/21 7:45 PM, Ian Lepore wrote:
> > > > -   for (int i = 0; i <= sc->sc_npins; i++) {
> > > > +   for (int i = 0; i != sc->sc_npins; i++) {
> > > >  mtx_destroy(>sc_pin_intr[i].mtx);
> > > >  free(>sc_pin_intr[i].pin, M_GPIOC);
> > > >  }
> > > 
> > > --HPS
> > > 
> > 
> > If that is the problem, I'd rather see it fixed by using the
> > idiomatic
> > i < sc->sc_npins rather than the non-standard != test.  (But I
> > don't
> > feel strongly enough about it to learn how to use git and commit
> > the
> > fix myself.)
> 
> Hi Ian,
> 
> I think it is more serious that the iteration variable is declared 
> inside the for-loop :-)
> 
> At least it is pretty obvious that the array written is one element
> too 
> small. I've always used != instead of <= in for-loops. But if there
> is a 
> certain style in there, I'm good with < too, though I've always seen
> < 
> as an overhead compared to != , because to implement < you need a 
> subtraction, while != is just a comparison ...
> 
> --HPS

I thought we recently changed (or at least discussed changing) style(9)
to allow for that sort of loop-iter-var declaration.

On most of the chips I know assembly language for (mostly risc chips),
there is no difference between a comparison and a subtraction at the
chip-instruction level.  That is, at the chip level, comparision
instructions are typically implemented as a subtraction that sets
condition code bits but doesn't store the result back to a register.

-- 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: Panic after updating

[Ian Lepore]

On Tue, 2021-01-12 at 18:10 +0100, Hans Petter Selasky wrote:
> On 1/12/21 2:46 PM, Hans Petter Selasky wrote:
> > On 1/12/21 2:40 PM, Jakob Alvermark wrote:
> > > 
> > > On 1/12/21 2:16 PM, Hans Petter Selasky wrote:
> > > > On 1/12/21 1:43 PM, Jakob Alvermark wrote:
> > > > > 
> > > > > On 1/12/21 12:54 PM, Hans Petter Selasky wrote:
> > > > > > On 1/12/21 12:32 PM, Jakob Alvermark wrote:
> > > > > > > Alright, after a new bisect run I got a different result,
> > > > > > > so I 
> > > > > > > most likely did something wrong the first time.
> > > > > > > 
> > > > > > > ff3468ac94597efdcbc56f372528dfc98b114dac is the first bad
> > > > > > > commit
> > > > > > > commit ff3468ac94597efdcbc56f372528dfc98b114dac
> > > > > > > Author: Ian Lepore 
> > > > > > > Date:   Sat Dec 12 18:34:15 2020 +
> > > > > > > 
> > > > > > >  Provide userland notification of gpio pin changes
> > > > > > > ("userland 
> > > > > > > gpio interrupts").
> > > > > > > 
> > > > > > > 
> > > > > > > Maybe more likely this is causing the panic?
> > > > > > 
> > > > > > Doesn't make sense :-(
> > > > > > 
> > > > > > Can you try to fetch the latest 13-current as of now and
> > > > > > re-build 
> > > > > > the kernel? I noticed some issues myself which got fixed.
> > > > > 
> > > > > 
> > > > > I did that, still panics the same way.
> > > > > 
> > > > > But, the commit above is about gpio, and I do have 
> > > > > 'bytgpio_load="YES"' in my /boot/loader.conf
> > > > > 
> > > > > If I boot the kernel without that it works.
> > > > > 
> > > > > 'kldload bytgpio' panics the machine.
> > > > > 
> > > > 
> > > > Could you screenshot the panic backtrace after kldload of
> > > > bytegpio ?
> > > 
> > > Sure:
> > > 
> > > panic: vm_fault_lookup: fault on nofault entry, addr:
> > > 0xfe00c96c2000
> > > cpuid = 1
> > > time = 1610458544
> > > KDB: stack backtrace:
> > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
> > > 0xfe00c7306140
> > > vpanic() at vpanic+0x181/frame 0xfe00c7306190
> > > panic() at panic+0x43/frame 0xfe00c73061f0
> > > vm_fault() at vm_fault+0x142d/frame 0xfe00c73062f0
> > > vm_fault_trap() at vm_fault_trap+0xb1/frame 0xfe00c7306340
> > > trap_pfault() at trap_pfault+0x1f6/frame 0xfe00c73063a0
> > > trap() at trap+0x280/frame 0xfe00c73064b0
> > > calltrap() at calltrap+0x8/frame 0xfe00c73064b0
> > > --- trap 0xc, rip = 0x80c27d08, rsp = 0xfe00c7306580,
> > > rbp 
> > > = 0xfe00c7306580 ---
> > > lock_init() at lock_init+0xf8/frame 0xfe00c7306580
> > > _mtx_init() at _mtx_init+0x70/frame 0xfe00c73065a0
> > > gpioc_attach() at gpioc_attach+0x139/frame 0xfe00c7306620
> > > device_attach() at device_attach+0x3dd/frame 0xfe00c7306670
> > > bus_generic_attach() at bus_generic_attach+0x4b/frame
> > > 0xfe00c73066a0
> > > gpiobus_attach_bus() at gpiobus_attach_bus+0x44/frame
> > > 0xfe00c73066c0
> > > bytgpio_attach() at bytgpio_attach+0x1f7/frame 0xfe00c7306710
> > > device_attach() at device_attach+0x3dd/frame 0xfe00c7306760
> > > device_probe_and_attach() at device_probe_and_attach+0x41/frame 
> > > 0xfe00c7306790
> > > acpi_driver_added() at acpi_driver_added+0xaa/frame
> > > 0xfe00c73067c0
> > > devclass_driver_added() at devclass_driver_added+0x3c/frame 
> > > 0xfe00c7306800
> > > devclass_add_driver() at devclass_add_driver+0x13d/frame 
> > > 0xfe00c7306840
> > > module_register_init() at module_register_init+0xa7/frame 
> > > 0xfe00c7306870
> > > linker_load_module() at linker_load_module+0xbca/frame
> > > 0xfe00c7306b80
> > > kern_kldload() at kern_kldload+0xbb/frame 0xfe00c7306bd0
> > > sys_kldload() at sys_kldload+0x5b/frame 0xfe00c7306c00
> > > amd64_syscall() at amd64_syscall+0x111/frame 0xfe00c7306d30
> > > fast_syscall_common() at fa

Re: Enabling AESNI by default

[Ian Lepore]

On Thu, 2020-12-31 at 14:09 -0800, Rodney W. Grimes wrote:
> > We've had the AESNI module for quite a few years now, and it has
> > not
> > caused any problems.
> > 
> > I am wondering if there are any objections to including it in
> > GENERIC,
> > so that users get the benefit without having to have the "tribal
> > knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC,
> > etc),
> > you need to load aesni.ko'
> > 
> > Userspace crypto that uses openssl or similar libraries is already
> > taking advantage of these CPU instructions if they are available,
> > by
> > excluding this feature from GENERIC we are just causing the "out of
> > the
> > box" experience to by very very slow for crypto.
> > 
> > For example, writing 1MB blocks to a GELI encrypted swap-backed
> > md(4)
> > device:
> > 
> > with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz
> > 
> > fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --
> > bs=1m
> > --numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync
> > --group_reporting --fallocate=none --runtime=60 --time_based
> > 
> > 
> > stock:
> > write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec)
> > 
> > with aesni.ko loaded:
> > write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec)
> > 
> > 
> > Does anyone have a compelling reason to deny our users the 5x
> > speedup?
> 
> Its for ever dead code on a large number of machines that do not have
> the hardware for it.  I know that is a decreasing set, but imho it
> would be better to somehow ONLY load the module if you had CPU
> support for it.  The down side is that detection would probably have
> to be in the laoder as this code can be used very early on.
> 

Not nearly so much as the code to support the PC/AT RTC and i8254
hardware as kernel eventtimers is dead code, probably today on
virtually every x86 machine that runs freebsd.

In other words, if you want to start worrying about mostly-unused code,
aesni is not the place to start.

-- 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: rc.d/zpool runs before ada(4) attaches

[Ian Lepore]

On Tue, 2020-12-01 at 16:22 +0100, Ronald Klop wrote:
>  
> Van: Harry Schmalzbauer 
> Datum: dinsdag, 1 december 2020 12:51
> Aan: Ronald Klop , FreeBSD Current <
> freebsd-current@freebsd.org>
> Onderwerp: Re: rc.d/zpool runs before ada(4) attaches
> > 
> > Am 01.12.2020 um 10:33 schrieb Ronald Klop:
> > :
> > :
> > :
> > > > One machine fails importing zpool because the correponding
> > > > vdevs >> (ada0-ada2)
> > > > are not available at the time rc.d/zpool runs.
> > > > 
> > > > 
> > > > Adhoc  I'm not aware of any rc(8) vs. driver awareness.
> > > > Is there any?
> > > > 
> > > > Suggestions how to fix else than 'sleep 1'?
> > > > 
> > > > Thanks,
> > > > 
> > > > -harry
> > > > 
> > > > P.S.: ahci(4) is compiled into kernel, machine is a HPE U48
> > > > (Gen 10 >> plus MicroServer), zfsloader loads root_MFS kernel
> > > > module
> > > > 
> > > 
> > > 
> > > There have been some changes to etc/rc.d/zpool in September.
> > > Do you have the latest version? Compare with:
> > > 
https://github.com/freebsd/freebsd/blob/master/libexec/rc/rc.d/zpool
> > > or
> > > 
https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/zpool?revision=365354=markup
> > >  >
> > > 
> > > Otherwise it would be helpful for readers if you could post some
> > > logs > which indicate what is happening.
> > > /var/run/dmesg.boot or the output of "dmesg"
> > > Part of /var/log/messages
> > > Part of /var/log/console.log if it exists.
> > > 
> > 
> > Thanks, I'm on -current from view days ago.
> > The problem is that cam(4) is still probing devices, when
> > rc.d/zpool runs, since mount_root_from succeeded, because it is a
> > RAM disk, so succeeds independent of any real drive/controller
> > probing.
> > I can imagine of other seldom edgecases hitting the issue too.
> > 
> > So my proposed patch, working for me, looks like this:
> > Index: libexec/rc/rc.d/zpool
> > ===
> > --- libexec/rc/rc.d/zpool   (revision 368202)
> > +++ libexec/rc/rc.d/zpool   (working copy)
> > @@ -18,8 +18,16 @@
> > 
> >   zpool_start()
> >   {
> > -   local cachefile
> > +local cachefile n=0 camlist=`camcontrol devlist -v`
> > 
> > +   # Wait for cam(4) devices attaching, 4 times at max by
> > increasing
> > +   # 1s each (10s max in total)
> > +while [ X"${camlist#*target*lun*probe}" != X"${camlist}"
> > ]; do
> > +   [ $n -lt 4 ] || break
> > +   sleep $((n+=1))
> > +   camlist=`camcontrol devlist -v`
> > +   done
> > +
> >  for cachefile in /etc/zfs/zpool.cache
> > /boot/zfs/zpool.cache; do
> >  if [ -r $cachefile ]; then
> >  zpool import -c $cachefile -a -N && break
> > 
> > best,
> > -harry
> > 
> > 
> > 
> 
> You can define these in /boot/loader.conf:
> #kern.cam.boot_delay="1" # Delay (in ms) of root mount for CAM
> bus
> #kern.cam.scsi_delay="2000" # Delay (in ms) before probing SCSI
> 
> Maybe that helps.
> 
> Ronald.
> 

Those settings control waiting before mounting root.  Harry's problem
is that root is mounted quickly, before other drives are ready for zfs.
 
The zpool script waits for 'disks'.  It would be nice if the cam
subsystem had something like a sysctl it set to indicate when initial
probing for disks was done, then there could be an rc.d/camprobe script
with 'PROVIDE: disks' which waits for the probing to complete.

-- 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: Deprecating ftpd in the FreeBSD base system?

[Ian Lepore]

On Thu, 2020-09-17 at 12:49 -0700, John-Mark Gurney wrote:
> Ian Lepore wrote this message on Thu, Sep 17, 2020 at 09:01 -0600:
> > On Thu, 2020-09-17 at 18:43 +0400, Gleb Popov wrote:
> > > On Thu, Sep 17, 2020 at 6:05 PM Cy Schubert <
> > > cy.schub...@cschubert.com>
> > > wrote:
> > > 
> > > > I've been advocating removing FTP (and HTTP) from libfetch as
> > > > well.
> > > > People
> > > > should be using HTTPS only.
> > > > 
> > > 
> > > Isn't this a bit too much? I often find myself in need to
> > > download
> > > something starting with "http://; or "ftp://; and use fetch for
> > > this.
> > 
> > Indeed, we have products which rely on this ability in libfetch and
> > we
> > have to keep supporting them for many many years to come.
> > 
> > I hate it when someone imperiously declares [For security reasons]
> > "People should/shouldn't be using __".  You have no idea what
> > the
> > context is, and thus no ability to declare what should or shouldn't
> > be
> > used in that context.  For example, two embedded systems talking to
> > each other over a point to point link within a sealed device are
> > not
> > concerned about man in the middle attacks or other modern internet
> > threats.
> 
> And I really dislike when people want to make sure that their unique
> case that less than a percent of people would every hit blocks the
> security improvements for the majority of people...
> 
> I've given up on a number of security improvements in FreeBSD because
> of this attitude...
> 

Good.  Because what you call "improvements" I would probably call
"Imposing policy rather than providing tools."

I've don't complain about making defaults the safest choices available.
I complain about removing options completely because they're unsafe in
some circumstances according to some people.

-- 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: Deprecating ftpd in the FreeBSD base system?

[Ian Lepore]

On Thu, 2020-09-17 at 18:43 +0400, Gleb Popov wrote:
> On Thu, Sep 17, 2020 at 6:05 PM Cy Schubert <
> cy.schub...@cschubert.com>
> wrote:
> 
> > I've been advocating removing FTP (and HTTP) from libfetch as well.
> > People
> > should be using HTTPS only.
> > 
> 
> Isn't this a bit too much? I often find myself in need to download
> something starting with "http://; or "ftp://; and use fetch for this.
> 

Indeed, we have products which rely on this ability in libfetch and we
have to keep supporting them for many many years to come.

I hate it when someone imperiously declares [For security reasons]
"People should/shouldn't be using __".  You have no idea what the
context is, and thus no ability to declare what should or shouldn't be
used in that context.  For example, two embedded systems talking to
each other over a point to point link within a sealed device are not
concerned about man in the middle attacks or other modern internet
threats.

-- 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: Plans for git (was: Please check the current beta git conversions)

[Ian Lepore]

On Wed, 2020-09-02 at 14:45 -0400, Dan Langille wrote:
> On Wed, Sep 2, 2020, at 2:36 PM, Ian Lepore wrote:
> 
> > Seriously, Warner?
> 
> Yes, seriously. We are adults.  Act accordingly.
> 
> Don't be confused. I also thought the message he was replying to was out of 
> line.
> 
> > I applaud Steve's message as being the first one in this thread that
> > has any real value at all.  Unlike everyone else, he has clearly seen
> > what the basic problem is (zero communications about this impending
> > cutover to the people who need to work with it every day), and he
> > summarized it in a completely practical way.
> 
> We disagree.  The message could have been worded without being negative.
> 
> > This assumption that everyone knows how to use git is mind-boggling.  I
> > think I installed it once, a few years ago.  Then I uninstalled it
> > because of how abysmally hard it was to try to learn even a few
> > commands to do anything with it.
> 
> No, it's assumed you will learn. I did. We all can.
> 
> Please, we cooperate on this project. We don't attack, and yes, these were 
> attacks. 
> 
> > I guess Steve & I are a couple dinosaurs and the whole rest of the
> > freebsd user and committer community is laughing at our ignorance and
> > thinking "we don't need their contributions anyway, so let's just mock
> > them and move on."
> 
> I don't think so. I'm guessing I'm older and more set in my ways.
> 
> There are much better ways to communicate that in recent messages.
> 

How typical:  trim away ALL context of what's being discussed, then
claim that the material was offensive in some way after destroying the
contextual evidence that makes a lie of your claim.

-- 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: Plans for git (was: Please check the current beta git conversions)

[Ian Lepore]

On Wed, 2020-09-02 at 11:11 -0600, Warner Losh wrote:
> On Wed, Sep 2, 2020 at 10:47 AM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
> 
> > On Wed, Sep 02, 2020 at 12:14:08PM -0400, Ed Maste wrote:
> > > On Wed, 2 Sep 2020 at 02:31, Steve Kargl
> > >  wrote:
> > > > 
> > > > > A short intro on git for svn users:
> > > > > https://hackmd.io/ML5TSl8mQ5-27B5eqDf7YA?view
> > > > > 
> > > > 
> > > > ROTFL.  From the "short intro", 2nd sentence.
> > > > 
> > > > New committers are assumed to already be familiar with the
> > > > basic
> > > > operation of Git.  If not, start by reading the Git Book.
> > > 
> > > This doc started as a direct translation of the Subversion
> > > primer,
> > > which has as its first sentence:
> > > > New committers are assumed to already be familiar with the
> > > > basic
> > 
> > operation of Subversion. If not, start by reading the Subversion
> > Book.
> > > 
> > > As with the Subversion primer the doc is intended to provide a
> > > quick
> > > reference for day-to-day commands, but not act as a reference or
> > > introduction to the entire theory of operation of the associated
> > > VCS.
> > 
> > Like GCC, which did the svn to git dance at start of the year,
> > FreeBSD is throwing away a decade+ of corporate knowledge of
> > working with svn and /usr/src.  What is needed is a succinct
> > translation of the most common svn commands translated to git.
> > 
> > Checking out /usr/src as u...@freebsd.org
> > 
> >   svn checkout svn+ssh://u...@svn.freebsd.org/base/head /usr/src
> > 
> >   git ...
> > 
> > Checking out /usr/src without freebsd.org account
> > 
> >   svn checkout https://svn.freebsd.org/base/head
> > ${HOME}/freebsd/src
> > 
> >   git ...
> > 
> > Creating diff against updated head.
> > 
> >   svn update
> >   svn diff > patch.diff
> > 
> >   git ...
> > 
> > Adding a new file
> > 
> >   svn add /usr/src/libm/msun/src/_s_sinpi.c
> > 
> >   git ...
> > 
> > Committing a change to /usr/src
> > 
> >   svn update
> >   svn diff  | more (everyone does one last check,
> > right?)
> >   svn commit 
> > 
> >   git ...
> > 
> 
> This is an insultingly stupid comment to make. We don't need people
> to say
> the obvious.
> 
> This sort of comment isn't helpful. People will just ignore you if
> you make
> too many of them like it.
> 

Seriously, Warner?

I applaud Steve's message as being the first one in this thread that
has any real value at all.  Unlike everyone else, he has clearly seen
what the basic problem is (zero communications about this impending
cutover to the people who need to work with it every day), and he
summarized it in a completely practical way.

This assumption that everyone knows how to use git is mind-boggling.  I
think I installed it once, a few years ago.  Then I uninstalled it
because of how abysmally hard it was to try to learn even a few
commands to do anything with it.

I guess Steve & I are a couple dinosaurs and the whole rest of the
freebsd user and committer community is laughing at our ignorance and
thinking "we don't need their contributions anyway, so let's just mock
them and move on."

-- 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: Undeletable files after kyua test runs

[Ian Lepore]

On Mon, 2020-06-29 at 21:08 +0200, Gordon Bergling wrote:
> On Mon, Jun 29, 2020 at 11:58:47AM -0700, Rodney W. Grimes wrote:
> > > On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote:
> > > > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling <
> > > > g...@freebsd.org> wrote:
> > > > > I recently stumbled across undeletable files that are
> > > > > generated by kyua
> > > > > test runs,
> > > > > for example
> > > > > 
> > > > > -rwxr-xr-x  1 root  wheel  0 May  9 13:10
> > > > > /tmp/kyua.aB4q62/8676/work/fileforaudit
> > > > > 
> > > > > I haven't yet identified the test that generate those files,
> > > > > but it is
> > > > > impossible
> > > > > to delete them. I have clear_tmp_enable="YES" set in the
> > > > > /etc/rc.conf, but
> > > > > on every boot the system argues that these file aren't
> > > > > deletable.
> > > > > I tried to 'rm -rf' them by hand but, even this wasn't
> > > > > possible. I have
> > > > > looked for
> > > > > any extend attributes, but I didn't find any.
> > > > > 
> > > > > Has anyone an idea how this is possible and may how these
> > > > > files can be
> > > > > deleted?
> > > > 
> > > > Have you done 'ls -o' to check for flags like schg?
> > > > --
> > > > Kevin Oberman, Part time kid herder and retired Network
> > > > Engineer
> > > > E-mail: rkober...@gmail.com
> > > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> > > 
> > > Argh, I haven't thought about chflags for quite some time. The
> > > chflags
> > > bit was set and after an
> > > 
> > > # find /tmp/ -type f -exec chflags -R 0 {} \;
> > 
> >^^Only files  ^^ meaningless when chflags is
> > given ONLY files
> > 
> > You probably could of done:
> > chflags -R 0 /tmp/
> 
> Okay, I am currently working on an update for clear_tmp_enable="YES"
> to include
> a check like this. I would think that an rc option like this should
> delete 
> everything in /tmp.
> 

I disagree.  One of the few things those immutable flags are good for
is protecting files from things like an rc script or other automation
that deletes files.  Those flags are typically set and maintained by
users and admins, and automation should not change them in order to
delete files.

The real fix we need is for the kyua tests to properly clean up after
themselves, including fixing the flags on temporary files created or
used by the tests, and then deleting them.

-- Ian 

>  
> > > I was able to finally delete them.
> > > 
> > > Thanks for the fast respone,
> > > 
> > > Gordon
> 
> --Gordon
> ___
> 

___
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: В ответ на: vnc can't connect to socket

[Ian Lepore]

On Sun, 2020-06-21 at 19:54 +0200, Michael Tuexen wrote:
> > On 21. Jun 2020, at 19:40, Ian Lepore  wrote:
> > 
> > On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote:
> > > > On 21. Jun 2020, at 14:28, Kostya Berger  > > > >
> > > > wrote:
> > > > 
> > > > Ok, it turns out, it gives the previously mentioned error only
> > > > if I
> > > > use VNC server string 0.0.0.0:5900 (as I always did). in my VNC
> > > > client.But when replaced with127.0.0.1:5900it connects all
> > > > right.
> > > 
> > > I don't hink 0.0.0.0 is a valid destination address you can use
> > > in
> > > connect(). Using 127.0.0.1 should
> > > be fine.
> > > 
> > > I guess, https://svnweb.freebsd.org/changeset/base/361752 is the
> > > relevant commit here.
> > > 
> > 
> > *BSD has always accepted 0 as a synonym for localhost (and iirc, linux
> > does not).  If this no longer works, it's a regression which is going
> > to cause existing applications and scripts to fail.  At the very least
> > it deserves an entry in UPDATING.
> 
> Hmm. 0.0.0.0 is a wildcard address, meaning any of my local addresses.
> I do understand how that works for binding a TCP socket you will be
> listening on. It just means accept TCP connections on all addresses.
> The destination address of the incoming SYN segment will determine which
> one to use. However, which of the local addresses should be used
> when calling connect() with 0.0.0.0? How should this choice be made?
> 
> Best regards
> Michael
> 

I don't know.  I had thought the idea was sanctioned by a couple RFCs,
but I just had a fresh look at them (1122, 5735) and it now appears to
me that in both cases it sanctions using 0.0.0.0 as a source address,
but not as a destination.  So now I'm thinking maybe it has been a
historical mistake amongst the BSDs to accept it as a destination
address synonym for 127.0.0.1.

I was mostly just pointing out this change to no longer accept it is
going to be a big surprise to many people when it hits the streets in a
release.  I know it's going to break things at $work, we'll have to
start combing around for uses of it and make changes.  (Fixing my 20+
years of finger-memory for "nc 0 " will be harder.)

-- 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: В ответ на: vnc can't connect to socket

[Ian Lepore]

On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote:
> > On 21. Jun 2020, at 14:28, Kostya Berger 
> > wrote:
> > 
> > Ok, it turns out, it gives the previously mentioned error only if I
> > use VNC server string 0.0.0.0:5900 (as I always did). in my VNC
> > client.But when replaced with127.0.0.1:5900it connects all right.
> 
> I don't hink 0.0.0.0 is a valid destination address you can use in
> connect(). Using 127.0.0.1 should
> be fine.
> 
> I guess, https://svnweb.freebsd.org/changeset/base/361752 is the
> relevant commit here.
> 

*BSD has always accepted 0 as a synonym for localhost (and iirc, linux
does not).  If this no longer works, it's a regression which is going
to cause existing applications and scripts to fail.  At the very least
it deserves an entry in UPDATING.

-- Ian

> Best regards
> Michael
> > Отправлено из Yahoo Почты для Android 
> > 
> > вс, 21 июн. 2020 в 9:40 Kostya Berger
> > написал(-а):   Hi,upgraded to 362292 via buildworld.Now I cannot
> > connect to my bhyve guest as I used to: neither via VNC nor via
> > RDP.VNC gets error: unable to connect the socket. Address family
> > not supported by protocol family (47).
> > Neither can I ping my bhyve IP (it uses a separate NIC and should
> > have no problems)
> > Internet connectivity is ok and I can ping other hosts on my
> > network.
> > In 359997 all works fine.
> > Отправлено из Yahoo Почты для Android  
> > ___
> > 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"
> 
> ___
> 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"
> 

___
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: efirtc + atrtc at the same time

[Ian Lepore]

On Mon, 2020-05-25 at 11:37 +0300, Andriy Gapon wrote:
> I see that on my laptop both efirtc and atrtc get attached.
> The latter is via an ACPI attachment:
> efirtc0: 
> efirtc0: registered as a time-of-day clock, resolution 1.00s
> atrtc0:  port 0x70-0x71 on acpi0
> atrtc0: registered as a time-of-day clock, resolution 1.00s
> 
> I am not sure if this is a problem by itself, but it certainly seems redundant
> to have two drivers controlling the same(?) hardware via different platform
> mechanisms.
> Maybe there is a nice way to automatically disable (or "neutralize") one of 
> the
> drivers?
> 

I thought I had done something long ago to prevent atrtc and efirtc
from both attaching, but apparently not.  I intended to, I even
mentioned it in https://reviews.freebsd.org/D14399 but it looks like I
never followed up and did the work.

> Also, there is another issue related to atrtc.
> When I have both drivers attached, and also when I have only atrtc attached
> (efi.rt.disabled=1), system clock jumps 10 minutes forward after each suspend 
> /
> resume cycle (S0 -> S3 -> S0).  That does not happen for reboot and shutdown
> cycles.  I haven't investigated this deeper, but it is a curious problem.
> 

I've looked at the code for messing with the clock around
suspend/resume and never felt like it was doing the right thing (or
even anything useful).  But I've never owned a freebsd machine that
could successfully resume from suspend, so I've never been able to
experiment with it.

-- 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: lock order reversal and poudriere

[Ian Lepore]

On Sat, 2020-05-02 at 20:36 +0200, Kurt Jaeger wrote:
> Hi!
> 
> > > > I am compiling some packages with poudriere on 13-current kernel. I
> > > > noticed some strange messages printed into the terminal and dmesg:
> > > > 
> > > > lock order reversal:
> > > 
> > > [...]
> > > > Are those the debug messages that aren't visible on non-current kernel
> > > > and should they be reported?
> > > 
> > > Yes, they should be checked and reported.
> > > 
> > > For more details see:
> > > 
> > > http://sources.zabbadoz.net/freebsd/lor.html
> > > 
> > > There's a webpage with a list of all known LORs and a way to
> > > report new LORs.
> > Thanks Kurt. I can't find those two specific LORs in the list on that
> > page. The page also says to report them using a link, which leads to 404
> > :-), or on this mailing list, which I did. I am not sure what else should
> > I do.
> 
> I don't know, either 8-} bz@ is in Cc:, so he'll probably know what
> to do.
> 

That LOR site hasn't been updated in years.  Many many years.

The sad truth appears to be that nobody cares about LORs anymore.  The
same ones have been there for years.  Nobody fixes them, nobody does
anything to suppress reporting them.  We just keep pointing new users
to a dead website because that has always been the only response
available.

> > How do I know if I have got a backtrace?
> > 
> > Are those errors:
> > 
> > pid 43297 (conftest), jid 5, uid 0: exited on signal 11
> > 
> > related or it's a different issue?
> 
> I think that's a different issue.
> 

Segfaults and other problems with a program named "conftest" while
building ports is normal.  Autotools' configure script writes and runs
programs named conftest to detect the presence or absence of features
or bugs.  That doesn't mean every failure of a program named conftest
is normal and expected, but in general it's not a thing to worry about.

-- 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: FYI: artifact-based head bisect and OPi+2e (an armv7): -r359311 fails to boot but -r359309 boots (kernel substitutions)

[Ian Lepore]

On Sun, 2020-03-29 at 09:44 -0700, Thomas Skibo wrote:
> On Sun, Mar 29, 2020 at 12:29:00AM -0700, Mark Millard via freebsd-
> arm wrote:
> > While trying to update the head version
> > in use I ran into boot hangups on the
> > OrangePi+ 2e and did an approximate
> > bisect of artificact.freebsd.org kernels
> > to find approximately which kernel
> > version the issue started at.
> > 
> > I found that head -r359309 boots and
> > -r359311 fails (shown later below).
> > The original update attempt was from
> > -r359966 to -r359376 and -r359376
> > stopped there as well. (I kept world
> > there and varied the kernel version
> > for the approximate bisect activity.)
> > 
> > It seems that at least one of the
> > "MI-namespace" atomics added do not work
> > in all its usage-contexts on the cortexA7
> > (armv7) involved.
> 
> It looks like my previous reply didn't go to the mailing lists.  I'm
> new to
> mutt.
> 
> Anyway, I looked at this problem yesterday and it seems r359311
> enables
> using some atomic operations that were not being used until now.  In
> particular, atomic_fcmpset_8() seems broken and hangs up
> in vm_page_bits_swap().  I think I have a fix but I want to run it
> by Ian.
> 
> --Thomas
> 
> Index: sys/arm/include/atomic-v6.h
> ===
> --- sys/arm/include/atomic-v6.h   (revision 359412)
> +++ sys/arm/include/atomic-v6.h   (working copy)
> @@ -196,7 +196,7 @@
>\
>   __asm __volatile( \
>   "1: ldrex" SUF "   %[tmp], [%[ptr]]  \n"  \
> - "   ldr%[ret], [%[oldv]] \n"  \
> + "   ldr" SUF " %[ret], [%[oldv]] \n"  \
>   "   teq%[tmp], %[ret]\n"  \
>   "   ittee  ne\n"  \
>   "   str" SUF "ne   %[tmp], [%[oldv]] \n"  \
> 


I've committed this fix as r359423, thanks!

-- 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: Any a.out users?

[Ian Lepore]

On Fri, 2020-03-13 at 13:34 -0400, Ed Maste wrote:
> On Fri, 13 Mar 2020 at 13:22, Ian Lepore  wrote:
> > 
> > Could a.out support be a kernel config option that's off by
> > default?
> 
> Probably. That seems reasonable to me.
> 
> > And could its presence be indicated via sysctl in some way, so that
> > ldconfig could do a.out hints only if support for them is
> > available?
> 
> But why does ldconfig need to know about a.out files at all? Assuming
> this support still works we can just provide an a.out ldconfig along
> with a.out shared libraries.
> 

Oh, that makes sense... if the libs are conditionally installed, an
ldconfig_aout could also be conditionally installed.

-- 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: Any a.out users?

[Ian Lepore]

On Fri, 2020-03-13 at 13:04 -0400, Ed Maste wrote:
> While looking at other things we came across ldconfig's a.out
> support,
> which hasn't been used by anything in the FreeBSD base system in ~2
> decades.
> 
> I know there are (or at least recently were) folks using a.out
> binaries on contemporary FreeBSD. Most likely statically linked
> proprietary software. I'd be curious to know if anyone is still using
> this.
> 
> As far as ldconfig goes I don't see the value in generating a.out
> hints; if someone is using a.out shared libraries (from FreeBSD 2.x)
> it seems that they can also just use FreeBSD 2.x ldconfig to generate
> the hints file. Is there any reason we shouldn't deprecate ldconfig
> a.out support?

Could a.out support be a kernel config option that's off by default? 
And could its presence be indicated via sysctl in some way, so that
ldconfig could do a.out hints only if support for them is available?

-- 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: bootstrap error with make buildworld

[Ian Lepore]

On Tue, 2020-02-18 at 14:16 +0100, Trond Endrestøl wrote:
> On Tue, 18 Feb 2020 11:03+0100, Jochen Neumeister wrote:
> 
> > Anyone got a tip to solve this problem?
> > Otherwise I would unfortunately have to reinstall the server. My Poudriere 
> > Box
> > runs on this server
> > 
> > Am 17.02.20 um 18:14 schrieb Kyle Evans:
> > > On Mon, Feb 17, 2020 at 11:13 AM Jochen Neumeister 
> > > wrote:
> > > > after a
> > > > cd /usr/src
> > > > svn up
> 
> It might be helpful if you can tell us which revision your source tree 
> is current at.
> 
> > > > make clean
> > > > make -j6 buildworld
> 
> make buildworld
> 
> Running make without any parallelism makes it easier to know the exact 
> point of failure.
> 

The exact point of failure in the log attached to the original message:

> --- _bootstrap-tools-link-[ ---
> *** [_bootstrap-tools-link-[] Error code 1
> make[2]: stopped in /usr/src

I have no idea why it failed trying to create a symlink to '[' (an
alias for test(1)), but that was the first error.

-- 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: OFWBUS: How does autoconfiguration work?

[Ian Lepore]

On Tue, 2020-02-04 at 19:09 +0530, Niteesh wrote:
> I am working on an operating systems project at my university, which
> currently
> uses lazy driver initialization i.e. that is the drivers initialize the
> hardware only
> during the first invocation, for example, the UART hardware is initialized
> only during the first call to output_char.
> 
> Currently, we have multiple BSP's to support different variants even though
> they are quite similar. For example, we have two BSPs to support BeagleBone
> Black
> and white. We are trying to avoid this by using device tree files. Our goal
> is to parse the
> DTB at boot time and call all the registered drivers to initialize the
> hardware. By registered
> drivers, I mean drivers which are statically linked to executable.
> 
> I am trying to add a system, which will parse the DTB files and initialize
> them by calling
> the appropriate drivers. I want a system similar to FreeBSD or Linux
> a probe and attach method for device drivers. It doesn't have to be as
> complex as FreeBSD
> but a simple one will do.
> 
> If you have any other questions please let me know :)
> 
> Thanks,
> Niteesh
> 

I don't think there is anything much in the freebsd code that will help
you with that.  The book "The Design and Implementation of the FreeBSD
Operating System 2nd ed." describes the freebsd autoconfiguration
mechanisms.  Those mechanisms are designed to solve problems a lot more
complex than parsing a simple hierarchical dtb to find active devices,
it supports a mix of buses that can identify the devices on the bus
(USB, PCI), buses that are described with metadata (ACPI, fdt
simplebus, ISA bus with PNP data), and drivers that can just force a
bus to adopt them by using an identify() method.  Resource management
(interrupts and mmio ranges, mostly) are also part of the scheme.  FDT
data adds another wrinkle by creating cross-hierarchy links between
devices using phandles, and there are sideband subsystems in freebsd to
handle that stuff separately from the normal hiearchical parent/child
bus relationships.

There just isn't much that can reasonably be separated out and used in
another project, I think.

-- 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: OFWBUS: How does autoconfiguration work?

[Ian Lepore]

On Sun, 2020-02-02 at 10:02 +0530, Niteesh wrote:
> I couldn't find anything useful for me, I need information about how the
> hardware autoconfiguration works, not autoconf.
> 

Then maybe you need to provide more details about what you're doing,
what you've tried that isn't working, or something.  I couldn't make
any sense out of your original question.

-- 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: btxld not found

[Ian Lepore]

On Tue, 2020-01-28 at 17:08 +0100, Nick Hibma wrote:
> > On Tue, Jan 28, 2020, 4:57 AM Nick Hibma  > > wrote:
> > > On 28/01 /2020, at 12:39, Toomas Soome  > > tso...@me.com>> wrote:
> > > 
> > > > On 28. Jan 2020, at 13:36, Nick Hibma  > > > > wrote:
> > > > 
> > > > Folks,
> > > > 
> > > > Could anyone explain to me what I am doing wrong? make
> > > > installworld fails each time with the following error
> > > > 
> > > > ===> stand/i386/libi386 (install)
> > > > ===> stand/i386/loader_4th (install)
> > > > strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
> > > > btxld -v -f aout -e 0x20 -o loader_4th -l
> > > > /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr  -b
> > > > /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx
> > > > loader_4th.bin
> > > > make[6]: exec(btxld) failed (No such file or directory)
> > > > *** Error code 1
> > > > 
> > > > This is with source of last week. I had this problem before
> > > > (from old sources) and fixed it by specifying the full path to
> > > > btxld in the stand/i386/*/Makefile. 
> > > > 
> > > > Any pointers?
> > > > 
> > > 
> > > it should be /usr/sbin/btxld; are you missing /usr/sbin from the
> > > path?
> > 
> > Well, it's an 'installworld' so I would expect it to be providing
> > that program itself, but no, /usr/sbin/ is in the path of the
> > current shell.
> > 
> > Also, in some of the makefiles the target calling btxldr is
> > depending on the build of that executable:
> > 
> > Index: stand/i386/pxeldr/Makefile
> > ===
> > --- stand/i386/pxeldr/Makefile  (revision 357042)
> > +++ stand/i386/pxeldr/Makefile  (working copy)
> > @@ -39,7 +39,7 @@
> >  CLEANFILES+= ${LOADER}
> > 
> >  ${LOADER}: ${LOADERBIN} ${BTXLDR} ${BTXKERN}
> > -   btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l
> > ${BTXLDR} \
> > +   /usr/sbin/btxld -v -f aout -e ${LOADER_ADDRESS} -o
> > ${.TARGET} -l ${BTXLDR} \
> > -b ${BTXKERN} ${LOADERBIN}
> > 
> > This is definitely wrong. We have either a path that is wrong, or
> > we aren't reinstalling btxld in the right place.
> > 
> > Warner
> 
> This is not a fix, this is to get me through the installworld. As
> I've not seen any mention of this the past 6 months it must be
> something on my system that makes things go bad, but I have no idea
> what.
> 
> They are being built, and installed:
> 
> {e}nick@fimkjecurrent:/usr/src/stand/i386/btx % find / -name btxld
> -ls
> 1908308   48 -r-xr-xr-x1
> root wheel   
> 22988 Jan 27 23:37 /usr/sbin/btxld
> 13190104 drwxr-xr-x2
> nick nick
>   512 Sep 15  2017 /usr/src/usr.sbin/btxld
> 33695644 drwxrwxr-x2
> root wheel   
>   512 Jan 27 22:33 /usr/obj/usr/src/i386.i386/usr.sbin/btxld
> 3371323   52 -rwxr-xr-x1
> root wheel   
> 25816 Jan 27 22:33 /usr/obj/usr/src/i386.i386/usr.sbin/btxld/btxld
> 
> I guess the difference in file size is due to it being stripped
> during install?
> 
> Nick

I would expect the one that gets used during make install to be in the
objdir/.../tmp/usr/sbin directory, like other build and install tools.

But oddly, I don't have btxld in tmp for amd64 builds, only for i386.

-- 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: head -r356109 on 32-bit powerpc (old PowerMac): Memory modified after free during late-stage of boot, most recently used by bus-sc

[Ian Lepore]

On Sun, 2019-12-29 at 23:04 +0100, Hans Petter Selasky wrote:
> On 2019-12-29 22:53, Mark Millard via freebsd-hackers wrote:
> > 0xd2630510: at uma_zalloc_arg+0x1b4
> > 0xd2630540: at malloc+0xfc
> > 0xd2630580: at alloc_bounce_pages+0x7c
> > 0xd26305c0: at bus_dmamap_create+0x1e8
> 
> Do you know what drivers are using bounce pages?
> 
> 

busdma isn't the culprit here.  It was trying to allocate memory and
the uma code found a block that was free and checked it before handing
it out, and discovered that it had been modified after being freed.

Before being freed, the memory was last used as the softc for some
device (perhaps only during probing of a device that never attached). 
That device would most likely be the culprit (or a wild-pointer write
hit that block).

-- 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: Best way to print something from the kernel at 1s intervals?

[Ian Lepore]

On Fri, 2019-11-29 at 23:10 +0100, Peter Eriksson wrote:
> I love dtrace, but I seriously doubt that it could be used it for
> this. This is the absolutely last code that executes at kernel
> shutdown/reboot. All other processes are terminated when this is
> happening...
> 
> Basically the code done in kern_reboot() (and stuff it calls) in
> /usr/src/sys/kern/kern_shutdown.c
> 
> This code in kern_reboot():
> ...
> >  EVENTHANDLER_INVOKE(shutdown_pre_sync, howto);
> > 
> >/*
> > * Now sync filesystems
> > */
> >if (!cold && (howto & RB_NOSYNC) == 0 && once == 0) {
> >once = 1;
> >bufshutdown(show_busybufs);
> >}
> > 
> >print_uptime();
> > 
> >cngrab();
> > 
> >/*
> > * Ok, now do things that assume all filesystem activity has
> > * been completed.
> > */
> >EVENTHANDLER_INVOKE(shutdown_post_sync, howto);
> > 
> >if ((howto & (RB_HALT|RB_DUMP)) == RB_DUMP && !cold &&
> > !dumping)
> >doadump(TRUE);
> > 
> >/* Now that we're going to really halt the system... */
> >EVENTHANDLER_INVOKE(shutdown_final, howto);
> 
> What I’ve seen is that the three different EVENTHANDLER_INVOKE() all
> can cause a lot of calls that can take a long time. As can
> bufshutdown(), probably when it calls vfs_unmountall() to unmount all
> filesystems.
> 
> We’re talking like 5-20 minutes (or more). I’ve not really timed it.
> 
> I have a feeling it sometimes is due to transactions stored up in the
> ZFS filesystems that the system tries to “run” so it doesn’t have to
> do it at mount() time after the reboot. If I reset the machine while
> it is busy doing this then sometimes the “zfs mount -a” takes very
> long time at boot instead.
> 
> Hmm.. I should be able to use the getnanouptime() call to get a
> “clock” to look for (it’s used in print_uptime()). As long as the
> clock isn’t stopped at this time in the shutdown sequence atleast :-)
> 
> *Time to write some code and test this* :-)
> 

If you want to throttle something to once a second (or some number of
integer seconds) the kernel has a global variable named time_sec, (in
sys/time.h), watch for it to change.

-- 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: Reverting -current by date.

[Ian Lepore]

On Wed, 2019-11-20 at 09:38 -0800, bob prohaska wrote:
> From time to time it would be handy to revert freebsd-current to
> an older, well-behaved revision. 
> 
> Is there a mechanism for identifying revision numbers that
> will at least compile and boot, by date? 
> 
> In my case buildworld seems to be markedly slower than, say,
> six months ago. Maybe it's hardware, maybe something else. Is
> there a way to pick a revision number to revert to, that's
> better than merely guessing? 
> 
> Thanks for reading,
> 
> bob prohaska
> 

svn update -r "{date}" 

The curly braces indicate you're specifying a date, which can be in a
large variety of typical formats, details here:

 http://svnbook.red-bean.com/en/1.7/svn.tour.revs.specifiers.html

Curly braces are significant in some shells, so the quotes may be
required.

-- 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: Best thread pool implementation for the base system?

[Ian Lepore]

On Thu, 2019-10-24 at 12:46 -0600, Alan Somers wrote:
> I count 5 thread pool implementations in contrib:
> * cddl/compat/opensolaris/misc/thread_pool.c
> * contrib/apr-util/misc/apr_thread_pool.c
> * contrib/llvm/lib/Support/ThreadPool.cpp
> * contrib/openmp/runtime/src/kmp_tasking.cpp
> * contrib/ofed/opensm/complib/cl_threadpool.c
> 
> However, I can't find any examples outside of contrib.  I'd like to
> use one
> in /sbin/geli.  Shall I roll my own (as everybody else apparently
> does), or
> is there something I'm not aware of?
> 
> 

Whenever the subject of thread pools comes up at $work I pose this
question:  What task is it you need to accomplish where the cost of
pthread_create/delete is significant in relation to the actual work
that will be done during the lifetime of the thread?

Over the years, the answers have been such that we never created a
thread pool class or helpers.  What we did eventually come up with was
basically an async taskqueue that had a single thread, because almost
always the answer to the question was something like "the work to be
done is really tiny and not-time-critical, it just needs to be done on
a different thread to avoid [recursion|deadlock|whatever]."

So I'd say the first thing to do is be sure that the best solution
isn't just to pthread_create() as needed.  If it turns out the cost of
pthread_create() is like 1-2% of the total work to be done, you may not
need a pool of pre-created 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"

Re: gpiobus: setting output value while in input mode

[Ian Lepore]

On Thu, 2019-10-24 at 19:01 +0300, Andriy Gapon wrote:
> Also, if we universally implement GPIO_PIN_PRESET we still need to answer the
> question.  Because some consumer might still try to change an input, either by
> mistake or for some reason, and we need a rule on how to handle that.

Well, yeah, I guess just to zoom in on the core question of "what
should happen if you try to set the state of a pin configured as
input?" the answer would be "the controller should return ENODEV" and
you could make a good case that it should do so regardless of the
hardware's capabilities.  Actually, for hardware that lets you set the
output state while configured for input, where the drivers currently
leverage that feature, we could both set the hardware and return
ENODEV, and existing code like that in gpioiic will still work.

But doing that also would require examining every existing driver and
probably changing many of them.  I'm not afraid of this aspect of any
change we decide on... it's about 30 drivers, all of which will need
minor changes.

-- 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: gpiobus: setting output value while in input mode

[Ian Lepore]

On Thu, 2019-10-24 at 17:04 +0300, Andriy Gapon wrote:
> For a lack of a more specific mailing list (or my not being aware of it), 
> asking
> here.
> 
> gpioiic, a very simple driver, has this code:
> ===
> static void
> gpioiic_setsda(device_t dev, int val)
> {
> struct gpioiic_softc*sc = device_get_softc(dev);
> 
> if (val == 0) {
> GPIOBUS_PIN_SET(sc->sc_busdev, sc->sc_dev, sc->sda_pin, 0);
> GPIOBUS_PIN_SETFLAGS(sc->sc_busdev, sc->sc_dev, sc->sda_pin,
> GPIO_PIN_OUTPUT);
> } else {
> GPIOBUS_PIN_SETFLAGS(sc->sc_busdev, sc->sc_dev, sc->sda_pin,
> GPIO_PIN_INPUT);
> }
> }
> ===
> 
> The interesting case is val == 0.
> 
> I know that there are GPIO controllers where input and output values are
> represented by different bits, so it is possible to set a future output value
> while the pin is in input mode.
> At the same time, there are controllers where there is a single bit per pin 
> and
> while the pin is input mode the bit is read-only.  So, it is impossible to
> preset the pin.
> 
> How should controllers of the second type handle GPIOBUS_PIN_SET when the pin 
> is
> in input mode?
> I see three options:
> 1) just silently ignore GPIOBUS_PIN_SET or do it in a more glorious way: go 
> all
> the way to the hardware without caring if that does anything;
> 2) return an error that would hint that the operation is not possible at this 
> time;
> 3) try to emulate the first class of controllers; that is, stash the value to
> apply it when the pin is switched to output mode.
> 
> I personally prefer 2, it's not hard to do (unlike 3) and there would be at
> least some visibility into the problem.
> 

A couple years ago I added new flags GPIO_PIN_PRESET_{LOW,HIGH}.  Maybe
we should document (where?) that the proper way to achieve the effect
the code wants in the val==0 case is to use the preset flag along with
the OUTPUT flag.  The driver will preset the pin before changing it to
output if it is able to do so, otherwise it will do the best it can,
which is to set the pin to output, then set its value, perhaps
generating a brief bogus state followed by a transition to the right
state.  Then of course we'd have to fix all existing drivers to behave
that way, but I don't think that will be hard.

My problem with #2 is that whenever you push the problem out to the
child drivers, one of two things happens:  drivers ignore the error, or
all drivers have to have essentially identical code to handle the
error.  In this case, what could a child driver do except react to the
error by doing the operations in the reverse order?

The current gpio(4) documentation really only covers gpiobus(4) and a
mentions a few of its older children and how to configure them via
hints.  We need manpages for some of the newer drivers, and we
especially need a manpage that documents sys/gpio.h (which is used both
from userland and internally with gpio_if.m).  I can probably find some
manpage-writing time over the new few weeks.

-- 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: ZFS with 32-bit, non-x86 kernel

[Ian Lepore]

On Fri, 2019-10-04 at 13:27 -0600, Warner Losh wrote:
> On Fri, Oct 4, 2019, 1:07 PM Dennis Clarke  wrote:
> 
> > On 10/4/19 10:05 AM, Andriy Gapon wrote:
> > > 
> > > Does anyone use ZFS with a 32-bit kernel, that is also not i386 ?
> > > If you do, could you please let me know?  Along with uname -rmp output.
> > > Thank you!
> > > 
> > 
> > I don't know if that has even been attempted by anyone. The ZIL and ZFS
> > log comonents require substantial amounts of memory and I am not aware
> > of anyone with arm devices that have 8GB+ of memory. I have had FreeBSD
> > current on RISC-V running fairly well with ZFS however that was a purely
> > rv64imafdc architecture.
> > 
> 
> In the FreeBSD 10 time frame I know people were running ZFS on arm7 boards.
> Iirc, there was a long list of tweaks needed to size of the ZIL. A quick
> google didn't find it.
> 
> Otoh, I looked at ZFS for NanoBSD when it first came out. I gave up because
> the 256MB boards at the time made any kind of storage traffic ran things
> out of memory.
> 
> Warner
> 
> 
> I will watch this thread with curiosity.

There have been several threads about using zfs on armv7 over the
years.  Some of them are from 2013 and indicate little sucess.  Others,
from 2015, indicate it works...

https://lists.freebsd.org/pipermail/freebsd-arm/2015-March/010607.html
https://lists.freebsd.org/pipermail/freebsd-arm/2015-March/010649.html

There have also been some bug reports as recently as 2017 indicating
that people are still doing this on small armv7 systems.

-- 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: Booting anything after r352057 kills console

[Ian Lepore]

On Tue, 2019-09-24 at 14:32 -0400, Thomas Laus wrote:
> On 2019-09-24 11:58, Pete Wright wrote:
> > 
> > darn, and they didn't give you any additional information in the
> > messages buffer, or generate a core file?
> > 
> 
> There were no messages in the syslog and no other log that showed
> anything after killing the console.  On my working BEADM boot
> environment, the next message after starting ntp is:
> 
> configuring vt: blanktime
> 
> This message never showed in the syslog on any of the 'black screens'.
> I looked over the changes made between r352057 and r352064 and nothing
> 'vt' related popped up.  I have not built anything between these 2
> releases and probably should in order to help narrow the problem.  I
> originally updated to r352304 and killed my system and was reverting
> back toward r352057 by splitting the difference by half.  The problem
> was still there in r352064, so I stopped and asked for help.
> 
> This problem did not generate a core and building GENERIC with the DEBUG
> symbols did not add any more information.
> 
> Tom

On my system, a whole lotta stuff happens between ntpd and syscons (the
thing that configures blanktime).  Try setting rc_debug=YES in rc.conf,
that should write more info to syslog about what's happening between
ntpd and the lockup point.

-- 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: head -r352274 buildkernel targetting armv7 failure: am335x/am335x_dmtpps.c:304:3: error: implicit declaration of function 'spinlock_enter' is invalid in C99 [-Werror,-Wimplicit-function-declaratio

[Ian Lepore]

On Sat, 2019-09-14 at 11:05 -0700, Mark Millard via freebsd-arm wrote:
> After updating my amd64 context to head -r352274,
> attempting an amd64->armv7 cross buildworld buildkernel
> ended up failing with:
> 
> 
> --- am335x_dmtpps.o ---
> /usr/src/sys/arm/ti/am335x/am335x_dmtpps.c:304:3: error: implicit
> declaration of function 'spinlock_enter' is invalid in C99 [-Werror,-
> Wimplicit-function-declaration]
> mtx_lock_spin(>pps_mtx);
> ^
> /usr/src/sys/sys/mutex.h:383:26: note: expanded from macro
> 'mtx_lock_spin'
> #define mtx_lock_spin(m)mtx_lock_spin_flags((m), 0)
> ^
> /usr/src/sys/sys/mutex.h:452:2: note: expanded from macro
> 'mtx_lock_spin_flags'
> mtx_lock_spin_flags_((m), (opts), LOCK_FILE, LOCK_LINE)
> ^
> /usr/src/sys/sys/mutex.h:429:2: note: expanded from macro
> 'mtx_lock_spin_flags_'
> __mtx_lock_spin((m), curthread, (opts), (file), (line))
> ^
> /usr/src/sys/sys/mutex.h:258:2: note: expanded from macro
> '__mtx_lock_spin'
> spinlock_enter();
>\
> ^
> /usr/src/sys/arm/ti/am335x/am335x_dmtpps.c:304:3: error: this
> function declaration is not a prototype [-Werror,-Wstrict-prototypes]
> /usr/src/sys/sys/mutex.h:383:26: note: expanded from macro
> 'mtx_lock_spin'
> #define mtx_lock_spin(m)mtx_lock_spin_flags((m), 0)
> ^
> /usr/src/sys/sys/mutex.h:452:2: note: expanded from macro
> 'mtx_lock_spin_flags'
> mtx_lock_spin_flags_((m), (opts), LOCK_FILE, LOCK_LINE)
> ^
> /usr/src/sys/sys/mutex.h:429:2: note: expanded from macro
> 'mtx_lock_spin_flags_'
> __mtx_lock_spin((m), curthread, (opts), (file), (line))
> ^
> /usr/src/sys/sys/mutex.h:258:2: note: expanded from macro
> '__mtx_lock_spin'
> spinlock_enter();
>\
> ^
> . . .
> 
> (spinlock_enter was not the only example.)
> 
> 

My bad, I forgot to include  when I switched the code to
spinlocks.  Should be fixed by r352333.

-- 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: Source tree has many empty directories?

[Ian Lepore]

On Tue, 2019-09-10 at 21:41 +0200, Dimitry Andric wrote:
> On 10 Sep 2019, at 20:14, Ian Lepore  wrote:
> > 
> > On Tue, 2019-09-10 at 11:01 -0600, Warner Losh wrote:
> > > However, please do *NOT* remove the sys/*/compile directories.
> > > 
> > > Warner
> > 
> > Uhhh... that's interesting.  I just nuked one of those on my system
> > yesterday, because it had been hanging around since 2013 and I had no
> > idea what was -- I just assumed the build machinery created it because
> > I had accidentally done a make in a wrong directory once.
> > 
> > So what are those directories about?  I'm not used to seeing mystery
> > directories appear inside a source tree.
> 
> There's not much mystery to be found.  Subversion does not warn you when you
> remove the last files from a directory, and it also does not automatically
> remove such empty directories, like Git.  Hence, those directories tend to
> stick around, because every simply forgets about them.
> 
> With regards to those empty directories under contrib/llvm, those were 
> actually
> imported from upstream.  But since the llvm project will switch to Git soon,
> this problem will automagically disappear. :-)
> 
> -Dimitry
> 

I was referring specifically to the sys/*/compile directories Warner
mentioned.

-- 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: Source tree has many empty directories?

[Ian Lepore]

On Tue, 2019-09-10 at 11:01 -0600, Warner Losh wrote:
> However, please do *NOT* remove the sys/*/compile directories.
> 
> Warner

Uhhh... that's interesting.  I just nuked one of those on my system
yesterday, because it had been hanging around since 2013 and I had no
idea what was -- I just assumed the build machinery created it because
I had accidentally done a make in a wrong directory once.

So what are those directories about?  I'm not used to seeing mystery
directories appear inside a source tree.

-- 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: ntpd segfaults on start

[Ian Lepore]

On Mon, 2019-09-09 at 12:28 -0700, Cy Schubert wrote:
> > 
> > On the other hand, the code execution times are not predictable if the
> > process's pages can be paged out. Under severe load next instruction
> > might take several seconds or even minutes to start. It is quite unlike
> > the scheduler delays. That introduces a jitter in the local time
> > measurements and their usage as done in userspace. Wouldn't this affect
> > the accuracy ?
> 
> IMO it would and would be unacceptable when used as a stratum N server or 
> with some OLTP or database applications. Locking a few megabytes is a small 
> cost.

What I proposed was changing the default to not lock all of ntpd into
memory, because I think that would work well for most users.  Admins
running stratum 1 or 2 servers are probably a bit more savvy about ntp
configuration than the average user, and would use the rlimit command
in ntp.conf.

-- 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: ntpd segfaults on start

[Ian Lepore]

On Mon, 2019-09-09 at 21:44 +0300, Konstantin Belousov wrote:
> On Mon, Sep 09, 2019 at 12:13:24PM -0600, Ian Lepore wrote:
> > On Mon, 2019-09-09 at 09:30 -0700, Rodney W. Grimes wrote:
> > > > On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote:
> > > > > In message <20190907161749.gj2...@kib.kiev.ua>, Konstantin
> > > > > Belousov writes:
> > > > > > On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert
> > > > > > wrote:
> > > > > > > [...]
> > > 
> > > Doesn't locking this memory down also protect ntpd from OOM kills?
> > > If so that is a MUST preserve functionality, as IMHO killing ntpd
> > > on a box that has it configured is a total no win situation.
> > > 
> > 
> > Does it have that effect?  I don't know.  But I would argue that that's
> > a separate issue, and we should make that happen by adding
> > ntpd_oomprotect=YES to /etc/defaults/rc.conf
> 
> Wiring process memory has no effect on OOM selection. More, because
> all potentially allocated pages are allocated for real after mlockall(),
> the size of the vmspace, as accounted by OOM, is the largest possible
> size from the whole lifetime.
> 
> On the other hand, the code execution times are not predictable if the
> process's pages can be paged out. Under severe load next instruction
> might take several seconds or even minutes to start. It is quite unlike
> the scheduler delays. That introduces a jitter in the local time
> measurements and their usage as done in userspace. Wouldn't this affect
> the accuracy ?
> 

IMO, there is a large gap between "in theory, paging could cause
indeterminate delays in code execution" and "time will be inaccurate on
your system".  If there were a delay in a part of the code where it
matters that amounted to "seconds or even minutes", what you'd end up
with is a measurement that would be discarded by the median filter as
an outlier.  There would be some danger that if that kind of delay
happened for too many polling cycles in a row, you'd end up with no
usable measurements after a while and clock accuracy would suffer. 
Sub-second delays would be more worriesome because they might not be
rejected as outliers.

There are only a couple code paths in freebsd ntpd processing where a
paging (or scheduling) delay could cause measurement inaccuracy:

 - When stepping the clock, the code that runs between calling
clock_gettime() and calling clock_settime() to apply the step
adjustment to the clock.

 - When beginning an exchange with or replying to a peer, the code that
runs between obtaining system time for the outgoing Transmit Timestamp
and actually transmitting that packet.

Stepping the clock typically only happens once at startup.  The ntpd
code itself recognizes that this is a time-critical path (it has
comments to that effect) but unfortunately the code that runs is
scattered among several different .c files so it's hard to say what the
likelyhood is that code in the critical section will all be in the same
page (or be already-resident because other startup-time code faulted in
those pages).  IMO, the right fix for this would be a kernel interface
that let you apply a step-delta to the clock with a single syscall
(perhaps as an extension to the existing ntp_adjtime() using a new mode
flag).

On freebsd, the Receive timestamps are captured in the kernel and
delivered along with the packet to userland, and are retrieved by the
ntpd code from the SCM_BINTIME control message in the packet, so there
is no latency problem in the receive path.  There isn't a corresponding
kernel mechanism for setting the outgoing timestamps, so whether it's
originating a request to a peer or replying to a request from a peer,
the transmit timestamp could be wrong due to:

 - paging delays
 - scheduler delays
 - network stack, outgoing queues, and driver delays

So the primary vulnerability is on the transmit path between obtaining
system time and the packet leaving the system.  A quick glance at that
code makes me think that most of the data being touched has already
been referenced pretty recently during the process of assembling the
outgoing packet, so it's unlikely that storing the timestamp into the
outgoing packet or the other bit of work that happens after that
triggers a pagein unless the system is pathologically overloaded. 
Naturally, obtaining the timestamp and putting it into the packet is
one of the last things it does before sending, so the code path is
relatively short, but it's not clear to me whether it's likely or not
that the code involved all lives in the same page.  Still, it's one of
the heavily exercised paths within ntpd, which should increase the odds
of the pages being resident because of recent use.

So, I'm not disputing the point that a sufficiently overl

Re: ntpd segfaults on start

[Ian Lepore]

On Mon, 2019-09-09 at 09:30 -0700, Rodney W. Grimes wrote:
> > On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote:
> > > In message <20190907161749.gj2...@kib.kiev.ua>, Konstantin
> > > Belousov writes:
> > > > On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert wrote:
> > > > > I've been able to set the memlock rlimit as low as 20 MB. The
> > > > > issue is 
> > > > > letting it default to 0 which allows ntp to mlockall()
> > > > > anything it wants. 
> > > > > ntpd on my sandbox is currently using 18 MB.
> > > > 
> > > > Default stack size on amd64 is 512M, and default stack gap
> > > > percentage is
> > > > 3%. This means that the gap can be as large as ~17MB. If 3MB is
> > > > enough
> > > > for the stack of the main thread of ntpd, then fine.
> > > 
> > > The default stack is 200K, which is also tuneable in ntp.conf.
> > > 
> > > [...]
> > 
> > I haven't seen anyone ask what I consider to be the crucial
> > question
> > yet:  why are we locking ntpd into memory by default at all?
> > 
> > I have seen two rationales for ntpd using mlockall() and
> > setrlimit(): 
> > 
> >- There are claims that it improves timing performance.
> > 
> >- Because ntpd is a daemon that can run for months at a time,
> >setting limits on memory and stack growth can help detect and
> >mitigate against memory leak problems in the daemon.
> 
> Doesn't locking this memory down also protect ntpd from OOM kills?
> If so that is a MUST preserve functionality, as IMHO killing ntpd
> on a box that has it configured is a total no win situation.
> 

Does it have that effect?  I don't know.  But I would argue that that's
a separate issue, and we should make that happen by adding
ntpd_oomprotect=YES to /etc/defaults/rc.conf

Right now only syslogd has oomprotect set to YES by default.  Maybe
that's a good choice -- once we start declaring one daemon to be more
important than others, you'll discover there's a whole back lot full of
bikesheds that need painting.

So maybe we should just document ntpd_oomprotect=YES in some more-
prominent way.  If we were to add a comment block to ntp.conf
describing rlimit, that might be a good place to mention setting
ntpd_oomprotect in rc.conf.

-- 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: ntpd segfaults on start

[Ian Lepore]

On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote:
> In message <20190907161749.gj2...@kib.kiev.ua>, Konstantin Belousov writes:
> > On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert wrote:
> > > I've been able to set the memlock rlimit as low as 20 MB. The issue is 
> > > letting it default to 0 which allows ntp to mlockall() anything it wants. 
> > > ntpd on my sandbox is currently using 18 MB.
> > 
> > Default stack size on amd64 is 512M, and default stack gap percentage is
> > 3%. This means that the gap can be as large as ~17MB. If 3MB is enough
> > for the stack of the main thread of ntpd, then fine.
> 
> The default stack is 200K, which is also tuneable in ntp.conf.
> 
> [...]

I haven't seen anyone ask what I consider to be the crucial question
yet:  why are we locking ntpd into memory by default at all?

I have seen two rationales for ntpd using mlockall() and setrlimit(): 

   - There are claims that it improves timing performance.

   - Because ntpd is a daemon that can run for months at a time,
   setting limits on memory and stack growth can help detect and
   mitigate against memory leak problems in the daemon.

I am *highly* skeptical of claims that locking ntpd in memory will
improve timing performance on freebsd (to the point where I'm inclined
to dismiss them out of hand, but I'd be willing to look at any actual
evidence).

The second point has at least some validity, but would be better
implemented (IMO) by decoupling the address space limit from the act of
locking down memory, and allowing configuration of RLIMIT_AS separately
from RLIMIT_MEMLOCK.  If there's any interest in this, I could try to
put together a patchset and submit it upstream for that.

I would propose that for freebsd, the autoconf-generated value for
DFLT_RLIMIT_MEMLOCK should be -1 to avoid calling setrlimit() and
mlockall() by default.  Then in the ntp.conf we distribute we have a
section like:

   # To lock ntpd into memory, uncomment the following rlimit line.
   # This should not be necessary on most systems, but may improve
   # performance on heavily-loaded servers experiencing enough
   # memory pressure to cause ntpd to be paged out.
   # rlimit memlock  stacksize 

Then we would need to come up with reasonable values for .

-- 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: Weird goings on with make::empty()

[Ian Lepore]

On Wed, 2019-09-04 at 09:33 -0500, Kyle Evans wrote:
> On Wed, Sep 4, 2019 at 9:27 AM Enji Cooper 
> wrote:
> > 
> > 
> > > On Sep 4, 2019, at 04:59, Poul-Henning Kamp 
> > > wrote:
> > > 
> > > On:
> > > 
> > >Repository Root: svn+ssh://repo.freebsd.org/base
> > >Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> > >Revision: 351809
> > > 
> > > I built a kernel, but drm-current-kmod did not get compiled
> > > from the new world order in /usr/local/sys/modules
> > > 
> > > Debugging I ended up doing this to src/sys/conf/kern.post.mk:
> > > 
> > >Index: sys/conf/kern.post.mk
> > >==
> > > =
> > >--- sys/conf/kern.post.mk(revision 351809)
> > >+++ sys/conf/kern.post.mk(working copy)
> > >@@ -77,12 +77,14 @@
> > >${target:S/^reinstall$/install/:S/^clobber$/cleandir/}
> > > .endif
> > > .for module in ${LOCAL_MODULES}
> > >-.if !empty(module)
> > >+true "XXX A $(module) 2 ${LOCALBASE} 3 ${LOCAL_MODULES} 4
> > > ${MODULES_WITH_WORLD}"
> > >+#.if !empty(module)
> > >+true "XXX B $(module) 2 ${LOCALBASE} 3 ${LOCAL_MODULES} 4
> > > ${MODULES_WITH_WORLD}"
> > >@${ECHODIR} "===> ${module}
> > > (${target:S/^reinstall$/install/:S/^clobber$/cleandir/})"
> > >@cd ${LOCAL_MODULES_DIR}/${module}; ${MKMODULESENV}
> > > ${MAKE} \
> > >DIRPRFX="${module}/" \
> > >${target:S/^reinstall$/install/:S/^clobber$/cleandir/}
> > >-.endif
> > >+#.endif
> > > .endfor
> > > .endif
> > > .endfor
> > > 
> > > This gives me the expected output from buildkernel:
> > > 
> > >true "XXX A drm-current-kmod 2 /usr/local 3 drm-current-kmod 4
> > > "
> > >true "XXX B drm-current-kmod 2 /usr/local 3 drm-current-kmod 4
> > > "
> > > 
> > > If I leave in the ".if !empty(module)" line in, I only get:
> > > 
> > >true "XXX A drm-current-kmod 2 /usr/local 3 drm-current-kmod 4
> > > "
> > > 
> > > suggestions welcome...
> > 
> > (CCing Kyle)
> > 
> > This behavior change is probably caused by r351799.
> > 
> > I personally think the code before Kyle’s change and after it was
> > buggy. It’s not word splitting LOCAL_MODULES before iterating over
> > it.
> > 
> 
> I've backed out r351799 since it breaks usage of LOCAL_MODULES
> (though
> I really don't understand how empty works, apparently, and that makes
> me sad)... please advise on a correct path forward, because it's not
> clear to me.
> 
> Thanks,
> 
> Kyle Evans
> 

I'm not positive, but I suspect this has to do with when variables are
expanded.  In particular, the loop variable for a .for is expanded on
each loop iteration, but doesn't yet exist during parsing.  I suspect
that the .if is evaluated earlier, during parsing.  For example, this
makefile:

   all:
   .for x in a "" b
   .if empty(x)
@echo empty
   .endif
@echo ${x}
   .endfor
@echo done

gives this output:

   revolution > make -f /tmp/Makefile 
   empty
   a
   empty

   empty
   b
   done

The way I interpret that is that empty(x) is true during parsing, so
the for loop is generated to contain "@echo empty" and "@echo ${x}",
then the for loop actually runs and prints both "empty" and the value
of ${x} on each iteration.

-- 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: Lost user database after bungled upgrade

[Ian Lepore]

On Wed, 2019-08-28 at 18:09 -0400, Ryan Stone wrote:
> Thanks for the hint; I wasn't aware of /var/backups.  Unfortunately
> fixing my user database at this point hasn't fixed pkg.  I'm worried
> that it has some bad data cached somewhere now. I tried restoring the
> pkg databack from /var/backups but that hasn't helped.
> 
> 

PR 223751 suggests that perhaps the assert is a side effect of another
problem such as a missing file, and fixing that may eliminate the
assert.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223751

Or maybe in your case the files are fine and it really is a uid
problem.  But a "pkg check -s -a" as suggested in the PR couldn't hurt.
:)

-- Ian

> On Wed, Aug 28, 2019 at 5:20 PM Gary Palmer 
> wrote:
> > 
> > On Wed, Aug 28, 2019 at 05:09:35PM -0400, Ryan Stone wrote:
> > > Hi everybody,
> > > 
> > > I lost /etc/master.passwd and friends while trying to recover
> > > from an
> > > src upgrade gone wrong.  I'm trying to run "pkg upgrade -f" to
> > > get all
> > > of the users and groups created by packages recreating, but pkg
> > > is
> > > hitting an assert related to uids:
> > > 
> > > Checking integrity...Assertion failed: (strcmp(uid, p->uid) !=
> > > 0),
> > > function pkg_conflicts_check_local_path, file
> > > pkg_jobs_conflicts.c,
> > > line 386.
> > > 
> > > Is there any way to get past this, or is the system toast?
> > 
> > Did you try restoring from the backups under /var/backups?  There
> > should
> > be master.passwd in there which can be restored and /etc/passwd and
> > the DB files regenarated with pwd_mkdb (I think, never tried)
> > 
> > Regards,
> > 
> > Gary
> 
> ___
> 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"

___
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: HEADSUP: drm-current-kmod now installs sources

[Ian Lepore]

On Wed, 2019-08-14 at 13:59 -0600, Warner Losh wrote:
> On Wed, Aug 14, 2019 at 1:56 PM Ian Lepore  wrote:
> 
> > On Wed, 2019-08-14 at 12:00 -0700, John Baldwin wrote:
> > > On 8/14/19 11:06 AM, Kyle Evans wrote:
> > > > LOCAL_MODULES="" does seem like a sensible default when we're
> > > > not
> > > > building a native kernel.
> > > 
> > > Unfortunately kern.post.mk has no way of knowing that as
> > > MACHINE_*
> > > are already set to the TARGET_* values by the time this target is
> > > invoked.  Also, the 'make tinderbox' use case is a legit use case
> > > that some folks want (for CI, etc.)
> > > 
> > 
> > BUILDHOST_ARCH!= uname -p
> > .if ${BUILDHOST_ARCH} != ${TARGET_ARCH}
> > 
> > Unfortunately, I don't think it's as easy to compare the buildhost
> > running version with the version of source being built, unless the
> > build is started from the top level so that Makefile.inc1 sets the
> > variables.
> > 
> 
> We already know MACHINE_ARCH != TARGET_ARCH in Makefile.inc1 and
> already do
> different things based on it. But to be honest, I'd think there'd be
> times
> I'd absolutely want to build them all, and other times I wouldn't
> which
> strongly suggests some kind of knob specific for cross building the
> port/pkg-based kernel modules. We could then pass that knob into the
> kernel
> builds which would then not try to guess whether or not to build
> LOCAL_MODULES...
> 
> 

This is just about AUTOMATICALLY deciding to build something, based on
the presence of source code in an arbitrary fixed location outside of
the source tree on the build machine.  Anything set by the user should
be honored without question, including LOCAL_MODULES.  

My point is only that the build machinery should not be deciding to
build something the user didn't specify based on the existence of out-
of-tree files on the build machine (I'd like to put the period right
here in this sentence), unless there's a very high likelyhood that the
build being done is for the build machine.

Things like CI that want to include more than in-tree sources as part
of the build should be handling that by setting appropriate knobs as
part of invoking the build.

-- 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: HEADSUP: drm-current-kmod now installs sources

[Ian Lepore]

On Wed, 2019-08-14 at 12:00 -0700, John Baldwin wrote:
> On 8/14/19 11:06 AM, Kyle Evans wrote:
> > LOCAL_MODULES="" does seem like a sensible default when we're not
> > building a native kernel.
> 
> Unfortunately kern.post.mk has no way of knowing that as MACHINE_*
> are already set to the TARGET_* values by the time this target is
> invoked.  Also, the 'make tinderbox' use case is a legit use case
> that some folks want (for CI, etc.)
> 

BUILDHOST_ARCH!= uname -p
.if ${BUILDHOST_ARCH} != ${TARGET_ARCH}

Unfortunately, I don't think it's as easy to compare the buildhost
running version with the version of source being built, unless the
build is started from the top level so that Makefile.inc1 sets the
variables.

-- 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: HEADSUP: drm-current-kmod now installs sources

[Ian Lepore]

On Wed, 2019-08-14 at 19:55 +0200, Niclas Zeising wrote:
> On 2019-08-14 19:23, Emmanuel Vadot wrote:
> > On Wed, 14 Aug 2019 10:13:48 -0700
> > John Baldwin  wrote:
> > 
> > > On 8/14/19 9:22 AM, Ian Lepore wrote:
> > > > This all sounds vaguely wrong, backwards, to me.  A developer
> > > > who is
> > > > using a given module on their build system might want that
> > > > module to be
> > > > rebuilt automatically, but only if the build parameters match
> > > > those of
> > > > the running build host system.
> > > > 
> > > > If my build host is running freebsd 12 amd64 and I'm doing a
> > > > build for
> > > > freebsd 13 armv7, I have no interest in automatic rebuilds of
> > > > an amd64
> > > > driver module for a different OS arch and version just because
> > > > that
> > > > module happens to be installed on the system I use to do
> > > > crossbuilds.
> > > > 
> > > > My objections are theoretical... this automation just seems
> > > > improperly
> > > > designed to me.  But it won't actually affect me in any way,
> > > > because I
> > > > don't build video driver modules from ports, and I don't run
> > > > freebsd
> > > > current on my build host machine.  Probably the number of
> > > > people doing
> > > > crossbuilding is small enough that nobody else is going to
> > > > object to
> > > > this "the whole world is amd64" automation.
> > > 
> > > You assume DRM is amd64-only when it is definitely not.  It also
> > > has
> > > suitable guards in its Makefile to only build the relevant kernel
> > > modules on supported architectures.
> > 
> >   I clearly don't want to spend time to build the drm and radeon
> > modules
> > when I'm hacking on arm64.
> >   Shouldn't LOCAL_MODULE have ${TARGET}.${TARGET_ARCH} as a
> > subdirectory ? So when you install drm-kmod-* it will only install
> > the
> > source in /usr/local/modules/${TARGET}.${TARGET_ARCH}/ ? (or
> > whatever
> > the correct dir is).
> > 
> 
> I'm not sure what you're trying to accomplish.  I might be 
> misunderstanding completely, but, at least the drm ports have
> safeguards 
> in their makefiles so they'll only be built for those arches where
> there 
> is support, and only the modules needed, as an example, i915kms.ko
> will 
> only be built on amd64 and i386, if that's what you're worried about.
> Regards

I can't understand what you guys are not-understanding.  New machinery
has been added that says "if some module source code exists in this
absolute fixed location on the build machine, then whenever you do any
kernel build for any OS version or any arch, rebuild that module source
code so that the the build machine's video drivers stay in sync with
the build machine's kernel."

Do you not see that for some of us, only a tiny fraction of the builds
done (maybe none of them at all) involve the kernel for the build host
machine or the video drivers for the build host machine?  And yet, for
us, every build we do will now inapppropriately rebuild this video
driver module which has nothing to do with the machine the build is
targeting.

And it's not just about crossbuilds, because it's about versions too. 
Even when a developer is running 13-current and wants their video
driver rebuilt and installed automatically along with the kernel,
they're certainly going to want that to happen only when they're
building 13-current.  If they're doing a test-build for 12-stable they
certainly aren't going to want to build and install that video driver.

-- 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: HEADSUP: drm-current-kmod now installs sources

[Ian Lepore]

On Wed, 2019-08-14 at 09:08 -0700, John Baldwin wrote:
> On 8/13/19 3:17 PM, Ian Lepore wrote:
> > On Tue, 2019-08-13 at 14:58 -0700, John Baldwin wrote:
> > > For developers this means even if you are doing testing on a box
> > > that doesn't use DRM, you can install the package so that kernel
> > > builds will try to compile it and hopefully spot KPI/KBI changes
> > > before they land in the tree so that the port/package can be
> > > patched in tandem with committing changes to HEAD.  Note that
> > > even
> > > builds of work trees in git checkouts, etc. will find the DRM
> > > modules and try to build them if the package is installed.
> > 
> > That last sentence sounds ominous.  Are you saying that when I'm on
> > my
> > amd64 machine building from /my/sources/rpi using TARGET_ARCH=armv6
> > it's going to find /usr/local/sys/modules/drm-current-kmod and try
> > to
> > crossbuild it for armv6?
> 
> Yes, meaning that you _can_ cross-build a DRM kernel module.  This
> also means
> that if you are trying out a KPI change and have the package
> installed, make
> tinderbox will now catch a change that breaks the DRM drivers on only
> a subset
> of platforms (e.g. a powerpc or arm-only breakage that currently goes
> unnoticed when a developer is only doing build testing from an amd64
> host).
> 
> There are several ways you can disable this either globally or in
> more
> fine-grained ways:
> 
> 1) You can set LOCALBASE to a different path either in a kernel
> config
>(via makeoptions) or when invoking buildkernel.
> 
>For example, I mount my rpi's sdcard at /mnt on my amd64 laptop
> and
>then cross-build into it, so I could set LOCALBASE to
> /mnt/usr/local when
>building the rpi's kernel to honor any kmod packages installed on
> the rpi.
> 
> 2) You can set LOCAL_MODULES (makeoptions, command line) to a list of
> modules
>to build (empty disables building any of them).
> 
> 3) You could set LOCAL_MODULES in /etc/src.conf to affect all kernel
> builds.
>(You probably don't want to set LOCALBASE there as it probably
> affects
>other things.)
> 
> 4) You can build the port with the SOURCES option disabled if you
> want to
>never build modules for a specific port.
> 
> > How about when I'm doing a build of 11-stable for testing, but
> > what's
> > in my /usr/local is sources for a 13-current driver?
> 
> Given that the kmod's are supposed to be portable across branches,
> the build really shouldn't be breaking.  But the same ability is
> still
> there to as above to disable builds either in general or for
> specific kernel configs or buildkernel invocations.
> 

This all sounds vaguely wrong, backwards, to me.  A developer who is
using a given module on their build system might want that module to be
rebuilt automatically, but only if the build parameters match those of
the running build host system.

If my build host is running freebsd 12 amd64 and I'm doing a build for
freebsd 13 armv7, I have no interest in automatic rebuilds of an amd64
driver module for a different OS arch and version just because that
module happens to be installed on the system I use to do crossbuilds.

My objections are theoretical... this automation just seems improperly
designed to me.  But it won't actually affect me in any way, because I
don't build video driver modules from ports, and I don't run freebsd
current on my build host machine.  Probably the number of people doing
crossbuilding is small enough that nobody else is going to object to
this "the whole world is amd64" automation.

-- 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: HEADSUP: drm-current-kmod now installs sources

[Ian Lepore]

On Tue, 2019-08-13 at 14:58 -0700, John Baldwin wrote:
> For developers this means even if you are doing testing on a box
> that doesn't use DRM, you can install the package so that kernel
> builds will try to compile it and hopefully spot KPI/KBI changes
> before they land in the tree so that the port/package can be
> patched in tandem with committing changes to HEAD.  Note that even
> builds of work trees in git checkouts, etc. will find the DRM
> modules and try to build them if the package is installed.

That last sentence sounds ominous.  Are you saying that when I'm on my
amd64 machine building from /my/sources/rpi using TARGET_ARCH=armv6
it's going to find /usr/local/sys/modules/drm-current-kmod and try to
crossbuild it for armv6?

How about when I'm doing a build of 11-stable for testing, but what's
in my /usr/local is sources for a 13-current driver?

-- 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: RFC: should lseek(SEEK_DATA/SEEK_HOLE) return ENOTTY?

[Ian Lepore]

On Sun, 2019-08-11 at 09:12 -0600, Alan Somers wrote:
> On Sun, Aug 11, 2019 at 8:57 AM Ian Lepore  wrote:
> > 
> > On Sun, 2019-08-11 at 09:04 +0200, Gary Jennejohn wrote:
> > > On Sun, 11 Aug 2019 02:03:10 +
> > > Rick Macklem  wrote:
> > > 
> > > > Hi,
> > > > 
> > > > I've noticed that, if you do a lseek(SEEK_DATA/SEEK_HOLE) on a
> > > > file
> > > > that
> > > > resides in a file system that does not support holes, ENOTTY is
> > > > returned.
> > > > 
> > > > This error isn't listed for lseek() and seems a liitle weird.
> > > > 
> > > 
> > > ENOTTY is the standard error return for an unimplemented
> > > ioctl(2),
> > > and SEEK_HOLE ultimately becomes a call to fo_ioctl().
> > > 
> > > > I can see a couple of alternatives to this:
> > > > 1 - Return a different error. Maybe ENXIO?
> > > > or
> > > > 2 - Have lseek() do the trivial implementation when the
> > > > VOP_IOCTL()
> > > > fails.
> > > >- For SEEK_DATA, just return the offset given as argument
> > > > and
> > > > for SEEK_HOLE
> > > >   return the file's size as the offset.
> > > > 
> > > > What do others think? rick
> > > > ps: The man page should be updated, whatever is done w.r.t.
> > > > this.
> > > > 
> > > 
> > > I also vote for option 2
> > > 
> > 
> > If SEEK_DATA and SEEK_HOLE don't return the standard "ioctl not
> > supported" error code and return a fake result, how are you
> > supposed to
> > determine at runtime whether SEEK_HOLE is supported or not?
> > 
> > -- Ian
> 
> pathconf(2) will tell you.
> 

Ahh, I wasn't aware of that.

For option 2, lseek() has to not just return the info, but must also
actually set the file position accordingly, and has to treat offset >=
filesize as an error.

-- 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: RFC: should lseek(SEEK_DATA/SEEK_HOLE) return ENOTTY?

[Ian Lepore]

On Sun, 2019-08-11 at 09:04 +0200, Gary Jennejohn wrote:
> On Sun, 11 Aug 2019 02:03:10 +
> Rick Macklem  wrote:
> 
> > Hi,
> > 
> > I've noticed that, if you do a lseek(SEEK_DATA/SEEK_HOLE) on a file
> > that
> > resides in a file system that does not support holes, ENOTTY is
> > returned.
> > 
> > This error isn't listed for lseek() and seems a liitle weird.
> > 
> 
> ENOTTY is the standard error return for an unimplemented ioctl(2),
> and SEEK_HOLE ultimately becomes a call to fo_ioctl().
> 
> > I can see a couple of alternatives to this:
> > 1 - Return a different error. Maybe ENXIO?
> > or
> > 2 - Have lseek() do the trivial implementation when the VOP_IOCTL()
> > fails.
> >- For SEEK_DATA, just return the offset given as argument and
> > for SEEK_HOLE
> >   return the file's size as the offset.
> > 
> > What do others think? rick
> > ps: The man page should be updated, whatever is done w.r.t. this.
> > 
> 
> I also vote for option 2
> 

If SEEK_DATA and SEEK_HOLE don't return the standard "ioctl not
supported" error code and return a fake result, how are you supposed to
determine at runtime whether SEEK_HOLE is supported or not?

-- 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: rc script: manual stop vs system shutdown

[Ian Lepore]

On Thu, 2019-08-01 at 21:14 +0300, Andriy Gapon wrote:
> On 01/08/2019 19:12, Warner Losh wrote:
> > 
> > 
> > On Thu, Aug 1, 2019, 10:53 AM Rodney W. Grimes
> > mailto:freebsd-...@gndrsh.dnsmgr.net>>
> > wrote:
> > 
> > >
> > > Is it possible in an rc script to distinguish between a manual stop
> > > (e.g., service foo stop) and a stop during a system shutdown (via
> > > rc.shutdown) ?
> > > Are there any marker variables for that?
> > > Or something in the global system state?
> > 
> > Not that I can think of, but I like this idea,
> > I am sure that use cases exist.
> > 
> > 
> > What is the use case that needs to disambiguate the two cases...
> 
> I have one use case in mind and it's a truly special case.
> I want rc.d/watchdogd to gracefully stop watchdogd and to disable the
> watchdog timer when the stop action is requested manually.  And I want
> it to stop watchdogd and set the watchdog timer to a special shutdown
> timeout during the shutdown.  If the special timeout is configured, of
> course.
> 

The shutdown timeout is already supported:  you just set '-x '
in watchdogd_flags in rc.conf; no changes to the rc.d script needed.

I think probably you don't even need the first part of what you want. 
The -x arg covers you in the reboot case; most people probably won't
use it.  But if you are using it, and you want to truly kill the dog,
you would just do "watchdog -t 0" after "service watchdogd stop".  If
you really felt the need to cover that with a single service command,
then how about using "service watchdogd cancel" where the cancel verb
does the -t 0 after killing the daemon?

-- 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: [package - head-i386-default][sysutils/lsof] Failed for lsof-4.93.2_2,8 in build

[Ian Lepore]

On Thu, 2019-07-25 at 13:13 -0500, Larry Rosenman wrote:
> On 07/25/2019 1:10 pm, Alan Somers wrote:
> > On Thu, Jul 25, 2019 at 12:05 PM Larry Rosenman  
> > wrote:
> > > 
> > > Um  Who broke this?
> > > 
> > > /usr/src/sys/sys/refcount.h:65:12: error: use of undeclared
> > > identifier
> > > 'false'
> > >  return (false);
> > >  ^
> > > [...]
> > > 
> > "svn blame" suggests r350199 by kib.  However, refcount.h should
> > only
> > be included if lsof defines _KERNEL, which normal programs
> > shouldn't.
> > So I think this should be considered a bug in lsof.
> > -Alan
> 
> 
> we *HAVE* to define _KERNEL, to get at the kernel structures.

Then you have to follow the rules (from style(9))...

   If either  or  is needed, include it
   before other include files.  ( includes ;
   do not include both.)

Typically, if you're including anything from sys/ you'll need
sys/types.h first.

-- 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: filesystem mount problem

[Ian Lepore]

On Sun, 2019-07-21 at 15:07 -0400, AN wrote:
> Hi:
> 
> FreeBSD FreeBSD_13 13.0-CURRENT FreeBSD 13.0-CURRENT #102 r350187:
> Sat Jul 
> 20 19:04:30 EDT 2019 
> root@FreeBSD_13:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL  amd64
> 1300036
> 
> I would appreciate some help with the following problem.
> 
> /etc/fstab:
> # Device  Mountpoint  FStype  Options DumpPass#
> /dev/ada0p2   noneswapsw  0   0
> /dev/ada0p3   /   ufs rw  1   1
> linprocfs   /compat/linux/proclinprocfs   rw  0   0
> tmpfs/compat/linux/dev/shmtmpfs   rw,mode=17770   
> 0
> 
> 
> # df -h
> Filesystem SizeUsed   Avail Capacity  Mounted on
> /dev/ada0p3428G245G149G62%/
> devfs  1.0K1.0K  0B   100%/dev
> linprocfs  4.0K4.0K  0B   100%/compat/linux/proc
> tmpfs   47G4.0K 47G 0%/compat/linux/dev/shm
> tmpfs   20M604K 19M 3%/tmp
> 
> I don't understand why the /tmp is being mounted.  It is causing
> problems 
> because when I try to run portupgrade it fails for lack of space.  If
> I 
> forcibly unmount it everything breaks.
> 
> # umount -v /tmp
> umount: unmount of /tmp failed: Device busy
> [root@FreeBSD_13 ~]# umount -vf /tmp
> tmpfs: unmount from /tmp
> [root@FreeBSD_13 ~]# df -h
> Filesystem SizeUsed   Avail Capacity  Mounted on
> /dev/ada0p3428G245G149G62%/
> devfs  1.0K1.0K  0B   100%/dev
> linprocfs  4.0K4.0K  0B   100%/compat/linux/proc
> tmpfs   47G4.0K 47G 0%/compat/linux/dev/shm
> [root@FreeBSD_13 ~]# vinagre
> Unable to init server: Could not connect to 127.0.0.1: Connection
> refused
> 
> (vinagre:27111): Gtk-WARNING **: 15:04:21.599: cannot open display:
> :0
> 
> Any help would be appreciated, thanks in advance.
> 

The problem isn't that /tmp is tmpfs, the problem is that it's being
mounted by /etc/rc.d/tmp as a 20MB filesystem because tmpsize="20m" is
the default.  You could set tmpsize to some bigger value in rc.conf, or
you can add an explicit mount for /tmp in fstab so that you get the
full (47G on your system) capacity that's available:

 tmpfs /tmp tmpfs rw 0 0

-- 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: New format for binaries?

[Ian Lepore]

On Tue, 2019-07-09 at 10:51 +0400, Gleb Popov wrote:
> On Tue, Jul 9, 2019 at 1:33 AM Unidef  wrote:
> 
> > Instead of just cc files*c -o file
> > 
> > We can do
> > 
> > cc files*. -o file.c
> > 
> > And cpp file*cpp -o file.cpp
> > 
> > We can hook it up to a MySQL or a neural database? A neural
> > database is a
> > multi dimensional multi directional binary tree with a master
> > function with
> > a character array and a (double long *) malloc(double long *
> > NEURAL_SIZE);
> > index variable, and there’s a search function that searches by
> > character
> > array
> > 
> > Hopefully this doesn’t sound like spam so don’t yell at me.. <0 (dr
> > evil
> > emote)
> > 
> > Unidef
> > 
> 
> This does look like a spam generated using some AI algorithm. The
> first
> part is probably written by hand, and other one is generated. I just
> wondering what's the point of this.
> 
> For everyone else, message looking much like this was sent to llvm-
> dev@
> mail list too.
> 
> 

Everything posted from that mail address has been very obvious
straight-up trolling.  So obvious, I'm amazed anyone has replied at
all.

-- 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: Someone broke USB

[Ian Lepore]

On Sat, 2019-07-06 at 14:06 -0700, Steve Kargl wrote:
> On Sat, Jul 06, 2019 at 10:50:59PM +0200, Hans Petter Selasky wrote:
> > On 2019-07-06 21:41, Steve Kargl wrote:
> > > On Sat, Jul 06, 2019 at 08:33:39PM +0200, Hans Petter Selasky
> > > wrote:
> > > > On 2019-07-06 20:23, Steve Kargl wrote:
> > > > > So, how does one get usb working, again?
> > > > > 
> > > > > -- Steve
> > > > 
> > > > Can you show dmesg?
> > > > 
> > > 
> > > It looks like the enumeration of busses and devices has changed.
> > > grepping for uhub and usbus of the working and broken dmesg.boot
> > > gives
> > > 
> > 
> > Are you able to bisect the commit introducing the bad behaviour?
> > 
> 
> I'll give it a shot.  I have two revision number to work with.
> 

It seems almost certain to be r349161 that causes the problem.

-- 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: i2c bit banging timeout for SCL

[Ian Lepore]

On Mon, 2019-07-01 at 11:25 -0600, Warner Losh wrote:
> On Mon, Jul 1, 2019 at 11:14 AM Poul-Henning Kamp  >
> wrote:
> 
> > 
> > In message <
> > canczdfofbvmxptnel4goqxtvp6zd-xrtja4rmuo1racy0jd...@mail.gmail.com>
> > ,
> > Warner Losh writes:
> > 
> > > The only issue, really, is that this timeout is a busy loop and
> > > there may
> > > be I/O bus contention introduced on these systems.
> > 
> > Does it have to be a busy loop for the entire duration ?
> > 
> > Spin for the median, timeout+poll for the rest of the time ?
> > 
> 
> That's a good suggestion. I'd be inclined to spin for 1 tick or so,
> then do
> a timeout per tick after that (eg, shift from DELAY to pause(1)). It
> won't
> be super accurate or high performance, but when the devices are slow,
> that
> would add only a little extra time.
> 
> Ideally, that's what we'd do. In the short term, bumping the timeout
> wouldn't be horrible.
> 
> Warner

Most of the DELAY() in i2c bitbang is just the idle time before
toggling the clock line to achieve the 100khz bus rate.  That's a 10us
delay, and on modern hardware those delays should be pause() calls
because that's enough time to get useful work done.  When polling for
ack at the end of a byte, using a DELAY(1) loop makes more sense
(actually, just polling without delay may make even more sense, since
DELAY() is generally just polling a clock register).

Hmm, actually, it looks like iicbb hardcodes the bus frequency delay as
10us and delays after every toggle, so I guess it's really running the
bus at 50khz.

-- 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: i2c bit banging timeout for SCL

[Ian Lepore]

On Mon, 2019-07-01 at 19:03 +0300, Andriy Gapon wrote:
> iicbb driver has a hardcoded timeout that defines how long the driver waits 
> for
>  SCL line to go high after the driver releases it to float.  Sometimes slaves
> hold the line low until they are ready to continue with the communication.
> As a side note, the timeout means that the driver just goes on as if the line
> became high.  Maybe it should produce an error instead.
> 
> Anyway, I would like to increase the current timeout of 100 x 10us to 1000 x
> 10us.  The rationale is that there are many slave devices, like sensors, that
> take about 10 ms to return a result.  So, I think that it makes sense to play
> nice with such devices by default.
> 
> Probably I'll add a sysctl for that parameter while I'll be there.
> 
> Any objections?

Many (perhaps most?) modern i2c slave devices are both i2c and smbus
compatible, and the smbus slave timeout is 35ms, so that wouldn't be a
bad default value.

I don't think ignoring the error and forging ahead is a good idea.  It
should return an error, and perhaps it should use the bitbang bus-
recovery sequence (from iic_recover_bus.c) to unwedge the slave device.

-- 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: error: yacc.h: No such file or directory

[Ian Lepore]

On Wed, 2019-06-19 at 09:30 -0700, Rodney W. Grimes wrote:
> > In message <
> > fffbe5d47e3515c960429ab416bf2ba234f9671d.ca...@freebsd.org>
> > , Ian Le
> > pore writes:
> > > On Tue, 2019-06-18 at 07:01 -0700, Enji Cooper wrote:
> > > > > On Jun 18, 2019, at 06:59, Enji Cooper  > > > > >
> > > > > wrote:
> > > > > 
> > > > > 
> > > > > > On Jun 18, 2019, at 06:53, Ian Lepore 
> > > > > > wrote:
> > > > > 
> > > > > ...
> > > > > 
> > > > > > Last Saturday, Bryan (cc'd) made a series of commits
> > > > > > (r349061-69) 
> > > > > > that
> > > > > > were all somehow related to dependency processing in the
> > > > > > build.  I
> > > > > > don't know the details, just remember seeing some commits
> > > > > > about
> > > > > > that.
> > > > > 
> > > > > I remember that as well. This might have changed the
> > > > > dependency
> > > > > order subtly, introducing a race.
> > > > > 
> > > > > The headers might not be built in all cases in time now.
> > > > > 
> > > > > Thanks,
> > > > > -Enji
> > > > > 
> > > > > PS This is one of the reasons why I wasn???t quick to
> > > > > discount Peter
> > > > > Jeremy???s reported build issue.
> > > > 
> > > > Correction: I meant Julian Stacey.
> > > 
> > > Julian Stacey has 3 problems:
> > > 
> > >  1. Missing opt_cam.h
> > >  2. Missing yacc.h
> > >  3. A years-long inability to report a problem without hurling
> > > personal
> > > insults at the project and everyone associated with it.
> > > 
> > > Because of #3, I don't much care about 1 and 2.
> > 
> > Bingo! My point exactly!
> 
> You can't understand the frustration of 25 years of
> having system build breakage on a pretty regular basis
> as a trigger point for anger?
> 

I understand how inappropriate it is for a project member to condone or
excuse the verbal abuse of other project members.

Somone with anger management problems likely shouldn't be running
current, where a certain amount of short-term breakage is normal and
expected.

-- 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: error: yacc.h: No such file or directory

[Ian Lepore]

On Tue, 2019-06-18 at 09:51 -0700, Bryan Drewery wrote:
> On 6/18/2019 3:56 AM, Kubilay Kocak wrote:
> > Have seen another report on Twitter yesterday. Didn't see a full
> > build
> > log, but theirs was had apparently without -j, apparently on June
> > 14
> > sources:
> > 
> > Error:
> > /usr/src/usr.bin/mkesdb/lex.1:46:10: fatal error: 'yacc.h' file not
> > found
> > 
> > Have not heard back from them whether it continued after trying -j2
> > but
> > I did ask them to hit up freebsd-current if it continued to be an
> > issue
> 
> Even -j1 should avoid it. For some reason I am only seeing it without
> any -j flag at all.
> 
> I should have a fix in soon.
> 

There's a subtle difference between -j1 and no -j at all, having to do
with running in "compatibility mode".  I forget the details, but I
remember being burned by the difference once. :)

-- 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: error: yacc.h: No such file or directory

[Ian Lepore]

On Tue, 2019-06-18 at 07:01 -0700, Enji Cooper wrote:
> > On Jun 18, 2019, at 06:59, Enji Cooper 
> > wrote:
> > 
> > 
> > > On Jun 18, 2019, at 06:53, Ian Lepore  wrote:
> > 
> > ...
> > 
> > > Last Saturday, Bryan (cc'd) made a series of commits (r349061-69) 
> > > that
> > > were all somehow related to dependency processing in the
> > > build.  I
> > > don't know the details, just remember seeing some commits about
> > > that.
> > 
> > I remember that as well. This might have changed the dependency
> > order subtly, introducing a race.
> > 
> > The headers might not be built in all cases in time now.
> > 
> > Thanks,
> > -Enji
> > 
> > PS This is one of the reasons why I wasn’t quick to discount Peter
> > Jeremy’s reported build issue.
> 
> Correction: I meant Julian Stacey.

Julian Stacey has 3 problems:

 1. Missing opt_cam.h
 2. Missing yacc.h
 3. A years-long inability to report a problem without hurling personal
insults at the project and everyone associated with it.

Because of #3, I don't much care about 1 and 2.

-- 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: error: yacc.h: No such file or directory

[Ian Lepore]

On Tue, 2019-06-18 at 06:45 -0700, Cy Schubert wrote:
> On June 18, 2019 6:24:36 AM PDT, Michael Tuexen 
> wrote:
> > > On 18. Jun 2019, at 12:56, Kubilay Kocak 
> > > wrote:
> > > 
> > > On 18/06/2019 5:42 pm, Michael Tuexen wrote:
> > > > Dear all,
> > > > I'm trying to run
> > > > sudo make buildworld
> > > > in a directory with r349168.
> > > > The result is:
> > > > cc  -O2 -pipe -I/usr/home/tuexen/head/usr.bin/mkesdb_static
> > 
> > -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../mkesdb 
> > -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../../lib/libc/iconv 
> >  -g
> > -MD  -MF.depend.lex.o -MTlex.o -std=gnu99
> > -I/usr/obj/usr/home/tuexen/head/powerpc.powerpc64/tmp/legacy/usr/in
> > clude
> > -c lex.c -o lex.o
> > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:46:18: error:
> > > > yacc.h: No
> > 
> > such file or directory
> > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l: In function
> > > > 'yylex':
> > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: 'R_LN'
> > 
> > undeclared (first use in this function)
> > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: (Each
> > 
> > undeclared identifier is reported only once
> > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: for each
> > 
> > function it appears in.)
> > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:72: error: 'yylval'
> > 
> > undeclared (first use in this function)
> > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:73: error: 'L_IMM'
> > 
> > undeclared (first use in this function)
> > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:76: error: 'R_NAME'
> > 
> > undeclared (first use in this function)
> > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:77: error:
> > > > 'R_ENCODING'
> > 
> > undeclared (first use in this function)
> > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:78: error:
> > > > 'R_VARIABLE'
> > 
> > undeclared (first use in this function)
> > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:79: error:
> > > > 'R_DEFCSID'
> > 
> > undeclared (first use in this function)
> > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:80: error:
> > > > 'R_INVALID'
> > 
> > undeclared (first use in this function)
> > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:88: error:
> > > > 'L_STRING'
> > 
> > undeclared (first use in this function)
> > > > *** Error code 1
> > > > Stop.
> > > > make[3]: stopped in /usr/home/tuexen/head/usr.bin/mkesdb_static
> > > > *** Error code 1
> > > > Stop.
> > > > make[2]: stopped in /usr/home/tuexen/head
> > > > *** Error code 1
> > > > Stop.
> > > > make[1]: stopped in /usr/home/tuexen/head
> > > > *** Error code 1
> > > > Stop.
> > > > make: stopped in /usr/home/tuexen/head
> > > > This is on a 64 bit PPC system. Doing sudo rm -rf /usr/obj does
> > > > not
> > 
> > resolve the issue.
> > > > Any idea what is going wrong?
> > > > Best regards
> > > > Michael
> > > 
> > > Have seen another report on Twitter yesterday. Didn't see a full
> > 
> > build log, but theirs was had apparently without -j, apparently on
> > June
> > 14 sources:
> > > 
> > > Error:
> > > /usr/src/usr.bin/mkesdb/lex.1:46:10: fatal error: 'yacc.h' file
> > > not
> > 
> > found
> > > 
> > > Have not heard back from them whether it continued after trying
> > > -j2
> > 
> > but I did ask them to hit up freebsd-current if it continued to be
> > an
> > issue
> > OK, I started the build again with -j 2 and it seems that the
> > problem
> > does not occur.
> > 
> > Since I have been using make buildworld without -j n in the past on
> > that machine, the
> > problem seems to be introduced recently. Any idea what is the cause
> > of
> > the problem?
> > 
> > Best regards
> > Michael
> > > 
> > 
> > ___
> > 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"
> 
> This is a generated file. It would appear the make target to build
> yacc.h hadn't run yet by the time the target that consumed the file
> ran.
> 
> I had a similar problem on Sunday. It wasn't yacc.h but some other
> file, I cannot remember which. It occurred during one of four
> buildworlds. Simply restarting the failed buildworld was enough to
> resolve it.
> 
> My hypothesis is a buildworld race. I wonder if some of the recent
> (over the last week or two) makefile changes exacerbated this issue.
> 
> 

Last Saturday, Bryan (cc'd) made a series of commits (r349061-69) that
were all somehow related to dependency processing in the build.  I
don't know the details, just remember seeing some commits about that.

-- 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: sys/modules/sdio broken in .svn_revision 348842 'opt_cam.h' not found

[Ian Lepore]

On Tue, 2019-06-18 at 02:21 +0200, Julian H. Stacey wrote:
> "Julian H. Stacey" wrote:
> > "Bjoern A. Zeeb" wrote:
> > > On 17 Jun 2019, at 10:37, Mark Linimon wrote:
> > > 
> > > > On Mon, Jun 17, 2019 at 11:41:03AM +0200, Julian H. Stacey
> > > > wrote:
> > > > > svn_revision 348842
> > > > 
> > > > [ ...]
> > > > > /usr/src/sys/modules/sdio/../../dev/sdio/sdiob.c:68:10: fatal
> > > > > error:
> > > > >   'opt_cam.h' file not found
> > > > > #include "opt_cam.h"
> > > > >  ^~~
> > > > > 1 error generated.
> > > > 
> > > > This is extremely unlikely to be r348842.  I would investigate
> > > > r349025
> > > > instead.  (Committer Cc:ed.)
> > > 
> > > Almost, more likely me.  I just had a look.  I am not exactly
> > > sure how 
> > > to reproduce this?
> > > 
> > > /bz
> > 
> > If I can help let me know.
> > My buildworld broke with 13.0-CURRENT 
> > /usr/src .ctm_status src-cur 14077 .svn_revision 348842
> > I'm now running make install, 
> > & can then compare my root include & libs with with a set
> > installed 
> > using DESTDIR=
> 
> I compiled, installed, compared.  
>   BTW cd /usr/src; make delete  - only cleans libs & bins but does
> not
>   clean other junk listed in ObsoleteFiles.inc not even with
>   -DBATCH_DELETE_OLD_FILES or -DBATCH_DELETE_OLD_FILES=YES so
> manually purged,
> I believe I have a clean system built from .ctm_status src-cur 14077
> .svn_revision 348842 but /usr/src/sys/modules/sdio still fails,
> so there was a commit of unbuildable code.
> 
> cd /usr/src ; find . -name opt_cam.h  # tools/tools/vhba/opt_cam.h
> cd /usr/include ; find . -name opt_cam.h  # nothing
> 
> 
> > I have a 2nd slower current box also building to 14077, I will then
> > take that on up to latest .ctm_status src-cur 14087 .svn_revision
> > 349129 to see if problem clears.
> 
> make buildworld blew on newer current, with a different bug:
> 
> cc  -O2 -pipe -I/usr/src/usr.bin/mkesdb_static
> -I/usr/src/usr.bin/mkesdb_static/../mkesdb  -
> I/usr/src/usr.bin/mkesdb_static/../../lib/libc/iconv  -g -MD  -
> MF.depend.lex.o -MTlex.o -std=gnu99  -Qunused-arguments   -
> I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -c lex.c -o
> lex.o
> /usr/src/usr.bin/mkesdb/lex.l:46:10: fatal error: 'yacc.h' file not
> found
> #include "yacc.h"
>  ^~~~
> 1 error generated.
> *** Error code 1
> 
> Stop.
> make[3]: stopped in /usr/src/usr.bin/mkesdb_static
> 
> A double waste of CPU & human time & power in a hot office.
> Commit bits used to be suspended for un-buildable code. I'll boot
> stable.

Since you seem to be so focused on mean-spirited criticism of others,
I'm sure you'll understand when I ask...

Have you *seriosly* been using and building freebsd this long and you
don't know that an opt_*.h file is generated as part of the build and
exists only in the object directory, so that searching for it under
/usr/src or /usr/include would be... let's see, how did you put it?...
Oh yeah: A double waste of CPU & human time.

-- 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: lib/libgcc_s fails on make all after make world succeeds

[Ian Lepore]

On Sun, 2019-05-19 at 23:54 +0200, Dimitry Andric wrote:
> On 19 May 2019, at 23:29, Julian H. Stacey  wrote:
> > 
> > Hi curr...@freebsd.org
> > On current src/ on 2 boxes, I have seen the same break for a week
> > or 2,
> > lib/libgcc_s fails on make all after make world succeeds,
> > Anyone else seen it or got ideas please ? Notes below the sample.
> > 
> > ===> lib/libgcc_s (all)
> > building shared library libgcc_s.so.1
> > cc  -nodefaultlibs -Wl,--version-
> > script=/usr/src/lib/libgcc_s/Version.map
> > -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel  -o \
> > libgcc_s.so.1.full -Wl,-soname,libgcc_s.so.1
> 
> ...
> > -L/usr/obj/usr/src/amd64.amd64/lib/libc -lc \
> > ld: error: can't create dynamic relocation R_X86_64_32S \
> > against symbol: __je_sz_size2index_tab in readonly segment; \
> > recompile object files with -fPIC or pass '-Wl,-z,notext' \
> > to allow text relocations in the output
> > > > > defined in
> > > > > /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a(jemalloc_sz.o)
> 
> It looks like for some reason, it chooses to link with libc.a instead
> of
> libc.so here.  Maybe your libc.so is not getting built at all,
> because
> of your environment?
> 
> Or maybe you are hitting some build race where libc.a is done, but
> libc.so is still being built, while at the same time, libgcc_s.so.1
> is
> being linked?
> 
> There are some difficult-to-reproduce races with libgcc_s, which are
> sometimes also hit by CI (I think Li-Wen mentioned them multiple
> times
> now).  But usually I would expect this to be "solved" by simply
> re-running buildworld, as the race window is very small, and you have
> to be quite lucky (or unlucky, depending on your point of view :) to
> hit
> it.
> 
> -Dimitry
> 

There is definitely something racy going on here.  I ran into 

  /usr/bin/ld: error: unable to find library -lgcc_s

Just a couple minutes into a build with an empty /usr/obj.  I killed
it, re-emptied /usr/obj, and started it again, and it didn't repeat the
problem.

Also, I noticed that libgcc_eh and libgcc_s seem to be getting built
twice in parallel here (this is about 2 minutes into a build of 12-
stable on a 12-stable system) with -j16, so all of these libs started
building together...

--
>>> stage 4.2: building libraries
--
===> lib/libcompiler_rt (obj,all,install)
===> gnu/lib/libssp/libssp_nonshared (obj,all,install)
===> lib/libgcc_eh (obj,all,install)
===> lib/libgcc_s (obj,all,install)
===> gnu/lib/csu (obj,all,install)
===> lib/libcompiler_rt (obj,all,install)
===> lib/csu (obj,all,install)
===> lib/libc_nonshared (obj,all,install)
===> lib/libc (obj,all,install)
===> lib/libgcc_eh (obj,all,install)
===> lib/csu/amd64 (all)
===> lib/csu/amd64 (install)
===> lib/libgcc_s (obj,all,install)
===> lib/libcxxrt (obj,all,install)

I've seen some bad things happen in the past when parallel jobs try to
build in the same directory.

-- 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: ci.freebsd.org: powerpcspe build failing due to linker error in assembly code

[Ian Lepore]

On Mon, 2019-05-20 at 17:54 -0700, Enji Cooper wrote:
> Hi,
>   The following build issue has been cropping up over the past 6 hours. 
> From https://ci.freebsd.org/job/FreeBSD-head-powerpcspe-build/11154/console :
> 
> 12:49:01 /usr/src/stand/powerpc/kboot/kerneltramp.S: Assembler messages:
> 12:49:01 /usr/src/stand/powerpc/kboot/kerneltramp.S:88: Error: Unrecognized 
> opcode: `rldicr'
> 12:49:01 /usr/src/stand/powerpc/kboot/kerneltramp.S:96: Error: Unrecognized 
> opcode: `rfid'
> 
>   This code hasn’t changed for some time. I’m not sure what
> triggered the issue, but I suspect it has to deal with an external
> [toolchain] change.
> Cheers!
> -Enji


r347992 seems like a good candidate.

-- 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: Inability to build FreeBSD-current amd64

[Ian Lepore]

On Wed, 2019-05-15 at 23:23 +, Thomas Mueller wrote:
> What do most FreeBSD users who rebuild system from source do
> regarding WITH_CLANG_EXTRAS in /etc/src.conf ?
> 
> I have WITH_CLANG_EXTRAS=yes in /etc/src.conf and wonder if that
> could be screwing my build.
> 
> Build seems to stumble on the llvm stuff, and llvm has really bloated
> in recent times.
> 
> But then if I remove WITH_CLANG_EXTRAS, would I face great trouble
> with llvm in the ports, where llvm is so critical to the bigger
> things including Xorg?
> 
> Would removing WITH_CLANG_EXTRAS also reduce the build time which has
> been around 6:45 (hours:minutes) just to fail?
> 
> 
> Tom
> 

In general, WITH_CLANG_EXTRAS controls the building of extra tools such
as a disassembler, and tools for working on clang itself such as bug
reporting tools.  I don't have a really detailed answer because I've
never enabled the option.  I've always perceived it as being something
most people don't need.  WITHOUT_CLANG_EXTRAS may cut some time from
your build, but it probably won't cut it in half or anything.

-- 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: Inability to build FreeBSD-current amd64

[Ian Lepore]

On Wed, 2019-05-15 at 19:26 +, Thomas Mueller wrote:
> from tech-lists:
> 
> > What do you do before buildworld?
> 
> 
> > I'll rm -rf /usr/obj and /var/cache/ccache [1], create them again,
> > then in
> > /usr/src I'll do this:
> > make -j32 cleanworld && make -j32 cleandir && make -j32 clean
> 
> 
> > before make buildworld. it's probably overkill but it'll for sure
> > clean
> > away any cruft
> > [1] make sure they get deleted without error. I've encountered
> > bad_file_descriptor error in ccache dir before and it caused all
> > kinds
> > of errors when building, which looked like build errors but obv.
> > were
> > not.
> 
> I did rm -R /usr/obj/* , so everything there was clean as far as I
> could see.
> 
> I had no /var/cache/cache .
> 
> I could still try to build current from the old current from August
> 2, 2017, or STABLE-12 from the old 11.1-STABLE from July 30, 2017.
> 
> Otherwise I still have stuff to do with NetBSD and Linux toolchains
> (OpenWRT, buildroot, crosstool-ng and ptxdist from Pengutronix).
> 
> Is there anything comparable to 
> https://releng.netbsd.org/cgi-bin/builds.cgi , but for FreeBSD?
> 
> If I see 0 passed, 67 failed for NetBSD-HEAD, I figure I should wait
> for a better time.  But what about FreeBSD?
> 
> Tom

A couple different views on the freebsd build CI...

https://ci.freebsd.org/
https://ci.freebsd.org/tinderbox/

-- 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: FCP-101: obsolete driver removal planned for 2019-05-18

[Ian Lepore]

On Sun, 2019-05-12 at 10:45 -0700, Rodney W. Grimes wrote:
> > 12.05.2019 8:21, Warner Losh wrote:
> > 
> > > >> I've posted a review to remove obsolete 10 and 10/100
> > > Ethernet drivers
> > > >> as previous approved in FCP-101.
> > > >> The following drivers are slated for
> > > >> removal from FreeBSD-HEAD (to be FreeBSD-13):
> > > >> ae, bm, cs, de, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp,
> > > vx, wb, xe
> > > > OMG ! ed ! That EOL's loads of PC boxes I have (& a show
> > > box of
> > > > spare)  that will never be able to upgrade.
> > > Do those boxes have 10M-only or 100Mbps variants of ed(4)?
> > > What kind of hardware do they have (CPU and memory-wise)?
> > > 
> > > There are no 100M ed variants. There are some PC Card variants
> > > that have 100M MII connections, but they are limited to about
> > > 12Mbps due to bus limits. Even the PCI ones didn't have 100M mii
> > > connections. 
> > 
> > There was RTL8029AS "NE2000-compatible" 100M 32 bit PCI 2.1
> > adapter.
> > Not sure if ed(4) supports RTL8029AS.
> 
> That is what I was hunting for, but I can not seem to
> locate a data sheet on that.  
> 
> I also thought there was a 100mb version of the DP83905,
> but can not seem to locate any data thier either.
> 
> Given this lack of findable data I shall continue to support
> the ed removal, unless Julian comes up with the needed criteria,
> and with holding my own fact that I do have a pile of these
> around, but they are not in use and are only retained for
> testing and resurection of ancient things.
> 

We should not lose track of the fact that the operative question here
isn't "are you using an ed(4) device?", but rather "do you have systems
containing an ed(4) device which are capable of running freebsd 13 and
that you plan on updating to freebsd 13 or later?"

Many of the systems that contained these old devices don't have enough
ram to run a modern version of freebsd.  If you can't update the system
to 13, you don't need ongoing ed(4) support.  And make no mistake,
ongoing support IS the issue -- it costs manpower we don't have much of
to maintain old device drivers.

-- 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: random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy.

[Ian Lepore]

On Wed, 2019-05-08 at 19:13 +0300, Andrey V. Elsukov wrote:
> Hi,
> 
> today I updated one of my test machines and discovered that message
> from
> the subject periodically printed in the console.
> 
> FreeBSD 13.0-CURRENT r347327=4f47587(svn_head) GENERIC-NODEBUG amd64
> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on
> LLVM 8.0.0)
> VT(vga): resolution 640x480
> CPU: Intel(R) Xeon(R) CPU E5-2660 v4@ 2.00GHz (2000.04-MHz K8-class
> CPU)
> ...
> real memory  = 68719476736 (65536 MB)
> avail memory = 66722340864 (63631 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: 
> FreeBSD/SMP: Multiprocessor System Detected: 28 CPUs
> FreeBSD/SMP: 2 package(s) x 14 core(s)
> ...
> 
> % grep -c random /var/run/dmesg.boot
> 606
> 
> % grep random /var/run/dmesg.boot | head -10
> __stack_chk_init: WARNING: Initializing stack protection with non-
> random
> cookies!
> random: entropy device external interface
> random: registering fast source Intel Secure Key RNG
> random: fast provider: "Intel Secure Key RNG"
> arc4random: WARNING: initial seeding bypassed the cryptographic
> random
> device because it was not yet seeded and the knob
> 'bypass_before_seeding' was enabled.
> random_sources_feed: rs_read for hardware device 'Intel Secure Key
> RNG'
> returned no entropy.
> random_sources_feed: rs_read for hardware device 'Intel Secure Key
> RNG'
> returned no entropy.
> random_sources_feed: rs_read for hardware device 'Intel Secure Key
> RNG'
> returned no entropy.
> random_sources_feed: rs_read for hardware device 'Intel Secure Key
> RNG'
> returned no entropy.
> random_sources_feed: rs_read for hardware device 'Intel Secure Key
> RNG'
> returned no entropy.
> 
> % sysctl -a | grep -v random_sources_feed | grep rand
> kern.fallback_elf_brand: -1
> devicerandom
> devicerdrand_rng
> kern.randompid: 0
> kern.elf32.fallback_brand: -1
> kern.elf64.fallback_brand: -1
> kern.random.fortuna.minpoolsize: 64
> kern.random.harvest.mask_symbolic:
> PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN
> ,MOUSE,KEYBOARD,ATTACH,CACHED
> kern.random.harvest.mask_bin: 000100011101
> kern.random.harvest.mask: 66015
> kern.random.use_chacha20_cipher: 0
> kern.random.block_seeded_status: 0
> kern.random.random_sources: 'Intel Secure Key RNG'
> kern.random.initial_seeding.disable_bypass_warnings: 0
> kern.random.initial_seeding.arc4random_bypassed_before_seeding: 1
> kern.random.initial_seeding.read_random_bypassed_before_seeding: 0
> kern.random.initial_seeding.bypass_before_seeding: 1
> net.inet.ip.portrange.randomtime: 45
> net.inet.ip.portrange.randomcps: 10
> net.inet.ip.portrange.randomized: 1
> net.inet.ip.random_id_total: 0
> net.inet.ip.random_id_collisions: 0
> net.inet.ip.random_id_period: 0
> net.inet.ip.random_id: 0
> net.key.int_random: 60
> debug.fail_point.status_fill_kinfo_vnode__random_path: off
> debug.fail_point.fill_kinfo_vnode__random_path: off
> debug.fail_point.status_random_fortuna_pre_read: off
> debug.fail_point.random_fortuna_pre_read: off
> security.stack_protect.permit_nonrandom_cookies: 1
> 

Fixed in r347329.

--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: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)

[Ian Lepore]

On Fri, 2019-01-18 at 21:24 +0300, Lev Serebryakov wrote:
> On 18.01.2019 21:14, Toomas Soome wrote:
> 
> > errm.. you press a key and enter device and or loader path. if it is not 
> > working - the code is there to be fixed.
> 
>  And loader looks to "bootme" attribute and try to boot from partition
> which has one, even if it is loaded from other partition itself.
> 

I am catching up, very late, on this old thread.  What Toomas was
describing does work, but it was broken for a long time.  It got fixed
in r341071 last November.

I hate the syntax, but at the gptboot boot prompt (boot:) you can enter
"da(D,P)" and gptboot will run loader(8) from that drive number D,
partition number P, and (after r341071) it will pass that info properly
so that loader(8) will attempt to load the kernel from the same
drive/partition.

IMO, it would be nice if "currdev syntax" worked too, so you could just
enter disk3p4 or similar.  I may look into adding that to the code.

-- Ian


> > GPT does not have the concept of active partition.
> 
>  It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't have
> any tools to set these attributes, AFAIK. Same for UEFI boot code.
> 

___
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: Question about 'gptzfsboot'

[Ian Lepore]

On Mon, 2019-04-29 at 14:47 -0400, Thomas Laus wrote:
> On 2019-04-29 14:27, Thomas Laus wrote:
> > It was more than a broken console.  All of the other 2 computers
> > that I
> > upgraded to r346885 were essentially 'dead'.  I could not even
> > remotely
> > login to them via ssh.  All of them required a hard power button
> > reset
> > to get into single user mode to let me comment out the rc.conf line
> > that
> > loads the DRM driver.  The computer could successfully boot without
> > DRM
> > activation but would go to a black console screen again with
> > 'startx'.
> > This also required a hard power button shutdown.  I rolled back to
> > r346544 and everything worked again like before.
> > 
> > My disastrous update to r346885 included installing a new
> > gptzfsboot and
> > pmbr in the drive boot record.  I did not try booting an older
> > kernel
> > using the new gptzfsboot.  I was concerned about the lack of ssh
> > login
> > when the computers lost their console, so I just rolled back my
> > system
> > to the last snapshot made a week ago.
> > 
> 
> Ian:
> 
> I re-activated the r346885 BEADM snapshot and booted from my
> 'kernel.old' from r346544 and everything came up OK including 'X'.
> 
> I don't know what that means.  It might be that I have a DRM issue
> instead of a gptzfsboot problem?  Everything except for the kernel is
> now running CURRENT r346885.  I am not using the updated
> drm-current-kmod because I am using the r346544 kernel.old.
> 
> Tom
> 
> 

I can't say anything at all about drm or other video driver issues, I'm
just not knowledgeable about that stuff at all.

The only thing I was getting at was that the changes I made in r346675
might make this error stop happening:

   gptzfsboot: error 1 LBA 18446744072709551608
   gptzfsboot: error 1 LBA 1
   gptzfsboot: No ZFS pools located, can't boot

Emphasis on the "might"... that appears to be an error during probing
for zfs, and I made some fixes related to probing for zfs.

-- 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: Question about 'gptzfsboot'

[Ian Lepore]

On Mon, 2019-04-29 at 10:33 -0400, Thomas Laus wrote:
> > On 2019-04-28 22:27, Ian Lepore wrote:
> > > 
> > > If you're using gptzfsboot, I guess you're using zfs?  I just
> > > fixed a
> > > problem with probing disks for zfs volumes a few days ago
> > > (r346675). 
> > > There is even some small chance it fixes this problem, because
> > > one of
> > > the things I noticed was that in one of the disk structures in
> > > loader,
> > > the "slice offset" value was sometimes a bit random-looking, like
> > > it
> > > was being initialized with whatever garbage was laying around in
> > > memory.  It actually makes some sense that the "garbage" might be
> > > different between a firstboot after power-on and a reboot.
> > > 
> > > So all in all, it wouldn't hurt to update both gptzfsboot and
> > > loader
> > > (gpart bootcode -b and -p) to see if there's a fix lurking in my
> > > zfs
> > > probe changes.
> > > 
> > 
> > I'll build and update my laptop OS this morning and report back to
> > this
> > thread if I have any additional issues.
> > 
> 
> Ian:
> 
> Updating to r346885 turned out to be a disaster!  There were changes
> to
> DRM between FreeBSD 13.0-CURRENT r346544 and r346885.  The desktop
> that
> I use for a build machine because it is much faster than any of my
> other
> PC's installed kernel and world without any problems including
> starting
> 'X'.  I had to update the drm-current-kmod port on my build
> PC.  Nothing
> was in /usr/src/UPDATING or /usr/ports/UPDATING about the need to do
> so.
>  DRM on my build computer did not start until the update and then
> worked
> as expected.
> 
> I did the same on my Dell laptop and it crashed on the first boot
> right
> after loading DRM-kmod.  I removed the line in rc.conf that activates
> the kernel module and my laptop booted into multiuser.  When I
> started
> 'X' it crashed just like before.  The screen was black and I could
> not
> login remotely via SSH.  Nothing in any system log.  The Xorg log
> shows
> this and stops:
> 
>  40.979]compiled for 1.18.4, module version = 2.4.0
> [40.979]Module class: X.Org Video Driver
> [40.979]ABI class: X.Org Video Driver, version 20.0
> [40.979] (II) intel: Driver for Intel(R) Integrated Graphics
> Chipsets:
> i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM,
> 865G,
> 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
> Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33,
> Q35,
> Q33,
> GM45, 4 Series, G45/G43, Q45/Q43, G41, B43
> [40.981] (II) intel: Driver for Intel(R) HD Graphics
> [40.981] (II) intel: Driver for Intel(R) Iris(TM) Graphics
> [40.981] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics
> [40.981] (II) modesetting: Driver for Modesetting Kernel Drivers:
> kms
> [40.981] (II) scfb: driver for wsdisplay framebuffer: scfb
> [40.981] (II) VESA: driver for VESA chipsets: vesa
> [40.981] (--) Using syscons driver with X support (version 2.0)
> [40.981] (--) using VT number 9
> 
> I had to recover my system using beadm to rollback to the last
> CURRENT
> snapshot from a week ago.
> 
> Tom
> 
> 

I'm fighting my own video driver troubles (seems like a lot of that
going around lately); on an upgrade of a machine from 11-stable to 12-
stable I lost my console.

But, a broken kernel and/or userland shouldn't affect your ability to
use the new boot components.  That is, you can use gptzfsboot and
loader that contain my fixes, and use them to load an older kernel that
has working video drivers.

-- 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: Question about 'gptzfsboot'

[Ian Lepore]

On Sun, 2019-04-28 at 19:29 -0400, Thomas Laus wrote:
> On 2019-04-28 08:07, Ronald Klop wrote:
> > 
> > Is this the same as this?
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=144234
> > 
> 
> The messages are similar.  The boot process will normally proceed on
> the
> second or third attempt.  On some days, I don't see this message
> appear
> and my laptops boot normally.  I don't think that this problem is
> hardware related.  One laptop is a Compaq Pavilion with an AMD Turion
> CPU and the other is a Dell Inspiron with an Intel Core2 Duo
> CPU.  One
> hard drive is mechanical and the other is a SSD.  I have swapped hard
> drives between the two laptops and the issue still shows up on
> occasion
> with each PC.  I have never seen this issue on any of my desktop
> computers.  Everything is running FreeBSD 13.0-CURRENT r346544
> GENERIC-NODEBUG at the moment.  The thread in the bug report also
> shows
> a smaller LBA number, mine is LBA 18446744072709551608 and much
> further
> in geometry than most of the reported issues.  I have seen this issue
> since FreeBSD 12 was CURRENT.  Since the boot process will work on a
> second or third boot attempt, it is not a show stopper for me.
> 
> Tom
> 

If you're using gptzfsboot, I guess you're using zfs?  I just fixed a
problem with probing disks for zfs volumes a few days ago (r346675). 
There is even some small chance it fixes this problem, because one of
the things I noticed was that in one of the disk structures in loader,
the "slice offset" value was sometimes a bit random-looking, like it
was being initialized with whatever garbage was laying around in
memory.  It actually makes some sense that the "garbage" might be
different between a firstboot after power-on and a reboot.

So all in all, it wouldn't hurt to update both gptzfsboot and loader
(gpart bootcode -b and -p) to see if there's a fix lurking in my zfs
probe changes.

-- 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: How to hotplug a PCI device (such as VF) on FreeBSD

[Ian Lepore]

On Mon, 2019-03-25 at 08:49 +, Hongxiong Xian (Wicresoft North
America Ltd) wrote:
> Hi,
> 
> I'm looking for a way to refresh the pci device list.
> In Linux, we can remove a particular pci device, and then after
> preforming a "rescan" the device will appear again.
> For example, disable/rescind PCI (such as VF) :
> echo 1 >  /sys/bus/pci/devices/0001\:00\:02.0/remove
> # Get the device back
> echo 1 > /sys/bus/pci/rescan
> 
> I'm looking for a similar way in FreeBSD. Does the FreeBSD support
> the hotplug of a PCI device?  Thanks in advance!
> 
> 

I think 'devctl rescan' will do that, 'man devctl' for details.

-- 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: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

[Ian Lepore]

On Thu, 2019-02-28 at 11:06 -0800, Conrad Meyer wrote:
> On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl
>  wrote:
> > This is interesting as well.  Does this mean that amd64 is now
> > the only tier 1 platform and all other architectures are after
> > thoughts?
> 
> This has been the de facto truth for years.  i386 is mostly only
> supported by virtue of sharing code with amd64.  There are efforts to
> promote arm64 to Tier 1, but it isn't there yet.  Power8+ might be
> another good alternative Tier 1 candidate eventually.  None have
> anything like the developer popularity that amd64 enjoys.
> 
> 

I have been of the opinion that armv[67] has met all the bullet points
to be a tier-1 arch for several years, but nobody seemed interested in
declaring it so.  Now it'll never happen, because there seems to be
growing momentum to throw everything 32-bit under the bus and declare
freebsd to be a 64-bit-only OS.  Netflix wins; those of us building
smaller embedded products will eventually be forced to move to linux.

-- 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: What is evdev and autoloading?

[Ian Lepore]

On Mon, 2019-02-18 at 08:50 -0800, Steve Kargl wrote:
> On Mon, Feb 18, 2019 at 09:11:14AM -0700, Warner Losh wrote:
> > 
> > You do know these constant complaints about people trying to make
> > things
> > better is demoralizing and counter productive.
> > 
> 
> You do realize some of the emails are from frustrated users
> who are trying to make FreeBSD (see for example libm).  
> 

And do you realize that you've trimmed away all the context so that now
it looks like Warner was talking to you, when in fact he was replying
to Rod? I sure hope that was an accident.

-- 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: What is evdev and autoloading?

[Ian Lepore]

On Sun, 2019-02-17 at 16:24 -0800, Steve Kargl wrote:
> On Sun, Feb 17, 2019 at 03:04:41PM -0800, Mark Millard wrote:
> > 
> > 
> > On 2019-Feb-17, at 10:03, Steve Kargl  > troutmask.apl.washington.edu> wrote:
> > 
> > Anyone have insight into what evdev is?  There appears to
> > be no manual page.  When I reboot a system with custom
> > kernel, the system is autoloading evdev.ko, uhid.ko, and
> > wmt.ko.  I do not need nor what these modules loaded.
> > How does one prevent this autoloading?
> > 
> > Looking via the web lead to:
> > 
> > 
https://www.freebsd.org/cgi/man.cgi?query=evdev=0=4=FreeBSD+12.0-RELEASE=default=html
> > So:
> > 
> > NAME
> >evdev - Generic Linux input driver
> > 
> > DESCRIPTION
> > 
> > evdev is an Xorg input driver for Linux's generic event
> > devices. It
> > therefore supports all input  devices  that  the kernel  kn
> > ows about,
> > including most mice, keyboards, tablets and touchscreens. evdev
> > is the default driver on the major Linux distributions.
> > . . .
> > 
> > 
> > 
> > but it seems to not have a 13-current entry. It does have
> > a 12.0-RELEASE entry.
> > 
> 
> Thanks.  Kinda odd that freebsd-current doesn't have a manual
> page, but FreeBSD-12 does.
> 

That manpage you found online is in section 4x. It probably gets
installed along with the xf86-input-evdev package.

-- 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: problem building dev/e1000

[Ian Lepore]

On Fri, 2019-02-15 at 12:32 -0700, Warner Losh wrote:
> On Fri, Feb 15, 2019 at 12:17 PM Ian Lepore  wrote:
> 
> > On Fri, 2019-02-15 at 10:53 -0800, Enji Cooper wrote:
> > > > [...]
> > > 
> > > HO Eric!
> > > 
> > > iflib was a recently added requirement on stable/12 IIRC..?
> > > 
> > > Does the manpage note this dependency, and is there an UPDATING
> > > entry
> > > for this change?
> > > 
> > > Thanks!
> > > -Enji
> > > 
> > 
> > My question would be: why? If some drivers have a new dependency on
> > iflib, why isn't that expressed in sys/conf/files and handled
> > automatically?
> > 
> 
> Right now we have
> 
>  files:net/iflib.c optional ether pci iflib
> 
> in the files file. This would need to change to
> 
> files:net/iflib.c optional ether pci (em | igb | ...)
> 
> but we don't have a () operator in config. Or we'd need dozens of
> lines,
> and the duplicate elimination code in config has been tricky (though
> I
> didn't check it just now).
> 
> Warner
> 

I guess the question would be how many things does '...' represent now
and in the future?  What it would need to be, given our current
inflexible config(8) is

 net/iflib.c optional ether pci em | ether pci igb | ...

So if ... is 2 or 3 more drivers, that's not so bad.  If iflib is
eventually going to be used by dozens of drivers, even the parens would
make for a pretty ugly solution.

-- 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: problem building dev/e1000

[Ian Lepore]

On Fri, 2019-02-15 at 10:53 -0800, Enji Cooper wrote:
> > On Feb 15, 2019, at 10:46, Eric Joyner  wrote:
> > 
> > ifdi_if.h is a system generated interface file that network drivers
> > that depend on iflib use. It's generated from ifdi_if.m in sys/net.
> > 
> > My guess is that you don't have "device iflib" defined in your
> > kernel configuration. em(4) depends on iflib in FreeBSD 12/13, and
> > with r343617, iflib is now explicitly a module that needs to be
> > included in your kernel config if you want to use a driver that
> > depends on it. It's already in the GENERIC kernel for amd64; are
> > you using a kernel config file that doesn't inherit from GENERIC?
> 
> HO Eric!
> 
> iflib was a recently added requirement on stable/12 IIRC..?
> 
> Does the manpage note this dependency, and is there an UPDATING entry
> for this change?
> 
> Thanks!
> -Enji
> 

My question would be: why? If some drivers have a new dependency on
iflib, why isn't that expressed in sys/conf/files and handled
automatically?

-- 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: kernel build dies with "unknown option"

[Ian Lepore]

On Wed, 2019-02-13 at 18:29 -0500, Robert Huff wrote:
>   On a system running:
> 
> FreeBSD 13.0-CURRENT r343080 16 Jan 2019  amd64
> 
>   I updated the source tree as of midnight US Eastern time, then
> ran buildworld.  That completed successfully.
>   Then:
> 
> huff@jerusalem> make buildkernel KERNCONF=JERUSALEM
> make[1]: "/usr/src/Makefile.inc1" line 349: SYSTEM_COMPILER: libclang
> will be built for bootstrapping a cross-compiler.
> make[1]: "/usr/src/Makefile.inc1" line 352: SYSTEM_LINKER: Determined
> that LD=ld matches the source tree.  Not bootstrapping a cross-
> linker.
> 
> --
> > > > Kernel build for JERUSALEM started on Wed Feb 13 18:20:44 EST
> > > > 2019
> 
> --
> ===> JERUSALEM
> mkdir -p /usr/obj/usr/src/amd64.amd64/sys
> 
> --
> > > > stage 1: configuring the kernel
> 
> --
> cd
> /usr/src/sys/amd64/conf;  PATH=/usr/obj/usr/src/amd64.amd64/tmp/usr/s
> bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.a
> md64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/
> bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin::/sbin:/bin:/usr/sbin
> :/usr/bin  config  -d /usr/obj/usr/src/amd64.amd64/sys/JERUSALEM  -I
> '/usr/src/sys/amd64/conf' '/usr/src/sys/amd64/conf/JERUSALEM'
> /usr/src/sys/amd64/conf/JERUSALEM: unknown option "AH_SUPPORT_AR5416"
> *** Error code 1
> 
>   I do have:
> 
> options AH_SUPPORT_AR5416  # enable AR5416 tx/rx descriptors
> options AH_AR5416_INTERRUPT_MITIGATION # AR5416 interrupt
> mitigation
> options ATH_ENABLE_11N # Enable 802.11n support for
> AR5416 and later
> 
>   in the config file.  (Full config file is appended.)
>   Googling found nothing useful; didn't find anything in
> src/UPDATING.
>   Is this me, or is the problem elsewhere?
> 
> [...]

It looks like that option is no longer valid, and we neglected to make
an entry in UPDATING (avos@ cc'd), so you can safely remove it from
your config.

   Author: avos
   Date: Fri Jan 25 13:48:40 2019
   New Revision: 343427
   URL: https://svnweb.freebsd.org/changeset/base/343427

Log:
  Garbage collect AH_SUPPORT_AR5416 config option.
  
  It does nothing since r318857.

-- 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: r342378 fails sometimes on boot mounting root (error 2)

[Ian Lepore]

On Fri, 2018-12-28 at 15:54 +0100, Matthias Apitz wrote:
> Hello,
> 
> I've setup a new r342378 (December 23) for amd64 onto an external
> disk
> with this procedure:
> 
> # grep da0 /var/log/messages
> ...
> Dec 28 14:20:01 c720-r314251 kernel: da0 at umass-sim0 bus 0 scbus1
> target 0 lun 0
> Dec 28 14:20:01 c720-r314251 kernel: da0: 
> Fixed Direct Access SPC-4 SCSI device
> Dec 28 14:20:01 c720-r314251 kernel: da0: Serial Number
> 575854314134383033483150
> Dec 28 14:20:01 c720-r314251 kernel: da0: 400.000MB/s transfers
> Dec 28 14:20:01 c720-r314251 kernel: da0: 953837MB (1953458176 512
> byte sectors)
> Dec 28 14:20:01 c720-r314251 kernel: da0: quirks=0x2
> 
> 
> # gpart destroy -F da0
> da0 destroyed
> # gpart create -s gpt da0
> da0 created
> # gpart add -t freebsd-boot -s 512k -a4k -l extboot da0
> da0p1 added
> # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 da0
> partcode written to da0p1
> bootcode written to da0
> # gpart add -t freebsd-ufs -l  extrootfs -b 1m -s 256g da0
> da0p2 added
> # gpart add -t freebsd-swap -l extswap -a 1m -s 2g da0
> da0p3 added
> # gpart add -t freebsd-ufs -l  extbackupfs -a 1m da0
> da0p4 added
> 
> # newfs -U /dev/gpt/extrootfs
> # newfs -U /dev/gpt/extbackupfs
> 
> # gpart set -a active da0
> active set on da0
> # gpart show -l da0
> =>40  1953458096  da0  GPT  (931G)
>   4010241  extboot  (512K)
> 1064 984   - free -  (492K)
> 2048   5368709122  extrootfs  (256G)
>    536872960 41943043  extswap  (2.0G)
>    541067264  14123888644  extbackupfs  (673G)
>   19534561282008   - free -  (1.0M)
> 
> 
> # mount /dev/gpt/extrootfs /mnt
> 
> # cd /usr/src
> # make installworld  DESTDIR=/mnt
> # make installkernel DESTDIR=/mnt
> # make distrib-dirs  DESTDIR=/mnt
> # make distribution  DESTDIR=/mnt
> 
> # cd ~guru/C720
> 
> # cp -p rc.conf /mnt/etc
> # cp -p c720.kbd/mnt/etc
> # cp -p sysctl.conf /mnt/etc
> # cp -p loader.conf /mnt/boot/
> # cp -p device.hints/mnt/boot/
> 
> # cat > /mnt/etc/fstab  < /dev/gpt/extrootfs  / ufs rw,noatime 1 1
> /dev/gpt/extswap none swap sw 0 0
> EOF
> 
> # chroot /mnt passwd root
> Changing local password for root
> New Password:
> 
> # umount /mnt
> 
> The disk now boots sometimes fine, more times it fails with:
> 
> Trying to mount root from ufs:/dev/gpt/extroot [rw, noatime]...
> Mounting from ufs:/dev/gpt/extroot failed with error 2; retrying fpr
> 3 seconds
> Mounting from ufs:/dev/gpt/extroot failed with error 2; retrying fpr
> 2 seconds
> Mounting from ufs:/dev/gpt/extroot failed with error 2; retrying fpr
> 1 seconds
> ...
> 
> I can provide a 'dmesg' output from an successful boot, if this
> helps.
> 
> Any hints? Thanks
> 
>   matthias
> 

Try setting vfs.mountroot.timeout= in loader.conf to a value long
enough to let the usb drive get probed reliably. The default is 3
seconds, maybe a value like 5 or 10 would work better for you.

-- 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: Composite PCI devices in FreeBSD (mfd in Linux)

[Ian Lepore]

On Wed, 2018-12-19 at 14:35 -0500, Anthony Jenkins wrote:
> On 12/19/18 10:41 AM, Anthony Jenkins wrote:
> > 
> > [snip]
> > 
> > I'm not feeling too confident about the condition of the FreeBSD
> > ig4 
> > driver; the PCI attach code was calling pci_alloc_msi() wrong,
> > passing 
> > a pointer to the rid (0) instead of a pointer to a count variable,
> > and 
> > not passing bus_alloc_resource_any() an IRQ rid > 0 if it has an
> > MSI.  
> > I'd be happy(er) if ig4 created a /dev/iic0 node - I figured
> > iicbus(4) 
> > took care of all that...
> > 
> > https://github.com/ScoobiFreeBSD/freebsd-intel-lpss
> > 
> Found it!  I didn't declare ig4_iic to include the ig4_lpss as a 
> sub-device.  Now it at least /looks/ like I'm getting I2C devices
> found 
> on both my DesignWare I2C busses.
> 
> diff --git a/sys/dev/ichiic/ig4_iic.c b/sys/dev/ichiic/ig4_iic.c
> index 6bbe417..34c1adb 100644
> --- a/sys/dev/ichiic/ig4_iic.c
> +++ b/sys/dev/ichiic/ig4_iic.c
> @@ -802,3 +802,4 @@ ig4iic_dump(ig4iic_softc_t *sc)
> 
>   DRIVER_MODULE(iicbus, ig4iic_acpi, iicbus_driver, iicbus_devclass, 
> NULL, NULL);
>   DRIVER_MODULE(iicbus, ig4iic_pci, iicbus_driver, iicbus_devclass, 
> NULL, NULL);
> +DRIVER_MODULE(iicbus, ig4iic_lpss, iicbus_driver, iicbus_devclass, 
> NULL, NULL);

That new DRIVER_MODULE() statement should be in your new driver, not in
ig4_iic.c. Those other two statements should also be moved into their
corresponding source code files.

At least, that's the precedent followed by all the i2c controller
drivers except ig4_iic: the DRIVER_MODULE() statement that establishes
the connection between iicbus and the controller lives right alongside
the DRIVER_MODULE() statement that establishes the connection between
the controller and the bus it sits on. See, for example:

 sys/dev/glxiic/glxiic.c
 sys/dev/iicbus/iicoc.c

-- 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: cannot build i386 12.0-RELEASE kernel on -current

[Ian Lepore]

On Wed, 2018-12-12 at 19:33 +0300, Yuri Pankov wrote:
> Henry Vogt wrote:
> > 
> > Hi,
> > 
> > my build machine (FreeBSD:13:amd64 r341429) builds world/kernel ok
> > for amd64, world for i386 ok, but fails 'make buildkernel' for
> > i386:
> > 
> > -- snip
> > 
> > ...
> > 
> > --- if_vte.o ---
> > /usr/src/12/sys/dev/vte/if_vte.c:76:10: fatal error: 'miibus_if.h'
> > file not found
> > #include "miibus_if.h"
> >  ^
> > Building /usr/obj/usr/src/12/i386.i386/sys/MODULAR/msdosfs_denode.o
> > --- modules-all ---
> > --- all_subdir_accf_dns ---
> > ===> accf_dns (all)
> > Building /usr/obj/usr/src/12/i386.i386/sys/MODULAR/msdosfs_fat.o
> > --- if_vte.o ---
> > 1 error generated.
> > *** [if_vte.o] Error code 1
> > 
> > ...
> > 
> > -- snip
> > 
> > Is this known - did i miss something ?
> > Howto fix ?
> Does your "MODULAR" config file include "device miibus"?
> 

It is possible to build miibus as a module, or not use it at all (and
use just the specific phy driver(s) you need), but in that case you
need 'device mii' in the kernel to get the minimal infrastructure
needed to support the modules (which includes generating miibus_if.h).

-- 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: pkg-base noise

[Ian Lepore]

On Tue, 2018-12-11 at 11:40 -0700, Sean Bruno wrote:
> make[8]: "/home/sbruno/bsd/fbsd_head/share/mk/bsd.files.mk" line 92:
> warning: duplicate script for target "_testsFILESINS_cleanup.ksh"
> ignored
> make[8]: "/home/sbruno/bsd/fbsd_head/share/mk/bsd.files.mk" line 92:
> warning: using previous script for "_testsFILESINS_cleanup.ksh"
> defined here
> 
> 
> Is this something easily fixable?  I'm unclear what is throwing a
> warning here?
> 
> sean
> 

Looks like some makefile has cleanup.ksh listed twice in a FILES= list.

-- 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: Composite PCI devices in FreeBSD (mfd in Linux)

[Ian Lepore]

On Mon, 2018-12-10 at 14:42 -0500, Anthony Jenkins wrote:
> On 12/10/18 1:26 PM, John Baldwin wrote:
> > 
> > On 12/10/18 9:00 AM, Anthony Jenkins wrote:
> > > 
> > > Hi all,
> > > 
> > > I'm trying to port an Intel PCI I2C controller from Linux to
> > > FreeBSD.
> > > Linux represents this device as an MFD (multi-function device),
> > > meaning
> > > it has these "sub-devices" that can be handed off to other
> > > drivers to
> > > actually attach devices to the system.  The Linux "super" PCI
> > > device is
> > > the intel-lpss-pci.c, and the "sub" device is i2c-designware-
> > > platdrv.c,
> > > which represents the DesignWare driver's "platform" attachment to
> > > the
> > > Linux system.  FreeBSD also has a DesignWare I2C controller
> > > driver,
> > > ig4(4), but it only has PCI and ACPI bus attachment
> > > implementations.
> > > 
> > > I have a port of the Linux intel-lpss driver to FreeBSD, but now
> > > I'm
> > > trying to figure out the best way to give FreeBSD's ig4(4) driver
> > > access
> > > to my lpss(4) device.  I'm thinking I could add an ig4_lpss.c
> > > describing
> > > the "attachment" of an ig4(4) to an lpss(4).  Its probe() method
> > > would
> > > scan the "lpss" devclass for devices, and its attach() method
> > > would
> > > attach itself as a child to the lpss device and "grab" the
> > > portion of
> > > PCI memory and the IRQ that the lpss PCI device got.
> > > 
> > > Is this the "FreeBSD Way (TM)" of handling this type of device? 
> > > If not,
> > > can you recommend an existing FreeBSD driver I can model my code
> > > after?
> > > If my approach is acceptable, how do I fully describe the ig4(4)
> > > device's attachment to the system?  Is simply making it a child
> > > of
> > > lpss(4) sufficient?  It's "kind of" a PCI device (it is
> > > controlled via
> > > access to a PCI memory region and an IRQ), but it's a sub-device
> > > of an
> > > actual PCI device (lpss(4)) attached to PCI.
> > > How would my ig4_lpss attachment get information from the lpss(4)
> > > driver
> > > about what it probed?
> > There are some existing PCI drivers that act as "virtual" busses
> > that attach
> > child devices.  For example, vga_pci.c can have drm, agp, and
> > acpi_video
> > child devices.  There are also some SMBus drivers that are also
> > PCI-ISA
> > bridges and thus create separate child devices.
> Yeah I was hoping to avoid using video PCI devices as a model, as 
> complex as they've gotten recently.  I'll check out its bus glue
> logic.
> 
> > 
> > For a virtual bus like this, you need to figure out how your child
> > devices
> > will be enumerated.  A simple way is to let child devices use an
> > identify
> > routine that looks at each parent device and decides if a child
> > device
> > for that driver makes sense.  It can then add a child device in the
> > identify routine.
> Really an lpss parent PCI parent device can only have the following:
> 
>   * one of {I2C, UART, SPI} controller
>   * optionally an IDMA64 controller
> 
> so I was thinking a child ig4(4) device would attach to lpss iff
> 
>   * the lpss device detected an I2C controller
>   * no other ig4 device is already attached
> 
> I haven't fiddled with identify() yet, will look at that tonight.
> 

If this is just another "bus" an ig4 instance can attach to, I'd think
the recipe would be to add another DRIVER_MODULE() to ig4_iic.c naming
ig4_lpss as the parent. Then add a new ig4_lpss.c modeled after the
existing pci and acpi attachment code, its DRIVER_MODULE() would name
lpss as parent, and its probe routine would return BUS_PROBE_NOWILDCARD
(attach only if specifically added by the parent).

Then there would be a new lpss driver that does the resource managment
stuff mentioned above, and if it detects configuration for I2C it would
do a device_add_child(lpssdev, "ig4_lpss", -1) followed by
bus_generic_attach(). There'd be no need for identify() in the child in
that case, I think.

But take jhb's word over mine on any of this stuff, he's been around
since the days when these mechanisms were all invented, whereas I tend
to cut and paste that bus and driver attachment stuff in semi-ignorance 
when I'm working on drivers.

-- Ian



> > To handle things like resources, you want to have
> > bus_*_resource methods that let your child device use the normal
> > bus_*
> > functions to allocate resources.  At the simplest end you don't
> > need to
> > permit any sharing of BARs among multiple children so you can just
> > proxy
> > the requests in the "real" PCI driver.  (vga_pci.c does this)  If
> > you need
> > the BARs to be shared you have a couple of options such as just
> > using a
> > refcount on the BAR resource but letting multiple devices allocate
> > the same
> > BAR.  If you want to enforce exclusivity (once a device allocates
> > part of
> > a BAR then other children shouldn't be permitted to do so), then
> > you will
> > need a more complicated solution.
> Another homework assignment for me - bus_*_resource 

Re: Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2

[Ian Lepore]

On Tue, 2018-12-04 at 21:51 +0200, Toomas Soome via freebsd-stable
wrote:
> 
> > 
> > On 4 Dec 2018, at 19:59, Mark Martinec  > i> wrote:
> > 
> > > 
> > > > 
> > > > 2018-11-29 18:43, Toomas Soome wrote:
> > > > > 
> > > > > I just did push biosdisk updates to stable/12, I wonder if
> > > > > you could
> > > > > test those bits…
> > Myself wrote:
> > > 
> > > > 
> > > > Thank you!  I haven't tried it yet, but I wonder whether this
> > > > fix was
> > > > already incorporated into 12.0-RC3, which would make my rescue
> > > > easier.
> > > > Otherwise I can build a stable/12 on another host and
> > > > transplant
> > > > the problematic file(s) to the affected host - if I knew which
> > > > files
> > > > to copy.
> > 2018-12-02 18:59, Toomas wrote:
> > > 
> > > The files are /boot/loader* binaries - to be exact, check which
> > > one is
> > > linked to /boot/loader. I can provide binaries if needed.
> > > [...]
> > > rgds,
> > > toomas
> > I got a maintenance window today so I tried with the new loader,
> > and it did not help.
> > 
> > More specifically:
> > 
> > As it comes with 12-RC2, the /boot/loader was hard linked with
> > loader_lua.
> > Its size is 421888 bytes. So I concentrated on this loader.
> > 
> > I build a fresh stable/12 on another host, and copied the newly
> > built loader_lua (425984 bytes) to the /boot directory of the
> > affected
> > host, deleted the file 'loader', and hard-linked loader_lua to
> > loader.
> > 
> > The situation has not changed: the BTX loader lists all BIOS drives
> > C..J (disk0..disk7), then a spinner starts and gets stuck forever.
> > It never reaches the 'BIOS 635kB/3537856kB available memory' line.
> > 
> > While trying to restore the old /boot from 11.2, I tried booting
> > a live image from a 12.0-RC3 memory stick - and the loader got
> > stuck again, same as when booting from a disk.
> > 
> > So I had to boot from an 11.2 memstick to be able to regain
> > control.
> > 
> >  Mark
> > 
> > 
> ok, if you could perform 2 tests:
> 
> 1. from loader prompt enter 0x413 0xa000 - @w . cr
> 
> 2. on first spinner, press space and type on boot: prompt:
> /boot/loader_4th and see if that will do better
> thanks,
> toomas
> 

I don't think that will be an option.  If it hasn't gotten to the point
of saying how much BIOS available memory there is, it's only halfway
through loader main() and has hung before getting to interact().

In fact, if that line hasn't printed, but some disk drives have been
listed, it pretty much has to be hung in the "March through the device
switch probing for things" loop. If all the disks are listed, then it
got through that entry in the devsw, and is likely hanging in the
dv_init calls for either the pxedisk or zfsdev devices.

-- Ian

> 
> > 
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > On 29 Nov 2018, at 17:01, Mark Martinec  > > > > > b...@ijs.si> wrote:
> > > > > > After successfully upgraded three hosts from 11.2-p4 to
> > > > > > 12.0-RC2 (amd64,
> > > > > > zfs, bios), I tried my luck with one of our production
> > > > > > hosts, and ended up
> > > > > > with a stuck loader after rebooting with a new kernel
> > > > > > (after the first
> > > > > > stage of upgrade).
> > > > > > These were the steps, and all went smoothly and normally
> > > > > > until a reboot:
> > > > > > freebsd-update upgrade -r 12.0-RC2
> > > > > > freebsd-update install
> > > > > > shutdown -r now
> > > > > > While booting, the 'BTX loader' comes up, lists the BIOS
> > > > > > drives,
> > > > > > then the spinner below the list comes up and begins
> > > > > > turning,
> > > > > > stuttering, and after a couple of seconds it grinds to a
> > > > > > standstill
> > > > > > and nothing happens afterwards.
> > > > > > At this point the ZFS and the bootstrap loader is supposed
> > > > > > to
> > > > > > come up, but it doesn't.
> > > > > > This host has too zfs pools, the system pool consists of
> > > > > > two SSDs
> > > > > > in a zfs mirror (also holding a freebsd-boot partition
> > > > > > each), the
> > > > > > other pool is a raidz2 with six JBOD disks on an LSI
> > > > > > controller.
> > > > > > The gptzfsboot in both freebsd-boot partitions is fresh
> > > > > > from 11.2,
> > > > > > both zpool versions are up-to-date with 11.2. The 'zpool
> > > > > > status -v'
> > > > > > is happy with both pools.
> > > > > > After rebooting from an USB drive and reverting the /boot
> > > > > > directory
> > > > > > to a previous version, the machine comes up normally again
> > > > > > with the 11.2-RELEASE-p4.
> > > > > > I found a file init.core in the / directory, slightly
> > > > > > predating the
> > > > > > last reboot with a salvaged system - although it was
> > > > > > probably not
> > > > > > a cause of the problem, but a consequence of the rescue
> > > > > > operation.
> > > > > > It is unfortunate that this is a production host, so I
> > > > > > can't play
> > > > > > much with it. One or two more quick experiments I can
> > > > > > probably
> > > > > 

Re: toolchain(s) for universe kernels

[Ian Lepore]

On Mon, 2018-11-19 at 11:55 -0600, Eric van Gyzen wrote:
> I want to
> 
>   make MAKE_JUST_KERNELS=1 universe
> 
> but it seems that I need a toolchain first.  There are multiple
> toolchain-ish make targets.  If I start with an empty obj, which
> toolchain target(s) should I build?
> 
> Eric

Do "make kernel-toolchains" to build all the tools needed to build all
universe kernels.

You can also add "MAKE_LINT_KERNELS=1" to build just the lint kernels
for all arches, but be aware that mips has no lint kernels.

-- 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: sh(1) and more(1) hangs on serial terminal at [ttydcd] state.

[Ian Lepore]

On Wed, 2018-09-05 at 00:07 +0300, Lev Serebryakov wrote:
> Hello FreeBSD,
> 
>  When I use serial console (configured as console + "getty std.115200
> xterm"), csh works perfectly Ok, but "sh" and "more" lockss forever.
> If I hit
> ^T system shows that locked process is in "[ttydcd]" state. ^C kills
> locked
> process.
> 
>  What do I have misconfigured?
> 

Change the std.115200 to 3wire.115200 so that it ignores modem-control
signals.

-- 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: priority of paths to kernel modules?

[Ian Lepore]

On Fri, 2018-08-24 at 08:35 -0700, Cy Schubert wrote:
> My idea, which I implemented locally and should probably create a
> phab review, was to ifdef DRM in modules/Makefile. We could do this
> too. Default not to build/install.
> 

This seems like the obvious fix. I thought the whole point of all this
is that we support drm2 on some platforms, but not x86 anymore. So to
me that implies not building the modules by default on x86.

-- Ian

> ---
> Sent using a tiny phone keyboard.
> Apologies for any typos and autocorrect.
> Also, this old phone only supports top post. Apologies.
> 
> Cy Schubert
>  or 
> The need of the many outweighs the greed of the few.
> ---
> 
> -Original Message-
> From: Johannes Lundberg
> Sent: 24/08/2018 01:08
> To: freebsd-current
> Subject: priority of paths to kernel modules?
> 
> Hi
> 
> Since we now stuck with drm2 in base for a few more years I have an
> idea
> would make things much smoother for many of us, hugely reduce the
> amount of
> bug reports we get and I think would be beneficial in other ways too.
> 
> Current I run with something like this in /boot/loader.conf
> 
> module_path="/boot/modules.drm-
> v4.16;/boot/modules;/boot/dtb;/boot/overlays"
> 
> So I expect modules to be loaded in that order, with /boot/
> LAST.
> 
> However, if you look at this
> sysctl kern.module_path
> kern.module_path:
> /boot/kernel;/boot/modules.drm-
> v4.16;/boot/modules;/boot/dtb;/boot/overlays
> 
> /boot/kernel is inserted first and probably modules in /boot/kernel
> have
> the highest priority. This is also proven by everyone wanting to use
> drm*kmods that get drm.ko from base loaded instead of the installed
> in
> /boot/modules.
> 
> Please correct me if I'm wrong but if my understanding is correct
> this is a
> flaw and /boot/ should be inserted last so that any
> overlays or
> custom modules have higher priority than the default ones.
> 
> I can imagine this is also useful when building custom modules and
> you
> don't want to overwrite or delete the default one in /boot/kernel...
> 
> Cheers
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd
> .org"
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd
> .org"
___
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: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

[Ian Lepore]

On Thu, 2018-08-16 at 11:25 -0700, Xin LI wrote:
> On Thu, Aug 16, 2018 at 9:26 AM Brad Davis  wrote:
> > 
> > 
> > On Thu, Aug 16, 2018, at 10:13 AM, Xin LI wrote:
> > > 
> > > This was caused by r337852, but I didn't investigated further.
> > > 
> > > The problem is that we have a source file called 'moduli.c' in
> > > crypto/openssh/ while the build target was moduli, and bmake seen
> > > 'moduli' in source tree as older than moduli.c, and decided to
> > > rebuild
> > > it from source, while the two files are unrelated.
> > Hi Xin,
> > 
> > I don't see how that could be the case as I didn't move the file
> > around, I just moved how it gets installed.
> > 
> > I have done many many builds with this change in and haven't seen
> > this problem..
> Yeah, let me rephrase: this might have been exposed by r337852; I
> don't think your change itself really caused or should have caused
> problem, but my theory based on what we have observed was that it
> might have exposed a bug where either bmake itself, or some .mk files
> might have generated e.g. automatic rule for ${foo}: ${foo}.c rules
> (haven't traced that part down yet).
> 

There is an implicit rule to build file from file.c, it's why you can
type "make foo" in a dir that contains a foo.c and no Makefile.

The CONFS=moduli makes moduli into a target.  The implicit rules search
finds the rule to make moduli from moduli.c and because of the .PATH
it's able to find a moduli.c.

It might be fixable by simply adding a target with a do-nothing script
for building moduli in usr.sbin/sshd/Makefile.  Something like

moduli:
    @ : # Do nothing.

But that's just a wild guess on my part, not sure that'll work. Hmm, in
fact, it'll probably cause a make warning about duplicate targets with
scripts.

--Ian

> The most scaring part is that the build system seems to trying
> building crypto/openssh/moduli because moduli.c was newer, and the
> file was deleted as part of the rebuild; should moduli.c compile by
> its own, we would end up with a binary moduli file.
> 
> I'll take another look tonight if I had some time.
> 
> > 
> > 
> > 
> > Regards,
> > Brad Davis
> > 
> > > 
> > > On Thu, Aug 16, 2018 at 4:19 AM David Wolfskill  > > .org> wrote:
> > > > 
> > > > 
> > > > Running:
> > > > 
> > > > FreeBSD g1-215.catwhisker.org 12.0-ALPHA1 FreeBSD 12.0-ALPHA1
> > > > #80  r337834M/337834:1200077: Wed Aug 15 04:34:45 PDT 2018 
> > > > r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/s
> > > > ys/CANARY  amd64
> > > > 
> > > > after updating working copy to r337903, I'm seeing:
> > > > 
> > > > ...
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > stage 4.3: building everything
> > > > ...
> > > > --- ifconfig_make ---
> > > > Building
> > > > /common/S4/obj/usr/src/amd64.amd64/rescue/rescue/usr/src/sbin/i
> > > > fconfig/af_inet6.o
> > > > --- all_subdir_secure ---
> > > > --- moduli ---
> > > > /usr/bin/ld: error: undefined symbol: main
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > referenced by crt1.c
> > > > > > >   /common/S4/obj/usr/src/amd64.amd64/tmp/usr/
> > > > > > > lib/crt1.o:(_start)
> > > > /usr/bin/ld: error: undefined symbol: Fssh_error
> > > > 
> > > > make[5]: stopped in /usr/src/secure/usr.sbin/sshd
> > > > .ERROR_TARGET='moduli'
> > > > .ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/secure/usr
> > > > .sbin/sshd/moduli.meta'
> > > > .MAKE.LEVEL='5'
> > > > MAKEFILE=''
> > > > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes
> > > > silent=yes verbose'
> > > > _ERROR_CMD='cc -target x86_64-unknown-freebsd12.0 --
> > > > sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp
> > > > -B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe   -
> > > > I/usr/src/crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1
> > > > -DUSE_BSM_AUDIT=1 -DHAVE_GETAUDIT_ADDR=1 -DUSE_BLACKLIST=1
> > > > -I/usr/src/contrib/blacklist/include -include krb5_config.h
> > > > -DLIBWRAP=1 -std=gnu99 -fstack-protector-strong -Wno-pointer-
> > > > sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-
> > > > variable -Wno-tautological-compare -Wno-unused-value -Wno-
> > > > parentheses-equality -Wno-unused-function -Wno-enum-conversion
> > > > -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-
> > > > switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-
> > > > parentheses  -Qunused-arguments   -
> > > > L/common/S4/obj/usr/src/amd64.amd64/lib/libblacklist  /usr/src/
> > > > crypto/openssh/moduli.c  -o moduli; ;'
> > > > .CURDIR='/usr/src/secure/usr.sbin/sshd'
> > > > .MAKE='make'
> > > > .OBJDIR='/common/S4/obj/usr/src/amd64.amd64/secure/usr.sbin/ssh
> > > > d'
> > > > .TARGETS='all'
> > > > DESTDIR='/common/S4/obj/usr/src/amd64.amd64/tmp'
> > > > 
> > > > 
> > > > (on both the laptop and the build machine).
> > > > 
> > > > I have copied the .ERROR_META_FILE to
> > > >  > > > eta and
> > > > a typescript of the attempted build to
> > > > 

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

[Ian Lepore]

On Sat, 2018-08-04 at 18:43 +0300, Konstantin Belousov wrote:
> On Sat, Aug 04, 2018 at 09:25:47AM -0600, Ian Lepore wrote:
> > 
> > On Sat, 2018-08-04 at 18:22 +0300, Konstantin Belousov wrote:
> > > 
> > > On Sat, Aug 04, 2018 at 09:58:43AM -0500, Kyle Evans wrote:
> > > > 
> > > > 
> > > > On Sat, Aug 4, 2018 at 9:51 AM, Ian Lepore  wrote:
> > > > > 
> > > > > 
> > > > > 
[...]
> > > > > What do we do on 32-bit arm that has no dmap but may have efi
> > > > > runtime
> > > > > support?
> > > > > 
> > > > This should probably just be compiled out for !arm64 && !x86 - its
> > > > sole purpose was to compensate for outdated loader.efi that hasn't
> > > > done the SetVirtualAddressMap. EFI on 32-bit ARM is "new" enough
> > > > that
> > > > it shouldn't have this problem.
> > > Does EFI on 32bit arm have RT support ?
> > I suspect the uboot implementation doesn't, but I can't think of any
> > reason why other implementations are not possible/available. In
> > particular, even 32bit arm supports virtualization and such an
> > environment could provide rt support.
> No, I mean, does our kernel has RT support on armv7 ?  I only implemented
> necessary VM tricks for amd64, then it was ported to arm64, and in both
> cases it relies on 64bit address space and specific location of the KVA.

I didn't realize the kernel implementation was arch-specific. So I
guess this comes under the category of "we'll solve that problem when
something comes along that provides efi rt for arm32."

-- 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: panic: mutex pmap not owned at ... efirt_machdep.c:255

[Ian Lepore]

On Sat, 2018-08-04 at 18:22 +0300, Konstantin Belousov wrote:
> On Sat, Aug 04, 2018 at 09:58:43AM -0500, Kyle Evans wrote:
> > 
> > On Sat, Aug 4, 2018 at 9:51 AM, Ian Lepore  wrote:
> > > 
> > > On Sat, 2018-08-04 at 08:56 -0500, Kyle Evans wrote:
> > > > 
> > > > On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov  > > > gmail.
> > > > com> wrote:
> > > > > 
> > > > > 
> > > > > On Sat, Aug 04, 2018 at 08:05:24AM -0500, Kyle Evans wrote:
> > > > > > 
> > > > > > 
> > > > > > On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov  > > > > > bel@gm
> > > > > > ail.com> wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > This seems odd- pmap lock is acquired at [1], then
> > > > > > > > asserted
> > > > > > > > shortly
> > > > > > > > later at [2]... I avoid some of this stuff as well as I
> > > > > > > > can,
> > > > > > > > but is it
> > > > > > > > actually possible for PCPU_GET(...) acquired curpmap to
> > > > > > > > not
> > > > > > > > match
> > > > > > > > curthread->td_proc->p_vmspace->vm_pmap in this context?
> > > > > > > > 
> > > > > > > > [1] https://svnweb.freebsd.org/base/head/sys/dev/efidev
> > > > > > > > /efirt
> > > > > > > > .c?view=markup#l260
> > > > > > > > [2] https://svnweb.freebsd.org/base/head/sys/amd64/amd6
> > > > > > > > 4/efir
> > > > > > > > t_machdep.c?view=markup#l254
> > > > > > > There could be that curpcpu not yet synced with proc0
> > > > > > > pmap.  It
> > > > > > > could be
> > > > > > > fixed.
> > > > > > > 
> > > > > > > But it is not clear to me why efi_arch_enter() is called
> > > > > > > there.  I see
> > > > > > > the check for GetTime belonging to the range described by
> > > > > > > a map
> > > > > > > descriptor.
> > > > > > > I do not see why do you need an enter into the EFI
> > > > > > > context for
> > > > > > > comparing
> > > > > > > integers.
> > > > > > This probably could have been documented better, but
> > > > > > efi_runtime
> > > > > > pointer may (always?) point into runtime service memory
> > > > > > that
> > > > > > isn't
> > > > > > valid/available at that point, so we get a fault and panic
> > > > > > when
> > > > > > dereferencing it to grab rt_gettime address. We ran into
> > > > > > this
> > > > > > wall
> > > > > > when adding the check originally.
> > > > > Wouldn't it be enough to access it by translating physical
> > > > > address
> > > > > into
> > > > > DMAP ?
> > > > Ah, sure, sure. [1] is proper form, yeah?
> > > > 
> > > > [1] https://people.freebsd.org/~kevans/efi-dmap.diff
> > > What do we do on 32-bit arm that has no dmap but may have efi
> > > runtime
> > > support?
> > > 
> > This should probably just be compiled out for !arm64 && !x86 - its
> > sole purpose was to compensate for outdated loader.efi that hasn't
> > done the SetVirtualAddressMap. EFI on 32-bit ARM is "new" enough
> > that
> > it shouldn't have this problem.
> Does EFI on 32bit arm have RT support ?

I suspect the uboot implementation doesn't, but I can't think of any
reason why other implementations are not possible/available. In
particular, even 32bit arm supports virtualization and such an
environment could provide rt support.

-- 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: panic: mutex pmap not owned at ... efirt_machdep.c:255

[Ian Lepore]

On Sat, 2018-08-04 at 08:56 -0500, Kyle Evans wrote:
> On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov  com> wrote:
> > 
> > On Sat, Aug 04, 2018 at 08:05:24AM -0500, Kyle Evans wrote:
> > > 
> > > On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov  > > ail.com> wrote:
> > > > 
> > > > On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans wrote:
> > > > > 
> > > > > 
> > > > > This seems odd- pmap lock is acquired at [1], then asserted
> > > > > shortly
> > > > > later at [2]... I avoid some of this stuff as well as I can,
> > > > > but is it
> > > > > actually possible for PCPU_GET(...) acquired curpmap to not
> > > > > match
> > > > > curthread->td_proc->p_vmspace->vm_pmap in this context?
> > > > > 
> > > > > [1] https://svnweb.freebsd.org/base/head/sys/dev/efidev/efirt
> > > > > .c?view=markup#l260
> > > > > [2] https://svnweb.freebsd.org/base/head/sys/amd64/amd64/efir
> > > > > t_machdep.c?view=markup#l254
> > > > There could be that curpcpu not yet synced with proc0 pmap.  It
> > > > could be
> > > > fixed.
> > > > 
> > > > But it is not clear to me why efi_arch_enter() is called
> > > > there.  I see
> > > > the check for GetTime belonging to the range described by a map
> > > > descriptor.
> > > > I do not see why do you need an enter into the EFI context for
> > > > comparing
> > > > integers.
> > > This probably could have been documented better, but efi_runtime
> > > pointer may (always?) point into runtime service memory that
> > > isn't
> > > valid/available at that point, so we get a fault and panic when
> > > dereferencing it to grab rt_gettime address. We ran into this
> > > wall
> > > when adding the check originally.
> > Wouldn't it be enough to access it by translating physical address
> > into
> > DMAP ?
> Ah, sure, sure. [1] is proper form, yeah?
> 
> [1] https://people.freebsd.org/~kevans/efi-dmap.diff

What do we do on 32-bit arm that has no dmap but may have efi runtime
support?

-- 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: GELI with UEFI supporting Boot Environments goes to HEAD when?

[Ian Lepore]

On Fri, 2018-08-03 at 22:20 +0100, Warner Losh wrote:
> On Fri, Aug 3, 2018, 10:17 PM Tommi Pernila 
> wrote:
> 
> > 
> > 
> > 
> > On Fri, 3 Aug 2018 at 20.17, Warner Losh  wrote:
> > 
> > > 
[...]
> > Thank you all for your work on this!
> > 
> > *starts updating CURRENT install*
> > 
> Let us know of there is a problem...

And don't forget to do the often-skipped "mergemaster -p" step of the
updating before doing the installworld, to add the new ntpd user. :)

-- 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: GELI with UEFI supporting Boot Environments goes to HEAD when?

[Ian Lepore]

On Fri, 2018-08-03 at 19:54 +0300, Tommi Pernila wrote:
> On Tue, 10 Jul 2018 at 1.05, Warner Losh  wrote:
> 
> > 
> > I have this in my tree already...
> > 
> > Warner
> > 
> > On Mon, Jul 9, 2018, 10:28 AM Allan Jude 
> > wrote:
> > 
> > > 
> > > I will look at updating the rootgen.sh script this evening, to
> > > support
> > > creating more flexible ESP partitions, so we can drop the
> > > loader.efi
> > > into an msdosfs directly.
> > > 
> > > On 07/08/2018 15:31, Ian Lepore wrote:
> > > > 
> > > > On Sun, 2018-07-08 at 21:08 +0200, Oliver Pinter wrote:
> > > > > 
> > > > > Hi!
> > > > > 
> > > > > Have you or Warner any update on this code?
> > > > > 
> > > > > On Thursday, April 12, 2018, Eric McCorkle  > > > > net>
> > > > > wrote:
> > > > > 
> > > > Are you aware of https://reviews.freebsd.org/D15743 ?
> > > > 
> > > > That's my changes to add geli support to loader(8) in an
> > > > architecture-
> > > > agnostic way, so that "it just works" for all platforms and
> > > > flavors of
> > > > loader. It has been succesfully tested on armv6/7 (ubldr) and
> > > > on x86
> > > > using qemu.  The x86 tests cover ufs and zfs, legacy bios and
> > > > uefi. The
> > > > only variations that aren't tested yet are the uefi flavors,
> > > > because
> > > > the current rootgen.sh script for assembling test images is
> > > > still using
> > > > boot1.efi and I don't know enough about efi myself to update
> > > > the script
> > > > to make it assemble images the new way Warner envisions.
> > > > 
> > > > -- Ian
> > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > I'm in the middle of moving to a new apartment right
> > > > > > now.  It's
> > > > > > going to
> > > > > > be a bit before I can get to this.
> > > > > > 
> > > > > > On 04/11/2018 20:31, Warner Losh wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > OK. I've pushed in the main part of it. The additional
> > > > > > > work I
> > > > > > > have
> > > > > > > shouldn't affect any of this stuff.  I was going to look
> > > > > > > at what
> > > > > > > part(s)
> > > > > > > of your open reviewed needed to be redone tomorrow and
> > > > > > > send you
> > > > > > > feedback, but if you wanted to get a start before then,
> > > > > > > I'm happy
> > > > > > > to
> > > > > > > answer questions. All the rest of my work is going to be
> > > > > > > selecting the
> > > > > > > root partition when we're told to us a specific
> > > > > > > partition, so
> > > > > > > will be
> > > > > > > very constrained.
> > > > > > > 
> > > > > > > Warner
> > > > > > > 
> > > > > > > On Wed, Apr 11, 2018 at 6:02 PM, Eric McCorkle  > > > > > > icspace.
> > > > > > > net
> > > > > > > <mailto:e...@metricspace.net>> wrote:
> > > > > > > 
> > > > > > >  I think the thing to do at this point is to wait for
> > > > > > > the
> > > > > > > current
> > > > > > work on
> > > > > > > 
> > > > > > > 
> > > > > > >  loader.efi to land, then adapt my patches to apply
> > > > > > > against
> > > > > > > that work.
> > > > > > > 
> > > > > > >  On 04/11/2018 15:06, Warner Losh wrote:
> > > > > > >  > Still reviewing the code. I'm worried it's too
> > > > > > > i386
> > > > > > > specific and it
> > > > > > >  > conflicts with some work I'm doing. I'll have a
> > > > > > > list of
> > > > > > > actionable
> > > > > > >  > critiques this

Re: ntpd user/group issue

[Ian Lepore]

On Fri, 2018-08-03 at 10:31 +0300, Daniel Braniss wrote:
> Hi,
> I am cross compiling, which means i’m using for example an 11.1 to
> compile current, for
> another host - an image which is different from the one i'm using to
> compile.
> 
> make install checks for ntpd in /etc, instead, should it look
> elsewhere? DESTDIR perhaps?
> 
> cheers,
>   danny
> 

Add -DDB_FROM_SRC to the make command when you're installing, to work
around this. Fixing the build system to automatically do so isn't as
easy as you might think, but I've been working on it in slow motion.

-- 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: acpiconf -s 3 does not call acpi sleep event handlers

[Ian Lepore]

On Thu, 2018-08-02 at 08:20 +0300, Andriy Gapon wrote:
> On 02/08/2018 01:17, Conrad Meyer wrote:
> > 
> > I don't understand the concern.  There is only one listener to the
> > event and it just invokes ReqSleepState, which is responsible for
> > performing all suspend behavior.  The behavior is identical between
> > lid close and acpiconf.
> Unless someone is adding a new listener for that event.
> 

Or if there is some listener in some proprietary or local module that's
not part of base freebsd. The ability to support modules that didn't
exist at the time the event was added is exactly the main benefit of a
loose-runtime-binding scheme such as event notifications.

-- 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: can't make installworld

[Ian Lepore]

On Wed, 2018-08-01 at 14:41 +, Glen Barber wrote:
> On Wed, Aug 01, 2018 at 10:29:18AM -0400, AN wrote:
> > 
> > FreeBSD BSD12 12.0-CURRENT FreeBSD 12.0-CURRENT #16 r335386: Tue
> > Jun
> > 19 19:57:51 EDT 2018
> > root@BSD12:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL  amd64
> > 
> > # cat /etc/master.passwd | grep ntp
> > ntpd:*:123:123::0:0:NTP Daemon:/var/db/ntp:/usr/sbin/nologin
> > 
> > 
> > # cat /etc/group | grep ntp
> > ntpd:*:123:
> > 
> This is a particularly annoying problem since 20180719.
> 

It's not a problem at all, we are just in one of the rare times when
you actually have to follow the recommended update procedure exactly,
without shortcuts. In particular, you cannot skip the pre-world
"mergemaster -p" step as described in the handbook or at the bottom of
UPDATING.

-- Ian

> > 
> > 
> > # svnlite info
> > Path: .
> > Working Copy Root Path: /usr/src
> > URL: svn://svn.freebsd.org/base/head
> > Relative URL: ^/head
> > Repository Root: svn://svn.freebsd.org/base
> > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> > Revision: 337003
> > Node Kind: directory
> > Schedule: normal
> > Last Changed Author: manu
> > Last Changed Rev: 337000
> > Last Changed Date: 2018-07-31 15:14:52 -0400 (Tue, 31 Jul 2018)
> > 
> > 
> > For several days I have been trying to update the world without
> > success.  In single user mode, trying to make installworld I get
> > the
> > following:
> > 
> > > 
> > > > 
> > > > > 
> > > > > Installworld check
> > ...
> > Required tool true not found in path.
> > 
> > 
> > Any idea how to fix this?
> What does your $PATH contain?
> 
> Glen
> 
___
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"