Re: devdmatch: Can't read linker file.

[Steve Wills]

FWIW, I ran into this issue on an i386 image I built from an amd64 host 
using poudriere and poudriere image.


Steve

On 03/13/2018 14:44, Warner Losh wrote:

Makes sense. I'd forgotten that kldxref can't do cross-platform stuff
One could arrange to build it targeting arch X but running on the native
host and fix things that way. Nobody has care enough to do that, though
perhaps this gives us a use case for why one might want to try.

Warner

On Tue, Mar 13, 2018 at 11:41 AM, Daniel Braniss 
wrote:




On 13 Mar 2018, at 19:12, Edward Napierala  wrote:

I think it's only needed for kernels that are cross-built.  That's due to
kldxref(8) being unable to handle kernels for other architectures.

my case exactly.

2018-03-13 13:34 GMT+00:00 Warner Losh :


I wonder why that isn't the default, or why the linker.hints isn't at
least
created by the make installkernel step...

Warner

On Tue, Mar 13, 2018 at 2:40 AM, Edward Tomasz Napierała <
tr...@freebsd.org>
wrote:


FWIW, it seems to be a common problem, see https://reviews.freebsd.org/
D14534.

On 0312T1027, Warner Losh wrote:

Well, is there a /boot/kernel/linker.hints?

Warner

On Mon, Mar 12, 2018 at 9:56 AM, Daniel Braniss 

wrote:



Hi,
the above i get on arm/nanopi-neo. (it’s the only platform I run

current

:-)

cheers,
 danny



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






___
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: devdmatch: Can't read linker file.

[Edward Napierala]

Hm.  Perhaps we should make kldxref_enable default to YES by default
on all platforms, then?  The overhead is pretty much none when it has
nothing to do - it won't try to recreate the linker.hints if it already
exists.

2018-03-14 17:01 GMT+00:00 Steve Wills :

> FWIW, I ran into this issue on an i386 image I built from an amd64 host
> using poudriere and poudriere image.
>
> Steve
>
>
> On 03/13/2018 14:44, Warner Losh wrote:
>
>> Makes sense. I'd forgotten that kldxref can't do cross-platform stuff
>> One could arrange to build it targeting arch X but running on the native
>> host and fix things that way. Nobody has care enough to do that, though
>> perhaps this gives us a use case for why one might want to try.
>>
>> Warner
>>
>> On Tue, Mar 13, 2018 at 11:41 AM, Daniel Braniss 
>> wrote:
>>
>>
>>>
>>> On 13 Mar 2018, at 19:12, Edward Napierala  wrote:
>>>
>>> I think it's only needed for kernels that are cross-built.  That's due to
>>> kldxref(8) being unable to handle kernels for other architectures.
>>>
>>> my case exactly.
>>>
>>> 2018-03-13 13:34 GMT+00:00 Warner Losh :
>>>
>>> I wonder why that isn't the default, or why the linker.hints isn't at
 least
 created by the make installkernel step...

 Warner

 On Tue, Mar 13, 2018 at 2:40 AM, Edward Tomasz Napierała <
 tr...@freebsd.org>
 wrote:

 FWIW, it seems to be a common problem, see https://reviews.freebsd.org/
> D14534.
>
> On 0312T1027, Warner Losh wrote:
>
>> Well, is there a /boot/kernel/linker.hints?
>>
>> Warner
>>
>> On Mon, Mar 12, 2018 at 9:56 AM, Daniel Braniss 
>>
> wrote:
>
>>
>> Hi,
>>> the above i get on arm/nanopi-neo. (it’s the only platform I run
>>>
>> current
>
>> :-)
>>>
>>> cheers,
>>>  danny
>>>
>>>
>>> ___
>> 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@f
 reebsd.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: Speed up CD/DVD-based FreeBSD

[Rodney W. Grimes]

