Re: drm / drm2 removal in 12

[blubee blubeeme]

On Sat, Aug 25, 2018 at 6:26 AM Warner Losh  wrote:

> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy  wrote:
>
> > On Fri, Aug 24, 2018 at 14:53 Ali  wrote:
> >
> > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote:
> > > > Just in case anyone misses the change to UPDATING:
> > > >
> > > > 20180821:
> > > > drm and drm2 have been removed. Users on powerpc, 32-bit
> > > hardware,
> > > > or with GPUs predating Radeon and i915 will need to install
> the
> > > > graphics/drm-legacy-kmod. All other users should be able to
> use
> > > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod,
> > > > graphics/drm-next-kmod, graphics/drm-devel-kmod.
> > > > Note that this applies only to 12.
> > >
> > > I see that The removal of drm and drm2 has been reverted on svn. Could
> > > you please kindly share the reasons behind the re-inclusion?
> > >
> >
> >
> > I can’t really give the blow by blow of internal project drama, but the
> > gist of it is that “best practices” (which are not yet actually
> documented
> > anywhere that I’ve seen) were not followed with regards to the
> deprecation
> > process. Warner and others believe that we can address the objectives of
> > the drm removal (improving the user experience and communicating that
> > drm/drm2 are _completely_ unsupported apart from continuing to compile)
> > through less disruptive means.
> >
>
> Just so.
>
> Our only continued frustration is that we were never given any guidance by
> > RE or core on said “best practices” when the discussion was taking place
> in
> > May and then those groups behaved as if this were a surprise when the
> > removal happened. I’m cautiously optimistic that this well expedite
> > improving communications on those matters.
> >
>
> All the problems that are exposed by this aren't technical. This one is
> social, but no less important.
>
> 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"
>

I've been watching this debacle for quite some time now and I'd just like
to ask why the rush?

The graphics team is working very hard to destroy the stability of FreeBSD
just so that they can force their uncooked work down users throats.

The Linuxkpi is unstable at best, alpha level software that's constantly in
need of someone to go and fix something on FreeBSD because Linux devs
decided to make some changes or implement a new feature.

This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM
Goals

   - Move DRM headers to a similar location as Linux
   -

   Use kmalloc() instead of malloc(9)
   - Use kref
   -

   Use idr and get rid of drm_gem_names.c
   - Use PCI API
   - Use Linux locking primitives

is garbage, if you want to use develop Linux code and use Linux then go do
that on Linux.

Are these guys insane and please avoid the nonsense about you're doing this
in your spare time.

If you cannot devote the resources to do something right then don't do it
at all.

Keep that stuff in to yourself or anyone crazy enough to follow those steps
to get it up and running, you guys cannot expect to contaminate the entire
FreeBSD project for this mess.

This is nonsense and I hope that more people who see it as such would say
so and stop having these guys forcing this crap; it's maintenance hell who
will maintain it if they decide to leave?

Best,
Owen
___
freebsd-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: drm / drm2 removal in 12

[blubee blubeeme]

On Sat, Aug 25, 2018 at 7:43 AM Kris Moore  wrote:

> On 8/24/18 7:07 PM, blubee blubeeme wrote:
> > On Sat, Aug 25, 2018 at 6:26 AM Warner Losh  wrote:
> >
> >> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy  wrote:
> >>
> >>> On Fri, Aug 24, 2018 at 14:53 Ali  wrote:
> >>>
> >>>> On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote:
> >>>>> Just in case anyone misses the change to UPDATING:
> >>>>>
> >>>>> 20180821:
> >>>>> drm and drm2 have been removed. Users on powerpc, 32-bit
> >>>> hardware,
> >>>>> or with GPUs predating Radeon and i915 will need to install
> >> the
> >>>>> graphics/drm-legacy-kmod. All other users should be able to
> >> use
> >>>>> one of the LinuxKPI-based ports: graphics/drm-stable-kmod,
> >>>>> graphics/drm-next-kmod, graphics/drm-devel-kmod.
> >>>>> Note that this applies only to 12.
> >>>> I see that The removal of drm and drm2 has been reverted on svn. Could
> >>>> you please kindly share the reasons behind the re-inclusion?
> >>>>
> >>>
> >>> I can’t really give the blow by blow of internal project drama, but the
> >>> gist of it is that “best practices” (which are not yet actually
> >> documented
> >>> anywhere that I’ve seen) were not followed with regards to the
> >> deprecation
> >>> process. Warner and others believe that we can address the objectives
> of
> >>> the drm removal (improving the user experience and communicating that
> >>> drm/drm2 are _completely_ unsupported apart from continuing to compile)
> >>> through less disruptive means.
> >>>
> >> Just so.
> >>
> >> Our only continued frustration is that we were never given any guidance
> by
> >>> RE or core on said “best practices” when the discussion was taking
> place
> >> in
> >>> May and then those groups behaved as if this were a surprise when the
> >>> removal happened. I’m cautiously optimistic that this well expedite
> >>> improving communications on those matters.
> >>>
> >> All the problems that are exposed by this aren't technical. This one is
> >> social, but no less important.
> >>
> >> 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"
> >>
> > I've been watching this debacle for quite some time now and I'd just like
> > to ask why the rush?
> >
> > The graphics team is working very hard to destroy the stability of
> FreeBSD
> > just so that they can force their uncooked work down users throats.
> >
> > The Linuxkpi is unstable at best, alpha level software that's constantly
> in
> > need of someone to go and fix something on FreeBSD because Linux devs
> > decided to make some changes or implement a new feature.
> >
> > This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM
> > Goals
> >
> >- Move DRM headers to a similar location as Linux
> >-
> >
> >Use kmalloc() instead of malloc(9)
> >- Use kref
> >-
> >
> >Use idr and get rid of drm_gem_names.c
> >- Use PCI API
> >- Use Linux locking primitives
> >
> > is garbage, if you want to use develop Linux code and use Linux then go
> do
> > that on Linux.
> >
> > Are these guys insane and please avoid the nonsense about you're doing
> this
> > in your spare time.
> >
> > If you cannot devote the resources to do something right then don't do it
> > at all.
> >
> > Keep that stuff in to yourself or anyone crazy enough to follow those
> steps
> > to get it up and running, you guys cannot expect to contaminate the
> entire
> > FreeBSD project for this mess.
> >
> > This is nonsense and I hope that more people who see it as such would say
> > so and stop having these guys forcing this crap; it's maintenance hell
> who
> > will maintain it if they decide to leave?
> >
> > Best,
> > Owen
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org

Re: drm / drm2 removal in 12

[blubee blubeeme]

On Sat, Aug 25, 2018 at 8:40 AM Pete Wright  wrote:

>
>
> On 8/24/18 4:07 PM, blubee blubeeme wrote:
>
> > This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM
> > Goals
> >
> > - Move DRM headers to a similar location as Linux
> > -
> >
> > Use kmalloc() instead of malloc(9)
> > - Use kref
> > -
> >
> > Use idr and get rid of drm_gem_names.c
> > - Use PCI API
> > - Use Linux locking primitives
> >
> > is garbage, if you want to use develop Linux code and use Linux then go
> do
> > that on Linux.
> having a hard time not feeding the troll here...but what specifically is
> garbage.  as in, what implementation of all this work do you have
> available that has been developed independently which also enables
> support for modern desktop and portable systems that you can buy today?
> > Are these guys insane and please avoid the nonsense about you're doing
> this
> > in your spare time.
>
The idea that FreeBSD relax it's standards just so that some devs have an
easier time
bringing up a half baked idea is nonsense.

Let's take power management, after you guys do all this work to get the
graphics card working
how much of devd will you need to implement to get that working properly?

I don't understand why this concept seems so hard to grasp but FreeBSD is
not Linux
why are some people continually trying to turn it into some Frankenstein
thing.

If you guys consider yourself developers then do what developers do and
solve problems
with constraints, if you cannot accomplish that stop pushing these breaking
changes.

None of these kmod guys seems to have put any thought into long
term maintenance of
this project. Look at the mailing list, every few days there's some
breaking changes waiting
for patches because something changed in Linux-land...

If you can't solve the problem in a maintainable way, you will just create
bigger problems for
developers down the line. Until you guys have something that's at least as
stable as what's
available now, keep working on it.

Some people take pride in their work and deliver a working product, they
don't need to twist
peoples arms into getting their way.

speaking as someone who's been working on this from pretty much the day
> of the initial CFT (maybe before?) - i don't know anyone who's getting
> paid for this specific work.  at least when it comes to GPU support.
> but, if you have the means, I'd love to work on this full time and am
> open to any serious offers :)
>
> -pete
>
I'd hope you have something more compelling than [http://nomadlogic.org]
as your calling card.

-- 
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: drm / drm2 removal in 12

[blubee blubeeme]

On Sat, Aug 25, 2018 at 10:04 AM Mark Linimon  wrote:

> On Sat, Aug 25, 2018 at 07:07:24AM +0800, blubee blubeeme wrote:
> > Are these guys insane and please avoid the nonsense about you're doing
> this
> > in your spare time.
>
> Let us know how whatever OS you wind up using instead works for you.
> I suggest you look for one that will put up with your constant harangues.
>
> There are very few people on the mailing lists as nasty and rude as
> yourself.  It is tiresome, demotivating, and childish.  Please go
> elsewhere.
>
> mcl
>
Your opinion has been noted but this issue isn't about me.

It's about the Graphics devs coding themselves into a corner and looking
for an easy button so they can continue to feel good about their toy.

There's a reason the changes they tried to force down the FreeBSD source
tree was reverted; It does not meet any standards of quality.

I have no inside knowledge other than my ability to think clearly and it's
obvious that The FreeBSD team wanted to hint at them that their code
doesn't pass the sniff test.

Instead of being whiny brats improve your code and have it work without
breaking compatibility with what has been working for quite a long time.

Here's the play by play;
You guys push this mess contaminating the FreeBSD source tree, some long
standing user tries to update their machines and it blows up;
1) Most will just leave
2) Some will complain
   2a) You guys will say; Read UPDATING. bleh bleh blen
They'll get aggravated, thereby aggravating people who came to this
platform for Stability.

Users who actually use FreeBSD to get things done do not time to trawl
these mailing lists, they have real world problems to solve with real world
constraints.

There are OS with kqueue and all those things it's called Linux; You can go
there and play w/ that stuff to your hearts content.

If you want your code to get merged, make sure it follows the guidelines
and not break the systems for people who are already using the platform.

Now, I understand hearing harsh criticism about your work might hurt your
feelings and all but here's the antidote;
work harder,
improve your code,
try again when your code quality improves.

You guys cannot expect people to accept these kludges in their systems that
they run everyday.

It's an open source project, you can't get mad because your code isn't
accepted, it's your jobs and engineers to do better not expect users to
jump through hoops to accommodate your subpar attempts at coding.

This isn't about me, it's about the quality of code that you guys are
trying to submit.

Best,
Owen
___
freebsd-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: drm / drm2 removal in 12

[blubee blubeeme]

On Sat, Aug 25, 2018 at 4:27 PM Matthew Macy  wrote:

> Hi Owen -
> I understand that you're enthusiastic and you just want what's best for
> the project. However, there's a couple of points I hope you'll take to
> heart. First, please read what you sent and think about the tone and word
> choice. It's extremely negative and critical - you're actively alienating
> people on the list. You're not going to be successful engaging any open
> source community or workplace if you choose to communicate like this.
> Second, this is a volunteer project. One needs to establish a track record
> of producing patches and working with developers to get them committed.
> Regardless of how sound your technical position is - you're going to have a
> hard time being acknowledged if there is no contribution to match.
>
> Best wishes.
> -M
>
True on both points my tone is just a reflection of attitudes of the
individuals that I am currently addressing.

Some people enjoy making contributions w/o waving a banner constantly
wanting acknowledgement, a pat on the head and good job from everyone.

How far will core FreeBSD bend over backwards to accommodate these devs.
Their project is half baked at best and sure it works; sorta if the moon is
just right.

This is the beauty of an open source project, we bring the best to the
table, not rip off two legs only to glue them back on later just
slightly askew.

This isn't a world where everyone gets a gold star, people fail even if
they work very hard, failure is still an option.

I guess the most important question to ask is what's the standards that the
FreeBSD Foundation want to represent, uphold, and maintain?

>
>
> On Fri, Aug 24, 2018 at 4:07 PM blubee blubeeme 
> wrote:
>
>>
>>
>> On Sat, Aug 25, 2018 at 6:26 AM Warner Losh  wrote:
>>
>>> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy  wrote:
>>>
>>> > On Fri, Aug 24, 2018 at 14:53 Ali  wrote:
>>> >
>>> > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote:
>>> > > > Just in case anyone misses the change to UPDATING:
>>> > > >
>>> > > > 20180821:
>>> > > > drm and drm2 have been removed. Users on powerpc, 32-bit
>>> > > hardware,
>>> > > > or with GPUs predating Radeon and i915 will need to
>>> install the
>>> > > > graphics/drm-legacy-kmod. All other users should be able
>>> to use
>>> > > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod,
>>> > > > graphics/drm-next-kmod, graphics/drm-devel-kmod.
>>> > > > Note that this applies only to 12.
>>> > >
>>> > > I see that The removal of drm and drm2 has been reverted on svn.
>>> Could
>>> > > you please kindly share the reasons behind the re-inclusion?
>>> > >
>>> >
>>> >
>>> > I can’t really give the blow by blow of internal project drama, but the
>>> > gist of it is that “best practices” (which are not yet actually
>>> documented
>>> > anywhere that I’ve seen) were not followed with regards to the
>>> deprecation
>>> > process. Warner and others believe that we can address the objectives
>>> of
>>> > the drm removal (improving the user experience and communicating that
>>> > drm/drm2 are _completely_ unsupported apart from continuing to compile)
>>> > through less disruptive means.
>>> >
>>>
>>> Just so.
>>>
>>> Our only continued frustration is that we were never given any guidance
>>> by
>>> > RE or core on said “best practices” when the discussion was taking
>>> place in
>>> > May and then those groups behaved as if this were a surprise when the
>>> > removal happened. I’m cautiously optimistic that this well expedite
>>> > improving communications on those matters.
>>> >
>>>
>>> All the problems that are exposed by this aren't technical. This one is
>>> social, but no less important.
>>>
>>> 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"
>>>
>>
>> I've been watching this debacle for quite some time now and I'd just like
>> to ask why the rush?
>>
>> The graphics t

Re: drm / drm2 removal in 12

[blubee blubeeme]

On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen 
wrote:

> blubee blubeeme wrote:
> > On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote:
> >> I've been personally using the new DRM bits since almost day one. I
> >> haven't found it to be unstable in the slightest. Compared to not
> >> having it and being forced to run 5+ year old hardware, it's been a
> >> huge blessing for those of us who care about running FreeBSD as a
> >> modern desktop / laptop.
> >>
> >> FreeBSD being an open source project, you are welcome to contribute
> >> back your work anytime. But since I don't imagine we'll see that
> >> patch coming anytime soon, I'll stick with this new LinuxKPI-powered,
> >> Plasma-desktop running awesomeness.
> >>
> >> (Written from my brand new Lenovo P71 which worked flawlessly out of
> >> box)
> >
> > Please tell me more about you're modern hardware, Kris Vice President
> > of Engineering at iXsystems.
> >
> > Try asking a person who doesn't run server infrastructure software and
> > hardware to get that stuff up and running, would you?
>
> Do you want to ask me? I'm mostly a private individual and linux/debian
> user that got fed up with the Linux fragmentation and direction of
> development (from a user perspective). I found my new home in FreeBSD.
> I migrated my (hobby) root server and have a few jails up and running
> and doing random stuff on them for myself and friends.
>
> Key to this was that I was able to get FreeBSD up and running on my
> Laptop - with the drm-next kmod - and use it daily to get used to it and
> learn about it. Actually it was a pain in the ass because back then I
> had to learn how to make -current run and even worse, I had to use the
> drm-next graphics branch from a github repository which wasn't even
> on the main FreeBSD account. I was forced to update the kernel every
> once in a while because the pkg update would complain otherwise. It
> frequently broke and I had to deal with it and learn how to recover it.
>
> The alternative would have been to go back to Linux, which has a whole
> lot more to complain about. So I stayed. And I'm happy with it.
>
> I accepted all this trouble to have decent graphics support. In all
> the time I had to fight -current issues a lot more than anything
> drm/graphics related. This stuff was always stable for me.
>
> I saw a few people trying out FreeBSD. And the first thing after the
> Installation is always: Graphics and Wifi. That's what people need.
>
> These are "desktop needs", where supporting new hardware fast is more
> important than being rock stable and feature complete.
>
> Just my 2 cents,
> Stefan
>
> --
> Stefan Hagen
> Mail: s...@codevoid.de | encryption key in header.
> gopher://codevoid.de | https://codevoid.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"
>
Like you said you're doing hobby work, that's fine. Take the time to test
that bleeding edge stuff on a branch somewhere.

You guys cannot expect reasonable people who have machines running
production code to have to deal with that type of nonsense that you just
described.

You left Linux because it's an unorganized mess, FreeBSD is not Linux.
There are clear rules and restrictions if you guys cannot understand this
then this is just a waste of time.

FreeBSD is server first and while that may suck for hobbyist at first, once
you understand that people who run servers do not care about graphics as
much as hobbyist do they need a reliable core.

The linuxkpi stuff the total antithesis of what I understand to be the
FreeBSD philosophy. Try reading it again:
https://www.freebsd.org/doc/handbook/nutshell.html

You guys can't expect to destroy the stability for everyone because a few
hobbyist who volunteer in their free time want to wreck the system.

Work on your code to improve the quality instead of trying to turn the
FreeBSD kernel into a thin wrapper around Linux kernel. Solve the
engineering problems instead of asking for quick fix solutions.

Any of you linuxkpi guys who are pushing this, what will be enough?

Haven't you guys gotten enough leeway from the core team?
How many breaking changes do you want to introduce to the FreeBSD kernel vs
engineering your software to work well within the existing infrastructure?

Which one of you guys dare to stand up and define a goal?
___
freebsd-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: drm / drm2 removal in 12

[blubee blubeeme]

On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav  wrote:

> blubee blubeeme  writes:
> > True on both points my tone is just a reflection of attitudes of the
> > individuals that I am currently addressing.
>
> Well, congratulations on alienating absolutely everybody you have
> interacted with on this topic.
>
> > Some people enjoy making contributions w/o waving a banner constantly
> > wanting acknowledgement, a pat on the head and good job from everyone.
>
> The only person I see constantly craving attention and validation from
> others here is you.
>
> > How far will core FreeBSD bend over backwards to accommodate these
> > devs.
>
> The core team does not decide what goes into the tree or not.  The
> developers do.
>
> > This is the beauty of an open source project, we bring the best to the
> > table, [...]
>
> Who exactly is “we” here?  You are not a member of the project, you do
> not speak for the project, and after seeing how you treat our fellow
> developers, our friends, most of us want nothing to do with you.  If
> can't live with that, I'm sure you can figure out how to install Linux.
>
> DES
> --
> Dag-Erling Smørgrav - d...@des.no


Some on here want to attack my personality because they think that I am
abrasive, fine but that's not the issue.

Some claim that they run the code and it works wonderful for them with no
issues, again that's lovely keep on running the code.

 Nevertheless let me restate the point that you guys are all seeming to
miss; If you can go out and build custom kernels with custom options and
out of mainline tree that's fine, keep doing that until you have something
that's production ready and as easy to install as the rest of FreeBSD
system.

The graphics stack on FreeBSD is pretty bad as it stands but all the
documentation currently out there is about using it as it stands now.

Why do you need to rip out the current graphics drivers which will break
systems for the vast majority of silent users who will not complain and
just leave?

 A little background 
Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update
their phones to the latest android version?

It's because the Linux kernel is such a mess they know it's a waste of
resources to try. You should not have to ask how or why I know this but if
it's unclear I was in the field.
---

Now you guys who claim to only be hobbyist doing this in their free time
expect to maintain this when those companies with all their resources
cannot?

Those 30,000 ports many of them bring bugs with them because of this
Linuxkpi stuff. Just recently there was a user who said google earth
doesn't work the answer was it doesn't work and that's that.

They get ported and then get dropped so while the ports tree is large, if
you actually try to use some of those programs they are broken, maintenance
hell for the developers and confusion for the users.

Johannes Lundberg I know that you are one of the main working on this
linuxkpi stuff but anyone else is free to answer as well.

Let's have an open discussion why do you need to remove the current
graphics stack to continue with your work?
___
freebsd-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: drm / drm2 removal in 12

[blubee blubeeme]

On Sun, Aug 26, 2018 at 8:16 AM Johannes Lundberg 
wrote:

>
>
> On Sun, Aug 26, 2018 at 00:25 blubee blubeeme  wrote:
>
>> On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav  wrote:
>>
>> > blubee blubeeme  writes:
>> > > True on both points my tone is just a reflection of attitudes of the
>> > > individuals that I am currently addressing.
>> >
>> > Well, congratulations on alienating absolutely everybody you have
>> > interacted with on this topic.
>> >
>> > > Some people enjoy making contributions w/o waving a banner constantly
>> > > wanting acknowledgement, a pat on the head and good job from everyone.
>> >
>> > The only person I see constantly craving attention and validation from
>> > others here is you.
>> >
>> > > How far will core FreeBSD bend over backwards to accommodate these
>> > > devs.
>> >
>> > The core team does not decide what goes into the tree or not.  The
>> > developers do.
>> >
>> > > This is the beauty of an open source project, we bring the best to the
>> > > table, [...]
>> >
>> > Who exactly is “we” here?  You are not a member of the project, you do
>> > not speak for the project, and after seeing how you treat our fellow
>> > developers, our friends, most of us want nothing to do with you.  If
>> > can't live with that, I'm sure you can figure out how to install Linux.
>> >
>> > DES
>> > --
>> > Dag-Erling Smørgrav - d...@des.no
>>
>>
>> Some on here want to attack my personality because they think that I am
>> abrasive, fine but that's not the issue.
>>
>> Some claim that they run the code and it works wonderful for them with no
>> issues, again that's lovely keep on running the code.
>>
>>  Nevertheless let me restate the point that you guys are all seeming to
>> miss; If you can go out and build custom kernels with custom options and
>> out of mainline tree that's fine, keep doing that until you have something
>> that's production ready and as easy to install as the rest of FreeBSD
>> system.
>>
>> The graphics stack on FreeBSD is pretty bad as it stands but all the
>> documentation currently out there is about using it as it stands now.
>>
>> Why do you need to rip out the current graphics drivers which will break
>> systems for the vast majority of silent users who will not complain and
>> just leave?
>>
>>  A little background 
>> Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update
>> their phones to the latest android version?
>>
>> It's because the Linux kernel is such a mess they know it's a waste of
>> resources to try. You should not have to ask how or why I know this but if
>> it's unclear I was in the field.
>> ---
>>
>> Now you guys who claim to only be hobbyist doing this in their free time
>> expect to maintain this when those companies with all their resources
>> cannot?
>>
>> Those 30,000 ports many of them bring bugs with them because of this
>> Linuxkpi stuff. Just recently there was a user who said google earth
>> doesn't work the answer was it doesn't work and that's that.
>>
>> They get ported and then get dropped so while the ports tree is large, if
>> you actually try to use some of those programs they are broken,
>> maintenance
>> hell for the developers and confusion for the users.
>>
>> Johannes Lundberg I know that you are one of the main working on this
>> linuxkpi stuff but anyone else is free to answer as well.
>>
>> Let's have an open discussion why do you need to remove the current
>> graphics stack to continue with your work?
>
>
> This has been discussed over and over on the mailing list and I don’t
> think anyone wants to do it over again so please feel free to search the
> archives.
>
> You’re misinformed. We are not removing anything for anyone. We are moving
> it to ports.
> “pkg install drm-legacy-kmod” will install those drivers for you that were
> earlier in base. I thought we have been clear about this but maybe we
> haven’t been clear enough.
>
>
>
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
>> "
>>
> Have you or anyone working 

Re: drm / drm2 removal in 12

[blubee blubeeme]

On Sun, Aug 26, 2018 at 9:08 AM Paul McNary  wrote:

> I think you can pay XinuOS to support FreeBSD in a LTS situation.
> It is just like linux where you have to pay Red Hat, Suse, etc.
> They break things even with point releases. Suse majorly
> screwed with video drivers back in the 9.x series. Totally
> broke major release. Their answer then was pay us or
> re-install bare metal and figure it out on your own.
> Other wise linux has always been, you get what you get for free.
> BSD is the same. If you are lucky some one like red hat, suse, XinuOS
> will be supporting and make their notes public, otherwise the
> OSS model doesn't include anything more than community support
> for what ever that is worth.
> I just upgraded a system from FreeBSD 9.x to 12.x, it took 2 weeks and
> several incremental upgrades sometimes to multiple point releases
> with in a major release. There is nothing really for free.
>
>
> On 8/25/2018 7:47 PM, blubee blubeeme wrote:
> > On Sun, Aug 26, 2018 at 8:16 AM Johannes Lundberg 
> > wrote:
> >
> >>
> >> On Sun, Aug 26, 2018 at 00:25 blubee blubeeme 
> wrote:
> >>
> >>> On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav 
> wrote:
> >>>
> >>>> blubee blubeeme  writes:
> >>>>> True on both points my tone is just a reflection of attitudes of the
> >>>>> individuals that I am currently addressing.
> >>>> Well, congratulations on alienating absolutely everybody you have
> >>>> interacted with on this topic.
> >>>>
> >>>>> Some people enjoy making contributions w/o waving a banner constantly
> >>>>> wanting acknowledgement, a pat on the head and good job from
> everyone.
> >>>> The only person I see constantly craving attention and validation from
> >>>> others here is you.
> >>>>
> >>>>> How far will core FreeBSD bend over backwards to accommodate these
> >>>>> devs.
> >>>> The core team does not decide what goes into the tree or not.  The
> >>>> developers do.
> >>>>
> >>>>> This is the beauty of an open source project, we bring the best to
> the
> >>>>> table, [...]
> >>>> Who exactly is “we” here?  You are not a member of the project, you do
> >>>> not speak for the project, and after seeing how you treat our fellow
> >>>> developers, our friends, most of us want nothing to do with you.  If
> >>>> can't live with that, I'm sure you can figure out how to install
> Linux.
> >>>>
> >>>> DES
> >>>> --
> >>>> Dag-Erling Smørgrav - d...@des.no
> >>>
> >>> Some on here want to attack my personality because they think that I am
> >>> abrasive, fine but that's not the issue.
> >>>
> >>> Some claim that they run the code and it works wonderful for them with
> no
> >>> issues, again that's lovely keep on running the code.
> >>>
> >>>   Nevertheless let me restate the point that you guys are all seeming
> to
> >>> miss; If you can go out and build custom kernels with custom options
> and
> >>> out of mainline tree that's fine, keep doing that until you have
> something
> >>> that's production ready and as easy to install as the rest of FreeBSD
> >>> system.
> >>>
> >>> The graphics stack on FreeBSD is pretty bad as it stands but all the
> >>> documentation currently out there is about using it as it stands now.
> >>>
> >>> Why do you need to rip out the current graphics drivers which will
> break
> >>> systems for the vast majority of silent users who will not complain and
> >>> just leave?
> >>>
> >>>  A little background 
> >>> Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update
> >>> their phones to the latest android version?
> >>>
> >>> It's because the Linux kernel is such a mess they know it's a waste of
> >>> resources to try. You should not have to ask how or why I know this
> but if
> >>> it's unclear I was in the field.
> >>> ---
> >>>
> >>> Now you guys who claim to only be hobbyist doing this in their free
> time
> >>> expect to maintain this when those companies with all their resources
> >>> cannot?
> >>>
> >&

Re: drm / drm2 removal in 12

[blubee blubeeme]

On Sun, Aug 26, 2018 at 10:05 AM Allan Jude  wrote:

> On 2018-08-25 21:20, blubee blubeeme wrote:
> > On Sun, Aug 26, 2018 at 9:08 AM Paul McNary  wrote:
> >
> >> I think you can pay XinuOS to support FreeBSD in a LTS situation.
> >> It is just like linux where you have to pay Red Hat, Suse, etc.
> >> They break things even with point releases. Suse majorly
> >> screwed with video drivers back in the 9.x series. Totally
> >> broke major release. Their answer then was pay us or
> >> re-install bare metal and figure it out on your own.
> >> Other wise linux has always been, you get what you get for free.
> >> BSD is the same. If you are lucky some one like red hat, suse, XinuOS
> >> will be supporting and make their notes public, otherwise the
> >> OSS model doesn't include anything more than community support
> >> for what ever that is worth.
> >> I just upgraded a system from FreeBSD 9.x to 12.x, it took 2 weeks and
> >> several incremental upgrades sometimes to multiple point releases
> >> with in a major release. There is nothing really for free.
> >>
> >>
> >> On 8/25/2018 7:47 PM, blubee blubeeme wrote:
> >>> On Sun, Aug 26, 2018 at 8:16 AM Johannes Lundberg 
> >>> wrote:
> >>>
> >>>>
> >>>> On Sun, Aug 26, 2018 at 00:25 blubee blubeeme 
> >> wrote:
> >>>>
> >>>>> On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav 
> >> wrote:
> >>>>>
> >>>>>> blubee blubeeme  writes:
> >>>>>>> True on both points my tone is just a reflection of attitudes of
> the
> >>>>>>> individuals that I am currently addressing.
> >>>>>> Well, congratulations on alienating absolutely everybody you have
> >>>>>> interacted with on this topic.
> >>>>>>
> >>>>>>> Some people enjoy making contributions w/o waving a banner
> constantly
> >>>>>>> wanting acknowledgement, a pat on the head and good job from
> >> everyone.
> >>>>>> The only person I see constantly craving attention and validation
> from
> >>>>>> others here is you.
> >>>>>>
> >>>>>>> How far will core FreeBSD bend over backwards to accommodate these
> >>>>>>> devs.
> >>>>>> The core team does not decide what goes into the tree or not.  The
> >>>>>> developers do.
> >>>>>>
> >>>>>>> This is the beauty of an open source project, we bring the best to
> >> the
> >>>>>>> table, [...]
> >>>>>> Who exactly is “we” here?  You are not a member of the project, you
> do
> >>>>>> not speak for the project, and after seeing how you treat our fellow
> >>>>>> developers, our friends, most of us want nothing to do with you.  If
> >>>>>> can't live with that, I'm sure you can figure out how to install
> >> Linux.
> >>>>>>
> >>>>>> DES
> >>>>>> --
> >>>>>> Dag-Erling Smørgrav - d...@des.no
> >>>>>
> >>>>> Some on here want to attack my personality because they think that I
> am
> >>>>> abrasive, fine but that's not the issue.
> >>>>>
> >>>>> Some claim that they run the code and it works wonderful for them
> with
> >> no
> >>>>> issues, again that's lovely keep on running the code.
> >>>>>
> >>>>>   Nevertheless let me restate the point that you guys are all seeming
> >> to
> >>>>> miss; If you can go out and build custom kernels with custom options
> >> and
> >>>>> out of mainline tree that's fine, keep doing that until you have
> >> something
> >>>>> that's production ready and as easy to install as the rest of FreeBSD
> >>>>> system.
> >>>>>
> >>>>> The graphics stack on FreeBSD is pretty bad as it stands but all the
> >>>>> documentation currently out there is about using it as it stands now.
> >>>>>
> >>>>> Why do you need to rip out the current graphics drivers which will
> >> break
> >>>>> systems for the vast majority of silent users who will not complain
> and
> >>&

Re: drm / drm2 removal in 12

[blubee blubeeme]

On Sun, Aug 26, 2018 at 10:51 AM cpghost  wrote:

> On 8/25/18 5:34 PM, Dave Cottlehuber wrote:
> >> On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen <
> sh+freebsd-curr...@codevoid.de>
>  On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote:
> > I've been personally using the new DRM bits since almost day one. I
> > haven't found it to be unstable in the slightest. Compared to not
> > having it and being forced to run 5+ year old hardware, it's been a
> > huge blessing for those of us who care about running FreeBSD as a
> > modern desktop / laptop.
> >
> > Ditto. I'd like to express my heartfelt thanks for all the people who
> have been
> > working on the drm-next code for over 2 years now. It's fantastic and an
> > incredible piece of effort to pull it all together.
>
> Same here. A big THANK YOU to the Graphics Team for drm-next.
> I've been running it on STABLE with amdgpu driver on an RX 580
> at 4K res, and had ZERO issues with it so far... except for broken
> opencl on drm-stable-kmod, but I can live with that until its fixed.
>
> > A+++
> > Dave
>
> -cpghost.
>
>
>
> There's a whole lot of cheerleading and that's wonderful keep it up. Enjoy
building and applying your patches no one will take that away from you guys.

Although the way you guys continually dodge, deflect and run away from 3
simple questions is astonishing, see below.

You guys can keep on cheerleading but that still doesn't answer the
questions that I have asked numerous time.

Cheerleading does not solve engineering problems, it's just noise.

I'll post this again to keep the focus on the issue at hand.

If The Graphics team has already done these tests, show us.
If The Graphics team has not, then maybe they should take some time to do
the work required get the code submitted upstream.


===
1) Take a [test] system with the current graphics stack installed and
working.
2) Apply your patches to remove the drm from base to create a port
3) update the working [test] system after applying your changes

How does your changes affect a [test] system that is already up and running?

Have any of you guys tried that? Do you have any documentation on how it'll
affect users.

You guys want to remove things from the current system but you come with;
it works for us hobbyists.
Where do users go to get steps to do all of this stuff?

You've repeatedly said what you want to do sure, but have you tested it?
___
freebsd-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: drm / drm2 removal in 12

[blubee blubeeme]

On Sun, Aug 26, 2018 at 4:32 PM Hans Petter Selasky  wrote:

> On 8/26/18 3:20 AM, blubee blubeeme wrote:
> > Have you or anyone working on this drm-legacy-kmod stuff done any
> testings
> > of how this will affect current users?
>
> Hi Blubee,
>
> Are you here to try to stir a conflict?
> If so that is not appreciated.
>
> --HPS
>
Hans, you of all people should know that's not true.

I would think that trying to sneak in code during a code freeze that would
break the release. Forcing the core devs to revert those changes and having
to dust off old policies to try to keep you guys in check is what's
stirring up conflicts, but hey; what do I know?

It's really sad state when capable engineers are so obsessed with something
that they cannot see the forest for the trees. Try to step away from the
canvas and look at the big picture.

If you don't mind me asking, Hans care to answer these questions below?
1) Take a [test] system with the current graphics stack installed and
working.
2) Apply your patches to remove the drm from base to create a port
3) update the working [test] system after applying your changes

How does your changes affect a [test] system that is already up and running?

Have any of you guys tried that? Do you have any documentation on how it'll
affect users.

You guys want to remove things from the current system but you come with;
it works for us hobbyists.
Where do users go to get steps to do all of this stuff?

You've repeatedly said what you want to do sure, but have you tested it?
___
freebsd-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: drm / drm2 removal in 12

[blubee blubeeme]

On Mon, Aug 27, 2018 at 2:39 AM Dag-Erling Smørgrav  wrote:

> blubee blubeeme  writes:
> > Hans Petter Selasky  writes:
> > > Are you here to try to stir a conflict?  If so that is not
> > > appreciated.
> > Hans, you of all people should know that's not true.
>
> And yet here we are.
>
> You have made it perfectly clear that you are not interested in an
> honest discussion.  Your entire strategy is to wear people down until
> they either leave or agree with you just to shut you up.  Like Hans
> Petter says, it is not appreciated.
>
> You clearly believe that you know better than anyone else how this
> should be handled, so instead of telling us, I suggest you just go do
> it.  It only takes seconds to fork the FreeBSD mirror on Github, and a
> few minutes to clone it onto your machine.  We look forward to hearing
> from you again when you have everything working perfectly and seamlessly
> out of the box for everybody on any equipment.  I'm sure that Johannes,
> Niclas, Warner and others with a century of combined experience will be
> thrilled to see you succeed where they, by your account, have failed.
>
> DES
> --
> Dag-Erling Smørgrav - d...@des.no


You seem to miss the point where the you avoid breaking the system for any
users not on the bleeding edge.

You technically adept guys can keep on hacking away, jumping through hoops
and building your stuff as you see fit.
Nobody will come take your steal your code away in the night. Feel free to
keep on working on it, until implementing it
doesn't break "old users" do the engineering work and improve your
implementation.

There are so many seemingly dead code projects around this linuxkpi stuff
that you guys just pump out code and abandon
inconsistent lack of documentation, lack of testing, it's just a huge mess.

Work on cleaning all that stuff up and bring something sensible to the
table, you cannot put onus on the core team to maintain
that mess going forward because you're not capable of doing it yourselves.
___
freebsd-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: Good motherboard for Ryzen (first-gen)

[blubee blubeeme]

On Sat, Sep 22, 2018 at 10:56 AM Eric van Gyzen  wrote:

> I would like to build a Ryzen desktop.  Can anyone recommend a good
> motherboard?
>
> I'm planning on a first-gen, because the second-gen has similar
> stability problems as the first-gen had, and AMD hasn't released errata
> for the second-gen yet (as far as I know...I would love to be wrong).
>
> I would like to be a cool kid with a Threadripper, but I can't justify
> the cost, so I'm thinking maybe a Ryzen 7 with /only/ 8 cores.  :)
>
> Ideally, I want an Intel NIC, ECC memory support, and a 3-year warranty.
>
> Thanks in advance,
>
> Eric
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>

I purchased MSI B350 Gaming Pro with a Ryzen 2600 it's been great but if
you plan to run FreeBSD you'll need a graphics card that's supported by the
current graphics drivers.

I found something quite old, it works with the drm2 drivers and there's no
issues. There's list of supported cards here:
https://wiki.freebsd.org/Graphics

There's work being done on improving the graphics drivers, soon you won't
need to get such old GPU.

As for ECC I don't think you'll find many 1st gen ryzen motherboards that
support that but I could be wrong, spec and datasheet here:
https://www.msi.com/Motherboard/B350M-GAMING-PRO/Specification
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

error: undefined symbol: main in poudriere jail

[blubee blubeeme]

This issue seemed to have come up in the past:
https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068870.html


Jail name: amd64_cur
Jail version:  12.0-ALPHA7 1200084
Jail vcs version:  r338898
Jail arch: amd64
Jail method:   svn
Jail mount:/usr/local/poudriere/jails/amd64_cur
Jail fs:   zroot/poudriere/jails/amd64_cur
Jail updated:  2018-09-24 03:39:31
Tree name: default
Tree method:   portsnap
Status:

error
/usr/bin/cc -pipe -fno-strict-aliasing -fno-common -fexceptions -std=gnu99
-m64 -Qunused-arguments -O3 -march=native -finline-functions -flto
-fomit-frame-pointer -pedantic -pedantic-errors -Wall -Wextra -Wundef
-Wfloat-equal -Wshadow -Wbad-function-cast -Wdeclaration-after-statement
-Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation
-m64 src/rttherm/CMakeFiles/rttherm.dir/spectrum.c.o
src/rttherm/CMakeFiles/rttherm.dir/viewtherm.c.o  -o bin/rttherm
-Wl,-rpath,/wrkdirs/usr/ports/cad/brlcad/work/.build/lib:/usr/local/lib:
lib/libged.so.20.0.1 lib/librtuif_multispectral.a
lib/libmultispectral.so.20.0.1 lib/libfb.so.20.0.1 lib/libpkg.so.20.0.1
/usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so
/usr/local/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so
/usr/local/lib/libGLU.so /usr/local/lib/libGL.so lib/libtk.so.8.5
/usr/local/lib/libX11.so /usr/local/lib/libXext.so lib/libtkstub.a
lib/libtclstub.a /usr/local/lib/libXrender.so lib/libwdb.so.20.0.1
lib/libicv.so.20.0.1 lib/libpng16.so.16.29.0 lib/libnetpbm.so
lib/libanalyze.so.20.0.1 lib/libtcl.so.8.5.19 lib/libclipper.so.4.6.0
lib/librt.so.20.0.1 lib/libnmg.so lib/libgdiam.so lib/libvds.so.1.0.1
lib/libbrep.so.20.0.1 lib/libbg.so.20.0.1 lib/libopenNURBS.so.2012.10.245
lib/libp2t.so.1.0.1 lib/libz.so.1.2.11 lib/libtinycthread.so lib/liblz4.so
lib/libbn.so.20.0.1 lib/libbu.so.20.0.1 lib/libregex.so.1.0.4 -lm -pthread
-ldl && :
FAILED: bin/rttherm
: && /usr/bin/cc -pipe -fno-strict-aliasing -fno-common -fexceptions
-std=gnu99 -m64 -Qunused-arguments -O3 -march=native -finline-functions
-flto -fomit-frame-pointer -pedantic -pedantic-errors -Wall -Wextra -Wundef
-Wfloat-equal -Wshadow -Wbad-function-cast -Wdeclaration-after-statement
-Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation
-m64 src/rttherm/CMakeFiles/rttherm.dir/spectrum.c.o
src/rttherm/CMakeFiles/rttherm.dir/viewtherm.c.o  -o bin/rttherm
-Wl,-rpath,/wrkdirs/usr/ports/cad/brlcad/work/.build/lib:/usr/local/lib:
lib/libged.so.20.0.1 lib/librtuif_multispectral.a
lib/libmultispectral.so.20.0.1 lib/libfb.so.20.0.1 lib/libpkg.so.20.0.1
/usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so
/usr/local/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so
/usr/local/lib/libGLU.so /usr/local/lib/libGL.so lib/libtk.so.8.5
/usr/local/lib/libX11.so /usr/local/lib/libXext.so lib/libtkstub.a
lib/libtclstub.a /usr/local/lib/libXrender.so lib/libwdb.so.20.0.1
lib/libicv.so.20.0.1 lib/libpng16.so.16.29.0 lib/libnetpbm.so
lib/libanalyze.so.20.0.1 lib/libtcl.so.8.5.19 lib/libclipper.so.4.6.0
lib/librt.so.20.0.1 lib/libnmg.so lib/libgdiam.so lib/libvds.so.1.0.1
lib/libbrep.so.20.0.1 lib/libbg.so.20.0.1 lib/libopenNURBS.so.2012.10.245
lib/libp2t.so.1.0.1 lib/libz.so.1.2.11 lib/libtinycthread.so lib/liblz4.so
lib/libbn.so.20.0.1 lib/libbu.so.20.0.1 lib/libregex.so.1.0.4 -lm -pthread
-ldl && :
/usr/bin/ld: error: undefined symbol: main
>>> referenced by crt1.c:74
(/usr/local/poudriere/jails/amd64_cur/usr/src/lib/csu/amd64/crt1.c:74)
>>>   /usr/lib/crt1.o:(_start)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
*** Error code 1
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: error: undefined symbol: main in poudriere jail

[blubee blubeeme]

On Mon, Sep 24, 2018 at 7:31 AM blubee blubeeme  wrote:

> This issue seemed to have come up in the past:
> https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068870.html
>
>
> Jail name: amd64_cur
> Jail version:  12.0-ALPHA7 1200084
> Jail vcs version:  r338898
> Jail arch: amd64
> Jail method:   svn
> Jail mount:/usr/local/poudriere/jails/amd64_cur
> Jail fs:   zroot/poudriere/jails/amd64_cur
> Jail updated:  2018-09-24 03:39:31
> Tree name: default
> Tree method:   portsnap
> Status:
>
> error
> /usr/bin/cc -pipe -fno-strict-aliasing -fno-common -fexceptions -std=gnu99
> -m64 -Qunused-arguments -O3 -march=native -finline-functions -flto
> -fomit-frame-pointer -pedantic -pedantic-errors -Wall -Wextra -Wundef
> -Wfloat-equal -Wshadow -Wbad-function-cast -Wdeclaration-after-statement
> -Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation
> -m64 src/rttherm/CMakeFiles/rttherm.dir/spectrum.c.o
> src/rttherm/CMakeFiles/rttherm.dir/viewtherm.c.o  -o bin/rttherm
> -Wl,-rpath,/wrkdirs/usr/ports/cad/brlcad/work/.build/lib:/usr/local/lib:
> lib/libged.so.20.0.1 lib/librtuif_multispectral.a
> lib/libmultispectral.so.20.0.1 lib/libfb.so.20.0.1 lib/libpkg.so.20.0.1
> /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so
> /usr/local/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so
> /usr/local/lib/libGLU.so /usr/local/lib/libGL.so lib/libtk.so.8.5
> /usr/local/lib/libX11.so /usr/local/lib/libXext.so lib/libtkstub.a
> lib/libtclstub.a /usr/local/lib/libXrender.so lib/libwdb.so.20.0.1
> lib/libicv.so.20.0.1 lib/libpng16.so.16.29.0 lib/libnetpbm.so
> lib/libanalyze.so.20.0.1 lib/libtcl.so.8.5.19 lib/libclipper.so.4.6.0
> lib/librt.so.20.0.1 lib/libnmg.so lib/libgdiam.so lib/libvds.so.1.0.1
> lib/libbrep.so.20.0.1 lib/libbg.so.20.0.1 lib/libopenNURBS.so.2012.10.245
> lib/libp2t.so.1.0.1 lib/libz.so.1.2.11 lib/libtinycthread.so lib/liblz4.so
> lib/libbn.so.20.0.1 lib/libbu.so.20.0.1 lib/libregex.so.1.0.4 -lm -pthread
> -ldl && :
> FAILED: bin/rttherm
> : && /usr/bin/cc -pipe -fno-strict-aliasing -fno-common -fexceptions
> -std=gnu99 -m64 -Qunused-arguments -O3 -march=native -finline-functions
> -flto -fomit-frame-pointer -pedantic -pedantic-errors -Wall -Wextra -Wundef
> -Wfloat-equal -Wshadow -Wbad-function-cast -Wdeclaration-after-statement
> -Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation
> -m64 src/rttherm/CMakeFiles/rttherm.dir/spectrum.c.o
> src/rttherm/CMakeFiles/rttherm.dir/viewtherm.c.o  -o bin/rttherm
> -Wl,-rpath,/wrkdirs/usr/ports/cad/brlcad/work/.build/lib:/usr/local/lib:
> lib/libged.so.20.0.1 lib/librtuif_multispectral.a
> lib/libmultispectral.so.20.0.1 lib/libfb.so.20.0.1 lib/libpkg.so.20.0.1
> /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so
> /usr/local/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so
> /usr/local/lib/libGLU.so /usr/local/lib/libGL.so lib/libtk.so.8.5
> /usr/local/lib/libX11.so /usr/local/lib/libXext.so lib/libtkstub.a
> lib/libtclstub.a /usr/local/lib/libXrender.so lib/libwdb.so.20.0.1
> lib/libicv.so.20.0.1 lib/libpng16.so.16.29.0 lib/libnetpbm.so
> lib/libanalyze.so.20.0.1 lib/libtcl.so.8.5.19 lib/libclipper.so.4.6.0
> lib/librt.so.20.0.1 lib/libnmg.so lib/libgdiam.so lib/libvds.so.1.0.1
> lib/libbrep.so.20.0.1 lib/libbg.so.20.0.1 lib/libopenNURBS.so.2012.10.245
> lib/libp2t.so.1.0.1 lib/libz.so.1.2.11 lib/libtinycthread.so lib/liblz4.so
> lib/libbn.so.20.0.1 lib/libbu.so.20.0.1 lib/libregex.so.1.0.4 -lm -pthread
> -ldl && :
> /usr/bin/ld: error: undefined symbol: main
> >>> referenced by crt1.c:74
> (/usr/local/poudriere/jails/amd64_cur/usr/src/lib/csu/amd64/crt1.c:74)
> >>>   /usr/lib/crt1.o:(_start)
> cc: error: linker command failed with exit code 1 (use -v to see
> invocation)
> ninja: build stopped: subcommand failed.
> *** Error code 1
>
> I though that it could be an issue with portsnap so I created a new jail
using svn

 poudriere jails -j amd64HD -i
Jail name: amd64HD
Jail version:  12.0-ALPHA7 1200084
Jail vcs version:  r338899
Jail arch: amd64
Jail method:   svn
Jail mount:/usr/local/poudriere/jails/amd64HD
Jail fs:   zroot/poudriere/jails/amd64HD
Jail updated:  2018-09-24 07:34:06
Tree name: default
Tree method:   portsnap
Status:

error
#include 
__FBSDID("$FreeBSD: head/lib/csu/amd64/crt1.c 326219 2017-11-26 02:00:33Z
pfg $");

#include 

#include "libc_private.h"
#include "crtbrand.c"
#include "ignore_init.c"

typedef void (*fptr)(void);

#ifdef GCRT
extern void _mcleanup(void);
extern void monstartup(void *, void *);
exter

Re: linux-c7 and opengl apps?

[blubee blubeeme]

On Wed, Oct 3, 2018 at 5:40 PM Johannes Lundberg  wrote:

> Hi
>
> Have anyone successfully run opengl apps with linux-c7?
>
> Linux opengl apps works great with linux-c6 on gpu < kabylake but
> linux-c6-dri does not include support for kabylake gpus.
> Linux glxinfo in c7 show support for hardware rendering on kabylake but any
> attempt to run an opengl app results in application seg fault or other
> crash (I believe this is also the case with skylake gpus on linux-c7).
>
> Is there any way to run gdb on linux apps/core dumps?
>
> /Johannes
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>

Highly unlikely since the Linux kernel memory model is pretty different
than FreeBSD especially concerning graphics.

Linux kernel graphics will have to use dma regions or the low kernel memory
while most other stuff hangs out in the high kernel memory.

Since the graphics drivers have to have contiguous memory regions that
should not be swapped out, if linuxkpi doesn't manage these complexities
you'll continue to random failures especially around sleep to wake, context
switching and power management.

It can be fixed though, you'll just need to port the entire Linux memory
architecture to FreeBSD and that's as it stands right now.

Don't look into rma, numa, hhm, huge pages and all the other lovely memory
features that is currently mainline or about to get merged into mainline.

Good luck with that though.

Best,
Owen
___
freebsd-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: linux-c7 and opengl apps?

[blubee blubeeme]

On Fri, Oct 5, 2018 at 11:50 PM Greg V  wrote:

>
>
> On Wed, Oct 3, 2018 at 12:36 PM, Johannes Lundberg 
> wrote:
> > Hi
> >
> > Have anyone successfully run opengl apps with linux-c7?
> >
> > Linux opengl apps works great with linux-c6 on gpu < kabylake but
> > linux-c6-dri does not include support for kabylake gpus.
> > Linux glxinfo in c7 show support for hardware rendering on kabylake
> > but any
> > attempt to run an opengl app results in application seg fault or other
> > crash (I believe this is also the case with skylake gpus on linux-c7).
>
> On AMD Polaris: everything used to work in an ubuntu 16.04 chroot
> (currently having "can't open display :0" with that, probably
> forgetting something).
>
> Trying Unigine Heaven with c7, segfaults right now. glxinfo shows
> everything correctly though.
>
> > Is there any way to run gdb on linux apps/core dumps?
>
> There was a BSDCan talk that mentioned some gdb solutions:
>
> https://www.youtube.com/watch?v=9N3NrPeCJpk
>
> https://www.bsdcan.org/2018/schedule/attachments/473_linuxulator-notes-bsdcan2018.txt
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
In the video, you guys run into issues w/ debugging core dumps. While this
doesn't make any sense, you guys are free to write your own Linux core dump
disassembler.

Core dumps are created this way:
https://github.com/torvalds/linux/blob/master/fs/binfmt_elf.c#L97

The elf format is documented online. Once that's done you have all the
registers, heap, stack, data and you can play from there.

Writing a disassembler should be childs play, shouldn't it?

Best
___
freebsd-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: Page fault in midi/sequencer.c

[blubee blubeeme]

On Sun, Oct 21, 2018 at 12:59 AM Peter Holm  wrote:

> I can trigger this on 13.0-CURRENT r339445 with a non-root test program:
>
> Calling uiomove() with the following non-sleepable locks held:
> exclusive sleep mutex seqflq (seqflq) r = 0 (0xf80003860c08) locked @
> dev/sound/midi/sequencer.c:952
> stack backtrace:
> #0 0x80bfe263 at witness_debugger+0x73
> #1 0x80bff1b8 at witness_warn+0x448
> #2 0x80bf6a91 at uiomove_faultflag+0x71
> #3 0x809439e6 at mseq_write+0x4c6
> #4 0x80a4f725 at devfs_write_f+0x185
> #5 0x80c02a87 at dofilewrite+0x97
> #6 0x80c0287f at kern_pwritev+0x5f
> #7 0x80c0277d at sys_pwrite+0x8d
> #8 0x81070af7 at amd64_syscall+0x2a7
> #9 0x8104a4ad at fast_syscall_common+0x101
> Kernel page fault with the following non-sleepable locks held:
> exclusive sleep mutex seqflq (seqflq) r = 0 (0xf80003860c08) locked @
> dev/sound/midi/sequencer.c:952
> stack backtrace:
> #0 0x80bfe263 at witness_debugger+0x73
> #1 0x80bff1b8 at witness_warn+0x448
> #2 0x810700d3 at trap_pfault+0x53
> #3 0x8106f70a at trap+0x2ba
> #4 0x81049bc5 at calltrap+0x8
> #5 0x80bf6b42 at uiomove_faultflag+0x122
> #6 0x809439e6 at mseq_write+0x4c6
> #7 0x80a4f725 at devfs_write_f+0x185
> #8 0x80c02a87 at dofilewrite+0x97
> #9 0x80c0287f at kern_pwritev+0x5f
> #10 0x80c0277d at sys_pwrite+0x8d
> #11 0x81070af7 at amd64_syscall+0x2a7
> #12 0x8104a4ad at fast_syscall_common+0x101
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 4; apic id = 04
> fault virtual address = 0x20ea6b
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x8106d32d
> stack pointer = 0x28:0xfe00a844a660
> frame pointer = 0x28:0xfe00a844a660
> 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  = 2356 (xxx)
> [ thread pid 2356 tid 100278 ]
> Stopped at  copyin_nosmap_erms+0xdd:movl(%rsi),%edx
> db>
>
> --
> Peter
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
It's a known fault in the oss implementation midi parsing code. The easiest
route is to use something else to parse midi for the time being.

OSS was ported over and many outstanding bugs are still laying around.

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

A quick question

[blubee blubeeme]

Hi

I am on a Macbook pro 11,3 and I wanted to start trying to help sort out
some problems that might be too small for the overall team but might help
others in the future.

Anyways I am on 12-CURRENT but when I installed from the USB stick I didn't
check the docs and 32 bit binaries.

svn checkout svn://svn.freebsd.org/base/head /usr/src
svn checkout svn://svn.freebsd.org/ports/head /usr/ports
svn checkout svn://svn.freebsd.org/doc/head /usr/doc

once I do the above steps, do I have to rebuild the entire world? Currently
all I am missing is the 32 bit binaries, could I just rebuild those instead
of building the entire system?


Best,
Owen
___
freebsd-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: A quick question

[blubee blubeeme]

Can I bump this issue one more time?

On Sun, Dec 18, 2016, 18:38 Dave Cottlehuber  wrote:

> On Sun, 18 Dec 2016, at 10:07, blubee blubeeme wrote:
> > Hi
> >
> > I am on a Macbook pro 11,3 and I wanted to start trying to help sort out
> > some problems that might be too small for the overall team but might help
> > others in the future.
>
> \o/ there are a few of us about, I'm using a MacBookPro 11,2.
>
> > Anyways I am on 12-CURRENT but when I installed from the USB stick I
> > didn't
> > check the docs and 32 bit binaries.
> >
> > svn checkout svn://svn.freebsd.org/base/head /usr/src
> > svn checkout svn://svn.freebsd.org/ports/head /usr/ports
> > svn checkout svn://svn.freebsd.org/doc/head /usr/doc
> >
> > once I do the above steps, do I have to rebuild the entire world?
> > Currently
> > all I am missing is the 32 bit binaries, could I just rebuild those
> > instead
> > of building the entire system?
> >
> >
> > Best,
> > Owen
>
> Hi Owen
>
> You probably only need to unpack
> http://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/12.0-CURRENT/*.txz ;
> I'm assuming this snapshot is still from the same date as your
> installer. If your USB stick has the txz on it, then you can extract
> them from there as well. Something like
>
> tar -xf docs.txz -C /
>
> is probably all you need. NB not tested, viz xkcd.com/1168
>
> A+
> Dave
> ___
> freebsd-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: A quick question

[blubee blubeeme]

Thanks for the follow-up.

On Sat, Dec 24, 2016, 17:08 Dave Cottlehuber  wrote:

> On Wed, 21 Dec 2016, at 06:39, blubee blubeeme wrote:
> > Can I bump this issue one more time?
> >
> > On Sun, Dec 18, 2016, 18:38 Dave Cottlehuber  wrote:
> >
> > > On Sun, 18 Dec 2016, at 10:07, blubee blubeeme wrote:
> > > > Hi
> > > >
> > > > I am on a Macbook pro 11,3 and I wanted to start trying to help sort
> out
> > > > some problems that might be too small for the overall team but might
> help
> > > > others in the future.
> > >
> > > \o/ there are a few of us about, I'm using a MacBookPro 11,2.
> > >
> > > > Anyways I am on 12-CURRENT but when I installed from the USB stick I
> > > > didn't
> > > > check the docs and 32 bit binaries.
> > > >
> > > > svn checkout svn://svn.freebsd.org/base/head /usr/src
> > > > svn checkout svn://svn.freebsd.org/ports/head /usr/ports
> > > > svn checkout svn://svn.freebsd.org/doc/head /usr/doc
> > > >
> > > > once I do the above steps, do I have to rebuild the entire world?
> > > > Currently
> > > > all I am missing is the 32 bit binaries, could I just rebuild those
> > > > instead
> > > > of building the entire system?
> > > >
> > > >
> > > > Best,
> > > > Owen
> > >
> > > Hi Owen
> > >
> > > You probably only need to unpack
> > > http://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/12.0-CURRENT/*.txz
> ;
> > > I'm assuming this snapshot is still from the same date as your
> > > installer. If your USB stick has the txz on it, then you can extract
> > > them from there as well. Something like
> > >
> > > tar -xf docs.txz -C /
> > >
> > > is probably all you need. NB not tested, viz xkcd.com/1168
> > >
> > > A+
> > > Dave
> > another question to make sure.
> >
> > looking at the url:
> http://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/12.0-CURRENT/
> >
> > I see the MANIFEST along with
> >
> > base-dbg.txz
> > base..
> > doc..
> > kernel-dbg...
> > etc.
> >
> > so when I install FreeBSD based on the installation items that I select,
> it just unpacks
> > one of the above listed file right into the / directory on the hdd?
>
> Sorry Christmas got in the way of emails.
>
> Yes, you can see here in pc-sysinstall:
>
>
> https://svnweb.freebsd.org/base/release/11.0.0/usr.sbin/pc-sysinstall/backend/functions-extractimage.sh?view=markup#l57
>
> the excellent 3rd party mfsbsd tool does the same thing to install
> FreeBSD:
>
> https://github.com/mmatuska/mfsbsd/blob/master/tools/zfsinstall#L354-L356
>
> A+
> Dave
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

A question about updating src & ports

[blubee blubeeme]

Howdy

I went through the process of building world for the first time, that was
interesting but I got it. svn clean up prior object files, build world,
kernel, etc.

Okay that part is fine

I have a question about keeping ports up to date, in the past I did
portsnap fetch update to update the ports but since I totally deleted all
the ports and used svn checkout to get the latest ports.

Can I mix portsnap fetch update or should I just continue to use svn update
/usr/ports

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

current freebsd graphics stack

[blubee blubeeme]

Howdy

Is there anyone on this list that works on the graphics stack for FreeBSD?

Watching this video: https://www.youtube.com/watch?v=dZI4pAvK_RY&spfreload=5

from a few years ago and what I've gathered so far the new x is getting a
major redesign and a lot of code is moving into the kernel.

You can take a look at the attached images to get the tl;dr of the talk.

http://imgur.com/a/Ek4fq

My question, is anyone here whose doing graphics stack work done any work
on implementing GEM, KMS, DRM in the FreeBSD kernel.

Even a port of the linux version would be somewhere to start.

Best,
Owen
___
freebsd-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: current freebsd graphics stack

[blubee blubeeme]

Hi Johannes

I was asking about the current state of those three main items.

I just looked at the linuxkpi thing and it's a wrapper around the linux
version of DRM but isn't DRM a open standard, if we keep chasing down linux
the more they move their stuff into their kernel the harder it will become
to maintain these things on FreeBSD even though it might be more work
upfront?

It seems like evdev is the same story, xorg was moving to libinput, I
believe.

Is there a reason why we have to wrap the linux things and why couldn't we
just write our own that can then be tied closely to the BSD kernel while
still sticking to the standards.

To be honest I don't have the slightest idea how massive GEM, KMS and DRM
are just yet but it seems like adding a wrapper around another OS kernel
into that mix can only go bad.

How many people are working on the project with you at the moment?

Best,
Owen

On Tue, Jan 3, 2017 at 5:42 PM, Johannes Lundberg 
wrote:

> Hi Owen
>
> I've been helping out with drm, i915, linuxkpi and evdev in the kernel.
>
> For userland I'm working on Wayland-related stuff.
>
> You can check my twitter (@johalun) or this mailing list for my earlier
> posts about how to use this work.
>
> Sorry for asking but exactly what is your question now again?
>
>
> On Tue, Jan 3, 2017 at 16:58 blubee blubeeme  wrote:
>
>> Howdy
>>
>>
>>
>> Is there anyone on this list that works on the graphics stack for FreeBSD?
>>
>>
>>
>> Watching this video: https://www.youtube.com/watch?
>> v=dZI4pAvK_RY&spfreload=5
>>
>>
>>
>> from a few years ago and what I've gathered so far the new x is getting a
>>
>> major redesign and a lot of code is moving into the kernel.
>>
>>
>>
>> You can take a look at the attached images to get the tl;dr of the talk.
>>
>>
>>
>> http://imgur.com/a/Ek4fq
>>
>>
>>
>> My question, is anyone here whose doing graphics stack work done any work
>>
>> on implementing GEM, KMS, DRM in the FreeBSD kernel.
>>
>>
>>
>> Even a port of the linux version would be somewhere to start.
>>
>>
>>
>> Best,
>>
>> Owen
>>
>> ___
>>
>> freebsd-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: current freebsd graphics stack

[blubee blubeeme]

It's understandable and I actually came across your twitter account a long
time ago before I joined this list.

I did look at intels open source gpu drivers. I will be attempting after a
smaller project to get it up and running on BSD without using the linux
wrappers. Crazy, I know but nothing tried nothing done and I'm stubborn
enough to do the work now to have an easier time later.

This is a pretty complex subject and it does touch so many different things
that are all trying to change, the complexity is pretty high.

We'll see if we can sort that out.

Best,
Owen

On Tue, Jan 3, 2017 at 6:45 PM, Johannes Lundberg 
wrote:

> Hi
>
> Not sure about the other graphics drivers but porting a driver like
> drm/i915 for Intel graphics is a massive undertaking (look at the source
> code from Intel!). Intel develops their open source driver for Linux and
> having linuxkpi reduces porting efforts for us from a full time job to a
> few weekends / year. Remember how we had to wait 5 years for Haswell
> support? That's the only reason I had to run Linux for several years
> instead of FreeBSD (and a lot of development time went into Linux just
> because of that, wasted). linuxkpi and friends will be optional, you don't
> have to use if you don't want to.
>
> I'm all for a BSDish system with X & Wayland compositors and GUIs and the
> whole package. But, who's gonna have the time to develop/maintain it? What
> happens when we no longer can run Qt/GTK applications and only a small
> subset of BSD-friendly apps?
>
> I agree with what your saying, but we have to be realistic. Adding
> optional wrapper/support in the kernel plus a thin userland layer like udev
> or epoll etc, does not "taint" FreeBSD in anyway, rather it allows us to
> use newer hardware and a larger set of software with minimal porting
> efforts.
>
> On this project? Not many, we need a lot more.
>
>
> On Tue, Jan 3, 2017 at 6:15 PM, blubee blubeeme 
> wrote:
>
>> Hi Johannes
>>
>> I was asking about the current state of those three main items.
>>
>> I just looked at the linuxkpi thing and it's a wrapper around the linux
>> version of DRM but isn't DRM a open standard, if we keep chasing down linux
>> the more they move their stuff into their kernel the harder it will become
>> to maintain these things on FreeBSD even though it might be more work
>> upfront?
>>
>> It seems like evdev is the same story, xorg was moving to libinput, I
>> believe.
>>
>> Is there a reason why we have to wrap the linux things and why couldn't
>> we just write our own that can then be tied closely to the BSD kernel while
>> still sticking to the standards.
>>
>> To be honest I don't have the slightest idea how massive GEM, KMS and DRM
>> are just yet but it seems like adding a wrapper around another OS kernel
>> into that mix can only go bad.
>>
>> How many people are working on the project with you at the moment?
>>
>> Best,
>> Owen
>>
>> On Tue, Jan 3, 2017 at 5:42 PM, Johannes Lundberg 
>> wrote:
>>
>>> Hi Owen
>>>
>>> I've been helping out with drm, i915, linuxkpi and evdev in the kernel.
>>>
>>> For userland I'm working on Wayland-related stuff.
>>>
>>> You can check my twitter (@johalun) or this mailing list for my earlier
>>> posts about how to use this work.
>>>
>>> Sorry for asking but exactly what is your question now again?
>>>
>>>
>>> On Tue, Jan 3, 2017 at 16:58 blubee blubeeme 
>>> wrote:
>>>
>>>> Howdy
>>>>
>>>>
>>>>
>>>> Is there anyone on this list that works on the graphics stack for
>>>> FreeBSD?
>>>>
>>>>
>>>>
>>>> Watching this video: https://www.youtube.com/watch?
>>>> v=dZI4pAvK_RY&spfreload=5
>>>>
>>>>
>>>>
>>>> from a few years ago and what I've gathered so far the new x is getting
>>>> a
>>>>
>>>> major redesign and a lot of code is moving into the kernel.
>>>>
>>>>
>>>>
>>>> You can take a look at the attached images to get the tl;dr of the talk.
>>>>
>>>>
>>>>
>>>> http://imgur.com/a/Ek4fq
>>>>
>>>>
>>>>
>>>> My question, is anyone here whose doing graphics stack work done any
>>>> work
>>>>
>>>> on implementing GEM, KMS, DRM in the FreeBSD kernel.
>>>>
>>>>
>>>>
>>>> Even a port of the linux version would be somewhere to start.
>>>>
>>>>
>>>>
>>>> Best,
>>>>
>>>> Owen
>>>>
>>>> ___
>>>>
>>>> freebsd-current@freebsd.org mailing list
>>>>
>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>>
>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f
>>>> reebsd.org"
>>>>
>>>>
>>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: current freebsd graphics stack

[blubee blubeeme]

I haven't looked at dragonfly I saw a few talks from the FreeBSD guys and
it seemed like the main reason for dragonfly was misguided. I am interested
in solving the problem within the constraints set fourth by FreeBSD so I
won't be forking anything. I might look at that project though.

I think the correct way to say it is that if Gallium and AMD conform to the
open standard they should work with KMS and the likes. It'll be hard to go
and try to talk to them with nothing to show them and hoping they'll
support; that'll only happen in a perfect world.

You came back to BSD after some work was done, I doubt you are the only
person out there who would like to return. Companies follow the money,
let's make FreeBSD attractable so that the customers come and that will
bring the support from the big players. Right now we are paupers begging
and picking up scraps from linux table. Not only that, since they are the
loudest voice in the room right now, they will try and push these things in
ways that might not be beneficial for BSD.

I cam to BSD because I got tired of debian being too outdated, opensuse
doesn't let me not have a DM and fedora w/o gnome might as well be a brick.
All of that started because of sysemd so I have no choice but to do what I
can to improve things over here.

Best,
Owen

On Tue, Jan 3, 2017 at 6:55 PM, Johannes Lundberg 
wrote:

> Isn't that the way it was done before and is done on DragonFly?
>
> Don't forget, linuxkpi also supports AMD and Gallium drivers
>
> It is a complex subject.. in a perfect world we'd have unlimited time and
> resources and FreeBSD would be in every man's hand  :)
>
> Good luck!
>
> On Tue, Jan 3, 2017 at 18:50 blubee blubeeme  wrote:
>
>> It's understandable and I actually came across your twitter account a
>> long time ago before I joined this list.
>>
>> I did look at intels open source gpu drivers. I will be attempting after
>> a smaller project to get it up and running on BSD without using the linux
>> wrappers. Crazy, I know but nothing tried nothing done and I'm stubborn
>> enough to do the work now to have an easier time later.
>>
>> This is a pretty complex subject and it does touch so many different
>> things that are all trying to change, the complexity is pretty high.
>>
>> We'll see if we can sort that out.
>>
>> Best,
>> Owen
>>
>> On Tue, Jan 3, 2017 at 6:45 PM, Johannes Lundberg 
>> wrote:
>>
>> Hi
>>
>> Not sure about the other graphics drivers but porting a driver like
>> drm/i915 for Intel graphics is a massive undertaking (look at the source
>> code from Intel!). Intel develops their open source driver for Linux and
>> having linuxkpi reduces porting efforts for us from a full time job to a
>> few weekends / year. Remember how we had to wait 5 years for Haswell
>> support? That's the only reason I had to run Linux for several years
>> instead of FreeBSD (and a lot of development time went into Linux just
>> because of that, wasted). linuxkpi and friends will be optional, you don't
>> have to use if you don't want to.
>>
>> I'm all for a BSDish system with X & Wayland compositors and GUIs and the
>> whole package. But, who's gonna have the time to develop/maintain it? What
>> happens when we no longer can run Qt/GTK applications and only a small
>> subset of BSD-friendly apps?
>>
>> I agree with what your saying, but we have to be realistic. Adding
>> optional wrapper/support in the kernel plus a thin userland layer like udev
>> or epoll etc, does not "taint" FreeBSD in anyway, rather it allows us to
>> use newer hardware and a larger set of software with minimal porting
>> efforts.
>>
>> On this project? Not many, we need a lot more.
>>
>>
>> On Tue, Jan 3, 2017 at 6:15 PM, blubee blubeeme 
>> wrote:
>>
>> Hi Johannes
>>
>> I was asking about the current state of those three main items.
>>
>> I just looked at the linuxkpi thing and it's a wrapper around the linux
>> version of DRM but isn't DRM a open standard, if we keep chasing down linux
>> the more they move their stuff into their kernel the harder it will become
>> to maintain these things on FreeBSD even though it might be more work
>> upfront?
>>
>> It seems like evdev is the same story, xorg was moving to libinput, I
>> believe.
>>
>> Is there a reason why we have to wrap the linux things and why couldn't
>> we just write our own that can then be tied closely to the BSD kernel while
>> still sticking to the standards.
>>
>> To be hon

linuxkpi

[blubee blubeeme]

I was looking at the linuxkpi source code in /sys/compat/linuxkpi and I had
a question.

A lot of those files just look like linux files brought over to FreeBSD, is
there any reason why those files couldn't be implemented in BSD w/o the
dependencies on the other Linux headers?

For example this header file:
sys/compat/linuxkpi/common/include/linux/workqueue.h

the workqueue.h, there doesn't seem to be anything special in there that
couldn't be implemented in BSD without relying on the Linux import
statements.

Maybe I'm missing something but why can't these files and functions be
implemented directly with their BSD equivalents?

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

firefox/ rust failed to install on FreeBSD 12-CURRENT

[blubee blubeeme]

I'm trying to install firefox on FreeBSD
FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT
#0 r318998: Sun May 28 04:38:22 CST 2017
/usr/obj/usr/src/sys/GENERIC  amd64

===>   firefox-i18n-53.0.3 depends on file: /usr/local/lib/firefox/firefox
- not found
===>   firefox-53.0.3_1,1 depends on package: nspr>=4.13.1 - found
===>   firefox-53.0.3_1,1 depends on package: nss>=3.29.5 - found
===>   firefox-53.0.3_1,1 depends on package: libevent>=2.0.21_2 - found
===>   firefox-53.0.3_1,1 depends on package: harfbuzz>=1.4.1 - found
===>   firefox-53.0.3_1,1 depends on package: graphite2>=1.3.8 - found
===>   firefox-53.0.3_1,1 depends on package: png>=1.6.28 - found
===>   firefox-53.0.3_1,1 depends on package: libvorbis>=1.3.5,3 - found
===>   firefox-53.0.3_1,1 depends on package: libvpx>=1.5.0 - found
===>   firefox-53.0.3_1,1 depends on package: sqlite3>=3.17.0 - found
===>   firefox-53.0.3_1,1 depends on package: py27-sqlite3>0 - found
===>   firefox-53.0.3_1,1 depends on package: v4l_compat>0 - found
===>   firefox-53.0.3_1,1 depends on executable: autoconf-2.13 - found
===>   firefox-53.0.3_1,1 depends on executable: yasm - found
===>   firefox-53.0.3_1,1 depends on executable: zip - found
===>   firefox-53.0.3_1,1 depends on package: gtk3>=3.14.6 - found
===>   firefox-53.0.3_1,1 depends on package: libnotify>0 - found
===>   firefox-53.0.3_1,1 depends on executable: rustc - not found
===>  Building for rust-1.17.0
gmake[7]: Entering directory '/usr/ports/lang/rust/work/rustc-1.17.0-src'
"/usr/local/bin/python2.7"
/usr/ports/lang/rust/work/rustc-1.17.0-src/src/bootstrap/bootstrap.py build
-v
info: looks like you are running this command under `sudo`
  and so in order to preserve your $HOME this will now
  use vendored sources by default. Note that if this
  does not work you should run a normal build first
  before running a command like `sudo make install`
extracting
/usr/ports/lang/rust/work/rustc-1.17.0-src/build/cache/2017-03-11/rust-std-1.16.0-x86_64-unknown-freebsd.tar.gz
  extracting
rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd
  extracting
rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/lib
  extracting
rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/
manifest.in
  extracting
rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/lib/rustlib
  extracting
rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd
  extracting
rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd/lib
  extracting
rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd/lib/GNUSparseFile.0/librustc_llvm-74a1be1110b5d4d0.so
gmake[7]: Leaving directory '/usr/ports/lang/rust/work/rustc-1.17.0-src'
*** Error code 1

Stop.
make[6]: stopped in /usr/ports/lang/rust
*** Error code 1

Stop.
make[5]: stopped in /usr/ports/lang/rust
*** Error code 1

Stop.
make[4]: stopped in /usr/ports/www/firefox
*** Error code 1

Stop.
make[3]: stopped in /usr/ports/www/firefox
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/www/firefox-i18n
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/www/firefox-i18n
*** Error code 1

Stop.
make: stopped in /usr/ports/www/firefox-i18n


I am getting build failures with or without make_build_unsafe flags.

I am building from source and ports tree is updated to revision 441919.

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

nvidia drivers mutex lock

[blubee blubeeme]

I'm running nvidia-drivers 375.66 with a GTX 1070 on FreeBSD-Current

This problem just started happening recently but, every so often my laptop
screen will just blank out and then I have to power cycle to get the
machine up and running again.

It seems to be a problem with nvidia drivers acquiring duplicate lock. Any
info on this?

Jun  2 02:29:41 blubee kernel: acquiring duplicate lock of same type:
"os.lock_mtx"
Jun  2 02:29:41 blubee kernel: 1st os.lock_mtx @ nvidia_os.c:841
Jun  2 02:29:41 blubee kernel: 2nd os.lock_mtx @ nvidia_os.c:841
Jun  2 02:29:41 blubee kernel: stack backtrace:
Jun  2 02:29:41 blubee kernel: #0 0x80ab7770 at
witness_debugger+0x70
Jun  2 02:29:41 blubee kernel: #1 0x80ab7663 at
witness_checkorder+0xe23
Jun  2 02:29:41 blubee kernel: #2 0x80a35b93 at
__mtx_lock_flags+0x93
Jun  2 02:29:41 blubee kernel: #3 0x82f4397b at
os_acquire_spinlock+0x1b
Jun  2 02:29:41 blubee kernel: #4 0x82c48b15 at _nv012002rm+0x185
Jun  2 02:29:41 blubee kernel: ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM:
Argument #4 type mismatch - Found [Buffer], ACPI requires [Package]
(20170303/nsarguments-205)
Jun  2 02:29:42 blubee kernel: nvidia-modeset: Allocated GPU:0
(GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ PCI::01:00.0

Best,
Owen
___
freebsd-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: nvidia drivers mutex lock

[blubee blubeeme]

Hi @tomoaki
Is that version of nvidia drivers currently in the ports tree? I just
checked but it seems not to be.

@jeffrey
I just generated a new xorg based on the force composition setting. I
merged it with my previous xorg I'll reboot, see if it gives better
performance.

It seems like my system is locking up more frequently now. Sometimes right
after a reboot the system, the screen locks and it's reboot and pray.

Best,
Owen

On Sat, Jun 3, 2017, 21:59 Jeffrey Bouquet  wrote:

> SOME LINES BOTTOM POSTED, SEE...
> 
> On Fri, 6/2/17, Tomoaki AOKI  wrote:
>
>  Subject: Re: nvidia drivers mutex lock
>  To: freebsd-current@freebsd.org
>  Cc: "Jeffrey Bouquet" , "blubee blubeeme" <
> gurenc...@gmail.com>
>  Date: Friday, June 2, 2017, 11:25 PM
>
>  Hi.
>  Version
>  381.22 (5 days newer than 375.66) of the driver states...
>  [1]
>
>   Fixed hangs and
>  crashes that could occur when an OpenGL context is
>   created while the system is out of available
>  memory.
>
>  Can this be related
>  with your hang?
>
>  IMHO,
>  possibly allocating new resource (using os.lock_mtx
>  guard)
>  without checking the lock first while
>  previous request is waiting for
>  another can
>  cause the duplicated lock situation. And high memory
>  pressure would easily cause the situation.
>
>   [1] http://www.nvidia.com/Download/driverResults.aspx/118527/en-us
>
>  Hope it helps.
>
>
>  On Thu, 1 Jun
>  2017 22:35:46 + (UTC)
>  Jeffrey Bouquet
>  
>  wrote:
>
>  > I see the same
>  message, upon load, ...
>  >
>  
>  > On Thu, 6/1/17, blubee blubeeme 
>  wrote:
>  >
>  >  Subject:
>  nvidia drivers mutex lock
>  >  To: freebsd-po...@freebsd.org,
>  freebsd-current@freebsd.org
>  >  Date: Thursday, June 1, 2017, 11:35
>  AM
>  >
>  >  I'm
>  running nvidia-drivers 375.66 with a GTX
>  >  1070 on FreeBSD-Current
>  >
>  >  This problem
>  just started happening
>  >  recently but,
>  every so often my laptop
>  >  screen will
>  just blank out and then I
>  >  have to
>  power cycle to get the
>  >  machine up and
>  running again.
>  >
>  >  It seems to be a problem with nvidia
>  >  drivers acquiring duplicate lock. Any
>  >  info on this?
>  >
>  >  Jun〓 2 02:29:41 blubee kernel:
>  >  acquiring duplicate lock of same
>  type:
>  >  "os.lock_mtx"
>  >  Jun〓 2 02:29:41 blubee kernel: 1st
>  >  os.lock_mtx @ nvidia_os.c:841
>  >  Jun〓 2 02:29:41 blubee kernel: 2nd
>  >  os.lock_mtx @ nvidia_os.c:841
>  >  Jun〓 2 02:29:41 blubee kernel:
>  >  stack backtrace:
>  >
>  Jun〓 2 02:29:41 blubee kernel: #0
>  >
>  0x80ab7770 at
>  >
>  witness_debugger+0x70
>  >  Jun〓 2
>  02:29:41 blubee kernel: #1
>  >
>  0x80ab7663 at
>  >
>  witness_checkorder+0xe23
>  >  Jun〓 2
>  02:29:41 blubee kernel: #2
>  >
>  0x80a35b93 at
>  >
>  __mtx_lock_flags+0x93
>  >  Jun〓 2
>  02:29:41 blubee kernel: #3
>  >
>  0x82f4397b at
>  >
>  os_acquire_spinlock+0x1b
>  >  Jun〓 2
>  02:29:41 blubee kernel: #4
>  >
>  0x82c48b15 at _nv012002rm+0x185
>  >  Jun〓 2 02:29:41 blubee kernel:
>  >  ACPI Warning:
>  \_SB.PCI0.PEG0.PEGP._DSM:
>  >  Argument #4
>  type mismatch - Found
>  >  [Buffer], ACPI
>  requires [Package]
>  >
>  (20170303/nsarguments-205)
>  >  Jun〓 2
>  02:29:42 blubee kernel:
>  >
>  nvidia-modeset: Allocated GPU:0
>  >
>  (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @
>  >  PCI::01:00.0
>  >
>
>  >  Best,
>  >  Owen
>  >
>  ___
>  >  freebsd-po...@freebsd.org
>  >  mailing list
>  >  https://lists.freebsd.org/mailman/listinfo/freebsd-ports
>  >  To unsubscribe, send any mail to
>  "freebsd-ports-unsubscr...@freebsd.org"
>  >
>  >
>  >
>  > ... then Xorg will
>  run happily twelve hours or so.  The lockups here happen
>  usually
>  > when too large or too many of
>  number of tabs/ large web pages with complex CSS etc
>  > are opened at a time.
>  > So no help, just a 'me
>  too'.
>  >
>  ___
>  > freebsd-current@freebsd.org
>  mailing list
>  > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>  >
>  To unsubscribe, send any mail to "freebsd-curren

Re: firefox/ rust failed to install on FreeBSD 12-CURRENT

[blubee blubeeme]

thanks for the two great pieces of advice.


Best,
Owen

On Sat, Jun 3, 2017 at 2:26 PM, Tim Kientzle  wrote:

>
> > On Jun 1, 2017, at 11:37 PM, Jean-Sébastien Pédron 
> wrote:
> >
> > On 28.05.2017 19:21, blubee blubeeme wrote:
> >> ===>  Building for rust-1.17.0
> >> ...
> >>  extracting
> >> rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_
> 64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd/lib/GNUSparseFile.0/
> librustc_llvm-74a1be1110b5d4d0.so
> >> gmake[7]: Leaving directory '/usr/ports/lang/rust/work/
> rustc-1.17.0-src'
> >> *** Error code 1
> >
> > Hi!
> >
> > This failure is caused by Python 2's tarfile module not supporting
> > sparse files in archives. Python 3 supports them but the configure
> > script insists on using Python 2.
> >
> > Before a proper fix is committed, you can change the following line in
> > lang/rust/Makefile:
> > https://github.com/freebsd/freebsd-ports/blob/master/
> lang/rust/Makefile#L159
> >
> > to say (this is a single line):
> > gtar -c -C ${WRKSRC} -f -
> > rust-std-1.16.0-${RUST_ARCH_${ARCH}}-unknown-freebsd | gzip >
> > ${WRKSRC}/rustc.tbz
>
> You could add --format=ustar to the existing command line; that would
> force bsdtar to use the older "ustar" format (without any extensions that
> might confuse Python's tar file module).
>
>
> > Then, change the following line:
> > https://github.com/freebsd/freebsd-ports/blob/master/
> lang/rust/Makefile#L34
> >
> > to say:
> > BUILD_DEPENDS= cmake:devel/cmake \
> >   gtar:archivers/gtar
> >
> > This will use GNU tar instead of BSD tar to recreate the bootstrap and
> > GNU tar doesn't seem to produce sparse file entries in the archive.
>
> How ironic; using GNU tar in order to avoid having GNU sparse file
> entries.  ;-)
>
> Tim
>
>
> ___
> freebsd-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: nvidia drivers mutex lock

[blubee blubeeme]

Thanks a lot! I'll give it a shot in a bit.

Best,
Owen

On Sun, Jun 4, 2017, 16:59 Tomoaki AOKI  wrote:

> Yes. FreeBSD patches in x11/nvidia-drivers/files are applied as usual.
>
> But beware! Sometimes upstream changes make any of FreeBSD patches not
> applicable (incorporating any of these, incompatible modifies, ...).
>
> For 381.22, current patchset applies and builds fine for me.
>
>
> On Sun, 04 Jun 2017 08:04:50 +
> blubee blubeeme  wrote:
>
> > I'm running with svn and I build by make.
> > If in use these steps, the BSD related patches will be applied, etc?
> >
> > Best,
> > Owen
> >
> > On Sun, Jun 4, 2017, 15:53 Tomoaki AOKI 
> wrote:
> >
> > > Hi.
> > >
> > > Not in ports tree, but easily overridden by adding
> > >
> > >   DISTVERSION=381.22 -DNO_CHECKSUM
> > >
> > > on make command line. Makefile of x11/nvidia-driver has a mechanism
> > > to do so for someone requires newer version (newer GPU support, etc.).
> > >
> > > If you're using portupgrade,
> > >
> > >   portupgrade -m 'DISTVERSION=381.22 -DNO_CHECKSUM' -f
> x11/nvidia-driver
> > >
> > > would do the same.
> > >
> > > If you installed it via pkg, there's no way to try. :-(
> > > (As it's pre-built.)
> > >
> > >
> > > On Sun, 04 Jun 2017 07:04:01 +
> > > blubee blubeeme  wrote:
> > >
> > > > Hi @tomoaki
> > > > Is that version of nvidia drivers currently in the ports tree? I just
> > > > checked but it seems not to be.
> > > >
> > > > @jeffrey
> > > > I just generated a new xorg based on the force composition setting. I
> > > > merged it with my previous xorg I'll reboot, see if it gives better
> > > > performance.
> > > >
> > > > It seems like my system is locking up more frequently now. Sometimes
> > > right
> > > > after a reboot the system, the screen locks and it's reboot and pray.
> > > >
> > > > Best,
> > > > Owen
> > > >
> > > > On Sat, Jun 3, 2017, 21:59 Jeffrey Bouquet  >
> > > wrote:
> > > >
> > > > > SOME LINES BOTTOM POSTED, SEE...
> > > > > 
> > > > > On Fri, 6/2/17, Tomoaki AOKI  wrote:
> > > > >
> > > > >  Subject: Re: nvidia drivers mutex lock
> > > > >  To: freebsd-current@freebsd.org
> > > > >  Cc: "Jeffrey Bouquet" , "blubee
> blubeeme" <
> > > > > gurenc...@gmail.com>
> > > > >  Date: Friday, June 2, 2017, 11:25 PM
> > > > >
> > > > >  Hi.
> > > > >  Version
> > > > >  381.22 (5 days newer than 375.66) of the driver states...
> > > > >  [1]
> > > > >
> > > > >   Fixed hangs and
> > > > >  crashes that could occur when an OpenGL context is
> > > > >   created while the system is out of available
> > > > >  memory.
> > > > >
> > > > >  Can this be related
> > > > >  with your hang?
> > > > >
> > > > >  IMHO,
> > > > >  possibly allocating new resource (using os.lock_mtx
> > > > >  guard)
> > > > >  without checking the lock first while
> > > > >  previous request is waiting for
> > > > >  another can
> > > > >  cause the duplicated lock situation. And high memory
> > > > >  pressure would easily cause the situation.
> > > > >
> > > > >   [1]
> http://www.nvidia.com/Download/driverResults.aspx/118527/en-us
> > > > >
> > > > >  Hope it helps.
> > > > >
> > > > >
> > > > >  On Thu, 1 Jun
> > > > >  2017 22:35:46 + (UTC)
> > > > >  Jeffrey Bouquet
> > > > >  
> > > > >  wrote:
> > > > >
> > > > >  > I see the same
> > > > >  message, upon load, ...
> > > > >  >
> > > > >  
> > > > >  > On Thu, 6/1/17, blubee blubeeme 
> > > > >  wrote:
> > > > >  >
> > > > >  >  Subject:
> > > > >  nvidia drivers mutex lock
> > > > >  >  To: freebsd-po...@freebsd.

[Help] Linux low level data structures < - > FreeBSD low level data structures

[blubee blubeeme]

Hello

Is there anyone on either of these lists that have experience with both
linux low level data structures and their equivalents on FreeBSD?

For instance the linux header file:


which includes the header file:


Then looking at that file:






I'll be doing a lot of work trying to find these FreeBSD equivalent of
these types of files to port some code.

Does anyone here have experience with something like this? Is there any
other projects that maps these low level data structures from
Linux <-> FreeBSD, etc?

Best,
Owen
___
freebsd-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: [Help] Linux low level data structures < - > FreeBSD low level data structures

[blubee blubeeme]

Hi Julian

My goals are to port the Linux graphics stack over to FreeBSD w/o relying
too heavily on the linuxkpi stuff. That's cool for a lot of use cases but
it just seems a bit too brittle.

It is a very large I understand the task will not be easy but I am willing
to do the work, even from scratch if necessary although some help would be
appreciated.

I've been watching the Linux DRM project grow and while the top levels has
changed, it's been a very long time since the actual low level stuff has
been changed. Most of the diffs have shown changes in the
[linux/driver/gpu/drm] layer which relies heavily on the
[linux/include/drm] that does a lot of the heavy lifting here's a link to
the latest version files:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/drm?h=v4.12-rc3

here's a diff of the latest version of the [linux/driver/gpu/drm] :
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/?id=v4.12-rc3&id2=v4.12-rc2&dt=2

The diffs in the drivers change constantly but the lower level stuff hasn't
changed as much.

Doing some of the lower level translation to native FreeBSD style data
structures then the upper part could be easily migrated, even with
something as using AST to translate the headers to their FreeBSD equivalent
without worrying about inadvertently breaking something or having major
diffs that needs people to actively look at maintaining.

That's a high level overview of my plan and what I'd like to achieve. Will
it be easy, most likely not but once it's done FreeBSD will be just fine.

Hope that helps clarify things for anyone who is interested. Any assistance
would be greatly appreciated.

Best,
Owen

On Sun, Jun 4, 2017 at 9:26 PM, Julian Elischer  wrote:

> On 4/6/17 7:07 pm, blubee blubeeme wrote:
>
>> Hello
>>
>> Is there anyone on either of these lists that have experience with both
>> linux low level data structures and their equivalents on FreeBSD?
>>
>> For instance the linux header file:
>> 
>>
>> which includes the header file:
>> 
>>
>> Then looking at that file:
>> 
>> 
>> 
>> 
>> 
>>
>
> You are going to have to be a lot more specific about this.
> I have worked in several places where they use s shim layer to make Linux
> basic services work on freeBSD.
> usually  a mix of functions, macros and inlines.
> However you need to narrow down your questions a bit as the POSSIBLE scope
> of your question is too large for anyone to attempt an answer.
>
> Remember that both systems are POSIX inspired so outside the kernel there
> are many more simlarities than one might be led to expect,
>  but you need to be way more specific.
> It's even possible to write kernel code to run on both, but it is usually
> domain specific.
>
>
>
>> I'll be doing a lot of work trying to find these FreeBSD equivalent of
>> these types of files to port some code.
>>
>> Does anyone here have experience with something like this? Is there any
>> other projects that maps these low level data structures from
>> Linux <-> FreeBSD, etc?
>>
>> Best,
>> Owen
>> ___
>> freebsd-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: [Help] Linux low level data structures < - > FreeBSD low level data structures

[blubee blubeeme]

＠Hans
I've noticed these things about Linux. A  lot of stuff relies on knowing
the internals of the data structures instead of working with the API but I
don't want to start all that stuff up.

The goal is to lift up FreeBSD w/o tearing down Linux and as u know needing
to be glued to the Linux data structures, while they always seem to be in
flux is one reason why I want to steer clear from the linuxkpi stuff.

I cam across the webcamd thing a while ago, it was written when Linux was
not moving so fast if I remember correctly. This is a big challenge but I
think once it's up and running it will bring some additional resources to
FreeBSD that can bring the desktop world up to snuff with it's server
acumen.

Thanks for the tips though!

Best,
Owen

On Mon, Jun 5, 2017 at 12:07 AM, Hans Petter Selasky 
wrote:

> Hi Owen,
>
> The most comprehensive open-source wrappers for Linux kernel APIs in the
> FreeBSD kernel is found at:
>
> https://github.com/FreeBSDDesktop/freebsd-base-graphics/
> tree/drm-next/sys/compat/linuxkpi
>
> The most comprehensive open-source wrappers for Linux kernel APIs in
> FreeBSD user-space is found at:
>
> http://www.freshports.org/multimedia/webcamd
>
> I recommend you start with webcamd. Download the source code and look at
> the sources. See if there is something you think you can improve. It is
> much easier to debug using GDB and if something goes wrong it can easily be
> restarted.
>
> When you have a working solution for webcamd, try to use the same solution
> with the kernel.
>
> There is no simple 1:1 mapping for Linux APIs to FreeBSD APIs. Take for
> example linux/list.h . You might think that a list can be re-implemented
> and mapped to our sys/queue.h. But oh-no. Linux kernel code depends on all
> the characteristics of list.h, how the structure members are stored and
> named, and how foreach() macros complete with NULL or non-NULL in the
> iterator. Further you'll find resistance among the Linux kernel developers
> to support compilers different from GCC. I recently found a piece of code
> in a header file, which works with GCC and causes a panic() when compiled
> with clang. I reported it to one of the Linux kernel team members and they
> didn't care about it. Even if you get everything compiling it doesn't it
> will work :-(
>
> --HPS
>
>
> On 06/04/17 16:35, blubee blubeeme wrote:
>
>> Hi Julian
>>
>> My goals are to port the Linux graphics stack over to FreeBSD w/o relying
>> too heavily on the linuxkpi stuff. That's cool for a lot of use cases but
>> it just seems a bit too brittle.
>>
>> It is a very large I understand the task will not be easy but I am willing
>> to do the work, even from scratch if necessary although some help would be
>> appreciated.
>>
>> I've been watching the Linux DRM project grow and while the top levels has
>> changed, it's been a very long time since the actual low level stuff has
>> been changed. Most of the diffs have shown changes in the
>> [linux/driver/gpu/drm] layer which relies heavily on the
>> [linux/include/drm] that does a lot of the heavy lifting here's a link to
>> the latest version files:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin
>> ux.git/tree/include/drm?h=v4.12-rc3
>>
>> here's a diff of the latest version of the [linux/driver/gpu/drm] :
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin
>> ux.git/diff/?id=v4.12-rc3&id2=v4.12-rc2&dt=2
>>
>> The diffs in the drivers change constantly but the lower level stuff
>> hasn't
>> changed as much.
>>
>> Doing some of the lower level translation to native FreeBSD style data
>> structures then the upper part could be easily migrated, even with
>> something as using AST to translate the headers to their FreeBSD
>> equivalent
>> without worrying about inadvertently breaking something or having major
>> diffs that needs people to actively look at maintaining.
>>
>> That's a high level overview of my plan and what I'd like to achieve. Will
>> it be easy, most likely not but once it's done FreeBSD will be just fine.
>>
>> Hope that helps clarify things for anyone who is interested. Any
>> assistance
>> would be greatly appreciated.
>>
>> Best,
>> Owen
>>
>> On Sun, Jun 4, 2017 at 9:26 PM, Julian Elischer 
>> wrote:
>>
>> On 4/6/17 7:07 pm, blubee blubeeme wrote:
>>>
>>> Hello
>>>>
>>>> Is there anyone on either of these lists that have experience with both
>>>> linux low level data structures and their equivalents on Fre

Re: freebsd-current Digest, Vol 711, Issue 2

[blubee blubeeme]

I was able to sort this out by installing rust from pkg. The pkg and ports
version was the same when I did it a lil while ago.

Try that, then running the Firefox build again.

Best,
Owen

On Tue, Jun 6, 2017, 20:18 Brandon Kastning 
wrote:

> FreeBSD 12-Current Community and Developers,
>
> Regarding Issue #8; I too am having issues. I removed Firefox because it
> was randomly closing. And upon reinstall, I was receiving the python rust
> build error.
>
> What is the proper syntax for a build with the "--format=ustar" ?
>
> I apologize if I am participating incorrectly. As I am new to the
> community and unix.
>
> Best Regards,
>
> Brandon Kastning
> AKA. StreetDancer (IRC & Forums)
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>
>  Original Message 
> Subject: freebsd-current Digest, Vol 711, Issue 2
> Local Time: June 6, 2017 5:00 AM
> UTC Time: June 6, 2017 12:00 PM
> From: freebsd-current-requ...@freebsd.org
> To: freebsd-current@freebsd.org
>
> 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: old syslog (jail) and new kernel = 100% CPU (Bryan Drewery)
> 2. Re: old syslog (jail) and new kernel = 100% CPU
> (Ngie Cooper (yaneurabeya))
> 3. Re: Time to increase MAXPHYS? (Kenneth D. Merry)
> 4. Boot CURRENT without efi (Andy Neustadter)
> 5. Re: Boot CURRENT without efi (Allan Jude)
> 6. Re: Time to increase MAXPHYS? (Edward Tomasz Napiera?a)
> 7. Re: Boot CURRENT without efi (Toomas Soome)
> 8. Re: firefox/ rust failed to install on FreeBSD 12-CURRENT
> (Jean-S?bastien P?dron)
>
> --
>
> Message: 1
> Date: Mon, 5 Jun 2017 08:20:47 -0700
> From: Bryan Drewery 
> To: Alexander Leidinger 
> Cc: curr...@freebsd.org
> Subject: Re: old syslog (jail) and new kernel = 100% CPU
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
>
> On 6/5/2017 2:34 AM, Alexander Leidinger wrote:
> >
> > Quoting Bryan Drewery  (from Sun, 4 Jun 2017 14:38:07
> > -0700):
> >
> >> On 6/4/17 5:09 AM, Alexander Leidinger wrote:
> >>> Hi,
> >>>
> >>> new kernel (surely r318877 and later) and old syslog in a jail = NOK.
> >>>
> >>
> >> What branch and revision is the syslogd? From my understanding the bug
> >> exists in a head version of syslogd only, maybe MFC'd to stable/11, but
> >> not released. If it was MFC'd we need to fix it before the 11.1 release.
> >
> > This was a syslogd from head for sure.
> >
> > So the issue was that for an intermediate period of time a bug was in
> > syslogd in head which was causing this, and if I would have upgraded a
> > system were the jail would have been head from before the or after the
> > bug, then I wouldn't have noticed it?
> >
>
> Yes, that's my understanding. So it's ultimately a non-issue for
> releases since it is just a temporary issue on head.
>
> --
> Regards,
> Bryan Drewery
>
> -- next part --
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 473 bytes
> Desc: OpenPGP digital signature
> URL: <
> http://lists.freebsd.org/pipermail/freebsd-current/attachments/20170605/6435eaef/attachment-0001.sig
> >
>
> --
>
> Message: 2
> Date: Mon, 5 Jun 2017 08:53:50 -0700
> From: "Ngie Cooper (yaneurabeya)" 
> To: Bryan Drewery 
> Cc: Alexander Leidinger , curr...@freebsd.org
> Subject: Re: old syslog (jail) and new kernel = 100% CPU
> Message-ID: <55114361-9212-49ae-a3ff-7691cadb2...@gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> > On Jun 5, 2017, at 08:20, Bryan Drewery  wrote:
> >
> > On 6/5/2017 2:34 AM, Alexander Leidinger wrote:
> >>
> >> Quoting Bryan Drewery  (from Sun, 4 Jun 2017 14:38:07
> >> -0700):
> >>
> >>> On 6/4/17 5:09 AM, Alexander Leidinger wrote:
>  Hi,
> 
>  new kernel (surely r318877 and later) and old syslog in a jail = NOK.
> 
> >>>
> >>> What branch and revision is the syslogd? From my understanding the bug
> >>> exists in a head version of syslogd only, maybe MFC'd to stable/11, but
> >>> not released. If it was MFC'd we need to fix it before the 11.1
> release.
> >>
> >> This was a syslogd from head for sure.
> >>
> >> So the issue was that for an intermediate period of time a bug was in
> >> syslogd in head which was causing this, and if I would have upgraded a
> >> system were the jail would have been head from before the or after the
> >> bug, then I wouldn't have noticed it?
> >>
> >
> > Yes, that's my understanding. So it's ultimately a non

Re: nvidia drivers mutex lock

[blubee blubeeme]

This is getting out of hand. I can't even keep x going for ten minutes
sometimes.
I've tested all the suggestions in this thread and they just don't work.

I have put out a print of sysctl hw. here : https://paste2.org/

With this CPU: hw.model: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
The bios on this laptop I can either set graphics to discrete or mshybrid.

I've tried in the past to disable discrete and run mshybrid but that always
comes up with 0 screens found. Even just doing Xorg -configure.

Anyone have some tips on disabling nvidia drivers, running this cpu with
igpu for a while?

Best,
Owen

On Sun, Jun 4, 2017, 18:11 blubee blubeeme  wrote:

> Thanks a lot! I'll give it a shot in a bit.
>
> Best,
> Owen
>
> On Sun, Jun 4, 2017, 16:59 Tomoaki AOKI  wrote:
>
>> Yes. FreeBSD patches in x11/nvidia-drivers/files are applied as usual.
>>
>> But beware! Sometimes upstream changes make any of FreeBSD patches not
>> applicable (incorporating any of these, incompatible modifies, ...).
>>
>> For 381.22, current patchset applies and builds fine for me.
>>
>>
>> On Sun, 04 Jun 2017 08:04:50 +
>> blubee blubeeme  wrote:
>>
>> > I'm running with svn and I build by make.
>> > If in use these steps, the BSD related patches will be applied, etc?
>> >
>> > Best,
>> > Owen
>> >
>> > On Sun, Jun 4, 2017, 15:53 Tomoaki AOKI 
>> wrote:
>> >
>> > > Hi.
>> > >
>> > > Not in ports tree, but easily overridden by adding
>> > >
>> > >   DISTVERSION=381.22 -DNO_CHECKSUM
>> > >
>> > > on make command line. Makefile of x11/nvidia-driver has a mechanism
>> > > to do so for someone requires newer version (newer GPU support, etc.).
>> > >
>> > > If you're using portupgrade,
>> > >
>> > >   portupgrade -m 'DISTVERSION=381.22 -DNO_CHECKSUM' -f
>> x11/nvidia-driver
>> > >
>> > > would do the same.
>> > >
>> > > If you installed it via pkg, there's no way to try. :-(
>> > > (As it's pre-built.)
>> > >
>> > >
>> > > On Sun, 04 Jun 2017 07:04:01 +
>> > > blubee blubeeme  wrote:
>> > >
>> > > > Hi @tomoaki
>> > > > Is that version of nvidia drivers currently in the ports tree? I
>> just
>> > > > checked but it seems not to be.
>> > > >
>> > > > @jeffrey
>> > > > I just generated a new xorg based on the force composition setting.
>> I
>> > > > merged it with my previous xorg I'll reboot, see if it gives better
>> > > > performance.
>> > > >
>> > > > It seems like my system is locking up more frequently now. Sometimes
>> > > right
>> > > > after a reboot the system, the screen locks and it's reboot and
>> pray.
>> > > >
>> > > > Best,
>> > > > Owen
>> > > >
>> > > > On Sat, Jun 3, 2017, 21:59 Jeffrey Bouquet <
>> jeffreybouq...@yahoo.com>
>> > > wrote:
>> > > >
>> > > > > SOME LINES BOTTOM POSTED, SEE...
>> > > > > 
>> > > > > On Fri, 6/2/17, Tomoaki AOKI  wrote:
>> > > > >
>> > > > >  Subject: Re: nvidia drivers mutex lock
>> > > > >  To: freebsd-current@freebsd.org
>> > > > >  Cc: "Jeffrey Bouquet" , "blubee
>> blubeeme" <
>> > > > > gurenc...@gmail.com>
>> > > > >  Date: Friday, June 2, 2017, 11:25 PM
>> > > > >
>> > > > >  Hi.
>> > > > >  Version
>> > > > >  381.22 (5 days newer than 375.66) of the driver states...
>> > > > >  [1]
>> > > > >
>> > > > >   Fixed hangs and
>> > > > >  crashes that could occur when an OpenGL context is
>> > > > >   created while the system is out of available
>> > > > >  memory.
>> > > > >
>> > > > >  Can this be related
>> > > > >  with your hang?
>> > > > >
>> > > > >  IMHO,
>> > > > >  possibly allocating new resource (using os.lock_mtx
>> > > > >  guard)
>> > > > >  without checking the lock first while
>> > > > >

[sed] command failure? Porting a project to FreeBSD

[blubee blubeeme]

Hello

I am trying to bring these updated print drivers to FreeBSD:
https://github.com/utsushi/utsushi.git


There's the automake scripts in there that's sorta helpful but I seem to
have gotten stuck with something.

I made sure that my environmental variables are set
LDFLAGS -L/usr/local/lib
CPPFLAGS -I/usr/local/include

i run autoreconf -fmi
that does it's thing and everything goes smoothly

./configure also seems to run just fine

when I run make there's a problem; sed command just hangs, it's been there
for hours now and no change.

the line in the makefile looks like this:
$(srcdir)/utsushi/tag.hpp $(srcdir)/lib/tag.cpp: $(srcdir)/lib/tag.xml \
  $(srcdir)/lib/tag.xsl
format=`echo $@ | sed 's|.*\.\([^.]*\)$$|\1|'`; \
sed -n \
   -e "/^/{ /-->/d; s|^$$|//|p; s|^|//|p; }' $< > $@; \
xsltproc --stringparam format $$format $(srcdir)/lib/tag.xsl $< >> $@
sed -i 's/SEC_N_("%1%")/"%1%"/' $@

I am not the best with sed but I feel like there might be some issues; I am
running tcsh shell, it could be it or that command is malformed.

Trying to run the same make file with gmake, I get this output.

format=`echo lib/tag.cpp | sed 's|.*\.\([^.]*\)$|\1|'`; \
sed -n \
-e "/^/{ /-->/d; s|^$|//|p; s|^|//|p; }' lib/tag.xml >
lib/tag.cpp; \
xsltproc --stringparam format $format ./lib/tag.xsl lib/tag.xml >>
lib/tag.cpp
sed -i 's/SEC_N_("%1%")/"%1%"/' lib/tag.cpp
sed: 1: "lib/tag.cpp": extra characters at the end of l command
gmake: *** [Makefile:1042: lib/tag.cpp] Error 1

extra character at the end of | command. It's a bit unclear to me.

There's a tags.xml and tags.xsl in the ./lib/ directory so it seems to be a
sed issue.

Any assistance would be appreciated.

Best,
Owen
___
freebsd-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: [sed] command failure? Porting a project to FreeBSD

[blubee blubeeme]

Ahhh, that was it. Doing a find and ask to replace all instances of sed
with gsed passed that part.

By the way, is knowledge like this written down somewhere centralized or is
it just floating in the ether?

Thank you,
Owen

On Wed, Jun 7, 2017, 14:26 Jov  wrote:

> The default sed on FreeBSD is different from GNU sed,there is some limit
> for bsd sed.You can try to patch the makefile to using gsed.
>
> 2017-06-07 14:10 GMT+08:00 blubee blubeeme :
>
>> Hello
>>
>> I am trying to bring these updated print drivers to FreeBSD:
>> https://github.com/utsushi/utsushi.git
>>
>>
>> There's the automake scripts in there that's sorta helpful but I seem to
>> have gotten stuck with something.
>>
>> I made sure that my environmental variables are set
>> LDFLAGS -L/usr/local/lib
>> CPPFLAGS -I/usr/local/include
>>
>> i run autoreconf -fmi
>> that does it's thing and everything goes smoothly
>>
>> ./configure also seems to run just fine
>>
>> when I run make there's a problem; sed command just hangs, it's been there
>> for hours now and no change.
>>
>> the line in the makefile looks like this:
>> $(srcdir)/utsushi/tag.hpp $(srcdir)/lib/tag.cpp: $(srcdir)/lib/tag.xml \
>>   $(srcdir)/lib/tag.xsl
>> format=`echo $@ | sed 's|.*\.\([^.]*\)$$|\1|'`; \
>> sed -n \
>>-e "/^/{ /-->/d; s|^$$|//|p; s|^|//|p; }' $< > $@; \
>> xsltproc --stringparam format $$format $(srcdir)/lib/tag.xsl $< >> $@
>> sed -i 's/SEC_N_("%1%")/"%1%"/' $@
>>
>> I am not the best with sed but I feel like there might be some issues; I
>> am
>> running tcsh shell, it could be it or that command is malformed.
>>
>> Trying to run the same make file with gmake, I get this output.
>>
>> format=`echo lib/tag.cpp | sed 's|.*\.\([^.]*\)$|\1|'`; \
>> sed -n \
>> -e "/^/{ /-->/d; s|^$|//|p; s|^|//|p; }' lib/tag.xml >
>> lib/tag.cpp; \
>> xsltproc --stringparam format $format ./lib/tag.xsl lib/tag.xml >>
>> lib/tag.cpp
>> sed -i 's/SEC_N_("%1%")/"%1%"/' lib/tag.cpp
>> sed: 1: "lib/tag.cpp": extra characters at the end of l command
>> gmake: *** [Makefile:1042: lib/tag.cpp] Error 1
>>
>> extra character at the end of | command. It's a bit unclear to me.
>>
>> There's a tags.xml and tags.xsl in the ./lib/ directory so it seems to be
>> a
>> sed issue.
>>
>> Any assistance would be appreciated.
>>
>> Best,
>> Owen
>>
> ___
>> freebsd-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"

[libltdl] removal from gnu ports

[blubee blubeeme]

Hi

I'm sure I was reading yesterday on a different machine about the linker
flag -ld which has something to do with gnu dlopen and how it's ok to
remove those from your Makefile since FreeBSD handles dlopen and a few
other things from that header in the standard libc.

Is that correct?

I'm seeing some errors when running make because of #include LT_CONFIG_H

Those files in this instance also handles dlopen and related system calls.
It should also be safe up remove those "ltdl" headers from the Makefile as
well?

Best,
Owen
___
freebsd-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: nvidia drivers mutex lock

[blubee blubeeme]

I was just looking through dmesg and noticed these:

Jun  6 21:40:52 blubee kernel: nvidia-modeset: Allocated GPU:0
(GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ PCI::01:00.0
Jun  6 21:41:05 blubee kernel: NVRM: GPU at PCI::01:00:
GPU-54a7b304-c99d-efee-0117-0ce119063cd6
Jun  6 21:41:05 blubee kernel: NVRM: GPU Board Serial Number:
Jun  6 21:41:05 blubee kernel: NVRM: Xid (PCI::01:00): 79, GPU has
fallen off the bus.
Jun  6 21:41:05 blubee kernel:
Jun  6 21:41:05 blubee kernel: NVRM: GPU at :01:00.0 has fallen off the
bus.
Jun  6 21:41:05 blubee kernel: NVRM: GPU is on Board .
Jun  6 21:41:05 blubee kernel: NVRM: A GPU crash dump has been created. If
possible, please run
Jun  6 21:41:05 blubee kernel: NVRM: nvidia-bug-report.sh as root to
collect this data before
Jun  6 21:41:05 blubee kernel: NVRM: the NVIDIA kernel module is unloaded.
Jun  6 21:41:05 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to
query display engine channel state: 0x927c:0:0:0x000f
Jun  6 21:41:05 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to
query display engine channel state: 0x927c:0:0:0x000f
Jun  6 21:41:05 blubee kernel: vgapci0: child nvidia0 requested
pci_enable_io
Jun  6 21:41:05 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to
query display engine channel state: 0x927c:0:0:0x000f
Jun  6 21:41:06 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to
query display engine channel state: 0x927c:0:0:0x000f
Jun  6 21:41:22 blubee kernel: .

then that lead me to this nvidia forum thread:
https://devtalk.nvidia.com/default/topic/985037/gtx-1070-quot-gpu-has-fallen-off-the-bus-quot-running-3d-games-in-arch-linux-/

maybe it could help somehow?

Best,
Owen

On Tue, Jun 6, 2017 at 10:08 PM, blubee blubeeme 
wrote:

> This is getting out of hand. I can't even keep x going for ten minutes
> sometimes.
> I've tested all the suggestions in this thread and they just don't work.
>
> I have put out a print of sysctl hw. here : https://paste2.org/
>
> With this CPU: hw.model: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
> The bios on this laptop I can either set graphics to discrete or mshybrid.
>
> I've tried in the past to disable discrete and run mshybrid but that
> always comes up with 0 screens found. Even just doing Xorg -configure.
>
> Anyone have some tips on disabling nvidia drivers, running this cpu with
> igpu for a while?
>
> Best,
> Owen
>
> On Sun, Jun 4, 2017, 18:11 blubee blubeeme  wrote:
>
>> Thanks a lot! I'll give it a shot in a bit.
>>
>> Best,
>> Owen
>>
>> On Sun, Jun 4, 2017, 16:59 Tomoaki AOKI 
>> wrote:
>>
>>> Yes. FreeBSD patches in x11/nvidia-drivers/files are applied as usual.
>>>
>>> But beware! Sometimes upstream changes make any of FreeBSD patches not
>>> applicable (incorporating any of these, incompatible modifies, ...).
>>>
>>> For 381.22, current patchset applies and builds fine for me.
>>>
>>>
>>> On Sun, 04 Jun 2017 08:04:50 +
>>> blubee blubeeme  wrote:
>>>
>>> > I'm running with svn and I build by make.
>>> > If in use these steps, the BSD related patches will be applied, etc?
>>> >
>>> > Best,
>>> > Owen
>>> >
>>> > On Sun, Jun 4, 2017, 15:53 Tomoaki AOKI 
>>> wrote:
>>> >
>>> > > Hi.
>>> > >
>>> > > Not in ports tree, but easily overridden by adding
>>> > >
>>> > >   DISTVERSION=381.22 -DNO_CHECKSUM
>>> > >
>>> > > on make command line. Makefile of x11/nvidia-driver has a mechanism
>>> > > to do so for someone requires newer version (newer GPU support,
>>> etc.).
>>> > >
>>> > > If you're using portupgrade,
>>> > >
>>> > >   portupgrade -m 'DISTVERSION=381.22 -DNO_CHECKSUM' -f
>>> x11/nvidia-driver
>>> > >
>>> > > would do the same.
>>> > >
>>> > > If you installed it via pkg, there's no way to try. :-(
>>> > > (As it's pre-built.)
>>> > >
>>> > >
>>> > > On Sun, 04 Jun 2017 07:04:01 +
>>> > > blubee blubeeme  wrote:
>>> > >
>>> > > > Hi @tomoaki
>>> > > > Is that version of nvidia drivers currently in the ports tree? I
>>> just
>>> > > > checked but it seems not to be.
>>> > > >
>>> > > > @jeffrey
>>> > > > I just generated a new xorg based on the force composition
>>> setting. I
>>> &g

autoreconf missing boost?

[blubee blubeeme]

Hi

I'm running a autoreconf trying to port a project; some printer code.
Having a bit of trouble.

I ran autoreconf -fi

then I do:
./configure --with-ltdl-include=/usr/local/share/libtool --with-gnu-ld
--with-libintl-prefix=/usr/local

that goes straight forward.

Then when I run gmake, it seems to fail at linking boost or something like
that. Here's the output of gmake, i've tried both make and gmake:
me@blubee:~/Downloads/Epson/ut % gmake
gmake  all-recursive
gmake[1]: Entering directory '/usr/home/blubee/Downloads/Epson/ut'
Making all in .
gmake[2]: Entering directory '/usr/home/blubee/Downloads/Epson/ut'
gmake[2]: Leaving directory '/usr/home/blubee/Downloads/Epson/ut'
Making all in lib
gmake[2]: Entering directory '/usr/home/blubee/Downloads/Epson/ut/lib'
Making all in .
gmake[3]: Entering directory '/usr/home/blubee/Downloads/Epson/ut/lib'
  CXX  connexion.lo
In file included from connexion.cpp:32:0:
/usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/include-fixed/sys/types.h:266:9:
error: '__vm_ooffset_t' does not name a type
 typedef __vm_ooffset_t vm_ooffset_t;
 ^
/usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/include-fixed/sys/types.h:268:9:
error: '__vm_pindex_t' does not name a type
 typedef __vm_pindex_t vm_pindex_t;
 ^
In file included from /usr/local/lib/gcc49/include/c++/cstdlib:72:0,
 from /usr/local/include/boost/core/demangle.hpp:39,
 from /usr/local/include/boost/core/typeinfo.hpp:119,
 from /usr/local/include/boost/detail/sp_typeinfo.hpp:20,
 from
/usr/local/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:27,
 from
/usr/local/include/boost/smart_ptr/detail/sp_counted_base.hpp:54,
 from
/usr/local/include/boost/smart_ptr/detail/shared_count.hpp:29,
 from /usr/local/include/boost/smart_ptr/shared_ptr.hpp:28,
 from /usr/local/include/boost/shared_ptr.hpp:17,
 from /usr/local/include/boost/filesystem/path.hpp:29,
 from /usr/local/include/boost/filesystem.hpp:16,
 from connexion.cpp:40:
/usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/include-fixed/stdlib.h:192:46:
error: expected initializer before '__nonnull'
 int  posix_memalign(void **, size_t, size_t) __nonnull(1); /* (ADV) */
  ^
In file included from
/usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr.h:148:0,
 from /usr/local/lib/gcc49/include/c++/ext/atomicity.h:35,
 from /usr/local/lib/gcc49/include/c++/bits/ios_base.h:39,
 from /usr/local/lib/gcc49/include/c++/ios:42,
 from /usr/local/lib/gcc49/include/c++/ostream:38,
 from /usr/local/lib/gcc49/include/c++/iostream:39,
 from connexion.cpp:38:
/usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:101:1:
error: 'int __gthrw_pthread_once(pthread_once_t*, void (*)())' declared
'static' but never defined [-Werror=unused-function]
 __gthrw(pthread_once)
 ^
/usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:102:1:
error: 'void* __gthrw_pthread_getspecific(pthread_key_t)' declared 'static'
but never defined [-Werror=unused-function]
 __gthrw(pthread_getspecific)
 ^
/usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:103:1:
error: 'int __gthrw_pthread_setspecific(pthread_key_t, const void*)'
declared 'static' but never defined [-Werror=unused-function]
 __gthrw(pthread_setspecific)
 ^
/usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:105:1:
error: 'int __gthrw_pthread_create(pthread**, pthread_attr* const*, void*
(*)(void*), void*)' declared 'static' but never defined
[-Werror=unused-function]
 __gthrw(pthread_create)
 ^
/usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:106:1:
error: 'int __gthrw_pthread_join(pthread_t, void**)' declared 'static' but
never defined [-Werror=unused-function]
 __gthrw(pthread_join)
 ^
/usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:107:1:
error: 'int __gthrw_pthread_equal(pthread_t, pthread_t)' declared 'static'
but never defined [-Werror=unused-function]
 __gthrw(pthread_equal)
 ^
/usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:108:1:
error: 'pthread* __gthrw_pthread_self()' declared 'static' but never
defined [-Werror=unused-function]
 __gthrw(pthread_self)
 ^
/usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:109:1:
error: 'int __gthrw_pthread_detach(pthread_t)' declared 'static' but never
defined [-Werror=unused-function]
 __gthrw(pthread_detach)
 ^
/usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:111:1:
error: 'int __gthrw_pthread_cancel(pthread_t)' declared 'static' but never
defined [-Werror=unused-func

Re: autoreconf missing boost?

[blubee blubeeme]

I forgot to add this in my last email, here's the boost packages that I
have installed.

me@blubee:~ % pkg info | grep boost
boost-jam-1.64.0   Build tool from the boost.org
boost-libs-1.64.0  Free portable C++ libraries (without
Boost.Python)
boost-python-libs-1.62.0   Framework for interfacing Python and C++
boost_build-2.0.m12_4  Extensible cross-platform build tool suite


On Thu, Jun 8, 2017 at 11:56 PM, blubee blubeeme 
wrote:

> Hi
>
> I'm running a autoreconf trying to port a project; some printer code.
> Having a bit of trouble.
>
> I ran autoreconf -fi
>
> then I do:
> ./configure --with-ltdl-include=/usr/local/share/libtool --with-gnu-ld
> --with-libintl-prefix=/usr/local
>
> that goes straight forward.
>
> Then when I run gmake, it seems to fail at linking boost or something like
> that. Here's the output of gmake, i've tried both make and gmake:
> me@blubee:~/Downloads/Epson/ut % gmake
> gmake  all-recursive
> gmake[1]: Entering directory '/usr/home/blubee/Downloads/Epson/ut'
> Making all in .
> gmake[2]: Entering directory '/usr/home/blubee/Downloads/Epson/ut'
> gmake[2]: Leaving directory '/usr/home/blubee/Downloads/Epson/ut'
> Making all in lib
> gmake[2]: Entering directory '/usr/home/blubee/Downloads/Epson/ut/lib'
> Making all in .
> gmake[3]: Entering directory '/usr/home/blubee/Downloads/Epson/ut/lib'
>   CXX  connexion.lo
> In file included from connexion.cpp:32:0:
> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/
> include-fixed/sys/types.h:266:9: error: '__vm_ooffset_t' does not name a
> type
>  typedef __vm_ooffset_t vm_ooffset_t;
>  ^
> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/
> include-fixed/sys/types.h:268:9: error: '__vm_pindex_t' does not name a
> type
>  typedef __vm_pindex_t vm_pindex_t;
>  ^
> In file included from /usr/local/lib/gcc49/include/c++/cstdlib:72:0,
>  from /usr/local/include/boost/core/demangle.hpp:39,
>  from /usr/local/include/boost/core/typeinfo.hpp:119,
>  from /usr/local/include/boost/detail/sp_typeinfo.hpp:20,
>  from /usr/local/include/boost/
> smart_ptr/detail/sp_counted_base_gcc_x86.hpp:27,
>  from /usr/local/include/boost/
> smart_ptr/detail/sp_counted_base.hpp:54,
>  from /usr/local/include/boost/
> smart_ptr/detail/shared_count.hpp:29,
>  from /usr/local/include/boost/
> smart_ptr/shared_ptr.hpp:28,
>  from /usr/local/include/boost/shared_ptr.hpp:17,
>  from /usr/local/include/boost/filesystem/path.hpp:29,
>  from /usr/local/include/boost/filesystem.hpp:16,
>  from connexion.cpp:40:
> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/include-fixed/stdlib.h:192:46:
> error: expected initializer before '__nonnull'
>  int  posix_memalign(void **, size_t, size_t) __nonnull(1); /* (ADV) */
>   ^
> In file included from /usr/local/lib/gcc49/include/
> c++/x86_64-portbld-freebsd12.0/bits/gthr.h:148:0,
>  from /usr/local/lib/gcc49/include/c++/ext/atomicity.h:35,
>  from /usr/local/lib/gcc49/include/c++/bits/ios_base.h:39,
>  from /usr/local/lib/gcc49/include/c++/ios:42,
>  from /usr/local/lib/gcc49/include/c++/ostream:38,
>  from /usr/local/lib/gcc49/include/c++/iostream:39,
>  from connexion.cpp:38:
> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:101:1:
> error: 'int __gthrw_pthread_once(pthread_once_t*, void (*)())' declared
> 'static' but never defined [-Werror=unused-function]
>  __gthrw(pthread_once)
>  ^
> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:102:1:
> error: 'void* __gthrw_pthread_getspecific(pthread_key_t)' declared
> 'static' but never defined [-Werror=unused-function]
>  __gthrw(pthread_getspecific)
>  ^
> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:103:1:
> error: 'int __gthrw_pthread_setspecific(pthread_key_t, const void*)'
> declared 'static' but never defined [-Werror=unused-function]
>  __gthrw(pthread_setspecific)
>  ^
> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:105:1:
> error: 'int __gthrw_pthread_create(pthread**, pthread_attr* const*, void*
> (*)(void*), void*)' declared 'static' but never defined
> [-Werror=unused-function]
>  __gthrw(pthread_create)
>  ^
&

xsltproc outputting nothing

[blubee blubeeme]

I tried sending this email to the gnome mailing list but no responses. Can
possibly get some help with this here:

===
Hi

I am trying to convert a .xsl file to a hpp file but the output is only a
blank file.

Here's the commands that I am running:

xsltproc --verbose --stringparam format hpp ./lib/tag.xsl > TAGS.hpp
creating dictionary for stylesheet
reusing dictionary from ./lib/tag.xsl for stylesheet
xsltParseStylesheetProcess : found stylesheet
xsltPrecomputeStylesheet: removing ignorable blank node
xsltParseTemplateContent: removing text
xsltCompilePattern : parsing 'tags'
xsltCompilePattern : parsed tags, default priority 0.00
added pattern : 'tags' priority 0.00
parsed 1 templates
Resolving attribute sets references
freeing dictionary from stylesheet


here's the tags.xsl file:




http://www.w3.org/1999/XSL/Transform";>
  

  



  
//  Automatically generated from lib/tag.xml using lib/tag.xsl.

#ifndef utsushi_tag_hpp_
#define utsushi_tag_hpp_

#include 

#include 

#include "key.hpp"
#include "string.hpp"

namespace utsushi {

struct tag
{
  //! Collect options and groups by the aspects they affect
  /*! A %tag::symbol is a string-like key that can be used to indicate
   *  which aspects are affected by an option or group.  An option may
   *  specify zero or more %tag symbols.
   *
   *  Similar to a descriptor, every %tag::symbol provides name() and
   *  text() accessors describing its purpose.  A user interface may
   *  use this information to provide a more human-oriented and mostly
   *  self-documenting view of tags.
   *
   *  \note  The UI is responsible for the translation of name() and
   * text() as well as any formatting of the text().
   *
   *  \sa  descriptor::name(), descriptor::text()
   */
  class symbol
: boost::totally_ordered< symbol >
  {
  public:
symbol (const key& key,
const string& name, const string& text);

//! \copybrief descriptor::name
const string& name () const;
//! \copybrief descriptor::text
const string& text () const;

bool operator== (const symbol& ts) const;
bool operator< (const symbol& ts) const;

operator key () const;

  private:
key key_;
string name_;
string text_;
  };

  static const symbol none;
  static const symbol ;
};

class tags
{
private:
  typedef std::set< tag::symbol > container_type;
  static container_type set_;
  static void initialize ();

public:
  typedef container_type::size_type size_type;
  typedef container_type::const_iterator const_iterator;

  static size_type count ();
  static const_iterator begin ();
  static const_iterator end ();
};

}   // namespace utsushi

#endif  /* utsushi_tag_hpp_ */

  

  
//  Automatically generated from tag.xml using tag.xsl.

#ifdef HAVE_CONFIG_H
#include 
#endif

#include "utsushi/i18n.hpp"
#include "utsushi/tag.hpp"

namespace utsushi {

tag::symbol::symbol (const key& key,
 const string& name, const string& text)
  : key_(key), name_(name), text_(text)
{}

const string&
tag::symbol::name () const
{
  return name_;
}

const string&
tag::symbol::text () const
{
  return text_;
}

bool
tag::symbol::operator== (const symbol& ts) const
{
  return key_ == ts.key_;
}

bool
tag::symbol::operator< (const tag::symbol& ts) const
{
  return key_ < ts.key_;
}

tag::symbol::operator key () const
{
  return key_;
}


const tag::symbol tag:: (
  "_",
  SEC_N_(""),
  CCB_N_("")
);

tags::container_type tags::set_;

void
tags::initialize ()
{
  container_type::iterator hint = set_.begin ();

  hint = set_.insert (hint, tag::);
}

tags::size_type
tags::count ()
{
  if (set_.empty ())
{
  initialize ();
}
  return set_.size ();
}

tags::const_iterator
tags::begin ()
{
  if (set_.empty ())
{
  initialize ();
}
  return set_.begin ();
}

tags::const_iterator
tags::end ()
{
  if (set_.empty ())
{
  initialize ();
}
  return set_.end ();
}

}   // namespace utsushi

  



  



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

autotools failing

[blubee blubeeme]

Hi

I just started to run into this problem with autotools. I am getting this
error running autoreconf -fi

here's the end of the output before unsuccessful exit:
---
configure.ac:54: error: possibly undefined macro: AS_IF
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
configure.ac:56: error: possibly undefined macro: AC_MSG_NOTICE
configure.ac:221: error: possibly undefined macro: AC_MSG_ERROR
autoreconf-2.69: /usr/local/bin/autoconf-2.69 failed with exit status: 1
---


= installed packages =
Coin-3.1.3_11  =
FreeCAD-0.17.g20170310_4   =
ORBit2-2.14.19_2   =
SoQt-1.5.0_6   =
adwaita-icon-theme-3.22.0  =
alsa-lib-1.1.2 =
alsa-plugins-1.1.1_1   =
apiextractor-0.10.10_3 =
appres-1.0.4   =
apr-1.5.2.1.5.4_2  =
arandr-0.1.9   =
argyllcms-1.9.2_1  =
at-spi2-atk-2.24.0 =
at-spi2-core-2.24.0=
atk-2.24.0 =
autoconf-2.69_1=
autoconf-wrapper-20131203  =
autoconf213-2.13.000227_6  =
automake-1.15_1=
automake-wrapper-20131203  =
autotools-20130627 =
avahi-app-0.6.31_5 =
bash-4.4.12_2  =
binutils-2.28,1=
bison-3.0.4,1  =
bitmap-1.0.8   =
blas-3.5.0_3   =
boost-all-1.64.0   =
boost-docs-1.64.0  =
boost-jam-1.64.0   =
boost-libs-1.64.0  =
boost-python-libs-1.64.0   =
ca_root_nss-3.31   =
cairo-1.14.8_1,2   =
cargo-0.17.0   =
cblas-1.0_6=
chromium-58.0.3029.110_2   =
cmake-3.8.2=
cmake-modules-3.8.2=
colord-1.2.12  =
compositeproto-0.4.2   =
compton-20160907_2 =
cups-2.2.3 =
curl-7.54.0<
cvsps-2.1_2=
damageproto-1.2.1  =
db5-5.3.28_6   =
dbus-1.10.16_1 =
dbus-glib-0.108=
dconf-0.24.0_1 =
dejavu-2.37=
desktop-file-utils-0.23=
dialog4ports-0.1.6 =
dmenu-4.7  =
dmxproto-2.3.1 =
dotconf-1.3_1  =
dri2proto-2.8  =
dri3proto-1.0  =
droid-fonts-ttf-20131024_3 =
dunst-1.1.0=
encodings-1.0.4_3,1=
espeak-1.48.04_2   =
expat-2.2.0_1  =
feh-2.18   =
ffmpeg-3.3.2,1 =
firefox-54.0,1 =
firefox-i18n-54.0  =
fixesproto-5.0 =
flac-1.3.2 =
font-adobe-100dpi-1.0.3_3  =
font-adobe-75dpi-1.0.3_3   =
font-adobe-utopia-100dpi-1.0.4_3   =
font-adobe-utopia-75dpi-1.0.4_3=
font-adobe-utopia-type1-1.0.4_3=
font-alias-1.0.3_3 =
font-arabic-misc-1.0.3_3   =
font-bh-100dpi-1.0.3_3 =
font-bh-75dpi-1.0.3_3  =
font-bh-lucidatypewriter-100dpi-1.0.3_3 =
font-bh-lucidatypewriter-75dpi-1.0.3_3 =
font-bh-ttf-1.0.3_3=
font-bh-type1-1.0.3_3  =
font-bitstream-100dpi-1.0.3_3  =
font-bitstream-75dpi-1.0.3_3   =
font-bitstream-type1-1.0.3_3   =
font-cronyx-cyrillic-1.0.3_3   =
font-cursor-misc-1.0.3_3   =
font-daewoo-misc-1.0.3_3   =
font-dec-misc-1.0.3_3  =
font-ibm-type1-1.0.3_3 =
font-isas-misc-1.0.3_3 =
font-jis-misc-1.0.3_3  =
font-micro-misc-1.0.3_3=
font-misc-cyrillic-1.0.3_3 =
font-misc-ethiopic-1.0.3_3 =
font-misc-meltho-1.0.3_3   =
font-misc-misc-1.1.2_3 =
font-mutt-misc-1.0.3_3 =
font-schumacher-misc-1.1.2_3   =
font-screen-cyrillic-1.0.4_3   =
font-sony-misc-1.0.3_3 =
font-sun-misc-1.0.3_3  =
font-util-1.3.1=
font-winitzki-cyrillic-1.0.3_3 =
font-xfree86-type1-1.0.4_3 =
fontcacheproto-0.1.3   =
fontconfig-2.12.1,1=
fontsproto-2.1.3,1 =
fr-med-3.2.0_2 =
freeimage-3.16.0_2 =
freetype2-2.8  =
ftgl-2.1.3.r5_6,1  =
gcc-ecj-4.5=
gcc5-5.4.0_2   =
gconf2-3.2.6_5   

.configure && make fails to find ld [dlopen]

[blubee blubeeme]

I am porting some software and it's getting tripped up with dlopen.

I run autoreconf -fi and it asks me to add AC_CONFIG_MACRO_DIRS([m4]) to my
configure.ac file, which I do. It creates a ./m4 directory and proceeds.

After running .configure --prefix=/tmp [for testing] that' also goes fine,
except .configure cannot find dlopen
checking for dlopen in -ldl... no

make also fails when it comes time to link because of the dlopen although
it's a part of FreeBSD libc

manually running ld -ld I get this output: https://pastebin.com/Rzfajnk0

The relevant parts of my env looks like this: https://pastebin.com/uJJ7BqDg

Is there anything that I am missing why configure can't find ld?

Best,
Owen
___
freebsd-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: .configure && make fails to find ld [dlopen]

[blubee blubeeme]

Thanks for the reply, I haven't set any -static in my env variables or
anything like that. Here's a brief output of my env


   1. OSTYPE=FreeBSD
   2. MACHTYPE=x86_64
   3. CC=clang
   4. PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
   5. EDITOR=vi
   6. LDFLAGS=-L/usr/local/lib
   7. LD_LIBRARY_PATH=/usr/local/llvm38/lib
   8. CPPFLAGS=-I/usr/local/include
   9. CXX=clang++
   10. SHELL=/bin/tcsh
   11. HOSTTYPE=FreeBSD
   12. CFLAGS=-I/usr/local/include


the linking to ldl is being done automatically since I call autoreconf -fi
and that sets up an m4 directory. grep -rn "\-ldl" in the root of the
source folder shows that the built in configure script and the scripts in
the m4 directory sets up those dlopen link example

# if libdl is installed we need to link against it
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for dlopen in -ldl"
>&5
$as_echo_n "checking for dlopen in -ldl... " >&6; }
if ${ac_cv_lib_dl_dlopen+:} false; then :
  $as_echo_n "(cached) " >&6
else
  ac_check_lib_save_LIBS=$LIBS
LIBS="-ldl  $LIBS"
cat confdefs.h - <<_ACEOF >conftest.$ac_ext

those are sprinkled all over the place, how do I avoid that and use libc
instead?

Best,
Owen

On Thu, Jul 6, 2017 at 8:14 AM, Simon J. Gerraty  wrote:

> blubee blubeeme  wrote:
> > I run autoreconf -fi and it asks me to add AC_CONFIG_MACRO_DIRS([m4]) to
> my
> > configure.ac file, which I do. It creates a ./m4 directory and proceeds.
> >
> > After running .configure --prefix=/tmp [for testing] that' also goes
> fine,
> > except .configure cannot find dlopen
> > checking for dlopen in -ldl... no
>
> dlopen is actually implemeted in the rtld - so you need to link at least
> one shared lib (usually libc) to get it.
>
> > make also fails when it comes time to link because of the dlopen although
> > it's a part of FreeBSD libc
>
> Check that you don't have -static or equivalent in CFLAGS/LDFLAGS.
>
___
freebsd-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: .configure && make fails to find ld [dlopen]

[blubee blubeeme]

Hi Ben

If you can help me with this, I would appreciate it greatly. I am trying to
port this project to FreeBSD:
https://github.com/endlessm/epson-inkjet-printer

After I grab those files then I run autoreconf -fi;
I am not sure how to get autoreconf to not put INCLUDES, which autoreconf
complains about.

After running autoreconf -fi I make the edits, that you can see with the
attached patch updated.path file. [is there's a way to make autoreconf -fi
not write INCLUDES but instead use the AM_CPPFLAGS?]

After I edit the files I run ./configure --prefix=/tmp

this seems to go well, no errors

Then I run make, this seems to go okay as well, it generates 3 warnings but
seems to run to completion, pastebin of the warnings:
https://pastebin.com/k5hs6011

after that I run make install and it installs some files in the tmp
directory:

.
├── doc
│   ├── AUTHORS
│   ├── COPYING
│   ├── COPYING.EPSON
│   ├── COPYING.LIB
│   ├── NEWS
│   └── README
├── etc
│   └── ld.so.conf.d
│   └── 99-epson-inkjet-printer.conf
└── lib
└── cups
└── filter
└── epson_inkjet_printer_filter

6 directories, 8 files


This might seem a bit silly but I am stuck here. These are the drivers for
the printer that I have but I noticed a few things wrong.

1) The PPD files didn't get copied over
2) The filter file is some type shared library and I am not sure how to use
it.

I know that I will need to move these files to /usr/local/libexec/cups
folder in their proper locations but why didn't the PPD files get installed?

Can I get some help sorting this out?

/usr/local/libexec/cups % tree .
.
├── backend
│   ├── beh
│   ├── dnssd
│   ├── driverless -> /usr/local/libexec/cups/driver/driverless
│   ├── http -> ipp
│   ├── https -> ipp
│   ├── implicitclass
│   ├── ipp
│   ├── ipps -> ipp
│   ├── lpd
│   ├── parallel
│   ├── serial
│   ├── snmp
│   ├── socket
│   └── usb
├── cgi-bin
│   ├── admin.cgi
│   ├── classes.cgi
│   ├── help.cgi
│   ├── jobs.cgi
│   └── printers.cgi
├── daemon
│   ├── cups-deviced
│   ├── cups-driverd
│   ├── cups-exec
│   └── cups-lpd
├── driver
│   └── driverless
├── filter
│   ├── bannertopdf
│   ├── commandtoescpx
│   ├── commandtopclx
│   ├── commandtops
│   ├── foomatic-rip
│   ├── gstopdf
│   ├── gstopxl
│   ├── gstoraster
│   ├── gziptoany
│   ├── imagetopdf
│   ├── imagetops
│   ├── imagetoraster
│   ├── pdftoijs
│   ├── pdftoopvp
│   ├── pdftopdf
│   ├── pdftops
│   ├── pdftoraster
│   ├── pstops
│   ├── rastertodymo -> rastertolabel
│   ├── rastertoepson
│   ├── rastertoescpx
│   ├── rastertohp
│   ├── rastertolabel
│   ├── rastertopclx
│   ├── rastertopdf
│   ├── rastertops
│   ├── rastertopwg
│   ├── sys5ippprinter
│   ├── texttopdf
│   ├── texttops
│   └── texttotext
├── monitor
│   ├── bcp
│   └── tbcp
└── notifier
├── dbus
├── mailto
└── rss



On Thu, Jul 6, 2017 at 9:52 PM, Benjamin Kaduk  wrote:

> On Thu, Jul 06, 2017 at 09:55:35AM +0800, blubee blubeeme wrote:
> >
> > those are sprinkled all over the place, how do I avoid that and use libc
> > instead?
>
> The software you are building needs to update their configure process
> to cope with dlopen being somewhere other than libdl, from what information
> you've provided.  Without looking at their source tree it's hard to
> say exactly what this would entail.
>
> -Ben
>
diff -ruN epson-inkjet-printer/Makefile.am --ep/Makefile.am
--- epson-inkjet-printer/Makefile.am	2017-07-06 10:33:43.822281000 +0800
+++ --ep/Makefile.am	2017-07-06 23:04:13.137811000 +0800
@@ -12,5 +12,6 @@
 
 ldsohooksdir = $(sysconfdir)/ld.so.conf.d
 ldsohooks_DATA = ld.so.conf.d/99-epson-inkjet-printer.conf
+ACLOCAL_AMFLAGS = -I m4
 
 EXTRA_DIST = $(doc_DATA) $(ldsohooks_DATA)
diff -ruN epson-inkjet-printer/configure.ac --ep/configure.ac
--- epson-inkjet-printer/configure.ac	2017-07-06 10:33:43.82248 +0800
+++ --ep/configure.ac	2017-07-06 23:04:13.138123000 +0800
@@ -7,6 +7,7 @@
 
 AC_CONFIG_SRCDIR([src/raster_to_epson.h])
 AC_CONFIG_HEADER([config.h])
+AC_CONFIG_MACRO_DIRS([m4])
 
 # Checks for programs.
 AC_PROG_CC
@@ -14,9 +15,6 @@
 AC_PROG_LN_S
 AC_PROG_LIBTOOL
 
-# Checks for libraries.
-AC_CHECK_LIB([dl], [dlopen])
-
 # Define flags
 AC_ARG_ENABLE(debug,
 AC_HELP_STRING([--enable-debug],[enable debug]),
@@ -50,7 +48,6 @@
 	CUPS_SERVER_DIR=${prefix}/lib/cups
 	CUPS_LIBS='-lcups -lm'
 	CUPS_IMAGE_LIBS='-lcupsimage -lcups -ljpeg -lm'
-	DL_LIBS='-ldl'
 	STDCPP_LIBS='-lstdc++'
 fi
 
diff -ruN epson-inkjet-printer/src/Makefile.am --ep/src/Makefile.am
--- epson-inkjet-printer/src/Makefile.am	2017-07-06 10:33:43.847522000 +0800
+++ --ep/src/Makefile.am	2017-07-06 23:04:13.235545000 +0800
@@ -2,7 +2,7 @@
 
 SUBDIRS = memory raster pagemanager filteropt
 
-INCLUDES = \
+AM_CPPFLAGS = \
 	-I../include \
 	-I./raster \
 	-I./memory \
diff -ruN epson-inkjet-printer/src/filteropt/Makefile.am --ep/src/filter

Re: .configure && make fails to find ld [dlopen]

[blubee blubeeme]

@Simon libdl is something used on Linux to provide dlopen like functions;
on FreeBSD it's already in libc so, removing the LIBS += -ldl removes the
problem and the program compiles successfully; I am just a bit lost as how
to proceed;

See my last email with the attached updated.diff file.

Best,
Owen

On Fri, Jul 7, 2017 at 12:12 AM, Simon J. Gerraty  wrote:

> blubee blubeeme  wrote:
>
> > Thanks for the reply, I haven't set any -static in my env variables or
> > anything like that. Here's a brief output of my env
>
> > the linking to ldl is being done automatically since I call autoreconf
> -fi
> > and that sets up an m4 directory. grep -rn "\-ldl" in the root of the
> > source folder shows that the built in configure script and the scripts in
> > the m4 directory sets up those dlopen link example
>
> Do you *have* a libdl?
> I don't on my system (10.3), and I don't see one in the tree (head).
>
> > $as_echo_n "checking for dlopen in -ldl... " >&6; }
>
> testing for it is fine - problem would be if it thinks it found it.
>
> > if ${ac_cv_lib_dl_dlopen+:} false; then :
> >   $as_echo_n "(cached) " >&6
> > else
> >   ac_check_lib_save_LIBS=$LIBS
> > LIBS="-ldl  $LIBS"
> > cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> >
> > those are sprinkled all over the place, how do I avoid that and use libc
> > instead?
>
> If it is a standard test, there may be a knob to disable it.
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Installing Linux libraries in /compat

[blubee blubeeme]

This is linux_base-c6

I would just like to check with the list to make sure If I want to install
missing libraries I should get the CentOS 6 versions of the rpm

I am missing some libraries for some printer drivers
---
ldd
/compat/linux/opt/epson-inkjet-printer-201401w/cups/lib/filter/epson_inkjet_printer_filter

/compat/linux/opt/epson-inkjet-printer-201401w/cups/lib/filter/epson_inkjet_printer_filter:
linux_vdso.so.1 =>  (0x7000)
libdl.so.2 => /lib64/libdl.so.2 (0x000800a0)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x000800e0)
libcupsimage.so.2 => not found
libcups.so.2 => not found
libjpeg.so.62 => not found
libpthread.so.0 => /lib64/libpthread.so.0 (0x00080120)
libm.so.6 => /lib64/libm.so.6 (0x00080160)
libc.so.6 => /lib64/libc.so.6 (0x000801a0)
/lib64/ld-lsb-x86-64.so.3 (0x000800607000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000801e0)
--

As you can see from the above I am missing
libcupsimage.so.2
libcups.so.2
libjpeg.so.62

looking at the ldd command from above all the printer drivers reference the
64 bit version of the libs so that means for example libcupsimage.so.2 I
should use the version from this url:

https://pkgs.org/download/libcupsimage.so.2

CentOS x86_64

   - cups-libs-1.4.2-77.el6.i686.rpm
   
Common
   Unix Printing System - libraries



To install that I'll follow the steps laid out here:
https://www.freebsd.org/doc/handbook/linuxemu-lbc-install.html

# *cd /compat/linux*# *rpm2cpio <
/path/to/cups-libs-1.4.2-77.el6.i686.rpm | cpio -id*

Is that correct?


linux_base-c6-6.8_12
Name   : linux_base-c6
Version: 6.8_12
Installed on   : Sat Jun  3 20:07:52 2017 CST
Origin : emulators/linux_base-c6
Architecture   : FreeBSD:11:amd64
Prefix : /compat/linux
Categories : linux emulators
Licenses   :
Maintainer : emulat...@freebsd.org
WWW: UNKNOWN
Comment: Base set of packages needed in Linux mode (Linux CentOS
6.8)
Options:
DOCS   : on
NLS: on
Annotations:
repo_type  : binary
repository : FreeBSD
Flat size  : 196MiB
Description:
This port contains packages from a near-minimal installation of CentOS 6
Linux.  These packages, in conjunction with the Linux kernel module,
form the basis of the Linux compatibility environment. It is designed to
provide a nice user experience by using the FreeBSD configuration for
corresponding Linux stuff where possible. Because of this any work which
needs to chroot into the Linux base may not work as expected (no fallthrough
to the FreeBSD config possible).
___
freebsd-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] future of drm1 in base

[blubee blubeeme]

I also have a current machine with one of those listed gpu.

A friend got hacked on windows, I got them setup with a ryzen chip and no
integrated GPU. Finding a supported gpu was a challenge but, those old
drivers allow the machine to have display.

Please try to maintain the older drivers, thanks.

Best,
Owen

On Sun, Sep 3, 2017, 18:03 David Chisnall  wrote:

> On 3 Sep 2017, at 06:31, Cy Schubert  wrote:
> >
> > Thanks for the heads up Johannes. I currently have three machines that
> each
> > run ATI r128, mach64 and the last one an mga card. I normally use my i945
> > and i915 laptops (mostly the former) but on occasion I may fire up X on
> one
> > of the other three. Having a drm-legacy port in the tree would benefit to
> > me.
>
> It’s been quite a while since I used any of these (though much of the list
> is very familiar), but the last machine I ran with a mach64 card was faster
> with the vesa driver than with the ‘accelerated’ driver (as I recall, it
> was a 500MHz Pentium III).  I suspect the real question is not whether
> people have machines that use these cards, but whether they do anything
> with them where they’d notice the lack of acceleration.
>
> David
>
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-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"

Extra Clang Tools

[blubee blubeeme]

FreeBSD switched to clang as it's compiler some time ago; was clang extra
tools: http://clang.llvm.org/extra/index.html ever ported over?

If yes, where is it located?
Best
___
freebsd-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: Extra Clang Tools

[blubee blubeeme]

Thank you for the tips; I was due for a rebuild anyways, might as well
upgrade the kernel along the way.

Best

On Sat, Sep 16, 2017 at 10:53 AM, Allan Jude  wrote:

> On 2017-09-15 22:29, blubee blubeeme wrote:
> > FreeBSD switched to clang as it's compiler some time ago; was clang extra
> > tools: http://clang.llvm.org/extra/index.html ever ported over?
> >
> > If yes, where is it located?
> > Best
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> freebsd.org"
> >
>
> I think you can enable most of them by adding WITH_CLANG_EXTRAS=yes to
> /etc/src.conf and recompiling.
>
> --
> Allan Jude
>
>
___
freebsd-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: Extra Clang Tools

[blubee blubeeme]

Is there any way to get the ports to provide them as well?

Best

On Sat, Sep 16, 2017 at 12:01 PM, blubee blubeeme 
wrote:

> Thank you for the tips; I was due for a rebuild anyways, might as well
> upgrade the kernel along the way.
>
> Best
>
> On Sat, Sep 16, 2017 at 10:53 AM, Allan Jude 
> wrote:
>
>> On 2017-09-15 22:29, blubee blubeeme wrote:
>> > FreeBSD switched to clang as it's compiler some time ago; was clang
>> extra
>> > tools: http://clang.llvm.org/extra/index.html ever ported over?
>> >
>> > If yes, where is it located?
>> > Best
>> > ___
>> > freebsd-current@freebsd.org mailing list
>> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@f
>> reebsd.org"
>> >
>>
>> I think you can enable most of them by adding WITH_CLANG_EXTRAS=yes to
>> /etc/src.conf and recompiling.
>>
>> --
>> Allan Jude
>>
>>
>
___
freebsd-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: Extra Clang Tools

[blubee blubeeme]

Howdy

I made a few changes to the devel/llvm40/Makefile and added pp-trace as the
last line of EXTRA_COMMANDS

Then I rebuilt llvm40, then I noticed that the pp-trace executable is
built, here's a output of the work directory grepping for pp-trace:
/usr/local/share/doc/llvm38/clang-tools/html/_sources/pp-trace.txt
/usr/local/share/doc/llvm38/clang-tools/html/pp-trace.html
/usr/local/share/doc/llvm39/clang-tools/html/_sources/pp-trace.txt
/usr/local/share/doc/llvm39/clang-tools/html/pp-trace.html
/usr/local/share/doc/llvm40/clang-tools/html/_sources/pp-trace.txt
/usr/local/share/doc/llvm40/clang-tools/html/pp-trace.html
/usr/ports/devel/llvm40/work/.build/bin/pp-trace
/usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/docs/_doctrees-html/pp-trace.doctree
/usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/docs/_doctrees-man/pp-trace.doctree
/usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/docs/html/_sources/pp-trace.txt
/usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/docs/html/pp-trace.html
/usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/pp-trace
/usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/pp-trace/CMakeFiles
/usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/pp-trace/CMakeFiles/pp-trace.dir
/usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/pp-trace/CMakeFiles/pp-trace.dir/PPCallbacksTracker.cpp.o
/usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/pp-trace/CMakeFiles/pp-trace.dir/PPTrace.cpp.o
/usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/pp-trace/cmake_install.cmake
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/docs/pp-trace.rst
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/pp-trace
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/pp-trace/CMakeLists.txt
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/pp-trace/PPCallbacksTracker.cpp
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/pp-trace/PPCallbacksTracker.h
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/pp-trace/PPTrace.cpp
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/Inputs
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/Inputs/Level1A.h
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/Inputs/Level1B.h
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/Inputs/Level2A.h
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/Inputs/Level2B.h
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/Inputs/ModularizeList.txt
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/Inputs/module.map
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/pp-trace-conditional.cpp
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/pp-trace-ident.cpp
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/pp-trace-include.cpp
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/pp-trace-modules.cpp
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/pp-trace-pragma-general.cpp
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/pp-trace-pragma-ms.cpp
/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/pp-trace-pragma-opencl.cpp
/usr/ports/devel/llvm40/work/stage/usr/local/share/doc/llvm40/clang-tools/html/_sources/pp-trace.txt
/usr/ports/devel/llvm40/work/stage/usr/local/share/doc/llvm40/clang-tools/html/pp-trace.html


So it now gets built but not installed; is it possible to have the port
updated to move these files to the proper after they are built?

I made a one line change to the Makefile:
# $FreeBSD: head/devel/llvm40/Makefile 449591 2017-09-10 20:55:38Z gerald $

EXTRAS_COMMANDS+= \
clang-apply-replacements \
clang-change-namespace \
clang-include-fixer \
clang-modernize \
clang-query \
clang-rename \
clang-reorder-fields \
clang-tidy \
find-all-symbols \
modularize \
pp-trace #===# My edit

Best

On Sat, Sep 16, 2017 at 2:01 PM, Shane Ambler  wrote:

> On 16/09/2017 11:59, blubee blubeeme wrote:
>
>> FreeBSD switched to clang as it's compiler some time ago; was clang extra
>> tools: http://clang.llvm.org/extra/index.html ever ported over?
>>
>> If yes, where is it located?
>>
>
> You will find them included in the llvm ports with EXTRAS enabled
>
> clang-tidy is in llvm 3.8+
> clang-include-fixer is in llvm 3.9+
> modularize is in llvm 3.8+

cve-2017-13077 - WPA2 security vulni

[blubee blubeeme]

Does anyone on FreeBSD know if it's affected by this?
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-13077
___
freebsd-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: cve-2017-13077 - WPA2 security vulni

[blubee blubeeme]

well, that's a cluster if I ever seen one.

On Mon, Oct 16, 2017 at 6:35 PM, Poul-Henning Kamp 
wrote:

> 
> In message  gmail.com>
> , blubee blubeeme writes:
>
> >Does anyone on FreeBSD know if it's affected by this?
> >https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-13077
>
> It is, same as Linux, we use the same wpa_supplicant software
>
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
___
freebsd-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: cve-2017-13077 - WPA2 security vulni

[blubee blubeeme]

This is awesome, thanks!

On Mon, Oct 16, 2017, 19:19 Stefan Esser  wrote:

> Am 16.10.17 um 12:38 schrieb blubee blubeeme:
> > well, that's a cluster if I ever seen one.
> >
> > On Mon, Oct 16, 2017 at 6:35 PM, Poul-Henning Kamp 
> > wrote:
> >
> >> ----
> >> In message  >> gmail.com>
> >> , blubee blubeeme writes:
> >>
> >>> Does anyone on FreeBSD know if it's affected by this?
> >>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-13077
> >>
> >> It is, same as Linux, we use the same wpa_supplicant software
>
> The attached patch includes the official patch applied by the WPA
> developers in   https://w1.fi/cgit/hostap/commit/?id=a00e946   but
> for our version of wpa_supplicant in /usr/src/contrib.
>
> Regards, STefan
> ___
> freebsd-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: There is *NO* abi stability in -head

[blubee blubeeme]

Thanks for these, I came across them when writing some game engine code a
few years back.
I really enjoy this stuff because I find it down right obnoxious that code
gets slower as CPU power increases!

On Tue, Oct 24, 2017 at 4:35 AM, Mateusz Guzik  wrote:

> This is your friendly reminder that in head struct layouts can change
> and each update requires you to rebuild *all* modules (including ones
> which come from ports). In practice you can get away without it most of
> the time, but if in doubt or seeing funny crashes - *recompile* and test
> with that.
>
> I'm sending this because in upcomming weeks struct thread (and probably
> more) will start getting fields moved around to improve cache-locality
> and reduce memory waste
>
> Both problems types are well known and rather widespread in big
> real-world c codebases.
>
> 1. memory waste
> Consider a 64-bit platform with 32-bit ints and 64-bit pointers
> (coincidently that's e.g. amd64 on *BSD, Linux, Illumos and others):
>
> struct crap {
> int i1;
> void *p1;
> int i2;
> void *p2;
> };
>
> Normallly fields are aligned to their size. So in particular p1 will be
> aligned to *8* bytes. But since sizeof i1 is only 4 bytes, there are
> another 4 bytes straight up wasted. The total sizeo of the obj is 32
> bytes.
>
> That is, if an object of type struct crap is at address 0x1000, fields
> will be:
>
> 0x1000 i1
> 0x1008 p1
> 0x1010 i2
> 0x1018 p2
>
> Instead, the same can be reshuffled:
> struct crap2 {
> int i1;
> int i2;
> void *p1;
> void *p2;
> };
>
> With offsets:
>
> 0x1000 i1
> 0x1004 i2
> 0x1008 p1
> 0x1010 p2
>
> This is only 24 bytes. 2 ints can be placed together and since they add
> up to 8 the p1 pointer gets the right alignment without extra padding.
>
> struct thread accumulated some of this and can just shrink without
> removing anything.
>
> Interested parties can read http://www.catb.org/esr/structure-packing/
>
> 2. cacheline bouncing (profesionnal term: cacheline ping pong)
>
> cpus store main memory content in local caches. the smallest unit it
> reads is 64 bytes (aligned to 64, i.e. reading of 0x1010 will fetch
> 0x1000).
>
> There are fields which are accessed only by the thread owning the
> struct. If they happen to share the line with something modified by
> other threads we lose on performance as now the cpu has to talk to
> some other cpu which has the line modified. This is increasingly painful
> on numa systems, where response times are longer.
>
> Furthermore, if fields frequently read/modified together are very far
> apart, chances are they require avoidable memory fetches - instead of
> taking just one line, they may take several. As cache size is finite,
> this may mean something else useful has to be evicted.
>
> For interested parties I can't recommend enough:
> https://www.kernel.org/pub/linux/kernel/people/paulmck/
> perfbook/perfbook.html
>
> --
> Mateusz Guzik 
> ___
> freebsd-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"

Linking against TK*

[blubee blubeeme]

I am running -ldd on a executable and I am missing links to a bunch
of: libTK**.so files

such as:
libTKGeomBase.so.11 => not found (0)
libTKG3d.so.11 => not found (0)
libTKG2d.so.11 => not found (0)
libTKMath.so.11 => not found (0)

I've searched quite a bit and can't find where those files are located.
What's going on, how do I link against them?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Okular or any pdf reader

[blubee blubeeme]

Whenever I try to launch any audio pdf viewer program my computer hard
locks up and I have to power cycle.

Does anyone have any info as to why?
uname -v:
FreeBSD 12.0-CURRENT #0 r319752: Sat Jun 10 01:59:26 CST 2017 blubee.me:
/usr/obj/usr/src/sys/GENERIC
___
freebsd-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: Okular or any pdf reader

[blubee blubeeme]

Typo on the [audio]

Here's my /var/log/messages for the past hour or so, the failure should be
logged in there somewhere: https://pastebin.com/FCkXEn1v

Other than that there's this: https://ibb.co/gUBVkm

On Wed, Oct 25, 2017 at 5:29 PM, Hans Petter Selasky 
wrote:

> On 10/25/17 11:30, blubee blubeeme wrote:
>
>>   any audio pdf viewer
>>
>
> Audio??
>
> Do you have a kernel trace or dmesg ?
>
> --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: Okular or any pdf reader

[blubee blubeeme]

lid0:  on
acpi0
Oct 25 17:52:52 blubee kernel: acpi_acad0:  on acpi0
Oct 25 17:52:52 blubee kernel: battery0:  on
acpi0
Oct 25 17:52:52 blubee kernel: acpi_tz0:  on acpi0
Oct 25 17:52:52 blubee kernel: atkbdc0:  port
0x60,0x64 irq 1 on acpi0
Oct 25 17:52:52 blubee kernel: atkbd0:  irq 1 on atkbdc0
Oct 25 17:52:52 blubee kernel: kbd0 at atkbd0
Oct 25 17:52:52 blubee kernel: atkbd0: [GIANT-LOCKED]
Oct 25 17:52:52 blubee kernel: psm0:  irq 12 on atkbdc0
Oct 25 17:52:52 blubee kernel: psm0: [GIANT-LOCKED]
Oct 25 17:52:52 blubee kernel: psm0: model Synaptics Touchpad, device ID 0
Oct 25 17:52:52 blubee kernel: orm0:  at iomem
0xce800-0xcf7ff on isa0
Oct 25 17:52:52 blubee kernel: ppc0: cannot reserve I/O port range
Oct 25 17:52:52 blubee kernel: est0: 
on cpu0
Oct 25 17:52:52 blubee kernel: est1: 
on cpu1
Oct 25 17:52:52 blubee kernel: est2: 
on cpu2
Oct 25 17:52:52 blubee kernel: est3: 
on cpu3
Oct 25 17:52:52 blubee kernel: est4: 
on cpu4
Oct 25 17:52:52 blubee kernel: est5: 
on cpu5
Oct 25 17:52:52 blubee kernel: est6: 
on cpu6
Oct 25 17:52:52 blubee kernel: est7: 
on cpu7
Oct 25 17:52:52 blubee kernel: ZFS filesystem version: 5
Oct 25 17:52:52 blubee kernel: ZFS storage pool version: features support
(5000)
Oct 25 17:52:52 blubee kernel: Timecounters tick every 1.000 msec
Oct 25 17:52:52 blubee kernel: iwm0: hw rev 0x180, fw ver 17.352738.0,
address 60:57:18:94:c6:4a
Oct 25 17:52:52 blubee kernel: ugen0.1: <0x8086 XHCI root HUB> at usbus0
Oct 25 17:52:52 blubee kernel: uhub0: <0x8086 XHCI root HUB, class 9/0, rev
3.00/1.00, addr 1> on usbus0
Oct 25 17:52:52 blubee kernel: nvd0:  NVMe namespace
Oct 25 17:52:52 blubee kernel: nvd0: 244198MB (500118192 512 byte sectors)
Oct 25 17:52:52 blubee kernel: hdacc0:  at cad 0
on hdac0
Oct 25 17:52:52 blubee kernel: hdaa0: 
at nid 1 on hdacc0
Oct 25 17:52:52 blubee kernel: pcm0:  at nid 20
and 24 on hdaa0
Oct 25 17:52:52 blubee kernel: pcm1:  at nid 23 on hdaa0
Oct 25 17:52:52 blubee kernel: pcm2:  at nid
30 on hdaa0
Oct 25 17:52:52 blubee kernel: WARNING: WITNESS option enabled, expect
reduced performance.
Oct 25 17:52:52 blubee kernel: Trying to mount root from
zfs:zroot/ROOT/default []...
Oct 25 17:52:52 blubee kernel: Root mount waiting for: usbus0
Oct 25 17:52:52 blubee kernel: Root mount waiting for: usbus0
Oct 25 17:52:52 blubee kernel: uhub0: 24 ports with 24 removable, self
powered
Oct 25 17:52:52 blubee kernel: ugen0.2:  at usbus0
Oct 25 17:52:52 blubee kernel: Root mount waiting for: usbus0
Oct 25 17:52:52 blubee kernel: ugen0.3:  at
usbus0
Oct 25 17:52:52 blubee kernel: Root mount waiting for: usbus0
Oct 25 17:52:52 blubee kernel: ugen0.4:  at usbus0
Oct 25 17:52:52 blubee kernel: wlan0: Ethernet address: 60:57:18:94:c6:4a
Oct 25 17:52:52 blubee kernel: wlan0: link state changed to UP
Oct 25 17:52:52 blubee kernel: re0: link state changed to DOWN
Oct 25 17:52:52 blubee kernel: ulpt0 on uhub0
Oct 25 17:52:52 blubee kernel: ulpt0:  on usbus0
Oct 25 17:52:52 blubee kernel: ulpt0: using bi-directional mode
Oct 25 17:52:52 blubee kernel: ubt0 on uhub0
Oct 25 17:52:52 blubee kernel: ubt0:  on usbus0
Oct 25 17:52:52 blubee kernel: WARNING: attempt to domain_add(bluetooth)
after domainfinalize()
Oct 25 17:52:52 blubee kernel: WARNING: attempt to domain_add(netgraph)
after domainfinalize()
Oct 25 17:52:52 blubee kernel: ubt0: ubt_ctrl_write_callback:780: control
transfer failed: USB_ERR_TIMEOUT
Oct 25 17:52:52 blubee kernel: ng_hci_process_command_timeout: ubt0hci -
unable to complete HCI command OGF=0x3, OCF=0x3. Timeout
Oct 25 17:52:53 blubee ntpd[825]: leapsecond file
('/var/db/ntpd.leap-seconds.list'): good hash signature
Oct 25 17:52:53 blubee ntpd[825]: leapsecond file
('/var/db/ntpd.leap-seconds.list'): loaded, expire=2017-12-28T00:00:00Z
last=2017-01-01T00:00:00Z ofs=37
Oct 25 17:52:58 blubee kernel: ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM:
Argument #4 type mismatch - Found [Buffer], ACPI requires [Package]
(20170531/nsarguments-205)
Oct 25 17:52:58 blubee last message repeated 6 times
Oct 25 17:52:58 blubee kernel: acquiring duplicate lock of same type:
"os.lock_mtx"
Oct 25 17:52:58 blubee kernel: 1st os.lock_mtx @ nvidia_os.c:841
Oct 25 17:52:58 blubee kernel: 2nd os.lock_mtx @ nvidia_os.c:841
Oct 25 17:52:58 blubee kernel: stack backtrace:
Oct 25 17:52:58 blubee kernel: #0 0x80ab6f30 at
witness_debugger+0x70
Oct 25 17:52:58 blubee kernel: #1 0x80ab6e23 at
witness_checkorder+0xe23
Oct 25 17:52:58 blubee kernel: #2 0x80a35293 at
__mtx_lock_flags+0x93
Oct 25 17:52:58 blubee kernel: #3 0x82f4097b at
os_acquire_spinlock+0x1b
Oct 25 17:52:58 blubee kernel: #4 0x82c45b15 at _nv012002rm+0x185
Oct 25 17:52:58 blubee kernel: ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM:
Argument #4 type mismatch - Found [Buffer], ACPI requires [Package]
(20170531/nsarguments-205)
Oct 25 17:52:59 blubee kernel: nvidia-modeset: Allocated GPU:0
(GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ PCI::01:00.0



On W

Re: Okular or any pdf reader

[blubee blubeeme]

The GPUT thing is pretty terrible so I know i'm risking things with that,
have no choice until I can take some time to try that drm-kmod.

Speaking of which, those commands do not work; I am on a laptop and if I
try to change terms like that the nvidia drivers just panic and die. screen
looks like when old nintendo would freeze with the colorful junk on screen.

I don't have another machine that can ssh into this one, any other options?

On Wed, Oct 25, 2017 at 5:58 PM, Hans Petter Selasky 
wrote:

> On 10/25/17 11:55, blubee blubeeme wrote:
>
>> "os.lock_mtx"
>> Oct 25 17:52:58 blubee kernel: 1st os.lock_mtx @ nvidia_os.c:841
>> Oct 25 17:52:58 blubee kernel: 2nd os.lock_mtx @ nvidia_os.c:841
>> Oct 25 17:52:58 blubee kernel: stack backtrace:
>> Oct 25 17:52:58 blubee kernel: #0 0x80ab6f30 at
>> witness_debugger+0x70
>> Oct 25 17:52:58 blubee kernel: #1 0x80ab6e23 at
>> witness_checkorder+0xe23
>> Oct 25 17:52:58 blubee kernel: #2 0x80a35293 at
>> __mtx_lock_flags+0x93
>> Oct 25 17:52:58 blubee kernel: #3 0x82f4097b at
>> os_acquire_spinlock+0x1b
>> Oct 25 17:52:58 blubee kernel: #4 0x82c45b15 at _nv012002rm+0x185
>> Oct 25 17:52:58 blubee kernel: ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM:
>> Argument #4 type mismatch - Found [Buffer], ACPI requires [Package]
>> (20170531/nsarguments-205)
>> Oct 25 17:52:59 blubee kernel: nvidia-modeset: Allocated GPU:0
>> (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ PCI::01:00.0
>>
>>
>>
> Hi,
>
> Try: CTRL+ALT+F1
> Or SSH into this machine.
>
> Then do:
>
> procstat -ak
>
> It will reveal any hangs and deadlocks.
>
> Further I note you're using 12-current with the NVIDIA driver. That might
> not be a supported configuration :-( Especially nowadays some core kernel
> structures are changing, which means NVIDIA needs to recompile their binary
> blob aswell!
>
> --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: Okular or any pdf reader

[blubee blubeeme]

Okay, I tried using chatbot for android to ssh into this laptop and that
works just fine.
Then when I launch okular the computer had locks up and the ssh dies on the
phone as well. So it seems not even ssh works when this this freezes up.

Any other suggestions?

On Wed, Oct 25, 2017 at 6:05 PM, blubee blubeeme 
wrote:

> The GPUT thing is pretty terrible so I know i'm risking things with that,
> have no choice until I can take some time to try that drm-kmod.
>
> Speaking of which, those commands do not work; I am on a laptop and if I
> try to change terms like that the nvidia drivers just panic and die. screen
> looks like when old nintendo would freeze with the colorful junk on screen.
>
> I don't have another machine that can ssh into this one, any other options?
>
> On Wed, Oct 25, 2017 at 5:58 PM, Hans Petter Selasky 
> wrote:
>
>> On 10/25/17 11:55, blubee blubeeme wrote:
>>
>>> "os.lock_mtx"
>>> Oct 25 17:52:58 blubee kernel: 1st os.lock_mtx @ nvidia_os.c:841
>>> Oct 25 17:52:58 blubee kernel: 2nd os.lock_mtx @ nvidia_os.c:841
>>> Oct 25 17:52:58 blubee kernel: stack backtrace:
>>> Oct 25 17:52:58 blubee kernel: #0 0x80ab6f30 at
>>> witness_debugger+0x70
>>> Oct 25 17:52:58 blubee kernel: #1 0x80ab6e23 at
>>> witness_checkorder+0xe23
>>> Oct 25 17:52:58 blubee kernel: #2 0x80a35293 at
>>> __mtx_lock_flags+0x93
>>> Oct 25 17:52:58 blubee kernel: #3 0x82f4097b at
>>> os_acquire_spinlock+0x1b
>>> Oct 25 17:52:58 blubee kernel: #4 0x82c45b15 at _nv012002rm+0x185
>>> Oct 25 17:52:58 blubee kernel: ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM:
>>> Argument #4 type mismatch - Found [Buffer], ACPI requires [Package]
>>> (20170531/nsarguments-205)
>>> Oct 25 17:52:59 blubee kernel: nvidia-modeset: Allocated GPU:0
>>> (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ PCI::01:00.0
>>>
>>>
>>>
>> Hi,
>>
>> Try: CTRL+ALT+F1
>> Or SSH into this machine.
>>
>> Then do:
>>
>> procstat -ak
>>
>> It will reveal any hangs and deadlocks.
>>
>> Further I note you're using 12-current with the NVIDIA driver. That might
>> not be a supported configuration :-( Especially nowadays some core kernel
>> structures are changing, which means NVIDIA needs to recompile their binary
>> blob aswell!
>>
>> --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: Okular or any pdf reader

[blubee blubeeme]

I've had the pdf viewers work with these nvidia drivers before, then a few
months back they stopped working. I've avoided dealing with the problem by
using chrome to view pdfs but that's getting old.

About this laptop it's a bios switch to use either the gtx 1070 or the
intel gpu
vgapci0@pci0:1:0:0: class=0x03 card=0x6a021558 chip=0x1ba110de rev=0xa1
hdr=0x00
vendor = 'NVIDIA Corporation'
device = 'GP104M [GeForce GTX 1070]'
class  = display
subclass   = VGA

hw.machine: amd64
hw.model: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
hw.ncpu: 8
hw.machine_arch: amd64

I havent had time to try the kmod drivers yet, maybe i'll install that
port, disable the nvidia-drivers, make the switch in the gpu and try again.

On Wed, Oct 25, 2017 at 7:23 PM, Hans Petter Selasky 
wrote:

> On 10/25/17 13:15, blubee blubeeme wrote:
>
>> Okay, I tried using chatbot for android to ssh into this laptop and that
>> works just fine.
>> Then when I launch okular the computer had locks up and the ssh dies on
>> the
>> phone as well. So it seems not even ssh works when this this freezes up.
>>
>> Any other suggestions?
>>
>
> Try to set:
>
> sysctl net.inet.tcp.per_cpu_timers=1
>
> Before connecting via SSH.
>
> Does the same happen when using VESA driver or is this specific to using
> the NVIDIA driver. If the NVIDIA is at cause, I cannot help.
>
> --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"

po/Makefile.in.in was not created by intltoolize."

[blubee blubeeme]

I found this really old thread:
https://mail.gnome.org/archives/gtkmm-list/2009-August/msg00072.html

and this really old script to "work around" the issue.

#! /bin/sh -etest -n "$srcdir" || srcdir=`dirname "$0"`test -n
"$srcdir" || srcdir=.(
  cd "$srcdir" &&
  AUTOPOINT='intltoolize --automake --copy' autoreconf --force
--install --verbose) || exittest -n "$NOCONFIGURE" ||
"$srcdir/configure" "$@"



Do I just have to implement this in the ports Makefile or is there some
workaround?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

can't link against math.h

[blubee blubeeme]

I wrote a simple test program to test and see if math.h has the function:
exp10f

#include 

int main(int argc, char** argv)
{
(void)argv;
return ((int*)(&exp10))[argc];
}

tried compiling it with clang:
clang++ test.cpp -o test -lm
test.cpp:7:17: error: use of undeclared identifier 'expf10'
return ((int*)(&expf10))[argc];
^
1 error generated.

tried with gcc:
gcc test.cpp -o test -lm
test.cpp: In function 'int main(int, char**)':
test.cpp:7:17: error: 'expf10' was not declared in this scope
 return ((int*)(&expf10))[argc];

Does FreeBSD math.h have expf10 and if so, how do I link against it?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Strange compiler error

[blubee blubeeme]

CMAKE_ARGS= -DFREECAD_USE_EXTERNAL_PIVY:BOOL=ON \
-DBUILD_QT5_WEBKIT:BOOL=OFF \
-DCMAKE_CXX_COMPILER=${LOCALBASE}/bin/mpicxx \

BUILD_DEPENDS= pyside-rcc:devel/pyside-tools \
swig:devel/swig13 \
${LOCALBASE}/libdata/pkgconfig/eigen3.pc:math/eigen3 \
${LOCALBASE}/bin/mpicc:net/mpich2

I've tried this but still no go, any ideas?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

strage compile error [with attachments]

[blubee blubeeme]

error:
FAILED: lib/libSMESH.so
: && /usr/bin/c++  -fPIC -Wall -Wextra -Wno-write-strings -O2 -pipe
-fstack-protector -isystem /usr/local/include -fno-strict-aliasing
 -isystem /usr/local/include -std=c++11 -Wno-undefined-var-template
-D_OCC64 -Wno-sign-compare -Wno-reorder -Wno-switch -Wno-unused-variable
-Wno-unused-private-field -Wno-unused-function -Wno-sometimes-uninitialized
-Wno-overloaded-virtual -Wno-dynamic-class-memaccess -Wno-comment
-Wno-unused-parameter -Wno-self-assign -Wno-reorder -Wno-switch-enum
-Wno-unknown-pragmas -Wno-logical-op-parentheses -Wno-unused-variable
-Wno-unused-function -Wno-overloaded-virtual -O2 -pipe -fstack-protector
-isystem /usr/local/include -fno-strict-aliasing  -isystem
/usr/local/include  -Wl,--no-undefined -shared -Wl,-soname,libSMESH.so -o
lib/libSMESH.so
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/libmesh.c.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverGMF.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverGMF_Read.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverGMF_Write.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverMED_Family.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverMED_R_SMESHDS_Mesh.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverMED_W_Field.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverMED_W_SMESHDS_Mesh.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/GEOMUtils.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_Algorithm.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_CoordUtils.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_Factory.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_GaussDef.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_GaussUtils.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_Structures.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_Utilities.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_V2_2_Wrapper.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_Wrapper.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Algo.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Block.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Exception.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Gen.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Group.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_HypoFilter.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Hypothesis.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Mesh.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_MeshAlgos.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_MeshEditor.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_MeshVSLink.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_MesherHelper.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Octree.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_OctreeNode.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Pattern.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_ProxyMesh.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_TryCatch.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_subMesh.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/Utils_ExceptHandlers.cpp.o
src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/Controls/SMESH_Controls.cpp.o
 
-Wl,-rpath,/usr/ports/cad/Freecad/work/.build/lib:/usr/local/lib:/usr/local/lib/vtk-6.2:
lib/libDriverSTL.so lib/libDriverDAT.so lib/libDriverUNV.so
/usr/local/lib/libmedC.so /usr/local/lib/libmed.so -lz
/usr/local/lib/libexpat.so lib/libSMESHDS.so lib/libSMDS.so
/usr/local/lib/vtk-6.2/libvtkFiltersVerdict-6.2.so.1
/usr/local/lib/vtk-6.2/libvtkverdict-6.2.so.1
/usr/local/lib/vtk-6.2/libvtkIOXML-6.2.so.1
/usr/local/lib/vtk-6.2/libvtkIOGeometry-6.2.so.1
/usr/local/lib/vtk-6.2/libvtkjsoncpp-6.2.so.1
/usr/local/lib/vtk-6.2/libvtkIOXMLParser-6.2.so.1
/usr/local/lib/vtk-6.2/libvtkIOLegacy-6.2.so.1
/usr/local/lib/vtk-6.2/libvtkIOCore-6.2.so.1
/usr/local/lib/vtk-6.2/libvtkFiltersExtraction-6.2.so.1
/usr/local/lib/vtk-6.2/libvtkFiltersStatistics-6.2.so.1
/usr/local/lib/vtk-6.2/libvtkImagingFourier-6.2.so.1
/usr/local/lib/vtk-6.2/libvtkImagingCore-6.2.so.1
/usr/local/lib/vtk-6.2/libvtkalglib-6.2.so.1
/usr/local/lib/vtk-6.2/libvtkFiltersSources-6.2.so.1
/usr/local/lib/vtk-6.2/libvtkFiltersGeneral-6.2.so.1
/usr/local/lib/vtk-6.2/libvtkCommonComputationalGeometry-6.2.so.1
/usr/local/lib/vtk-6.2/libvtkFiltersGeometry-6.2.so.1
/usr/local/lib/vtk-6.2/libvtkFiltersCore-6.2.so.1
/usr/local/lib/vtk-6.2/libvtkCommonExecutionModel-6.2.so.1
/usr/local/lib/vtk-6

Re: strage compile error [with attachments]

[blubee blubeeme]

The header file includes these headers:
//  SMESH SMESH : implementaion of SMESH idl descriptions
//  File   : SMESH_Algo.cxx
//  Author : Paul RASCLE, EDF
//  Module : SMESH

#include "SMESH_Algo.hxx"

#include "SMDS_EdgePosition.hxx"
#include "SMDS_FacePosition.hxx"
#include "SMDS_MeshElement.hxx"
#include "SMDS_MeshNode.hxx"
#include "SMDS_VolumeTool.hxx"
#include "SMESHDS_Mesh.hxx"
#include "SMESHDS_SubMesh.hxx"
#include "SMESH_Comment.hxx"
#include "SMESH_Gen.hxx"
#include "SMESH_HypoFilter.hxx"
#include "SMESH_Mesh.hxx"
#include "SMESH_MeshAlgos.hxx"
#include "SMESH_TypeDefs.hxx"
#include "SMESH_subMesh.hxx"

#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 

#include "utilities.h"

#include 
#include 
#include "SMESH_ProxyMesh.hxx"
#include "SMESH_MesherHelper.hxx"
#include 
using namespace std;

I don't really see anything that would cause such errors..

On Fri, Oct 27, 2017 at 8:24 PM, blubee blubeeme 
wrote:

> error:
> FAILED: lib/libSMESH.so
> : && /usr/bin/c++  -fPIC -Wall -Wextra -Wno-write-strings -O2 -pipe
> -fstack-protector -isystem /usr/local/include -fno-strict-aliasing
>  -isystem /usr/local/include -std=c++11 -Wno-undefined-var-template
> -D_OCC64 -Wno-sign-compare -Wno-reorder -Wno-switch -Wno-unused-variable
> -Wno-unused-private-field -Wno-unused-function -Wno-sometimes-uninitialized
> -Wno-overloaded-virtual -Wno-dynamic-class-memaccess -Wno-comment
> -Wno-unused-parameter -Wno-self-assign -Wno-reorder -Wno-switch-enum
> -Wno-unknown-pragmas -Wno-logical-op-parentheses -Wno-unused-variable
> -Wno-unused-function -Wno-overloaded-virtual -O2 -pipe -fstack-protector
> -isystem /usr/local/include -fno-strict-aliasing  -isystem
> /usr/local/include  -Wl,--no-undefined -shared -Wl,-soname,libSMESH.so -o
> lib/libSMESH.so 
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/libmesh.c.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverGMF.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverGMF_Read.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverGMF_Write.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverMED_Family.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/
> SMESH/DriverMED_R_SMESHDS_Mesh.cpp.o src/3rdParty/salomesmesh/
> CMakeFiles/SMESH.dir/src/SMESH/DriverMED_W_Field.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/
> SMESH/DriverMED_W_SMESHDS_Mesh.cpp.o src/3rdParty/salomesmesh/
> CMakeFiles/SMESH.dir/src/SMESH/GEOMUtils.cpp.o src/3rdParty/salomesmesh/
> CMakeFiles/SMESH.dir/src/SMESH/MED_Algorithm.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_CoordUtils.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_Factory.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_GaussDef.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_GaussUtils.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_Structures.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_Utilities.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_V2_2_Wrapper.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_Wrapper.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Algo.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Block.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Exception.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Gen.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Group.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_HypoFilter.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Hypothesis.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Mesh.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_MeshAlgos.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_MeshEditor.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_MeshVSLink.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_MesherHelper.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Octree.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_OctreeNode.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Pattern.cpp.o
> src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_ProxyMesh.cpp.o
> src/3rdParty/sal

FreeBSD Documentation

[blubee blubeeme]

How can we suggest edits for the docs?

The docs still reference using sysinstall to setup a jail when it hasn't
been that since at least 2011
https://www.freebsd.org/cgi/man.cgi?query=jail&sektion=8&manpath=freebsd-release-ports

 Start a shell in the jail:

   jail -c path=/data/jail/testjail mount.devfs \
   host.hostname=testhostname ip4.addr=192.0.2.100 \
   command=/bin/sh

 Assuming no errors, you will end up with a shell prompt within the jail.
 You can now run */usr/sbin/sysinstall* and do the post-install configura-
 tion to set various configuration options, or perform these actions manu-
 ally by editing */etc/rc.conf*, etc.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

writing drivers based on hardware manuals

[blubee blubeeme]

This is a request on where can I get more information and talk to other
FreeBSD developers about writing software to control hardware based on
dmidecode and a device manual.

I found this manual page that not only describe the fan controllers and lid
switch but also the keyboard LED controller as well.

https://www.manualslib.com/manual/1269646/Clevo-P650hs.html?page=114#manual

I should be able to write code to interface with this hardware directly
from FreeBSD.

Where can I go to get help with this?
___
freebsd-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: writing drivers based on hardware manuals

[blubee blubeeme]

ordered, 3-4 weeks until delivery.

Until then...

On Sun, Nov 12, 2017 at 5:42 PM, Kurt Jaeger  wrote:

> Hi!
>
> > This is a request on where can I get more information and talk to other
> > FreeBSD developers about writing software to control hardware based on
> > dmidecode and a device manual.
> >
> > I found this manual page that not only describe the fan controllers and
> lid
> > switch but also the keyboard LED controller as well.
> >
> > https://www.manualslib.com/manual/1269646/Clevo-P650hs.
> html?page=114#manual
> >
> > I should be able to write code to interface with this hardware directly
> > from FreeBSD.
> >
> > Where can I go to get help with this?
>
> Try this book:
>
> https://www.nostarch.com/bsddrivers.htm
>
> --
> p...@opsec.eu+49 171 3101372 3 years to
> go !
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Linux KMS/DRM and Google DRM

[blubee blubeeme]

Google is trying to get HDMI drm upstream into the linux kernel:
https://www.phoronix.com/scan.php?page=news_item&px=2017-Google-Intel-HDCP-DRM

As we see this coming, how would the guys on FreeBSD working on that Linux
kmod stuff deal when this stuff starts to creep into the linux kernel?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

xdg-desktop-menu-dummy.menu causes Firefox to crash

[blubee blubeeme]

This issue started happening recently I think after updating to the latest
version of Firefox.

Every so often I'll come back to my machine and Firefox has died, then in
one of my terminals I'll see this message:

kbuildsycoca4 running...
kbuildsycoca4(51442) VFolderMenu::loadDoc: Parse error in
"/usr/home/blubee/.config/menus/applications-merged/xdg-desktop-menu-dummy.menu"
, line  1 , col  1 :  "unexpected end of file"

When I look at the file in question it's just an empty file. I tried
grepping around finding that xdg-desktop-menu file but nothing came up.

Anyone have any idea what it's about or why is it crashing Firefox?
Firefox version: 57.0 (64-bit) from ports tree.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

valloric YCM [header definitions]

[blubee blubeeme]

I'm looking for where the u_int, u_long headers are defined?

for instance MOD_LOAD, UNLOAD, ENOTSUP along with u_int and u_long aren't
being picked up by libclang

module_t isn't being found either but I located that header file in
/usr/include/sys/module.h

snd_modevent(module_t mod, int type, void *data)
{

switch (type) {
case MOD_LOAD:
break;
case MOD_UNLOAD:
break;
default:
return (ENOTSUP);
break;
}
return 0;
}

Anyone here uses YCM?

Here's a verbose output of my global ycm_config. I hard coded the values to
test but still some headers like u_int, u_long and the above mentioned
MOD_* aren't being picked up.

Any ideas why?

'-std=c99',
'-x',
'c',
'-I',
'/usr/local/include',
'-I',
'/usr/include',
'-I',
'/usr/include/teken',
'-I',
'/usr/include/geom',
'-I',
'/usr/include/netgraph',
'-I',
'/usr/include/isofs',
'-I',
'/usr/include/net80211',
'-I',
'/usr/include/gssapi',
'-I',
'/usr/include/xlocale',
'-I',
'/usr/include/netpfil',
'-I',
'/usr/include/gcc',
'-I',
'/usr/include/bsnmp',
'-I',
'/usr/include/libxo',
'-I',
'/usr/include/ssp',
'-I',
'/usr/include/devdctl',
'-I',
'/usr/include/security',
'-I',
'/usr/include/crypto',
'-I',
'/usr/include/cam',
'-I',
'/usr/include/rdma',
'-I',
'/usr/include/infiniband',
'-I',
'/usr/include/rpcsvc',
'-I',
'/usr/include/atf-c',
'-I',
'/usr/include/netnatm',
'-I',
'/usr/include/ufs',
'-I',
'/usr/include/edit',
'-I',
'/usr/include/nfsserver',
'-I',
'/usr/include/netsmb',
'-I',
'/usr/include/gnu',
'-I',
'/usr/include/net',
'-I',
'/usr/include/private',
'-I',
'/usr/include/nfsclient',
'-I',
'/usr/include/openssl',
'-I',
'/usr/include/libmilter',
'-I',
'/usr/include/atf-c++',
'-I',
'/usr/include/netinet6',
'-I',
'/usr/include/x86',
'-I',
'/usr/include/dev',
'-I',
'/usr/include/bsm',
'-I',
'/usr/include/netipsec',
'-I',
'/usr/include/netinet',
'-I',
'/usr/include/krb5',
'-I',
'/usr/include/casper',
'-I',
'/usr/include/protocols',
'-I',
'/usr/include/lib80211',
'-I',
'/usr/include/arpa',
'-I',
'/usr/include/pcap',
'-I',
'/usr/include/nfs',
'-I',
'/usr/include/machine',
'-I',
'/usr/include/fs',
'-I',
'/usr/include/sys',
'-I',
'/usr/include/rpc',
'-I',
'/usr/include/kadm5',
'-I',
'/usr/include/vm',
'-I',
'/usr/include/c++',
'-I',
'/usr/include/lzma',
'-I',
'/sys',
'-I',
'/dev',
'-I',
'/usr/src',
___
freebsd-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: valloric YCM [header definitions]

[blubee blubeeme]

On Wed, Dec 6, 2017 at 2:18 AM, blubee blubeeme  wrote:

> I'm looking for where the u_int, u_long headers are defined?
>
> for instance MOD_LOAD, UNLOAD, ENOTSUP along with u_int and u_long aren't
> being picked up by libclang
>
> module_t isn't being found either but I located that header file in
> /usr/include/sys/module.h
>
> snd_modevent(module_t mod, int type, void *data)
> {
>
> switch (type) {
> case MOD_LOAD:
> break;
> case MOD_UNLOAD:
> break;
> default:
> return (ENOTSUP);
> break;
> }
> return 0;
> }
>
> Anyone here uses YCM?
>
> Here's a verbose output of my global ycm_config. I hard coded the values
> to test but still some headers like u_int, u_long and the above mentioned
> MOD_* aren't being picked up.
>
> Any ideas why?
>
> '-std=c99',
> '-x',
> 'c',
> '-I',
> '/usr/local/include',
> '-I',
> '/usr/include',
> '-I',
> '/usr/include/teken',
> '-I',
> '/usr/include/geom',
> '-I',
> '/usr/include/netgraph',
> '-I',
> '/usr/include/isofs',
> '-I',
> '/usr/include/net80211',
> '-I',
> '/usr/include/gssapi',
> '-I',
> '/usr/include/xlocale',
> '-I',
> '/usr/include/netpfil',
> '-I',
> '/usr/include/gcc',
> '-I',
> '/usr/include/bsnmp',
> '-I',
> '/usr/include/libxo',
> '-I',
> '/usr/include/ssp',
> '-I',
> '/usr/include/devdctl',
> '-I',
> '/usr/include/security',
> '-I',
> '/usr/include/crypto',
> '-I',
> '/usr/include/cam',
> '-I',
> '/usr/include/rdma',
> '-I',
> '/usr/include/infiniband',
> '-I',
> '/usr/include/rpcsvc',
> '-I',
> '/usr/include/atf-c',
> '-I',
> '/usr/include/netnatm',
> '-I',
> '/usr/include/ufs',
> '-I',
> '/usr/include/edit',
> '-I',
> '/usr/include/nfsserver',
> '-I',
> '/usr/include/netsmb',
> '-I',
> '/usr/include/gnu',
> '-I',
> '/usr/include/net',
> '-I',
> '/usr/include/private',
> '-I',
> '/usr/include/nfsclient',
> '-I',
> '/usr/include/openssl',
> '-I',
> '/usr/include/libmilter',
> '-I',
> '/usr/include/atf-c++',
> '-I',
> '/usr/include/netinet6',
> '-I',
> '/usr/include/x86',
> '-I',
> '/usr/include/dev',
> '-I',
> '/usr/include/bsm',
> '-I',
> '/usr/include/netipsec',
> '-I',
> '/usr/include/netinet',
> '-I',
> '/usr/include/krb5',
> '-I',
> '/usr/include/casper',
> '-I',
> '/usr/include/protocols',
> '-I',
> '/usr/include/lib80211',
> '-I',
> '/usr/include/arpa',
> '-I',
> '/usr/include/pcap',
> '-I',
> '/usr/include/nfs',
> '-I',
> '/usr/include/machine',
> '-I',
> '/usr/include/fs',
> '-I',
> '/usr/include/sys',
> '-I',
> '/usr/include/rpc',
> '-I',
> '/usr/include/kadm5',
> '-I',
> '/usr/include/vm',
> '-I',
> '/usr/include/c++',
> '-I',
> '/usr/include/lzma',
> '-I',
> '/sys',
> '-I',
> '/dev',
> '-I',
> '/usr/src',
>
>
There's no one on this mailing list that uses YCM for their FreeBSD
development?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Makefile show all flags

[blubee blubeeme]

When porting software FreeBSD has a lot of internal makefiles that gets
pulled in that setup the build environment: /usr/ports/Mk/*

Is there a way to print out the env during the make process so that I can
see what knobs, switches and flags were set before the build is run?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

get_swap_pager(x) failed

[blubee blubeeme]

I am seeing tons of these messages while running tail -f /var/log/messages

Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(25): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(22): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(11): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(32): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(25): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(8): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(6): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(32): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9

Re: get_swap_pager(x) failed

[blubee blubeeme]

On Tue, Dec 12, 2017 at 3:34 PM, blubee blubeeme 
wrote:

> I am seeing tons of these messages while running tail -f /var/log/messages
> 
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(25): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(22): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(11): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(32): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(25): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(8): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(6): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(32): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed
> Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed
> Dec 12 15:11:41 blubee ke

Re: get_swap_pager(x) failed

[blubee blubeeme]

On Wed, Dec 13, 2017 at 5:53 AM, Mark Millard  wrote:

> blubee blubeeme gurenchan at gmail.com wrote on
> Tue Dec 12 15:58:19 UTC 2017 :
>
> > On Tue, Dec 12, 2017 at 3:34 PM, blubee blubeeme  > >wrote:
> > > I am seeing tons of these messages while running tail -f
> /var/log/messages
> > > 
> > > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(25): failed
> > . . .
> > >  1159 blubee5  200   149M 56876K select  6   1:05   0.00%
> > > ibus-engine-chewing
> > >
> > > ===
> > >
> > > What's with all the swap errors? I am running ZFS and I have 16GB of
> ram,
> > > how could I be having swap space errors?
> > >
> >
> > Well I added 4GB of extra swap in /var/tmp/swap0
> > then added that to my /etc/fstab: md99noneswap
> > sw,file=/var/tmp/swap0,late 0   0
> >
> > and those errors went away.
>
> I recommend reviewing bugzilla 206048 (title in part
> "swapfile usage hangs; swap partition works"):
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206048
>
> before using file-system based swap spaces. They have
> lots of problems with deadlocks. See especially comments
> #7 and #8 quoting Konstantin Belousov. #8 is just a
> reference to:
>
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/
> kerneldebug-deadlocks.html
>
> Comment #3 shows a way to test for the problematical
> behavior.
>
> Using swap partitions avoids the issue.
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
>
Thanks for the info, why would I be getting swap errors like that when I
have 32GB of ram?
sysctl hw.physmem
hw.physmem: 34253692928

That really doesn't make any sense to me... Is it Chromium eating up 32GB+
of ram?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

kernel names

[blubee blubeeme]

When you boot into FreeBSD and you can select kernels, there's only 2
options:
default and kernel.old

Is there a way to have better output and support multiple kernels without
having to login to the system and running uname -v or something like that?

Would it be possible to add options for more kernels from that boot menu?
___
freebsd-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: get_swap_pager(x) failed

[blubee blubeeme]

On Thu, Dec 14, 2017 at 1:43 PM, Peter Jeremy  wrote:

> On 2017-Dec-13 11:23:46 +, Gary Palmer  wrote:
> >An open question would be why ARC is not reducing if the system is
> >under memory pressure.  It's meant to, but there have been various
> >bugs in that implementation.
>
> The OP doesn't say what version of -current he is running but I would
> point the finger at r325851.  I have discovered that, in 11-stable,
> r326619 (which is the MFC of r325851) stops ARC responding to memory
> backpressure.
>
> --
> Peter Jeremy
>

I just did a new install world and kernel so I'm but this is uname -v
FreeBSD 12.0-CURRENT #0 r326839: Thu Dec 14 13:34:47 CST 2017
 root@blubee:/usr/obj/usr/src/amd64.amd64/sys/OSS_GENERIC

The previous was with GENERIC kernel and maybe ports & src from two weeks
ago.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kernel names

[blubee blubeeme]

On Thu, Dec 14, 2017 at 1:51 PM, Allan Jude  wrote:

> On 12/14/2017 00:47, blubee blubeeme wrote:
> > When you boot into FreeBSD and you can select kernels, there's only 2
> > options:
> > default and kernel.old
> >
> > Is there a way to have better output and support multiple kernels without
> > having to login to the system and running uname -v or something like
> that?
> >
> > Would it be possible to add options for more kernels from that boot menu?
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> freebsd.org"
> >
>
> The list is controlled by the /boot/loader.conf variable kernels=
> which defaults to "kernel kernel.old"
>
> I have a patch almost ready to land that will search all subdirectories
> of /boot for a file named 'kernel' and add the names of those
> directories to the list, such that the list will basically be
> autogenerated.
>
> It currently contains too much copy/pasted code, and I just need to
> clean it up a bit: https://reviews.freebsd.org/D11886
>
> It was originally designed as part of my contributions towards packaged
> base, where pkg will keep the last N (default to 5 I think) kernel
> packages you have installed around, incase an upgrade goes bad.
>
> This feature will work on any filesystem supported by the loader.
>
> --
> Allan Jude
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>

Allen, thanks for the great work. I'll test it out but I can't wait to have
it merged in.
___
freebsd-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: [Request for review] Profiling the FreeBSD kernel boot

[blubee blubeeme]

On Fri, Dec 22, 2017 at 5:44 PM, Colin Percival 
wrote:

> Hi everyone,
>
> For the past few months I've been working on code for profiling the FreeBSD
> "kernel boot", i.e., everything between when kernel code starts running and
> when we first enter userland as init(8).  This is not trivial since it's
> impossible to use tools like dtrace to monitor things prior to when said
> tools are running.  The goal of this exercise is to help me track down the
> places where we're wasting time during the boot, and then to fix them.
>
> The approach I've taken is to add some macros -- most notably TSENTER() and
> TSEXIT() -- which by default compile to nothing, but if the TSLOG kernel
> option is enabled they compile to code which logs the cycle count (e.g., on
> x86 the value from the RDTSC instruction) along with some other data (in
> the
> case of TSENTER and TSEXIT, the fact that we're entering/exiting a
> function).
> This can then be dumped via a sysctl (debug.tslog) and processed in
> userland
> to convert function entries/exits into stacks and to visualize the time
> spent
> in the boot process.
>
> Two examples:
>
> A flame chart of my laptop booting HEAD:
> http://www.daemonology.net/timestamping/tslog-laptop.svg
>
> A flame chart of an EC2 c5.4xlarge instance booting 11.1-RELEASE:
> http://www.daemonology.net/timestamping/tslog-c5.4xlarge.svg
>
> The patches (10 of them, to be applied in order), userland scripts, and
> very
> brief usage instructions are at:
> http://www.daemonology.net/timestamping/tslog.tgz
>
> I hope to commit the patches in the next week, since I'm planning on
> writing
> a paper to submit to AsiaBSDCon (which has a deadline of December 31st); so
> if anyone has interest/time to look at this in the near future (I mean,
> it's
> not like anyone is going to be busy this weekend, right?) I'd love to have
> some feedback before it goes into the tree.
>
> --
> Colin Percival
> Security Officer Emeritus, FreeBSD | The power to serve
> Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
I've gotta say  nice work with the tracing.
Hopefully your talk gets accepted, i'd love to hear it.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Programmatically cache line

[blubee blubeeme]

Is there some way to programmatically get the CPU cache line sizes on
FreeBSD?
___
freebsd-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: Programmatically cache line

[blubee blubeeme]

On Tue, Jan 2, 2018 at 12:26 AM, Ian Lepore  wrote:

> On Mon, 2018-01-01 at 12:36 +0200, Konstantin Belousov wrote:
> > On Mon, Jan 01, 2018 at 06:52:37AM +, David Chisnall wrote:
> > >
> > > On 1 Jan 2018, at 05:09, Adrian Chadd  wrote:
> > > >
> > > >
> > > > On 30 December 2017 at 00:28, Konstantin Belousov  wrote:
> > > > >
> > > > > On Sat, Dec 30, 2017 at 07:50:19AM +, blubee blubeeme wrote:
> > > > > >
> > > > > > Is there some way to programmatically get the CPU cache line
> sizes on
> > > > > > FreeBSD?
> > > > > There are, all of them are MD.
> > > > >
> > > > > On x86, the CPUID instruction leaf 0x1 returns the information in
> > > > > %ebx register.
> > > > Hm, weird. Why don't we extend sysctl to include this info?
> > For the same reason we do not provide a sysctl to add two integers.
> >
> > >
> > >
> > > It would be nice to expose this kind of information via VDSO or
> similar.  There are a lot of similar bits of info that people want to use
> for ifunc and, SVE is going to have a bunch of similar requirements.
> > >
> > Is VDSO a new trendy word ?
> >
> > ifunc resolvers in usermode on FreeBSD/x86 get four arguments which
> > are essentially cpu_features / cpu_features2 / cpu_stdext_features /
> > cpu_stdext_features2.  I suspect that only FreeBSD/x86 arches have the
> > ifunc support, in rtld and coming shortly in kernel.
> >
> > Recently HW_CAP/HW_CAP2 were added to the ELF auxv, and elf_aux_info(3)
> > interface exported from libc.
> >
> > ARM* did not implemented yet the ifunc stubs in rtld. I believe this is
> > considered a low priority because there is no ready to use toolchain
> > which allow to utilize ifuncs on FreeBSD, except if you use recent bfd
> > ld externally.
>
> Linux exports this info using getauxval().  I think we should support
> getauxval() and as many of the AT_* values that linux defines as makes
> sense for us to do.
>
> I think it was a mistake to give our version of the function a
> different name and different semantics, but this is something that
> affects mainly ports, and I don't yet have enough info to make the case
> that being linux-compatible will ease porting rather than complicate it
> (in some cases, patches will be needed either way).
>
> -- Ian
>
FreeBSD implements hardware specific atomic instructions [man atomic] or
look at: #include 

but implementing something that returns size of cache lines is somehow out
of the question?

If you're working with atomic data structures and want to ensure there's no
false sharing the
simplest method I know is to put some padding that's sizeof(cache_line) -
sizeof(data_members)
so that you can try to get them to live on different cache line.

Do we have to go in and write inline assembly to grab the size of the cache
line or wouldn't it
be simpler to have atomic.h return this 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"

USB stack

[blubee blubeeme]

Does FreeBSD current USB stack support usb >= 2.0 devices?

Testing out the USB devices support I get about 7.2-7.8 megabytes per
second which seems odd.
___
freebsd-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 stack

[blubee blubeeme]

On Wed, Jan 3, 2018 at 6:41 PM, O'Connor, Daniel  wrote:

>
>
> > On 3 Jan 2018, at 11:31, blubee blubeeme  wrote:
> > Does FreeBSD current USB stack support usb >= 2.0 devices?
>
> Absolutely.
>
> > Testing out the USB devices support I get about 7.2-7.8 megabytes per
> > second which seems odd.
>
> What sort of test? What sort of device? What sort of port?
>
> What is the output of dmesg and usbconfig?
>
> --
> Daniel O'Connor
> "The nice thing about standards is that there
> are so many of them to choose from."
>  -- Andrew Tanenbaum
> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
>
> I transferred about 30GB of audio from laptop to Samsung usb class 10 usb
device connected to LG v30.

current usbconfig shows this:
ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER
(5.0Gbps) pwr=SAVE (0mA)
ugen0.3:  at usbus0, cfg=0 md=HOST
spd=HIGH (480Mbps) pwr=ON (500mA)
ugen0.2:  at usbus0, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (100mA)
___
freebsd-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: Intel CPU design flaw - FreeBSD affected?

[blubee blubeeme]

On Thu, Jan 4, 2018 at 8:51 AM, Mark Heily  wrote:

> On Jan 2, 2018 19:05, "Warner Losh"  wrote:
>
> The register article says the specifics are under embargo still. That would
> make it hard for anybody working with Intel to comment publicly on the flaw
> and any mitigations that may be underway. It would be unwise to assume that
> all the details are out until the embargo lifts.
>
>
> Details of the flaws are now published at:
>
> https://meltdownattack.com
>
>
> Warner
>
> On Jan 2, 2018 4:13 PM, "Michael Butler" 
> wrote:
>
> > Has any impact assessment been made as to FreeBSD's exposure or
> > mitigation strategies?
> >
> > 'Kernel memory leaking' Intel processor design flaw forces Linux,
> > Windows redesign - The Register
> >
> > Other OSes will need an update, performance hits loom A fundamental
> > design flaw in Intel's processor chips has forced a significant redesign
> > of the Linux and Windows kernels to defang the chip-level security bug.…
> > Programmers are scrambling to overhaul the open-source Linux kernel's
> > virtual memory system. Meanwhile, Microsoft is expected to publicly
> > introduce necessary changes to its Windows operating system in this
> > month's Patch Tuesday ...
> >
> > https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
> >
> > imb
> >
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> freebsd.org"
> >
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
This is insane...

And to think a few months ago people were complaining that Ryzen processors
and specifically Threadripper might be insecure in data centers, ha.

This is a massive clusterfk
___
freebsd-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: Intel CPU design flaw - FreeBSD affected? // disabling _R_DTSC

[blubee blubeeme]

On Fri, Jan 5, 2018 at 2:25 AM, Klaus P. Ohrhallinger  wrote:

> On 04.01.2018 19:23, Klaus P. Ohrhallinger wrote:
> > Hello,
> >
> > I disabled the ldtsc and ldtscp instructions for usermode on one of my
> > production servers:
> >
>
> Oops, RDTSC of course.
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
I'd love to see if RISC-V is vulnerable to this?

I think they are in the best position to capitalize on this clusterfk...
___
freebsd-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: Programmatically cache line

[blubee blubeeme]

On Fri, Jan 5, 2018 at 2:29 AM, Konstantin Belousov 
wrote:

> On Thu, Jan 04, 2018 at 10:03:32AM +, David Chisnall wrote:
> > On 3 Jan 2018, at 22:12, Nathan Whitehorn 
> wrote:
> > >
> > > On 01/03/18 13:37, Ed Schouten wrote:
> > >> 2018-01-01 11:36 GMT+01:00 Konstantin Belousov :
> > >> On x86, the CPUID instruction leaf 0x1 returns the information in
> > >> %ebx register.
> > > Hm, weird. Why don't we extend sysctl to include this info?
> > >>> For the same reason we do not provide a sysctl to add two integers.
> > >> I strongly agree with Kostik on this one. Why add stuff to the kernel,
> > >> if userspace is already capable of extracting this? Adding that stuff
> > >> to sysctl has the downside that it will effectively introduce yet
> > >> another FreeBSDism, whereas something generic already exists.
> > >>
> > >
> > > Well, kind of. The userspace version is platform-dependent and not
> always available: for example, on PPC, you can't do this from userland and
> we provide a sysctl machdep.cacheline_size to userland. It would be nice to
> have an MI API.
> >
> > On ARMv8, similarly, sometimes the kernel needs to advertise the wrong
> size.  A few big.LITTLE cores have 64-byte cache lines on one cluster and
> 32-byte on the other.  If you query the size from userspace while running
> on a 64-byte cluster, then issue the zero-cache-line instruction while
> migrated to the 32-byte cluster, you only clear half the size.  Linux works
> around this by trapping and emulating the instruction to query the cache
> size and always reporting the size for the smallest cache lines.  ARM tells
> people not to build systems like this, but it doesn???t always stop them.
> Trapping and emulating is much slower than just providing the information
> in a shared page, elf aux args vector, or even (often) a system call.
>
> Of course MD way is the best way to get such information, just because the
> meaning of the 'cache line size' exists only in context of the given CPU
> (micro)architecture.  For instance, on PowerPC and ARM you are often
> concerned
> with the granularity of the instruction cache flush, but also you might be
> concerned with the DMA, and these are different concepts of cache.
>
> Even on x86, you may care about alignment to avoid false sharing or
> about CLFLUSH granularity, and these can be different legitimately.
> Which one to report as 'cache line' ?
>
> And you cannot bail out with the max among all constants, because sometimes
> you really need the min size (for CLFLUSH), and sometime max size (for
> false sharing).
>
> >
> > To give another example, Linux provides a very cheap way for a userspace
> process to enquire which core it???s running on.  Some more recent
> high-performance mallocs use this to have a second-layer per-core cache
> after the per-thread cache for free blocks.  Unlike the per-thread cache,
> the per-core cache does need a lock, but it???s very unlikely to be
> contended (it will only be contended if either a thread is migrated in
> between checking and locking, so acquires the wrong CPU???s lock, or if a
> thread is preempted in the middle of middle of the very brief fill
> operation).  The author of the SuperMalloc paper tried doing this with
> CPUID and found that it was slower by a sufficient margin to almost
> entirely offset the benefits of the extra layer of caching.
>
> There, RDTSCP is the intended way to get cpu id in userspace, but the use
> of this instruction requires some minimal OS support.  It should be faster
> than CPUID, since it is not fully serializing.  We do not support it only
> because nobody asked so far.
>
> >
> > Just because userspace can get at the information directly from the
> hardware doesn???t mean that this is the most efficient or best way for
> userspace to get at it.
> >
> It depends, but single instruction (!) vs syscall comparision makes this
> discussion silly.
>
> > Oh, and some of these things are useful in portable code, so having to
> write some assembly for every target to get information that the kernel
> already knows is wasteful.
> >
> Required work is to provide the definitions of these interfaces, then they
> can be implemented in the best way for each architecture.  But nobody did
> that.
>
Initially I was "asking" to see if these facilities were available so that
I didn't have to go do some hack job
that would be brittle or reinvent the wheel.

My use case for getting the cache lines was to prevent false sharing.
I should've been more clear about that in my initial email but,
I didn't know all these other people were interested in this issue as well.

since I'd like the cache line sizes to prevent false sharing that's my use
case.

Does anyone else have any use cases that they would like to propose?

Once we have come to some agreement on what features they need,
then we can work out the interfaces and get the work done on implementation?

> ___
> freebsd-curren

Re: USB stack

[blubee blubeeme]

I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
and the topic gets derailed...?

Are you guys saying that 7-8MB/s is USB speeds?

On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel  wrote:

>
>
> > On 4 Jan 2018, at 09:23, Gary Jennejohn  wrote:
> >> What is an "LG v30"?
> >>
> > It's a smartphone from LG and only supports USB2 speed.  The reported
> > transfer rate is no big surprise.
>
> OK thanks.
>
> --
> Daniel O'Connor
> "The nice thing about standards is that there
> are so many of them to choose from."
>  -- Andrew Tanenbaum
> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
>
>
___
freebsd-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 stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 11:56 AM, blubee blubeeme 
wrote:

> I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
> and the topic gets derailed...?
>
> Are you guys saying that 7-8MB/s is USB speeds?
>
> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
> wrote:
>
>>
>>
>> > On 4 Jan 2018, at 09:23, Gary Jennejohn  wrote:
>> >> What is an "LG v30"?
>> >>
>> > It's a smartphone from LG and only supports USB2 speed.  The reported
>> > transfer rate is no big surprise.
>>
>> OK thanks.
>>
>> --
>> Daniel O'Connor
>> "The nice thing about standards is that there
>> are so many of them to choose from."
>>  -- Andrew Tanenbaum
>> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
>>
>>
> Actually, this post: https://forums.freebsd.org/threads/41041/

on the forum from 2013 pretty well describes what I am experiencing when
moving data over USB.

I have no problems hitting very high read/ write speeds using dd or
downloading something but copying by USB is excruciatingly slow.

Why is that?
___
freebsd-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 stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 12:17 PM, Warner Losh  wrote:

>
>
> On Sat, Jan 6, 2018 at 9:08 PM, blubee blubeeme 
> wrote:
>
>> On Sun, Jan 7, 2018 at 11:56 AM, blubee blubeeme 
>> wrote:
>>
>> > I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
>> > and the topic gets derailed...?
>> >
>> > Are you guys saying that 7-8MB/s is USB speeds?
>> >
>> > On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
>> > wrote:
>> >
>> >>
>> >>
>> >> > On 4 Jan 2018, at 09:23, Gary Jennejohn 
>> wrote:
>> >> >> What is an "LG v30"?
>> >> >>
>> >> > It's a smartphone from LG and only supports USB2 speed.  The reported
>> >> > transfer rate is no big surprise.
>> >>
>> >> OK thanks.
>> >>
>> >> --
>> >> Daniel O'Connor
>> >> "The nice thing about standards is that there
>> >> are so many of them to choose from."
>> >>  -- Andrew Tanenbaum
>> >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
>> >>
>> >>
>> > Actually, this post: https://forums.freebsd.org/threads/41041/
>>
>> on the forum from 2013 pretty well describes what I am experiencing when
>> moving data over USB.
>>
>> I have no problems hitting very high read/ write speeds using dd or
>> downloading something but copying by USB is excruciatingly slow.
>>
>> Why is that?
>
>
> If you are copying a boatload of tiny files to USB there's two issues.
> Both our UFS and MSDOS don't do well in this case. Second, for flash based
> USB thumbdrives, most of them have horrible write performance unless you
> buy quality drives...
>
> Warner
>
I would consider this：
https://www.samsung.com/us/computing/memory-storage/memory-cards/micro-sd-evo-256gb-memory-card-w-adapter-mb-mc256da-am/
 256GB Samsung microsd card quality.
___
freebsd-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 stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 12:20 PM, Warner Losh  wrote:

>
>
> On Sat, Jan 6, 2018 at 9:18 PM, blubee blubeeme 
> wrote:
>
>>
>>
>> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh  wrote:
>>
>>>
>>>
>>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme 
>>> wrote:
>>>
>>>> I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
>>>> and the topic gets derailed...?
>>>>
>>>
>>> Yes, it does.
>>>
>>>
>>>> Are you guys saying that 7-8MB/s is USB speeds?
>>>>
>>>
>>> I've gotten up to 24MB/s for maybe a decade. That's not possible with
>>> USB 1.x. More recently, I've maxed out the writes on a USB stick at about
>>> 75MB/s (the fastest it will do), which isn't possible with USB 2.0... I've
>>> not tried USB3 with an SSD that can do more
>>>
>>> Warner
>>>
>>>
>>>> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
>>>> wrote:
>>>>
>>>> >
>>>> >
>>>> > > On 4 Jan 2018, at 09:23, Gary Jennejohn 
>>>> wrote:
>>>> > >> What is an "LG v30"?
>>>> > >>
>>>> > > It's a smartphone from LG and only supports USB2 speed.  The
>>>> reported
>>>> > > transfer rate is no big surprise.
>>>> >
>>>> > OK thanks.
>>>> >
>>>> > --
>>>> > Daniel O'Connor
>>>> > "The nice thing about standards is that there
>>>> > are so many of them to choose from."
>>>> >  -- Andrew Tanenbaum
>>>> > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
>>>> >
>>>> >
>>>> ___
>>>> freebsd-current@freebsd.org mailing list
>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f
>>>> reebsd.org"
>>>>
>>>
>>> I just connected a Transcend StorageJet 1TB hdd not a mobile phone
>> ---
>> Jan  7 11:56:56 blubee kernel: umass0 on uhub0
>> Jan  7 11:56:56 blubee kernel: umass0: > Transcend, class 0/0, rev 3.00/80.00, addr 4> on usbus0
>> Jan  7 11:56:56 blubee kernel: umass0:  SCSI over Bulk-Only; quirks =
>> 0x0100
>> Jan  7 11:56:56 blubee kernel: umass0:3:0: Attached to scbus3
>> Jan  7 11:56:56 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0
>> lun 0
>> Jan  7 11:56:56 blubee kernel: da0:  Fixed Direct
>> Access SPC-4 SCSI device
>> Jan  7 11:56:56 blubee kernel: da0: Serial Number W9328YZN
>> Jan  7 11:56:56 blubee kernel: da0: 400.000MB/s transfers
>> Jan  7 11:56:56 blubee kernel: da0: 953869MB (1953525168 512 byte sectors)
>> Jan  7 11:56:56 blubee kernel: da0: quirks=0x2
>> Jan  7 12:06:08 blubee kernel: lock order reversal:
>> Jan  7 12:06:08 blubee kernel:  1st 0xfe07c26336c0 bufwait (bufwait)
>> @ /usr/src/sys/vm/vm_pager.c:374
>> Jan  7 12:06:08 blubee kernel:  2nd 0xf80148c425f0 zfs (zfs) @
>> /usr/src/sys/dev/md/md.c:952
>> Jan  7 12:06:08 blubee kernel: stack backtrace:
>> Jan  7 12:06:08 blubee kernel: #0 0x80acfa03 at
>> witness_debugger+0x73
>> Jan  7 12:06:08 blubee kernel: #1 0x80acf882 at
>> witness_checkorder+0xe02
>> Jan  7 12:06:08 blubee kernel: #2 0x80a41b8e at
>> lockmgr_lock_fast_path+0x1ae
>> Jan  7 12:06:08 blubee kernel: #3 0x81094309 at VOP_LOCK1_APV+0xd9
>> Jan  7 12:06:08 blubee kernel: #4 0x80b4ac36 at _vn_lock+0x66
>> Jan  7 12:06:08 blubee kernel: #5 0x80611d32 at
>> mdstart_vnode+0x442
>> Jan  7 12:06:08 blubee kernel: #6 0x806102ce at md_kthread+0x1fe
>> Jan  7 12:06:08 blubee kernel: #7 0x80a2d654 at fork_exit+0x84
>> Jan  7 12:06:08 blubee kernel: #8 0x80ef5e0e at
>> fork_trampoline+0xe
>> Jan  7 12:06:15 blubee kernel: lock order reversal:
>> Jan  7 12:06:15 blubee kernel:  1st 0xfe07c41d5dc0 bufwait (bufwait)
>> @ /usr/src/sys/kern/vfs_bio.c:3562
>> Jan  7 12:06:15 blubee kernel:  2nd 0xf8002bb31a00 dirhash (dirhash)
>> @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281
>> Jan  7 12:06:15 blubee kernel: stack backtrace:
>> Jan  7 12:06:15 blubee kernel: #0 0x80acfa03 at
>> witness_debugger+0x73
>> 

Re: USB stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh  wrote:

>
>
> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme 
> wrote:
>
>> I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
>> and the topic gets derailed...?
>>
>
> Yes, it does.
>
>
>> Are you guys saying that 7-8MB/s is USB speeds?
>>
>
> I've gotten up to 24MB/s for maybe a decade. That's not possible with USB
> 1.x. More recently, I've maxed out the writes on a USB stick at about
> 75MB/s (the fastest it will do), which isn't possible with USB 2.0... I've
> not tried USB3 with an SSD that can do more
>
> Warner
>
>
>> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
>> wrote:
>>
>> >
>> >
>> > > On 4 Jan 2018, at 09:23, Gary Jennejohn  wrote:
>> > >> What is an "LG v30"?
>> > >>
>> > > It's a smartphone from LG and only supports USB2 speed.  The reported
>> > > transfer rate is no big surprise.
>> >
>> > OK thanks.
>> >
>> > --
>> > Daniel O'Connor
>> > "The nice thing about standards is that there
>> > are so many of them to choose from."
>> >  -- Andrew Tanenbaum
>> > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
>> >
>> >
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
>> "
>>
>
> I just connected a Transcend StorageJet 1TB hdd not a mobile phone
---
Jan  7 11:56:56 blubee kernel: umass0 on uhub0
Jan  7 11:56:56 blubee kernel: umass0:  on usbus0
Jan  7 11:56:56 blubee kernel: umass0:  SCSI over Bulk-Only; quirks = 0x0100
Jan  7 11:56:56 blubee kernel: umass0:3:0: Attached to scbus3
Jan  7 11:56:56 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0 lun 0
Jan  7 11:56:56 blubee kernel: da0:  Fixed Direct
Access SPC-4 SCSI device
Jan  7 11:56:56 blubee kernel: da0: Serial Number W9328YZN
Jan  7 11:56:56 blubee kernel: da0: 400.000MB/s transfers
Jan  7 11:56:56 blubee kernel: da0: 953869MB (1953525168 512 byte sectors)
Jan  7 11:56:56 blubee kernel: da0: quirks=0x2
Jan  7 12:06:08 blubee kernel: lock order reversal:
Jan  7 12:06:08 blubee kernel:  1st 0xfe07c26336c0 bufwait (bufwait) @
/usr/src/sys/vm/vm_pager.c:374
Jan  7 12:06:08 blubee kernel:  2nd 0xf80148c425f0 zfs (zfs) @
/usr/src/sys/dev/md/md.c:952
Jan  7 12:06:08 blubee kernel: stack backtrace:
Jan  7 12:06:08 blubee kernel: #0 0x80acfa03 at
witness_debugger+0x73
Jan  7 12:06:08 blubee kernel: #1 0x80acf882 at
witness_checkorder+0xe02
Jan  7 12:06:08 blubee kernel: #2 0x80a41b8e at
lockmgr_lock_fast_path+0x1ae
Jan  7 12:06:08 blubee kernel: #3 0x81094309 at VOP_LOCK1_APV+0xd9
Jan  7 12:06:08 blubee kernel: #4 0x80b4ac36 at _vn_lock+0x66
Jan  7 12:06:08 blubee kernel: #5 0x80611d32 at mdstart_vnode+0x442
Jan  7 12:06:08 blubee kernel: #6 0x806102ce at md_kthread+0x1fe
Jan  7 12:06:08 blubee kernel: #7 0x80a2d654 at fork_exit+0x84
Jan  7 12:06:08 blubee kernel: #8 0x80ef5e0e at fork_trampoline+0xe
Jan  7 12:06:15 blubee kernel: lock order reversal:
Jan  7 12:06:15 blubee kernel:  1st 0xfe07c41d5dc0 bufwait (bufwait) @
/usr/src/sys/kern/vfs_bio.c:3562
Jan  7 12:06:15 blubee kernel:  2nd 0xf8002bb31a00 dirhash (dirhash) @
/usr/src/sys/ufs/ufs/ufs_dirhash.c:281
Jan  7 12:06:15 blubee kernel: stack backtrace:
Jan  7 12:06:15 blubee kernel: #0 0x80acfa03 at
witness_debugger+0x73
Jan  7 12:06:15 blubee kernel: #1 0x80acf882 at
witness_checkorder+0xe02
Jan  7 12:06:15 blubee kernel: #2 0x80a748a8 at _sx_xlock+0x68
Jan  7 12:06:15 blubee kernel: #3 0x80d6a28d at ufsdirhash_add+0x3d
Jan  7 12:06:15 blubee kernel: #4 0x80d6d119 at ufs_direnter+0x459
Jan  7 12:06:15 blubee kernel: #5 0x80d76313 at ufs_makeinode+0x613
Jan  7 12:06:15 blubee kernel: #6 0x80d71ff4 at ufs_create+0x34
Jan  7 12:06:15 blubee kernel: #7 0x810919e3 at VOP_CREATE_APV+0xd3
Jan  7 12:06:15 blubee kernel: #8 0x80b4a53d at vn_open_cred+0x2ad
Jan  7 12:06:15 blubee kernel: #9 0x80b42e92 at kern_openat+0x212
Jan  7 12:06:15 blubee kernel: #10 0x80f16d2b at amd64_syscall+0x79b
Jan  7 12:06:15 blubee kernel: #11 0x80ef5b7b at Xfast_syscall+0xfb


Is the slow transfers user error?
___
freebsd-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 stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 12:25 PM, Warner Losh  wrote:

>
>
> On Sat, Jan 6, 2018 at 9:20 PM, blubee blubeeme 
> wrote:
>
>>
>>
>> On Sun, Jan 7, 2018 at 12:17 PM, Warner Losh  wrote:
>>
>>>
>>>
>>> On Sat, Jan 6, 2018 at 9:08 PM, blubee blubeeme 
>>> wrote:
>>>
>>>> On Sun, Jan 7, 2018 at 11:56 AM, blubee blubeeme 
>>>> wrote:
>>>>
>>>> > I ask does FreeBSD usb stack actually implements USB spec 2.0 or
>>>> greater
>>>> > and the topic gets derailed...?
>>>> >
>>>> > Are you guys saying that 7-8MB/s is USB speeds?
>>>> >
>>>> > On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
>>>> > wrote:
>>>> >
>>>> >>
>>>> >>
>>>> >> > On 4 Jan 2018, at 09:23, Gary Jennejohn 
>>>> wrote:
>>>> >> >> What is an "LG v30"?
>>>> >> >>
>>>> >> > It's a smartphone from LG and only supports USB2 speed.  The
>>>> reported
>>>> >> > transfer rate is no big surprise.
>>>> >>
>>>> >> OK thanks.
>>>> >>
>>>> >> --
>>>> >> Daniel O'Connor
>>>> >> "The nice thing about standards is that there
>>>> >> are so many of them to choose from."
>>>> >>  -- Andrew Tanenbaum
>>>> >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
>>>> >>
>>>> >>
>>>> > Actually, this post: https://forums.freebsd.org/threads/41041/
>>>>
>>>> on the forum from 2013 pretty well describes what I am experiencing when
>>>> moving data over USB.
>>>>
>>>> I have no problems hitting very high read/ write speeds using dd or
>>>> downloading something but copying by USB is excruciatingly slow.
>>>>
>>>> Why is that?
>>>
>>>
>>> If you are copying a boatload of tiny files to USB there's two issues.
>>> Both our UFS and MSDOS don't do well in this case. Second, for flash based
>>> USB thumbdrives, most of them have horrible write performance unless you
>>> buy quality drives...
>>>
>>> Warner
>>>
>> I would consider this： https://www.samsung.com/
>> us/computing/memory-storage/memory-cards/micro-sd-evo-256gb-
>> memory-card-w-adapter-mb-mc256da-am/
>>  256GB Samsung microsd card quality.
>>
>
> At most, you can get 90MB/s read/write on this card. What are you seeing?
> And how are you copying?
>
> Warner
>
I use the phone, LG V30 to record basically ungraded RAW video files to the
microsd card; they are large files.
I transfer them to my computer copy a backup to the 1TB driver; then do
edits/ color grading, etc in blender,
then I transfer the finished to another 1TB hdd for backup as well.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"