Re: [RFC] Deprecation and removal of the drm2 driver

[blubee blubeeme]

On Fri, Jun 1, 2018, 07:42 Oliver Pinter 
wrote:

> On Friday, June 1, 2018, Pete Wright  wrote:
>
> >
> >
> > On 05/31/2018 15:34, Oliver Pinter wrote:
> >
> >> On Thursday, May 31, 2018, Johannes Lundberg 
> wrote:
> >>
> >> On Thu, May 31, 2018 at 4:34 PM Joe Maloney 
> >>> wrote:
> >>>
> >>> I personally wish that more drivers, and firmware were separated from
>  base.
> 
> 
>  I'm not a committer
> >>>
> >>
> >>
> >>> If you are not a committer,  how and why want to remove drm2 from the
> >> base
> >> system?
> >>
> > Johannes did not start this threat.  A committer, Niclas Zeising, did.
> > Johannes has stepped up and done a ton of work (along with many others,
> > some committers and some not) to get modern intel and amd GPU's working
> > under freebsd.
>
>
> >
> True. Yes I agree that their work is hard and it's a very big step forward
> for supporting modern hardwares. And it's required modern desktops, but
> please don't break the existing ones.

Agreed

This is my only request, probably it
> was expressed in a harsh way, sorry.
>
>
>
> >
> >
> > this was something that was a gaping hole in freebsd when this work
> > started a bit over a year ago, and i'm not sure why more committers
> weren't
> > embarrassed by this gap nor motivated to chip in.
> >
> > regardless - not sure why you'd take his comment out of context :/ the
> > full quote was:
> > "I'm not a committer but as I understand there's not pre-commit
> > integration tests.. If one had that, plus that it would test build kmod
> > ports against the pre-commit state of head as well, then maybe this would
> > work."
> >
> > not really sure what's controversial about that statement which would
> > prompt your reply - but i guess people dedicating their spare time to
> help
> > create useful things for others shouldn't go unpunished.
> >
> > well i guess i broke my promise to ignore this bikeshed :(
> >
> > -p
> >
> > --
> > Pete Wright
> > p...@nomadlogic.org
> > @nomadlogicLA
> >
> >
> ___
> freebsd-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: PR backlog (was: [RFC] Deprecation and removal of the drm2 driver)

[K. Macy]

>
> I wrote up a couple more paragraphs about why I think it happens and
> what we'd need to do to import more of that sense over into src.  But
> it was way longer than it needs to be.  We get a lot more man-hours in
> ports/ acting as conduits for the "outside patches -> svn" pipeline
> because the incentives are rigged.  A bad outside contribution brought
> into ports more often yields "hey, you should have noticed" to the
> committer and more opprobrium back to the submitter.  A bad outside
> contribution brought into src falls all over the commiter.
>
> Not entirely unreasonable, since a lot of even small-ish breakages in
> src are much bigger deals than even large-ish breakages in ports.  But
> it still makes it expensive to contemplate being a conduit...

Whereas the incentives in ports are structured such as to encourage
being a conduit and arguably it's a big part of being a responsible
porter, in src there is an active disincentive. A committer invites
substantial criticism by breaking src by importing a change but
invites no criticism for ignoring review requests or patches. There
are a few people who go through the pain of wading through patches and
committing them but as a general rule one has to have some level of
rapport with a proxy to get changes in without a bit. Whereas with
TrueOS the Git PR system lets one submit a change, the CI system
builds it to verify, and then it's thumbs up or thumbs down and it
goes in, undergoes further review / refinement, or is rejected
outright. There's something to be said for automation.

Submitting enhancements is even harder. There's always someone who
will be upset by a change in existing behavior, no matter how logical
a change may seem to the rest of us. This obvious change is almost 10
years old and seems completely common sense:

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

I've been keeping it in my bookmarks hoping that Eitan will commit it,
but may at some point overcome my reservations and just go ahead and
commit.

My problem with the bug system is classification. If a bug report
refers to something I touched recently, it's easy to assign it to me.
However, when I've tried wading through the bug system to find things
that I might be able to fix, I have not found it easy at all. This is
where culling older bug reports comes in. With a poor signal to noise
ratio from too many PRs, what really happens is _fewer_ things get
fixed, not more.

Cheers.
-M
___
freebsd-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: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

[Christopher Hall]

Hello Glen,

On Wed, 30 May 2018 15:50:39 +, Glen Barber  wrote:

> Hi,
> 
> Could folks please help boot-test the most recent 12.0-CURRENT amd64
> memstick images on various hardware?  Note, this is not a request to
> install 12.0-CURRENT, only a boot-test with various system knobs
> tweaked.
> 
> The most recent images are available at:
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img
> 
> We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we
> would like to get this included in the upcoming 11.2-RELEASE if the
> change that had been committed addresses several boot issues reported
> recently.
> 
> Please help test, and report back (both successes and failures).

on Thinkpad T420s mini image boots in both UEFI and Legacy modes, but
UEFI is considerably faster.

> 
> Thanks,
> 
> Glen
> 


-- 
Best Regards.
Christopher Hall.
___
freebsd-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: PR backlog (was: [RFC] Deprecation and removal of the drm2 driver)

[Matthew D. Fuller]

On Thu, May 31, 2018 at 03:49:46PM -0500 I heard the voice of
Mark Linimon, and lo! it spake thus:
> 
> We do slightly better turning over ports PRs -- due to the fact that
> we attach a maintainer field to each port.  This doesn't completely
> solve the problem, but it goes some distance.

>From my perspective as a maintainer of some and occasional contributor
to others, I think "slightly" undersells it a bit; hardly without
exception, but it generally works OK.

I wrote up a couple more paragraphs about why I think it happens and
what we'd need to do to import more of that sense over into src.  But
it was way longer than it needs to be.  We get a lot more man-hours in
ports/ acting as conduits for the "outside patches -> svn" pipeline
because the incentives are rigged.  A bad outside contribution brought
into ports more often yields "hey, you should have noticed" to the
committer and more opprobrium back to the submitter.  A bad outside
contribution brought into src falls all over the commiter.

Not entirely unreasonable, since a lot of even small-ish breakages in
src are much bigger deals than even large-ish breakages in ports.  But
it still makes it expensive to contemplate being a conduit...


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
freebsd-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: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

[Alan Somers]

On Wed, May 30, 2018 at 9:50 AM, Glen Barber  wrote:

> Hi,
>
> Could folks please help boot-test the most recent 12.0-CURRENT amd64
> memstick images on various hardware?  Note, this is not a request to
> install 12.0-CURRENT, only a boot-test with various system knobs
> tweaked.
>
> The most recent images are available at:
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-
> IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-
> IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img
>
> We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we
> would like to get this included in the upcoming 11.2-RELEASE if the
> change that had been committed addresses several boot issues reported
> recently.
>
> Please help test, and report back (both successes and failures).
>
> Thanks,
>
> Glen
>
>
No problems with a System76 Lemur in both UEFI and non-UEFI mode.  It's a
SkyLake-based system.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Deprecation and removal of the drm2 driver

[Oliver Pinter]

On Friday, June 1, 2018, Pete Wright  wrote:

>
>
> On 05/31/2018 15:34, Oliver Pinter wrote:
>
>> On Thursday, May 31, 2018, Johannes Lundberg  wrote:
>>
>> On Thu, May 31, 2018 at 4:34 PM Joe Maloney 
>>> wrote:
>>>
>>> I personally wish that more drivers, and firmware were separated from
 base.


 I'm not a committer
>>>
>>
>>
>>> If you are not a committer,  how and why want to remove drm2 from the
>> base
>> system?
>>
> Johannes did not start this threat.  A committer, Niclas Zeising, did.
> Johannes has stepped up and done a ton of work (along with many others,
> some committers and some not) to get modern intel and amd GPU's working
> under freebsd.


>
True. Yes I agree that their work is hard and it's a very big step forward
for supporting modern hardwares. And it's required modern desktops, but
please don't break the existing ones. This is my only request, probably it
was expressed in a harsh way, sorry.



>
>
> this was something that was a gaping hole in freebsd when this work
> started a bit over a year ago, and i'm not sure why more committers weren't
> embarrassed by this gap nor motivated to chip in.
>
> regardless - not sure why you'd take his comment out of context :/ the
> full quote was:
> "I'm not a committer but as I understand there's not pre-commit
> integration tests.. If one had that, plus that it would test build kmod
> ports against the pre-commit state of head as well, then maybe this would
> work."
>
> not really sure what's controversial about that statement which would
> prompt your reply - but i guess people dedicating their spare time to help
> create useful things for others shouldn't go unpunished.
>
> well i guess i broke my promise to ignore this bikeshed :(
>
> -p
>
> --
> Pete Wright
> p...@nomadlogic.org
> @nomadlogicLA
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Deprecation and removal of the drm2 driver

[Pete Wright]

On 05/31/2018 15:34, Oliver Pinter wrote:

On Thursday, May 31, 2018, Johannes Lundberg  wrote:


On Thu, May 31, 2018 at 4:34 PM Joe Maloney 
wrote:


I personally wish that more drivers, and firmware were separated from
base.



I'm not a committer





If you are not a committer,  how and why want to remove drm2 from the base
system?
Johannes did not start this threat.  A committer, Niclas Zeising, did.  
Johannes has stepped up and done a ton of work (along with many others, 
some committers and some not) to get modern intel and amd GPU's working 
under freebsd.  this was something that was a gaping hole in freebsd 
when this work started a bit over a year ago, and i'm not sure why more 
committers weren't embarrassed by this gap nor motivated to chip in.


regardless - not sure why you'd take his comment out of context :/ the 
full quote was:
"I'm not a committer but as I understand there's not pre-commit 
integration tests.. If one had that, plus that it would test build kmod 
ports against the pre-commit state of head as well, then maybe this 
would work."


not really sure what's controversial about that statement which would 
prompt your reply - but i guess people dedicating their spare time to 
help create useful things for others shouldn't go unpunished.


well i guess i broke my promise to ignore this bikeshed :(

-p

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

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

Re: [RFC] Deprecation and removal of the drm2 driver

[Oliver Pinter]

On Thursday, May 31, 2018, Johannes Lundberg  wrote:

> On Thu, May 31, 2018 at 4:34 PM Joe Maloney 
> wrote:
>
> > I personally wish that more drivers, and firmware were separated from
> > base.
> >
> >
> I'm not a committer


>
>
If you are not a committer,  how and why want to remove drm2 from the base
system?

>From other side, how you want to maintain VM and other KPI changes in
unmaintained and abandoned port? ;) Or how you can guarantee to everyone
who breaks KPI to follow these breaks in an external abandoned port?


>
> but as I understand there's not pre-commit integration
> tests.. If one had that, plus that it would test build kmod ports against
> the pre-commit state of head as well, then maybe this would work.
>
>
> > For example wireless firmware:
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433
> >
> > That was a ticket which I chimed in on about a firmware I needed to make
> > my wireless adapter work.  I went through numerous efforts on IRC, and
> > elsewhere to try to bring attention that ticket in order to attempt to
> get
> > that firmware backported for several 10.x releases in a row without
> > success.  The firmware worked perfectly fine in PC-BSD where it was
> cherry
> > picked for numerous 10.x releases.
> >
> > Technically since I was using PC-BSD, and was a committer for that
> project
> > I had no real dire need to reach out to FreeBSD about the issue.  I was
> > simply trying to help anyone else who might be encountering the same
> issue
> > trying to use stock FreeBSD because it was a simple backport.  If my
> effort
> > had turned out to be more fruitful I would have spent more time pursuing
> > tickets, diffs, or whatever to get more things back-ported when I found
> > them.  I am not sure where the breakdown was which did not allow that to
> > happen.  Anyways I don't want to bikeshed, or anything but I just wanted
> to
> > point out how I think having more drivers, and firmware in ports could be
> > helpful to enhance compatibility for end users.
> >
> > Having a separate port for legacy drm could definitely make things easier
> > to providing installation options for end users, and automating the post
> > install action chosen in TrueOS, GhostBSD, and future derivative projects
> > tailored for the desktop use case.  For example for TrueOS we boot the
> > installer in failsafe mode with either VESA, or SCFB depending on whether
> > or not BIOS, or EFI is booted.  Then we could simply make a checkbox for
> > legacy intel, or skylake + to install the correct package then the module
> > path for either driver can more or less remain the same.  Eventually with
> > something like devmatch maybe that can even be fully automatic.
> >
> > Joe Maloney
> >
> > On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen 
> > wrote:
> >
> >> On Thu, 31 May 2018, Konstantin Belousov wrote:
> >>
> >> On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:
> >>>
> >>> We're not replacing anything. We are moving the older drm1 and drm2
> from
>  kernel to ports to make it easier for the majority of the users to
> load
>  the
>  correct driver without conflicts.
> 
> >>>
> >>> You do understand that you increase your maintainence load by this
> move.
> >>> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in
> stable
> >>> branches, so you will need to chase these updates.
> >>>
> >>
> >> I agree.  One argument previously made was that it's easier
> >> to maintain in ports.  One data point from me - I rarely
> >> update my ports, I update my OS much more frequently.  In
> >> fact, some times my ports get so out of date I just
> >> (take off and) nuke /usr/local (from orbit, it's the only
> >> way to be sure).
> >>
> >> Also, are we trying to solve a problem by moving drm[2] to
> >> ports that won't be a problem when base is pkg'ized?  If
> >> drm[2] is a package unto itself, then you don't have this
> >> problem of ports conflicting with it, at least not so
> >> much.  You can either not install the base drm[2] package
> >> or deinstall it to make way for a conflicting port.  Once
> >> drm[2] is pkg rm'd, it's not going to be reinstalled
> >> again when you update the base OS.
> >>
> >> And don't we have the same problem with sendmail and a
> >> few other base services?
> >>
> >> --
> >> DE
> >>
> >> ___
> >> freebsd-current@freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org
> >> "
> >>
> >
> >
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To 

Re: ``make buildkernel'' fails when /usr/obj is empty

[Shane Ambler]

On 01/06/2018 03:41, Warner Losh wrote:
> On Thu, May 31, 2018 at 11:47 AM, Dimitry Andric  wrote:
> 
>> On 31 May 2018, at 18:04, Benjamin Kaduk  wrote:
>>>
>>> On Thu, May 31, 2018 at 09:58:50AM +0200, Gary Jennejohn wrote:
 On Thu, 31 May 2018 09:52:22 +0200
 Gary Jennejohn  wrote:

> There's something totally screwy about trying to build a kernel when
> /usr/obj is not populated.
>
> I ran ``make clean'' in /usr/src and then ``make buildkernel''.  This
> fails with
> make[2]: "/usr/src/sys/conf/kern.pre.mk" line 125: amd64 kernel
> requires linker ifunc support
>
> This is total BS because
>
> /usr/bin/ld --version
> LLD 6.0.0 (FreeBSD 326565-122) (compatible with GNU linkers)
>
> which is exactly what bsd.linker.mk is looking for to set ifunc.
>
> If I do this:
>
> mkdir -p /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin
> cp /usr/bin/ld /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin
>
> the buildkernel then succeeds.
>
> Considering that (reformatted output from make)
>
> PATH=/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:
> /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:
> /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin:
> /sbin:/bin:/usr/sbin:/usr/bin
>
> it seems like /usr/bin/ld should be found by bsd.linker.mk and no
> error should be reported.
>

 OK, it seems that ``make clean'' does not remove the contents of
 /usr/obj/usr/src/amd64.amd64/tmp/legacy.  If I delete everything
 under /usr/obj then ``make buildkernel'' works.

 Still, it seems pretty strange to me to make building a kernel
 depend on some random junk which is left laying around under
 /usr/obj.
>>>
>>> Whatever happened to the "run buildworld or kernel-toolchain before
>>> buildkernel" requirement?
>>
>> That is still a requirement, yes.  Otherwise, you might have outdated
>> toolchain components are in your /usr/obj.
>>
> 
> Usually you can get away without doing that, and now that clang is the
> toolchain that's rebuilt (and that's not fast) people try to get away with
> it more and more...

There is WITH_SYSTEM_COMPILER to not bootstrap if possible.


-- 
FreeBSD - the place to B...Software Developing

Shane Ambler

___
freebsd-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: PR backlog (was: [RFC] Deprecation and removal of the drm2 driver)

[Mark Linimon]

Straying off-topic from the Subject line ...

On Thu, May 31, 2018 at 11:34:18AM -0400, Joe Maloney wrote:
> Technically since I was using PC-BSD, and was a committer for that
> project I had no real dire need to reach out to FreeBSD about the
> [wireless driver issue].  I was simply trying to help anyone else
> who might be encountering the same issue trying to use stock FreeBSD
> because it was a simple backport.  If my effort had turned out to be
> more fruitful I would have spent more time pursuing tickets, diffs,
> or whatever to get more things back-ported when I found them.

FreeBSD doesn't do well handling problem reports.  We've known it for
years but no one has come up with a magic solution yet.

We have volunteers willing to triage, but not enough committers willing
to suspend working on their own priorities to work through the backlog.
(It's understandable, really.)

And the backlog is astounding. (*)

I hesitate to even look, but ...

  kern   3270
  ports  2010
  bin1607

The flow has decreased from where it was a few years ago -- this stat
says that 727 total new ones have come in this month.

We do slightly better turning over ports PRs -- due to the fact that
we attach a maintainer field to each port.  This doesn't completely
solve the problem, but it goes some distance.

Finally, the number of PRs with patches stands around 1021.  That is
particularly disappointing.

Well, it's too bad we weren't able to corral you into keeping working
on such things.  fwiw.

mcl

*: there are other categories but these constitute the majority (9485
in total).
___
freebsd-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: hwpmc - wither ppro and p4

[Steve Kargl]

On Thu, May 31, 2018 at 03:23:56PM -0500, Mark Linimon wrote:
> On Thu, May 31, 2018 at 12:58:23PM -0700, Steve Kargl wrote:
> > On Thu, May 31, 2018 at 11:08:18AM -0700, Matthew Macy wrote:
> > > 
> > > Based on the i386 discussion I recognize that there's a great deal of
> > > sentimental attachment to older hardware. However, there's very few
> > 
> > s/sentimental/practical
> 
> I know, but ... in this special case of _performance measurement_ code
> on old hardware, I'm going to have to agree with Matt.
> 

I did not state that a I disagree or agree with Matt's
proposed removal of support for pmc on old hardware.
I simply corrected his unwarranted passive aggressive
comment.

-- 
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: hwpmc - wither ppro and p4

[Mark Linimon]

On Thu, May 31, 2018 at 12:58:23PM -0700, Steve Kargl wrote:
> On Thu, May 31, 2018 at 11:08:18AM -0700, Matthew Macy wrote:
> > 
> > Based on the i386 discussion I recognize that there's a great deal of
> > sentimental attachment to older hardware. However, there's very few
> 
> s/sentimental/practical

I know, but ... in this special case of _performance measurement_ code
on old hardware, I'm going to have to agree with Matt.

mcl
___
freebsd-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: hwpmc - wither ppro and p4

[Steve Kargl]

On Thu, May 31, 2018 at 11:08:18AM -0700, Matthew Macy wrote:
> 
> Based on the i386 discussion I recognize that there's a great deal of
> sentimental attachment to older hardware. However, there's very few

s/sentimental/practical

-- 
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: ``make buildkernel'' fails when /usr/obj is empty

[Konstantin Belousov]

On Thu, May 31, 2018 at 08:19:20PM +0200, Dimitry Andric wrote:
> On 31 May 2018, at 20:11, Warner Losh  wrote:
> > 
> > On Thu, May 31, 2018 at 11:47 AM, Dimitry Andric  wrote:
> > On 31 May 2018, at 18:04, Benjamin Kaduk  wrote:
> > > On Thu, May 31, 2018 at 09:58:50AM +0200, Gary Jennejohn wrote:
> > >> On Thu, 31 May 2018 09:52:22 +0200
> > >> Gary Jennejohn  wrote:
> ...
> > > Whatever happened to the "run buildworld or kernel-toolchain before
> > > buildkernel" requirement?
> > 
> > That is still a requirement, yes.  Otherwise, you might have outdated
> > toolchain components are in your /usr/obj.
> > 
> > Usually you can get away without doing that, and now that clang is the 
> > toolchain that's rebuilt (and that's not fast) people try to get away with 
> > it more and more...
> 
> Actually clang doesn't get updated *that* often, but there is a minor
> snag that one of llvm's config files (lib/clang/include/llvm/Config/config.h)
> includes , so each time __FreeBSD_version is bumped, quite
> a lot of dependencies get triggered...
> 
> The version is only used for two checks:
> 
> #if __FreeBSD_version >= 152
> /* Define to 1 if you have the `backtrace' function. */
> #define HAVE_BACKTRACE TRUE
> 
> and:
> 
> /* Define to 1 if you have the `futimens' function. */
> #if __FreeBSD_version >= 1100056
> #define HAVE_FUTIMENS 1
> #endif
> 
> Maybe the first check could be dropped, assuming that backtrace() is
> always available, but I'm not sure about futimens().  Is there any
> supported version of FreeBSD left that does *not* have it?
Or you can manually define the symbols as needed on each branch,
eliminating the need for osreldate.h and reusable if some other
configuration variable needs to be conditionally set.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ``make buildkernel'' fails when /usr/obj is empty

[Dimitry Andric]

On 31 May 2018, at 20:11, Warner Losh  wrote:
> 
> On Thu, May 31, 2018 at 11:47 AM, Dimitry Andric  wrote:
> On 31 May 2018, at 18:04, Benjamin Kaduk  wrote:
> > On Thu, May 31, 2018 at 09:58:50AM +0200, Gary Jennejohn wrote:
> >> On Thu, 31 May 2018 09:52:22 +0200
> >> Gary Jennejohn  wrote:
...
> > Whatever happened to the "run buildworld or kernel-toolchain before
> > buildkernel" requirement?
> 
> That is still a requirement, yes.  Otherwise, you might have outdated
> toolchain components are in your /usr/obj.
> 
> Usually you can get away without doing that, and now that clang is the 
> toolchain that's rebuilt (and that's not fast) people try to get away with it 
> more and more...

