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"

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

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

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: 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 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 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
> >>>>> just leave?
> >&g

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?
> >>>
> >>> Those 30,000 ports many of them bring bugs

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 on this drm-legacy-kmod stuff done any testings
of how this will 

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 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 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 team is working very hard to destroy the stability of
>> Fre

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 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 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/mailman/listinfo/freebsd-current
&

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: building LLVM threads gets killed

[blubee blubeeme]

On Mon, Aug 20, 2018 at 11:04 PM Mark Millard  wrote:

> Rodney W. Grimes freebsd-rwg at pdx.rh.CN85.dnsmgr.net wrote on
> Mon Aug 20 14:26:55 UTC 2018 :
>
> > > On 20 Aug 2018, at 05:01, blubee blubeeme 
> wrote:
> > > >
> > > > I am running current compiling LLVM60 and when it comes to linking
> > > > basically all the processes on my computer gets killed; Chrome,
> Firefox and
> > > > some of the LLVM threads as well
> > > ...
> > > > llvm/build % ninja -j8
> > > > [2408/2473] Building CXX object
> > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o
> > > > FAILED: lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o
> > > > /usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS
> > > > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Passes
> -I../lib/Passes
> > > > -Iinclude -I../include -isystem /usr/local/include -fPIC
> > > > -fvisibility-inlines-hidden -Werror=date-time
> > > > -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra
> > > > -Wno-unused-parameter -Wwrite-strings -Wcast-qual
> > > > -Wmissing-field-initializers -pedantic -Wno-long-long
> > > > -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
> > > > -Wstring-conversion -fdiagnostics-color -g-fno-exceptions
> -fno-rtti -MD
> > > > -MT lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -MF
> > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o.d -o
> > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -c
> > > > ../lib/Passes/PassBuilder.cpp
> > > > c++: error: unable to execute command: Killed
> > >
> > > It is running out of RAM while running multiple parallel link jobs.  If
> > > you are building using WITH_DEBUG, turn that off, it consumes large
> > > amounts of memory.  If you must have debug info, try adding the
> > > following flag to the CMake command line:
> > >
> > > -D LLVM_PARALLEL_LINK_JOBS:STRING="1"
> > >
> > > That will limit the amount of parallel link jobs to 1, even if you
> > > specify -j 8 to gmake or ninja.
> > >
> > > Brooks, it would not be a bad idea to always use this CMake flag in the
> > > llvm ports. :)
> >
> > And this may also fix the issues that all the small
> > memory (aka, RPI*) buliders are facing when trying
> > to do -j4?
>
> It may help, but:
>
> Even just compiles with no links running can get the kills
> in such small system contexts.
>
> And going for a simpler context that can demonstrate
> the behavior . . .
>
> Taking a Pine64+ 2GB as an example (4 cores with 1
> HW-thread per core, 2 GiBytes of RAM, USB device for
> root file system and swap partition):
>
> In another login:
> # stress -d 2 -m 4 --vm-keep --vm-bytes 536870912
>
> That "4" and "536870912" total to the 2 GiBytes so
> swapping is induced for the context in question.
> (Scale --vm-bytes appropriately to context.)
> [Note: I had 3 GiBytes of swap space in a partition
> for the below.]
>
> [stress is from the port sysutils/stress .]
>
> I had left the default vm.pageout_oom_seq=12 in place for this,
> making the kills easier to get than the 120 figure would. It
> does not take very long generally for some sort of message to
> show up. Sometimes kills happen:
>
> My test environment has Mark Johnston patches to report
> things not normally reported:
>
> waited 9s for async swap write
> waited 9s for swap buffer
> waited 9s for async swap write
> waited 9s for async swap write
> waited 9s for async swap write
> v_free_count: 1357, v_inactive_count: 1
> Aug 20 06:04:27 pine64 kernel: pid 1010 (stress), uid 0, was killed: out
> of swap space
> waited 5s for async swap write
> waited 5s for swap buffer
> waited 5s for async swap write
> waited 5s for async swap write
> waited 5s for async swap write
> waited 13s for async swap write
> waited 12s for swap buffer
> waited 13s for async swap write
> waited 12s for async swap write
> waited 12s for async swap write
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 161177, size: 131072
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164766, size: 65536
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164064, size: 12288
> . . .
>
> (I made multiple runs, most manually stopped. None run for
> all that long.)
>
> (Warning: the swap space part of "killed: out of swap space"
> can be a misnomer. Killing is driven by having low free RAM
> for

soundcard.h expose device block size

[blubee blubeeme]

I'm looking at FreeBSD's soundcard.h and it doesn't seem to expose the
hardware block size, this seems like a limitation stemming from FreeBSD's
soundcard.h being an extension of OSS.

Since we've already implemented a lot of additional features on top of the
OSS API, is it possible to also expose the hardware block size for
applications that might need access to that information?

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: What's this gregset_t gregs thing

[blubee blubeeme]

On Mon, Aug 20, 2018 at 9:49 PM Shawn Webb 
wrote:

> On Mon, Aug 20, 2018 at 08:33:04AM +0800, blubee blubeeme wrote:
> > Linux has gregset_t gregs;
> >
> https://github.com/lattera/glibc/blob/master/sysdeps/unix/sysv/linux/x86/sys/ucontext.h
>
> Please note that that repo is hopelessly old and out-of-date. I
> created it as a mirror of the official glibc repo because I was doing
> some offensive research against GNU's RTLD way back in 2011-2012. The
> repo hasn't been updated since.
>
> Thanks,
>
> --
> Shawn Webb
> Cofounder and Security Engineer
> HardenedBSD
>
> Tor-ified Signal:+1 443-546-8752
> Tor+XMPP+OTR:latt...@is.a.hacker.sx
> GPG Key ID:  0x6A84658F52456EEE
> GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
>

Thanks for all the replies, I think OSX also lacks this gregs_t thing as
well I was able to lock it up behind some ifdefs and all is 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: building LLVM threads gets killed

[blubee blubeeme]

On Mon, Aug 20, 2018 at 10:26 PM Rodney W. Grimes <
freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:

> > On 20 Aug 2018, at 05:01, blubee blubeeme  wrote:
> > >
> > > I am running current compiling LLVM60 and when it comes to linking
> > > basically all the processes on my computer gets killed; Chrome,
> Firefox and
> > > some of the LLVM threads as well
> > ...
> > > llvm/build % ninja -j8
> > > [2408/2473] Building CXX object
> > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o
> > > FAILED: lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o
> > > /usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS
> > > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Passes
> -I../lib/Passes
> > > -Iinclude -I../include -isystem /usr/local/include -fPIC
> > > -fvisibility-inlines-hidden -Werror=date-time
> > > -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra
> > > -Wno-unused-parameter -Wwrite-strings -Wcast-qual
> > > -Wmissing-field-initializers -pedantic -Wno-long-long
> > > -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
> > > -Wstring-conversion -fdiagnostics-color -g-fno-exceptions
> -fno-rtti -MD
> > > -MT lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -MF
> > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o.d -o
> > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -c
> > > ../lib/Passes/PassBuilder.cpp
> > > c++: error: unable to execute command: Killed
> >
> > It is running out of RAM while running multiple parallel link jobs.  If
> > you are building using WITH_DEBUG, turn that off, it consumes large
> > amounts of memory.  If you must have debug info, try adding the
> > following flag to the CMake command line:
> >
> > -D LLVM_PARALLEL_LINK_JOBS:STRING="1"
> >
> > That will limit the amount of parallel link jobs to 1, even if you
> > specify -j 8 to gmake or ninja.
> >
> > Brooks, it would not be a bad idea to always use this CMake flag in the
> > llvm ports. :)
>
> And this may also fix the issues that all the small
> memory (aka, RPI*) buliders are facing when trying
> to do -j4?
>
>
> --
> Rod Grimes
> rgri...@freebsd.org


Someone mentioned earlier that debug builds cause a lot of memory usage and
it's true that I am building with debug.
I couldn't grab the relevant text from top but the posted was after
everything settled down.
The memory situation got so bad that xserver died and I was booted to
terminal.

I saw ld.lld using up to 12GB of ram for each process, that will definitely
use up 32GB of ram.

I can't avoid building w/ debug symbols since I have to debug the program
are there any other options other than
building with only 1 thread? Reason being even when I set gmake -j1 the
problem comes just a lot later during linking
stage.

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"

building LLVM threads gets killed

[blubee blubeeme]

I am running current compiling LLVM60 and when it comes to linking
basically all the processes on my computer gets killed; Chrome, Firefox and
some of the LLVM threads as well

I am using ninja which is a little better but gmake or make are a lot worse.

uname -a: FreeBSD blubee 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r336196: Wed
Jul 11 21:52:50 CST 2018
root@blubee:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64

me@blubee:~ % uname -K
1200072
me@blubee:~ % uname -U
1200072

building with -j1 still crashes and burns. Basically everything on my
machine gets killed. This machine has

sysctl hw.physmem
hw.physmem: 34246332416


last pid: 20965;  load averages:  0.64,  5.79,  7.73
 up 12+01:35:46  11:00:36
76 processes:  1 running, 75 sleeping
CPU:  0.8% user,  0.5% nice,  1.0% system,  0.0% interrupt, 98.1% idle
Mem: 10G Active, 3G Inact, 100M Laundry, 13G Wired, 6G Free
ARC: 4G Total, 942M MFU, 1G MRU, 1M Anon, 43M Header, 2G Other
 630M Compressed, 2G Uncompressed, 2.74:1 Ratio
Swap: 2G Total, 1G Used, 739M Free, 63% Inuse


llvm/build % ninja -j8
[2408/2473] Building CXX object
lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o
FAILED: lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o
/usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Passes -I../lib/Passes
-Iinclude -I../include -isystem /usr/local/include -fPIC
-fvisibility-inlines-hidden -Werror=date-time
-Werror=unguarded-availability-new -std=c++11 -Wall -Wextra
-Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wmissing-field-initializers -pedantic -Wno-long-long
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
-Wstring-conversion -fdiagnostics-color -g-fno-exceptions -fno-rtti -MD
-MT lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -MF
lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o.d -o
lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -c
../lib/Passes/PassBuilder.cpp
c++: error: unable to execute command: Killed
c++: error: clang frontend command failed due to signal (use -v to see
invocation)
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM
6.0.1)
Target: x86_64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin
c++: note: diagnostic msg: PLEASE submit a bug report to
https://bugs.freebsd.org/submit/ and include the crash backtrace,
preprocessed source, and associated run script.
c++: note: diagnostic msg:


PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
c++: note: diagnostic msg: /tmp/PassBuilder-1bff7b.cpp
c++: note: diagnostic msg: /tmp/PassBuilder-1bff7b.sh
c++: note: diagnostic msg:



---

llvm/build % ninja -j8
[54/59] Linking CXX executable bin/opt
FAILED: bin/opt
: && /usr/bin/c++  -fPIC -fvisibility-inlines-hidden -Werror=date-time
-Werror=unguarded-availability-new -std=c++11 -Wall -Wextra
-Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wmissing-field-initializers -pedantic -Wno-long-long
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
-Wstring-conversion -fdiagnostics-color -g  -Wl,--color-diagnostics
-Wl,-allow-shlib-undefined   -Wl,--export-dynamic  -Wl,-z,origin
tools/opt/CMakeFiles/opt.dir/AnalysisWrappers.cpp.o
tools/opt/CMakeFiles/opt.dir/BreakpointPrinter.cpp.o
tools/opt/CMakeFiles/opt.dir/Debugify.cpp.o
tools/opt/CMakeFiles/opt.dir/GraphPrinters.cpp.o
tools/opt/CMakeFiles/opt.dir/NewPMDriver.cpp.o
tools/opt/CMakeFiles/opt.dir/PassPrinters.cpp.o
tools/opt/CMakeFiles/opt.dir/PrintSCC.cpp.o
tools/opt/CMakeFiles/opt.dir/opt.cpp.o  -o bin/opt -L/usr/local/lib
-Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMAArch64CodeGen.a
lib/libLLVMAArch64AsmParser.a lib/libLLVMAArch64AsmPrinter.a
lib/libLLVMAArch64Desc.a lib/libLLVMAArch64Disassembler.a
lib/libLLVMAArch64Info.a lib/libLLVMAArch64Utils.a
lib/libLLVMAMDGPUCodeGen.a lib/libLLVMAMDGPUAsmParser.a
lib/libLLVMAMDGPUAsmPrinter.a lib/libLLVMAMDGPUDesc.a
lib/libLLVMAMDGPUDisassembler.a lib/libLLVMAMDGPUInfo.a
lib/libLLVMAMDGPUUtils.a lib/libLLVMARMCodeGen.a lib/libLLVMARMAsmParser.a
lib/libLLVMARMAsmPrinter.a lib/libLLVMARMDesc.a
lib/libLLVMARMDisassembler.a lib/libLLVMARMInfo.a lib/libLLVMARMUtils.a
lib/libLLVMBPFCodeGen.a lib/libLLVMBPFAsmParser.a
lib/libLLVMBPFAsmPrinter.a lib/libLLVMBPFDesc.a
lib/libLLVMBPFDisassembler.a lib/libLLVMBPFInfo.a
lib/libLLVMHexagonCodeGen.a lib/libLLVMHexagonAsmParser.a
lib/libLLVMHexagonDesc.a lib/libLLVMHexagonDisassembler.a
lib/libLLVMHexagonInfo.a lib/libLLVMLanaiCodeGen.a
lib/libLLVMLanaiAsmParser.a lib/libLLVMLanaiAsmPrinter.a
lib/libLLVMLanaiDesc.a lib/libLLVMLanaiDisassembler.a
lib/libLLVMLanaiInfo.a lib/libLLVMMipsCodeGen.a lib/libLLVMMipsAsmParser.a
lib/libLLVMMipsAsmPrinter.a lib/libLLVMMipsDesc.a
lib/libLLVMMipsDisassembler.a lib/libLLVMMipsInfo.a
lib/libLLVMMSP430CodeGen.a lib/libLLVMMSP430AsmPrinter.a

What's this gregset_t gregs thing

[blubee blubeeme]

Linux has gregset_t gregs;
https://github.com/lattera/glibc/blob/master/sysdeps/unix/sysv/linux/x86/sys/ucontext.h

Defined above, I also see it in the RISC-V glibc stuff as well.

FreeBSD doesn't seem to have this field defined, I see FreeBSD uses
/usr/include/x86/ucontext.h

but there's no gregs;

If I wanted to return mcontext.gregs

How could I implement that on FreeBSD?

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: Sharing compiled builds between multiple 12-CURRENT boxes.

[blubee blubeeme]

On Sun, Aug 19, 2018 at 6:30 PM O. Hartmann  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am Sun, 19 Aug 2018 00:34:20 +0200
> Dhananjay Balan  schrieb:
>
> > Hi,
> >
> > I run 12-CURRENT on few machines, some more powerful that other (all
> > of them x86_64, march varies).
> >
> > Is there is a way to avoid building CURRENT on all machines? Rather
> > than building everywhere, can I just build it on the big server that I
> > have and copy and update my laptop?
> >
> > -
> > Dhananjay Balan
> [...]
>
> Yes, you can.
> We do this via a custom build and creating packages as this is introduced
> at
>
> https://wiki.freebsd.org/PkgBase
>
> But beware! As many others have already stated, take care about to use the
> least common
> denominator of achitectural specifications amongst your pools! This means
> to not use any
> kind of optimizations for a specific CPU type for pkg-base distributed
> builds!
>
> Because we build the local OS for fast/server machines always(!) with
> optimisations, the
> pkg-base builds are done in a separate way - which is very easy if you've
> once understood
> the really neat and great build framework of FreeBSD's!
>
> Instead of building the traditional (probably optimised) system from
> /usr/src
> and /usr/obj, now you've to consider a separate path like
> /pool/sources/CURRENT/src (our
> way, since we also try to build packages and object trees for 11.X), then
> setup a small
> build script that essentially sets
>
> MAKEOBJDIRPREFIX
> KERNCONFDIR
> KERNCONF
>
> and especially
>
> __MAKE_CONF
> SRCCONF
> SRC_ENV_CONF
>
> if you use usually optimisations for the native target build on the
> building host and
> more generic binaries for the Intel x86 crap for redistribution.
>
> Doing so, we also perform builds for some ARM64 based experimental boxes.
>
> The next step is then up to you how to distribute. We copy all the pkg
> stuff coming out
> of the build cycle to a folder which is accessible by pkg via HTTP(S) - so
> www/apache24
> is our platform to redistribute the binaries over the network and even to
> remote sites
> (beware of the security implications!). You also can distribute the
> obj-folder (/usr/obj,
> or, if using another approach, like /pool/sources/CURRENT/obj) via NFS.
>
> Once you've understood the (easy to learn) concept of building the source
> tree, creating
> the packages for pkg-base and having dealt with the more labor for the
> setting of a
> distribution server, you can use the most potent server/box on you network
> for building
> dedicated distributions
>
> Even a "Release" build is possible as long as there are not pitfalls like
> they occured
> during the transition from 11.X to more 12-CURRENT spcific development
> (i.e. LINT).
>
> If you use pkg-base as mentioned above, be aware to setup a proper
> pkg.conf file as
> introduced on the Wiki and please be also aware of the fact, that there is
> at the moment
> no sharp separation between pkg-base and oridnary pkg for packages - so
> take the
> warinig serious, that pkg delete -a will not only kill all packages, it
> also will kill
> all packages installed for the base system!
>
> Once installed you'll see how fast compared to source build the pkg-base
> installation
> is (although I still prefer source build, optimised builds ...).
>
> And by the way: depending on the sophistication of your build script for
> dedicated
> tree builds as mentioned, via manipulations of __MAKE_CONF, SRCCONF you're
> able to also
> build optimised binary trees for different CPU types, but you have to deal
> yourself
> with the fact that you've to put the binaries into a proper place and then
> delegate the
> URI in pkg.conf to the correct branch of your tree. The ABI environmental
> variable
> doesn't take care of the "set" you may have used to optimise. But this is
> something
> you're able to deal with easily yourself after having setup your basic
> build
> environment.
>
> Regards,
>
> oh
>
> - --
> O. Hartmann
>
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
> -BEGIN PGP SIGNATURE-
>
> iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW3lGDwAKCRDS528fyFhY
> lMBeAf4nVIFEAgegbZyKDZvTQQD/9Q8mN+IY8aJ7Fzza23KgWQsM3ZP59Orh0mi2
> PA94ywn5hOjfTgzdYcp1lq3MCE84AgCBGAWAMTag87ru89JHm75NLsgDvEjPpYgG
> 9hW1Vrdoj9EeiR2HTv2ncTc/AkFPNhdyhe+EJqUg01rtAd9sdmdM
> =/rzO
> -END PGP SIGNATURE-
> ___
> freebsd-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 would say setup a poudriere build bot on your most powerful machine to
build and test all the applications and tools that your weaker machines
need, then setup a custom pkg repo so once poudriere builds all the ports
and create packages from them.

Then you use the custom pkg url to update your 

Executables with [ -def __linux__ ]

[blubee blubeeme]

This is going out to both current and ports in hopes someone can offer some
guidance on this issue.

I'm porting some code that seems to want to have -def __linux__ when I run
the executable with verbose output, take a look below

--
 -opt 0 -terse 1 -inform warn -nohpf -nostatic -inform warn -x 19 0x40
-quad -x 68 0x1 -x 59 4 -x 15 2 -x 49 0x44 -x 51 0x20 -x 57 0x4c -x 58
0x1 -x 124 0x1000 -tp px -x 57 0xfb -x 58 0x78031040 -x 47 0x08 -x
48 4608 -x 49 0x100 -def unix -def __unix -def __unix__ -def linux -def
__linux -def __linux__ -def __NO_MATH_INLINES -def __LP64__ -def __x86_64
-def __x86_64__ -def __LONG_MAX__=9223372036854775807L -def
__SIZE_TYPE__=unsigned long int -def __PTRDIFF_TYPE__=long int -def
__THROW= -def __extension__= -def __amd_64__amd64__ -def __k8 -def __k8__
-def __PGLLVM__ -freeform -vect 48 -y 54 1 -x 70 0x4000 -y 163
0xc000 -x 189 0x10 -stbfile test-276576.stb -modexport test-276576.cmod
-modindex test-276576.cmdx -output test-276576.ilm


