Re: FreeBSD CURRENT stabilization cycle

[Franco Fichtner]

Hi,

And whom do you want to „stab“ with this? ;)

Why not do the same thing that ports does and call this „monthly“ which is 
pretty much what it is and easy to understand and you can have one build at the 
end of that week?


Cheers,
Franco

> On 24. Feb 2024, at 12:51, Kirill Ponomarev  wrote:
> 
> On 02/23, Mark Millard wrote:
>> Gleb Smirnoff  wrote on
>> Date: Sat, 24 Feb 2024 04:32:52 UTC :
>> 
>>> More seriously speaking, I
>>> actually hope that in some future snapshots.FreeBSD.org will start using 
>>> these
>>> points for snapshot generation.
>> 
>> How about also the likes of:
>> 
>> https://pkg.freebsd.org/FreeBSD:15:aarch64/stabweek/
>> 
>> for pkgbase (various "aarch64" replacements too)?
> 
> yes, great idea, base_stabweek or similar is something I'd vote for.

Re: FreeBSD CURRENT stabilization cycle

[Kirill Ponomarev]

On 02/23, Mark Millard wrote:
> Gleb Smirnoff  wrote on
> Date: Sat, 24 Feb 2024 04:32:52 UTC :
> 
> > More seriously speaking, I
> > actually hope that in some future snapshots.FreeBSD.org will start using 
> > these
> > points for snapshot generation.
> 
> How about also the likes of:
> 
> https://pkg.freebsd.org/FreeBSD:15:aarch64/stabweek/
> 
> for pkgbase (various "aarch64" replacements too)?

yes, great idea, base_stabweek or similar is something I'd vote for.


signature.asc
Description: PGP signature

RE: FreeBSD CURRENT stabilization cycle

[Mark Millard]

Gleb Smirnoff  wrote on
Date: Sat, 24 Feb 2024 04:32:52 UTC :

> More seriously speaking, I
> actually hope that in some future snapshots.FreeBSD.org will start using these
> points for snapshot generation.

How about also the likes of:

https://pkg.freebsd.org/FreeBSD:15:aarch64/stabweek/

for pkgbase (various "aarch64" replacements too)?

===
Mark Millard
marklmi at yahoo.com

FreeBSD CURRENT stabilization cycle

[Gleb Smirnoff]

  Hi FreeBSD CURRENT users,

back in November I came up with a proposal of providing some stabilization
cadence to development of the main branch, also known as FreeBSD CURRENT.  Here
is a video with the initial proposal and following discussion at VendorBSD
Conference (18 minutes):

https://www.youtube.com/live/k-AzShVdAHo?si=hPAhCd_-RuoTRqcW&t=2511

And here goes an up to date version of the plan!

In the last decade quality of FreeBSD CURRENT improved so much, that not only
brave developers run it on their laptops, but also large companies use it. Time
to bring it to a new level.  Every individual or a business that use CURRENT
has their own protocol of how to stay up date and avoid disasters.  An
individual will first update their desktop and only after that will update
server(s).  A company would run their internal regression test suite or some
other validation protocol.  Right now we all do that independently from each
other having little coordination and providing little help each other.  We also
do not broadcast to the world that FreeBSD CURRENT is usable. I've seen a lot
of people who stay away from CURRENT based on their 20-year old experience with
it.

Here is how we are going to improve:

* Last week of a month is declared a stabilization week

Src committers are encouraged to avoid pushing risky changes to FreeBSD/main
during this week.  This is an advice, not a policy!  If a committer breaks
something during the week they got 3x public shame, but no administrative
penalties or fines.  Committers are encouraged to push bug fixes, improve unit
tests, clean up comments and improve documentation.  It is a also a good time
to do merging of past work to stable branches. Developers of course will
continue their work on bigger projects in their private branches.

Sidenote: there is no agreement in the world what is "the last week of a
month".  For our purposes we will use the week that contains the last Friday of
the month.  Because we want the monthly snapshot to be called by the name of
the month (not next month) and thus we want the last day of the stabilization
cycle always to be in that month.

* Monday of the stabweek is the day to update your CURRENT and test it

Monday 8:00 GMT a tag is created and published.  Right now it is published
at my personal https://github.com/glebius/FreeBSD/tags.  Note that the tag
points at a hash in the official repo, so there is no trust involved here.

At Netflix I will be working on merging the tagged revision into our tree and I
will hand off the resulting branch to our excellent testing team (dhw@ +
olivier@) usually by the end of Monday (PST time).  Other companies and parties
are encouraged to start testing the tagged revision.  Peter Holm may switch his
stress2 to run that revision.  You are encouraged to update your desktop or
laptop that of course runs FreeBSD CURRENT.

* A short lived stabilization branch may be created

In case we discover regressions compared to the previous month stabweek, bug
fixes to them will be committed to a short lived branch.  This branch may
contain direct cherry-picks from main, as well as work-in-progress bugfixes
that had not yet been committed to main, reverts of commits and even stop gaps
that disable certain functionality for the sake of stability.  This branch may
be rebased and force pushed if a temporary bugfix appears different to a final
one in main.  The branch may observe commits immediately Monday morning in case
we already know about a certain regression.  The branch will not observe
commits to a long standing bugs that were fixed in main during the stabweek,
unless somebody explicitly asks to include one.  And finally, the branch may
not even be created in case testing confirms everything is alright with the
Monday tag.

The branch will be published at https://github.com/glebius/FreeBSD.  There is
certain level of trust required to use it. That may change to a more official
publishing point in the future.

* The stabweek quiet period ends no later than Friday 18:00 GMT

No matter if we were able to identify and fix any or all bugs the quiet period
ends.  The public shame level for src committers breaking FreeBSD CURRENT goes
back to normal level.  In a case we were not able to address all issues by end
of Friday the stabweek branch will be active past the end of the stabweek, as
we want to collect all regression fixes in the branch.  But this is the worst
case scenario!

A more appreciated scenario is that the stabilization period ends earlier in
the week. If all testing parties report their satisfaction with state of main
as is or of the stabweek branch and if I don't see any fresh bug reports in
bugzilla or submissions via other channels, there is no reason to withheld
committers with pushing their stuff.

At the end of the stabilization period be it Friday or earlier I will write
email to current@ reporting the results:

- were there any regression identified with the Mo

Re: How do I update the kernel of FreeBSD-CURRENT

[John Nielsen]

On Nov 29, 2023, at 12:21 PM, Manoel Games  wrote:
> 
> I am a new FreeBSD user, and I am using FreeBSD-CURRENT. How do I update the 
> FreeBSD-CURRENT kernel, and is it done through pkg? I installed 
> FreeBSD-CURRENT without src.

As a new user you should probably run a supported release version, such as 
14.0.  Releases have binary updates available via freebsd-update. (Upgrading 
the base OS via pkg is still experimental.) Current has no such feature, so you 
need to download/update the source and recompile.

See the Handbook chapter on upgrading FreeBSD:
https://docs.freebsd.org/en/books/handbook/cutting-edge/

JN

How do I update the kernel of FreeBSD-CURRENT

[Manoel Games]

I am a new FreeBSD user, and I am using FreeBSD-CURRENT. How do I update the 
FreeBSD-CURRENT kernel, and is it done through pkg? I installed FreeBSD-CURRENT 
without src.

Re: Status of Alder and Raptor lake on FreeBSD Current

[Alexey Vyskubov]

> I was wondering what the status of Alder/Raptor lake support is on FreeBSD?
> Does it boot?

I am writing this message from 13.2 machine with i3-12100F (must be an
Alder Lake; no integrated graphics in this one, though) in B660
motherboard. Previously the same machine was running 13.1. If it
matters, I have multiple ZFS pools, including root on ZFS mirror.
According to powermon(8) my package normally consumes less than 10W.

I do not think that the support for an Alder Lake got worse in -CURRENT.

-- 
Alexey

I cannot receive HTML mail at this account.

Hi, I am a signature virus. Add me to your signature to help me spread.

Re: Status of Alder and Raptor lake on FreeBSD Current

[Stephane Rochoy]

Dries Michiels  writes:

I was wondering what the status of Alder/Raptor lake support is 
on FreeBSD?
Does it boot? Integrated graphics are supported from what I 
recall with the

newest drm drivers.
Are there any plans for changes to our scheduler to account for 
efficiency

and performance cores?
Are there real world downsides of not having such a scheduler 
when running

an Alder or Raptor lake CPU?

Interested to hear from users using these CPU's right now in 
there system!
The Reason I ask is that I'm interested in upgrading my home 
server

hardware :-).


Hi,

AFAIK, last status was given by Mike Karels (karels@) on Feb 7,
2023 on freebsd-stable@ [1]. I'm also interested in any news on
the topic :)

[1] 
https://lists.freebsd.org/archives/freebsd-stable/2023-February/001103.html


Regards,
--
Stéphane Rochoy
O: Stormshield

Re: Status of Alder and Raptor lake on FreeBSD Current

[Kevin Oberman]

On Wed, Apr 12, 2023 at 11:43 AM Mike Karels  wrote:

> On 12 Apr 2023, at 9:59, Dries Michiels wrote:
>
> > Hello current mailing list,
> >
> > I was wondering what the status of Alder/Raptor lake support is on
> FreeBSD?
> > Does it boot? Integrated graphics are supported from what I recall with
> the
> > newest drm drivers.
>
-current and 13.2 boot and run on Alder Lake, and probably Raptor Lake (I
> haven’t heard of any tests).  There is a bug, probably in hardware, that
> affects page invalidation on E-cores, but a workaround changes the
> mechanism
> on the E-cores to compensate.  I have no information on graphics, maybe
> someone else does.
>

It works with drm-515-kmod, but I have been unable to get VA-API or DRM to
work much. driinfo reports swrast. Performance is pretty bad compared to my
12 year old Ivy Lake, but surprisingly fast with all 12 threads on my
ThinkPad T16 running. a 1180p video runs at about 13% of the total CPU
capacity. glxgears get a rather paltry 900 FPS. But everything seems to
work.

Mike
>
-- 
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

Re: Status of Alder and Raptor lake on FreeBSD Current

[Mike Karels]

On 12 Apr 2023, at 9:59, Dries Michiels wrote:

> Hello current mailing list,
>
> I was wondering what the status of Alder/Raptor lake support is on FreeBSD?
> Does it boot? Integrated graphics are supported from what I recall with the
> newest drm drivers.

-current and 13.2 boot and run on Alder Lake, and probably Raptor Lake (I
haven’t heard of any tests).  There is a bug, probably in hardware, that
affects page invalidation on E-cores, but a workaround changes the mechanism
on the E-cores to compensate.  I have no information on graphics, maybe
someone else does.

> Are there any plans for changes to our scheduler to account for efficiency
> and performance cores?
> Are there real world downsides of not having such a scheduler when running
> an Alder or Raptor lake CPU?

I have been working on scheduler changes, but slowly.  Things work surprisingly
well without them though.  An E-core is slower than the first thread on a
P-core, but faster than the second thread.  The scheduler puts fewer processes
on the E-cores because of the shared cache in groups of 4 CPUs (vs 2 for SMT
on the P-cores).  Of course, with enough processes, they all get used.

> Interested to hear from users using these CPU's right now in there system!
> The Reason I ask is that I'm interested in upgrading my home server
> hardware :-).

I’m running -current on an i7-12700K, and it feels fast compared to my
i7-10700K.

Mike

Status of Alder and Raptor lake on FreeBSD Current

[Dries Michiels]

Hello current mailing list,

I was wondering what the status of Alder/Raptor lake support is on FreeBSD?
Does it boot? Integrated graphics are supported from what I recall with the
newest drm drivers.
Are there any plans for changes to our scheduler to account for efficiency
and performance cores?
Are there real world downsides of not having such a scheduler when running
an Alder or Raptor lake CPU?

Interested to hear from users using these CPU's right now in there system!
The Reason I ask is that I'm interested in upgrading my home server
hardware :-).

Regards
Dries

Re: Profiled libraries on freebsd-current

[John Baldwin]

On 5/4/22 1:38 PM, Steve Kargl wrote:

On Wed, May 04, 2022 at 01:22:57PM -0700, John Baldwin wrote:

On 5/4/22 12:53 PM, Steve Kargl wrote:

On Wed, May 04, 2022 at 11:12:55AM -0700, John Baldwin wrote:

I don't know the entire FreeBSD ecosystem.  Do people
use FreeBSD on embedded systems (e.g., nanobsd) where
libthr may be stripped out?  Thus, --enable-threads=no
is needed.


If they do, they are also using a constrained userland and
probably are not shipping a GCC binary either.  However, it's
not clear to me what --enable-threads means.

Does this enable -pthread as an option?  If so, that should
definitely just always be on.  It's still an option users have
to opt into via a command line flag and doesn't prevent
building non-threaded programs.

If it's enabling use of threads at runtime within GCC itself,
I'd say that also should probably just be allowed to be on.

I can't really imagine what else it might mean (and I doubt
it means the latter).



AFAICT, it controls whether -lpthread is automatically added to
the command line.  In the case of -pg, it is -lpthread_p.
The relevant lines are

#ifdef FBSD_NO_THREADS
#define FBSD_LIB_SPEC "\
   %{pthread: %eThe -pthread option is only supported on FreeBSD when gcc \
is built with the --enable-threads configure-time option.}  \
   %{!shared:   \
 %{!pg: -lc}
\
 %{pg:  -lc_p}  \
   }"
#else
#define FBSD_LIB_SPEC "\
   %{!shared:   \
 %{!pg: %{pthread:-lpthread} -lc}   \
 %{pg:  %{pthread:-lpthread_p} -lc_p}   \
   }\
   %{shared:\
 %{pthread:-lpthread} -lc   \
   }"
#endif

Ed is wondering if one can get rid of FBSD_NO_THREADS. With the
pending removal of WITH_PROFILE, the above reduces to

#define FBSD_LIB_SPEC " \
   %{!shared:\
 %{pthread:-lpthread} -lc\
   } \
   %{shared: \
 %{pthread:-lpthread} -lc\
   }"

If one can do the above, then freebsd-nthr.h is no longer needed
and can be deleted and config.gcc's handling of --enable-threads
can be updated/removed.


Ok, so it's just if -pthread is supported (%{pthread:-lpthread} only
adds -lpthread if -pthread was given on the command line).  That can just
be on all the time and Ed is correct that it is safe to remove the
FBSD_NO_THREADS case and assume it is always present instead.

--
John Baldwin

Re: Profiled libraries on freebsd-current

[Steve Kargl]

On Wed, May 04, 2022 at 01:22:57PM -0700, John Baldwin wrote:
> On 5/4/22 12:53 PM, Steve Kargl wrote:
> > On Wed, May 04, 2022 at 11:12:55AM -0700, John Baldwin wrote:
> > 
> > I don't know the entire FreeBSD ecosystem.  Do people
> > use FreeBSD on embedded systems (e.g., nanobsd) where
> > libthr may be stripped out?  Thus, --enable-threads=no
> > is needed.
> 
> If they do, they are also using a constrained userland and
> probably are not shipping a GCC binary either.  However, it's
> not clear to me what --enable-threads means.
> 
> Does this enable -pthread as an option?  If so, that should
> definitely just always be on.  It's still an option users have
> to opt into via a command line flag and doesn't prevent
> building non-threaded programs.
> 
> If it's enabling use of threads at runtime within GCC itself,
> I'd say that also should probably just be allowed to be on.
> 
> I can't really imagine what else it might mean (and I doubt
> it means the latter).
> 

AFAICT, it controls whether -lpthread is automatically added to
the command line.  In the case of -pg, it is -lpthread_p.
The relevant lines are

#ifdef FBSD_NO_THREADS
#define FBSD_LIB_SPEC " \
  %{pthread: %eThe -pthread option is only supported on FreeBSD when gcc \
is built with the --enable-threads configure-time option.}  \
  %{!shared:\
%{!pg: -lc} \
%{pg:  -lc_p}   \
  }"
#else
#define FBSD_LIB_SPEC " \
  %{!shared:\
%{!pg: %{pthread:-lpthread} -lc}\
%{pg:  %{pthread:-lpthread_p} -lc_p}\
  } \
  %{shared: \
%{pthread:-lpthread} -lc\
  }"
#endif

Ed is wondering if one can get rid of FBSD_NO_THREADS. With the
pending removal of WITH_PROFILE, the above reduces to

#define FBSD_LIB_SPEC " \
  %{!shared:\
%{pthread:-lpthread} -lc\
  } \
  %{shared: \
%{pthread:-lpthread} -lc\
  }"

If one can do the above, then freebsd-nthr.h is no longer needed
and can be deleted and config.gcc's handling of --enable-threads
can be updated/removed.

-- 
Steve

Re: Profiled libraries on freebsd-current

[John Baldwin]

On 5/4/22 12:53 PM, Steve Kargl wrote:

On Wed, May 04, 2022 at 11:12:55AM -0700, John Baldwin wrote:

On 5/2/22 10:37 AM, Steve Kargl wrote:

On Mon, May 02, 2022 at 12:32:25PM -0400, Ed Maste wrote:

On Sun, 1 May 2022 at 11:54, Steve Kargl
 wrote:


diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h
index 594487829b5..1e8ab2e1827 100644
--- a/gcc/config/freebsd-spec.h
+++ b/gcc/config/freebsd-spec.h
@@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
  (similar to the default, except no -lg, and no -p).  */

   #ifdef FBSD_NO_THREADS