Actually clang doesn't get updated *that* often, but there is a minor
snag that one of llvm's config files (lib/clang/include/llvm/Config/config.h)
includes , so each time __FreeBSD_version is bumped, quite
a lot of dependencies get triggered...

The version is only used for two checks:

#if __FreeBSD_version >= 152
/* Define to 1 if you have the `backtrace' function. */
#define HAVE_BACKTRACE TRUE

and:

/* Define to 1 if you have the `futimens' function. */
#if __FreeBSD_version >= 1100056
#define HAVE_FUTIMENS 1
#endif

Maybe the first check could be dropped, assuming that backtrace() is
always available, but I'm not sure about futimens().  Is there any
supported version of FreeBSD left that does *not* have it?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: ``make buildkernel'' fails when /usr/obj is empty

[Warner Losh]

On Thu, May 31, 2018 at 11:47 AM, Dimitry Andric  wrote:

> On 31 May 2018, at 18:04, Benjamin Kaduk  wrote:
> >
> > On Thu, May 31, 2018 at 09:58:50AM +0200, Gary Jennejohn wrote:
> >> On Thu, 31 May 2018 09:52:22 +0200
> >> Gary Jennejohn  wrote:
> >>
> >>> There's something totally screwy about trying to build a kernel when
> >>> /usr/obj is not populated.
> >>>
> >>> I ran ``make clean'' in /usr/src and then ``make buildkernel''.  This
> >>> fails with
> >>> make[2]: "/usr/src/sys/conf/kern.pre.mk" line 125: amd64 kernel
> >>> requires linker ifunc support
> >>>
> >>> This is total BS because
> >>>
> >>> /usr/bin/ld --version
> >>> LLD 6.0.0 (FreeBSD 326565-122) (compatible with GNU linkers)
> >>>
> >>> which is exactly what bsd.linker.mk is looking for to set ifunc.
> >>>
> >>> If I do this:
> >>>
> >>> mkdir -p /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin
> >>> cp /usr/bin/ld /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin
> >>>
> >>> the buildkernel then succeeds.
> >>>
> >>> Considering that (reformatted output from make)
> >>>
> >>> PATH=/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:
> >>> /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:
> >>> /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:
> >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:
> >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin:
> >>> /sbin:/bin:/usr/sbin:/usr/bin
> >>>
> >>> it seems like /usr/bin/ld should be found by bsd.linker.mk and no
> >>> error should be reported.
> >>>
> >>
> >> OK, it seems that ``make clean'' does not remove the contents of
> >> /usr/obj/usr/src/amd64.amd64/tmp/legacy.  If I delete everything
> >> under /usr/obj then ``make buildkernel'' works.
> >>
> >> Still, it seems pretty strange to me to make building a kernel
> >> depend on some random junk which is left laying around under
> >> /usr/obj.
> >
> > Whatever happened to the "run buildworld or kernel-toolchain before
> > buildkernel" requirement?
>
> That is still a requirement, yes.  Otherwise, you might have outdated
> toolchain components are in your /usr/obj.
>