As you can see from above there's some -def linux, def __linux, etc..

FreeBSD isn't Linux and I'd like to better understand where these things
are being set, it's a cmake project and I've grepped through a lot of the
sources and can't really find where these flags are coming from.

Any tips on finding where they are coming from and fixing them to reflect
the correct platform information?

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: FreeBSD elf_machine_id

[blubee blubeeme]

On Sun, Aug 12, 2018 at 9:59 PM blubee blubeeme  wrote:

>
>
> On Sun, Aug 12, 2018 at 7:43 PM Dimitry Andric  wrote:
>
>> On 12 Aug 2018, at 13:21, blubee blubeeme  wrote:
>> >
>> > What's the elf_machine_id for FreeBSD amd64 systems?
>> >
>> > How can I find this info?
>>
>> There isn't any FreeBSD-specific machine ID, just a machine ID for
>> x86-64 (aka amd64) in general:
>>
>> $ grep x86-64 /usr/include/sys/elf_common.h
>> #define EM_X86_64   62  /* Advanced Micro Devices x86-64 */
>> #define EM_AMD64EM_X86_64   /* Advanced Micro Devices x86-64
>> (compat) */
>>
>> -Dimitry
>>
>> Thank you for the clarification.
>
> I think in this case I was looking for 62.
>
> Best,
> Owen
>
Actually I had another quick question along these lines.

if x86_64 is already defined should I bother changing those to amd64 or
just use x86_64 and make FreeBSD modifications where Linux specifics are
defined?

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: FreeBSD elf_machine_id

[blubee blubeeme]

On Sun, Aug 12, 2018 at 7:43 PM Dimitry Andric  wrote:

> On 12 Aug 2018, at 13:21, blubee blubeeme  wrote:
> >
> > What's the elf_machine_id for FreeBSD amd64 systems?
> >
> > How can I find this info?
>
> There isn't any FreeBSD-specific machine ID, just a machine ID for
> x86-64 (aka amd64) in general:
>
> $ grep x86-64 /usr/include/sys/elf_common.h
> #define EM_X86_64   62  /* Advanced Micro Devices x86-64 */
> #define EM_AMD64EM_X86_64   /* Advanced Micro Devices x86-64
> (compat) */
>
> -Dimitry
>
> Thank you for the clarification.

I think in this case I was looking for 62.

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 elf_machine_id

[blubee blubeeme]

What's the elf_machine_id for FreeBSD amd64 systems?

How can I find this info?

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: #includes and #defined

[blubee blubeeme]

On Fri, Aug 10, 2018 at 9:53 PM Warner Losh  wrote:

>
>
> On Thu, Aug 9, 2018 at 11:51 PM, Erich Dollansky <
> freebsd.ed.li...@sumeritec.com> wrote:
>
>> Hi,
>>
>> On Fri, 10 Aug 2018 12:40:48 +0800
>> blubee blubeeme  wrote:
>>
>> > On Fri, Aug 10, 2018 at 8:28 AM Erich Dollansky <
>> > freebsd.ed.li...@sumeritec.com> wrote:
>> >
>> > > Hi,
>> > >
>> > > On Fri, 10 Aug 2018 08:01:42 +0800
>> > > blubee blubeeme  wrote:
>> > >
>> > > > What's the proper way to define and include FreeBSD amd64 in GNU
>> > > > Makefiles
>> > > >
>> > > > Do we define FreeBSD as x86_64 or amd64 also is it __FreeBSD__,
>> > > > FreeBSD__, or __FreeBSD
>> > > >
>> > > > I've seen all of the above looking through different projects.
>> > >
>> > > clang defines '__FreeBSD__'
>> > >
>> > > Erich
>> > >
>> >
>> > What about the architecture name is it recommended to use x86_64 or
>> > amd64?
>>
>> my clang reports on an Intel CPU:
>>
>> #define __amd64 1
>> #define __amd64__ 1
>> #define __x86_64 1
>> #define __x86_64__ 1
>>
>> as defined.
>>
>> It reports
>>
>> #define __aarch64__ 1
>>
>> on an 64 bit ARM CPU.
>>
>
> 'man 7 arch' will tell you these things:
>
>amd64  __amd64__, __x86_64__
>
This is what I was looking for, thank you for the man page and it's good to
see that these things are starting to get documented.

>
> it contains the preferred list of macros to use. Ideally, you'd use the
> first one listed, though all the ones listed are supported. Others might
> not be.
>
> Warner
>

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: #includes and #defined

[blubee blubeeme]

On Fri, Aug 10, 2018 at 8:28 AM Erich Dollansky <
freebsd.ed.li...@sumeritec.com> wrote:

> Hi,
>
> On Fri, 10 Aug 2018 08:01:42 +0800
> blubee blubeeme  wrote:
>
> > What's the proper way to define and include FreeBSD amd64 in GNU
> > Makefiles
> >
> > Do we define FreeBSD as x86_64 or amd64 also is it __FreeBSD__,
> > FreeBSD__, or __FreeBSD
> >
> > I've seen all of the above looking through different projects.
>
> clang defines '__FreeBSD__'
>
> Erich
>

What about the architecture name is it recommended to use x86_64 or amd64?

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"

#includes and #defined

[blubee blubeeme]

What's the proper way to define and include FreeBSD amd64 in GNU Makefiles

Do we define FreeBSD as x86_64 or amd64 also is it __FreeBSD__, FreeBSD__,
or __FreeBSD

I've seen all of the above looking through different projects.

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"

SVN down or slow

[blubee blubeeme]

Has anyone else noticed that svn is getting this type of error trying to
run svn: svn: E65: Error running context: No route to host
___
freebsd-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: automake-wrapper conflicts

[blubee blubeeme]

On Sat, Jul 28, 2018 at 10:41 AM blubee blubeeme 
wrote:

> I am getting some build errors around automake-wrapper.
>
> I tried deinstalling automake-wrapper and then installing automake but
> then during the installation of automake I get this error:
>
> install-info: warning: no info dir entry in
> `/usr/ports/devel/automake/work/stage/usr/local/info/automake-history.info
> '
>  /bin/mkdir -p '/usr/ports/devel/automake/work/stage/usr/local/man/man1'
>  install  -m 0644 doc/aclocal.1 doc/automake.1 doc/aclocal-1.16.1
> doc/automake-1.16.1
> '/usr/ports/devel/automake/work/stage/usr/local/man/man1'
>  /bin/mkdir -p
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/Automake'
>  install  -m 0644 lib/Automake/Config.pm
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/Automake'
> /usr/bin/make  install-data-hook
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.guess'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.sub'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/install-sh'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mdate-sh'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/missing'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mkinstalldirs'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ylwrap'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/depcomp'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/compile'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/py-compile'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ar-lib'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/test-driver'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/tap-driver.sh'
> find: /usr/ports/devel/automake/work/stage/usr/local/lib/perl5/site_perl:
> No such file or directory
> > Compressing man pages (compress-man)
> ===>  Installing for automake-1.16.1
> ===>  Checking if automake already installed
> ===>   Registering installation for automake-1.16.1
> Installing automake-1.16.1...
> pkg-static: automake-1.16.1 conflicts with automake-wrapper-20131203
> (installs files into the same place).  Problematic file:
> /usr/local/bin/aclocal
> *** Error code 70
>
>
> Is this just me or a bug?
>
> Best,
> Owen
>

Okay, seems that UPDATING addresses this issue!

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"

automake-wrapper conflicts

[blubee blubeeme]

I am getting some build errors around automake-wrapper.

I tried deinstalling automake-wrapper and then installing automake but then
during the installation of automake I get this error:

install-info: warning: no info dir entry in
`/usr/ports/devel/automake/work/stage/usr/local/info/automake-history.info'
 /bin/mkdir -p '/usr/ports/devel/automake/work/stage/usr/local/man/man1'
 install  -m 0644 doc/aclocal.1 doc/automake.1 doc/aclocal-1.16.1
doc/automake-1.16.1
'/usr/ports/devel/automake/work/stage/usr/local/man/man1'
 /bin/mkdir -p
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/Automake'
 install  -m 0644 lib/Automake/Config.pm
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/Automake'
/usr/bin/make  install-data-hook
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.guess'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.sub'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/install-sh'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mdate-sh'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/missing'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mkinstalldirs'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ylwrap'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/depcomp'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/compile'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/py-compile'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ar-lib'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/test-driver'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/tap-driver.sh'
find: /usr/ports/devel/automake/work/stage/usr/local/lib/perl5/site_perl:
No such file or directory
> Compressing man pages (compress-man)
===>  Installing for automake-1.16.1
===>  Checking if automake already installed
===>   Registering installation for automake-1.16.1
Installing automake-1.16.1...
pkg-static: automake-1.16.1 conflicts with automake-wrapper-20131203
(installs files into the same place).  Problematic file:
/usr/local/bin/aclocal
*** Error code 70


Is this just me or a bug?

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"

Make buildworld fails

[blubee blubeeme]

Why am I getting these errors?

error: user-defined literal suffixes not starting with '_' are reserved
[-Werror,-Wuser-defined-literals]

