Re: Deprecating ftpd in the FreeBSD base system?

2020-09-17 Thread 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?

2020-09-17 Thread 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)

2020-09-02 Thread 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)

2020-09-02 Thread 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

2020-06-29 Thread 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

2020-06-21 Thread 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

2020-06-21 Thread 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

2020-05-26 Thread 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

2020-05-03 Thread 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)

2020-03-29 Thread 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?

2020-03-13 Thread 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?

2020-03-13 Thread 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

2020-02-18 Thread 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?

2020-02-04 Thread 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?

2020-02-02 Thread 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

2020-01-28 Thread 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

2019-12-29 Thread 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?

2019-11-29 Thread 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.

2019-11-20 Thread 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?

2019-10-24 Thread 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

2019-10-24 Thread 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

2019-10-24 Thread 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

2019-10-04 Thread 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

2019-09-24 Thread 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

2019-09-14 Thread 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?

2019-09-10 Thread 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?

2019-09-10 Thread 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

2019-09-09 Thread 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

2019-09-09 Thread 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

2019-09-09 Thread 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

2019-09-09 Thread 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()

2019-09-04 Thread 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

2019-08-28 Thread 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

2019-08-14 Thread 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

2019-08-14 Thread 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

2019-08-14 Thread 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

2019-08-14 Thread 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

2019-08-13 Thread 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?

2019-08-11 Thread 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?

2019-08-11 Thread 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

2019-08-01 Thread 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

2019-07-25 Thread 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

2019-07-21 Thread 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?

2019-07-09 Thread 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

2019-07-06 Thread 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

2019-07-01 Thread 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

2019-07-01 Thread 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

2019-06-19 Thread 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

2019-06-18 Thread 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

2019-06-18 Thread 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

2019-06-18 Thread 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

2019-06-17 Thread 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

2019-05-23 Thread 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

2019-05-20 Thread 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

2019-05-15 Thread 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

2019-05-15 Thread 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

2019-05-12 Thread 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.

2019-05-08 Thread 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)

2019-04-30 Thread 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'

2019-04-29 Thread 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'

2019-04-29 Thread 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'

2019-04-28 Thread 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

2019-03-25 Thread 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

2019-02-28 Thread 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?

2019-02-18 Thread 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?

2019-02-17 Thread 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

2019-02-15 Thread 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

2019-02-15 Thread 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"

2019-02-13 Thread 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)

2018-12-28 Thread 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)

2018-12-19 Thread 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

2018-12-12 Thread 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

2018-12-11 Thread 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)

2018-12-10 Thread 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

2018-12-04 Thread 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

2018-11-19 Thread 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.

2018-09-04 Thread 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?

2018-08-24 Thread 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]

2018-08-16 Thread 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

2018-08-04 Thread 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

2018-08-04 Thread 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

2018-08-04 Thread 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?

2018-08-03 Thread 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?

2018-08-03 Thread 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

2018-08-03 Thread 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

2018-08-02 Thread 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

2018-08-01 Thread 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"


Re: svn commit: r336751 - head/usr.sbin/pw

2018-07-27 Thread Ian Lepore
On Fri, 2018-07-27 at 14:43 +, Li-Wen Hsu wrote:
> On Thu, Jul 26, 2018 at 20:03:11 +0000, Ian Lepore wrote:
> > 
> > Author: ian
> > Date: Thu Jul 26 20:03:11 2018
> > New Revision: 336751
> > URL: https://svnweb.freebsd.org/changeset/base/336751
> > 
> > Log:
> >   Re-apply r336625 which was reverted with r336638, now that the underlying
> >   pw_scan(3) has been fixed in a way that doesn't perturb other callers of
> >   it or the getpwnam(3) family.
> >   
> >   Make pw(8) showuser work the same with or without -R  for non-root
> >   users.  Without -R, pw(8) uses getpwnam(3), which will open master.passwd
> >   for the root user or passwd for non-root users.  With -R  pw(8) was
> >   always opening /master.passwd, which would fail for a non-root user,
> >   then falsely claim the userid you're trying to show doesn't exist.
> >   
> >   Now for a non-root user it opens /passwd, and populates the fields in
> >   the returned struct passwd which aren't present in that file with 
> > well-known
> >   canonical values, which duplicates the behavior of getpwnam(3).  The net
> >   effect is that the showuser output is identical whether using -R or not.
> > 
> > Modified:
> >   head/usr.sbin/pw/pw_vpw.c
> Hi Ian,
> 
> It seems usr.sbin.pw.* tests are failing after this commit:
> 
> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/8367/testReport/
> 
> Can you help me check this is realted to the new pw code or there is
> anything we need to modify in the test VM setup or running environment.
> 
> The related artifacts are available here:
> 
> https://artifact.ci.freebsd.org/snapshot/head/r336751/amd64/amd64/
> 
> You can use disk-test.img.xz which is a VM with setup testing
> environment.  The build script will start automatically but you can
> ctrl-c to interrupt anytime and run tests by hand:
> 
> cd /usr/tests/usr.sbin/pw
> kyua test