Usually you can get away without doing that, and now that clang is the
toolchain that's rebuilt (and that's not fast) people try to get away with
it more and more...

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"

hwpmc - wither ppro and p4

[Matthew Macy]

Intel now provides comprehensive tables for all performance counters
and the various valid configuration permutations as text .json files.
I've converted libpmc to use these and simplified the hwpmc_core to
pass the values through. I'd like to remove all the existing Intel
tables from the kernel. The one gotcha is that they don't support
pentium pro and and pentium IV.

Based on the i386 discussion I recognize that there's a great deal of
sentimental attachment to older hardware. However, there's very few
users of hwpmc on _amd64_ kernels on new hardware. I don't think
anyone is doing low level optimization on 15 year old Intel hardware.

I'm going to remove all the tables and the now unsupported p4 and ppro
configuration bits in the kmod. However, if someone feels strongly
enough to implement the corresponding tables for p4 and ppro I will
reinstate the files in to the build.

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

Re: [RFC] Deprecation and removal of the drm2 driver

[Johannes Lundberg]

On Thu, May 31, 2018 at 4:34 PM Joe Maloney  wrote:

> I personally wish that more drivers, and firmware were separated from
> base.
>
>
I'm not a committer but as I understand there's not pre-commit integration
tests.. If one had that, plus that it would test build kmod ports against
the pre-commit state of head as well, then maybe this would work.


> For example wireless firmware:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433
>
> That was a ticket which I chimed in on about a firmware I needed to make
> my wireless adapter work.  I went through numerous efforts on IRC, and
> elsewhere to try to bring attention that ticket in order to attempt to get
> that firmware backported for several 10.x releases in a row without
> success.  The firmware worked perfectly fine in PC-BSD where it was cherry
> picked for numerous 10.x releases.
>
> Technically since I was using PC-BSD, and was a committer for that project
> I had no real dire need to reach out to FreeBSD about the issue.  I was
> simply trying to help anyone else who might be encountering the same issue
> trying to use stock FreeBSD because it was a simple backport.  If my effort
> had turned out to be more fruitful I would have spent more time pursuing
> tickets, diffs, or whatever to get more things back-ported when I found
> them.  I am not sure where the breakdown was which did not allow that to
> happen.  Anyways I don't want to bikeshed, or anything but I just wanted to
> point out how I think having more drivers, and firmware in ports could be
> helpful to enhance compatibility for end users.
>
> Having a separate port for legacy drm could definitely make things easier
> to providing installation options for end users, and automating the post
> install action chosen in TrueOS, GhostBSD, and future derivative projects
> tailored for the desktop use case.  For example for TrueOS we boot the
> installer in failsafe mode with either VESA, or SCFB depending on whether
> or not BIOS, or EFI is booted.  Then we could simply make a checkbox for
> legacy intel, or skylake + to install the correct package then the module
> path for either driver can more or less remain the same.  Eventually with
> something like devmatch maybe that can even be fully automatic.
>
> Joe Maloney
>
> On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen 
> wrote:
>
>> On Thu, 31 May 2018, Konstantin Belousov wrote:
>>
>> On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:
>>>
>>> We're not replacing anything. We are moving the older drm1 and drm2 from
 kernel to ports to make it easier for the majority of the users to load
 the
 correct driver without conflicts.

>>>
>>> You do understand that you increase your maintainence load by this move.
>>> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in stable
>>> branches, so you will need to chase these updates.
>>>
>>
>> I agree.  One argument previously made was that it's easier
>> to maintain in ports.  One data point from me - I rarely
>> update my ports, I update my OS much more frequently.  In
>> fact, some times my ports get so out of date I just
>> (take off and) nuke /usr/local (from orbit, it's the only
>> way to be sure).
>>
>> Also, are we trying to solve a problem by moving drm[2] to
>> ports that won't be a problem when base is pkg'ized?  If
>> drm[2] is a package unto itself, then you don't have this
>> problem of ports conflicting with it, at least not so
>> much.  You can either not install the base drm[2] package
>> or deinstall it to make way for a conflicting port.  Once
>> drm[2] is pkg rm'd, it's not going to be reinstalled
>> again when you update the base OS.
>>
>> And don't we have the same problem with sendmail and a
>> few other base services?
>>
>> --
>> DE
>>
>> ___
>> freebsd-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: ``make buildkernel'' fails when /usr/obj is empty