I wonder if we can simplify things now, and remove this
`FBSD_NO_THREADS` case. I didn't see anything similar in other GCC
targets I looked at.


That I don't know.  FBSD_NO_THREADS is defined in freebsd-nthr.h.
In fact, it's the only thing in that header (except copyright
broilerplate).  freebsd-nthr.h only appears in config.gcc and
seems to only get added to the build if someone runs configure
with --enable-threads=no.  Looking at my last config.log for
gcc trunk, I see "Thread model: posix", which appears to be
the default case or if someone does --enable-threads=yes or
--enable-threads=posix.  So, I suppose it comes down to
two questions: (1) is libpthread.* available on all supported
targets and versions? (2) does anyone build gcc without
threads support?


libpthread is available on all supported architectures on all
supported versions.  libthr has been the default threading library
since 7.0 and the only supported library since 8.0.  In GDB I just
assume libthr style threads, and I think GCC can safely do the
same.



I don't know the entire FreeBSD ecosystem.  Do people
use FreeBSD on embedded systems (e.g., nanobsd) where
libthr may be stripped out?  Thus, --enable-threads=no
is needed.


If they do, they are also using a constrained userland and
probably are not shipping a GCC binary either.  However, it's
not clear to me what --enable-threads means.

Does this enable -pthread as an option?  If so, that should
definitely just always be on.  It's still an option users have
to opt into via a command line flag and doesn't prevent
building non-threaded programs.

If it's enabling use of threads at runtime within GCC itself,
I'd say that also should probably just be allowed to be on.

I can't really imagine what else it might mean (and I doubt
it means the latter).

--
John Baldwin

Re: Profiled libraries on freebsd-current

[Steve Kargl]

On Wed, May 04, 2022 at 11:12:55AM -0700, John Baldwin wrote:
> On 5/2/22 10:37 AM, Steve Kargl wrote:
> > On Mon, May 02, 2022 at 12:32:25PM -0400, Ed Maste wrote:
> > > On Sun, 1 May 2022 at 11:54, Steve Kargl
> > >  wrote:
> > > > 
> > > > diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h
> > > > index 594487829b5..1e8ab2e1827 100644
> > > > --- a/gcc/config/freebsd-spec.h
> > > > +++ b/gcc/config/freebsd-spec.h
> > > > @@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME 
> > > > respectively.  If not, see
> > > >  (similar to the default, except no -lg, and no -p).  */
> > > > 
> > > >   #ifdef FBSD_NO_THREADS
> > > 
> > > I wonder if we can simplify things now, and remove this
> > > `FBSD_NO_THREADS` case. I didn't see anything similar in other GCC
> > > targets I looked at.
> > 
> > That I don't know.  FBSD_NO_THREADS is defined in freebsd-nthr.h.
> > In fact, it's the only thing in that header (except copyright
> > broilerplate).  freebsd-nthr.h only appears in config.gcc and
> > seems to only get added to the build if someone runs configure
> > with --enable-threads=no.  Looking at my last config.log for
> > gcc trunk, I see "Thread model: posix", which appears to be
> > the default case or if someone does --enable-threads=yes or
> > --enable-threads=posix.  So, I suppose it comes down to
> > two questions: (1) is libpthread.* available on all supported
> > targets and versions? (2) does anyone build gcc without
> > threads support?
> 
> libpthread is available on all supported architectures on all
> supported versions.  libthr has been the default threading library
> since 7.0 and the only supported library since 8.0.  In GDB I just
> assume libthr style threads, and I think GCC can safely do the
> same.
> 

I don't know the entire FreeBSD ecosystem.  Do people
use FreeBSD on embedded systems (e.g., nanobsd) where
libthr may be stripped out?  Thus, --enable-threads=no
is needed.

gcc/config/freebsd-nthr.h was committed on May 22, 2001.
There have been no changes to the file other than cosmetic
ones (e.g., updating copyright notice).

gcc/config/freebsd-spec.h has had a number of changes.
Someone with a better understanding of the spec file
will need to clean that up.

-- 
Steve

Re: Profiled libraries on freebsd-current

[John Baldwin]

On 5/2/22 10:37 AM, Steve Kargl wrote:

On Mon, May 02, 2022 at 12:32:25PM -0400, Ed Maste wrote:

On Sun, 1 May 2022 at 11:54, Steve Kargl
 wrote:


diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h
index 594487829b5..1e8ab2e1827 100644
--- a/gcc/config/freebsd-spec.h
+++ b/gcc/config/freebsd-spec.h
@@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 (similar to the default, except no -lg, and no -p).  */

  #ifdef FBSD_NO_THREADS


I wonder if we can simplify things now, and remove this
`FBSD_NO_THREADS` case. I didn't see anything similar in other GCC
targets I looked at.


That I don't know.  FBSD_NO_THREADS is defined in freebsd-nthr.h.
In fact, it's the only thing in that header (except copyright
broilerplate).  freebsd-nthr.h only appears in config.gcc and
seems to only get added to the build if someone runs configure
with --enable-threads=no.  Looking at my last config.log for
gcc trunk, I see "Thread model: posix", which appears to be
the default case or if someone does --enable-threads=yes or
--enable-threads=posix.  So, I suppose it comes down to
two questions: (1) is libpthread.* available on all supported
targets and versions? (2) does anyone build gcc without
threads support?


libpthread is available on all supported architectures on all
supported versions.  libthr has been the default threading library
since 7.0 and the only supported library since 8.0.  In GDB I just
assume libthr style threads, and I think GCC can safely do the
same.

--
John Baldwin

Re: Profiled libraries on freebsd-current

[Steve Kargl]

On Mon, May 02, 2022 at 10:37:00AM -0700, Steve Kargl wrote:
> On Mon, May 02, 2022 at 12:32:25PM -0400, Ed Maste wrote:
> > On Sun, 1 May 2022 at 11:54, Steve Kargl
> >  wrote:
> > >
> > > diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h
> > > index 594487829b5..1e8ab2e1827 100644
> > > --- a/gcc/config/freebsd-spec.h
> > > +++ b/gcc/config/freebsd-spec.h
> > > @@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME 
> > > respectively.  If not, see
> > > (similar to the default, except no -lg, and no -p).  */
> > >
> > >  #ifdef FBSD_NO_THREADS
> > 
> > I wonder if we can simplify things now, and remove this
> > `FBSD_NO_THREADS` case. I didn't see anything similar in other GCC
> > targets I looked at.
> 
> That I don't know.  FBSD_NO_THREADS is defined in freebsd-nthr.h.
> In fact, it's the only thing in that header (except copyright
> broilerplate).  freebsd-nthr.h only appears in config.gcc and
> seems to only get added to the build if someone runs configure
> with --enable-threads=no.  Looking at my last config.log for
> gcc trunk, I see "Thread model: posix", which appears to be
> the default case or if someone does --enable-threads=yes or
> --enable-threads=posix.  So, I suppose it comes down to 
> two questions: (1) is libpthread.* available on all supported
> targets and versions? (2) does anyone build gcc without 
> threads support?
> 

Well, I built and executed gcc testsuite with and without
threads enabled.  Either a few new test failures in the
disable case may unilaterally assume threads are available,
or these are in fact issues (with a rarely used configure
option).



config 1
../gccx/configure --prefix=$HOME/work/x --enable-languages=c,c++,fortran,lto \
  --enable-bootstrap --disable-nls --enable-checking --disable-multilib

config 2
../gccx/configure --prefix=$HOME/work/x --enable-languages=c,c++,fortran,lto \
  --enable-bootstrap --disable-nls --enable-checking --disable-multilib \
  --enable-threads=no --disable-threads

=== g++ Summary ===

config 1  config 2
# of expected passes225442 225348
# of unexpected failures675724
# of expected failures  2071   2071
# of unresolved testcases   11 47
# of unsupported tests  10342  10342

=== gcc Summary ===

# of expected passes175562 175401
# of unexpected failures1046   1116
# of unexpected successes   20 20
# of expected failures  1459   1459
# of unresolved testcases   10 92
# of unsupported tests  3260   3260

=== gfortran Summary ===

# of expected passes66124  66046
# of unexpected failures6  84
# of expected failures  272272
# of unresolved testcases   2  2
# of unsupported tests  100100

-- 
Steve

Re: Profiled libraries on freebsd-current

[Steve Kargl]

On Mon, May 02, 2022 at 12:32:25PM -0400, Ed Maste wrote:
> On Sun, 1 May 2022 at 11:54, Steve Kargl
>  wrote:
> >
> > diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h
> > index 594487829b5..1e8ab2e1827 100644
> > --- a/gcc/config/freebsd-spec.h
> > +++ b/gcc/config/freebsd-spec.h
> > @@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME 
> > respectively.  If not, see
> > (similar to the default, except no -lg, and no -p).  */
> >
> >  #ifdef FBSD_NO_THREADS
> 
> I wonder if we can simplify things now, and remove this
> `FBSD_NO_THREADS` case. I didn't see anything similar in other GCC
> targets I looked at.

That I don't know.  FBSD_NO_THREADS is defined in freebsd-nthr.h.
In fact, it's the only thing in that header (except copyright
broilerplate).  freebsd-nthr.h only appears in config.gcc and
seems to only get added to the build if someone runs configure
with --enable-threads=no.  Looking at my last config.log for
gcc trunk, I see "Thread model: posix", which appears to be
the default case or if someone does --enable-threads=yes or
--enable-threads=posix.  So, I suppose it comes down to 
two questions: (1) is libpthread.* available on all supported
targets and versions? (2) does anyone build gcc without 
threads support?

-- 
Steve

Re: Profiled libraries on freebsd-current

[Ed Maste]

On Sun, 1 May 2022 at 11:54, Steve Kargl
 wrote:
>
> diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h
> index 594487829b5..1e8ab2e1827 100644
> --- a/gcc/config/freebsd-spec.h
> +++ b/gcc/config/freebsd-spec.h
> @@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
> If not, see
> (similar to the default, except no -lg, and no -p).  */
>
>  #ifdef FBSD_NO_THREADS

I wonder if we can simplify things now, and remove this
`FBSD_NO_THREADS` case. I didn't see anything similar in other GCC
targets I looked at.

Re: Profiled libraries on freebsd-current

[Steve Kargl]

On Sat, Apr 30, 2022 at 04:07:48PM -0400, Ed Maste wrote:
> On Sat, 30 Apr 2022 at 11:34, Steve Kargl
>  wrote:
> >
> > On Sat, Apr 30, 2022 at 09:39:32AM -0400, Ed Maste wrote:
> > > On Fri, 29 Apr 2022 at 01:58, Steve Kargl
> > >  wrote:
> > > >
> > > > If one looks at src.conf(5), one finds
> > > >
> > > >WITH_PROFILE
> > > >  Build profiled libraries for use with gprof(8).  This option is
> > > >  deprecated and is not present in FreeBSD 14.
> > > >
> > > > I assume that the *_p.a libraries will no longer be built and
> > > > installed on FreeBSD 14 and later.  Is this correct?
> > >
> > > FreeBSD 14 is not yet released, of course, but that is indeed the
> > > intent. PR256874 reports that a GCC patch (to stop linking against
> > > _p.a) is in the works but unfortunately has not had an update for some
> > > time.
> >
> > I see.  It only took me 2+ years to get
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125
> >
> > committed to the GCC repository.  Good luck with
> > getting your patch upstream.
> 
> Heh, thanks.
> 
> I have just now changed the WITH_PROFILE description to state "a
> future version of FreeBSD" since it may well not happen for FreeBSD
> 14.
> 
> We could also just install libc_p.a as a symlink to libc.a (and same
> for the other _p.a archives).

This works for me, but there is one addition place dealing with -pg
in freebsd-spec.h


diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h
index 594487829b5..1e8ab2e1827 100644
--- a/gcc/config/freebsd-spec.h
+++ b/gcc/config/freebsd-spec.h
@@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
(similar to the default, except no -lg, and no -p).  */
 
 #ifdef FBSD_NO_THREADS
+#if FBSD_MAJOR < 14
 #define FBSD_LIB_SPEC "
\
-  %{pthread: %eThe -pthread option is only supported on FreeBSD when gcc \
+ %{pthread: %eThe -pthread option is only supported on FreeBSD when gcc \
 is built with the --enable-threads configure-time option.} \
   %{!shared:   \
 %{!pg: -lc}
\
 %{pg:  -lc_p}  \
   }"
 #else
+#define FBSD_LIB_SPEC "
\
+ %{pthread: %eThe -pthread option is only supported on FreeBSD when gcc \
+is built with the --enable-threads configure-time option.} \
+  }"
+#endif
+#else
+#if FBSD_MAJOR < 14
 #define FBSD_LIB_SPEC "
\
   %{!shared:   \
 %{!pg: %{pthread:-lpthread} -lc}   \
@@ -109,6 +117,15 @@ is built with the --enable-threads configure-time option.} 
\
   %{shared:\
 %{pthread:-lpthread} -lc   \
   }"