This was just an error on my part, the code was wrong and I fixed it in
r336762. This time I made sure the kyua tests pass first.

I had intended to run the kyua tests before and after re-applying my
changes to pw(8). Now that I look in my scrollback, it seems I ran the
"before" tests, then got distracted and forgot to run them again after
and just committed the changes. Sorry about the breakage.

-- 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 as ntpd user question

2018-07-23 Thread Ian Lepore
On Mon, 2018-07-23 at 18:54 -0700, bob prohaska wrote:
> On Mon, Jul 23, 2018 at 09:34:26PM +0200, Herbert J. Skuhra wrote:
> > 
> > 
> > Yes, first you press m. Then you will see differences of installed
> > file (left) and new file (right). Then you press either l or
> > r:
> > 
> > l | 1:  choose left diff
> > r | 2:  choose right diff
> > 
> > If the diff tries to remove/add to many lines you can:
> > 
> > el: edit left diff
> > er: edit right diff
> > 
> > And if done you can view the merged file (v) before installing (i)
> > it.
> > 
> > I am sure, someone can explain it better! :)
> > 
> Perhaps, but you've made the essential point. Your reply let me
> understand that 
> mergemaster does not really "master" the merge, it rather identifies
> files needing 
> to be merged and then starts sdiff to let me modify files. Never
> having even looked 
> at sdiff, the learning curve proved very steep. Too steep, in fact.
> 
> I'm going to try a more incremental approach. 
> 
> Thank you _very_ much!
> 
> bob prohaska

Your reaction to mergemaster is about the same as mine was when I first
encountered it very long ago, and re-discovered when I tried it a
couple years ago. It just seems like more trouble than it's worth, I
can usually figure out what's broken and fix it by hand faster than
messing with all the merge stuff.

But, someone told me that if you give mergemaster the right flags it
can potentially be intervention-free. Those apparently aren't the flag
or two that're suggested at the bottom of UPDATING. So I didn't really
dig into that any deeper, but I toss it out there in case someone can
expand on it.

It certainly makes some sense that it could be done intervention-free.
When doing other diff-based merges (like 'svn update') you only have to
intervene when there's an actual conflict between some local change
you've made and the incoming 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: ntpd as ntpd user question

2018-07-22 Thread Ian Lepore
On Sat, 2018-07-21 at 15:09 -0700, bob prohaska wrote:
> On Sat, Jul 21, 2018 at 12:14:10PM -0600, Ian Lepore wrote:
> > 
> > 
> > I can't see any way that installkernel would lead to the complaint
> > about the ntpd user not existing; that check is tied to the
> > installworld target.
> > 
> My mistake. I was sleepy and in a hurry. The error message was in
> installworld
> and my attempt to adduser ntpd concluded with an error:
> Locked : yes
> OK? (yes/no): yes
> pw: Bad id 'ntpd': invalid
> adduser: ERROR: There was an error adding user (ntpd).
> On reboot the old ntpd set the clock and I thought all was well.
> 
> The failure is a little surprising, is ntpd a reserved name?
> 
> The machine is re-running buildworld/installworld from a clean start,
> so presumably it'll halt over the same error again. When that
> happens, 
> what's the simplest way to recover? Mergemaster is a big hammer,
> something
> less comprehensive might suffice, even manual editing of files.  
> 
> There's minimal customization on the machine, basically /etc/fstab, 
> /etc/rc.conf and /etc/passwd. Nothing else of real value, so if I
> kill 
> it in the attempt it won't be a disaster.
> 
> 
> Thanks for waking me to my blunder...
> 
> bob prohaska
>  