[Dimitry Andric]

On 31 May 2018, at 18:04, Benjamin Kaduk  wrote:
> 
> On Thu, May 31, 2018 at 09:58:50AM +0200, Gary Jennejohn wrote:
>> On Thu, 31 May 2018 09:52:22 +0200
>> Gary Jennejohn  wrote:
>> 
>>> There's something totally screwy about trying to build a kernel when
>>> /usr/obj is not populated.
>>> 
>>> I ran ``make clean'' in /usr/src and then ``make buildkernel''.  This
>>> fails with
>>> make[2]: "/usr/src/sys/conf/kern.pre.mk" line 125: amd64 kernel
>>> requires linker ifunc support
>>> 
>>> This is total BS because
>>> 
>>> /usr/bin/ld --version
>>> LLD 6.0.0 (FreeBSD 326565-122) (compatible with GNU linkers)
>>> 
>>> which is exactly what bsd.linker.mk is looking for to set ifunc.
>>> 
>>> If I do this:
>>> 
>>> mkdir -p /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin
>>> cp /usr/bin/ld /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin
>>> 
>>> the buildkernel then succeeds.
>>> 
>>> Considering that (reformatted output from make)
>>> 
>>> PATH=/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:
>>> /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:
>>> /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:
>>> /usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:
>>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin:
>>> /sbin:/bin:/usr/sbin:/usr/bin
>>> 
>>> it seems like /usr/bin/ld should be found by bsd.linker.mk and no
>>> error should be reported.
>>> 
>> 
>> OK, it seems that ``make clean'' does not remove the contents of
>> /usr/obj/usr/src/amd64.amd64/tmp/legacy.  If I delete everything
>> under /usr/obj then ``make buildkernel'' works.
>> 
>> Still, it seems pretty strange to me to make building a kernel
>> depend on some random junk which is left laying around under
>> /usr/obj.
> 
> Whatever happened to the "run buildworld or kernel-toolchain before
> buildkernel" requirement?

That is still a requirement, yes.  Otherwise, you might have outdated
toolchain components are in your /usr/obj.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: [RFC] Deprecation and removal of the drm2 driver

[Jeffrey Bouquet]

On Thu, 31 May 2018 18:02:26 +0200, "Ronald Klop"  wrote:

> On Thu, 31 May 2018 17:34:18 +0200, Joe Maloney   
> wrote:
> 
> > I personally wish that more drivers, and firmware were separated from
> > base.
> >
> > For example wireless firmware:
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433
> >
> > That was a ticket which I chimed in on about a firmware I needed to make  
> > my
> > wireless adapter work.  I went through numerous efforts on IRC, and
> > elsewhere to try to bring attention that ticket in order to attempt to  
> > get
> > that firmware backported for several 10.x releases in a row without
> > success.  The firmware worked perfectly fine in PC-BSD where it was  
> > cherry
> > picked for numerous 10.x releases.
> 
> 
> I would support an idea that the FreeBSD project only delivers CURRENT  
> (and one periodic release with security fixes) and parties like PC-BSD  
> maintain stable branches and support for companies.
> 
> I read about this somewhere a while ago and the idea sticks. Backporting  
> to code 2+ years old is not the best use of human volunteer resources IMHO.
> 
> Regards,
> Ronald.
> 
> 
> 
> >
> > Technically since I was using PC-BSD, and was a committer for that  
> > project
> > I had no real dire need to reach out to FreeBSD about the issue.  I was
> > simply trying to help anyone else who might be encountering the same  
> > issue
> > trying to use stock FreeBSD because it was a simple backport.  If my  
> > effort
> > had turned out to be more fruitful I would have spent more time pursuing
> > tickets, diffs, or whatever to get more things back-ported when I found
> > them.  I am not sure where the breakdown was which did not allow that to
> > happen.  Anyways I don't want to bikeshed, or anything but I just wanted  
> > to
> > point out how I think having more drivers, and firmware in ports could be
> > helpful to enhance compatibility for end users.
> >
> > Having a separate port for legacy drm could definitely make things easier
> > to providing installation options for end users, and automating the post
> > install action chosen in TrueOS, GhostBSD, and future derivative projects
> > tailored for the desktop use case.  For example for TrueOS we boot the
> > installer in failsafe mode with either VESA, or SCFB depending on whether
> > or not BIOS, or EFI is booted.  Then we could simply make a checkbox for
> > legacy intel, or skylake + to install the correct package then the module
> > path for either driver can more or less remain the same.  Eventually with
> > something like devmatch maybe that can even be fully automatic.
> >
> > Joe Maloney
> >
> > On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen 
> > wrote:
> >
> >> On Thu, 31 May 2018, Konstantin Belousov wrote:
> >>
> >> On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:
> >>>
> >>> We're not replacing anything. We are moving the older drm1 and drm2  
> >>> from
>  kernel to ports to make it easier for the majority of the users to  
>  load
>  the
>  correct driver without conflicts.
> 
> >>>
> >>> You do understand that you increase your maintainence load by this  
> >>> move.
> >>> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in  
> >>> stable
> >>> branches, so you will need to chase these updates.
> >>>
> >>
> >> I agree.  One argument previously made was that it's easier
> >> to maintain in ports.  One data point from me - I rarely
> >> update my ports, I update my OS much more frequently.  In
> >> fact, some times my ports get so out of date I just
> >> (take off and) nuke /usr/local (from orbit, it's the only
> >> way to be sure).
> >>
> >> Also, are we trying to solve a problem by moving drm[2] to
> >> ports that won't be a problem when base is pkg'ized?  If
> >> drm[2] is a package unto itself, then you don't have this
> >> problem of ports conflicting with it, at least not so
> >> much.  You can either not install the base drm[2] package
> >> or deinstall it to make way for a conflicting port.  Once
> >> drm[2] is pkg rm'd, it's not going to be reinstalled
> >> again when you update the base OS.
> >>
> >> And don't we have the same problem with sendmail and a
> >> few other base services?
> >>
> >> --
> >> DE
> >>
> >> ___
> >> freebsd-current@freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> To unsubscribe, send any mail to  
> >> "freebsd-current-unsubscr...@freebsd.org"
> >>
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to  
> > "freebsd-current-unsubscr...@freebsd.org"
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 

Re: [RFC] Deprecation and removal of the drm2 driver

[Niclas Zeising]

On 05/31/18 16:21, Rodney W. Grimes wrote:


I do remeber for a long time this
was a -current only modules, is that still true, or can I
load it on 11.0, 11.1 and 11.2Beta3 now?


drm-stable-kmod works on 11.2 (including the betas) and later.  We can't 
backport the needed changes to the lkpi to the releases, for obvious 
reasons, but they were backported some time between 11.1 and now.

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: ``make buildkernel'' fails when /usr/obj is empty

[Benjamin Kaduk]

On Thu, May 31, 2018 at 09:58:50AM +0200, Gary Jennejohn wrote:
> On Thu, 31 May 2018 09:52:22 +0200
> Gary Jennejohn  wrote:
> 
> > There's something totally screwy about trying to build a kernel when
> > /usr/obj is not populated.
> > 
> > I ran ``make clean'' in /usr/src and then ``make buildkernel''.  This
> > fails with
> > make[2]: "/usr/src/sys/conf/kern.pre.mk" line 125: amd64 kernel
> > requires linker ifunc support
> > 
> > This is total BS because
> > 
> > /usr/bin/ld --version
> > LLD 6.0.0 (FreeBSD 326565-122) (compatible with GNU linkers)
> > 
> > which is exactly what bsd.linker.mk is looking for to set ifunc.
> > 
> > If I do this:
> > 
> > mkdir -p /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin
> > cp /usr/bin/ld /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin
> > 
> > the buildkernel then succeeds.
> > 
> > Considering that (reformatted output from make)
> > 
> > PATH=/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:
> > /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:
> > /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:
> > /usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:
> > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin:
> > /sbin:/bin:/usr/sbin:/usr/bin
> > 
> > it seems like /usr/bin/ld should be found by bsd.linker.mk and no
> > error should be reported.
> > 
> 
> OK, it seems that ``make clean'' does not remove the contents of
> /usr/obj/usr/src/amd64.amd64/tmp/legacy.  If I delete everything
> under /usr/obj then ``make buildkernel'' works.
> 
> Still, it seems pretty strange to me to make building a kernel
> depend on some random junk which is left laying around under
> /usr/obj.

Whatever happened to the "run buildworld or kernel-toolchain before
buildkernel" requirement?

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

Fwd: panic: Assertion td->td_lock == TDQ_LOCKPTR(tdq) failed at /usr/src/sys/kern/sched_ule.c:2137

[Ronald Klop]

cross-post to -current to get more feedback

--- Forwarded message ---
From: "Ronald Klop" 
To: freebsd-...@freebsd.org
Cc:
Subject: panic: Assertion td->td_lock == TDQ_LOCKPTR(tdq) failed at  
/usr/src/sys/kern/sched_ule.c:2137

Date: Thu, 31 May 2018 17:53:12 +0200

I had a crash on mu RPI-3B+ running freebsd 12/aarch64 from the 29 may
snapshot.
It was building world -j4 and portsnap extract.

I will keep it in the debugger for about an hour so if I need to provide
more information, please mail me.


db> show panic
panic: Assertion td->td_lock == TDQ_LOCKPTR(tdq) failed at
/usr/src/sys/kern/sched_ule.c:2137

db> bt
Tracing pid 20 tid 100063 td 0xfd00014fe000
db_trace_self() at db_stack_trace+0xf0
   pc = 0x006680f4  lr = 0x000d8b18
   sp = 0x53972e10  fp = 0x53972e40