--
In file included from /usr/src/usr.sbin/pmc/cmd_pmc_filter.cc:71:
In file included from
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:477:
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string_view:796:29:
error: user-defined literal suffixes not starting with '_' are reserved
[-Werror,-Wuser-defined-literals]
basic_string_view operator "" sv(const char *__str, size_t __len)
_NOEXCEPT
^
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string_view:802:32:
error: user-defined literal suffixes not starting with '_' are reserved
[-Werror,-Wuser-defined-literals]
basic_string_view operator "" sv(const wchar_t *__str, size_t
__len) _NOEXCEPT
   ^
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string_view:808:33:
error: user-defined literal suffixes not starting with '_' are reserved
[-Werror,-Wuser-defined-literals]
basic_string_view operator "" sv(const char16_t *__str,
size_t __len) _NOEXCEPT
^
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string_view:814:33:
error: user-defined literal suffixes not starting with '_' are reserved
[-Werror,-Wuser-defined-literals]
basic_string_view operator "" sv(const char32_t *__str,
size_t __len) _NOEXCEPT
^
In file included from /usr/src/usr.sbin/pmc/cmd_pmc_filter.cc:71:
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:4046:24: error:
user-defined literal suffixes not starting with '_' are reserved
[-Werror,-Wuser-defined-literals]
basic_string operator "" s( const char *__str, size_t __len )
   ^
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:4052:27: error:
user-defined literal suffixes not starting with '_' are reserved
[-Werror,-Wuser-defined-literals]
basic_string operator "" s( const wchar_t *__str, size_t __len
)
  ^
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:4058:28: error:
user-defined literal suffixes not starting with '_' are reserved
[-Werror,-Wuser-defined-literals]
basic_string operator "" s( const char16_t *__str, size_t
__len )
   ^
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:4064:28: error:
user-defined literal suffixes not starting with '_' are reserved
[-Werror,-Wuser-defined-literals]
basic_string operator "" s( const char32_t *__str, size_t
__len )
   ^
8 errors generated.
*** 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: RiscV tinderbox fails

[blubee blubeeme]

It seems to be that the FreeBSD implementation of the RISC-V has stalled
and development is only proceeding on Linux with GCC.

In my opinion FreeBSD forget GCC and work on implementing RISC-V backend
for the llvm project.



On Sat, Jun 30, 2018, 08:18 Dimitry Andric  wrote:

> On 29 Jun 2018, at 13:33, hartmut.bra...@dlr.de wrote:
> >
> > is it supposed not to fail? I get:
> >
> > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In
> function
> > `__gedf2':
> > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:101: multiple
> definition
> > of `__gedf2'
> >
> /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(gedf2.o):/usr/src/lib/libc/s
> > oftfloat/gedf2.c:18: first defined here
> > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In
> function
> > `__eqdf2':
> > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:127: multiple
> definition
> > of `__eqdf2'
> >
> /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(eqdf2.o):/usr/src/lib/libc/s
> > oftfloat/eqdf2.c:18: first defined here
> > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In
> function
> > `__ltdf2':
> > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:127: multiple
> definition
> > of `__ltdf2'
> >
> /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(ltdf2.o):/usr/src/lib/libc/s
> > oftfloat/ltdf2.c:18: first defined here
> > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In
> function
> > `__nedf2':
> > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:127: multiple
> definition
> > of `__nedf2'
> >
> /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(nedf2.o):/usr/src/lib/libc/s
> > oftfloat/nedf2.c:18: first defined here
> > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In
> function
> > `__gtdf2':
> > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:142: multiple
> definition
> > of `__gtdf2'
> >
> /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(gtdf2.o):/usr/src/lib/libc/s
> > oftfloat/gtdf2.c:18: first defined here
> > collect2: error: ld returned 1 exit status
> > *** [nologin.full] Error code 1
>
> As far as I know, it has been broken for quite some time.  I guess for
> riscv those functions need to be defined either in libc, or in
> compiler-rt, but not both...
>
> -Dimitry
>
>
___
freebsd-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: Proper way to remove never used ioctls

[blubee blubeeme]

On Sun, Jun 3, 2018, 02:34 Vladimir Kondratyev 
wrote:

> On 2018-06-02 20:36, Allan Jude wrote:
> > On 2018-06-02 11:03, Warner Losh wrote:
> >> On Sat, Jun 2, 2018 at 7:33 AM, Vladimir Kondratyev
> >> 
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> Our sys/mouse.h header has a definition of MOUSE_GETVARS and
> >>> MOUSE_SETVARS
> >>> ioctls which are not documented and only stubbed in a few drivers:
> >>> mse(4),
> >>> psm(4) and syscon's sysmouse(4). The only exception is MOUSE_GETVARS
> >>> implemented in psm(4)
> >>>
> >>> Given the fact that they were introduced 20 years ago, implementation
> >>> was
> >>> never completed and googling on them shows no traces of usage in
> >>> indexed
> >>> universe, is it acceptable to just drop both defines and
> >>> implementation
> >>> w.o. leaving any COMPAT_FREEBSD shims?
> >>
> >>
> >> I'd prepare a patch just removing them. I'd then send that patch to
> >> the
> >> ports mgr team and request a exp-run. Details for that can be found in
> >>
> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/ports.html
> >>
> >> Once that's done, submit a Phabricator review and send me email. I'll
> >> make
> >> sure it gets pushed in if there's no objections.
> >>
> >> Warner
> >
> > This indeed seems to be the correct approach. The exp-run will compile
> > the entire ports tree against the patched base system, and identify any
> > 3rd party software that fails to compile because of the change.
>
> Thank you, Allan and Warner! I'll follow yours advice.
>
> --
> WBR
> Vladimir Kondratyev
> ___
> freebsd-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 was great information.

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

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

[blubee blubeeme]

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

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

Agreed

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

OSS loopback device

[blubee blubeeme]

Cross post; FreeBSD-[questions | current | ultimedia]

Where's the midi loopback device in the FreeBSD OSS implementation?

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: Fatal trap 12

[blubee blubeeme]

On Sat, May 26, 2018, 19:52 Manuel Stühn  wrote:

> Since upgrading my Lenovo T450 from r333740 to r334167 I'm experiencing
> several "Fatal traps 12". Before the update i did not have any of those.
> In all cases the traps occured some time after resume.
>
> Below there is some output found in /var/crash/core.txt
>
> __curthread () at ./machine/pcpu.h:231
> 231 ./machine/pcpu.h: No such file or directory.
> (kgdb) #0  __curthread () at ./machine/pcpu.h:231
> #1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:366
> #2  0x80b9a6f0 in kern_reboot (howto=260)
> at /usr/src/sys/kern/kern_shutdown.c:446
> #3  0x80b9ab83 in vpanic (fmt=,
> ap=0xfe0056507e50)
> at /usr/src/sys/kern/kern_shutdown.c:863
> #4  0x80b9a973 in panic (fmt=)
> at /usr/src/sys/kern/kern_shutdown.c:790
> #5  0x80ba5c3b in kdb_switch () at
> /usr/src/sys/kern/kern_synch.c:377
> #6  0x80ba5bb9 in mi_switch (flags=, newtd=0x0)
> at /usr/src/sys/kern/kern_synch.c:406
> #7  0x80bf3f5f in sleepq_timedwait (wchan=,
> pri=) at /usr/src/sys/kern/subr_sleepqueue.c:727
> #8  0x833c7bed in linux_add_to_sleepqueue
> (wchan=0xf8000bf6ad80, task=0xf8000bf6ad80, wmesg= out>, timeout=50, state=)
> at /usr/src/sys/compat/linuxkpi/common/src/linux_schedule.c:70
> #9  0x833c7a58 in linux_wait_event_common (wqh=,
> wq=, timeout=50, state=2, lock=0x0)
> at /usr/src/sys/compat/linuxkpi/common/src/linux_schedule.c:270
> #10 0x83458de6 in ?? ()
> #11 0x00061d026200 in ?? ()
> #12 0x0006 in ?? ()
> #13 0xf8000bf6ad80 in ?? ()
> #14 0x833c7540 in ?? ()
> at /usr/src/sys/compat/linuxkpi/common/src/linux_schedule.c:167
>from /boot/kernel/linuxkpi.ko
> #15 0xf80007804828 in ?? ()
> #16 0xf80007804828 in ?? ()
> #17 0x0030 in ?? ()
> #18 0x in ?? ()
> (kgdb)
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 3; apic id = 03
> fault virtual address   = 0x3
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x80cc60cb
> stack pointer   = 0x28:0xfe0056508560
> frame pointer   = 0x28:0xfe0056508760
> 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 = 10218 (nextcloud)
> --
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address   = 0x30011
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x80cc60cb
> stack pointer   = 0x28:0xfe005e4d1560
> frame pointer   = 0x28:0xfe005e4d1760
> 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 = 17918 (DNS Resolver #16)
> --
> Fatal trap 12: page fault while in kernel mode
> cpuid = 3; apic id = 03
> fault virtual address   = 0x3
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x80cc60cb
> stack pointer   = 0x28:0xfe0056508560
> frame pointer   = 0x28:0xfe0056508760
> 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 = 10218 (nextcloud)
>
> If there is any other information i can provide for solving this, please
> let me know.
>
> --
> Manuel
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
Aren't you the guy using the drm-kmod if yes, your custom complied kernel
and not the default kernel causing those issues.

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: Periodical interrupt storm when playing game with USB keyboard

[blubee blubeeme]

78
>   kernel`bcopy 90
>   i915kms.ko`fw_domains_get   228
>   kernel`spinlock_exit284
>   kernel`cpu_idle4698
>   kernel`acpi_cpu_idle      36288
>
>
> I also tried rebuilding linux-c6_sdl-1.2 using get time functions in librt
> vs libc but no difference.
> Will dig deeper next time I have free time to spare.
>
>
>
> On Tue, Jan 23, 2018 at 2:33 AM, blubee blubeeme <gurenc...@gmail.com>
> wrote:
>
>>
>>
>> On Tue, Jan 23, 2018 at 9:48 AM, Adrian Chadd <adrian.ch...@gmail.com>
>> wrote:
>>
>>> Hi
>>>
>>> Yeah the timers eventually get coalesced unless someone's asking for a
>>> ridciulously accurate timer value.
>>>
>>> So is some driver asking for hyper-accurate callout timer that isn't
>>> being coalesced? hps, is there any useful debugging to try and find
>>> callouts that are requesting stupidly accurate timers? Maybe a dtrace
>>> probe on the callout schedule entry point?
>>>
>>>
>>>
>>> -adrian
>>> ___
>>> 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'd say dtrace might be able to get you in the right direction very
>> quickly.
>>
>> I used SDL in the past for android apps and the code is very Linux
>> specific. I am sure there's some Linux related timers in there somewhere
>> that FreeBSD is returning nothing from and that's what's killing the
>> performance.
>>
>> I can almost guarantee that none of the SDL designers and or programmers
>> use any *BSD systems.
>>
>> The easiest solution would be to go look at the timer code and implement
>> something that FreeBSD can work with and try to get that upstream.
>>
>> These are just a few of the issues that will crop up when devs try to
>> just use shims to hook into the Linux kernel. Do the design work up front
>> and implement things in a native way or enjoy the jank.
>>
>> DTrace should be able to point you in the right direction relatively
>> quickly.
>> The DTraceBook: https://www.amazon.com/DTrace-Dynamic-Tracing-
>> Solaris-FreeBSD/dp/0132091518
>>
>> 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: Periodical interrupt storm when playing game with USB keyboard

[blubee blubeeme]

On Tue, Jan 23, 2018 at 9:48 AM, Adrian Chadd 
wrote:

> Hi
>
> Yeah the timers eventually get coalesced unless someone's asking for a
> ridciulously accurate timer value.
>
> So is some driver asking for hyper-accurate callout timer that isn't
> being coalesced? hps, is there any useful debugging to try and find
> callouts that are requesting stupidly accurate timers? Maybe a dtrace
> probe on the callout schedule entry point?
>
>
>
> -adrian
> ___
> freebsd-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 say dtrace might be able to get you in the right direction very quickly.

I used SDL in the past for android apps and the code is very Linux
specific. I am sure there's some Linux related timers in there somewhere
that FreeBSD is returning nothing from and that's what's killing the
performance.

I can almost guarantee that none of the SDL designers and or programmers
use any *BSD systems.

The easiest solution would be to go look at the timer code and implement
something that FreeBSD can work with and try to get that upstream.

These are just a few of the issues that will crop up when devs try to just
use shims to hook into the Linux kernel. Do the design work up front and
implement things in a native way or enjoy the jank.

DTrace should be able to point you in the right direction relatively
quickly.
The DTraceBook:
https://www.amazon.com/DTrace-Dynamic-Tracing-Solaris-FreeBSD/dp/0132091518

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: msdosfs_iconv

[blubee blubeeme]

On Sun, Jan 14, 2018 at 1:39 PM, Henry Hu <henry.hu...@gmail.com> wrote:

>
>
> On Sun, Jan 14, 2018 at 12:20 AM, blubee blubeeme <gurenc...@gmail.com>
> wrote:
>
>>
>>
>> On Sun, Jan 14, 2018 at 12:16 PM, Henry Hu <henry.hu...@gmail.com> wrote:
>>
>>>
>>>
>>> On Sat, Jan 13, 2018 at 10:56 PM, blubee blubeeme <gurenc...@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sun, Jan 14, 2018 at 11:53 AM, Henry Hu <henry.hu...@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sat, Jan 13, 2018 at 9:10 PM, blubee blubeeme <gurenc...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> This is a repost from freebsd-question; Hoping to get more exposure
>>>>>> and
>>>>>> help here.
>>>>>>
>>>>>> I am trying to run mount_msdosfs with the option to set locale like
>>>>>> this:
>>>>>> mount_msdosfs -L en_US.UTF-8 /dev/da0s1 $HOME/usb
>>>>>>
>>>>>> This returns operation not permitted.
>>>>>>
>>>>>> usrmount is set to 1 and everything mounts as expected w/o root if I
>>>>>> remove
>>>>>> the locale option. The problem here is that my document filenames are
>>>>>> garbled and I can't actually open the files.
>>>>>>
>>>>>> kiconvtool: https://wiki.freebsd.org/DmitryMarakasov/kiconvtool
>>>>>> is said to work but it does not, after installing it I still get the
>>>>>> exact
>>>>>> same error.
>>>>>>
>>>>>> Have you tried to kldload msdosfs_iconv first?
>>>>>
>>>>> Is there a way to set locale when using mount_msdosfs without sudo?
>>>>>> ___
>>>>>> 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"
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Henry
>>>>>
>>>> Yes, /etc/rc.conf has this line:
>>>> kld_list="nvidia-modeset msdosfs_iconv"
>>>>
>>>>
>>> I just tried that and it works. I can create filenames in Chinese on the
>>> mounted drive.
>>> The command I used:
>>>
>>> > mount_msdosfs -L zh_CN.UTF-8 /dev/da1p1 /tmp/y
>>>
>>> kernel modules:
>>>
>>> > kldstat | grep iconv
>>> 303 0x8506e000 458f libiconv.ko
>>> 331 0x8507a000 801  msdosfs_iconv.ko
>>>
>>> But I'm using 11.1-STABLE.  Maybe something changed?
>>>
>>> --
>>> Cheers,
>>> Henry
>>>
>> I am running:
>>  FreeBSD blubee 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r326056: Tue Nov 21
>> 14:54:55 UTC 2017 r...@releng3.nyi.freebsd.org:
>> /usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
>>
>> kldstats
>> 101 0x85e89000 806  msdosfs_iconv.ko
>> 111 0x85e8a000 4633 libiconv.ko
>>
>> Can you list out the steps that you followed?
>>
>> I know that if I first run the mount command as root; I can then mount
>> and unmount as regular user.
>>
>> If I try to mount with that -L flag
>> msdosfs_iconv complains at me.
>>
>
> I just inserted a USB drive, and created /tmp/y for testing, which is
> owned by my user. I can access /dev/da1p1 as my user.
>
> Do you mean that if you have mounted & unmounted as root once, you can
> mount as regular user?
> Maybe that changes something, like loaded a kernel module? Maybe you can
> compare kldstat output?
>
> --
> Cheers,
> Henry
>
if you first run the mount_msdosfs command as root, it'll load the locale
settings just fine.
If you logout or reboot and try to call mount_msdosfs -L [locale] as a
regular user;

The command will fail.
___
freebsd-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: msdosfs_iconv

[blubee blubeeme]

On Sun, Jan 14, 2018 at 12:16 PM, Henry Hu <henry.hu...@gmail.com> wrote:

>
>
> On Sat, Jan 13, 2018 at 10:56 PM, blubee blubeeme <gurenc...@gmail.com>
> wrote:
>
>>
>>
>> On Sun, Jan 14, 2018 at 11:53 AM, Henry Hu <henry.hu...@gmail.com> wrote:
>>
>>>
>>>
>>> On Sat, Jan 13, 2018 at 9:10 PM, blubee blubeeme <gurenc...@gmail.com>
>>> wrote:
>>>
>>>> This is a repost from freebsd-question; Hoping to get more exposure and
>>>> help here.
>>>>
>>>> I am trying to run mount_msdosfs with the option to set locale like
>>>> this:
>>>> mount_msdosfs -L en_US.UTF-8 /dev/da0s1 $HOME/usb
>>>>
>>>> This returns operation not permitted.
>>>>
>>>> usrmount is set to 1 and everything mounts as expected w/o root if I
>>>> remove
>>>> the locale option. The problem here is that my document filenames are
>>>> garbled and I can't actually open the files.
>>>>
>>>> kiconvtool: https://wiki.freebsd.org/DmitryMarakasov/kiconvtool
>>>> is said to work but it does not, after installing it I still get the
>>>> exact
>>>> same error.
>>>>
>>>> Have you tried to kldload msdosfs_iconv first?
>>>
>>> Is there a way to set locale when using mount_msdosfs without sudo?
>>>> ___
>>>> 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"
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Henry
>>>
>> Yes, /etc/rc.conf has this line:
>> kld_list="nvidia-modeset msdosfs_iconv"
>>
>>
> I just tried that and it works. I can create filenames in Chinese on the
> mounted drive.
> The command I used:
>
> > mount_msdosfs -L zh_CN.UTF-8 /dev/da1p1 /tmp/y
>
> kernel modules:
>
> > kldstat | grep iconv
> 303 0x8506e000 458f libiconv.ko
> 331 0x8507a000 801  msdosfs_iconv.ko
>
> But I'm using 11.1-STABLE.  Maybe something changed?
>
> --
> Cheers,
> Henry
>
I am running:
 FreeBSD blubee 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r326056: Tue Nov 21
14:54:55 UTC 2017
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64

kldstats
101 0x85e89000 806  msdosfs_iconv.ko
111 0x85e8a000 4633 libiconv.ko

Can you list out the steps that you followed?

I know that if I first run the mount command as root; I can then mount and
unmount as regular user.

If I try to mount with that -L flag
msdosfs_iconv complains at me.
___
freebsd-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: msdosfs_iconv

[blubee blubeeme]

On Sun, Jan 14, 2018 at 11:53 AM, Henry Hu <henry.hu...@gmail.com> wrote:

>
>
> On Sat, Jan 13, 2018 at 9:10 PM, blubee blubeeme <gurenc...@gmail.com>
> wrote:
>
>> This is a repost from freebsd-question; Hoping to get more exposure and
>> help here.
>>
>> I am trying to run mount_msdosfs with the option to set locale like this:
>> mount_msdosfs -L en_US.UTF-8 /dev/da0s1 $HOME/usb
>>
>> This returns operation not permitted.
>>
>> usrmount is set to 1 and everything mounts as expected w/o root if I
>> remove
>> the locale option. The problem here is that my document filenames are
>> garbled and I can't actually open the files.
>>
>> kiconvtool: https://wiki.freebsd.org/DmitryMarakasov/kiconvtool
>> is said to work but it does not, after installing it I still get the exact
>> same error.
>>
>> Have you tried to kldload msdosfs_iconv first?
>
> Is there a way to set locale when using mount_msdosfs without sudo?
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
>> "
>>
>
>
>
> --
> Cheers,
> Henry
>
Yes, /etc/rc.conf has this line:
kld_list="nvidia-modeset msdosfs_iconv"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

msdosfs_iconv

[blubee blubeeme]

This is a repost from freebsd-question; Hoping to get more exposure and
help here.

I am trying to run mount_msdosfs with the option to set locale like this:
mount_msdosfs -L en_US.UTF-8 /dev/da0s1 $HOME/usb

This returns operation not permitted.

usrmount is set to 1 and everything mounts as expected w/o root if I remove
the locale option. The problem here is that my document filenames are
garbled and I can't actually open the files.

kiconvtool: https://wiki.freebsd.org/DmitryMarakasov/kiconvtool
is said to work but it does not, after installing it I still get the exact
same error.

Is there a way to set locale when using mount_msdosfs without sudo?
___
freebsd-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 Tue, Jan 9, 2018 at 10:09 AM, Mark Millard <mar...@dsl-only.net> wrote:

>
> On 2018-Jan-8, at 1:15 AM, blubee blubeeme  wrote:
>
> > On Mon, Jan 8, 2018 at 3:20 PM, Mark Millard 
> wrote:
> >> [The involvement of sysutils/fusefs-simple-mtpfs
> >> and sysutils/fusefs-libs and multimedia/libmtp
> >> in order to use the Media Transfer Protocol (MTP)
> >> against the LG v30 likely explains much of the
> >> performance difference vs. local UFS file
> >> systems. I provide some related notes.]
> >>
> >> blubee blubeeme gurenchan at gmail.com wrote on
> >> Mon Jan 8 05:17:24 UTC 2018 :
> >>
> >> [Note: the original was in a reply to a Jon Brawn
> >> post. I've merged it back with my post.]
> >>
> >> > On 2018-Jan-7, at 11:46 AM, Mark Millard 
> wrote:
> >> >
> >> >> On 2018-Jan-7, at 10:23 AM, blubee blubeeme 
> wrote:
> >> >>
> >> >>
> >> >>
> >> >>> On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard  dsl-only.net> wrote:
> >> >>>
> >> >>>> On 2018-Jan-7, at 7:50 AM, blubee blubeeme 
> wrote:
> >> >>>>
> >> >>>>> I ran this test and here's some results.
> >> >>>>> gstat -pd images:
> >> >>>>>
> >> >>>>> 18GB file from laptop to phone: https://imgur.com/a/7iHwv
> >> >>>>> 18GB file from laptop to ssd: https://imgur.com/a/40Q6V
> >> >>>>> multiple small files from laptop to phone:
> https://imgur.com/a/B4v4y
> >> >>>>> multiple small files from laptop to ssd:
> https://imgur.com/a/mDiMu
> >> >>>>>
> >> >>>>> The files are missing timestamps but the originals were taken
> with scrot and have timestamps available here: https://nofile.io/f/
> mzKnkpM9CyC/stats.tar.gz2
> >> >>>>>
> >> >>>>> as far as why there's such high deletions? I can't say I'm only
> using cp.
> >> >>>>
> >> >>>> I assume that md99 is for a file-based swap-space, such as
> >> >>>> via /var/swap0 file. (As a side note I warn about bugzilla
> >> >>>> 206048 for such contexts.) Otherwise please describe how
> >> >>>> md99 is created. (Below I assume the swap-space usage of
> >> >>>> md99.)
> >> >>>>
> >> >>>> The only other device that your pictures show is your
> >> >>>> NVMe device nvd0.
> >> >>>>
> >> >>>> No picture shows a device for the LG v30 when it is mentioned
> >> >>>> above as being copied to or from. How is it that there is no
> >> >>>> mounted device shown for the LG v30?
> >> >>>>
> >> >>>> No picture shows a device for the SSD when it is mentioned
> >> >>>> above as being copied to or from. How is it that there
> >> >>>> is no mounted device shown for the SSD?
> >> >>>>
> >> >>>> Without a device displayed for the LG-v30/SSD there is nothing
> >> >>>> displayed for its reads or writes. This makes the gstat -pd
> >> >>>> useless.
> >> >>>>
> >> >>>> May be the p needs to be omitted for some reason? gstat -d
> >> >>>>
> >> >>>> ===
> >> >>>> Mark Millard
> >> >>>> markmi at dsl-only.net
> >> >>>
> >> >>> You are correct that md99 is a file backed swap disk, I am aware of
> the issues but I had to test some things out.
> >> >>>
> >> >>> Those tests earlier was a huge time sink.
> >> >>> Here's the dmesg output from earlier:
> >> >>> . . .
> >> >>> --
> >> >>>
> >> >>> I don't know why gstat isn't showing the info u are looking for.
> >> >>>
> >> >>> You said earlier that something was getting deleted,
> >> >>> I don't know what could be causing that.
> >> >>
> >> >> Those "deletes" are more commonly called TRIM on SSD's.
> >> >> FreeBSD called them, BIO_DELETE as I remember.
> >> >>
> >> >> Those deletes have nothing to do with umounting, deleteing
> &

Re: USB stack

[blubee blubeeme]

On Mon, Jan 8, 2018 at 3:20 PM, Mark Millard <mar...@dsl-only.net> wrote:

> [The involvement of sysutils/fusefs-simple-mtpfs
> and sysutils/fusefs-libs and multimedia/libmtp
> in order to use the Media Transfer Protocol (MTP)
> against the LG v30 likely explains much of the
> performance difference vs. local UFS file
> systems. I provide some related notes.]
>
> blubee blubeeme gurenchan at gmail.com wrote on
> Mon Jan 8 05:17:24 UTC 2018 :
>
> [Note: the original was in a reply to a Jon Brawn
> post. I've merged it back with my post.]
>
> > On 2018-Jan-7, at 11:46 AM, Mark Millard  wrote:
> >
> >> On 2018-Jan-7, at 10:23 AM, blubee blubeeme 
> wrote:
> >>
> >>
> >>
> >>> On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard 
> wrote:
> >>>
> >>>> On 2018-Jan-7, at 7:50 AM, blubee blubeeme 
> wrote:
> >>>>
> >>>>> I ran this test and here's some results.
> >>>>> gstat -pd images:
> >>>>>
> >>>>> 18GB file from laptop to phone: https://imgur.com/a/7iHwv
> >>>>> 18GB file from laptop to ssd: https://imgur.com/a/40Q6V
> >>>>> multiple small files from laptop to phone: https://imgur.com/a/B4v4y
> >>>>> multiple small files from laptop to ssd: https://imgur.com/a/mDiMu
> >>>>>
> >>>>> The files are missing timestamps but the originals were taken with
> scrot and have timestamps available here: https://nofile.io/f/
> mzKnkpM9CyC/stats.tar.gz2
> >>>>>
> >>>>> as far as why there's such high deletions? I can't say I'm only
> using cp.
> >>>>
> >>>> I assume that md99 is for a file-based swap-space, such as
> >>>> via /var/swap0 file. (As a side note I warn about bugzilla
> >>>> 206048 for such contexts.) Otherwise please describe how
> >>>> md99 is created. (Below I assume the swap-space usage of
> >>>> md99.)
> >>>>
> >>>> The only other device that your pictures show is your
> >>>> NVMe device nvd0.
> >>>>
> >>>> No picture shows a device for the LG v30 when it is mentioned
> >>>> above as being copied to or from. How is it that there is no
> >>>> mounted device shown for the LG v30?
> >>>>
> >>>> No picture shows a device for the SSD when it is mentioned
> >>>> above as being copied to or from. How is it that there
> >>>> is no mounted device shown for the SSD?
> >>>>
> >>>> Without a device displayed for the LG-v30/SSD there is nothing
> >>>> displayed for its reads or writes. This makes the gstat -pd
> >>>> useless.
> >>>>
> >>>> May be the p needs to be omitted for some reason? gstat -d
> >>>>
> >>>> ===
> >>>> Mark Millard
> >>>> markmi at dsl-only.net
> >>>
> >>> You are correct that md99 is a file backed swap disk, I am aware of
> the issues but I had to test some things out.
> >>>
> >>> Those tests earlier was a huge time sink.
> >>> Here's the dmesg output from earlier:
> >>> . . .
> >>> --
> >>>
> >>> I don't know why gstat isn't showing the info u are looking for.
> >>>
> >>> You said earlier that something was getting deleted,
> >>> I don't know what could be causing that.
> >>
> >> Those "deletes" are more commonly called TRIM on SSD's.
> >> FreeBSD called them, BIO_DELETE as I remember.
> >>
> >> Those deletes have nothing to do with umounting, deleteing
> >> devices, etc.
> >>
> >>> I've provided tons of debug out, logs, pciconf, dmesg, etc...
> >>> Even say forget the mobile device and go from
> >>> zpool
> >>
> >> From which I've not been able to figure out the kind of
> >> information that I'm looking for.
> >>
> >> Just because a device is present, does not mean that it
> >> is available as a file system. I'm more interested in
> >> how the file systems are made available --or if some
> >> non-file system way of working is involved.
> >>
> >>> Are you saying that there's something misconfigured on my end?
> >>> What other info do you need me to provide to try to figure out
> >>> what's going on or why I'm getting these transfer rates?
> >&

Re: USB stack

[blubee blubeeme]

On Mon, Jan 8, 2018 at 8:03 AM, Jon Brawn <j...@brawn.org> wrote:

>
>
> > On Jan 7, 2018, at 5:44 PM, Jon Brawn <j...@brawn.org> wrote:
> >
> >
> >> On Jan 6, 2018, at 10:18 PM, blubee blubeeme <gurenc...@gmail.com>
> wrote:
> >>
> >> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh <i...@bsdimp.com> wrote:
> >>
> >>>
> >>>
> >>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme <gurenc...@gmail.com>
> >>> 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 <dar...@dons.net.au>
> >>>> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>>> On 4 Jan 2018, at 09:23, Gary Jennejohn <gljennj...@gmail.com>
> 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@
> 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:  >> 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 0x80

newcons vs syscons

[blubee blubeeme]

I'm curious why the new console driver vt doesn't have a vesa driver when
the traditional syscons driver did.

https://wiki.freebsd.org/Newcons

Is there any specific reason why vesa driver wasn't implemented?
___
freebsd-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 Mon, Jan 8, 2018 at 1:41 AM, Mark Millard <mar...@dsl-only.net> wrote:

>
> On 2018-Jan-7, at 7:50 AM, blubee blubeeme  wrote:
>
> > I ran this test and here's some results.
> > gstat -pd images:
> >
> > 18GB file from laptop to phone: https://imgur.com/a/7iHwv
> > 18GB file from laptop to ssd: https://imgur.com/a/40Q6V
> > multiple small files from laptop to phone: https://imgur.com/a/B4v4y
> > multiple small files from laptop to ssd: https://imgur.com/a/mDiMu
> >
> > The files are missing timestamps but the originals were taken with scrot
> and have timestamps available here: https://nofile.io/f/
> mzKnkpM9CyC/stats.tar.gz2
> >
> > as far as why there's such high deletions? I can't say I'm only using cp.
>
> I assume that md99 is for a file-based swap-space, such as
> via /var/swap0 file. (As a side note I warn about bugzilla
> 206048 for such contexts.) Otherwise please describe how
> md99 is created. (Below I assume the swap-space usage of
> md99.)
>
> The only other device that your pictures show is your
> NVMe device nvd0.
>
> No picture shows a device for the LG v30 when it is mentioned
> above as being copied to or from. How is it that there is no
> mounted device shown for the LG v30?
>
> No picture shows a device for the SSD when it is mentioned
> above as being copied to or from. How is it that there
> is no mounted device shown for the SSD?
>
> Without a device displayed for the LG-v30/SSD there is nothing
> displayed for its reads or writes. This makes the gstat -pd
> useless.
>
> May be the p needs to be omitted for some reason? gstat -d
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> You are correct that md99 is a file backed swap disk, I am aware of the
issues but I had to test some things out.

Those tests earlier was a huge time sink.
Here's the dmesg output from earlier:

Jan  7 19:13:17 blubee kernel: Copyright (c) 1992-2017 The FreeBSD Project.
Jan  7 19:13:17 blubee kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988,
1989, 1991, 1992, 1993, 1994
Jan  7 19:13:17 blubee kernel: The Regents of the University of California.
All rights reserved.
Jan  7 19:13:17 blubee kernel: FreeBSD is a registered trademark of The
FreeBSD Foundation.
Jan  7 19:13:17 blubee kernel: FreeBSD 12.0-CURRENT #0 r326056: Tue Nov 21
14:54:55 UTC 2017
Jan  7 19:13:17 blubee kernel:
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64
Jan  7 19:13:17 blubee kernel: FreeBSD clang version 5.0.0
(tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn)
Jan  7 19:13:17 blubee kernel: WARNING: WITNESS option enabled, expect
reduced performance.
Jan  7 19:13:17 blubee kernel: VT(efifb): resolution 3840x2160
Jan  7 19:13:17 blubee kernel: CPU: Intel(R) Core(TM) i7-6700HQ CPU @
2.60GHz (2592.11-MHz K8-class CPU)
Jan  7 19:13:17 blubee kernel:   Origin="GenuineIntel"  Id=0x506e3
Family=0x6  Model=0x5e  Stepping=3
Jan  7 19:13:17 blubee kernel:
 
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Jan  7 19:13:17 blubee kernel:
 
Features2=0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
Jan  7 19:13:17 blubee kernel:   AMD
Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
Jan  7 19:13:17 blubee kernel:   AMD Features2=0x121<LAHF,ABM,Prefetch>
Jan  7 19:13:17 blubee kernel:   Structured Extended
Features=0x29c6fbf<FSGSBASE,TSCADJ,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE>
Jan  7 19:13:17 blubee kernel:   XSAVE
Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
Jan  7 19:13:17 blubee kernel:   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
Jan  7 19:13:17 blubee kernel:   TSC: P-state invariant, performance
statistics
Jan  7 19:13:17 blubee kernel: real memory  = 34359738368 (32768 MB)
Jan  7 19:13:17 blubee kernel: avail memory = 33147957248 (31612 MB)
Jan  7 19:13:17 blubee kernel: Event timer "LAPIC" quality 600
Jan  7 19:13:17 blubee kernel: ACPI APIC Table: 
Jan  7 19:13:17 blubee kernel: FreeBSD/SMP: Multiprocessor System Detected:
8 CPUs
Jan  7 19:13:17 blubee kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) x 2
hardware threads
Jan  7 19:13:17 blubee kernel: random: unblocking device.
Jan  7 19:13:17 blubee kernel: ioapic0  irqs 0-119 on
motherboard
Jan  7 19:13:17 blubee kernel: SMP: AP CPU #1 Launched!
Jan  7 19:13:17 blubee kernel: SMP: AP CPU #4 Launched!
Jan  7 19:13:17 blubee kernel: SMP: AP CPU #2 Launched!
Jan  7 19:13:17 blubee kernel: SMP: AP CPU #3 Launched!
Jan  7 19:13:17 blubee kernel: SMP: AP CPU #6 Launched!
Jan  7 19:13:17 blubee kernel: SMP: AP CPU #5 Launched!
Jan  7 19:13:17 bl

Re: USB stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 8:13 PM, Mark Millard <mar...@dsl-only.net> wrote:

> [I add an example of a none-USB to USB2 copy and
> a USB2 to non-USB copy. They do not show any
> < 8 MiByte/s bottlenecks.]
>
> On 2018-Jan-7, at 3:42 AM, Mark Millard <mar...@dsl-only.net> wrote:
>
> > [The other numbers show lots of delete activity on nvd0,
> > not just primarily reads. Also: Can you test a different
> > USB device, such as a USB SSD stick?]
> >
> > On 2018-Jan-7, at 2:44 AM, Mark Millard  wrote:
> >
> >> [The following notes a problem with how a test was done.
> >> I omit the rest of the material.]
> >>
> >> On 2018-Jan-7, at 2:09 AM, blubee blubeeme 
> wrote:
> >>
> >> . . .
> >>> This is a larger file, not the largest but hey
> >>>
> >>> L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps
>  ms/d   %busy Name
> >>>   0  4  0  00.0  2  80.0  0  0
> 0.00.1| nvd0
> >>>   0  0  0  00.0  0  00.0  0  0
> 0.00.0| md99
> >>> 128982  1 32   58.8981 125428  110.5  0  0
> 0.0  100.0| da1
> >> . . .
> >>
> >> Note that almost complete lack of kBps near r/s but the large
> >> kBps near w/s.
> >>
> >> It appears that the file has been cached in RAM and is not
> >> being read from media at all. So this test is of a RAM to
> >> disk transfer, not disk to disk, as far as I can tell.
> >>
> >> You need to avoid re-reading the same file unless you
> >> dismount and remount between tests or some such. Or
> >> just use a different file not copied since booting (that
> >> file may or may not be a previous copy of the same file
> >> by content).
> >>
> >> See if you can get gstat -pd results that show both
> >> read kBps and write kBps figures.
> >
> > Can you test another USB device, such as a USB SSD
> > stick, sometime known to be reliably fast and not
> > involving reading from the LG v30?
> >
> > From what I read Android has many file systems supported
> > or used at one time: ext4, f2fs, yaffs, yaffs2,
> > vfat, msdos being in the list. Normal SD and SDHC files
> > systems are FAT32 and SDXC is exFAT.
> >
> > So "Android 7.1" does not answer my question about which
> > file system is actually on the usdcard being used. I'd
> > guess FAT32 or exFAT, depending on SD/SDHC vs. SDXC, but
> > I do not really know.
> >
> >
> > My results show that getting above 8 MiBytes/s over
> > USB 2.0 is supported for other than the rather low end
> > of the FreeBSD range of systems. Beyond that is something
> > more specific to your context and not involved in mine.
> > The file system might be involved.
> >
> > So far, from the tables and what you have written, the
> > LG v30 is required to be involved for the slowdown
> > to sub 8 MiBytes/s. This is part of why I ask about
> > testing an alternative USB device that is fast: it
> > tests USB without involving the LG v30 or the usdcard.
> >
> > If USB ends up faster, then it is not USB's "stack" that
> > is the primary source of the current bottleneck for your
> > context: something else is also involved, such as the
> > file system may be.
> >
> > Can you show gstat -pd output for copying from the
> > LG v30? Copying to the 1TB USB backup device? The
> > %busy figures might be interesting.
> >
> >
> > In your other table:
> >
> > This is an example copying [multiple small files] to the 1TB drive.
> > 
> --
> > L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps
>  ms/d   %busy Name
> >0547290  352392.0  4 16   73.1249  44291
>  93.7   48.8| nvd0
> >0  0  0  00.0  0  00.0  0  0
> 0.00.0| md99
> >   21333  0  00.0333  36040   16.2  0  0
> 0.0   76.2| da1
> > 
> --
> >
> > This shows lots of deletes per second for some reason.
> >
> > Did you move instead of copy? After each file was copied,
> > was it then deleted?
> >
> > It is possible that the deletes slowed this down,
> > whatever they were from.
>
>
> Here are 

Re: USB stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 5:35 PM, Mark Millard <mar...@dsl-only.net> wrote:

> blubee blubeeme gurenchan at gmail.com wrote on
> Wed Jan 3 10:31:56 UTC 2018 :
>
> > 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 machine: Pine64+ 2GB? Ryzen Threadripper 1950X? . . .?
>
> It would help to specify the type of system and its
> relevant properties (not just the processor).
>
> What independent channels are in use? Any? Or are
> the source and destination on the same channel at
> some stage?
>
> > I transferred about 30GB of audio from laptop
>
> The 30GB was on what type of device? Plugged in to what?
> What file system?
>
ZFS file system on the main machine and the 1TB Transcend drive.
I am not 100% sure what format android device is;
I can look into this further but I've been testing on the Transcend device
linked above in this list.

>
> > to Samsung usb class 10 usb
> > device connected to LG v30.
>
> What file system?
>
Android 7.1

>
> And in another message (indicating the other direction
> of transfer compared to the above?):
>
I transfer from the phone to the computer.

>
> > 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.
>
> So the LG v30 was plugged in as a USB device, effectively
> acting as a media reader/writer? What file system?
> (It seems unlikely that the LG v30 would use a FreeBSD
> native file system to record RAW video files.)
>
>
> Going the other direction of providing some examples
> of files copies for UFS. . .
>
> Note: These are based on head -r327485 with
> non-debug kernel builds.
>
>
> Example performance copying /usr/src/ :
> (lots of small files on a fairly low-end FreeBSD
> machine)
>
> RPi2B V1.1 (with USB 2.0)
> One USB 3.0 powered hub (USB 2.0 compatible) with both:
>
> A) USB 3.0 SSD stick (USB 2.0 compatible) with the root file system
>
> B) 64 GB eMMC on a usdcard adapter, plugged into a USB 3.0 media
>reader/writer (USB 2.0 compatible).
>
> mount -o noatime in use for (A) and (B). UFS file systems.
> soft-updates enabled.
>
> cp -ax /usr/src/ /mnt/root/srccpy_test
>
> gstat -pd outputs, a few examples:
>
> dT: 1.007s  w: 1.000s
>  L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps
>  ms/d   %busy Name
> 0255255   55011.9  0  00.0  0  0
> 0.0   48.0| da0
> 0  0  0  00.0  0  00.0  0  0
> 0.00.0| da1
> 0  0  0  00.0  0  00.0  0  0
> 0.00.0| da2
> 0  0  0  00.0  0  00.0  0  0
> 0.00.0| da3
>64426  1 32  221.4425   6287  140.4  0  0
> 0.0   62.9| da4
>
> Note that the read kBps + write kBps means around 11MiByte/s for r+w.
> (There is only one USB connection at the RPi2B V1.1 here,
> not multiple, independent channels.)
>

This is an example copying [multiple small files] to the 1TB drive.
--
 L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps
 ms/d   %busy Name
0547290  352392.0  4 16   73.1249  44291
 93.7   48.8| nvd0
0  0  0  00.0  0  00.0  0  0
0.00.0| md99
   21333  0  00.0333  36040   16.2  0  0
0.0   76.2| da1
--


>
> dT: 1.007s  w: 1.000s
>  L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps
>  ms/d   %busy Name
> 0393393   52951.3  0  00.0  0  0
> 0.0   50.7| da0
> 0  0  0  00.0  0  00.0  0  0
> 0.00.0| da1
> 0  0  0  00.0  0  00.0  0  0
> 0.00.0| da2
> 0  0  0  00.0  0  00.0  0  0
> 0.00.0| da3
>46102  2 642.9100   2101  116.9  0  0
> 0.0   19.5| da4
>
> The above last shows a period with around 7 MiBytes/s for r+w.
>
> dT: 1.007s  w: 1.000s
>  L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps
>  ms/d   %busy Name
>16   

Re: Re: USB stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 4:27 PM, Freddie Cash <fjwc...@gmail.com> wrote:

> Forgot to include the list. Resending.
>
> -- Forwarded message --
> From: "Freddie Cash" <fjwc...@gmail.com>
> Date: Jan 7, 2018 12:26 AM
> Subject: Re: USB stack
> To: "blubee blubeeme" <gurenc...@gmail.com>
> Cc:
>
> On Jan 6, 2018 8:30 PM, "blubee blubeeme" <gurenc...@gmail.com> wrote:
>
> > 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
>
>
> Is the slow transfers user error?
>
>
> You'll need to post /var/run/dmesg.boot somewhere so we can see how your
> USB controllers are being detected and the different buses are being
> configured, and which bus/controller the USB devices are attaching too. You
> haven't shown enough information yet to be able to help you.
>
> Cheers,
> Freddie
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
Here's the latest unmodified GENERIC kernel boot log.

FreeBSD blubee 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r326056: Tue Nov 21
14:54:55 UTC 2017
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64

pastebin: https://pastebin.com/66NZEFtp

Anything else that I can provide?
___
freebsd-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 1:32 PM, Tomoaki AOKI <junch...@dec.sakura.ne.jp>
wrote:

> On Sun, 7 Jan 2018 12:25:17 +0800
> blubee blubeeme <gurenc...@gmail.com> wrote:
>
> > On Sun, Jan 7, 2018 at 12:20 PM, Warner Losh <i...@bsdimp.com> wrote:
> >
> > >
> > >
> > > On Sat, Jan 6, 2018 at 9:18 PM, blubee blubeeme <gurenc...@gmail.com>
> > > wrote:
> > >
> > >>
> > >>
> > >> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh <i...@bsdimp.com> wrote:
> > >>
> > >>>
> > >>>
> > >>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme <gurenc...@gmail.com
> >
> > >>> 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 <
> dar...@dons.net.au>
> > >>>> wrote:
> > >>>>
> > >>>> >
> > >>>> >
> > >>>> > > On 4 Jan 2018, at 09:23, Gary Jennejohn <gljennj...@gmail.com>
> > >>>> 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
> &

Re: USB stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 12:25 PM, Warner Losh <i...@bsdimp.com> wrote:

>
>
> On Sat, Jan 6, 2018 at 9:20 PM, blubee blubeeme <gurenc...@gmail.com>
> wrote:
>
>>
>>
>> On Sun, Jan 7, 2018 at 12:17 PM, Warner Losh <i...@bsdimp.com> wrote:
>>
>>>
>>>
>>> On Sat, Jan 6, 2018 at 9:08 PM, blubee blubeeme <gurenc...@gmail.com>
>>> wrote:
>>>
>>>> On Sun, Jan 7, 2018 at 11:56 AM, blubee blubeeme <gurenc...@gmail.com>
>>>> 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 <dar...@dons.net.au>
>>>> > wrote:
>>>> >
>>>> >>
>>>> >>
>>>> >> > On 4 Jan 2018, at 09:23, Gary Jennejohn <gljennj...@gmail.com>
>>>> 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"

Re: USB stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh <i...@bsdimp.com> wrote:

>
>
> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme <gurenc...@gmail.com>
> 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 <dar...@dons.net.au>
>> wrote:
>>
>> >
>> >
>> > > On 4 Jan 2018, at 09:23, Gary Jennejohn <gljennj...@gmail.com> 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:20 PM, Warner Losh <i...@bsdimp.com> wrote:

>
>
> On Sat, Jan 6, 2018 at 9:18 PM, blubee blubeeme <gurenc...@gmail.com>
> wrote:
>
>>
>>
>> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh <i...@bsdimp.com> wrote:
>>
>>>
>>>
>>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme <gurenc...@gmail.com>
>>> 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 <dar...@dons.net.au>
>>>> wrote:
>>>>
>>>> >
>>>> >
>>>> > > On 4 Jan 2018, at 09:23, Gary Jennejohn <gljennj...@gmail.com>
>>>> 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 ba

Re: USB stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 12:17 PM, Warner Losh <i...@bsdimp.com> wrote:

>
>
> On Sat, Jan 6, 2018 at 9:08 PM, blubee blubeeme <gurenc...@gmail.com>
> wrote:
>
>> On Sun, Jan 7, 2018 at 11:56 AM, blubee blubeeme <gurenc...@gmail.com>
>> 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 <dar...@dons.net.au>
>> > wrote:
>> >
>> >>
>> >>
>> >> > On 4 Jan 2018, at 09:23, Gary Jennejohn <gljennj...@gmail.com>
>> 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 11:56 AM, blubee blubeeme <gurenc...@gmail.com>
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 <dar...@dons.net.au>
> wrote:
>
>>
>>
>> > On 4 Jan 2018, at 09:23, Gary Jennejohn <gljennj...@gmail.com> 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]

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

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: 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: USB stack

[blubee blubeeme]

On Wed, Jan 3, 2018 at 6:41 PM, O'Connor, Daniel <dar...@dons.net.au> wrote:

>
>
> > On 3 Jan 2018, at 11:31, blubee blubeeme <gurenc...@gmail.com> 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"

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: Programmatically cache line

[blubee blubeeme]

On Tue, Jan 2, 2018 at 12:26 AM, Ian Lepore <i...@freebsd.org> 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 <adrian.ch...@gmail.com> 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"

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

Re: kernel names

[blubee blubeeme]

On Thu, Dec 14, 2017 at 1:51 PM, Allan Jude <allanj...@freebsd.org> 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: 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"

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 Wed, Dec 13, 2017 at 5:53 AM, Mark Millard <mar...@dsl-only.net> 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"

Re: get_swap_pager(x) failed

[blubee blubeeme]

On Tue, Dec 12, 2017 at 3:34 PM, blubee blubeeme <gurenc...@gmail.com>
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 blu

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: 

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"

Re: valloric YCM [header definitions]

[blubee blubeeme]

On Wed, Dec 6, 2017 at 2:18 AM, blubee blubeeme <gurenc...@gmail.com> 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"

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"

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"

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

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"

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"

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

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 <gurenc...@gmail.com>
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

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

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"

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*)())[argc];
}

tried compiling it with clang:
clang++ test.cpp -o test -lm
test.cpp:7:17: error: use of undeclared identifier 'expf10'
return ((int*)())[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*)())[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"

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"

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 <h...@selasky.org>
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"

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 <gurenc...@gmail.com>
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 <h...@selasky.org>
> 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]

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 <h...@selasky.org>
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]

: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 Wed, Oct 25, 2017 at 5:47 PM, Hans Petter Selasky <h...@selasky.org>
wrote:

> On 10/25/17 11:39, blubee blubeeme wrote:
>
>> 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
>>
>>
> Try:
>
> dbus-launch okular
>
> --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]

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 <h...@selasky.org>
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"

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"

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"

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"

Re: cve-2017-13077 - WPA2 security vulni

[blubee blubeeme]

This is awesome, thanks!

On Mon, Oct 16, 2017, 19:19 Stefan Esser <s...@freebsd.org> 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 <p...@phk.freebsd.dk>
> > wrote:
> >
> >> 
> >> In message <CALM2mEmawo7q7GNYLQZPovPVP3dQun5S4Aa4J8Cw2nK8g6Ux4Q@mail.
> >> 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: 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 <p...@phk.freebsd.dk>
wrote:

> 
> In message <CALM2mEmawo7q7GNYLQZPovPVP3dQun5S4Aa4J8Cw2nK8g6Ux4Q@mail.
> 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"