> On Mon, 12 Mar 2018 09:00:28 +0100
> Andreas Nilsson  wrote:
> Sorry for the late reply, I'll answer inline, see below.
> > On Mon, Mar 12, 2018 at 8:30 AM, Rodney W. Grimes <
> > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > 
> > > > We have a special case of running FreeBSD (actually a NanoBSD)
> > > > from a  
> > > CD/DVD.  
> > > > The reason behind using a CD/DVD is to prevent manipulations.
> > > >
> > > > Now, after the GUI hass started, the system autologin a user and  
> > > autostarts  
> > > > Firefox. But starting Firefox takes ~ 5 - 7 minutes, while the
> > > > operating  
> > > system  
> > > > takes 2 - 3 minutes. As you can imagine, this isn't quite a
> > > > useful time.
> > > >
> > > > Is there a simple way, considering enough RAM in the box, to
> > > > speed up the process? Loading Firefox makes the DVD drive moving
> > > > the head very often  
> > > - I  
> > > > assume this is the fact because I can hear the head scratiching
> > > > around  
> > > very  
> > > > intense.
> > > >
> > > > Does FreeBSD bring tools/facilities onboard to achive what I'm  
> > > requesting or do  
> > > > I need an additional port/softwarepackage?  
> > >
> > > Are you custom building this CD-rom image, or is it just a slightly
> > > modified
> > > stock FreeBSD distritbution with some scripts?
> 
> I do not understand correctly what you mean by "stock FreeBSD". I do

I was refering to one of the .iso files avaliable on FreeBSD.org.

> not change the sources. It is mostly NanoBSD-driven, but the resulting
> system is highly minimalistic by excluding those parts of the OS which
> are usually not needed when running embedded applications apart from
> development. So, there are lots of WITHOUT_ tags while building and
> more importantly while installing the resulting image.
> 
> The image itself is "custom made", since NanoBSD doesn't offer a proper
> CD9660 build script. But, it isn't hard to add some functionality to
> achive this task.

So you are running a roll your own release, and not a stock
FreeBSD image, this makes it easier to fix your performance
related issue.

O(1) would be to get /lib and /usr/lib/... in a tmpfs memory file
system, then probably /usr/local/lib.  This is not a huge amount
of memory:
6522/lib
55317   /usr/lib
639983  /usr/local/lib

fyi, firefox has a chunk in /usr/local/lib:
du -s /usr/local/lib/firefox/
79768   /usr/local/lib/firefox/

My /usr/local/lib is probably significantly larger than yours,
as I have full X11 + many apps, including firefox:
pkg info | wc -l
448

> The "bloat" of 2,6 GB size comes from the utoization of X11,
> windowmaker and not at last Firefox itself. I'll try to reduce the size
> by using x11/xorg-minimal with adding missing/required ports manually,
> but this issue is another one.

If your whole custom image is only 2.6GB then running this all
in RAM would not be hard to do with a 4GB machine, and very 
comfortable in 8GB.   Reducing this to 2GB would leave you a
2GB of ram for firefox to eat away, and that should be enough.

> The meaning of "having enough/plenty of RAM" is: I'm willing to use at
> least 2GB RAM, at the moment I have 4GB in the box, but 8 is also
> possible. But this box has only one purpose: offering Firefox for
> checking on a remote server for some data. So any RAM  more than
> necessary is a waste of resources.

It looks like 1G of ram dedicated to tmpfs would probably
make your problem disappear.  DVD drives are not good for
random access, and thats what your doing a lot of here,
especially when doing the dynamic linking at exec time.

> > > One suggestion would be to run from a mfs /usr,
> > > including /usr/local, as a sample on how to do this take a look
> > > at /etc/rc.initdiskless that does this for /etc and /var when
> > > booting diskless.
> 
> I'll check this, thanks for the hint.
> 
> > >
> > > I suspect your slow down is shared library linking time, which
> > > would mean you might also solve this problem by building a staticly
> > > linked firefox binary.  This would be much simpler to try out.
> 
> FreeBSD 11.1-RELENG-p7 boot time itself is ~ 3 - 5 minutes (4
> core/thread Haswell customer CPU at >3 GHz and 8 GB RAM from DVD ROM).
> Starting X11 takes another 3 minutes and when windowmaker shows up
> starting Firefox, it takes overall more than 35 minutes until Firefox
> is started and usable. The box is supposed to run 24/7, but consider a
> power surge or lightouts, it is indisputable that booting takes to long.
> 
> Linking Firefox statically would take precautions in the poudriere
> package builder we run for such tasks - well, I guess this would be
> achivable, but for the sake of being most flexible in terms of we can
> use ANY repository I would consider a static linking approach a last
> resort.
> 
> > >
> > > --
> > > Rod Grimes
> > > rgri...@freebsd.org
> > >  
> > 
> > Hello,
> > 
> > doesn't nanoBSD run in ro-mode per 