The important changes that mergemaster would handle are:

  - add ntpd user, id 123
  - add ntpd group, id 123
  - set ntpd_flags="" in /etc/defaults/rc.conf
  - install the new /etc/rc.d/ntpd

You can add the user by doing vipw and pasting the ntpd line from
/usr/src/etc/master.passwd, IMO easier than doing adduser and answering
all the questions.

-- 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 as ntpd user question

2018-07-21 Thread Ian Lepore
On Sat, 2018-07-21 at 10:47 -0700, bob prohaska wrote:
> On Sat, Jul 21, 2018 at 11:14:45AM -0600, Ian Lepore wrote:
> > 
> > 
> > There's a "pre-world" stage of mergemaster (-Fp option I think) which
> > isn't needed often, but one of the times it is needed is apparently
> > when new user ids are added. ?(So I've been told, I've never much used
> > mergemaster myself). I think there are some words about it at the very
> > bottom of UPDATING.
> > 
> FWIW, installkernel stopped with the note about needing an ntpd user/group.
> Never having been successful with mergemaster (couldn't make heads nor tails
> of the "what to do" prompts) I just ran adduser, creating a locked ntpd user
> and group. Nothing else special done. The machine is up to r336567 on arm64.
> 
> Installkernel ran, I didn't touch anthing in /etc manually and reboot looked 
> normal.
> For now it seems ignorance is bliss
> 
> If there's something special I should do (beyond locking) to secure the ntpd 
> account please warn me.
> 
> Thanks for reading,
> 
> bob prohaska

I can't see any way that installkernel would lead to the complaint
about the ntpd user not existing; that check is tied to the
installworld target.

A quick way to check whether ntpd is running as ntpd user:

 procstat cred `pgrep ntpd`

 PID  COMM  EUID  RUID SVUID  EGID  RGID SVGID UMASK FLAGS GROUPS
 1176 ntpd   123   123   123   123   123   123   022 - 123

-- 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 as ntpd user question

