Re: Stop installing /usr/bin/clang
On Fri, Aug 16, 2019 at 08:57:13AM +0300, nonamel...@ukr.net wrote:
> I see the same thing with base /usr/bin/ld and /usr/local/bin/ld from
> binutils.
Yes but a direct ld use is very rare. When it is needed, usually the
level of hackery applied is already high enough for the user to already
know what she does. I did not see it causing issues practically, while
multiple clangs in the path cause real problems.
>
> --- Original message ---
> From: "Konstantin Belousov"
> Date: 15 August 2019, 19:48:37
>
> Please look at https://reviews.freebsd.org/D21060
> I propose to stop installing /usr/bin/clang, clang++, clang-cpp.
>
> It probably does not matter when all your software comes from ports or
> packages, but is actually very annoying when developing on FreeBSD.
> In particular, you never know which `clang' is called in the user
> environment, because it depends on the $PATH elements ordering.
>
> To clear some confusion: this has nothing to do with not installing
> compiler from base, /usr/bin/c{c,++,pp} are still there after the change
> is applied. It only to make clang on par with gcc, and to remove one
> thing that was quite time-consuming in multi-target environment for me
> during porting something large in FreeBSD userspace.
> ___
> freebsd-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: Stop installing /usr/bin/clang
On 15/08/2019 17:48, Konstantin Belousov wrote:
> Please look at https://reviews.freebsd.org/D21060
> I propose to stop installing /usr/bin/clang, clang++, clang-cpp.
>
> It probably does not matter when all your software comes from ports or
> packages, but is actually very annoying when developing on FreeBSD.
> In particular, you never know which `clang' is called in the user
> environment, because it depends on the $PATH elements ordering.
What is the confusion here? The binary that is invoked as clang is from
the base system. The binary that is invoked as clang{version number} is
from ports. If the user has built clang from source and has set up
their path to put that first, then they will get a different clang, but
there's no way we can stop that kind of behaviour.
For reference, on my machine, I have:
clang <- this one is from the base system
clang60 <- this one if from ports
clang70 <- this one if from ports
clang80 <- this one if from ports
clang-devel <- this one if from ports
Nothing in my PATH order affects this.
The only source of confusion that I regularly encounter comes from the
fact that FreeBSD packages install clang80, when every other system
installs clang-8, so I end up having to have a special case in CMake
logic for finding specific versions of tools like clang-format on FreeBSD.
That said, I don't know what the impact would be on configure scripts if
we didn't have a clang binary. CMake seems to run ${CC} -v and parse
the output, so it's quite happy finding that cc is clang (and the
specific version). How do most autoconf things handle this? Apple
shipped a gcc symlink to clang for years because, in the absence of a
gcc binary, a load of programs detected /usr/bin/cc and decided not to
enable any GNU extensions. We've managed to avoid having to do that,
but how many things look for clang, gcc, and cc in the path and enable
features based on which one they find?
David
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Huawei mobile/wifi gadgets: HOWTO
This seems to be sort of a FAQ, and I had a chance to spend a couple of
quality minutes with one of these devices.
The fundamental problem is that they come up as a CD device, with Windows
software to do whatever it takes.
Sending them a magic USB command enables other interfaces, including
serial/modem, USB ethernet etc.
The remaining issue is: How to get FreeBSD do send the magic string?
A file in /etc/devd along these lines will do it:
notify 1000 {
match "system" "GEOM";
match "type""CREATE";
match "cdev""iso9660/MOBILEWIFI";
action "/usr/local/sbin/usb_modeswitch -v 0x12d1 -p 0x15ca -J";
};
It works by reacting to the CD device appearing, which seems to be a
sure-fire indication that the device is in wrong mode.
You may have to adjust the precise "cdev" name (ls /dev/iso9660) and
vendor/product numbers (usbconfig dump_device_desc), and obviously
you have to install the usb_modeswitch port.
The -J argument seems to be what all newer Huawei devices want.
Add ifconfig_ue0=DHCP in /etc/rc.conf, and you should be set.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Stop installing /usr/bin/clang
On Fri, Aug 16, 2019 at 09:47:41AM +0100, David Chisnall wrote:
> On 15/08/2019 17:48, Konstantin Belousov wrote:
> > Please look at https://reviews.freebsd.org/D21060
> > I propose to stop installing /usr/bin/clang, clang++, clang-cpp.
> >
> > It probably does not matter when all your software comes from ports or
> > packages, but is actually very annoying when developing on FreeBSD.
> > In particular, you never know which `clang' is called in the user
> > environment, because it depends on the $PATH elements ordering.
>
> What is the confusion here?
Between /usr/bin/clang and /usr/local/bin/clang.
> The binary that is invoked as clang is from the base system.
Not necessary.
> The binary that is invoked as clang{version number} is from ports.
This is irrelevant.
> If the user has built clang from source and has set up
> their path to put that first, then they will get a different clang, but
> there's no way we can stop that kind of behaviour.
This is irrelevant as well.
You did not read neither review summary nor followups. clang also
comes from devel/llvm. Users that want clang do install it, esp. when
version in base is different.
>
> For reference, on my machine, I have:
>
> clang <- this one is from the base system
> clang60 <- this one if from ports
> clang70 <- this one if from ports
> clang80 <- this one if from ports
> clang-devel <- this one if from ports
>
> Nothing in my PATH order affects this.
>
> The only source of confusion that I regularly encounter comes from the
> fact that FreeBSD packages install clang80, when every other system
> installs clang-8, so I end up having to have a special case in CMake
> logic for finding specific versions of tools like clang-format on FreeBSD.
>
> That said, I don't know what the impact would be on configure scripts if
> we didn't have a clang binary. CMake seems to run ${CC} -v and parse
> the output, so it's quite happy finding that cc is clang (and the
> specific version). How do most autoconf things handle this? Apple
> shipped a gcc symlink to clang for years because, in the absence of a
> gcc binary, a load of programs detected /usr/bin/cc and decided not to
> enable any GNU extensions. We've managed to avoid having to do that,
> but how many things look for clang, gcc, and cc in the path and enable
> features based on which one they find?
I plan to ask for exp run with the patch after some more time to gather
feedback.
___
freebsd-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: Stop installing /usr/bin/clang
> On Fri, Aug 16, 2019 at 08:57:13AM +0300, nonamel...@ukr.net wrote:
> > I see the same thing with base?/usr/bin/ld and?/usr/local/bin/ld from
> > binutils.
> Yes but a direct ld use is very rare. When it is needed, usually the
> level of hackery applied is already high enough for the user to already
> know what she does. I did not see it causing issues practically, while
> multiple clangs in the path cause real problems.
Though I have accepted the change, I have now heard this "multiple foo
in path" argument twice, could you please elaborate on it?
If /usr/bin /bin are first I should get base stuff,
if /usr/local/bin are first I should get local stuff,
what exactly is this "real problems" your refering too?
Is it that something is flipping paths around? If so that
should be fixed! People have been using path to pick which
overload order they prefer for decades, and if we have some
how broken this.. well that should get fixed asap, not
removing stuff out of base because something is broken by
incorrect path manipulations.
Regards,
Rod
> > --- Original message ---
> > From: "Konstantin?Belousov"?
> > Date: 15?August?2019,?19:48:37
> >
> > Please look at https://reviews.freebsd.org/D21060
> > I propose to stop installing /usr/bin/clang, clang++, clang-cpp.
> >
> > It probably does not matter when all your software comes from ports or
> > packages, but is actually very annoying when developing on FreeBSD.
> > In particular, you never know which `clang' is called in the user
> > environment, because it depends on the $PATH elements ordering.
> >
> > To clear some confusion: this has nothing to do with not installing
> > compiler from base, /usr/bin/c{c,++,pp} are still there after the change
> > is applied. It only to make clang on par with gcc, and to remove one
> > thing that was quite time-consuming in multi-target environment for me
> > during porting something large in FreeBSD userspace.
> > ___
> > freebsd-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"
>
>
--
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Stop installing /usr/bin/clang
On Fri, Aug 16, 2019 at 02:14:38AM -0700, Rodney W. Grimes wrote:
> > On Fri, Aug 16, 2019 at 08:57:13AM +0300, nonamel...@ukr.net wrote:
> > > I see the same thing with base?/usr/bin/ld and?/usr/local/bin/ld from
> > > binutils.
> > Yes but a direct ld use is very rare. When it is needed, usually the
> > level of hackery applied is already high enough for the user to already
> > know what she does. I did not see it causing issues practically, while
> > multiple clangs in the path cause real problems.
>
> Though I have accepted the change, I have now heard this "multiple foo
> in path" argument twice, could you please elaborate on it?
I already did that more than once. Please read the review.
>
> If /usr/bin /bin are first I should get base stuff,
> if /usr/local/bin are first I should get local stuff,
> what exactly is this "real problems" your refering too?
You cannot mandate the path elements order for user, there are multiple
conflicting requirements which create loop in the elements ordering.
Removing clang from /usr/bin removes one of the requirement.
People have to put ~/bin in front of their $PATH and create symlink,
which raises questions why should they do that, and makes awful experience
for starting developing on FreeBSD.
>
> Is it that something is flipping paths around? If so that
> should be fixed! People have been using path to pick which
> overload order they prefer for decades, and if we have some
> how broken this.. well that should get fixed asap, not
> removing stuff out of base because something is broken by
> incorrect path manipulations.
>
> Regards,
> Rod
> > > --- Original message ---
> > > From: "Konstantin?Belousov"?
> > > Date: 15?August?2019,?19:48:37
> > >
> > > Please look at https://reviews.freebsd.org/D21060
> > > I propose to stop installing /usr/bin/clang, clang++, clang-cpp.
> > >
> > > It probably does not matter when all your software comes from ports or
> > > packages, but is actually very annoying when developing on FreeBSD.
> > > In particular, you never know which `clang' is called in the user
> > > environment, because it depends on the $PATH elements ordering.
> > >
> > > To clear some confusion: this has nothing to do with not installing
> > > compiler from base, /usr/bin/c{c,++,pp} are still there after the change
> > > is applied. It only to make clang on par with gcc, and to remove one
> > > thing that was quite time-consuming in multi-target environment for me
> > > during porting something large in FreeBSD userspace.
> > > ___
> > > freebsd-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"
> >
> >
>
> --
> Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Stop installing /usr/bin/clang
> On Fri, Aug 16, 2019 at 09:47:41AM +0100, David Chisnall wrote:
> > On 15/08/2019 17:48, Konstantin Belousov wrote:
> > > Please look at https://reviews.freebsd.org/D21060
> > > I propose to stop installing /usr/bin/clang, clang++, clang-cpp.
> > >
> > > It probably does not matter when all your software comes from ports or
> > > packages, but is actually very annoying when developing on FreeBSD.
> > > In particular, you never know which `clang' is called in the user
> > > environment, because it depends on the $PATH elements ordering.
> >
> > What is the confusion here?
> Between /usr/bin/clang and /usr/local/bin/clang.
Why is that a confusion? Any installed port that overloades
a base system component expects to do exactly that type of thing.
Why is clang special in this respect?
> > The binary that is invoked as clang is from the base system.
> Not necessary.
>
> > The binary that is invoked as clang{version number} is from ports.
> This is irrelevant.
>
> > If the user has built clang from source and has set up
> > their path to put that first, then they will get a different clang, but
> > there's no way we can stop that kind of behaviour.
> This is irrelevant as well.
>
> You did not read neither review summary nor followups. clang also
> comes from devel/llvm. Users that want clang do install it, esp. when
> version in base is different.
Exactly what is installed from devel/llvm that was not
covered below as clang-devel? And why is it any different
than any other port of clang listed below?
> > For reference, on my machine, I have:
> >
> > clang <- this one is from the base system
> > clang60 <- this one if from ports
> > clang70 <- this one if from ports
> > clang80 <- this one if from ports
> > clang-devel <- this one if from ports
> >
> > Nothing in my PATH order affects this.
> >
> > The only source of confusion that I regularly encounter comes from the
> > fact that FreeBSD packages install clang80, when every other system
> > installs clang-8, so I end up having to have a special case in CMake
> > logic for finding specific versions of tools like clang-format on FreeBSD.
> >
> > That said, I don't know what the impact would be on configure scripts if
> > we didn't have a clang binary. CMake seems to run ${CC} -v and parse
> > the output, so it's quite happy finding that cc is clang (and the
> > specific version). How do most autoconf things handle this? Apple
> > shipped a gcc symlink to clang for years because, in the absence of a
> > gcc binary, a load of programs detected /usr/bin/cc and decided not to
> > enable any GNU extensions. We've managed to avoid having to do that,
> > but how many things look for clang, gcc, and cc in the path and enable
> > features based on which one they find?
>
> I plan to ask for exp run with the patch after some more time to gather
> feedback.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
--
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Huawei mobile/wifi gadgets: HOWTO
On 2019-08-16 11:07, Poul-Henning Kamp wrote: The remaining issue is: How to get FreeBSD do send the magic string? FreeBSD USB has several quirks for these devices: See for example: /sys/dev/usb/usb_msctest.c:usb_msc_auto_quirk(struct usb_device *udev, uint8_t iface_index) /sys/dev/usb/usb_msctest.h:usb_error_t usb_msc_auto_quirk(struct usb_device *udev, /sys/dev/usb/usb_device.c: err = usb_msc_auto_quirk(udev, 0); And: usbconfig dump_quirk_names | grep -i UQ_MSC --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"
problem with LOCAL_MODULES
I tried to build a kernel today and it failed in modules-all even though I had LOCAL_MODULES="" in /etc/src.conf, as recommended by jhb. That's wrong. It has to be LOCAL_MODULES=, otherwise /sys/conf/kern.post.mk seems to conclude that there should be a module under /usr/local/sys/modules with the name "". -- Gary Jennejohnl ___ freebsd-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: Stop installing /usr/bin/clang
On 16/08/2019 10:10, Konstantin Belousov wrote:
You did not read neither review summary nor followups.
This is needlessly insulting and this kind of attitude from you towards
people on the mailing lists is one of the main reasons that my
engagement with the FreeBSD project tends to be in brief bursts. If
this were a one-off, then I would be happy to assume that you were
unusually stressed, but this is a long-term repeated pattern of behaviour.
I was not aware that devel/llvm was anything other than a meta-port that
installed the latest devel/llvm{version} (I have only ever installed the
packages when I need a specific version and so do not have the
devel/llvm port installed). You could have clarified that. Instead,
you chose to launch a personal attack.
You are not Linus and the FreeBSD project does not need a Linus.
David
___
freebsd-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: head -r351102 amd64 rebuilding itself but via devel/xtoolchain-llvm90 ( rc2: ports head -r509054 ) fails for boot2.out: ld.lld: error: undefined symbol: __ashldi3
On Thu, Aug 15, 2019 at 7:09 PM Mark Millard wrote: > > My attempt to have -r351102 rebuild itself via devel/llvm90 (rc2) > got: > > --- all_subdir_stand --- > --- boot2.out --- > ld.lld: error: undefined symbol: __ashldi3 > >>> referenced by ufsread.c:234 (/usr/src/stand/libsa/ufsread.c:234) > >>> boot2.o:(fsread) > >>> referenced by ufsread.c:270 (/usr/src/stand/libsa/ufsread.c:270) > >>> boot2.o:(fsread) > >>> referenced by ufsread.c:295 (/usr/src/stand/libsa/ufsread.c:295) > >>> boot2.o:(fsread) > >>> referenced by ufsread.c:297 (/usr/src/stand/libsa/ufsread.c:297) > >>> boot2.o:(fsread) > *** [boot2.out] Error code 1 > > make[5]: stopped in /usr/src/stand/i386/boot2 > .ERROR_TARGET='boot2.out' > .ERROR_META_FILE='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/stand/i386/boot2/boot2.out.meta' > .MAKE.LEVEL='5' > MAKEFILE='' > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' > _ERROR_CMD='/usr/local/llvm90/bin/ld.lld -m elf_i386_fbsd -static -N > --gc-sections -Ttext 0x2000 -o boot2.out > /usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/stand/i386/btx/lib/crt0.o > boot2.o sio.o;' > .CURDIR='/usr/src/stand/i386/boot2' > .MAKE='make' > .OBJDIR='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/stand/i386/boot2' > .TARGETS='all' > DESTDIR='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp' > LD_LIBRARY_PATH='' > MACHINE='amd64' > MACHINE_ARCH='amd64' > MAKEOBJDIRPREFIX='' > MAKESYSPATH='/usr/src/share/mk' > MAKE_VERSION='20181221' > PATH='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/bin::/sbin:/bin:/usr/sbin:/usr/bin' > SRCTOP='/usr/src' > OBJTOP='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64' > .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk > /usr/src/share/mk/src.sys.env.mk > /root/src.configs/src.conf.amd64-xtoolchain-llvm.amd64-host > /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk > /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk > /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk > /usr/src/share/mk/src.sys.mk /dev/null /usr/src/stand/i386/boot2/Makefile > /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk > /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk > /usr/src/share/mk/src.init.mk /usr/src/stand/i386/boot2/../Makefile.inc > /usr/src/share/mk/bsd.linker.mk /usr/src/stand/i386/boot2/../../Makefile.inc > /usr/src/stand/i386/boot2/../../defs.mk /usr/src/share/mk/src.opts.mk > /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk > /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.prog.mk > /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk > /usr/src/share/mk/bsd.nls.mk / us > r/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk > /usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk > /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.mk > /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk > /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk > /usr/src/share/mk/bsd.sys.mk' > .PATH='. /usr/src/stand/i386/boot2' > 1 error > We've been iterating on a fix for this- this is the latest iteration: https://reviews.freebsd.org/D21291 Thanks, Kyle Evans ___ freebsd-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: Can't boot current under bhyve on current
On 8/15/19 9:21 AM, Sean Eric Fagan wrote: > I get: > > Loading kernel... > /boot/kernel/kernel text=0x16c493c data=0x1c8b38+0x819238 > syms=[0x8+0x180c18+0x8+0x19df0b] > Loading configured modules... > can't find '/boot/entropy' > \ > > Note that I am using vm-bhyve as a management & control wrapper, so that was > done by doing > > vm create VM-TEST ; vm install VM-TEST 13.0.iso I think vm-bhyve hides stderr output from bhyve by default, but there might be a flag to make it display the stderr output. Can you try doing that to see if bhyve is reporting an error? Alternatively, can you see if the bhyve process is still running? -- John Baldwin ___ freebsd-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: Can't boot current under bhyve on current
>I think vm-bhyve hides stderr output from bhyve by default, but there might >be a flag to make it display the stderr output. Can you try doing that to see >if bhyve is reporting an error? Alternatively, can you see if the bhyve >process is still running? The log file from it is below. bhyve was still running, looping on vm ioctls, until I killed it. starting bhyve (run 1) bhyve exited with status 1 destroying network device tap1 stopped initialising [loader: bhyveload] [cpu: 1] [memory: 512M] [hostbridge: standard] [com ports: com1] [uuid: ad7532de-bec1-11e9-8a55-d05099c38c95] [utctime: yes] [debug mode: no] [primary disk: disk0.img] [primary disk dev: file] initialising network device tap0 failed to find virtual switch 'public' booting bhyveload -m 512M -e autoboot_delay=3 -d /VMs/VM-TEST/../.iso/FreeBSD-13.0-CURRENT-amd64-20190725-r350322-disc1.iso VM-TEST [bhyve options: -c 1 -m 512M -AHP -U ad7532de-bec1-11e9-8a55-d05099c38c95 -u] [bhyve devices: -s 0,hostbridge -s 31,lpc -s 4:0,virtio-blk,/VMs/VM-TEST/disk0.img -s 5:0,virtio-net,tap0,mac=58:9c:fc:04:34:69] [bhyve console: -l com1,stdio] [bhyve iso device: -s 3:0,ahci-cd,/VMs/VM-TEST/../.iso/FreeBSD-13.0-CURRENT-amd64-20190725-r350322-disc1.iso,ro] starting bhyve (run 1) bhyve exited with status 1 destroying network device tap0 stopped Alan was trying to help me debug this yesterday, and I manually ran bhyve, but had no errors, and it still didn't work. Thanks, Sean. ___ freebsd-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: Can't boot current under bhyve on current
Could you test with larger memory setup - instead of 512M, 1-2G? rgds, toomas > On 16 Aug 2019, at 22:00, Sean Eric Fagan wrote: > >> I think vm-bhyve hides stderr output from bhyve by default, but there might >> be a flag to make it display the stderr output. Can you try doing that to >> see >> if bhyve is reporting an error? Alternatively, can you see if the bhyve >> process is still running? > > The log file from it is below. bhyve was still running, looping on vm ioctls, > until I killed it. > > starting bhyve (run 1) > bhyve exited with status 1 > destroying network device tap1 > stopped > initialising >[loader: bhyveload] >[cpu: 1] >[memory: 512M] >[hostbridge: standard] >[com ports: com1] >[uuid: ad7532de-bec1-11e9-8a55-d05099c38c95] >[utctime: yes] >[debug mode: no] >[primary disk: disk0.img] >[primary disk dev: file] > initialising network device tap0 > failed to find virtual switch 'public' > booting > bhyveload -m 512M -e autoboot_delay=3 -d > /VMs/VM-TEST/../.iso/FreeBSD-13.0-CURRENT-amd64-20190725-r350322-disc1.iso > VM-TEST >[bhyve options: -c 1 -m 512M -AHP -U > ad7532de-bec1-11e9-8a55-d05099c38c95 -u] >[bhyve devices: -s 0,hostbridge -s 31,lpc -s > 4:0,virtio-blk,/VMs/VM-TEST/disk0.img -s > 5:0,virtio-net,tap0,mac=58:9c:fc:04:34:69] >[bhyve console: -l com1,stdio] >[bhyve iso device: -s > 3:0,ahci-cd,/VMs/VM-TEST/../.iso/FreeBSD-13.0-CURRENT-amd64-20190725-r350322-disc1.iso,ro] > starting bhyve (run 1) > bhyve exited with status 1 > destroying network device tap0 > stopped > > Alan was trying to help me debug this yesterday, and I manually ran bhyve, but > had no errors, and it still didn't work. > > Thanks, > > Sean. > ___ > freebsd-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: Can't boot current under bhyve on current
>Could you test with larger memory setup - instead of 512M, 1-2G? I tried multiple vcpus and 1G of RAM; it made no difference (to either my attempting to boot the system I built, or the ISO; just confirmed the ISO with 1G). Sean. ___ freebsd-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: Can't boot current under bhyve on current
Ok, with debug=yes I see that it *is* running the VM -- but I have no serial console? This may be operator error here, which is a big relief. An update after I get back from the vet :). Thanks! Sean. ___ freebsd-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: HEADSUP: drm-current-kmod now installs sources
On 8/14/19 3:40 PM, Daniel Eischen wrote: > I've lost the original thread, but would the sources in > /usr/local/sys/modules get built regardless of what MAKEOBJDIRPREFIX is? > And, now that sources may be installed by a port, what is the method for > _just_ updating the sources? Why do I even need to build and install the > port? Personally, I would just rather have the drm-kmod sources just > imported into base and maintained there. If I have 2 or more different > checked out base src trees, how do I get the correct drm-kmod to go with them > if there is only one /usr/local/sys/modules? Do I need multiple port trees > just to pull in out of tree module sources? In some ways, installing sources for DRM is a compromise for the fact that we can't have DRM in the base source anymore (for various reasons). However, virtualbox is also probably in that camp as well. -- John Baldwin ___ freebsd-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: HEADSUP: drm-current-kmod now installs sources
On 8/14/19 1:19 PM, Ian Lepore wrote:
> On Wed, 2019-08-14 at 13:59 -0600, Warner Losh wrote:
>> On Wed, Aug 14, 2019 at 1:56 PM Ian Lepore wrote:
>>
>>> On Wed, 2019-08-14 at 12:00 -0700, John Baldwin wrote:
On 8/14/19 11:06 AM, Kyle Evans wrote:
> LOCAL_MODULES="" does seem like a sensible default when we're
> not
> building a native kernel.
Unfortunately kern.post.mk has no way of knowing that as
MACHINE_*
are already set to the TARGET_* values by the time this target is
invoked. Also, the 'make tinderbox' use case is a legit use case
that some folks want (for CI, etc.)
>>>
>>> BUILDHOST_ARCH!= uname -p
>>> .if ${BUILDHOST_ARCH} != ${TARGET_ARCH}
>>>
>>> Unfortunately, I don't think it's as easy to compare the buildhost
>>> running version with the version of source being built, unless the
>>> build is started from the top level so that Makefile.inc1 sets the
>>> variables.
>>>
>>
>> We already know MACHINE_ARCH != TARGET_ARCH in Makefile.inc1 and
>> already do
>> different things based on it. But to be honest, I'd think there'd be
>> times
>> I'd absolutely want to build them all, and other times I wouldn't
>> which
>> strongly suggests some kind of knob specific for cross building the
>> port/pkg-based kernel modules. We could then pass that knob into the
>> kernel
>> builds which would then not try to guess whether or not to build
>> LOCAL_MODULES...
>>
>>
>
> This is just about AUTOMATICALLY deciding to build something, based on
> the presence of source code in an arbitrary fixed location outside of
> the source tree on the build machine. Anything set by the user should
> be honored without question, including LOCAL_MODULES.
>
> My point is only that the build machinery should not be deciding to
> build something the user didn't specify based on the existence of out-
> of-tree files on the build machine (I'd like to put the period right
> here in this sentence), unless there's a very high likelyhood that the
> build being done is for the build machine.
>
> Things like CI that want to include more than in-tree sources as part
> of the build should be handling that by setting appropriate knobs as
> part of invoking the build.
I talked with Warner some offline and I think having some knob that
controls whether or not LOCAL_MODULES auto-populates and having make
buildkernel default it to on/off for native/cross builds (but it can
always be forcefully set on the command line) is fine with me.
--
John Baldwin
___
freebsd-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: HEADSUP: drm-current-kmod now installs sources
> On 8/14/19 3:40 PM, Daniel Eischen wrote: > > I've lost the original thread, but would the sources in > > /usr/local/sys/modules get built regardless of what MAKEOBJDIRPREFIX is? > > And, now that sources may be installed by a port, what is the method for > > _just_ updating the sources? Why do I even need to build and install the > > port? Personally, I would just rather have the drm-kmod sources just > > imported into base and maintained there. If I have 2 or more different > > checked out base src trees, how do I get the correct drm-kmod to go with > > them if there is only one /usr/local/sys/modules? Do I need multiple port > > trees just to pull in out of tree module sources? > > In some ways, installing sources for DRM is a compromise for the fact that we > can't have DRM in the base source anymore (for various reasons). However, > virtualbox is also probably in that camp as well. I applaud this effort to provide a source compile mode for DRM, but I think it has come up a bit short on execution with numorious problems sited. I too am not real happy that /usr/local/src is going to get automatically invoked from my some odd 10+ src trees that are of various WIP's. I need a way to easily disable this both on a global scale, and on a per src tree way. Rather than a default to on with an opt out mechanism perhaps while we gain experience change this to a default to off with an opt in mechanism? Sadly I do not have proposed solution, but something better than what is there now needs to be found. Regards, -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't boot current under bhyve on current
Ok, if I run the bhyve commands manually, then I get a serial console. So something is just borked with vm-bhyve and its use of tmux. Whew. (Now I don't know *what*, but that's at least progress in my diagnosis!) ___ freebsd-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: 13.0 Current - r350702 exposed a Xorg failure
Graham, I loaded yesterday's new 13.0 Current r351067 snapshot and re-installed FreeBSD. The basic install went well, and I gave my user operator, wheel, & video permissions. I loaded Xorg via the pkg install route, all 172 packages. I installed the drm-kmod pkg too. I rebooted and ran startx as user and it failed, basically did not create the .serverauth file. I pressed forward and did the install of my desktop, LXDE, with it's config files. Still no go. I have looked at your good suggestions and the results are at the end of this message. I had to copy them to paper as best I could. I guess you saw John Baldwin's email of 13 Aug about the changes in drm-kmod. I played with my /etc/rc.conf and set the line to leave out the path (/boot/modules/), just "kld_list="amdgpu.ko". That didn't work either. I was wondering at that point if Pete Wright may be on track with his suggestion that the permissions were set to root, but I don't think so, as it all seems to be user - user in the user home directory, root - wheel in /usr/local/bin where start lives, and root-wheel in /boot/modules where the kmod files are. Then I started playing with the /etc/rc.conf file and got some interesting results. My machine is an HP All in One thing manufactured in 2014. It has a AMD E3 processor with integrated Radeon graphics. I had been using the newer "amdgpu.ko" module for some weeks, at least through installs of Gnome, KDE, Xfce, and two or three weeks of LXDE and it worked fine. I tried first using John Baldwin's sugestion to leave out the path. Thant didn't work, and I really think this advice was for those who are 1. Installing from ports, not pkg, and 2. Compiling these modules into their kernel. Neither apply to me, at least not yet, but I'm always ready to try if needed. This is where it gets real interesting: I tried the older "radeonkms.ko", and rebooted. The loading messages did not look promising, but no real errors either. When I ran startx, it tried to load. I got a white screen, that changed to a blank one after "some" time, and was unresponsive. I had to use the power button to shutdown Bnd guess what? When I rebooted and performed a post-mortum, it had created an .serverauth file. So it makes we think the permissions are ok, but there are some problems with my machine and the amd kmod files. I looked in /boot/modules and both amdgpu.ko & radeonkms.ko had dates of Aug 11. So the problem keeps shifting, but I'm working on it. pkg info | grep kmod : drm-current-kmod-4.16.g20190806 DRM Modules for the linuxkpi-base KMS components drm-kmod-g20190806 Metaport of DRM Modules for the linuxkpi-base KMS components gpu-firmware-g20190620 pciconf -lv | grep -C 3 display : 6 lines that confirm my video setup: Kabini/Radeon HD 8280/R3 series AMD/ATI VGA grep PORTS_MODULES /etc/make.conf: FILE/DIRECTORY NOT FOUND pkg rquery %e drm-kmod : Message about the basic DRM metaport, no hard info, looks like a sales pitch :) Anyway, I continue to work on this, one step at a time. Open to any & all corrections and suggestions. The base install of r351067 is good, and I installed ports this time, so I may do a pkg delete drm-kmod and make it from the ports. Maybe it would suit my machine better. Clay On Wed, Aug 14, 2019 at 3:09 AM Graham Perrin wrote: > On 10/08/2019 04:56, Clay Daniels Jr. wrote: > > drm-kmod was the same (g20190710) > > It's equally (if not more) important to consider what's installed by > drm-kmod. > > Can you share output from these three commands? > > pkg info | grep kmod > > pciconf -lv | grep -C 3 display > > grep PORTS_MODULES /etc/make.conf > > Thanks. > > Also, FYI (to help understand the purpose of drm-kmod): > > pkg rquery %e drm-kmod > > ___ freebsd-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: HEADSUP: drm-current-kmod now installs sources
On August 16, 2019 2:51:22 PM PDT, "Rodney W. Grimes" wrote: >> On 8/14/19 3:40 PM, Daniel Eischen wrote: >> > I've lost the original thread, but would the sources in >/usr/local/sys/modules get built regardless of what MAKEOBJDIRPREFIX >is? And, now that sources may be installed by a port, what is the >method for _just_ updating the sources? Why do I even need to build >and install the port? Personally, I would just rather have the >drm-kmod sources just imported into base and maintained there. If I >have 2 or more different checked out base src trees, how do I get the >correct drm-kmod to go with them if there is only one >/usr/local/sys/modules? Do I need multiple port trees just to pull in >out of tree module sources? >> >> In some ways, installing sources for DRM is a compromise for the fact >that we >> can't have DRM in the base source anymore (for various reasons). >However, >> virtualbox is also probably in that camp as well. > >I applaud this effort to provide a source compile mode for DRM, >but I think it has come up a bit short on execution with numorious >problems sited. > >I too am not real happy that /usr/local/src is going to get >automatically invoked from my some odd 10+ src trees that >are of various WIP's. I need a way to easily disable this >both on a global scale, and on a per src tree way. > >Rather than a default to on with an opt out mechanism perhaps >while we gain experience change this to a default to off with >an opt in mechanism? > >Sadly I do not have proposed solution, but something better >than what is there now needs to be found. > >Regards, Could we have a .src.conf in the root of the tree to configure this on a tree by tree basis? -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-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: HEADSUP: drm-current-kmod now installs sources
On Fri, 16 Aug 2019 15:40:24 -0700 Cy Schubert wrote: > On August 16, 2019 2:51:22 PM PDT, "Rodney W. Grimes" > wrote: > >> On 8/14/19 3:40 PM, Daniel Eischen wrote: > >> > I've lost the original thread, but would the sources in > >/usr/local/sys/modules get built regardless of what MAKEOBJDIRPREFIX > >is? And, now that sources may be installed by a port, what is the > >method for _just_ updating the sources? Why do I even need to build > >and install the port? Personally, I would just rather have the > >drm-kmod sources just imported into base and maintained there. If I > >have 2 or more different checked out base src trees, how do I get the > >correct drm-kmod to go with them if there is only one > >/usr/local/sys/modules? Do I need multiple port trees just to pull > >in out of tree module sources? > >> > >> In some ways, installing sources for DRM is a compromise for the > >> fact > >that we > >> can't have DRM in the base source anymore (for various reasons). > >However, > >> virtualbox is also probably in that camp as well. > > > >I applaud this effort to provide a source compile mode for DRM, > >but I think it has come up a bit short on execution with numorious > >problems sited. > > > >I too am not real happy that /usr/local/src is going to get > >automatically invoked from my some odd 10+ src trees that > >are of various WIP's. I need a way to easily disable this > >both on a global scale, and on a per src tree way. > > > >Rather than a default to on with an opt out mechanism perhaps > >while we gain experience change this to a default to off with > >an opt in mechanism? > > > >Sadly I do not have proposed solution, but something better > >than what is there now needs to be found. > > > >Regards, > > Could we have a .src.conf in the root of the tree to configure this > on a tree by tree basis? > > I use better way: /etc/make.conf: # Modules to build with kernel. PORTS_MODULES+= graphics/drm-fbsd12.0-kmod graphics/gpu-firmware-kmod + https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237290 ___ freebsd-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: HEADSUP: drm-current-kmod now installs sources
> On Fri, 16 Aug 2019 15:40:24 -0700 > Cy Schubert wrote: > > > On August 16, 2019 2:51:22 PM PDT, "Rodney W. Grimes" > > wrote: > > >> On 8/14/19 3:40 PM, Daniel Eischen wrote: > > >> > I've lost the original thread, but would the sources in > > >/usr/local/sys/modules get built regardless of what MAKEOBJDIRPREFIX > > >is? And, now that sources may be installed by a port, what is the > > >method for _just_ updating the sources? Why do I even need to build > > >and install the port? Personally, I would just rather have the > > >drm-kmod sources just imported into base and maintained there. If I > > >have 2 or more different checked out base src trees, how do I get the > > >correct drm-kmod to go with them if there is only one > > >/usr/local/sys/modules? Do I need multiple port trees just to pull > > >in out of tree module sources? > > >> > > >> In some ways, installing sources for DRM is a compromise for the > > >> fact > > >that we > > >> can't have DRM in the base source anymore (for various reasons). > > >However, > > >> virtualbox is also probably in that camp as well. > > > > > >I applaud this effort to provide a source compile mode for DRM, > > >but I think it has come up a bit short on execution with numorious > > >problems sited. > > > > > >I too am not real happy that /usr/local/src is going to get > > >automatically invoked from my some odd 10+ src trees that > > >are of various WIP's. I need a way to easily disable this > > >both on a global scale, and on a per src tree way. > > > > > >Rather than a default to on with an opt out mechanism perhaps > > >while we gain experience change this to a default to off with > > >an opt in mechanism? > > > > > >Sadly I do not have proposed solution, but something better > > >than what is there now needs to be found. > > > > > >Regards, > > > > Could we have a .src.conf in the root of the tree to configure this > > on a tree by tree basis? > > > > > > > I use better way: > /etc/make.conf: That file is global to all src trees, so that does not achive the desired effect. > # Modules to build with kernel. > PORTS_MODULES+= graphics/drm-fbsd12.0-kmod graphics/gpu-firmware-kmod Can we some how trigger that from either a kernel conf file, or at least on a per src tree basis? Ala cy's .src.conf? > + > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237290 I do like the patch that makes these go into the obj dir, good stuff! -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On Fri, 16 Aug 2019 16:32:18 -0700 (PDT) "Rodney W. Grimes" wrote: > > > >> > I've lost the original thread, but would the sources in > > > >/usr/local/sys/modules get built regardless of what > > > >MAKEOBJDIRPREFIX is? And, now that sources may be installed by > > > >a port, what is the method for _just_ updating the sources? Why > > > >do I even need to build and install the port? Personally, I > > > >would just rather have the drm-kmod sources just imported into > > > >base and maintained there. If I have 2 or more different > > > >checked out base src trees, how do I get the correct drm-kmod to > > > >go with them if there is only one /usr/local/sys/modules? Do I > > > >need multiple port trees just to pull in out of tree module > > > >sources? > > > >> > > > >> In some ways, installing sources for DRM is a compromise for > > > >> the fact > > > >that we > > > >> can't have DRM in the base source anymore (for various > > > >> reasons). > > > >However, > > > >> virtualbox is also probably in that camp as well. > > > > > > > >I applaud this effort to provide a source compile mode for DRM, > > > >but I think it has come up a bit short on execution with > > > >numorious problems sited. > > > > > > > >I too am not real happy that /usr/local/src is going to get > > > >automatically invoked from my some odd 10+ src trees that > > > >are of various WIP's. I need a way to easily disable this > > > >both on a global scale, and on a per src tree way. > > > > > > > >Rather than a default to on with an opt out mechanism perhaps > > > >while we gain experience change this to a default to off with > > > >an opt in mechanism? > > > > > > > >Sadly I do not have proposed solution, but something better > > > >than what is there now needs to be found. > > > > > > > > > > Could we have a .src.conf in the root of the tree to configure > > > this on a tree by tree basis? > > > > > > > > > > > > I use better way: > > /etc/make.conf: > > That file is global to all src trees, > so that does not achive the desired effect. You can override this using env __MAKE_CONF=PATH_TO_MAKE.CONF SRCCONF=PATH_TO_SRC.CONF > > # Modules to build with kernel. > > PORTS_MODULES+= graphics/drm-fbsd12.0-kmod > > graphics/gpu-firmware-kmod > > Can we some how trigger that from either a kernel conf file, > or at least on a per src tree basis? Ala cy's .src.conf? I dont know, never use 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: HEADSUP: drm-current-kmod now installs sources
On 8/16/19 3:52 PM, Rozhuk Ivan wrote: > On Fri, 16 Aug 2019 15:40:24 -0700 > I use better way: > /etc/make.conf: > # Modules to build with kernel. > PORTS_MODULES+= graphics/drm-fbsd12.0-kmod graphics/gpu-firmware-kmod This doesn't work for folks who use pre-built packages. -- John Baldwin ___ freebsd-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: HEADSUP: drm-current-kmod now installs sources
On August 16, 2019 4:32:18 PM PDT, "Rodney W. Grimes" wrote: >> On Fri, 16 Aug 2019 15:40:24 -0700 >> Cy Schubert wrote: >> >> > On August 16, 2019 2:51:22 PM PDT, "Rodney W. Grimes" >> > wrote: >> > >> On 8/14/19 3:40 PM, Daniel Eischen wrote: >> > >> > I've lost the original thread, but would the sources in >> > >/usr/local/sys/modules get built regardless of what >MAKEOBJDIRPREFIX >> > >is? And, now that sources may be installed by a port, what is the >> > >method for _just_ updating the sources? Why do I even need to >build >> > >and install the port? Personally, I would just rather have the >> > >drm-kmod sources just imported into base and maintained there. If >I >> > >have 2 or more different checked out base src trees, how do I get >the >> > >correct drm-kmod to go with them if there is only one >> > >/usr/local/sys/modules? Do I need multiple port trees just to >pull >> > >in out of tree module sources? >> > >> >> > >> In some ways, installing sources for DRM is a compromise for the >> > >> fact >> > >that we >> > >> can't have DRM in the base source anymore (for various reasons). > >> > >However, >> > >> virtualbox is also probably in that camp as well. >> > > >> > >I applaud this effort to provide a source compile mode for DRM, >> > >but I think it has come up a bit short on execution with numorious >> > >problems sited. >> > > >> > >I too am not real happy that /usr/local/src is going to get >> > >automatically invoked from my some odd 10+ src trees that >> > >are of various WIP's. I need a way to easily disable this >> > >both on a global scale, and on a per src tree way. >> > > >> > >Rather than a default to on with an opt out mechanism perhaps >> > >while we gain experience change this to a default to off with >> > >an opt in mechanism? >> > > >> > >Sadly I do not have proposed solution, but something better >> > >than what is there now needs to be found. >> > > >> > >Regards, >> > >> > Could we have a .src.conf in the root of the tree to configure this >> > on a tree by tree basis? >> > >> > >> >> >> I use better way: >> /etc/make.conf: > >That file is global to all src trees, >so that does not achive the desired effect. > >> # Modules to build with kernel. >> PORTS_MODULES+= graphics/drm-fbsd12.0-kmod graphics/gpu-firmware-kmod > >Can we some how trigger that from either a kernel conf file, >or at least on a per src tree basis? Ala cy's .src.conf? > >> + >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237290 > >I do like the patch that makes these go into the obj dir, good stuff! Presently we can use $SRCCONF. It's a PITA. .src.conf would override any preexisting variables. We could expand the concept to look in ~/.src.conf prior to $SRCTOP/.src.conf. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-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: HEADSUP: drm-current-kmod now installs sources
On Fri, 16 Aug 2019 17:23:08 -0700 John Baldwin wrote: > > I use better way: > > /etc/make.conf: > > # Modules to build with kernel. > > PORTS_MODULES+= graphics/drm-fbsd12.0-kmod > > graphics/gpu-firmware-kmod > > This doesn't work for folks who use pre-built packages. > I update mine /usr/src via rsync from other mine server, so any changes made by port or me or ... will lost. Probably there is must be some solution like special folder where ports can store some file with port name, that automaticly go to PORTS_MODULES on build kernel. And probably pkg can do with this something for "folks who use pre-built packages". ___ freebsd-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: HEADSUP: drm-current-kmod now installs sources
On 8/16/19 2:51 PM, Rodney W. Grimes wrote: >> On 8/14/19 3:40 PM, Daniel Eischen wrote: >>> I've lost the original thread, but would the sources in >>> /usr/local/sys/modules get built regardless of what MAKEOBJDIRPREFIX is? >>> And, now that sources may be installed by a port, what is the method for >>> _just_ updating the sources? Why do I even need to build and install the >>> port? Personally, I would just rather have the drm-kmod sources just >>> imported into base and maintained there. If I have 2 or more different >>> checked out base src trees, how do I get the correct drm-kmod to go with >>> them if there is only one /usr/local/sys/modules? Do I need multiple port >>> trees just to pull in out of tree module sources? >> >> In some ways, installing sources for DRM is a compromise for the fact that we >> can't have DRM in the base source anymore (for various reasons). However, >> virtualbox is also probably in that camp as well. > > I applaud this effort to provide a source compile mode for DRM, > but I think it has come up a bit short on execution with numorious > problems sited. Do you have a reported problem vs a theoretical problem? The only reported problem I've seen is that LOCAL_MODULES="" doesn't work. That and Cy reported a build error from a recent commit to head due to LOCAL_MODULES working as intended. > I too am not real happy that /usr/local/src is going to get > automatically invoked from my some odd 10+ src trees that > are of various WIP's. I need a way to easily disable this > both on a global scale, and on a per src tree way. Modulo the LOCAL_MODULES="" not working (you have to just use LOCAL_MODULES=) this already exists. You can set it in /etc/src.conf, in a kernel config, or on the command line. > Rather than a default to on with an opt out mechanism perhaps > while we gain experience change this to a default to off with > an opt in mechanism? It's head, not stable. We can't gain experience with something that isn't turned on. -- John Baldwin ___ freebsd-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: problem with LOCAL_MODULES
On 8/16/19 3:05 AM, Gary Jennejohn wrote:
> I tried to build a kernel today and it failed in modules-all even
> though I had LOCAL_MODULES="" in /etc/src.conf, as recommended by
> jhb.
>
> That's wrong. It has to be LOCAL_MODULES=, otherwise
> /sys/conf/kern.post.mk seems to conclude that there should be a
> module under /usr/local/sys/modules with the name "".
I think this will permit both versions to work:
Index: sys/conf/kern.post.mk
===
--- kern.post.mk(revision 351151)
+++ kern.post.mk(working copy)
@@ -76,6 +76,7 @@ modules-${target}:
cd $S/modules; ${MKMODULESENV} ${MAKE} \
${target:S/^reinstall$/install/:S/^clobber$/cleandir/}
.endif
+.if !empty(LOCAL_MODULES)
.for module in ${LOCAL_MODULES}
@${ECHODIR} "===> ${module}
(${target:S/^reinstall$/install/:S/^clobber$/cleandir/})"
@cd ${LOCAL_MODULES_DIR}/${module}; ${MKMODULESENV} ${MAKE} \
@@ -83,6 +84,7 @@ modules-${target}:
${target:S/^reinstall$/install/:S/^clobber$/cleandir/}
.endfor
.endif
+.endif
.endfor
# Handle ports (as defined by the user) that build kernel modules
--
John Baldwin
___
freebsd-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: HEADSUP: drm-current-kmod now installs sources
On Fri, Aug 16, 2019 at 6:37 PM John Baldwin wrote: > On 8/16/19 2:51 PM, Rodney W. Grimes wrote: > >> On 8/14/19 3:40 PM, Daniel Eischen wrote: > >>> I've lost the original thread, but would the sources in > /usr/local/sys/modules get built regardless of what MAKEOBJDIRPREFIX is? > And, now that sources may be installed by a port, what is the method for > _just_ updating the sources? Why do I even need to build and install the > port? Personally, I would just rather have the drm-kmod sources just > imported into base and maintained there. If I have 2 or more different > checked out base src trees, how do I get the correct drm-kmod to go with > them if there is only one /usr/local/sys/modules? Do I need multiple port > trees just to pull in out of tree module sources? > >> > >> In some ways, installing sources for DRM is a compromise for the fact > that we > >> can't have DRM in the base source anymore (for various reasons). > However, > >> virtualbox is also probably in that camp as well. > > > > I applaud this effort to provide a source compile mode for DRM, > > but I think it has come up a bit short on execution with numorious > > problems sited. > > Do you have a reported problem vs a theoretical problem? The > only reported problem I've seen is that LOCAL_MODULES="" doesn't > work. That and Cy reported a build error from a recent commit to > head due to LOCAL_MODULES working as intended. > And once it's working like it is supposed too, you can override it on a per-tree basis. But it needs to be on by default to avoid POLA. > > I too am not real happy that /usr/local/src is going to get > > automatically invoked from my some odd 10+ src trees that > > are of various WIP's. I need a way to easily disable this > > both on a global scale, and on a per src tree way. > > Modulo the LOCAL_MODULES="" not working (you have to just use > LOCAL_MODULES=) this already exists. You can set it in > /etc/src.conf, in a kernel config, or on the command line. > You can also per-tree settings on a src.conf if you want. Nanobsd overrides /etc/src.conf and others to set per-build defaults that are reproducible w/o host contamination, for example. We have half a dozen mechanisms for managing per-tree settings. > > Rather than a default to on with an opt out mechanism perhaps > > while we gain experience change this to a default to off with > > an opt in mechanism? > > It's head, not stable. We can't gain experience with something > that isn't turned Turned off by default violates POLA for people that pkg install the drm stuff. They expect it to just work, even if they rebuild the kernel. So for at least the non-cross-build cases, it should be on by default. People with special needs, like 10 trees, will have to tweak their defaults. We cannot set the defaults based on that. Most developers have one or two trees and can easily manage when they are building stuff for other systems, jail images, etc on a case by case basis. 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"
head -r351153 amd64 upgrade installworld failure: realinstall_subdir_stand got: 'sh: cc: not found' (a race?)
The below installworld material was after an apparently successful buildworld buildkernel then installkernel . Wrong stage for a cc producing loader_lua.sym ? (This was a normal, system-clang based build context, attempting an upgrade from head -r351102 .) --- realinstall_subdir_stand --- cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp -B/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -I/usr/src/stand/i386/btx/lib -nostdinc -I/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/stand/libsa32 -I/usr/src/stand/libsa -D_STANDALONE -I/usr/src/sys -Ddouble=jagged-little-pill -Dfloat=floaty-mcfloatface -DLOADER_GELI_SUPPORT -I/usr/src/stand/libsa/geli -DLOADER_DISK_SUPPORT -m32 -ffreestanding -mno-mmx -mno-sse -mno-avx -mno-avx2 -msoft-float -march=i386 -I. -I/usr/src/stand/common -I/usr/src/contrib/lua/src -I/usr/src/stand/common -I/usr/src/stand/liblua -DLUA_FLOAT_TYPE=LUA_FLOAT_INT64 -DLOADER_CD9660_SUPPORT -DLOADER_EXT2FS_SUPPORT -DLOADER_MSDOS_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_BZIP2_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DLOADER_GPT_SUPPORT -DLOADER_MBR_SUPPORT -DLOADER_ZFS_SUPPORT -I/usr/src/stand/libsa/zfs -I/usr/src/sys/cddl /boot/zfs -Wall -I/usr/src--- realinstall_subdir_usr.sbin --- . . . --- realinstall_subdir_stand --- /stand/i386 -DLOADER_PREFER_AMD64 -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Oz -Qunused-arguments ERROR-tried-to-rebuild-during-make-install -nostdlib -static -Ttext 0x0 -Wl,--no-threads -Wl,--no-rosegment -o loader_lua.sym /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/stand/i386/btx/lib/crt0.o main.o conf.o vers.o chain.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o interp_parse.o ls.o misc.o module.o load_elf32.o load_elf32_obj.o reloc_elf32.o load_elf64.o load_elf64_obj.o reloc_elf64.o disk.o part.o vdisk.o dev_net.o bcache.o isapnp.o pnp.o interp_lua.o zfs_cmd.o /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/stand/ liblua32/liblua.a /usr/ob--- realinstall_subdir_share --- . . . --- realinstall_subdir_stand --- j/amd64_clang/amd64.amd64/usr/src/amd64.amd64/stand/i386/libi386/libi386.a /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/stand/libsa32/libsa32.a --- realinstall_subdir_tests --- . . . --- realinstall_subdir_stand --- sh: cc: not found Repeating buildworld buildkernel and then trying installworld (without the -j28 I had used originally) completed. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
amd64 head -r351153 self-built but via devel/llvm90: 'objcopy: elf_update() failed: Layout constraint violation' for gptboot.bin
I upgraded to head -r351153 and then attempted a buildworld buildkernel via devel/llvm90 (rc2 via ports head -r509054), but that (from scratch) build attempt got: --- gptboot.bin --- objcopy: elf_update() failed: Layout constraint violation *** [gptboot.bin] Error code 1 make[5]: *** gptboot.bin removed make[5]: stopped in /usr/src/stand/i386/gptboot .ERROR_TARGET='gptboot.bin' .ERROR_META_FILE='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/stand/i386/gptboot/gptboot.bin.meta' .MAKE.LEVEL='5' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' _ERROR_CMD='objcopy -S -O binary gptboot.out gptboot.bin;' .CURDIR='/usr/src/stand/i386/gptboot' .MAKE='make' .OBJDIR='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/stand/i386/gptboot' .TARGETS='all' DESTDIR='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MAKEOBJDIRPREFIX='' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20181221' PATH='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/bin::/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64' .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /root/src.configs/src.conf.amd64-xtoolchain-llvm.amd64-host /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /dev/null /usr/src/stand/i386/gptboot/Makefile /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk /usr/src/stand/i386/gptboot/../Makefile.inc /usr/src/share/mk/bsd.linker.mk /usr/src/stand/i386/gptboot/../../Makefile.inc /usr/src/stand/i386/gptboot/../../defs.mk /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.prog.mk /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/bsd.nl s.mk /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.mk /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' .PATH='. /usr/src/stand/i386/gptboot /usr/src/stand/i386/boot2 /usr/src/stand/i386/common /usr/src/stand/libsa' 1 error === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-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: should lseek(SEEK_DATA/SEEK_HOLE) return ENOTTY?
Ian Lepore wrote: >On Sun, 2019-08-11 at 09:12 -0600, Alan Somers wrote: >> On Sun, Aug 11, 2019 at 8:57 AM Ian Lepore wrote: >> > >> > On Sun, 2019-08-11 at 09:04 +0200, Gary Jennejohn wrote: >> > > On Sun, 11 Aug 2019 02:03:10 + >> > > Rick Macklem wrote: >> > > >> > > > Hi, >> > > > >> > > > I've noticed that, if you do a lseek(SEEK_DATA/SEEK_HOLE) on a >> > > > file >> > > > that >> > > > resides in a file system that does not support holes, ENOTTY is >> > > > returned. >> > > > >> > > > This error isn't listed for lseek() and seems a liitle weird. >> > > > >> > > >> > > ENOTTY is the standard error return for an unimplemented >> > > ioctl(2), >> > > and SEEK_HOLE ultimately becomes a call to fo_ioctl(). >> > > >> > > > I can see a couple of alternatives to this: >> > > > 1 - Return a different error. Maybe ENXIO? >> > > > or >> > > > 2 - Have lseek() do the trivial implementation when the >> > > > VOP_IOCTL() >> > > > fails. >> > > >- For SEEK_DATA, just return the offset given as argument >> > > > and >> > > > for SEEK_HOLE >> > > > return the file's size as the offset. >> > > > >> > > > What do others think? rick >> > > > ps: The man page should be updated, whatever is done w.r.t. >> > > > this. >> > > > >> > > >> > > I also vote for option 2 >> > > >> > >> > If SEEK_DATA and SEEK_HOLE don't return the standard "ioctl not >> > supported" error code and return a fake result, how are you >> > supposed to >> > determine at runtime whether SEEK_HOLE is supported or not? >> > >> > -- Ian >> >> pathconf(2) will tell you. >> > >Ahh, I wasn't aware of that. > >For option 2, lseek() has to not just return the info, but must also >actually set the file position accordingly, and has to treat offset >= >filesize as an error. I have put a patch for this at https://reviews.freebsd.org/D21299 I listed markj@ as a reviewer, but anyone is welcome to review it, if they'd like. Since vn_bmap_seekhole() can return ENOTTY, the above patch follows that convention as well. I also have a trivial patch to map errnos not specified for lseek() to EINVAL. https://reviews.freebsd.org/D21300. Ditto above w.r.t. to reviewing it. rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