md(4) ioctl ABI broken by r322969

[Brooks Davis]

Hi,

I just noticed that r322969 consumed part of md_pad in struct md_ioctl.
In moving the start of md_pad this broke the ABI of MDIOCLIST.

At a glance it looks like the struct was sufficiently incompetently
padded to begin with that the change of adding a char * and subtracting
an int did not change the size of the struct and break all the ioctls,
but this definitely warranted a comment in the commit.

At this point I'm not sure what the right thing to do is.  MDIOCLIST
isn't used by anything in the base system and is broken by design so
just deleting it might be acceptable.  A somewhat better approach
would be to delete it from public view and fix it up with a compatibility
shim so it works for old code.  We could put that under COMPAT11.  I
have a patch it the works that would make that easier to do.

-- Brooks


signature.asc
Description: PGP signature

Re: devdmatch: Can't read linker file.

[Warner Losh]

I wouldn't. It make read-only root a pain in the back side Better to
fix kldxref to be a build tool that can cope.

And it isn't something that needs to be done on every boot.

On Wed, Mar 14, 2018 at 11:05 AM, Edward Napierala 
wrote:

> Hm.  Perhaps we should make kldxref_enable default to YES by default
> on all platforms, then?  The overhead is pretty much none when it has
> nothing to do - it won't try to recreate the linker.hints if it already
> exists.
>
> 2018-03-14 17:01 GMT+00:00 Steve Wills :
>
>> FWIW, I ran into this issue on an i386 image I built from an amd64 host
>> using poudriere and poudriere image.
>>
>> Steve
>>
>>
>> On 03/13/2018 14:44, Warner Losh wrote:
>>
>>> Makes sense. I'd forgotten that kldxref can't do cross-platform stuff
>>> One could arrange to build it targeting arch X but running on the native
>>> host and fix things that way. Nobody has care enough to do that, though
>>> perhaps this gives us a use case for why one might want to try.
>>>
>>> Warner
>>>
>>> On Tue, Mar 13, 2018 at 11:41 AM, Daniel Braniss 
>>> wrote:
>>>
>>>

 On 13 Mar 2018, at 19:12, Edward Napierala  wrote:

 I think it's only needed for kernels that are cross-built.  That's due
 to
 kldxref(8) being unable to handle kernels for other architectures.

 my case exactly.

 2018-03-13 13:34 GMT+00:00 Warner Losh :

 I wonder why that isn't the default, or why the linker.hints isn't at
> least
> created by the make installkernel step...
>
> Warner
>
> On Tue, Mar 13, 2018 at 2:40 AM, Edward Tomasz Napierała <
> tr...@freebsd.org>
> wrote:
>
> FWIW, it seems to be a common problem, see
>> https://reviews.freebsd.org/
>> D14534.
>>
>> On 0312T1027, Warner Losh wrote:
>>
>>> Well, is there a /boot/kernel/linker.hints?
>>>
>>> Warner
>>>
>>> On Mon, Mar 12, 2018 at 9:56 AM, Daniel Braniss >> >
>>>
>> wrote:
>>
>>>
>>> Hi,
 the above i get on arm/nanopi-neo. (it’s the only platform I run

>>> current
>>
>>> :-)

 cheers,
  danny


 ___
>>> 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@f
> reebsd.org
> "
>
>


 ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f
>>> reebsd.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: devdmatch: Can't read linker file.

[Edward Napierala]

While making kldxref(8) crossarch-capable would be the best solution,
it's also the most time consuming.  The kldxref rc script doesn't do
anything
if the linker.hints file already exists, so it shouldn't be much of a
problem.


2018-03-14 17:39 GMT+00:00 Warner Losh :