2018-07-21 Thread Ian Lepore
On Sat, 2018-07-21 at 10:11 -0700, Pete Wright wrote:
> 
> On 07/21/2018 09:47, Ian Lepore wrote:
> > 
> > On Sat, 2018-07-21 at 09:41 -0700, Pete Wright wrote:
> > > 
> > > hello - i am testing out the new ntpd that was committed
> > > yesterday and
> > > am attempting to run as non-root.  i've created a ntpd
> > > user/group, and
> > > verified permissions look good on pertinent directories.  i am
> > > running
> > > into an issue with the rc script tho - it's complaining about
> > > multiple
> > > pid files being specified?
> > > 
> > > $ sudo /etc/rc.d/ntpd start
> > > Starting ntpd.
> > > ntpd error:  only one pidfile option allowed
> > > ntpd - NTP daemon program - Ver. 4.2.8p11
> > > Usage:  ntpd [ - [] | --[{=| }] ]... \
> > >       [  ...  ]
> > > Try 'ntpd --help' for more information.
> > > /etc/rc.d/ntpd: WARNING: failed to start ntpd
> > > 
> > > 
> > > has anyone else seen this issue? not sure if this is an issue
> > > with my
> > > local config or not, i've read through the rc script and its not
> > > obvious
> > > to me yet why it may be getting multiple pid arguments passed. 
> > > the only
> > > relevant bit i have set in rc.conf is:
> > > 
> > > $ grep ntpd /etc/rc.conf
> > > ntpd_enable="YES"
> > > 
> > > 
> > > thanks!
> > > -pete
> > > 
> > You say you created an ntpd user/group, that seems to imply you
> > didn't
> > run mergemaster (which would have done that). If that's the case,
> > you
> > probably also didn't get /etc/defaults/rc.conf updated, so it still
> > has
> > the old ntpd_flags that includes the pidfile (which is now provided
> > by
> > the startup script and shouldn't be set in ntpd_flags).
> > 
> > If all of that is the wrong guess, let me know and we'll figure it
> > out.
> that's Ian - that's most likely it (defaults/rc.conf).  i did run 
> mergemaster but i suspect i didn't run it correctly b/c it didn't
> copy 
> over any files, nor create the ntpd uid/gid.  my buildworld script
> does 
> a "mergemaster -m $CHECKOUT -a".  i'll re-read the man page today
> and 
> update my scripts accordingly.
> 
> thanks again for the bread-crumb!
> -pete
> 

There's a "pre-world" stage of mergemaster (-Fp option I think) which
isn't needed often, but one of the times it is needed is apparently
when new user ids are added.  (So I've been told, I've never much used
mergemaster myself). I think there are some words about it at the very
bottom of UPDATING.

-- 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 as ntpd user question

2018-07-21 Thread Ian Lepore
On Sat, 2018-07-21 at 09:41 -0700, Pete Wright wrote:
> hello - i am testing out the new ntpd that was committed yesterday and 
> am attempting to run as non-root.  i've created a ntpd user/group, and 
> verified permissions look good on pertinent directories.  i am running 
> into an issue with the rc script tho - it's complaining about multiple 
> pid files being specified?
> 
> $ sudo /etc/rc.d/ntpd start
> Starting ntpd.
> ntpd error:  only one pidfile option allowed
> ntpd - NTP daemon program - Ver. 4.2.8p11
> Usage:  ntpd [ - [] | --[{=| }] ]... \
>      [  ...  ]
> Try 'ntpd --help' for more information.
> /etc/rc.d/ntpd: WARNING: failed to start ntpd
> 
> 
> has anyone else seen this issue? not sure if this is an issue with my 
> local config or not, i've read through the rc script and its not obvious 
> to me yet why it may be getting multiple pid arguments passed.  the only 
> relevant bit i have set in rc.conf is:
> 
> $ grep ntpd /etc/rc.conf
> ntpd_enable="YES"
> 
> 
> thanks!
> -pete
> 

You say you created an ntpd user/group, that seems to imply you didn't
run mergemaster (which would have done that). If that's the case, you
probably also didn't get /etc/defaults/rc.conf updated, so it still has
the old ntpd_flags that includes the pidfile (which is now provided by
the startup script and shouldn't be set in ntpd_flags).

If all of that is the wrong guess, let me know and we'll figure it out.

-- 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: [PATCH] Recent libm additions

2018-07-15 Thread Ian Lepore
On Sun, 2018-07-15 at 11:55 -0600, Warner Losh wrote:
> On Sun, Jul 15, 2018, 11:23 AM K. Macy  wrote:
> 
> > 
> > > 
> > > 
> > > Well, actually, the functions in polevll.c should have been
> > > copied
> > > into ld80/e_powl.c, and polevall.c should never have been
> > > committed.
> > > Unfortunately, the code was not reviewed for correctness.
> > That is not correct. Please stop repeating it. Bruce Evans and John
> > Baldwin were both looped in. Neither made this observation.
> > 
> Steve is the fp guy these days. And it wasn't reviewed by him. He's
> mad you
> cut him out of the loop. Arguing about pedantic points of process
> does no
> one any good.
> 
> Warner

On the other hand, what information is there for someone to know that
Steve should be involved in a review? There is nothing in MAINTAINERS.
The review was on phab for almost a month, and phab is supposedly the
preferred way to do reviews these days.

Steve is no longer a committer, but that doesn't preclude him having a
phab account and participating in reviews. If he doesn't like using
phab (and I can certainly understand that POV), an entry in MAINTAINERS
would still be helpful, unless we have a rule that only committers can
be listed in there.

-- 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: [PATCH] Recent libm additions

2018-07-15 Thread Ian Lepore
On Sun, 2018-07-15 at 08:06 -0700, Steve Kargl wrote:
> Apparently, the recents additions to libm were not
> subject to any code review.  The following patch 
> does two things.  First, it works around
> 
> https://bugs.llvm.org/show_bug.cgi?id=8532
> 
> Second, it removes the pollution of libm with the
> polevll.c functions.  Those functions are used 
> only in ld80/e_powl.c, and those functions should
> be inlined.
> 
> Index: Makefile
> ===
> --- Makefile  (revision 336304)
> +++ Makefile  (working copy)
> @@ -56,7 +56,6 @@
>   imprecise.c \
>   k_cos.c k_cosf.c k_exp.c k_expf.c k_rem_pio2.c k_sin.c k_sinf.c \
>   k_tan.c k_tanf.c \
> - polevll.c \
>   s_asinh.c s_asinhf.c s_atan.c s_atanf.c s_carg.c s_cargf.c s_cargl.c \
>   s_cbrt.c s_cbrtf.c s_ceil.c s_ceilf.c s_clog.c s_clogf.c \
>   s_copysign.c s_copysignf.c s_cos.c s_cosf.c \
> Index: ld80/e_powl.c
> ===
> --- ld80/e_powl.c (revision 336304)
> +++ ld80/e_powl.c (working copy)
> @@ -77,6 +77,7 @@
>  #include 
>  
>  #include "math_private.h"
> +#include "polevll.c"
>  
>  /* Table size */
>  #define NXT 32
> Index: src/math_private.h
> ===
> --- src/math_private.h(revision 336304)
> +++ src/math_private.h(working copy)
> @@ -828,7 +828,4 @@
>  long double __kernel_cosl(long double, long double);
>  long double __kernel_tanl(long double, long double, int);
>  
> -long double __p1evll(long double, void *, int);
> -long double __polevll(long double, void *, int);
> -
>  #endif /* !_MATH_PRIVATE_H_ */
> Index: src/polevll.c
> ===
> --- src/polevll.c (revision 336304)
> +++ src/polevll.c (working copy)
> @@ -69,7 +69,7 @@
>   * Polynomial evaluator:
>   *  P[0] x^n  +  P[1] x^(n-1)  +  ...  +  P[n]
>   */
> -long double
> +static inline long double
>  __polevll(long double x, void *PP, int n)
>  {
>   long double y;
> @@ -88,7 +88,7 @@
>   * Polynomial evaluator:
>   *  x^n  +  P[0] x^(n-1)  +  P[1] x^(n-2)  +  ...  +  P[n]
>   */
> -long double
> +static inline long double
>  __p1evll(long double x, void *PP, int n)
>  {
>   long double y;
> Index: src/s_cpow.c
> ===
> --- src/s_cpow.c  (revision 336304)
> +++ src/s_cpow.c  (working copy)
> @@ -60,7 +60,7 @@
>   y = cimag (z);
>   absa = cabs (a);
>   if (absa == 0.0) {
> - return (0.0 + 0.0 * I);
> + return (CMPLX(0.0, 0.0));
>   }
>   arga = carg (a);
>   r = pow (absa, x);
> @@ -69,6 +69,6 @@
>   r = r * exp (-y * arga);
>   theta = theta + y * log (absa);
>   }
> - w = r * cos (theta) + (r * sin (theta)) * I;
> + w = CMPLX(r * cos (theta),  r * sin (theta));
>   return (w);
>  }
> Index: src/s_cpowf.c
> ===
> --- src/s_cpowf.c (revision 336304)
> +++ src/s_cpowf.c (working copy)
> @@ -59,7 +59,7 @@
>   y = cimagf(z);
>   absa = cabsf (a);
>   if (absa == 0.0f) {
> - return (0.0f + 0.0f * I);
> + return (CMPLXF(0.0f, 0.0f));
>   }
>   arga = cargf (a);
>   r = powf (absa, x);
> @@ -68,6 +68,6 @@
>   r = r * expf (-y * arga);
>   theta = theta + y * logf (absa);
>   }
> - w = r * cosf (theta) + (r * sinf (theta)) * I;
> + w = CMPLXF(r * cosf (theta), r * sinf (theta));
>   return (w);
>  }
> Index: src/s_cpowl.c
> ===
> --- src/s_cpowl.c (revision 336304)
> +++ src/s_cpowl.c (working copy)
> @@ -59,7 +59,7 @@
>   y = cimagl(z);
>   absa = cabsl(a);
>   if (absa == 0.0L) {
> - return (0.0L + 0.0L * I);
> + return (CMPLXL(0.0L, 0.0L));
>   }
>   arga = cargl(a);
>   r = powl(absa, x);
> @@ -68,6 +68,6 @@
>   r = r * expl(-y * arga);
>   theta = theta + y * logl(absa);
>   }
> - w = r * cosl(theta) + (r * sinl(theta)) * I;
> + w = CMPLXL(r * cosl(theta), r * sinl(theta));
>   return (w);
>  }
> 