db_stack_trace() at db_command+0x220
   pc = 0x000d8b18  lr = 0x000d879c
   sp = 0x53972e50  fp = 0x53972f30

db_command() at db_command_loop+0x60
   pc = 0x000d879c  lr = 0x000d8560
   sp = 0x53972f40  fp = 0x53972f60

db_command_loop() at db_trap+0xf4
   pc = 0x000d8560  lr = 0x000db678
   sp = 0x53972f70  fp = 0x53973190

db_trap() at kdb_trap+0x1d8
   pc = 0x000db678  lr = 0x003beca0
   sp = 0x539731a0  fp = 0x53973250

kdb_trap() at do_el1h_sync+0xf0
   pc = 0x003beca0  lr = 0x00683094
   sp = 0x53973260  fp = 0x53973290

do_el1h_sync() at handle_el1h_sync+0x74
   pc = 0x00683094  lr = 0x0066a074
   sp = 0x539732a0  fp = 0x539733b0

handle_el1h_sync() at kdb_enter+0x34
   pc = 0x0066a074  lr = 0x003be34c
   sp = 0x539733c0  fp = 0x53973450

kdb_enter() at vpanic+0x1c4
   pc = 0x003be34c  lr = 0x0037a3a4
   sp = 0x53973460  fp = 0x53973510

vpanic() at kassert_panic+0x1bc
   pc = 0x0037a3a4  lr = 0x0037a134
   sp = 0x53973520  fp = 0x539735d0

kassert_panic() at sched_switch+0x994
   pc = 0x0037a134  lr = 0x003a3d1c
   sp = 0x539735e0  fp = 0x539736c0

sched_switch() at mi_switch+0x1a0
   pc = 0x003a3d1c  lr = 0x00385044
   sp = 0x539736d0  fp = 0x539736f0

mi_switch() at uma_reclaim_locked+0x1cc
   pc = 0x00385044  lr = 0x006169b4
   sp = 0x53973700  fp = 0x53973750

uma_reclaim_locked() at uma_reclaim+0x34
   pc = 0x006169b4  lr = 0x006167cc
   sp = 0x53973760  fp = 0x53973770

uma_reclaim() at vm_pageout_worker+0x3e8
   pc = 0x006167cc  lr = 0x00636d08
   sp = 0x53973780  fp = 0x53973b10

vm_pageout_worker() at vm_pageout+0x140
   pc = 0x00636d08  lr = 0x00635b58
   sp = 0x53973b20  fp = 0x53973b50

vm_pageout() at fork_exit+0x7c
   pc = 0x00635b58  lr = 0x0033bb14
   sp = 0x53973b60  fp = 0x53973b90

fork_exit() at fork_trampoline+0x10
   pc = 0x0033bb14  lr = 0x00682e14
   sp = 0x53973ba0  fp = 0x



Accidently I had this in a xterm: (da4s1b is the label/usbswap)

dT: 1.008s  w: 1.000s
   L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/w   %busy Name
 18  1  0  00.0  1 32  430.5   42.7| mmcsd0
  0  0  0  00.0  0  00.00.0| da0
  0  0  0  00.0  0  00.00.0| mmcsd0s1
 18  1  0  00.0  1 32  430.5   42.7| mmcsd0s2
  0  0  0  00.0  0  00.00.0|
msdosfs/MSDOSBOOT
 18  1  0  00.0  1 32  430.5   42.7| mmcsd0s2a
 18  1  0  00.0  1 32  430.6   42.7| ufs/rootfs
  0  0  0  00.0  0  00.00.0| da1
  0  0  0  00.0  0  00.00.0| da2
  0  0  0  00.0  0  00.00.0| da3
  6315  5 52  963.9310   2158   11.6   92.6| da4
  0  0  0  00.0  0  00.00.0| da2s1
  0  0  0  00.0  0  00.00.0| da2s2
  6314  5 52  963.9309   2158   11.6   92.6| da4s1
  0  0  0  00.0  0  00.00.0| da2s2a
  1  0  0  00.0  0  00.00.0| da4s1a
  5314  5 52  963.9309   2158   11.6   92.6| da4s1b
  0  0  0  00.0  0  00.00.0|
ufs/oldsdrootfs
  1  0  0 

Re: [RFC] Deprecation and removal of the drm2 driver

[Andriy Gapon]

On 31/05/2018 18:34, Joe Maloney wrote:
> I personally wish that more drivers, and firmware were separated from
> base.

I would agree with you IF FreeBSD had a defined and stable Device Driver
Interface.  Or Thirdparty Module Interface. Or whatever the name.

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

Re: [RFC] Deprecation and removal of the drm2 driver

[Ronald Klop]

On Thu, 31 May 2018 17:34:18 +0200, Joe Maloney   
wrote:



I personally wish that more drivers, and firmware were separated from
base.

For example wireless firmware:

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

That was a ticket which I chimed in on about a firmware I needed to make  
my

wireless adapter work.  I went through numerous efforts on IRC, and
elsewhere to try to bring attention that ticket in order to attempt to  
get

that firmware backported for several 10.x releases in a row without
success.  The firmware worked perfectly fine in PC-BSD where it was  
cherry

picked for numerous 10.x releases.



I would support an idea that the FreeBSD project only delivers CURRENT  
(and one periodic release with security fixes) and parties like PC-BSD  
maintain stable branches and support for companies.


I read about this somewhere a while ago and the idea sticks. Backporting  
to code 2+ years old is not the best use of human volunteer resources IMHO.


Regards,
Ronald.





Technically since I was using PC-BSD, and was a committer for that  
project

I had no real dire need to reach out to FreeBSD about the issue.  I was
simply trying to help anyone else who might be encountering the same  
issue
trying to use stock FreeBSD because it was a simple backport.  If my  
effort

had turned out to be more fruitful I would have spent more time pursuing
tickets, diffs, or whatever to get more things back-ported when I found
them.  I am not sure where the breakdown was which did not allow that to
happen.  Anyways I don't want to bikeshed, or anything but I just wanted  
to

point out how I think having more drivers, and firmware in ports could be
helpful to enhance compatibility for end users.

Having a separate port for legacy drm could definitely make things easier
to providing installation options for end users, and automating the post
install action chosen in TrueOS, GhostBSD, and future derivative projects
tailored for the desktop use case.  For example for TrueOS we boot the
installer in failsafe mode with either VESA, or SCFB depending on whether
or not BIOS, or EFI is booted.  Then we could simply make a checkbox for
legacy intel, or skylake + to install the correct package then the module
path for either driver can more or less remain the same.  Eventually with
something like devmatch maybe that can even be fully automatic.

Joe Maloney

On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen 
wrote:


On Thu, 31 May 2018, Konstantin Belousov wrote:

On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:


We're not replacing anything. We are moving the older drm1 and drm2  
from
kernel to ports to make it easier for the majority of the users to  
load

the
correct driver without conflicts.



You do understand that you increase your maintainence load by this  
move.
dev/drm and dev/drm2 use KPIs which cannot be kept stable even in  
stable

branches, so you will need to chase these updates.



I agree.  One argument previously made was that it's easier
to maintain in ports.  One data point from me - I rarely
update my ports, I update my OS much more frequently.  In
fact, some times my ports get so out of date I just
(take off and) nuke /usr/local (from orbit, it's the only
way to be sure).

Also, are we trying to solve a problem by moving drm[2] to
ports that won't be a problem when base is pkg'ized?  If
drm[2] is a package unto itself, then you don't have this
problem of ports conflicting with it, at least not so
much.  You can either not install the base drm[2] package
or deinstall it to make way for a conflicting port.  Once
drm[2] is pkg rm'd, it's not going to be reinstalled
again when you update the base OS.

And don't we have the same problem with sendmail and a
few other base services?

--
DE

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



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

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

Re: [RFC] Deprecation and removal of the drm2 driver

[Joe Maloney]

I personally wish that more drivers, and firmware were separated from
base.

For example wireless firmware:

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

That was a ticket which I chimed in on about a firmware I needed to make my
wireless adapter work.  I went through numerous efforts on IRC, and
elsewhere to try to bring attention that ticket in order to attempt to get
that firmware backported for several 10.x releases in a row without
success.  The firmware worked perfectly fine in PC-BSD where it was cherry
picked for numerous 10.x releases.

Technically since I was using PC-BSD, and was a committer for that project
I had no real dire need to reach out to FreeBSD about the issue.  I was
simply trying to help anyone else who might be encountering the same issue
trying to use stock FreeBSD because it was a simple backport.  If my effort
had turned out to be more fruitful I would have spent more time pursuing
tickets, diffs, or whatever to get more things back-ported when I found
them.  I am not sure where the breakdown was which did not allow that to
happen.  Anyways I don't want to bikeshed, or anything but I just wanted to
point out how I think having more drivers, and firmware in ports could be
helpful to enhance compatibility for end users.

Having a separate port for legacy drm could definitely make things easier
to providing installation options for end users, and automating the post
install action chosen in TrueOS, GhostBSD, and future derivative projects
tailored for the desktop use case.  For example for TrueOS we boot the
installer in failsafe mode with either VESA, or SCFB depending on whether
or not BIOS, or EFI is booted.  Then we could simply make a checkbox for
legacy intel, or skylake + to install the correct package then the module
path for either driver can more or less remain the same.  Eventually with
something like devmatch maybe that can even be fully automatic.

Joe Maloney

On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen 
wrote:

> On Thu, 31 May 2018, Konstantin Belousov wrote:
>
> On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:
>>
>> We're not replacing anything. We are moving the older drm1 and drm2 from
>>> kernel to ports to make it easier for the majority of the users to load
>>> the
>>> correct driver without conflicts.
>>>
>>
>> You do understand that you increase your maintainence load by this move.
>> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in stable
>> branches, so you will need to chase these updates.
>>
>
> I agree.  One argument previously made was that it's easier
> to maintain in ports.  One data point from me - I rarely
> update my ports, I update my OS much more frequently.  In
> fact, some times my ports get so out of date I just
> (take off and) nuke /usr/local (from orbit, it's the only
> way to be sure).
>
> Also, are we trying to solve a problem by moving drm[2] to
> ports that won't be a problem when base is pkg'ized?  If
> drm[2] is a package unto itself, then you don't have this
> problem of ports conflicting with it, at least not so
> much.  You can either not install the base drm[2] package
> or deinstall it to make way for a conflicting port.  Once
> drm[2] is pkg rm'd, it's not going to be reinstalled
> again when you update the base OS.
>
> And don't we have the same problem with sendmail and a
> few other base services?
>
> --
> DE
>
> ___
> freebsd-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: [RFC] Deprecation and removal of the drm2 driver

[Daniel Eischen]

On Thu, 31 May 2018, Konstantin Belousov wrote:


On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:


We're not replacing anything. We are moving the older drm1 and drm2 from
kernel to ports to make it easier for the majority of the users to load the
correct driver without conflicts.


You do understand that you increase your maintainence load by this move.
dev/drm and dev/drm2 use KPIs which cannot be kept stable even in stable
branches, so you will need to chase these updates.


I agree.  One argument previously made was that it's easier
to maintain in ports.  One data point from me - I rarely
update my ports, I update my OS much more frequently.  In
fact, some times my ports get so out of date I just
(take off and) nuke /usr/local (from orbit, it's the only
way to be sure).

Also, are we trying to solve a problem by moving drm[2] to
ports that won't be a problem when base is pkg'ized?  If
drm[2] is a package unto itself, then you don't have this
problem of ports conflicting with it, at least not so
much.  You can either not install the base drm[2] package
or deinstall it to make way for a conflicting port.  Once
drm[2] is pkg rm'd, it's not going to be reinstalled
again when you update the base OS.

And don't we have the same problem with sendmail and a
few other base services?

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

Re: [RFC] Deprecation and removal of the drm2 driver

[Rodney W. Grimes]

> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA512
> > >
> > > Am Thu, 24 May 2018 09:10:10 -0700 (PDT)
> > > "Rodney W. Grimes"  schrieb:
> > >
> > > > -- Start of PGP signed section.
> > > > > On Thu, May 24, 2018 at 08:22:12AM -0700, Rodney W. Grimes wrote:
> > > > > > > On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote:
> > > > > > > > >Also as the Moore's law curve flattens expect the life of these
> > > > > > > > >older, but not so old, machines to live quiet some time.  I
> > > > > > > > >believe we are talking sandy bridge and earlier?  If that is
> > > > > > > > >corret Sandy bridge is still a very viable system.
> > > > > > > >
> > > > > > > > I noticed this lack of love for older systems recently.
> > > > > > > >
> > > > > > > > I wanted to use an older Dell server to test the 11.2 BETAs and
> > > RCs.
> > > > > > > >
> > > > > > > > Turns out, you can't install FreeBSD using a USB stick image
> > > because the
> > > > > > > > BIOS only support MBR. No idea why MBR support was dropped for
> > > the USB images.
> > > > > > > >
> > > > > > > > In the end I had to find a CD burner, and after a couple of
> > > tries managed to
> > > > > > > > install from CD.
> > > > > > > >
> > > > > > > > After that, my ansible playbooks started failing because
> > > /boot/loader.conf
> > > > > > > > is absent if you boot from zfs in combination with MBR.
> > > > > > > >
> > > > > > > > Pity. This older server hardware is great for trying out new
> > > releases, play
> > > > > > > > with zfs, etc.
> > > > > > >
> > > > > > > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are 
> > > > > > > now
> > > > > > > built as hybrid images, supporting both MBR and GPT, as well as
> > > being
> > > > > > > written to a flash drive (like memstick.img) as well as a CD.
> > > > > >
> > > > > > To clarify a minor point here, are the amd64 disc1.iso images or
> > > > > > both the amd64 and i386 disk1.iso images being built as "hybrid"?
> > > > > >
> > > > >
> > > > > Only amd64.  i386 does not have UEFI-/GPT-related boot issues.
> > > >
> > > > Here is a data point:
> > > >
> > > > Test system is Dell R710,
> > > > First attempt is with BIOS in Boot mode: Bios
> > > > Second attempt is with BIOS in Boot mode: UEFI
> > > >
> > > > Attemtped to boot amd64 version:
> > > > Screen goes white background, text appears (yes, way indented)
> > > > BTX version is 1.02
> > > > Consoles: internal video/keyboard
> > > > _
> > > >
> > > > That last _ is a blinking cursor, system is hung, does repsond to 
> > > > C-A-del
> > > >
> > > >
> > > > Second attempt:
> > > > Works properly
> > > >
> > > >
> > > > I am going after Ed Maste's posted build image in the other thread 
> > > > now...
> > > >
> > > >
> > > > >
> > > > > > As this is what I see on my system:
> > > > > > root@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-*
> > > > > > FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1
> > > : ID=0xee,
> > > > > > start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1472695
> > > sectors
> > > > > > FreeBSD-11.2-BETA2-i386-disc1.iso:  ISO 9660 CD-ROM filesystem data
> > > > > > '11_2_BETA2_I386_CD' (bootable)
> > > > > > > MBR support was initially removed from the memstick installer, as
> > > it is
> > > > > > > not compatible with some UEFI implementations.  (Or, at least that
> > > is my
> > > > > > > understanding, based on my limited intimate knowledge of UEFI.)
> > > > > > >
> > > > >
> > > > > Glen
> > > > >
> > > > -- End of PGP section, PGP failed!
> > > >
> > >
> > > Today, I tried to eliminate FreeBSD's native KMS drm2 by installing
> > > graphics/drm-stable-kmod (ports tree at revision 471172) on CURRENT
> > > (FreeBSD 12.0-CURRENT
> > > #46 r334401: Wed May 30 23:32:45 CEST 2018 amd64, CUSTOM kernel).
> > >
> > > The hardware is a presumably UEFI capable ASROCK Z77-Pro4M (latest
> > > firmware available
> > > from late 2013) equipted with a XEON IvyBridge:
> > >
> > > CPU: Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz (3400.09-MHz K8-class CPU)
> > >   Origin="GenuineIntel"  Id=0x306a9  Family=0x6  Model=0x3a  Stepping=9
> > >
> > > Features=0xbfebfbff
> > >
> > > Features2=0x7fbae3ff
> > >   AMD Features=0x28100800
> > >   AMD Features2=0x1
> > >   Structured Extended Features=0x281
> > >   XSAVE Features=0x1
> > >   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
> > >   TSC: P-state invariant, performance statistics
> > > real memory  = 17179869184 (16384 MB)
> > > avail memory = 16295137280 (15540 MB)
> > > Event timer "LAPIC" quality 600
> > > ACPI APIC Table: 
> > > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
> > >
> > >
> > > The box isn't capable of booting FreeBSD in UEFI (while Linux and Windows
> > > seems to work).
> > > So I'm stuck with BIOS.
> > >
> > > Loading i915kms.ko/drm2.ko on the system put the console in a
> > > high-resolution mode
> > > instead of this crap 80x25 ancient console immediately.
> > >
> > > Loading 

Re: ``make buildkernel'' fails when /usr/obj is empty

[Rodney W. Grimes]

> There's something totally screwy about trying to build a kernel when
> /usr/obj is not populated.
> 
> I ran ``make clean'' in /usr/src and then ``make buildkernel''.  This
> fails with
>   make[2]: "/usr/src/sys/conf/kern.pre.mk" line 125: amd64 kernel
>   requires linker ifunc support
> 
> This is total BS because
> 
> /usr/bin/ld --version
> LLD 6.0.0 (FreeBSD 326565-122) (compatible with GNU linkers)
> 
> which is exactly what bsd.linker.mk is looking for to set ifunc.
> 
> If I do this:
> 
> mkdir -p /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin
> cp /usr/bin/ld /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin
> 
> the buildkernel then succeeds.
> 
> Considering that (reformatted output from make)
> 
> PATH=/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:
> /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:
> /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin:
> /sbin:/bin:/usr/sbin:/usr/bin
> 
> it seems like /usr/bin/ld should be found by bsd.linker.mk and no
> error should be reported.

AHH!!  That explains why I was still seeing this too!
I been forcing the LD= work around and just ignoring
this failure thinking it was something in my not so
normal setup, but infact I always start with an empty
/usr/obj due to a zfs rollback pool/usr/obj@empty

So this is a "confirmed" this occurs, including in a 20180521
freshly installed snapshot.

-- 
Rod Grimes rgri...@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: evdev + ps/2 dell touchpad weirdness

[Johannes Lundberg]

On Thu, May 31, 2018 at 1:11 PM Hans Petter Selasky  wrote:

> On 05/31/18 13:39, Johannes Lundberg wrote:
> > EV_REL is for pushing events. For evdev_push_rel(), use REL_{axis}.
>
> Does this work:
> https://svnweb.freebsd.org/changeset/base/334422


Perfect. Thanks!


>
>
> --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: evdev + ps/2 dell touchpad weirdness

[Hans Petter Selasky]

On 05/31/18 13:39, Johannes Lundberg wrote:

EV_REL is for pushing events. For evdev_push_rel(), use REL_{axis}.


Does this work:
https://svnweb.freebsd.org/changeset/base/334422

--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: evdev + ps/2 dell touchpad weirdness

[Johannes Lundberg]

On Thu, May 31, 2018 at 9:32 AM Johannes Lundberg 
wrote:

>
>
> On Thu, May 31, 2018 at 8:45 AM Johannes Lundberg 
> wrote:
>
>> Hi
>>
>> I could swear this was working a couple of months ago but since
>> installing new kernel+world a couple of times and revisiting using Weston
>> or X with udev+evdev+libinput I can't get all the events.
>>
>> Using libinput-debug-events on my dell laptop touchpad (psm driver with
>> hw.psm.synaptics=1) I get events for two finger scroll Y (no horizontal
>> scroll but that's another issue), single finger tap (left mouse), two
>> finger tap (right mouse) but not single finger movements, that is I can't
>> move the mouse cursor...
>>
>> Changing to trackpoint, elantech, etc makes no difference.
>>
>> All packages are from stock ports.
>>
>
> To add more information. With PSM_DEBUG in kernel I can see that I'm
> getting interrupts for single finger movement
>
> psmintr: 38 f4 fd 00 00 00
> psmintr: 38 f4 ff 00 00 00
> psmintr: 18 f5 00 00 00 00
> psmintr: 18 f5 00 00 00 00
> psmintr: 18 f5 03 00 00 00
> psmintr: 18 f7 04 00 00 00
> psmintr: 18 f9 05 00 00 00
>
>
>


Ok got the fix. Can someone commit?

EV_REL is for pushing events. For evdev_push_rel(), use REL_{axis}.

diff --git a/sys/dev/atkbdc/psm.c b/sys/dev/atkbdc/psm.c
index 0b6a061e15b..227b73e7088 100644
--- a/sys/dev/atkbdc/psm.c
+++ b/sys/dev/atkbdc/psm.c
@@ -4966,8 +4966,8 @@ psmsoftintr(void *arg)
if (evdev_rcpt_mask & EVDEV_RCPT_HW_MOUSE &&
sc->hw.model != MOUSE_MODEL_ELANTECH &&
sc->hw.model != MOUSE_MODEL_SYNAPTICS) {
-   evdev_push_rel(sc->evdev_r, EV_REL, x);
-   evdev_push_rel(sc->evdev_r, EV_REL, -y);
+   evdev_push_rel(sc->evdev_r, REL_X, x);
+   evdev_push_rel(sc->evdev_r, REL_Y, -y);

switch (sc->hw.model) {
case MOUSE_MODEL_EXPLORER:
___
freebsd-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: vm_phys_free_pages: page 0x... has unexpected order 0

[Mark Johnston]

On Thu, May 31, 2018 at 10:10:40AM +0300, Andriy Gapon wrote:
> On 31/05/2018 05:04, Jonathan T. Looney wrote:
> > On Tue, May 29, 2018 at 10:18 AM, Andriy Gapon  > > wrote:
> > 
> > 
> > [ping]
> > 
> > On 21/05/2018 11:44, Andriy Gapon wrote:
> > > 
> > > FreeBSD 12.0-CURRENT amd64 r332472
> > > Does this panic ring a bell to anyone?
> > > Has it already been fixed?
> > > Thank you!
> > 
> > 
> > Is there any chance that r333703 fixes this problem for you? It fixes a race
> > that can manifest itself in other ways. I'm honestly not sure whether it 
> > could
> > also cause this problem.
> 
> Thank you for the suggestion.
> I guess it's worth trying that fix.
> I'll report back in a while.

r333703 fixes a bug in r332974, while the problem was reported on
r332472, so it won't address the crash.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Deprecation and removal of the drm2 driver

[Konstantin Belousov]

On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:
> On Wed, May 30, 2018 at 10:57 PM O. Hartmann  wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Am Thu, 24 May 2018 09:10:10 -0700 (PDT)
> > "Rodney W. Grimes"  schrieb:
> >
> > > -- Start of PGP signed section.
> > > > On Thu, May 24, 2018 at 08:22:12AM -0700, Rodney W. Grimes wrote:
> > > > > > On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote:
> > > > > > > >Also as the Moore's law curve flattens expect the life of these
> > > > > > > >older, but not so old, machines to live quiet some time.  I
> > > > > > > >believe we are talking sandy bridge and earlier?  If that is
> > > > > > > >corret Sandy bridge is still a very viable system.
> > > > > > >
> > > > > > > I noticed this lack of love for older systems recently.
> > > > > > >
> > > > > > > I wanted to use an older Dell server to test the 11.2 BETAs and
> > RCs.
> > > > > > >
> > > > > > > Turns out, you can't install FreeBSD using a USB stick image
> > because the
> > > > > > > BIOS only support MBR. No idea why MBR support was dropped for
> > the USB images.
> > > > > > >
> > > > > > > In the end I had to find a CD burner, and after a couple of
> > tries managed to
> > > > > > > install from CD.
> > > > > > >
> > > > > > > After that, my ansible playbooks started failing because
> > /boot/loader.conf
> > > > > > > is absent if you boot from zfs in combination with MBR.
> > > > > > >
> > > > > > > Pity. This older server hardware is great for trying out new
> > releases, play
> > > > > > > with zfs, etc.
> > > > > >
> > > > > > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now
> > > > > > built as hybrid images, supporting both MBR and GPT, as well as
> > being
> > > > > > written to a flash drive (like memstick.img) as well as a CD.
> > > > >
> > > > > To clarify a minor point here, are the amd64 disc1.iso images or
> > > > > both the amd64 and i386 disk1.iso images being built as "hybrid"?
> > > > >
> > > >
> > > > Only amd64.  i386 does not have UEFI-/GPT-related boot issues.
> > >
> > > Here is a data point:
> > >
> > > Test system is Dell R710,
> > > First attempt is with BIOS in Boot mode: Bios
> > > Second attempt is with BIOS in Boot mode: UEFI
> > >
> > > Attemtped to boot amd64 version:
> > > Screen goes white background, text appears (yes, way indented)
> > > BTX version is 1.02
> > > Consoles: internal video/keyboard
> > > _
> > >
> > > That last _ is a blinking cursor, system is hung, does repsond to C-A-del
> > >
> > >
> > > Second attempt:
> > > Works properly
> > >
> > >
> > > I am going after Ed Maste's posted build image in the other thread now...
> > >
> > >
> > > >
> > > > > As this is what I see on my system:
> > > > > root@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-*
> > > > > FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1
> > : ID=0xee,
> > > > > start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1472695
> > sectors
> > > > > FreeBSD-11.2-BETA2-i386-disc1.iso:  ISO 9660 CD-ROM filesystem data
> > > > > '11_2_BETA2_I386_CD' (bootable)
> > > > > > MBR support was initially removed from the memstick installer, as
> > it is
> > > > > > not compatible with some UEFI implementations.  (Or, at least that
> > is my
> > > > > > understanding, based on my limited intimate knowledge of UEFI.)
> > > > > >
> > > >
> > > > Glen
> > > >
> > > -- End of PGP section, PGP failed!
> > >
> >
> > Today, I tried to eliminate FreeBSD's native KMS drm2 by installing
> > graphics/drm-stable-kmod (ports tree at revision 471172) on CURRENT
> > (FreeBSD 12.0-CURRENT
> > #46 r334401: Wed May 30 23:32:45 CEST 2018 amd64, CUSTOM kernel).
> >
> > The hardware is a presumably UEFI capable ASROCK Z77-Pro4M (latest
> > firmware available
> > from late 2013) equipted with a XEON IvyBridge:
> >
> > CPU: Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz (3400.09-MHz K8-class CPU)
> >   Origin="GenuineIntel"  Id=0x306a9  Family=0x6  Model=0x3a  Stepping=9
> >
> > Features=0xbfebfbff
> >
> > Features2=0x7fbae3ff
> >   AMD Features=0x28100800
> >   AMD Features2=0x1
> >   Structured Extended Features=0x281
> >   XSAVE Features=0x1
> >   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
> >   TSC: P-state invariant, performance statistics
> > real memory  = 17179869184 (16384 MB)
> > avail memory = 16295137280 (15540 MB)
> > Event timer "LAPIC" quality 600
> > ACPI APIC Table: 
> > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
> >
> >
> > The box isn't capable of booting FreeBSD in UEFI (while Linux and Windows
> > seems to work).
> > So I'm stuck with BIOS.
> >
> > Loading i915kms.ko/drm2.ko on the system put the console in a
> > high-resolution mode
> > instead of this crap 80x25 ancient console immediately.
> >
> > Loading graphics/drm-stable-kmod as requested (via rc.conf.local) ends up
> > in a trap
> > 12/crash. Very nice for such an old hardware. graphics/drm-next-kmod does
> > load without
> > 

Re: evdev + ps/2 dell touchpad weirdness

[Johannes Lundberg]

On Thu, May 31, 2018 at 8:45 AM Johannes Lundberg 
wrote:

> Hi
>
> I could swear this was working a couple of months ago but since installing
> new kernel+world a couple of times and revisiting using Weston or X with
> udev+evdev+libinput I can't get all the events.
>
> Using libinput-debug-events on my dell laptop touchpad (psm driver with
> hw.psm.synaptics=1) I get events for two finger scroll Y (no horizontal
> scroll but that's another issue), single finger tap (left mouse), two
> finger tap (right mouse) but not single finger movements, that is I can't
> move the mouse cursor...
>
> Changing to trackpoint, elantech, etc makes no difference.
>
> All packages are from stock ports.
>

To add more information. With PSM_DEBUG in kernel I can see that I'm
getting interrupts for single finger movement

psmintr: 38 f4 fd 00 00 00
psmintr: 38 f4 ff 00 00 00
psmintr: 18 f5 00 00 00 00
psmintr: 18 f5 00 00 00 00
psmintr: 18 f5 03 00 00 00
psmintr: 18 f7 04 00 00 00
psmintr: 18 f9 05 00 00 00
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ``make buildkernel'' fails when /usr/obj is empty

[Gary Jennejohn]

On Thu, 31 May 2018 09:52:22 +0200
Gary Jennejohn  wrote:

> There's something totally screwy about trying to build a kernel when
> /usr/obj is not populated.
> 
> I ran ``make clean'' in /usr/src and then ``make buildkernel''.  This
> fails with
>   make[2]: "/usr/src/sys/conf/kern.pre.mk" line 125: amd64 kernel
>   requires linker ifunc support
> 
> This is total BS because
> 
> /usr/bin/ld --version
> LLD 6.0.0 (FreeBSD 326565-122) (compatible with GNU linkers)
> 
> which is exactly what bsd.linker.mk is looking for to set ifunc.
> 
> If I do this:
> 
> mkdir -p /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin
> cp /usr/bin/ld /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin
> 
> the buildkernel then succeeds.
> 
> Considering that (reformatted output from make)
> 
> PATH=/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:
> /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:
> /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin:
> /sbin:/bin:/usr/sbin:/usr/bin
> 
> it seems like /usr/bin/ld should be found by bsd.linker.mk and no
> error should be reported.
> 

OK, it seems that ``make clean'' does not remove the contents of
/usr/obj/usr/src/amd64.amd64/tmp/legacy.  If I delete everything
under /usr/obj then ``make buildkernel'' works.

Still, it seems pretty strange to me to make building a kernel
depend on some random junk which is left laying around under
/usr/obj.

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

``make buildkernel'' fails when /usr/obj is empty

[Gary Jennejohn]

There's something totally screwy about trying to build a kernel when
/usr/obj is not populated.

I ran ``make clean'' in /usr/src and then ``make buildkernel''.  This
fails with
make[2]: "/usr/src/sys/conf/kern.pre.mk" line 125: amd64 kernel
requires linker ifunc support

This is total BS because

/usr/bin/ld --version
LLD 6.0.0 (FreeBSD 326565-122) (compatible with GNU linkers)

which is exactly what bsd.linker.mk is looking for to set ifunc.

If I do this:

mkdir -p /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin
cp /usr/bin/ld /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin

the buildkernel then succeeds.

Considering that (reformatted output from make)

PATH=/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:
/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:
/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:
/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:
/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:
/sbin:/bin:/usr/sbin:/usr/bin

it seems like /usr/bin/ld should be found by bsd.linker.mk and no
error should be reported.

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

evdev + ps/2 dell touchpad weirdness

[Johannes Lundberg]

Hi

I could swear this was working a couple of months ago but since installing
new kernel+world a couple of times and revisiting using Weston or X with
udev+evdev+libinput I can't get all the events.

Using libinput-debug-events on my dell laptop touchpad (psm driver with
hw.psm.synaptics=1) I get events for two finger scroll Y (no horizontal
scroll but that's another issue), single finger tap (left mouse), two
finger tap (right mouse) but not single finger movements, that is I can't
move the mouse cursor...

Changing to trackpoint, elantech, etc makes no difference.

All packages are from stock ports.
___
freebsd-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: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

[Vitalij Satanivskij]

Hi 

Tested both images in both modes on: 

Supermicro X9SCL-F
E3-1230 CPU 

Work perfectly



Glen Barber wrote:
GB> Hi,
GB> 
GB> Could folks please help boot-test the most recent 12.0-CURRENT amd64
GB> memstick images on various hardware?  Note, this is not a request to
GB> install 12.0-CURRENT, only a boot-test with various system knobs
GB> tweaked.
GB> 
GB> The most recent images are available at:
GB> 
https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img
GB> 
https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img
GB> 
GB> We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we
GB> would like to get this included in the upcoming 11.2-RELEASE if the
GB> change that had been committed addresses several boot issues reported
GB> recently.
GB> 
GB> Please help test, and report back (both successes and failures).
GB> 
GB> Thanks,
GB> 
GB> Glen
GB> 


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

Re: [RFC] Deprecation and removal of the drm2 driver

[Johannes Lundberg]

On Wed, May 30, 2018 at 10:57 PM O. Hartmann  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am Thu, 24 May 2018 09:10:10 -0700 (PDT)
> "Rodney W. Grimes"  schrieb:
>
> > -- Start of PGP signed section.
> > > On Thu, May 24, 2018 at 08:22:12AM -0700, Rodney W. Grimes wrote:
> > > > > On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote:
> > > > > > >Also as the Moore's law curve flattens expect the life of these
> > > > > > >older, but not so old, machines to live quiet some time.  I
> > > > > > >believe we are talking sandy bridge and earlier?  If that is
> > > > > > >corret Sandy bridge is still a very viable system.
> > > > > >
> > > > > > I noticed this lack of love for older systems recently.
> > > > > >
> > > > > > I wanted to use an older Dell server to test the 11.2 BETAs and
> RCs.
> > > > > >
> > > > > > Turns out, you can't install FreeBSD using a USB stick image
> because the
> > > > > > BIOS only support MBR. No idea why MBR support was dropped for
> the USB images.
> > > > > >
> > > > > > In the end I had to find a CD burner, and after a couple of
> tries managed to
> > > > > > install from CD.
> > > > > >
> > > > > > After that, my ansible playbooks started failing because
> /boot/loader.conf
> > > > > > is absent if you boot from zfs in combination with MBR.
> > > > > >
> > > > > > Pity. This older server hardware is great for trying out new
> releases, play
> > > > > > with zfs, etc.
> > > > >
> > > > > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now
> > > > > built as hybrid images, supporting both MBR and GPT, as well as
> being
> > > > > written to a flash drive (like memstick.img) as well as a CD.
> > > >
> > > > To clarify a minor point here, are the amd64 disc1.iso images or
> > > > both the amd64 and i386 disk1.iso images being built as "hybrid"?
> > > >
> > >
> > > Only amd64.  i386 does not have UEFI-/GPT-related boot issues.
> >
> > Here is a data point:
> >
> > Test system is Dell R710,
> > First attempt is with BIOS in Boot mode: Bios
> > Second attempt is with BIOS in Boot mode: UEFI
> >
> > Attemtped to boot amd64 version:
> > Screen goes white background, text appears (yes, way indented)
> > BTX version is 1.02
> > Consoles: internal video/keyboard
> > _
> >
> > That last _ is a blinking cursor, system is hung, does repsond to C-A-del
> >
> >
> > Second attempt:
> > Works properly
> >
> >
> > I am going after Ed Maste's posted build image in the other thread now...
> >
> >
> > >
> > > > As this is what I see on my system:
> > > > root@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-*
> > > > FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1
> : ID=0xee,
> > > > start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1472695
> sectors
> > > > FreeBSD-11.2-BETA2-i386-disc1.iso:  ISO 9660 CD-ROM filesystem data
> > > > '11_2_BETA2_I386_CD' (bootable)
> > > > > MBR support was initially removed from the memstick installer, as
> it is
> > > > > not compatible with some UEFI implementations.  (Or, at least that
> is my
> > > > > understanding, based on my limited intimate knowledge of UEFI.)
> > > > >
> > >
> > > Glen
> > >
> > -- End of PGP section, PGP failed!
> >
>
> Today, I tried to eliminate FreeBSD's native KMS drm2 by installing
> graphics/drm-stable-kmod (ports tree at revision 471172) on CURRENT
> (FreeBSD 12.0-CURRENT
> #46 r334401: Wed May 30 23:32:45 CEST 2018 amd64, CUSTOM kernel).
>
> The hardware is a presumably UEFI capable ASROCK Z77-Pro4M (latest
> firmware available
> from late 2013) equipted with a XEON IvyBridge:
>
> CPU: Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz (3400.09-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x306a9  Family=0x6  Model=0x3a  Stepping=9
>
> Features=0xbfebfbff
>
> Features2=0x7fbae3ff
>   AMD Features=0x28100800
>   AMD Features2=0x1
>   Structured Extended Features=0x281
>   XSAVE Features=0x1
>   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>   TSC: P-state invariant, performance statistics
> real memory  = 17179869184 (16384 MB)
> avail memory = 16295137280 (15540 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: 
> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
>
>
> The box isn't capable of booting FreeBSD in UEFI (while Linux and Windows
> seems to work).
> So I'm stuck with BIOS.
>
> Loading i915kms.ko/drm2.ko on the system put the console in a
> high-resolution mode
> instead of this crap 80x25 ancient console immediately.
>
> Loading graphics/drm-stable-kmod as requested (via rc.conf.local) ends up
> in a trap
> 12/crash. Very nice for such an old hardware. graphics/drm-next-kmod does
> load without
> crashing the system - but the console is stuck in the clumsy 80x25 mode.
>
> So why should I vote for non-working drivers to replace perfectly working
> ones?
>
> oh
>
>
We're not replacing anything. We are moving the older drm1 and drm2 from
kernel to ports to make it easier for the majority of the users to load the
correct driver 

Re: [RFC] Deprecation and removal of the drm2 driver

[Hans Petter Selasky]

On 05/30/18 23:51, O. Hartmann wrote:

Loading graphics/drm-stable-kmod as requested (via rc.conf.local) ends up in a 
trap
12/crash. Very nice for such an old hardware. graphics/drm-next-kmod does load 
without
crashing the system - but the console is stuck in the clumsy 80x25 mode.

So why should I vote for non-working drivers to replace perfectly working ones?


Usually the crashes you get are low hanging fruit. Why not get the 
backtrace and resolve the crash? It should take less than 10 minutes.


--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: vm_phys_free_pages: page 0x... has unexpected order 0

[Andriy Gapon]

On 31/05/2018 05:04, Jonathan T. Looney wrote:
> On Tue, May 29, 2018 at 10:18 AM, Andriy Gapon  > wrote:
> 
> 
> [ping]
> 
> On 21/05/2018 11:44, Andriy Gapon wrote:
> > 
> > FreeBSD 12.0-CURRENT amd64 r332472
> > Does this panic ring a bell to anyone?
> > Has it already been fixed?
> > Thank you!
> 
> 
> Is there any chance that r333703 fixes this problem for you? It fixes a race
> that can manifest itself in other ways. I'm honestly not sure whether it could
> also cause this problem.

Thank you for the suggestion.
I guess it's worth trying that fix.
I'll report back in a while.


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