> I wouldn't. It make read-only root a pain in the back side Better to
> fix kldxref to be a build tool that can cope.
>
> And it isn't something that needs to be done on every boot.
>
>
> On Wed, Mar 14, 2018 at 11:05 AM, Edward Napierala 
> wrote:
>
>> Hm.  Perhaps we should make kldxref_enable default to YES by default
>> on all platforms, then?  The overhead is pretty much none when it has
>> nothing to do - it won't try to recreate the linker.hints if it already
>> exists.
>>
>> 2018-03-14 17:01 GMT+00:00 Steve Wills :
>>
>>> FWIW, I ran into this issue on an i386 image I built from an amd64 host
>>> using poudriere and poudriere image.
>>>
>>> Steve
>>>
>>>
>>> On 03/13/2018 14:44, Warner Losh wrote:
>>>
 Makes sense. I'd forgotten that kldxref can't do cross-platform
 stuff
 One could arrange to build it targeting arch X but running on the native
 host and fix things that way. Nobody has care enough to do that, though
 perhaps this gives us a use case for why one might want to try.

 Warner

 On Tue, Mar 13, 2018 at 11:41 AM, Daniel Braniss 
 wrote:


>
> On 13 Mar 2018, at 19:12, Edward Napierala  wrote:
>
> I think it's only needed for kernels that are cross-built.  That's due
> to
> kldxref(8) being unable to handle kernels for other architectures.
>
> my case exactly.
>
> 2018-03-13 13:34 GMT+00:00 Warner Losh :
>
> I wonder why that isn't the default, or why the linker.hints isn't at
>> least
>> created by the make installkernel step...
>>
>> Warner
>>
>> On Tue, Mar 13, 2018 at 2:40 AM, Edward Tomasz Napierała <
>> tr...@freebsd.org>
>> wrote:
>>
>> FWIW, it seems to be a common problem, see
>>> https://reviews.freebsd.org/
>>> D14534.
>>>
>>> On 0312T1027, Warner Losh wrote:
>>>
 Well, is there a /boot/kernel/linker.hints?

 Warner

 On Mon, Mar 12, 2018 at 9:56 AM, Daniel Braniss <
 da...@cs.huji.ac.il>

>>> wrote:
>>>

 Hi,
> the above i get on arm/nanopi-neo. (it’s the only platform I run
>
 current
>>>
 :-)
>
> cheers,
>  danny
>
>
> ___
 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@f
>> reebsd.org
>> "
>>
>>
>
>
> ___
 freebsd-current@freebsd.org mailing list
 https://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to "freebsd-current-unsubscribe@f
 reebsd.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: Conflict between FreeBSD-binutils and FreeBSD-lld packages

[Tobias Kortkamp]

On Sun, Mar 4, 2018, at 02:38, Ed Maste wrote:
> On 2 March 2018 at 04:34, Tobias Kortkamp  wrote:
> > Building pkgbase packages with r330236 results in FreeBSD-binutils and
> > FreeBSD-lld packages conflicting with each other.  Both want to
> > install /usr/share/man/man1/ld.1.gz
> 
> Thanks for the report; this should be fixed as of r330366.

Finally got around to updating. Works fine now. Thank you for the quick fix!
___
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: Speed up CD/DVD-based FreeBSD

[Hartmann, O.]

On Mon, 12 Mar 2018 09:00:28 +0100
Andreas Nilsson  wrote:


Sorry for the late reply, I'll answer inline, see below.


> On Mon, Mar 12, 2018 at 8:30 AM, Rodney W. Grimes <
> freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> 
> > > We have a special case of running FreeBSD (actually a NanoBSD)
> > > from a  
> > CD/DVD.  
> > > The reason behind using a CD/DVD is to prevent manipulations.
> > >
> > > Now, after the GUI hass started, the system autologin a user and  
> > autostarts  
> > > Firefox. But starting Firefox takes ~ 5 - 7 minutes, while the
> > > operating  
> > system  
> > > takes 2 - 3 minutes. As you can imagine, this isn't quite a
> > > useful time.
> > >
> > > Is there a simple way, considering enough RAM in the box, to
> > > speed up the process? Loading Firefox makes the DVD drive moving
> > > the head very often  
> > - I  
> > > assume this is the fact because I can hear the head scratiching
> > > around  
> > very  
> > > intense.
> > >
> > > Does FreeBSD bring tools/facilities onboard to achive what I'm  
> > requesting or do  
> > > I need an additional port/softwarepackage?  
> >
> > Are you custom building this CD-rom image, or is it just a slightly
> > modified
> > stock FreeBSD distritbution with some scripts?