+#else
+#define FBSD_LIB_SPEC "
\
+  %{!shared:   \
+%{pthread:-lpthread} -lc   \
+  }\
+  %{shared:\
+%{pthread:-lpthread} -lc   \
+  }"
+#endif
 #endif
 
 /* To make matters interesting, we can't actually use __FreeBSD_version
-- 
Steve

Re: Profiled libraries on freebsd-current

[Ed Maste]

On Sat, 30 Apr 2022 at 11:34, Steve Kargl
 wrote:
>
> On Sat, Apr 30, 2022 at 09:39:32AM -0400, Ed Maste wrote:
> > On Fri, 29 Apr 2022 at 01:58, Steve Kargl
> >  wrote:
> > >
> > > If one looks at src.conf(5), one finds
> > >
> > >WITH_PROFILE
> > >  Build profiled libraries for use with gprof(8).  This option is
> > >  deprecated and is not present in FreeBSD 14.
> > >
> > > I assume that the *_p.a libraries will no longer be built and
> > > installed on FreeBSD 14 and later.  Is this correct?
> >
> > FreeBSD 14 is not yet released, of course, but that is indeed the
> > intent. PR256874 reports that a GCC patch (to stop linking against
> > _p.a) is in the works but unfortunately has not had an update for some
> > time.
>
> I see.  It only took me 2+ years to get
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125
>
> committed to the GCC repository.  Good luck with
> getting your patch upstream.

Heh, thanks.

I have just now changed the WITH_PROFILE description to state "a
future version of FreeBSD" since it may well not happen for FreeBSD
14.

We could also just install libc_p.a as a symlink to libc.a (and same
for the other _p.a archives).

Re: Profiled libraries on freebsd-current

[Steve Kargl]

On Sat, Apr 30, 2022 at 09:39:32AM -0400, Ed Maste wrote:
> On Fri, 29 Apr 2022 at 01:58, Steve Kargl
>  wrote:
> >
> > If one looks at src.conf(5), one finds
> >
> >WITH_PROFILE
> >  Build profiled libraries for use with gprof(8).  This option is
> >  deprecated and is not present in FreeBSD 14.
> >
> > I assume that the *_p.a libraries will no longer be built and
> > installed on FreeBSD 14 and later.  Is this correct?
> 
> FreeBSD 14 is not yet released, of course, but that is indeed the
> intent. PR256874 reports that a GCC patch (to stop linking against
> _p.a) is in the works but unfortunately has not had an update for some
> time.

I see.  It only took me 2+ years to get

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125

committed to the GCC repository.  Good luck with
getting your patch upstream.

-- 
Steve

Re: Profiled libraries on freebsd-current

[Ed Maste]

On Fri, 29 Apr 2022 at 01:58, Steve Kargl
 wrote:
>
> If one looks at src.conf(5), one finds
>
>WITH_PROFILE
>  Build profiled libraries for use with gprof(8).  This option is
>  deprecated and is not present in FreeBSD 14.
>
> I assume that the *_p.a libraries will no longer be built and
> installed on FreeBSD 14 and later.  Is this correct?

FreeBSD 14 is not yet released, of course, but that is indeed the
intent. PR256874 reports that a GCC patch (to stop linking against
_p.a) is in the works but unfortunately has not had an update for some
time.

Re: Profiled libraries on freebsd-current

[Steve Kargl]

On Fri, Apr 29, 2022 at 02:54:17PM -0700, Mark Millard wrote:
> On 2022-Apr-29, at 13:12, Steve Kargl  
> wrote:
> 
> > The evenual absence of libc_p.a and libm_p.a will break GCC's
> > -pg option in GCC.  One will then need to know how to change the
> > GCC source or install symlinks for to point *_p.a a the *.a libs.
> > 
> 
> src/tree/tools/build/mk/OptionalObsoleteFiles.inc shows the
> following that does include those 2 files as ones considered
> obsolete (i.e., to be removed) by WITHOUT_PROFILE:
> 

(snip)

> 
> I expect that this is part of the mechanism that will
> ultimately remove those then-out-of-date files from
> systems when WITH_PROFILE is no longer supported.
> 
> Metion was made of "[a] similar change is still needed
> for GCC" --but I've no clue of the details or status.
> 

Therein lies the problem.  None of the people pushing the
removal of WITH[OUT]_PROFILE have submitted a patch to 
fix GCC.  Anyone installing a lang/gccXXX port will be
met with errors when using -pg.  

-- 
Steve

Re: Profiled libraries on freebsd-current

[Mark Millard]

On 2022-Apr-29, at 13:12, Steve Kargl  wrote:

> On Fri, Apr 29, 2022 at 12:51:12PM -0700, Mark Millard wrote:
>> On 2022-Apr-29, at 12:38, Mark Millard  wrote:
>> 
>>> https://cgit.freebsd.org/src/commit/?id=175841285e289edebb6603da39f02549521ce950
>>> says the following (later), but first I quote the part tbat dirves the
>>> interpretation:
>>> 
>>> QUOTE
>>> Clang's -pg support and mcount() remain, so building with -pg can still
>>> be used on code that the user builds; we just do not provide prebuilt
>>> libraries compiled with -pg.
>>> END QUOTE
>>> 
>>> No WITH_PROFILE options means no "prebuilt libraries compiled with -pg".
>>> 
>>> 
>>> The overall notice was:
>>> 
>>> author  Ed Maste2021-06-27 17:21:26 +
>>> committer   Ed Maste2021-06-28 15:36:59 +
>>> commit  175841285e289edebb6603da39f02549521ce950 (patch)
>>> tree9c2d3b05546961457bb18faeebd2302a25559b49
>>> parent  243b95978debac3db06df6d26ca9f8d84f6cbd83 (diff)
>>> downloadsrc-175841285e289edebb6603da39f02549521ce950.tar.gz
>>> src-175841285e289edebb6603da39f02549521ce950.zip
>>> 
>>> Add deprecation notice for WITH_PROFILE option
>>> 
>>> As discussed on freebsd-current [1] and freebsd-arch [2] and review
>>> D30833, FreeBSD 14 will ship without the _p.a libraries built with -pg.
>>> Both upstream and base system (in commit b762974cf4b9) Clang have been
>>> modified to remove the special case for linking against these libraries.
>>> 
>>> Clang's -pg support and mcount() remain, so building with -pg can still
>>> be used on code that the user builds; we just do not provide prebuilt
>>> libraries compiled with -pg.  A similar change is still needed for GCC.
>>> 
>>> [1]  
>>> https://lists.freebsd.org/pipermail/freebsd-current/2020-January/075105.html
>>> 
>>> [2] 
>>> https://lists.freebsd.org/archives/freebsd-arch/2021-June/16.html
>>> 
>>> 
>>> MFC after:  1 week
>>> Sponsored by:   The FreeBSD Foundation
>>> END QUOTE
>>> 
>> 
>> I probably should have been explicit: the actual removal of WITH_PROFILE
>> has not happened yet. So testing attempts to use it are not yet expected
>> to have the new behavior yet.
>> 
> 
> The evenual absence of libc_p.a and libm_p.a will break GCC's
> -pg option in GCC.  One will then need to know how to change the
> GCC source or install symlinks for to point *_p.a a the *.a libs.
> 

src/tree/tools/build/mk/OptionalObsoleteFiles.inc shows the
following that does include those 2 files as ones considered
obsolete (i.e., to be removed) by WITHOUT_PROFILE:

.if ${MK_PROFILE} == no
OLD_FILES+=usr/lib/lib80211_p.a
OLD_FILES+=usr/lib/lib9p_p.a
OLD_FILES+=usr/lib/libBlocksRuntime_p.a
OLD_FILES+=usr/lib/libalias_dummy_p.a
OLD_FILES+=usr/lib/libalias_ftp_p.a
OLD_FILES+=usr/lib/libalias_irc_p.a
OLD_FILES+=usr/lib/libalias_nbt_p.a
OLD_FILES+=usr/lib/libalias_p.a
OLD_FILES+=usr/lib/libalias_pptp_p.a
OLD_FILES+=usr/lib/libalias_skinny_p.a
OLD_FILES+=usr/lib/libalias_smedia_p.a
OLD_FILES+=usr/lib/libarchive_p.a
OLD_FILES+=usr/lib/libasn1_p.a
OLD_FILES+=usr/lib/libauditd_p.a
OLD_FILES+=usr/lib/libavl_p.a
OLD_FILES+=usr/lib/libbe_p.a
OLD_FILES+=usr/lib/libbegemot_p.a
OLD_FILES+=usr/lib/libblacklist_p.a
OLD_FILES+=usr/lib/libbluetooth_p.a
OLD_FILES+=usr/lib/libbsdxml_p.a
OLD_FILES+=usr/lib/libbsm_p.a
OLD_FILES+=usr/lib/libbsnmp_p.a
OLD_FILES+=usr/lib/libbz2_p.a
OLD_FILES+=usr/lib/libc++_p.a
OLD_FILES+=usr/lib/libc_p.a
OLD_FILES+=usr/lib/libcalendar_p.a
OLD_FILES+=usr/lib/libcam_p.a
OLD_FILES+=usr/lib/libcom_err_p.a
OLD_FILES+=usr/lib/libcompat_p.a
OLD_FILES+=usr/lib/libcompiler_rt_p.a
OLD_FILES+=usr/lib/libcrypt_p.a
OLD_FILES+=usr/lib/libcrypto_p.a
OLD_FILES+=usr/lib/libctf_p.a
OLD_FILES+=usr/lib/libcurses_p.a
OLD_FILES+=usr/lib/libcursesw_p.a
OLD_FILES+=usr/lib/libcuse_p.a
OLD_FILES+=usr/lib/libcxxrt_p.a
OLD_FILES+=usr/lib/libdevctl_p.a
OLD_FILES+=usr/lib/libdevinfo_p.a
OLD_FILES+=usr/lib/libdevstat_p.a
OLD_FILES+=usr/lib/libdialog_p.a
OLD_FILES+=usr/lib/libdl_p.a
OLD_FILES+=usr/lib/libdpv_p.a
OLD_FILES+=usr/lib/libdtrace_p.a
OLD_FILES+=usr/lib/libdwarf_p.a
OLD_FILES+=usr/lib/libedit_p.a
OLD_FILES+=usr/lib/libefivar_p.a
OLD_FILES+=usr/lib/libelf_p.a
OLD_FILES+=usr/lib/libexecinfo_p.a
OLD_FILES+=usr/lib/libfetch_p.a
OLD_FILES+=usr/lib/libfigpar_p.a
OLD_FILES+=usr/lib/libfl_p.a
OLD_FILES+=usr/lib/libform_p.a
OLD_FILES+=usr/lib/libformw_p.a
OLD_FILES+=usr/lib/libgcc_eh_p.a
OLD_FILES+=usr/lib/libgcc_p.a
OLD_FILES+=usr/lib/libgeom_p.a
OLD_FILES+=usr/lib/libgpio_p.a
OLD_FILES+=usr/lib/libgssapi_krb5_p.

Re: Profiled libraries on freebsd-current

[Steve Kargl]

On Fri, Apr 29, 2022 at 12:51:12PM -0700, Mark Millard wrote:
> On 2022-Apr-29, at 12:38, Mark Millard  wrote:
> 
> > https://cgit.freebsd.org/src/commit/?id=175841285e289edebb6603da39f02549521ce950
> > says the following (later), but first I quote the part tbat dirves the
> > interpretation:
> > 
> > QUOTE
> > Clang's -pg support and mcount() remain, so building with -pg can still
> > be used on code that the user builds; we just do not provide prebuilt
> > libraries compiled with -pg.
> > END QUOTE
> > 
> > No WITH_PROFILE options means no "prebuilt libraries compiled with -pg".
> > 
> > 
> > The overall notice was:
> > 
> > author  Ed Maste2021-06-27 17:21:26 +
> > committer   Ed Maste2021-06-28 15:36:59 +
> > commit  175841285e289edebb6603da39f02549521ce950 (patch)
> > tree9c2d3b05546961457bb18faeebd2302a25559b49
> > parent  243b95978debac3db06df6d26ca9f8d84f6cbd83 (diff)
> > downloadsrc-175841285e289edebb6603da39f02549521ce950.tar.gz
> > src-175841285e289edebb6603da39f02549521ce950.zip
> > 
> > Add deprecation notice for WITH_PROFILE option
> > 
> > As discussed on freebsd-current [1] and freebsd-arch [2] and review
> > D30833, FreeBSD 14 will ship without the _p.a libraries built with -pg.
> > Both upstream and base system (in commit b762974cf4b9) Clang have been
> > modified to remove the special case for linking against these libraries.
> > 
> > Clang's -pg support and mcount() remain, so building with -pg can still
> > be used on code that the user builds; we just do not provide prebuilt
> > libraries compiled with -pg.  A similar change is still needed for GCC.
> > 
> > [1]  
> > https://lists.freebsd.org/pipermail/freebsd-current/2020-January/075105.html
> > 
> > [2] 
> > https://lists.freebsd.org/archives/freebsd-arch/2021-June/16.html
> > 
> > 
> > MFC after:  1 week
> > Sponsored by:   The FreeBSD Foundation
> > END QUOTE
> > 
> 
> I probably should have been explicit: the actual removal of WITH_PROFILE
> has not happened yet. So testing attempts to use it are not yet expected
> to have the new behavior yet.
> 

The evenual absence of libc_p.a and libm_p.a will break GCC's
-pg option in GCC.  One will then need to know how to change the
GCC source or install symlinks for to point *_p.a a the *.a libs.

-- 
Steve

Re: Profiled libraries on freebsd-current

[Mark Millard]

On 2022-Apr-29, at 12:38, Mark Millard  wrote:

> https://cgit.freebsd.org/src/commit/?id=175841285e289edebb6603da39f02549521ce950
> says the following (later), but first I quote the part tbat dirves the
> interpretation:
> 
> QUOTE
> Clang's -pg support and mcount() remain, so building with -pg can still
> be used on code that the user builds; we just do not provide prebuilt
> libraries compiled with -pg.
> END QUOTE
> 
> No WITH_PROFILE options means no "prebuilt libraries compiled with -pg".
> 
> 
> The overall notice was:
> 
> authorEd Maste2021-06-27 17:21:26 +
> committer Ed Maste2021-06-28 15:36:59 +
> commit175841285e289edebb6603da39f02549521ce950 (patch)
> tree  9c2d3b05546961457bb18faeebd2302a25559b49
> parent243b95978debac3db06df6d26ca9f8d84f6cbd83 (diff)
> download  src-175841285e289edebb6603da39f02549521ce950.tar.gz
> src-175841285e289edebb6603da39f02549521ce950.zip
> 
> Add deprecation notice for WITH_PROFILE option
> 
> As discussed on freebsd-current [1] and freebsd-arch [2] and review
> D30833, FreeBSD 14 will ship without the _p.a libraries built with -pg.
> Both upstream and base system (in commit b762974cf4b9) Clang have been
> modified to remove the special case for linking against these libraries.
> 
> Clang's -pg support and mcount() remain, so building with -pg can still
> be used on code that the user builds; we just do not provide prebuilt
> libraries compiled with -pg.  A similar change is still needed for GCC.
> 
> [1]  
> https://lists.freebsd.org/pipermail/freebsd-current/2020-January/075105.html
> 
> [2] 
> https://lists.freebsd.org/archives/freebsd-arch/2021-June/16.html
> 
> 
> MFC after:1 week
> Sponsored by: The FreeBSD Foundation
> END QUOTE
> 

I probably should have been explicit: the actual removal of WITH_PROFILE
has not happened yet. So testing attempts to use it are not yet expected
to have the new behavior yet.


===
Mark Millard
marklmi at yahoo.com

Re: Profiled libraries on freebsd-current

[Mark Millard]

https://cgit.freebsd.org/src/commit/?id=175841285e289edebb6603da39f02549521ce950
says the following (later), but first I quote the part tbat dirves the
interpretation:

QUOTE
Clang's -pg support and mcount() remain, so building with -pg can still
be used on code that the user builds; we just do not provide prebuilt
libraries compiled with -pg.
END QUOTE

No WITH_PROFILE options means no "prebuilt libraries compiled with -pg".


The overall notice was:

author  Ed Maste2021-06-27 17:21:26 +
committer   Ed Maste2021-06-28 15:36:59 +
commit  175841285e289edebb6603da39f02549521ce950 (patch)
tree9c2d3b05546961457bb18faeebd2302a25559b49
parent  243b95978debac3db06df6d26ca9f8d84f6cbd83 (diff)
downloadsrc-175841285e289edebb6603da39f02549521ce950.tar.gz
src-175841285e289edebb6603da39f02549521ce950.zip

Add deprecation notice for WITH_PROFILE option

As discussed on freebsd-current [1] and freebsd-arch [2] and review
D30833, FreeBSD 14 will ship without the _p.a libraries built with -pg.
Both upstream and base system (in commit b762974cf4b9) Clang have been
modified to remove the special case for linking against these libraries.

Clang's -pg support and mcount() remain, so building with -pg can still
be used on code that the user builds; we just do not provide prebuilt
libraries compiled with -pg.  A similar change is still needed for GCC.

[1]  
https://lists.freebsd.org/pipermail/freebsd-current/2020-January/075105.html

[2] 
https://lists.freebsd.org/archives/freebsd-arch/2021-June/16.html


MFC after:  1 week
Sponsored by:   The FreeBSD Foundation
END QUOTE



===
Mark Millard
marklmi at yahoo.com

Re: Profiled libraries on freebsd-current

[Steve Kargl]

On Thu, Apr 28, 2022 at 10:56:48PM -0700, Steve Kargl wrote:
> If one looks at src.conf(5), one finds
> 
>WITH_PROFILE
>  Build profiled libraries for use with gprof(8).  This option is
>  deprecated and is not present in FreeBSD 14.
> 
> I assume that the *_p.a libraries will no longer be built and
> installed on FreeBSD 14 and later.  Is this correct?
> 

Empirical evidence suggests that src.conf(5) manpage is
incorrect.  Adding WITH_PROFILE to /etc/src.conf, 

cd msun
cd make clean && make
ls /usr/obj/usr/src/amd64.amd64/lib/msun/libm*
/usr/obj/usr/src/amd64.amd64/lib/msun/libm.a
/usr/obj/usr/src/amd64.amd64/lib/msun/libm.so@
/usr/obj/usr/src/amd64.amd64/lib/msun/libm.so.5*
/usr/obj/usr/src/amd64.amd64/lib/msun/libm_p.a

so libm_p.a is built.  I haven't tried to install it.

git blame share/man/man5/src.conf.5
...
f94360971e64 (Ed Maste 2021-06-28 17:30:48 -0400 1392)
f94360971e64 (Ed Maste  2021-06-28 17:30:48 -0400 1393)

git log -r f94360971e64
commit f94360971e649fa684ef3b7e72839b59c7242bdb
Author: Ed Maste 
Date:   Mon Jun 28 17:30:48 2021 -0400

Clarify notice for profiled libraries in FreeBSD 14

Well, that certainly clarifies the situation.

Could someone please fix src.conf(5)?

-- 
Steve

Profiled libraries on freebsd-current

[Steve Kargl]

If one looks at src.conf(5), one finds

   WITH_PROFILE
 Build profiled libraries for use with gprof(8).  This option is
 deprecated and is not present in FreeBSD 14.

I assume that the *_p.a libraries will no longer be built and
installed on FreeBSD 14 and later.  Is this correct?

-- 
Steve

Verify Your Account freebsd-current@freebsd.org

[freebsd . org]

 
Server Administrator | IT Support freebsd.org   
Hello freebsd-current@freebsd.org

We are closing all old versions users from 8/18/2021 11:34:43 p.m.. Please confirm your email address freebsd-current@freebsd.org to keep your account from being deactivated.


Confirm Your Email Here
  
Account will be  automatically deleted after 8/18/2021 11:34:43 p.m. You can change the frequency of these notifications within your mailbox portal.

Re: Fwd: Information for freebsd-current@FreeBSD.org

[Baptiste Daroussin]

On Thu, Jul 29, 2021 at 05:39:04PM +0200, Matthias Apitz wrote:
> 
> Is this a phishing attack or did I missed some change in the FBSD
> mailing lists?
> 

This is not phishing attack this is the result of someone requesting help using
freebsd-current@f.o in the from and somehow not catched by our antispam.

Anyway those kind of request are now blocked.

As for the change in FBSD mailing list, it happened for most of the a couple of
month ago. Some are still in migration (the moderated one)

Best regards,
Bapt

Re: Fwd: Information for freebsd-current@FreeBSD.org

[Steve Kargl]

The mailing lists are migrating from mailman to Mlmmj.  I
suspect, but haven't verified, that this is the new norm
for the monthly notice about mailing list subscriptions.

I would suggesting reading the mailing list archives,
but needs to guess where the relevent discussion might
be found.  If you got here:

https://www.freebsd.org/community/mailinglists/

You'll find

   You can *search* or *browse* the mailing list archives.
   At the current time, archives prior to May 2021 are *in
   a separate archive.*

where *search*, *browse* and *in a separate archive.* are
hyperlinks.  This is quite misleading as at least

dev-commits-doc-all/-   2021-Jul-02 03:27
dev-commits-ports-all/  -   2021-Jul-01 03:27
dev-commits-ports-branches/ -   2021-Jul-04 03:27
dev-commits-ports-main/ -   2021-Jul-01 03:27
dev-commits-src-all/-   2021-Jul-02 03:27
dev-commits-src-branches/   -   2021-Jul-03 03:27
dev-commits-src-main-   2021-Jul-03 03:27

are under *in a separate archive*, which clearly shows
messages newer than the May 2021 date are not archived
under *browse*.  There are a few other archives that 
violate the statement on the FreeBSD.org.


-- 
steve

On Thu, Jul 29, 2021 at 05:39:04PM +0200, Matthias Apitz wrote:
> 
> Is this a phishing attack or did I missed some change in the FBSD
> mailing lists?
> 
>   matthias
> 
> - Forwarded message from freebsd-current+ow...@freebsd.org -
> 
> Date: Thu, 29 Jul 2021 15:00:41 +
> From: freebsd-current+ow...@freebsd.org
> To: freebsd-current@FreeBSD.org
> Subject: Information for freebsd-current@FreeBSD.org
> 
> Hi, this is the Mlmmj program managing the 
> mailing list.
> 
> Here is some information about the list.
> 
> You can subscribe to the following versions:
> 
> - The normal version: Every time a post is sent to the list, subscribers
>   receive a copy of it. Subscribe by emailing
>   .
> 
> - The digest version: Subscribers receive multiple posts in a single mail
>   message, at regular intervals, or when a lot of posts have accumulated.
>   Subscribe by emailing .
> 
> - The no-mail version: Subscribers do not receive any posts to the list.
>   This means, though, they are able to post to a list which only
>   subscribers may post to, while they follow the list using a web archive
>   or another subscribed email address. Subscribe by emailing
>   .
> 
> Unsubscribe by emailing .
> 
> Posts are made by emailing .
> 
> However, only subscribers may post to the list.
> 
> The list also has access rules which may affect who can post and which
> posts are moderated.
> 
> Subscribers can retrieve message number N from the list's archive by
> sending a message to  (change the N to
> the number of the desired message).
> 
> You can retrieve the frequently asked questions document for the list by
> sending a message to .
> 
> To contact the list owner, send a message to
> .
> 
> 
> 
> - End forwarded message -
> 
> -- 
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub
> Tear it down! Defund the Humboldt Forum!
> https://www.jungewelt.de/artikel/406715.humboldt-forum-feudaler-themenpark.html
> 

-- 
Steve

Fwd: Information for freebsd-current@FreeBSD.org

[Matthias Apitz]

Is this a phishing attack or did I missed some change in the FBSD
mailing lists?

matthias

- Forwarded message from freebsd-current+ow...@freebsd.org -

Date: Thu, 29 Jul 2021 15:00:41 +
From: freebsd-current+ow...@freebsd.org
To: freebsd-current@FreeBSD.org
Subject: Information for freebsd-current@FreeBSD.org

Hi, this is the Mlmmj program managing the 
mailing list.

Here is some information about the list.

You can subscribe to the following versions:

- The normal version: Every time a post is sent to the list, subscribers
  receive a copy of it. Subscribe by emailing
  .

- The digest version: Subscribers receive multiple posts in a single mail
  message, at regular intervals, or when a lot of posts have accumulated.
  Subscribe by emailing .

- The no-mail version: Subscribers do not receive any posts to the list.
  This means, though, they are able to post to a list which only
  subscribers may post to, while they follow the list using a web archive
  or another subscribed email address. Subscribe by emailing
  .

Unsubscribe by emailing .

Posts are made by emailing .

However, only subscribers may post to the list.

The list also has access rules which may affect who can post and which
posts are moderated.

Subscribers can retrieve message number N from the list's archive by
sending a message to  (change the N to
the number of the desired message).

You can retrieve the frequently asked questions document for the list by
sending a message to .

To contact the list owner, send a message to
.



- End forwarded message -

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
Tear it down! Defund the Humboldt Forum!
https://www.jungewelt.de/artikel/406715.humboldt-forum-feudaler-themenpark.html

Information for freebsd-current@FreeBSD.org

[freebsd-current+owner]

Hi, this is the Mlmmj program managing the 
mailing list.

Here is some information about the list.

You can subscribe to the following versions:

- The normal version: Every time a post is sent to the list, subscribers
  receive a copy of it. Subscribe by emailing
  .

- The digest version: Subscribers receive multiple posts in a single mail
  message, at regular intervals, or when a lot of posts have accumulated.
  Subscribe by emailing .

- The no-mail version: Subscribers do not receive any posts to the list.
  This means, though, they are able to post to a list which only
  subscribers may post to, while they follow the list using a web archive
  or another subscribed email address. Subscribe by emailing
  .

Unsubscribe by emailing .

Posts are made by emailing .

However, only subscribers may post to the list.

The list also has access rules which may affect who can post and which
posts are moderated.

Subscribers can retrieve message number N from the list's archive by
sending a message to  (change the N to
the number of the desired message).

You can retrieve the frequently asked questions document for the list by
sending a message to .

To contact the list owner, send a message to
.

Re: Updating to FreeBSD-current, can't mount -uw / : update: seemingly solved

[Thomas Mueller]

> In both cases, the entry is INcorrect. Juraj is correct. The swap entry is
> missing sw
> IOW the line MUST read as:

> /dev/gpt/Sea1-18noneswapsw  0   0

> or

> /dev/gpt/Sea1-18noneswapsw,trimonce 0   0

> as appropriate for the media referenced.

>-Chris

As my last message stated, I found the missing field in /etc/fstab and 
corrected it.

Then "mount -u /" worked smoothly.

Perhaps one field too few makes the system look to the next line, so the whole 
/etc/fstab is misinterpreted.

I also pointed out that, from previous messages on this list, that etcupdate 
was replacing mergemaster.

But UPDATING at the top of the src tree still specifies mergemaster, so that 
would need to be updated.

There needs to be better documentation on the newer etcupdate.

Parameters for etcupdate are somewhat different in FreeBSD than in NetBSD, so 
the documentation needs to be updated.

I don't want to mess up by doing the wrong thing in NetBSD or FreeBSD.

Tom

Re: Updating to FreeBSD-current, can't mount -uw / : update: seemingly solved

[Chris]

On 2021-06-06 23:49, Graham Perrin wrote:

On 07/06/2021 07:10, Juraj Lutter wrote:

Bacause swap entry is in inapropriate format.

The line should read:

/dev/gpt/Sea1-18noneswapsw  0   0


Very well spotted, Juraj, but maybe a typo in your correction.

A clearer view of the original  where the device 
given to swap is:


/dev/gpt/Sea1-08

In both cases, the entry is INcorrect. Juraj is correct. The swap entry is
missing sw
IOW the line MUST read as:

/dev/gpt/Sea1-18noneswapsw  0   0

or

/dev/gpt/Sea1-18noneswapsw,trimonce 0   0

as appropriate for the media referenced.

--Chris

Re: Updating to FreeBSD-current, can't mount -uw / : update: seemingly solved

[Graham Perrin]

On 07/06/2021 07:10, Juraj Lutter wrote:

Bacause swap entry is in inapropriate format.

The line should read:

/dev/gpt/Sea1-18noneswapsw  0   0


Very well spotted, Juraj, but maybe a typo in your correction.

A clearer view of the original  where the 
device given to swap is:


/dev/gpt/Sea1-08

Re: Updating to FreeBSD-current, can't mount -uw / : update: seemingly solved

[Juraj Lutter]

> On 7 Jun 2021, at 02:15, Thomas Mueller  wrote:
> 
> I updated a FreeBSD-current to the newest FreeBSD-current/14, buildworld took 
> 11:15 (hours:minutes), buildkernel was also successful, I even appeared to be 
> successful with "dhclient re0".
> 
> UPDATING file says to boot single-user after buildkernel and installkernel, 
> but then mount -u / or mount -uw / does not work as it did in previous times.
> 
> Results were
> 
> mount -uw / or mount -u / produces 
> fstab: /etc/fstab:2: Inappropriate file type or format
> fstab: /etc/fstab:2: Inappropriate file type or format

Bacause swap entry is in inapropriate format.

The line should read:

/dev/gpt/Sea1-18noneswapsw  0   0

otis

—
Juraj Lutter
o...@freebsd.org

Re: Updating to FreeBSD-current, can't mount -uw /

[Warner Losh]

On Sun, Jun 6, 2021 at 5:24 AM Thomas Mueller  wrote:

> I updated a FreeBSD-current to the newest FreeBSD-current/14, buildworld
> took 11:15 (hours:minutes), buildkernel was also successful, I even
> appeared to be successful with "dhclient re0".
>
> UPDATING file says to boot single-user after buildkernel and
> installkernel, but then mount -u / or mount -uw / does not work as it did
> in previous times.
>
> Results were
>
> mount -uw / or mount -u / produces
> fstab: /etc/fstab:2: Inappropriate file type or format
> fstab: /etc/fstab:2: Inappropriate file type or format
>
> /etc/fstab
> # DeviceMountpoint  FStype  Options DumpPass#
> /dev/gpt/Sea1-08  none swap 0   0
> /dev/gpt/Sea1-18  / ufs rw  1   1
> #/dev/gpt/Sea1-06 /home   ufs  rw 1  1
>
> fsck -p produces
>
> fstab: /etc/fstab:2: Inappropriate file type or format
> /dev/gpt/Sea1-18: NO WRITE ACCESS
> /dev/gpt/Sea1-18: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
>
> I tried fsck /dev/gpt/Sea1-18 and fsck / but did no better.
>
> Now what do I do?  I also ran fsck_ffs instead of just fsck.
>
> Do I need to boot NetBSD and run fsck_ffs or fsck_ffs -f from there?
>

fsck /dev/gpt/Seae1-18

doesn't work? You can also fsck on the underlying disk, but since there's
many choices
that are hard to know w/o a dmesg.

Warner

Updating to FreeBSD-current, can't mount -uw / : update: seemingly solved

[Thomas Mueller]

I updated a FreeBSD-current to the newest FreeBSD-current/14, buildworld took 
11:15 (hours:minutes), buildkernel was also successful, I even appeared to be 
successful with "dhclient re0".

UPDATING file says to boot single-user after buildkernel and installkernel, but 
then mount -u / or mount -uw / does not work as it did in previous times.

Results were

mount -uw / or mount -u / produces 
fstab: /etc/fstab:2: Inappropriate file type or format
fstab: /etc/fstab:2: Inappropriate file type or format

/etc/fstab
# DeviceMountpoint  FStype  Options DumpPass#
/dev/gpt/Sea1-08  none swap 0   0
/dev/gpt/Sea1-18  / ufs rw  1   1
#/dev/gpt/Sea1-06 /home   ufs  rw 1  1

fsck -p produces

fstab: /etc/fstab:2: Inappropriate file type or format
/dev/gpt/Sea1-18: NO WRITE ACCESS
/dev/gpt/Sea1-18: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

I tried fsck /dev/gpt/Sea1-18 and fsck / but did no better.

Now what do I do?  I also ran fsck_ffs instead of just fsck.

Do I need to boot NetBSD and run fsck_ffs or fsck_ffs -f from there?

Now I seem to have solved the problem.  Either rebooting or fixing /etc/fstab 
did it.

I may have had one too few fields on the /dev/gpt/Sea1-08 line, maybe that 
caused the system to misinterpret the next line.

I added sw between swap and 0, thus the corrected fstab is

# DeviceMountpoint  FStype  Options DumpPass#
/dev/gpt/Sea1-08  none swap sw  0   0
/dev/gpt/Sea1-18  / ufs rw  1   1
#/dev/gpt/Sea1-06 /home   ufs  rw 1  1

Now I see from the emailing lists that etcupdate is replacing mergemaster, but 
UPDATING file still says to use mergemaster without mentioning etcupdate.

Developers, please update!

There are differences between NetBSD's etcupdate and FreeBSD's etcupdate.  I 
don't want to do the wrong thing in FreeBSD. 

Tom

Updating to FreeBSD-current, can't mount -uw /

[Thomas Mueller]

I updated a FreeBSD-current to the newest FreeBSD-current/14, buildworld took 
11:15 (hours:minutes), buildkernel was also successful, I even appeared to be 
successful with "dhclient re0".

UPDATING file says to boot single-user after buildkernel and installkernel, but 
then mount -u / or mount -uw / does not work as it did in previous times.

Results were

mount -uw / or mount -u / produces 
fstab: /etc/fstab:2: Inappropriate file type or format
fstab: /etc/fstab:2: Inappropriate file type or format

/etc/fstab
# DeviceMountpoint  FStype  Options DumpPass#
/dev/gpt/Sea1-08  none swap 0   0
/dev/gpt/Sea1-18  / ufs rw  1   1
#/dev/gpt/Sea1-06 /home   ufs  rw 1  1

fsck -p produces

fstab: /etc/fstab:2: Inappropriate file type or format
/dev/gpt/Sea1-18: NO WRITE ACCESS
/dev/gpt/Sea1-18: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

I tried fsck /dev/gpt/Sea1-18 and fsck / but did no better.

Now what do I do?  I also ran fsck_ffs instead of just fsck.

Do I need to boot NetBSD and run fsck_ffs or fsck_ffs -f from there?

Tom

Unable to unsubscribe from freebsd-current@FreeBSD.org

[freebsd-current+help]

Hi, this is the Mlmmj program managing the 
mailing list.

You were unable to be unsubscribed from the list because you are not
subscribed.

If you are receiving messages, perhaps a different email address is
subscribed. To find out which address you are subscribed with, refer to the
message welcoming you to the list, or look at the envelope "Return-Path"
header of a message you receive from the list.

Network in VNET jail does not work on my FreeBSD current bhyve vm

[mj-mailinglist]

Hello everybody,

since a few weeks, my jails on a bhyve-vm, running current are not reachable 
via network, when configured with VNET. They can't even access the gateway. I 
don't remember when this problem started, but it's a few weeks.
The same jail.conf works on a 13.0 host, on a current system the network does 
not work. A configuration without VNET on the same jail works. Are there any 
changes, that i missed? Here is the configuration, maybe someone spots an 
error, or has an idea what's going on:

--
Martin

uname on bhyve vm:
--
root@fbsd14:~ # uname -a
FreeBSD fbsd14.fritz.box 14.0-CURRENT FreeBSD 14.0-CURRENT 
main-n247020-e0fa04e257c GENERIC-NODEBUG  amd64

root@fbsd14:~ # freebsd-version -kru
14.0-CURRENT
14.0-CURRENT
14.0-CURRENT


jail.conf on bhyve vm:
--
# set default configuration values
mount.devfs = true;
exec.clean = true;

allow.chflags = 1;
allow.raw_sockets = 1;

devfs_ruleset = 5;

exec.system_user  = "root";
exec.jail_user= "root";

exec.timeout = 30;
stop.timeout = 30;

#
# Jails #
#
j1 {
# Hostname
host.hostname   = "j1.fritz.box";
host.domainname = "fritz.box";
host.hostuuid   = "68c2ad9b-b582-11eb-a925-589cfc0ac350";

osrelease = "14.0-CURRENT";
osreldate = "1400013";

# Network
vnet = 1;
vnet.interface = "epair2b";

exec.prestart += "ifconfig epair2 create up";
exec.prestart += "ifconfig epair2a description 'IFID=2 JAIL=j1'";
exec.prestart += "ifconfig bridge0 addm epair2a";

command  = "ifconfig epair2b inet 192.168.1.101/22";
command += "route -n add -inet default 192.168.0.1";

exec.prestop   = "ifconfig epair2b -vnet j1";

exec.poststop += "ifconfig bridge0 deletem epair2a";
exec.poststop += "ifconfig epair2a destroy";

sysvmsg = new;
sysvsem = new;
sysvshm = new;

path = "/jails/j1";
allow.mount.zfs = 1;

## Script execution
exec.timeout = 90;

# Pre-/Post-Scripts
exec.prestart  += "logger trying to start jail j1 ...";
exec.poststart += "logger jail j1 has started";
exec.prestop   += "logger shutting down jail j1";
exec.poststop  += "logger jail j1 has shut down";

# Start Script
exec.start  = "/bin/sh /etc/rc";
exec.stop   = "/bin/sh /etc/rc.shutdown";
}
---



/etc/rc.conf on bhyve vm:
-
syslogd_flags="-ss"
sendmail_enable="NONE"
hostname="fbsd14.fritz.box"
ifconfig_vtnet0="inet 192.168.1.100 netmask 255.255.252.0"
defaultrouter="192.168.0.1"
local_unbound_enable="YES"
sshd_enable="YES"
ntpd_enable="YES"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
zfs_enable="YES"
jail_enable="YES"
keymap="de"

cloned_interfaces="bridge0"
ifconfig_bridge0="addm vtnet0 up"

# NFS
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
nfs_client_enable="YES"
nfsuserd_enable="YES"
-


ifconfig on bhyve vm:
-
root@fbsd14:~ # ifconfig -f inet:cidr
vtnet0: flags=8863 metric 0 mtu 1500
options=80028
ether 58:9c:fc:0a:c3:50
inet 192.168.1.100/22 broadcast 192.168.3.255
media: Ethernet autoselect (10Gbase-T )
status: active
nd6 options=29
lo0: flags=8049 metric 0 mtu 16384
options=680003
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1/8
groups: lo
nd6 options=21
bridge0: flags=8843 metric 0 mtu 1500
ether 58:9c:fc:10:ff:bf
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: epair2a flags=143
ifmaxaddr 0 port 4 priority 128 path cost 2000
groups: bridge
nd6 options=9
epair2a: flags=8943 metric 0 
mtu 1500
description: IFID=2 JAIL=j1
options=8
ether 02:b4:ee:59:b3:0a
groups: epair
media: Ethernet 10Gbase-T (10Gbase-T )
status: active
nd6 options=29
---




/etc/rc.conf in jail:
-
syslogd_flags="-ss"
sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"
sshd_enable="YES"
---


ifconfig in jail:
-
root@j1:~ # ifconfig -f inet:cidr
lo0: flags=8049 metric 0 mtu 16384
options=680003
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1/8
groups: lo
nd6 options=21
epair2b: flags=8843 metric 0 mtu 1500
options=8
ether 02:b4:ee:59:b3:0b
inet 192.168.1.101/22 broadcast 192.168.3.255
groups: epair
media: Ethernet 10Gbase-T (10Gbase-T )
status: active
nd6 options=29


uname in jail:
--
root@j1:

Re: freebsd-current Digest, Vol 904, Issue 5

[Piotr Kubaj via freebsd-current]

Thanks for that work.

Is there any plan to enable PIE for ports by default? On my workstation I've 
been building ports with PIE for some time. Most ports seem to build fine.

Piotr Kubaj.


signature.asc
Description: PGP signature

Re: any images for freebsd-current?

[Steve Kargl]

On Mon, Feb 08, 2021 at 03:03:10AM +, Glen Barber wrote:
> On Sat, Feb 06, 2021 at 11:59:27AM -0800, Steve Kargl wrote:
> > Any one aware of where images from freebsd-current?
> > freebsd.org appears to offer no images.
> > 
> 
> Some juggling needs to be done to the release build machines, which
> I hope to have done this week before the weekly snapshots.
> 

FYI.  I downloaded the 20210218 memstick image for FreeBSD-14
amd64, and re-installed FreeBSD on the problematic laptop.  So
far, the laptop has been rock solid.  Rebuilt 547 ports from 
source.

I suspect that there is vm or ufs or clang/llvm bug(s) that
make running FreeBSD i386 on this laptop a nightmare.  From 
early Jan 2021 until this passed weekend, I was having daily
(sometime multiple) panics.  Panics pointed at issues with
vm (but required drm-kmod to be loaded) and massively scrambled
my SU ufs filesystems.  I also know that clang miscompiles
libm, so by extension it may be miscompiling others parts of
FreeBSD (leading to the panics).  YMMV.

-- 
Steve
___________
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 images for freebsd-current?

[Steve Kargl]

On Mon, Feb 08, 2021 at 03:03:10AM +, Glen Barber wrote:
> On Sat, Feb 06, 2021 at 11:59:27AM -0800, Steve Kargl wrote:
> > Any one aware of where images from freebsd-current?
> > freebsd.org appears to offer no images.
> > 
> 
> Some juggling needs to be done to the release build machines, which
> I hope to have done this week before the weekly snapshots.
> 

Glen (and Warner),

After poking around on freebsd.org, I concluded Release
Engineers were busy with 13.0 and 14.0 would come along.
Fortunately, wo people have sent private emails to images
that they had created.

-- 
Steve
___________
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 images for freebsd-current?

[Glen Barber]

On Sat, Feb 06, 2021 at 11:59:27AM -0800, Steve Kargl wrote:
> Any one aware of where images from freebsd-current?
> freebsd.org appears to offer no images.
> 

Some juggling needs to be done to the release build machines, which
I hope to have done this week before the weekly snapshots.

Glen



signature.asc
Description: PGP signature

Re: any images for freebsd-current?

[Warner Losh]

On Sat, Feb 6, 2021, 3:09 PM Steve Kargl 
wrote:

> On Sat, Feb 06, 2021 at 04:49:46PM -0500, Dennis Clarke via
> freebsd-current wrote:
> > On 2/6/21 4:02 PM, Steve Kargl wrote:
> > > On Sat, Feb 06, 2021 at 03:33:48PM -0500, Dennis Clarke via
> freebsd-current wrote:
> > >> On 2/6/21 2:59 PM, Steve Kargl wrote:
> > >>> Any one aware of where images from freebsd-current?
> > >>> freebsd.org appears to offer no images.
> > >>>
> > >>
> > >> try
> > >> https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/
> > >>
> > >> Also .. have you tried RISC-V ??
> > >>
> > >
> > > 13.0 does not equal 14.0.  On my Dell Latitude D530 laptop,
> > > i386-freebsd current ran well up to about Dec 2, 2020.  Since
> > > an attempted update in early Jan 2021, I've had nothing but
> > > daily panics and other issues.  There are two possibilities:
> > > (1) failing hardware and/or (2) recently introduced i386-freebsd
> > > kernel issues.  Installing amd64-freebsd may eliminate one
> > > of the two possibilities.
> > >
> >
> > so install the latest there and then do a buildworld and buildkernel.
> >
> > easy.
>
> Ah, that's my question.  Where can I find a freebsd-14.0
> amd64 iso image so that I can install the latest?
>

They haven't started yet. I recall hearing they will resume after BETA1 is
out.

Warner

-- 
> Steve
> ___
> 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: any images for freebsd-current?

[Steve Kargl]

On Sat, Feb 06, 2021 at 04:49:46PM -0500, Dennis Clarke via freebsd-current 
wrote:
> On 2/6/21 4:02 PM, Steve Kargl wrote:
> > On Sat, Feb 06, 2021 at 03:33:48PM -0500, Dennis Clarke via freebsd-current 
> > wrote:
> >> On 2/6/21 2:59 PM, Steve Kargl wrote:
> >>> Any one aware of where images from freebsd-current?
> >>> freebsd.org appears to offer no images.
> >>>
> >>
> >> try
> >> https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/
> >>
> >> Also .. have you tried RISC-V ??
> >>
> > 
> > 13.0 does not equal 14.0.  On my Dell Latitude D530 laptop,
> > i386-freebsd current ran well up to about Dec 2, 2020.  Since
> > an attempted update in early Jan 2021, I've had nothing but
> > daily panics and other issues.  There are two possibilities:
> > (1) failing hardware and/or (2) recently introduced i386-freebsd
> > kernel issues.  Installing amd64-freebsd may eliminate one
> > of the two possibilities.
> > 
> 
> so install the latest there and then do a buildworld and buildkernel.
> 
> easy.

Ah, that's my question.  Where can I find a freebsd-14.0 
amd64 iso image so that I can install the latest?

-- 
Steve
___
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 images for freebsd-current?

[Rebecca Cran]

On 2/6/2021 1:33 PM, Dennis Clarke via freebsd-current wrote:


On 2/6/21 2:59 PM, Steve Kargl wrote:

Any one aware of where images from freebsd-current?
freebsd.org appears to offer no images.


try
https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/

Also .. have you tried RISC-V ??



FreeBSD -CURRENT is 14.0 now. It looks like there aren't any snapshots yet.


--
Rebecca Cran


___
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 images for freebsd-current?

[Dennis Clarke via freebsd-current]

On 2/6/21 4:02 PM, Steve Kargl wrote:
> On Sat, Feb 06, 2021 at 03:33:48PM -0500, Dennis Clarke via freebsd-current 
> wrote:
>> On 2/6/21 2:59 PM, Steve Kargl wrote:
>>> Any one aware of where images from freebsd-current?
>>> freebsd.org appears to offer no images.
>>>
>>
>> try
>> https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/
>>
>> Also .. have you tried RISC-V ??
>>
> 
> 13.0 does not equal 14.0.  On my Dell Latitude D530 laptop,
> i386-freebsd current ran well up to about Dec 2, 2020.  Since
> an attempted update in early Jan 2021, I've had nothing but
> daily panics and other issues.  There are two possibilities:
> (1) failing hardware and/or (2) recently introduced i386-freebsd
> kernel issues.  Installing amd64-freebsd may eliminate one
> of the two possibilities.
> 

so install the latest there and then do a buildworld and buildkernel.

easy.

Dennis
___________
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 images for freebsd-current?

[Steve Kargl]

On Sat, Feb 06, 2021 at 03:33:48PM -0500, Dennis Clarke via freebsd-current 
wrote:
> On 2/6/21 2:59 PM, Steve Kargl wrote:
> > Any one aware of where images from freebsd-current?
> > freebsd.org appears to offer no images.
> > 
> 
> try
> https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/
> 
> Also .. have you tried RISC-V ??
> 

13.0 does not equal 14.0.  On my Dell Latitude D530 laptop,
i386-freebsd current ran well up to about Dec 2, 2020.  Since
an attempted update in early Jan 2021, I've had nothing but
daily panics and other issues.  There are two possibilities:
(1) failing hardware and/or (2) recently introduced i386-freebsd
kernel issues.  Installing amd64-freebsd may eliminate one
of the two possibilities.

-- 
Steve
_______
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 images for freebsd-current?

[Dennis Clarke via freebsd-current]

On 2/6/21 2:59 PM, Steve Kargl wrote:
> Any one aware of where images from freebsd-current?
> freebsd.org appears to offer no images.
> 

try
https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/

Also .. have you tried RISC-V ??

-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
_______
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"

any images for freebsd-current?

[Steve Kargl]

Any one aware of where images from freebsd-current?
freebsd.org appears to offer no images.

-- 
Steve
___
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 src: pulling without pushing: example Git commands to clone then update

[Graham Perrin]

On 23/12/2020 10:13, Johan Hendriks wrote:

… For me and i think a lot of regular users that do not push just 
pull, a simple page with the exact commands to track stable or head is 
very appreciated.


Like svnlite update /usr/src replace with git pull  and so on and 
an example for head, stable or release will push most people in the 
right direction. … 



-CURRENT


Guided mostly by the documentation:

1. with /usr/src as an empty working directory
2. the command below, just once

git clone -o freebsd -b main --depth 1 https://git.freebsd.org/src.git 
freebsd-current


(I do not foresee me committing, and I had no immediate interest in 
history.)


Subsequent updates
--

portsnap auto && git -C /usr/src/freebsd-current pull --ff-only && echo 
"FreeBSD-CURRENT Git revision: " && git -C /usr/src/freebsd-current 
rev-list --count HEAD


– take what you like from that. Not intended to be an exact command for 
other users, but it suits me.


Context: <https://old.reddit.com/comments/keme3b/-/ggs61in/?context=1>

HTH
Graham

_______
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: FreeBSD-CURRENT VirtualBox guest: EFI: lost the ability to boot

[Graham Perrin]

On 20/12/2020 00:31, Graham Perrin wrote:


… With the boot maintenance manager of VirtualBox, I 
<https://imgur.com/BTsj4zS> navigated to loader.efi, added it as a 
boot option (I lazily named it 'loader.efi') then set it as primary 
<https://imgur.com/FYnHynr> after which:


* normal resets or restarts of the VM do successfully boot

– and if I change the boot order to make 'EFI Hard Drive' primary and 
'loader.efi' last, boots fail (drop outs to the EFI shell).


<https://imgur.com/MYLowDt> and <https://imgur.com/G3SKMZh> it appears 
that 'EFI Hard Drive' and 'EFI DVD/CDROM' have the same path. Surely 
wrong, I can think of nothing that might have caused this.


The boot manager of VirtualBox repeatedly lost the working boot option 
that I repeatedly added, leaving a non-working 'EFI Hard drive' option.


I tried releasing the virtual disk, creating a new hard disk-less 
virtual machine with EFI enabled, then added the disk. First boot 
failed, dropped to EFI. It worked after I manually added a boot option 
to the boot manager but then again the working option was lost.


Is this symptomatic of a bug with VirtualBox?

This weekend I sort of lost the ability to think straight :-)

___
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: FreeBSD-CURRENT VirtualBox guest: EFI: lost the ability to boot

[Toomas Soome]

> On 19. Dec 2020, at 23:21, Graham Perrin  wrote:
> 
> With VirtualBox on an r368589 host I installed the latest (17th December) 
> snapshot of 13.0-CURRENT in a guest machine. I set the guest to EFI before 
> installation, and chose GPT (UEFI) during installation.
> 
> After installing KDE Plasma etc., the guest worked for a short while but then 
> failed to boot. Screenshots at <https://imgur.com/a/xoYHwbT>; scroll down to 
> 17:49:06 for a shot of a failure.
> 
> Is this maybe another case of bug 251866? 
> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251866>
> 
> _______
> 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”


Do You mean the screenshot with UEFI shell? You usually do drop to UEFI shell 
when firmware did decide it can not start your efi application. Other option 
is, we got failure and did exit loader.efi.

it may help if you attempt to start loader.efi manually from ESP, by entering: 
FS0:/efi/boot/bootx64.efi  — there may appear some messages...

rgds,
toomas
___
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: FreeBSD-CURRENT VirtualBox guest: EFI: lost the ability to boot

[Graham Perrin]

On 19/12/2020 23:20, Warner Losh wrote:



On Sat, Dec 19, 2020 at 2:21 PM Graham Perrin <mailto:grahamper...@gmail.com>> wrote:


With VirtualBox on an r368589 host I installed the latest (17th
December) snapshot of 13.0-CURRENT in a guest machine. I set the
guest
to EFI before installation, and chose GPT (UEFI) during installation.

After installing KDE Plasma etc., the guest worked for a short
while but
then failed to boot. Screenshots at <https://imgur.com/a/xoYHwbT
<https://imgur.com/a/xoYHwbT>>;
scroll down to 17:49:06 for a shot of a failure.

Is this maybe another case of bug 251866?
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251866
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251866>>


Try the next snapshot... I just fixed this in -current... or so I 
claim. Please validate my claim. :)


Though unless there's a bunch of stuff where the boot loader fails and 
then loads the shell, maybe not...


You need to check you ESP to make sure there's a bootx64.efi in 
\efi\boot\ as well... that would also kick you into the shell...


Warner



Thanks, will the next snapshot be on/around 24th December? Or later, 
with the festive season?


In the meantime I added four shots to the album. With the boot 
maintenance manager of VirtualBox, I <https://imgur.com/BTsj4zS> 
navigated to loader.efi, added it as a boot option (I lazily named it 
'loader.efi') then set it as primary <https://imgur.com/FYnHynr> after 
which:


* normal resets or restarts of the VM do successfully boot

– and if I change the boot order to make 'EFI Hard Drive' primary and 
'loader.efi' last, boots fail (drop outs to the EFI shell).


<https://imgur.com/MYLowDt> and <https://imgur.com/G3SKMZh> it appears 
that 'EFI Hard Drive' and 'EFI DVD/CDROM' have the same path. Surely 
wrong, I can think of nothing that might have caused this.


Graham

___________
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: FreeBSD-CURRENT VirtualBox guest: EFI: lost the ability to boot

[Warner Losh]

On Sat, Dec 19, 2020 at 2:21 PM Graham Perrin 
wrote:

> With VirtualBox on an r368589 host I installed the latest (17th
> December) snapshot of 13.0-CURRENT in a guest machine. I set the guest
> to EFI before installation, and chose GPT (UEFI) during installation.
>
> After installing KDE Plasma etc., the guest worked for a short while but
> then failed to boot. Screenshots at <https://imgur.com/a/xoYHwbT>;
> scroll down to 17:49:06 for a shot of a failure.
>
> Is this maybe another case of bug 251866?
> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251866>
>

Try the next snapshot... I just fixed this in -current... or so I claim.
Please validate my claim. :)

Though unless there's a bunch of stuff where the boot loader fails and then
loads the shell, maybe not...

You need to check you ESP to make sure there's a bootx64.efi in \efi\boot\
as well... that would also kick you into the shell...

Warner
_______
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD-CURRENT VirtualBox guest: EFI: lost the ability to boot

[Graham Perrin]

With VirtualBox on an r368589 host I installed the latest (17th 
December) snapshot of 13.0-CURRENT in a guest machine. I set the guest 
to EFI before installation, and chose GPT (UEFI) during installation.


After installing KDE Plasma etc., the guest worked for a short while but 
then failed to boot. Screenshots at <https://imgur.com/a/xoYHwbT>; 
scroll down to 17:49:06 for a shot of a failure.


Is this maybe another case of bug 251866? 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251866>


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

Subject: Important update for freebsd-current@freebsd.org: Please see transcript for details.

[Email Gateway Security]

___
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 with wifi + usb in latest FreeBSD-current

[Graham Perrin]

On 14/09/2020 06:29, Adrian Chadd wrote:

Yeah, this was also reported in #freebsd-wireless today.


FWIW <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249326#c2> 
through bisection, recent r365488 is identified as panicking with vboxdrv


___
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: USB sound devices with FreeBSD-CURRENT

[Hans Petter Selasky]

On 2020-09-13 16:30, Hans Petter Selasky wrote:

On 2020-09-13 16:13, Graham Perrin wrote:

pcm3:  (rec)
pcm4:  (play/rec)


Or:

-R /dev/dsp4 -P /dev/dsp4

-f /dev/dsp4

You can also add these parameters run-time via the GUI for virtual_oss.



As a follow up to this discussion I've lowered the default buffer 
latency to 8ms, which is the default for all USB devices.


https://svnweb.freebsd.org/changeset/ports/548703

--HPS
___
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 with wifi + usb in latest FreeBSD-current

[Kevin Oberman]

Small correction... My rtwn is running at 1 MB, not Mb. I have two tools
watching the network, one does bits and the other bytes. Still,
performance is really bad. Can't say whether it's the driver or something
else, but I'll be gathering data as I can between reboots of my current
system.

Sorry for the bogus information.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683


On Mon, Sep 14, 2020 at 9:52 AM Kevin Oberman  wrote:

> On Sun, Sep 13, 2020 at 11:31 PM Adrian Chadd 
> wrote:
>
>> On Sun, 13 Sep 2020 at 22:34, Warner Losh  wrote:
>>
>> >
>> >
>> > On Sun, Sep 13, 2020, 11:29 PM Adrian Chadd 
>> > wrote:
>> >
>> >> Yeah, this was also reported in #freebsd-wireless today.
>> >>
>> >> Is there a lock being held in the rtwn path that shouldn't be?
>> >>
>> >
>> > I'll check in the morning... this was like the 20th thing to go wrong
>> this
>> > weekend,  so I copied the panic down, send the email and grabbed a beer
>> and
>> > turned it off...
>> >
>>
>> Ok. I checked the driver and the usb stack; nothing in the change lists
>> obviously stands out to me at 11pm on a Sunday.
>>
>> Can you see if any locks are held? or an epoch? Something smells fishy.
>> (defining EPOCH_TRACE will dump the list of epochs, if I'm reading the
>> subr_sleepqueue.c code correctly.)
>>
>> Ok, so, since I dug a bit more on a hunch, I bet the NET epoch is being
>> held - it's grabbed in rtwn_bulk_rx_callback, and rtwn_rx_common is
>> reading
>> some registers as part of processing the receive queue. I bet that act of
>> reading registers over blocking USB is causing things to explode.
>>
>> If it is net epoch then we're going to have to think of a better design
>> pattern here to migrate all of these here wifi drivers to, because I
>> guarantee you they're all behaving poorly in this newer world order.
>>
>>
>>
>> Thanks,
>>
>>
>> -adrian
>>
> While I have not seen panics, performance of my rtwn has simply cratered.
> Trying to move files to my new laptop, which has an rtwn, it crawls at
> about 1.5 Mbps. Before I built an updated kernel, I was seeing 60M. Of
> course, this is complicated by the continual kernel lockups I keep getting,
> so I really didn't think much about it until I saw Warner's note.
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>
>
___
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 with wifi + usb in latest FreeBSD-current

[Kevin Oberman]

On Sun, Sep 13, 2020 at 11:31 PM Adrian Chadd 
wrote:

> On Sun, 13 Sep 2020 at 22:34, Warner Losh  wrote:
>
> >
> >
> > On Sun, Sep 13, 2020, 11:29 PM Adrian Chadd 
> > wrote:
> >
> >> Yeah, this was also reported in #freebsd-wireless today.
> >>
> >> Is there a lock being held in the rtwn path that shouldn't be?
> >>
> >
> > I'll check in the morning... this was like the 20th thing to go wrong
> this
> > weekend,  so I copied the panic down, send the email and grabbed a beer
> and
> > turned it off...
> >
>
> Ok. I checked the driver and the usb stack; nothing in the change lists
> obviously stands out to me at 11pm on a Sunday.
>
> Can you see if any locks are held? or an epoch? Something smells fishy.
> (defining EPOCH_TRACE will dump the list of epochs, if I'm reading the
> subr_sleepqueue.c code correctly.)
>
> Ok, so, since I dug a bit more on a hunch, I bet the NET epoch is being
> held - it's grabbed in rtwn_bulk_rx_callback, and rtwn_rx_common is reading
> some registers as part of processing the receive queue. I bet that act of
> reading registers over blocking USB is causing things to explode.
>
> If it is net epoch then we're going to have to think of a better design
> pattern here to migrate all of these here wifi drivers to, because I
> guarantee you they're all behaving poorly in this newer world order.
>
>
>
> Thanks,
>
>
> -adrian
>
While I have not seen panics, performance of my rtwn has simply cratered.
Trying to move files to my new laptop, which has an rtwn, it crawls at
about 1.5 Mbps. Before I built an updated kernel, I was seeing 60M. Of
course, this is complicated by the continual kernel lockups I keep getting,
so I really didn't think much about it until I saw Warner's note.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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 with wifi + usb in latest FreeBSD-current

[Adrian Chadd]

On Sun, 13 Sep 2020 at 22:34, Warner Losh  wrote:

>
>
> On Sun, Sep 13, 2020, 11:29 PM Adrian Chadd 
> wrote:
>
>> Yeah, this was also reported in #freebsd-wireless today.
>>
>> Is there a lock being held in the rtwn path that shouldn't be?
>>
>
> I'll check in the morning... this was like the 20th thing to go wrong this
> weekend,  so I copied the panic down, send the email and grabbed a beer and
> turned it off...
>

Ok. I checked the driver and the usb stack; nothing in the change lists
obviously stands out to me at 11pm on a Sunday.

Can you see if any locks are held? or an epoch? Something smells fishy.
(defining EPOCH_TRACE will dump the list of epochs, if I'm reading the
subr_sleepqueue.c code correctly.)

Ok, so, since I dug a bit more on a hunch, I bet the NET epoch is being
held - it's grabbed in rtwn_bulk_rx_callback, and rtwn_rx_common is reading
some registers as part of processing the receive queue. I bet that act of
reading registers over blocking USB is causing things to explode.

If it is net epoch then we're going to have to think of a better design
pattern here to migrate all of these here wifi drivers to, because I
guarantee you they're all behaving poorly in this newer world order.



Thanks,


-adrian




>
> panic: sleepq_add: td  to sleep on wchan  with sleeping
>>> prohibited
>>> cpuid = 5
>>> time = 1600057358
>>> KDB: stack backtrace:
>>> ...
>>> panic()
>>> sleepq_add()
>>> _cv_wait()
>>> usbd_do_request_flags
>>> rtwn_do_request
>>> rtwn_usb_read_4
>>> rtwn_rx_common
>>> rtwn_bulk_rx_callback
>>> usbd_callback_wrapper
>>> usb_command_wrapper
>>> usb_callback_proc
>>> usb_process
>>> ...
>>>
>>> I've done a fresh installworld and installkernel, but am running packages
>>> from late may since I've not updated them. I've updated the iichid and
>>> drm-kmod ports and rebuilt them and reinstalled them as well (so I know
>>> they aren't out of date).
>>>
>>> Has anybody else seen this?
>>>
>>> Warner
>>> ___________
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "
>>> freebsd-current-unsubscr...@freebsd.org"
>>>
>>
___
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 with wifi + usb in latest FreeBSD-current

[Warner Losh]

On Sun, Sep 13, 2020, 11:29 PM Adrian Chadd  wrote:

> Yeah, this was also reported in #freebsd-wireless today.
>
> Is there a lock being held in the rtwn path that shouldn't be?
>

I'll check in the morning... this was like the 20th thing to go wrong this
weekend,  so I copied the panic down, send the email and grabbed a beer and
turned it off...

Warner


> -adrian
>
>
>
> On Sun, 13 Sep 2020 at 21:30, Warner Losh  wrote:
>
>> I'm running current as of -2h ago.
>>
>> When I plug in my rtwn0 device and it configures, etc, I get:
>>
>> rtwn0 on uhub 0
>> rtwn0:  on
>> usbus0
>> rtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
>>  host dpa_supplicant[1619]: ioctl[SIOS80211, op=20, val=0,
>> arg_len=7]: Invalid argument
>> panic: sleepq_add: td  to sleep on wchan  with sleeping
>> prohibited
>> cpuid = 5
>> time = 1600057358
>> KDB: stack backtrace:
>> ...
>> panic()
>> sleepq_add()
>> _cv_wait()
>> usbd_do_request_flags
>> rtwn_do_request
>> rtwn_usb_read_4
>> rtwn_rx_common
>> rtwn_bulk_rx_callback
>> usbd_callback_wrapper
>> usb_command_wrapper
>> usb_callback_proc
>> usb_process
>> ...
>>
>> I've done a fresh installworld and installkernel, but am running packages
>> from late may since I've not updated them. I've updated the iichid and
>> drm-kmod ports and rebuilt them and reinstalled them as well (so I know
>> they aren't out of date).
>>
>> Has anybody else seen this?
>>
>> Warner
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
>> "
>>
>
___
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 with wifi + usb in latest FreeBSD-current

[Adrian Chadd]

Yeah, this was also reported in #freebsd-wireless today.

Is there a lock being held in the rtwn path that shouldn't be?


-adrian



On Sun, 13 Sep 2020 at 21:30, Warner Losh  wrote:

> I'm running current as of -2h ago.
>
> When I plug in my rtwn0 device and it configures, etc, I get:
>
> rtwn0 on uhub 0
> rtwn0:  on
> usbus0
> rtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
>  host dpa_supplicant[1619]: ioctl[SIOS80211, op=20, val=0,
> arg_len=7]: Invalid argument
> panic: sleepq_add: td  to sleep on wchan  with sleeping
> prohibited
> cpuid = 5
> time = 1600057358
> KDB: stack backtrace:
> ...
> panic()
> sleepq_add()
> _cv_wait()
> usbd_do_request_flags
> rtwn_do_request
> rtwn_usb_read_4
> rtwn_rx_common
> rtwn_bulk_rx_callback
> usbd_callback_wrapper
> usb_command_wrapper
> usb_callback_proc
> usb_process
> ...
>
> I've done a fresh installworld and installkernel, but am running packages
> from late may since I've not updated them. I've updated the iichid and
> drm-kmod ports and rebuilt them and reinstalled them as well (so I know
> they aren't out of date).
>
> Has anybody else seen this?
>
> Warner
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___________
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"

Panic with wifi + usb in latest FreeBSD-current

[Warner Losh]

I'm running current as of -2h ago.

When I plug in my rtwn0 device and it configures, etc, I get:

rtwn0 on uhub 0
rtwn0:  on
usbus0
rtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
 host dpa_supplicant[1619]: ioctl[SIOS80211, op=20, val=0,
arg_len=7]: Invalid argument
panic: sleepq_add: td  to sleep on wchan  with sleeping prohibited
cpuid = 5
time = 1600057358
KDB: stack backtrace:
...
panic()
sleepq_add()
_cv_wait()
usbd_do_request_flags
rtwn_do_request
rtwn_usb_read_4
rtwn_rx_common
rtwn_bulk_rx_callback
usbd_callback_wrapper
usb_command_wrapper
usb_callback_proc
usb_process
...

I've done a fresh installworld and installkernel, but am running packages
from late may since I've not updated them. I've updated the iichid and
drm-kmod ports and rebuilt them and reinstalled them as well (so I know
they aren't out of date).

Has anybody else seen this?

Warner
___________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB sound devices with FreeBSD-CURRENT

[Hans Petter Selasky]

On 2020-09-13 16:13, Graham Perrin wrote:

pcm3:  (rec)
pcm4:  (play/rec)


Or:

-R /dev/dsp4 -P /dev/dsp4

-f /dev/dsp4

You can also add these parameters run-time via the GUI for virtual_oss.

--HPS
___
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: USB sound devices with FreeBSD-CURRENT

[Hans Petter Selasky]

On 2020-09-13 16:13, Graham Perrin wrote:

   -f /dev/dsp0 \


Try:

-f /dev/dsp3

--HPS
___
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: USB sound devices with FreeBSD-CURRENT

[Graham Perrin]

Now with

On 13/09/2020 10:24, Hans Petter Selasky wrote:

On 2020-09-13 11:21, Graham Perrin wrote:


1. Chromium simply does not play AV content e.g. 
<https://www.ted.com/talks/james_geary_metaphorically_speaking> – 
after a click to play, there's a moment of visual motion but no playback


2. if Firefox media.cubeb.backend set to oss then behaviour is the 
same as Chromium


3. if Firefox media.cubeb.backend is not set (audio backend defaults 
to pulse-rust) then playback occurs through IDT 92HD81B1X (Analog) – 
not USB.


Try to configure a smaller audio buffer size in virtual_oss . 
Sometimes devices request a very small audio buffer .


--HPS


Now with virtual_oss and sndiod disabled (starting them when required 
with onestart), with the buffer size reduced from 1024 to 256,




root@momh167-gjp4-8570p:~ # head -n 55 /usr/local/etc/rc.d/virtual_oss | 
grep -v \#



. /etc/rc.subr

name=virtual_oss
desc="Virtual OSS device manager"
rcvar=${name}_enable
start_precmd="${name}_precmd"
start_cmd="${name}_start"
stop_cmd="${name}_stop"
virtual_oss_default_args="\
  -T /dev/sndstat \
  -S \
  -i 8 \
  -C 2 -c 2 \
  -r 48000 \
  -b 24 \
  -s 256 \
  -f /dev/dsp0 \
  -c 2 \
  -d dsp \
  -t dsp.ctl"
configs=

load_rc_config $name

root@momh167-gjp4-8570p:~ # service virtual_oss onestart ; service 
sndiod onestart ; service virtual_oss onestatus ; service sndiod 
onestatus ; cat /dev/sndstat

Starting Virtual OSS config dsp ... done
Starting sndiod.
virtual_oss is running as pid 5990.
sndiod is running as pid 6006.
Installed devices:
pcm0:  (play) default
pcm1:  (play/rec)
pcm2:  (play/rec)
pcm3:  (rec)
pcm4:  (play/rec)
No devices installed from userspace.
root@momh167-gjp4-8570p:~ #



I get visual playback but nothing audible at the USB headset or analogue 
loudspeakers.


I see device buffer sizes below but I don't know how to use those to 
determine a usable setting for -s in /usr/local/etc/rc.d/virtual_oss


From dmesg :



ugen0.5:  at usbus0
uhid1 on uhub2
uhid1:  
on usbus0

uaudio0 on uhub2
uaudio0: 4> on usbus0

uaudio0: No playback.
uaudio0: Record[0]: 48000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record[0]: 44100 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record[0]: 32000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record[0]: 22050 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record[0]: 16000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record[0]: 11025 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record[0]: 8000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio0: No MIDI sequencer.
pcm3:  on uaudio0
uaudio0: No HID volume keys found.
ugen0.6:  at usbus0
uhub8 on uhub2
uhub8:  
on usbus0

uhub8: MTT enabled
uhub8: 4 ports with 4 removable, self powered
ugen0.7:  at usbus0
uaudio1 on uhub8
uaudio1: addr 6> on usbus0

uaudio1: Play[0]: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio1: Play[0]: 44100 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio1: Play[0]: 22050 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio1: Play[0]: 16000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio1: Play[0]: 11025 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio1: Play[0]: 8000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio1: Record[0]: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio1: Record[0]: 44100 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio1: Record[0]: 22050 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio1: Record[0]: 16000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio1: Record[0]: 11025 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio1: Record[0]: 8000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio1: No MIDI sequencer.
pcm4:  on uaudio1
uaudio1: HID volume keys found.

___
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: USB sound devices with FreeBSD-CURRENT

[Samy Mahmoudi]

Hi,

If reducing the audio buffer size in virtual_oss does not solve the issue
and you temporarily resort to use PulseAudio to achieve switching devices
on-the-fly (which does work very well with PulseAudio), you could indeed
'keep the devices connected' and use a variant of the following script:

#!/usr/local/bin/zsh
SINK_INDEX1=1
SINK_INDEX2=4
ACTIVE_SINK=$(pacmd list-sinks | grep '* index:' | /usr/local/bin/grep -o
'[0-9]*')
if [ "$ACTIVE_SINK" = $SINK_INDEX1 ] ; then
pacmd set-default-sink $SINK_INDEX2
pacmd list-sink-inputs | awk '/index:/{print $2}' | xargs -r -I{} pacmd
move-sink-input {} $SINK_INDEX2
else
pacmd set-default-sink $SINK_INDEX1
pacmd list-sink-inputs | awk '/index:/{print $2}' | xargs -r -I{} pacmd
move-sink-input {} $SINK_INDEX1
fi

In its current form, it allowed me to switch devices on-the-fly with a
keyboard shortcut.

The problem is I had to use a poudriere to build relevant ports with option
PULSEAUDIO (chromium, firefox, mpv, audacious, virtualbox, etc.) and there
may have been (I can not remember precisely) another problem if the USB
headset was either hot-plugged or hot-unplugged. Please let us know if you
manage to sort this out with virtual_oss.
___
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: USB sound devices with FreeBSD-CURRENT

[Tomasz CEDRO]

I am using EMU10K1 attached to the sound system over USB on my laptop
and the device needs to be connected on boot - unplug will crash the
system.

If device is plugged in on boot and I add `hw.snd.default_unit=3` to
`/etc/sysctl.conf`, that is before I start X, then I have audio
playback "by default".

In order to have dynamic audio configuration I have found PulseAudio
helpful a lot as it allows you to select which application uses which
input/otput audio device. Note that PulseAudio can lock your audio
hardware and block clean module removal.

I am not sure about current default sound system in FreeBSD if its
still OSS or ALSA, but if you do not want to use PulseAudio, you may
want to try ALSA configuration at `/usr/local/etc/asound.conf` it
allows some more detailed remap.

Good luck :-)
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
_______
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: USB sound devices with FreeBSD-CURRENT

[Hans Petter Selasky]

On 2020-09-13 11:21, Graham Perrin wrote:


1. Chromium simply does not play AV content e.g. 
<https://www.ted.com/talks/james_geary_metaphorically_speaking> – after 
a click to play, there's a moment of visual motion but no playback


2. if Firefox media.cubeb.backend set to oss then behaviour is the same 
as Chromium


3. if Firefox media.cubeb.backend is not set (audio backend defaults to 
pulse-rust) then playback occurs through IDT 92HD81B1X (Analog) – not USB.


Try to configure a smaller audio buffer size in virtual_oss . Sometimes 
devices request a very small audio buffer .


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

USB sound devices with FreeBSD-CURRENT

[Graham Perrin]

for sound 
application to exit!

root@momh167-gjp4-8570p:~ #



Clearly I'm doing something wrong.

If on-the-fly use of USB audio devices is not possible, then must I keep 
the devices connected whilst I'm signed in to the desktop environment?

___________
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: freebsd-current Digest, Vol 877, Issue 7

[Vanbreukelingen Ltd.]

replying to myself at 1am:

1. completely new-install

2. kmod-legacy and kmd-stable built

3. svn up; make kernel

4. linux-c7 from /ports installed

5. kld_load x 2

6. fine drm initialized but when trying to sddm or xinit or startx or 
whatever I get a loong debug output message with self reset running 
over my screen.


any help?

miranda


On 22.08.20 14:00, freebsd-current-requ...@freebsd.org wrote:

Send freebsd-current mailing list submissions to
freebsd-current@freebsd.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.freebsd.org/mailman/listinfo/freebsd-current
or, via email, send a message with subject or body 'help' to
    freebsd-current-requ...@freebsd.org

You can reach the person managing the list at
    freebsd-current-ow...@freebsd.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-current digest..."


Today's Topics:

    1. Re: freebsd-current Digest, Vol 877, Issue 6
   (Vanbreukelingen Ltd.)
2. /usr/lib/libomp.so : is there a reason that aarch64 does not
   have such by default? (Mark Millard)
3. FreeBSD CI Weekly Report 2020-08-16 (Li-Wen Hsu)
4. Re: Kernel crash during video transcoding (Hans Petter Selasky)
5. Re: /usr/lib/libomp.so : is there a reason that aarch64 does
   not have such by default? (myfreeweb)
6. 13-CURRENT won't boot after switch to sysutils/openzfs (marco)


--

Message: 1
Date: Fri, 21 Aug 2020 19:37:54 +0200
From: "Vanbreukelingen Ltd." 
To: freebsd-current@freebsd.org
Subject: Re: freebsd-current Digest, Vol 877, Issue 6
Message-ID: <2624761.GQDcWxOStt@alice>
Content-Type: text/plain; charset="us-ascii"

here we go - when nothing works anymore (kernel panic after a simple 'xinit'
and kwin_x11. recomiled to WITNESS="YES" and HYPERV off, but still same panics.

https://pasteboard.co/Jnqgbeq.png



On Friday, August 21, 2020 2:00:00 PM CEST freebsd-current-requ...@freebsd.org
wrote:


Message: 1
Date: Thu, 20 Aug 2020 08:15:56 +0200
From: "Vanbreukelingen Ltd." 
To: Current FreeBSD 
Subject: Re: funny thing with the drm0
Message-ID: <8073347.hK6j7OjjKr@alice>
Content-Type: text/plain; charset="us-ascii"

On Thursday, August 20, 2020 8:12:58 AM CEST Vanbreukelingen Ltd. wrote:

On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote:

On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D <

lizbethmutterh...@gmail.com> wrote:

After having had some near-death-experiences in Greece I'm back to my
screens. As horizon arises, BSD gets up --- and if it is 3 a.m.! :-)


But this is the experience with my Dell Vostro on 13 current:


After finally recompiling the kernel with the drm-module inside and
the trick of injecting the

This is not the way to do it. Modern hardware require drm-kmod from
ports,
or if you want the latest drm-devel-kmod. Then add  /boot/modules/drm.ko
and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf

wasn't yet finished (c [see] beyond), but I guess I have to disable the
whole output with something like hw.*=1 or so. is it possible to make a
bootlogo while VEBOSE output = 2 just for the reason some kids try to play
with it.


device IWNFW

  doesn't install the 6000, btw --- probably can't find FW on device HAL.


Again, this is not needed, firmware is autoloaded on module load. Just
add
if_iwn to kld_list in /etc/rc.conf

  built of 15 hours of NanoBSD while finishing the nightly built someone was
on Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at all
but some reason tells me behind this system in system is something to beat
beastie in killing KFC forks. ;-)


I get a *nice* message a bootup:

Aug 19 02:51:10 current kernel: info: [drm] Initialized drm 1.1.0
20060810
Aug 19 02:51:10 current kernel: drmn0:  on
vgapci0
Aug 19 02:51:10 current kernel: info: [drm] Memory usable by graphics
device = 2048M
Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation failed.
Graphics performance may suffer.
Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0
Aug 19 02:51:10 current kernel: iicbus0:  on
iicbb_nostop0 addr 0x1
Aug 19 02:51:10 current kernel: iic0:  on iicbus0
Aug 19 02:51:10 current kernel: iicbus1:  on
intel_gmbus0
Aug 19 02:51:10 current kernel: iic1:  on iicbus1
Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0
Aug 19 02:51:10 current kernel: iicbus2:  on
iicbb_nostop1 addr 0x12
Aug 19 02:51:10 current kernel: iic2:  on iicbus2
Aug 19 02:51:10 current kernel: iicbus3:  on
intel_gmbus1
Aug 19 02:51:10 current kernel: iic3:  on iicbus3
Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0
Aug 19 02:51:10 current kernel: iicbus4:  on
iicbb_nostop2 addr 0x12
Aug 19 02:51:10 current kernel: iic4:  on iicbus4
Aug 19 02:51:10 current kernel: iicbus5:  on
inte

Re: freebsd-current Digest, Vol 877, Issue 6

[Vanbreukelingen Ltd.]

here we go - when nothing works anymore (kernel panic after a simple 'xinit' 
and kwin_x11. recomiled to WITNESS="YES" and HYPERV off, but still same panics. 

https://pasteboard.co/Jnqgbeq.png



On Friday, August 21, 2020 2:00:00 PM CEST freebsd-current-requ...@freebsd.org 
wrote:

> Message: 1
> Date: Thu, 20 Aug 2020 08:15:56 +0200
> From: "Vanbreukelingen Ltd." 
> To: Current FreeBSD 
> Subject: Re: funny thing with the drm0
> Message-ID: <8073347.hK6j7OjjKr@alice>
> Content-Type: text/plain; charset="us-ascii"
> 
> On Thursday, August 20, 2020 8:12:58 AM CEST Vanbreukelingen Ltd. wrote:
> > On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote:
> > > On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D <
> > > 
> > > lizbethmutterh...@gmail.com> wrote:
> > > > After having had some near-death-experiences in Greece I'm back to my
> > > > screens. As horizon arises, BSD gets up --- and if it is 3 a.m.! :-)
> > > > 
> > > > 
> > > > But this is the experience with my Dell Vostro on 13 current:
> > > > 
> > > > 
> > > > After finally recompiling the kernel with the drm-module inside and
> > > > the trick of injecting the
> > > 
> > > This is not the way to do it. Modern hardware require drm-kmod from
> > > ports,
> > > or if you want the latest drm-devel-kmod. Then add  /boot/modules/drm.ko
> > > and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf
> 
> wasn't yet finished (c [see] beyond), but I guess I have to disable the
> whole output with something like hw.*=1 or so. is it possible to make a
> bootlogo while VEBOSE output = 2 just for the reason some kids try to play
> with it.
> 
> > > > device IWNFW
> 
>  doesn't install the 6000, btw --- probably can't find FW on device HAL.
> 
> > > Again, this is not needed, firmware is autoloaded on module load. Just
> > > add
> > > if_iwn to kld_list in /etc/rc.conf
> 
>  built of 15 hours of NanoBSD while finishing the nightly built someone was
> on Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at all
> but some reason tells me behind this system in system is something to beat
> beastie in killing KFC forks. ;-)
> 
> > > > I get a *nice* message a bootup:
> > > > 
> > > > Aug 19 02:51:10 current kernel: info: [drm] Initialized drm 1.1.0
> > > > 20060810
> > > > Aug 19 02:51:10 current kernel: drmn0:  on
> > > > vgapci0
> > > > Aug 19 02:51:10 current kernel: info: [drm] Memory usable by graphics
> > > > device = 2048M
> > > > Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation failed.
> > > > Graphics performance may suffer.
> > > > Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0
> > > > Aug 19 02:51:10 current kernel: iicbus0:  on
> > > > iicbb_nostop0 addr 0x1
> > > > Aug 19 02:51:10 current kernel: iic0:  on iicbus0
> > > > Aug 19 02:51:10 current kernel: iicbus1:  on
> > > > intel_gmbus0
> > > > Aug 19 02:51:10 current kernel: iic1:  on iicbus1
> > > > Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0
> > > > Aug 19 02:51:10 current kernel: iicbus2:  on
> > > > iicbb_nostop1 addr 0x12
> > > > Aug 19 02:51:10 current kernel: iic2:  on iicbus2
> > > > Aug 19 02:51:10 current kernel: iicbus3:  on
> > > > intel_gmbus1
> > > > Aug 19 02:51:10 current kernel: iic3:  on iicbus3
> > > > Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0
> > > > Aug 19 02:51:10 current kernel: iicbus4:  on
> > > > iicbb_nostop2 addr 0x12
> > > > Aug 19 02:51:10 current kernel: iic4:  on iicbus4
> > > > Aug 19 02:51:10 current kernel: iicbus5:  on
> > > > intel_gmbus2
> > > > Aug 19 02:51:10 current kernel: iic5:  on iicbus5
> > > > Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0
> > > > Aug 19 02:51:10 current kernel: iicbus6:  on
> > > > iicbb_nostop3 addr 0x12
> > > > Aug 19 02:51:10 current kernel: iic6:  on iicbus6
> > > > Aug 19 02:51:10 current kernel: iicbus7:  on
> > > > intel_gmbus3
> > > > Aug 19 02:51:10 current kernel: iic7:  on iicbus7
> > > > Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0
> > > > Aug 19 02:51:10 current kernel: iicbus8:  on
> > > > iicbb_nostop4 addr 0x12
> > > > Aug 19 02:51:10 current kernel: iic8:  on iicbus8
>

You have [3] undelivered mails freebsd-current@freebsd.org

[I.T Server]

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

VirtualBox segmentation fault, 5.2.34_2 on FreeBSD-CURRENT r359628

[Graham Perrin]

On 20/03/2020 01:24, Kyle Evans wrote:

On Thu, Mar 19, 2020 at 12:11 PM Graham Perrin  wrote:

Is this maybe related to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244847 or should I
make a separate bug report?


Please throw a tentative "Me too" on that PR; I'm investigating it,
then we'll see if they're related or requires yet another PR.
Re: <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244847#c13> and 
the landing described at comment 15


Now with FreeBSD-CURRENT r359628 I (re)installed virtualbox-ose 
5.2.34_2. Still no go:




root@momh167-gjp4-8570p:~ # pkg remove virtualbox-ose
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 1 packages (of 0 
packages in the universe):


Installed packages to be REMOVED:
    virtualbox-ose: 5.2.34_2

Number of packages to be removed: 1

The operation will free 380 MiB.

Proceed with deinstalling packages? [y/N]: y
[1/1] Deinstalling virtualbox-ose-5.2.34_2...
[1/1] Deleting files for virtualbox-ose-5.2.34_2: 100%
==> You should manually remove the "vboxusers" user.
==> You should manually remove the "vboxusers" group
root@momh167-gjp4-8570p:~ # pkg install -r FreeBSD virtualbox-ose
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
solver: cannot find provide for requirement libopenblas.so when 
processing package: py27-numpy
solver: cannot find provide for requirement libopenblas.so when 
processing package: suitesparse
solver: cannot find provide for requirement libncurses.so.9 when 
processing package: llvm10
solver: cannot find provide for requirement libdioritegtk-0.2.so when 
processing package: nuvolaplayer
solver: cannot find provide for requirement libdioriteglib-0.2.so when 
processing package: nuvolaplayer
solver: cannot find provide for requirement libopenblas.so when 
processing package: coin-or-CoinUtils

The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
    virtualbox-ose: 5.2.34_2 [FreeBSD]

Number of packages to be installed: 1

The process will require 380 MiB more space.
74 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/1] Fetching virtualbox-ose-5.2.34_2.txz: 100%   74 MiB 225.7kB/s    
05:46

Checking integrity... done (0 conflicting)
[1/1] Installing virtualbox-ose-5.2.34_2...
===> Creating groups.
Using existing group 'vboxusers'.
===> Creating users
Using existing user 'vboxusers'.
[1/1] Extracting virtualbox-ose-5.2.34_2: 100%
=
Message from virtualbox-ose-5.2.34_2:
…

Please report any problems to emulation@. Thanks!
root@momh167-gjp4-8570p:~ # exit
logout
grahamperrin@momh167-gjp4-8570p:~ % virtualbox
Segmentation fault
grahamperrin@momh167-gjp4-8570p:~ % date ; uptime ; uname -v
Sun  5 Apr 2020 08:46:06 BST
 8:46a.m.  up  2:33, 6 users, load averages: 3.94, 3.60, 3.14
FreeBSD 13.0-CURRENT #5 r359628: Sun Apr  5 00:25:58 BST 2020 
root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

grahamperrin@momh167-gjp4-8570p:~ %

___
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: USB microphones with FreeBSD-CURRENT: bug 194727, r358629

[Graham Perrin]

On 31/03/2020 03:47, Theron wrote:



I don't know what would be attaching to mixer before login. …



www/plasma5-plasma-browser-integration interaction with x11/sddm maybe?

___
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: USB microphones with FreeBSD-CURRENT: bug 194727, r358629

[Theron]

On 2020-03-30 20:08, Graham Perrin wrote:
Theron, thank you! That might explain a recent sense of randomness 
with the symptoms. I've been testing in three different boot 
environments, only one of which is above the 358629 at 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194727#c22>:


I don't know what would be attaching to mixer before login.  For me the 
problem is predictable: suspending after I've opened a player reliably 
hangs kernel, and killing every user of /dev/dsp* /dev/mixer* before 
sleep reliably avoids the problem.  Maybe something is attaching on startup.


(In retrospect, most remarkable to me was that the bug could bite 
before logging in; taking the 'Sleep' option in sddm did not lead to a 
suspend of the system. Hopefully fixed for FreeBSD-CURRENT by r358629; 
I'll not test now, maybe later in the week.)


As I understand it, r358629 adds a mechanism that applications can use 
to "do the right thing" but does not fix the underlying kernel 
vulnerability.


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

USB microphones with FreeBSD-CURRENT: bug 194727, r358629

[Graham Perrin]

On 30/03/2020 20:36, Theron wrote:


On 2020-03-30 15:06, Graham Perrin wrote:
Worth noting: if I attempt to suspend the system whilst the device at 
3 (SteelSeries Siberia 350 headphones with integral microphone 
<https://steelseries.com/gaming-headsets/siberia-350>) is physically 
connected, suspend sometimes fails; it becomes necessary to force off 
the computer.

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

Theron, thank you! That might explain a recent sense of randomness with 
the symptoms. I've been testing in three different boot environments, 
only one of which is above the 358629 at 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194727#c22>:


grahamperrin@momh167-gjp4-8570p:~ % beadm list
BE   Active Mountpoint  Space Created
Waterfox -  -  383.2M 2020-03-10 18:24
r357746f -  -  148.3M 2020-03-20 06:19
r359249b -  -   15.8G 2020-03-28 01:19
r357746g NR /   60.9G 2020-03-31 00:24

(In retrospect, most remarkable to me was that the bug could bite before 
logging in; taking the 'Sleep' option in sddm did not lead to a suspend 
of the system. Hopefully fixed for FreeBSD-CURRENT by r358629; I'll not 
test now, maybe later in the week.)


_______
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: USB microphones with FreeBSD-CURRENT

[Theron]

On 2020-03-30 15:06, Graham Perrin wrote:
Worth noting: if I attempt to suspend the system whilst the device at 
3 (SteelSeries Siberia 350 headphones with integral microphone 
<https://steelseries.com/gaming-headsets/siberia-350>) is physically 
connected, suspend sometimes fails; it becomes necessary to force off 
the computer.

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

___
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: USB microphones with FreeBSD-CURRENT

[Graham Perrin]

On 28/03/2020 12:45, Jan Beich wrote:

Graham Perrin  writes:


I can't get web browsers to recognise USB microphones.

USB output (e.g. to my headphones) is OK.

USB input (e.g. from the microphone part of the headphones) is not.

Any suggestions?

Firefox uses "pulse-rust" cubeb backend *by default* if "pulseaudio"
package is installed. getUserMedia is supposed to preset a dropdown menu
to select a microphone. Make sure pulseaudio actually recognizes the
desired microphone e.g., debug via "pactl list" and "parec".

I don't have a mic but, looking at the code, only pulse-rust or pulse
backends on Linux/FreeBSD support selecting non-default audio device.
It maybe possible to use other backends but if audio device used for
output and input are different that'd require routing defaults which can
be done via config file (e.g., ~/.asoundrc) or externally via virtual_oss.


pcm3:  (play/rec) default
pcm4:  (rec)

Are these distinct physical devices?


Yes.




hw.snd.default_unit: 3

Have you tried using 4?


I did, but decided that the device previously at 4 (Alctron USB700 
<https://www.alctron-audio.com/EN/microphones/USB/USB700.html>) probably 
has a hardware fault.


Worth noting: if I attempt to suspend the system whilst the device at 3 
(SteelSeries Siberia 350 headphones with integral microphone 
<https://steelseries.com/gaming-headsets/siberia-350>) is physically 
connected, suspend sometimes fails; it becomes necessary to force off 
the computer.


If I start the system with the headphones connected, then the microphone 
at 3 is usable at e.g. 
<https://www.podcastinsights.com/online-mic-test/> and 
<https://talky.io/> (see <https://i.imgur.com/Ch3SuZn.png>) but not in 
Microsoft Teams.


If I disconnect the headphones (to minimise the risk of failure to 
suspend), then reconnect, the system seems unable to reuse the 
headphones (see <https://i.imgur.com/8Of5MUK.png>); a restart is required.


In Microsoft Teams, neither 2 nor 3 is detected; there's only 1 (see 
<https://i.imgur.com/13HmxKi.png>) and after allowing use of /dev/dsp1 
it 'disappears', leaving only the camera in use (head of 
<https://i.imgur.com/k5ak2jL.png>).


___________
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: USB microphones with FreeBSD-CURRENT

[Jan Beich]

Graham Perrin  writes:

> I can't get web browsers to recognise USB microphones.
>
> USB output (e.g. to my headphones) is OK.
>
> USB input (e.g. from the microphone part of the headphones) is not.
>
> Any suggestions?

Firefox uses "pulse-rust" cubeb backend *by default* if "pulseaudio"
package is installed. getUserMedia is supposed to preset a dropdown menu
to select a microphone. Make sure pulseaudio actually recognizes the
desired microphone e.g., debug via "pactl list" and "parec".

I don't have a mic but, looking at the code, only pulse-rust or pulse
backends on Linux/FreeBSD support selecting non-default audio device.
It maybe possible to use other backends but if audio device used for
output and input are different that'd require routing defaults which can
be done via config file (e.g., ~/.asoundrc) or externally via virtual_oss.

> pcm3:  (play/rec) default
> pcm4:  (rec)

Are these distinct physical devices?

> hw.snd.default_unit: 3

Have you tried using 4?
___
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: USB microphones with FreeBSD-CURRENT

[Hans Petter Selasky]

On 2020-03-28 07:31, Graham Perrin wrote:

I can't get web browsers to recognise USB microphones.

USB output (e.g. to my headphones) is OK.

USB input (e.g. from the microphone part of the headphones) is not.

Any suggestions?

 From <https://redd.it/fmwy9x>:



What are the mixer values?

mixer -f /dev/mixerN

Are you sure the volume is set high enough?

--HPS

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

USB microphones with FreeBSD-CURRENT

[Graham Perrin]

I can't get web browsers to recognise USB microphones.

USB output (e.g. to my headphones) is OK.

USB input (e.g. from the microphone part of the headphones) is not.

Any suggestions?

From <https://redd.it/fmwy9x>:

grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
Sun 22 Mar 2020 08:49:07 GMT
FreeBSD 13.0-CURRENT #0 r359068: Wed Mar 18 21:14:12 GMT 2020 
root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

grahamperrin@momh167-gjp4-8570p:~ % cat /dev/sndstat
Installed devices:
pcm0:  (play)
pcm1:  (play/rec)
pcm2:  (play/rec)
pcm3:  (play/rec) default
pcm4:  (rec)
No devices installed from userspace.
grahamperrin@momh167-gjp4-8570p:~ % sysctl hw.snd.default_unit
hw.snd.default_unit: 3
grahamperrin@momh167-gjp4-8570p:~ % pkg query '%o %v %R' firefox
www/firefox 74.0_5,1 FreeBSD
grahamperrin@momh167-gjp4-8570p:~ %
___________
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"

VirtualBox segmentation fault, 5.2.34_1 on FreeBSD-CURRENT r359249

[Graham Perrin]

On 20/03/2020 01:24, Kyle Evans wrote:

On Thu, Mar 19, 2020 at 12:11 PM Graham Perrin  wrote:

Is this maybe related to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244847 or should I
make a separate bug report?


Please throw a tentative "Me too" on that PR; I'm investigating it,
then we'll see if they're related or requires yet another PR.


Locally built 5.2.34_1 not working on -CURRENT. Should I open a new bug?


grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
Tue 24 Mar 2020 10:49:01 GMT
FreeBSD 13.0-CURRENT #1 r359249: Tue Mar 24 00:12:27 GMT 2020 
root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

grahamperrin@momh167-gjp4-8570p:~ % virtualbox
Segmentation fault
grahamperrin@momh167-gjp4-8570p:~ % pkg query '%o %v %R' virtualbox-ose 
virtualbox-ose-kmod

emulators/virtualbox-ose 5.2.34_1 poudriere
emulators/virtualbox-ose-kmod 5.2.34 poudriere
grahamperrin@momh167-gjp4-8570p:~ % grep virtualbox /var/log/messages
Mar 22 21:22:40 momh167-gjp4-8570p pkg[26037]: virtualbox-ose-kmod 
reinstalled: 5.2.34 -> 5.2.34
Mar 22 21:23:05 momh167-gjp4-8570p pkg[26037]: virtualbox-ose 
reinstalled: 5.2.34_1 -> 5.2.34_1
Mar 23 01:38:52 momh167-gjp4-8570p pkg[77976]: virtualbox-ose 
reinstalled: 5.2.34_1 -> 5.2.34_1
Mar 23 05:03:36 momh167-gjp4-8570p pkg[52378]: virtualbox-ose 
reinstalled: 5.2.34_1 -> 5.2.34_1
Mar 23 15:44:12 momh167-gjp4-8570p pkg[27169]: virtualbox-ose 
reinstalled: 5.2.34_1 -> 5.2.34_1
Mar 24 08:19:51 momh167-gjp4-8570p pkg[49646]: virtualbox-ose 
reinstalled: 5.2.34_1 -> 5.2.34_1
grahamperrin@momh167-gjp4-8570p:~ % grep -v \# 
/usr/local/etc/poudriere.d/make.conf

WITHOUT_LLVM_TARGET_ALL=
MESA_LLVM_VER=${LLVM_DEFAULT}
grahamperrin@momh167-gjp4-8570p:~ %

_______
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: VirtualBox segmentation fault, FreeBSD-CURRENT r359068

[Kyle Evans]

On Thu, Mar 19, 2020 at 12:11 PM Graham Perrin  wrote:
>
> Is this maybe related to
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244847 or should I
> make a separate bug report?
>

Please throw a tentative "Me too" on that PR; I'm investigating it,
then we'll see if they're related or requires yet another PR.
_______
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: Running FreeBSD Current without performance penalties

[Ronald Klop]

On Sat, 26 Oct 2019 20:51:23 +0200, Brennan Vincent  
 wrote:



Hello,

Is there anything else that needs to be done besides building with  
`-DMALLOC_PRODUCTION` and `KERNCONF=GENERIC-NODEBUG` in order to build  
current and avoid any performance penalties due to debugging flags?


Nothing else needs to be done. This is it.

Please read the note "NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW:"  
in /usr/src/UPGRADING.
It does not mention GENERIC-NODEBUG, but that is the easy way to disable  
WITNESS, INVARIANTS, etc.


Regards,
Ronald.
_______
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"

Running FreeBSD Current without performance penalties

[Brennan Vincent]

Hello,

Is there anything else that needs to be done besides building with 
`-DMALLOC_PRODUCTION` and `KERNCONF=GENERIC-NODEBUG` in order to build 
current and avoid any performance penalties due to debugging flags?


___
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: freebsd-current Digest, Vol 832, Issue 4

[Miranda van den Breukelingen]

newly buildworld for 7 hours, couldn't be installed in headers/test from
single mode on and on a normal reboot ELF doesn't work when installing.
So reverted, revision is 353388 now kernel with VERBOSE_DEBUG=2 on.
Plasma comes to the point where the 'kstart5 plasmashell' should begin
to a "sudden death", having XFCE in reserve.





On 2019-10-10 14:00, freebsd-current-requ...@freebsd.org wrote:
> Send freebsd-current mailing list submissions to
>     freebsd-current@freebsd.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>     https://lists.freebsd.org/mailman/listinfo/freebsd-current
> or, via email, send a message with subject or body 'help' to
>     freebsd-current-requ...@freebsd.org
>
> You can reach the person managing the list at
>     freebsd-current-ow...@freebsd.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of freebsd-current digest..."
>
> Today's Topics:
>
>    1. Re: panic: Assertion in_epoch(net_epoch_preempt) failed at
>   ... src/sys/net/if.c:3694 (David Wolfskill)
>    2. 2 things; a cool crash log of my grandmother-laptop, that's
>   plasma's now bricked; vmn0 not X -configuring
>   (Miranda van den Breukelingen)
>    3. Re: 2 things; a cool crash log of my grandmother-laptop,
>   that's plasma's now bricked; vmn0 not X -configuring (David
Wolfskill)
>
> _______
> 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 buildworld in virtualbox guest crashes FreeBSD host

[Don Lewis]

Please forgive the crosspost, I don't know where the problem actually
belongs.

For the last several months I've had a problem where doing a buildworld
on FreeBSD CURRENT running as a virtualbox guest is crashing a the
FreeBSD current host.

This doesn't always happen, but there is a pattern.  The host in
question is primarily used for building packages sets with poudriere. If
I do a poudriere run, and after poudriere is finished, I start the
virtual box guest and do a buildworld there, this host will panic,
usually after an hour or so.  After I reboot the host and restart the
guest, the guest's UFS filesystem has some pretty severe damage, which
is not terribly unexpected.  I've never had the host panic under the
same circumstances if this host is freshly booted, though I did
experience a panic this morning during the subsequent installworld.  I'm
guessing that whether the panic happens or not depends on how much the
host memory map has been churned since boot.  According to top, there
are always around 5 GB of free memory when the crash occurs.

As mentioned, the problem has been happening with multiple revisions of
-CURRENT over the last several months, as well as multiple versions of
virtualbox.  This morning's crash happened with:
  FreeBSD zipper.catspoiler.org 13.0-CURRENT FreeBSD 13.0-CURRENT r352198 
GENERIC  amd64
  virtualbox-ose-5.2.32_1General-purpose full virtualizer for x86 
hardware
  virtualbox-ose-kmod-5.2.32_1   VirtualBox kernel module for FreeBSD

The CPU is:
CPU: AMD Ryzen 7 1700X Eight-Core Processor  (3393.72-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x800f11  Family=0x17  Model=0x1  Stepping=1
  Features=0x178bfbff
  Features2=0x7ed8320b
  AMD Features=0x2e500800
  AMD Features2=0x35c233ff
  Structured Extended Features=0x209c01a9
  XSAVE Features=0xf
  AMD Extended Feature Extensions ID EBX=0x1007
  SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
  TSC: P-state invariant, performance statistics

and the machine has 64 GB of ECC RAM.

The stack trace is wierd:

zipper.catspoiler.org dumped core - see /var/crash/vmcore.7

Fri Aug  9 18:03:07 PDT 2019

FreeBSD zipper.catspoiler.org 13.0-CURRENT FreeBSD 13.0-CURRENT r350665 GENERIC 
 amd64

panic: page fault

GNU gdb (GDB) 8.3 [GDB v8.3 for FreeBSD]
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd13.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...
Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 7; apic id = 07
fault virtual address   = 0xd45647000
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x82f81b35
stack pointer   = 0x28:0xfe01862681f0
frame pointer   = 0x28:0xfe0186268250
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 34192 (VirtualBox)
trap number = 12
panic: page fault
cpuid = 7
time = 1565393713
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0186267eb0
vpanic() at vpanic+0x19d/frame 0xfe0186267f00
panic() at panic+0x43/frame 0xfe0186267f60
trap_fatal() at trap_fatal+0x39c/frame 0xfe0186267fc0
trap_pfault() at trap_pfault+0x62/frame 0xfe0186268010
trap() at trap+0x2b4/frame 0xfe0186268120
calltrap() at calltrap+0x8/frame 0xfe0186268120
--- trap 0xc, rip = 0x82f81b35, rsp = 0xfe01862681f0, rbp = 
0xfe0186268250 ---
ng_ether_ifnet_arrival_cookie() at 0x82f81b35/frame 0xfe0186268250
ng_ether_ifnet_arrival_cookie() at 0x82f695c5/frame 0xfe01862682e0
ng_ether_ifnet_arrival_cookie() at 0x82f682fb/frame 0xfe0186268350
ng_ether_ifnet_arrival_cookie() at 0x82ec5f2c/frame 0xfe0186268380
ng_ether_ifnet_arrival_cookie() at 0x82ec461f/frame 0xfe0186268400
ng_ether_ifnet_arrival_cookie() at 0x82ec0ec3/frame 0xfe0186268490
ng_ether_ifnet_arrival_cookie() at 0x82f88a36/frame 0xfe0186268530
ng_ether_ifn

Re: Inability to build FreeBSD-current amd64

[Thomas Mueller]

from Niclas Zeising:


So now I wonder why I failed four times straight building current.  One 
definition of insanity is doing the same thing repeatedly and expecting a 
different result.

Maybe the build host, 11.1-STABLE from July 30, 2017, was too old?  I wouldn't 
have thought it was too old.

I could also try an old current host from August 2, 2017, or try to build 
12-STABLE from my 11.1-STABLE host.  Would I do better to build amd64 or i386 
from amd64 host?  I presently have no FreeBSD i386 installation, only amd64.

I can't quote anything from your message because of problems with mutt on 
xterm; this is NetBSD 8.99.39 amd64 with icewm.

But here is the relevant error message, I believe:

===> usr.bin/clang/llvm-mca (all)
Warning: Object directory not changed from original 
/usr/src/usr.bin/clang/llvm-mca
c++  -target x86_64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe 
-I/usr/src/contrib/llvm/tools/llvm-mca 
-I/usr/obj/usr/src/amd64.amd64/lib/clang/libllvm -I/usr/src/lib/clang/include 
-I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DDEFAULT_SYSROOT=\"\" 
-DLLVM_TARGET_ENABLE_AARCH64 -DLLVM_TARGET_ENABLE_ARM -DLLVM_TARGET_ENABLE_MIPS 
-DLLVM_TARGET_ENABLE_POWERPC -DLLVM_TARGET_ENABLE_SPARC 
-DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser 
-DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter 
-DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler 
-DLLVM_NATIVE_TARGET=LLVMInitializeX86Target 
-DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo 
-DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections 
-fdata-sections -g
 line-tables-only -MD -MF.depend.Views_DispatchStatistics.o 
-MTViews/DispatchStatistics.o -fstack-protector-strong -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  -fno-exceptions -fno-rtti -std=c++11 -stdlib=libc++ 
-Wno-c++11-extensions  -c 
/usr/src/contrib/llvm/tools/llvm-mca/Views/DispatchStatistics.cpp -o 
Views/DispatchStatistics.o
error: unable to open output file 'Views/DispatchStatistics.o': 'No such file 
or directory'
1 error generated.
*** Error code 1

I switched to the other computer with an installation of FreeBSD-current from 
August 2, 2017, and managed to succeed.

I had the same mergemaster problem cited in another thread, copied 
etc/master.passwd and etc/group from the 12-STABLE src tree.

That enabled me to successfully get through the update, but the result was a 
strong negative selling point for FreeBSD: no internet access.

Ethernet (re) would not connect, Hiro H50191 USB wi-fi adapter gave "Device not 
configured" as rsu0, and Edimax USB wi-fi adapter dropped the connection as I 
was trying the dhclient or ifconfig step.  Only other thing I could try is 
urndis with my mobile phone as access point.  I really ought to try that on 
FreeBSD and/or NetBSD.

I thought maybe the lack of etc/master.passwd and etc/group in src tree was a 
fault of subversion on NetBSD from pkgsrc as opposed to subversion on FreeBSD 
from ports, but browsing svnweb.freebsd.org/base/head revealed that 
master.passwd and group had indeed been moved, and mergemaster had not been 
appropriately updated.

Tom

___
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

[Niclas Zeising]

On 2019-05-16 09:36, Thomas Mueller wrote:

from Niclas Zeising:


I run a build WITH_CLANG_EXTRAS, and that worked, on current, last weekend, if
that's what you're asking about.
  

This won't take away the need for llvm ports in certain ports builds, however,
such as firefox and mesa.


So now I wonder why I failed four times straight building current.  One 
definition of insanity is doing the same thing repeatedly and expecting a 
different result.

Maybe the build host, 11.1-STABLE from July 30, 2017, was too old?  I wouldn't 
have thought it was too old.

I could also try an old current host from August 2, 2017, or try to build 
12-STABLE from my 11.1-STABLE host.  Would I do better to build amd64 or i386 
from amd64 host?  I presently have no FreeBSD i386 installation, only amd64.



That could be that the toolchain on 11.1 stable is too old to build 
current.  If you've posted the error you're getting, I've missed it, 
however.

Regards
--
Niclas
___________
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

[Thomas Mueller]

from Niclas Zeising:

> I run a build WITH_CLANG_EXTRAS, and that worked, on current, last weekend, if
> that's what you're asking about.
 
> This won't take away the need for llvm ports in certain ports builds, however,
> such as firefox and mesa.

So now I wonder why I failed four times straight building current.  One 
definition of insanity is doing the same thing repeatedly and expecting a 
different result.

Maybe the build host, 11.1-STABLE from July 30, 2017, was too old?  I wouldn't 
have thought it was too old.

I could also try an old current host from August 2, 2017, or try to build 
12-STABLE from my 11.1-STABLE host.  Would I do better to build amd64 or i386 
from amd64 host?  I presently have no FreeBSD i386 installation, only amd64.

Tom

_______
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

[Niclas Zeising]

On 2019-05-16 03:46, Thomas Mueller wrote:

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


I am not concerned about the time to build CLANG_EXTRAS so much as the 
possibility of CLANG_EXTRAS stopping the build.

WITH_CLANG_EXTRAS worked back in July-August 2017, but it may have ballooned 
since then beyond FreeBSD buildability.



I run a build WITH_CLANG_EXTRAS, and that worked, on current, last 
weekend, if that's what you're asking about.


This won't take away the need for llvm ports in certain ports builds, 
however, such as firefox and mesa.


Regards
--
Niclas
_______
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

[Thomas Mueller]

> 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  

I am not concerned about the time to build CLANG_EXTRAS so much as the 
possibility of CLANG_EXTRAS stopping the build.

WITH_CLANG_EXTRAS worked back in July-August 2017, but it may have ballooned 
since then beyond FreeBSD buildability.


Tom

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