If a file contains inline function definitions and is intended only to
be included into another file and not compiled separately, shouldn't
its name be spelled polevll.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: sys/Makefile .if defined(MODULES_WITH_WORLD)

2018-07-09 Thread Ian Lepore
On Mon, 2018-07-09 at 11:50 +0200, Julian H. Stacey wrote:
> Hi current@
> src/sys/dev/amdsbwd/amdsbwd.c broke src/sys/modules
> 
> Is it immediately intuitive & well known to developers working in
> sys/dev
> to enable MODULES_WITH_WORLD before a test make all before a commit ?
> 
> Or what should we do to increase the liklehood of commiters catching
> modules/ errors before a commit ?
> 
> With src/
>   .ctm_status src-cur 13573
>   .svn_revision 335362
> sys/Makefile has
>   .if defined(MODULES_WITH_WORLD)
>   SUBDIR+=modules
> & nothing from cd /usr/src; find . -name \*src.conf\*
> & no default /etc/src.conf with no
>   MODULES_WITH_WORLD=YES
> so make all does not build /sys/modules/ 
> so this not seen from /sys/modules/
> ===> amdsbwd (all)
> cc  -O2 -pipe -DBERKLIX=YES  -fno-strict-aliasing -Werror -D_KERNEL
> -DKLD_MODULE -nostdinc   -I. -I/data/release/s1/usr/src/sys
> -I/data/release/s1/usr/src/sys/contrib/ck/include -fno-common  -fno-
> omit-frame-pointer -mno-omit-leaf-frame-pointer   -MD  -
> MF.depend.amdsbwd.o -MTamdsbwd.o -mcmodel=kernel -mno-red-zone -mno-
> mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables
> -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls
> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-
> arith -Wcast-qual -Wundef -Wno-pointer-sign
> -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs
> -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-
> tautological-compare -Wno-error-empty-body -Wno-error-parentheses-
> equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-
> error-shift-negative-value -Wno-address-of-packed-member  -mno-aes
> -mno-avx  -std=iso9899:1999 -c
> /data/release/s1/usr/src/sys/dev/amdsbwd/amdsbwd.c -o amdsbwd.o
> /data/release/s1/usr/src/sys/dev/amdsbwd/amdsbwd.c:52:10: fatal
> error: 
>   'opt_amdsbwd.h' file not found
> #include "opt_amdsbwd.h"
> 
> 
> PS With 
>   .ctm_status src-cur 13601
>   .svn_revision   336117
> nothing from
>   find . -name opt_amdsbwd.h
> but this has
>   src/sys/dev/amdsbwd/amdsbwd.c
>   #include "opt_amdsbwd.h"
> I haven't yet upgraded my src/ yet to see if it still fails.
> 
> Cheers,
> Julian