I do not understand correctly what you mean by "stock FreeBSD". I do
not change the sources. It is mostly NanoBSD-driven, but the resulting
system is highly minimalistic by excluding those parts of the OS which
are usually not needed when running embedded applications apart from
development. So, there are lots of WITHOUT_ tags while building and
more importantly while installing the resulting image.

The image itself is "custom made", since NanoBSD doesn't offer a proper
CD9660 build script. But, it isn't hard to add some functionality to
achive this task.


The "bloat" of 2,6 GB size comes from the utoization of X11,
windowmaker and not at last Firefox itself. I'll try to reduce the size
by using x11/xorg-minimal with adding missing/required ports manually,
but this issue is another one.

The meaning of "having enough/plenty of RAM" is: I'm willing to use at
least 2GB RAM, at the moment I have 4GB in the box, but 8 is also
possible. But this box has only one purpose: offering Firefox for
checking on a remote server for some data. So any RAM  more than
necessary is a waste of resources.

> >
> > One suggestion would be to run from a mfs /usr,
> > including /usr/local, as a sample on how to do this take a look
> > at /etc/rc.initdiskless that does this for /etc and /var when
> > booting diskless.

I'll check this, thanks for the hint.

> >
> > I suspect your slow down is shared library linking time, which
> > would mean you might also solve this problem by building a staticly
> > linked firefox binary.  This would be much simpler to try out.

FreeBSD 11.1-RELENG-p7 boot time itself is ~ 3 - 5 minutes (4
core/thread Haswell customer CPU at >3 GHz and 8 GB RAM from DVD ROM).
Starting X11 takes another 3 minutes and when windowmaker shows up
starting Firefox, it takes overall more than 35 minutes until Firefox
is started and usable. The box is supposed to run 24/7, but consider a
power surge or lightouts, it is indisputable that booting takes to long.

Linking Firefox statically would take precautions in the poudriere
package builder we run for such tasks - well, I guess this would be
achivable, but for the sake of being most flexible in terms of we can
use ANY repository I would consider a static linking approach a last
resort.

> >
> > --
> > Rod Grimes
> > rgri...@freebsd.org
> >  
> 
> Hello,
> 
> doesn't nanoBSD run in ro-mode per default, ie it should be somewhat
> tamper proof as is, even installed on disk.

Well, NanoBSD can be configured to mount / ro, but this can be changed.
Running from a DVD ROM provides a better tamper proof solution and I
would prefere the DVD ROM in favour of a potentially writable medium.
At this very moment the test system runs from an USB flash device and
is fairly fast in bootup, > 3 minutes at from hitting the power button
up to have Firefox opened and ready to work.

> 
> If running from optical drive is important, I would have a closer
> look on how pcbsd/trueos sets up their install-discs ( or at least
> used to, haven't tried one in a while ) where they basically load the
> entire file system into ram from a compressed image on the optical
> disc.

Well, thanks for the hint. 

> 
> Best regards
> Andreas

Kind regards,

Oliver
___
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: Speed up CD/DVD-based FreeBSD

[Rozhuk Ivan]

On Wed, 14 Mar 2018 17:13:27 +0100
"Hartmann, O."  wrote:

> The image itself is "custom made", since NanoBSD doesn't offer a
> proper CD9660 build script. But, it isn't hard to add some
> functionality to achive this task.

May be geom_cache can help increase random read speed?
___
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: X1 Carbon 6th gen. ACPI issues

[Kirill Ponomarev]

On 03/10, Kirill Ponomarev wrote:
> Hi,
> 
> it seems new Carbonss have some issues with S3 according to this Lenovo
> thread:
> https://forums.lenovo.com/t5/Linux-Discussion/X1-Carbon-Gen-6-cannot-enter-deep-sleep-S3-state-aka-Suspend-to/td-p/3998182
> 
> The same issues we have in CURRENT:
> hw.acpi.supported_sleep_state: S4 S5
> 
> If someone would like to analyze it and fix, I'm ready to help with
> access and testing.

In case if someone interested, there's a Linux workaround for this
issue:
https://delta-xi.net/#056

K.


signature.asc
Description: PGP signature