Should be fixed in r336134.

-- 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?

2018-07-08 Thread Ian Lepore
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 
> 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  > > 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 week.
> > > >
> > > > Warner
> > > >
> > > > On Wed, Apr 11, 2018 at 1:03 PM, Oliver Pinter
> > > >  > > 
> > >  > > >>
> > > > wrote:
> > > >
> > > > Hi!
> > > >
> > > > Is there any update regarding the rebase or the
> > > inclusion to
> > base
> > > 
> > > > system?
> > > > On 3/28/18, Eric McCorkle  > >  > e...@metricspace.net>
> > > 
> > > >  > > et>>>
> > wrote:
> > > 
> > > > > I'll do another rebase from head just to be sure
> > > > >
> > > > > On March 28, 2018 3:23:23 PM EDT, Warner Losh <
> > i...@bsdimp.com 
> > > 
> > > > >> wrote:
> > > > >>It's on my list for nexr, finally. I have an
> > > alternate patch
> > for
> > > 
> > > > >>loader.efi
> > > > >>from ESP, but i don't think it will affect the GELI
> > > stuff. I
> > have some
> > > 
> > > > >>time
> > > > >>slotted for integration issues though.
> > > > >>
> > > > >>I am quite mindful of the freeze dates I  have
> > > some uefi
> > boot
> > > 
> > > > >>loader
> > > > >>protocol changes that I need to get in.
> > > > >>
> > > > >>Warner
> > > > >>
> > > > >>On Feb 21, 2018 11:18 PM, "Tommi Pernila" <
> > tommi.pern...@iki.fi 
> > > 
> > > >  > > fi>>>
> > wrote:
> > > 
> > > > >>
> > > > >>> Awesome, thanks for the update and the work that
> > > you have
> > done!
> > > 
> > > > >>>
> > > > >>> Now we just need some more reviewers eyes on the
> > > code :)
> > > > >>>
> > > > >>> Br,
> > > > >>>
> > > > >>> Tommi
> > > > >>>
> > > > >>> On Thu, 22 Feb 2018 at 2.03, Eric McCorkle <
> > e...@metricspace.net 
> > > 
> > > >  > > et>>>
> > > > >>wrote:
> > > > >>>
> > > >  FYI, I just IFC'ed everything, and the current
> > > patches
> > > are still
> > > > >>fine.
> > > > 
> > > >  Also, the full GELI + standalone loader has been
> > > deployed
> > > on one of
> > > > >>my
> > > >  laptops for some time now.
> > > > 
> > > >  On 02/21/2018 18:15, Eric McCorkle wrote:
> > > >  > The GELI work could be merged at this point,
> > > though it
> > > won't be
> > > > >>usable
> > > >  > without an additional patch to enable loader-
> > > only
> > > operation.  

Re: TSC calibration in virtual machines

2018-06-27 Thread Ian Lepore
On Wed, 2018-06-27 at 10:05 -0700, Rodney W. Grimes wrote:
> > 
> > On Wed, Jun 27, 2018 at 10:36 AM, Jung-uk Kim 
> > wrote:
> > 
> > > 
> > > On 06/27/2018 03:14, Andriy Gapon wrote:
> > > > 
> > > > 
> > > > It seems that TSC calibration in virtual machines sometimes can
> > > > do more
> > > harm
> > > > 
> > > > than good.  Should we default to trusting the information
> > > > provided by a
> > > hypervisor?
> > > > 
> > > > 
> > > > Specifically, I am observing a problem on GCE instances where
> > > > calibrated
> > > TSC
> > > > 
> > > > frequency is about 10% lower than advertised frequency.  And
> > > > apparently
> > > the
> > > > 
> > > > advertised frequency is the right one.
> > > > 
> > > > I found this thread with similar reports and a variety of
> > > > workarounds
> > > from
> > > > 
> > > > administratively disabling the calibration to switching to a
> > > > different
> > > timecounter:
> > > > 
> > > > https://lists.freebsd.org/pipermail/freebsd-cloud/2017-
> > > January/80.html
> > > 
> > > We already do that for VMware hosts since r221214.
> > > 
> > > https://svnweb.freebsd.org/changeset/base/221214
> > > 
> > > We should do the same for each hypervisor.
> > > 
> > > Jung-uk Kim
> > > 
> > > 
> > We probably should.  But why does calibration fail in the first
> > place?  If
> > it can fail in a VM, then it can probably fail on bare metal
> > too.  It would
> > be worth investigating.
> No, the failure in a VM is unique to a VM, it has to do with the fact
> your have the hypervisor timeslicing a CPU that you believe to be
> 100%
> dedicated to you.
> 
> There are several white papers, including one from VMWare about what
> they have done to help with the time keeping problems.
> 
> What is suggested above would be a correct thing to do.
> Bhyve creates these issues as well, and use of certain timers
> in a bhyve guest can cause you nightmares with ntp.

Iirc, bhyve's arithmetic when doing timer emulation leads to roundoff
errors that accumulate to effectively make the emulated timer run off-
frequency. The hpet timer was trivial to fix by just redefining it to
run at a power-of-2 frequency to eliminate rounding errors. The other
timers have to run at fixed frequencies, so better arithmetic will be
the way to fix them. I vaguely remember that being harder to do than to
say because of the way the code is currently structured, which is why I
just did the easy fix to the hpet so that people would have at least
one usable timer that didn't give ntpd fits in guest OSes.

-- 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 attach issue from r326073 -> r334996

2018-06-13 Thread Ian Lepore
On Wed, 2018-06-13 at 14:29 -0400, Michael Jung wrote:
> Hi!
> 
> I just tried updating current from r326073 -> r334996 and when
> I try 'geli attach' I get the following error:
> 
> # geli attach -p -k mykey.key /dev/gpt/da14
> geli: Missing keyno argument
> #
> 
> If I boot the old kernel GELI attaches just fine.
> 
> I ran into this once before but can not find the thread.  I recall
> it being a bug... with no resolution.
> 
> I mount zfs partitions over GELI - my painful solution was to
> nuke each GPT partition in the zpool, resilver, repeat and
> rinse until everything was non-encrypted and repeat the cycle
> to re-encrypt.  NOT FUN.
> 
> Looking for suggestions to supply additional information to debug
> and resolve.
> 
> dmesg attached from working kernel.
> 
> Thanks!

r333439 added a '-n keyno' parameter to geli attach, but it's supposed
to default to trying all keys if you don't use -n. Is it possible
you're running a newer kernel (or geom_eli module) than your userland
or vice versa?

-- 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: serial console vs suspend

2018-05-17 Thread Ian Lepore
On Thu, 2018-05-17 at 10:54 +0300, Andriy Gapon wrote:
> 
> It seems that the serial console, or rather a UART used by it, may require
> re-initialization after waking up (from suspend to RAM).  At least one of my
> systems fails to wake up properly if I configure the serial console.  I've 
> done
> some experimenting with cu (and without the console) and the UART seems to be 
> in
> some weird state, it echoes back the input and does not send anything on the
> wire.  I guess that trying to print to the serial console while the UART is in
> that state results in a hang.
> 
> To test the theory I made this hack and it does help:
> Index: sys/dev/uart/uart_tty.c
> ===
> --- sys/dev/uart/uart_tty.c   (revision 333667)
> +++ sys/dev/uart/uart_tty.c   (working copy)
> @@ -114,6 +114,13 @@ uart_cninit(struct consdev *cp)
>   uart_init(di);
>  }
> 
> +void uart_resume(void);
> +void
> +uart_resume(void)
> +{
> + uart_init(_console);
> +}
> +
>  static void
>  uart_cnterm(struct consdev *cp)
>  {
> Index: sys/x86/acpica/acpi_wakeup.c
> ===
> --- sys/x86/acpica/acpi_wakeup.c  (revision 333667)
> +++ sys/x86/acpica/acpi_wakeup.c  (working copy)
> @@ -204,6 +205,8 @@ acpi_wakeup_cpus(struct acpi_softc *sc)
>  }
>  #endif
> 
> +extern void uart_resume(void);
> +
>  int
>  acpi_sleep_machdep(struct acpi_softc *sc, int state)
>  {
> @@ -300,6 +303,7 @@ acpi_sleep_machdep(struct acpi_softc *sc, int stat
>  #else
>   npxresume(susppcbs[0]->sp_fpususpend);
>  #endif
> + uart_resume();
>   }
> 
>   return (1); /* wakeup successfully */
> 
> 
> ===
> 
> This is quick and dirty, of course.
> I think that this should go through the console layer.
> And, obviously, not all consoles actually need such a reinit.
> 
> So, maybe:
> cnresume()
> {
>   for each console {
>   if cn->cn_ops->cn_resume != NULL
>   cn->cn_ops->cn_resume(cn)
>   }
> }
> 
> uart_resume(struct consdev *cp)
> {
>   uart_init(cp->cn_arg);
> }
> 
> What do you think?
> 
> Hmm, it looks like CONSOLE_DRIVER() does not allow to omit a console method.
> So, will I have to add a dummy resume to all console drivers?

Why should it go through the console layer? If the uart hardware needs
some re-init on resume, won't that be true whether the uart is serving
as a console, a dial-in terminal, or the interface to wifi or bluetooth
chip?

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


  1   2   3   4   5   >