. Hartmann
See so@'s answer from a couple days ago:
https://lists.freebsd.org/archives/freebsd-security/2024-March/000248.html
TL;DR no
Thanks,
Kyle Evans
-u2f thing, much less in a way that we care
about.
Thanks,
Kyle Evans
something.
Thanks,
Kyle Evans
[0]
https://github.com/ventoy/Ventoy/tree/master/Unix/ventoy_unix_src/FreeBSD/geom_ventoy_src
On 10/12/23 00:08, Mark Millard wrote:
Kyle Evans wrote on
Date: Thu, 12 Oct 2023 02:54:13 UTC :
The branch main has been updated by kevans:
URL:
https://cgit.FreeBSD.org/src/commit/?id=989c5f6da99081b1f2b76ec09e91078e531e1250
commit 989c5f6da99081b1f2b76ec09e91078e531e1250
Author: Kyle
On 9/29/23 15:37, Kyle Evans wrote:
On 9/29/23 13:25, Jamie Landeg-Jones wrote:
Jamie Landeg-Jones wrote:
Brilliant! Thanks for the quick response and fix. It works fine for me -
I've not managed to break it again :-)
Famous last words
"grep -v" now produces duplicate
the vflag
because we already terminated in the first printline().
It also removes the offending code that made me overlook that scenario.
Thanks,
Kyle Evans
On 9/27/23 22:34, Greg 'groggy' Lehey wrote:
On Wednesday, 27 September 2023 at 22:30:43 -0500, Kyle Evans wrote:
On 9/27/23 21:40, Jamie Landeg-Jones wrote:
When using color=always and a regex of '.' (for example), output lines
are duplicated.
$ grep --version
grep (BSD grep, GNU compatible
again + terminate
again.
Thanks,
Kyle Evans
On 8/29/23 14:15, Felix Palmen wrote:
* Kyle Evans [20230829 14:07]:
On 8/29/23 14:02, Shawn Webb wrote:
Back in 2019, I had a similar issue: I needed access to be able to
read/write to the system extended attribute namespace from within a
jailed context. I wrote a rather simple patch
's useful to someone.
Thanks,
FWIW (which likely isn't much), I like this approach much better; it
makes more sense to me that it's a feature controlled by the creator of
the jail and not one allowed just by using a compat ABI within a jail.
Thanks,
Kyle Evans
This error indicates that for some reason we're trying to build during
the install phase; either tree was updated since last build, messed up
timestamps on build artifacts, messed up clock, etc. Whatever the case
may be, make(1) sees the build output of this as out-of-date.
Thanks,
Kyle Evans
On Sat, Apr 8, 2023 at 5:24 AM Mateusz Guzik wrote:
>
> On 4/8/23, Kyle Evans wrote:
> > On Fri, Apr 7, 2023 at 4:54 PM Mateusz Guzik wrote:
> >>
> >> On 4/7/23, Mark Millard wrote:
> >> > On Apr 7, 2023, at 14:26, Mateusz Guzik wrote:
>
8de23c22bde/arm64/aarch64/kernel.txz
> >
> > (No artifact build was exactly at either of your commits.)
> >
> > ===
> > Mark Millard
> > marklmi at yahoo.com
> >
> >
>
> I have arm64 + zfs at $job and just verified the above lets it boot
> again, so I committed already.
>
This was a known issue that we were working on fixing properly over in
https://reviews.freebsd.org/D39448... this really could have waited
just a little bit longer. This problem was already brought up in
response to the commit in question days ago.
Thanks,
Kyle Evans
te/d_read need the uio accounting updated to reflect how
much data was written/read, it doesn't want to assume you were able to
do everything in a single call.
Thanks,
Kyle Evans
kernel.old/kernel
>
> Looks wrong to me. (I've never explicitly assigned to kern.bootfile .)
>
The usual suspect here is that you did an `installkernel` -- if it
replaces kern.bootfile, it moves the old kern.bootfile to
/boot/kernel.old and updates the sysctl to reflect the new location so
that it still accurately reflects the booted kernel.
Thanks,
Kyle Evans
On Tue, Aug 23, 2022 at 2:44 PM Peter Jeremy wrote:
>
> On 2022-Aug-23 15:19:34 +0200, Ronald Klop wrote:
> >Van: Kyle Evans
> >> I was not aware that beadm touches loader.conf, but I find that
> >> slightly horrifying. I won't personally make bectl do that, but
On Mon, Aug 22, 2022 at 5:10 AM Ronald Klop wrote:
>
>
>
> Van: Peter Jeremy
> Datum: maandag, 22 augustus 2022 10:45
> Aan: "Patrick M. Hausen"
> CC: Ryan Moeller , freebsd-current@freebsd.org
> Onderwerp: Re: Beadm can't create snapshot
>
> On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen"
On Thu, Jul 7, 2022 at 10:01 AM Steve Kargl
wrote:
>
> On Thu, Jul 07, 2022 at 10:37:40AM -0600, Warner Losh wrote:
> > On Thu, Jul 7, 2022 at 10:37 AM Steve Kargl <
> > s...@troutmask.apl.washington.edu> wrote:
> >
> > > Thanks, but
> > >
> > > root[216] git cherry-pick -n 37f604b49d4a
> > >
tudent eligible for
GSoC is able to propose ideas (regardless of whether we've pitched the
ideas on our wiki or not).
Thanks,
Kyle Evans
>
> On Sat, Apr 16, 2022 at 7:26 PM Julian H. Stacey wrote:
>>
>> > okay...
>> > all seems very time consuming operations!!
>>
On Wed, Feb 2, 2022 at 10:50 AM Kyle Evans wrote:
>
> On Wed, Feb 2, 2022 at 3:41 AM Jesper Schmitz Mouridsen
> wrote:
> >
> >
> >
> > On 31.01.2022 22.20, Mark Millard wrote:
> > > Mike Karels wrote on
> > > Date: Mon, 31 Jan 2022 12:27:41 -
On Wed, Feb 2, 2022 at 3:41 AM Jesper Schmitz Mouridsen
wrote:
>
>
>
> On 31.01.2022 22.20, Mark Millard wrote:
> > Mike Karels wrote on
> > Date: Mon, 31 Jan 2022 12:27:41 -0600 :
> >
> >> A bisect
> >> would be rather laborious, building a modified SD card each time,
> >> even if just testing
Where did this ecpubkey.pem come from?
On Tue, Dec 7, 2021, 15:28 Larry Rosenman wrote:
>
> --
> >>> Installing everything completed on Tue Dec 7 15:23:33 CST 2021
> --
>
On Wed, Dec 1, 2021 at 8:05 PM John-Mark Gurney wrote:
>
> Hello,
>
> It seems like the recent changes to make --no-allow-shlib-undefined
> broke pructl.
>
> lib/libc/stdlib/atexit.c uses a weak _Block_copy symbol, but
> pructl does not use atexit_b, and yet gets the following error:
> : &&
On Sun, Oct 10, 2021 at 12:18 AM Warner Losh wrote:
>
> On Sat, Oct 9, 2021 at 10:45 PM Warner Losh wrote:
>
> >
> >
> > On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin
> > wrote:
> >
> >> On Sun, Oct 10, 2021 at 06:06:37AM +0200, Baptiste Daroussin wrote:
> >> > On Sun, Oct 10, 2021 at
n Fri, Apr 16, 2021 at 11:36 AM Rainer Hurling wrote:
>
> While viewing sys/sys/param.h I noticed that the comment of the
> definition of __FreeBSD_version is probably out of date.
>
> Since the switch to Git, doesn't it have to be 'main' instead of 'master'?
>
This isn't based on a branch name,
On Wed, Mar 31, 2021 at 7:25 AM Ronald Klop wrote:
>
>
> Van: Jochen Neumeister
> Datum: woensdag, 31 maart 2021 13:26
> Aan: Christoph Moench-Tegeder ,
> freebsd-current@freebsd.org
> Onderwerp: Re: Blacklisted certificates
> >
> >
> > Am 31.03.21 um 13:02 schrieb Christoph Moench-Tegeder:
> >
ully pointed out to me attempts to use KASSERT
> without having it defined.
>
> So: Is DIAGNOSTIC intended to necessarily imply that KASSERT is
> available for use?
>
This is fixed in ff92a03616c5, thanks for the report!
Kyle Evans
___
fre
On Mon, Mar 8, 2021 at 10:51 AM Yasuhiro Kimura wrote:
>
> From: Yasuhiro Kimura
> Subject: Re: Waiting for bufdaemon
> Date: Tue, 09 Mar 2021 00:57:32 +0900 (JST)
>
> > But still one question remains. Why have the value of
> > kern.timecounter.hardware and kern.timecounter.tc.ACPI-fast.counter
On Sat, Mar 6, 2021 at 4:02 AM Yasuhiro Kimura wrote:
>
> From: Yasuhiro Kimura
> Subject: Re: Waiting for bufdaemon
> Date: Sat, 06 Mar 2021 08:33:23 +0900 (JST)
>
> >> My belief is that this commit helps more users than it hurts. Namely,
> >> the VMWare and KVM users, which are majority, use
On Tue, Feb 16, 2021 at 7:29 PM Kyle Evans wrote:
>
> On Tue, Feb 16, 2021 at 7:23 PM Mark Millard via freebsd-current
> wrote:
> >
> > I historically on occasion have done something like:
> >
> > # grep -rI ... /
> >
> > in order to find all inst
On Tue, Feb 16, 2021 at 7:23 PM Mark Millard via freebsd-current
wrote:
>
> I historically on occasion have done something like:
>
> # grep -rI ... /
>
> in order to find all instances of a text, including
> in build trees and such. I now find that I need to
> do something more like (using a more
fined symbol: hid_is_mouse
> >>> referenced by ukbd.c:958 (/usr/src/sys/dev/usb/input/ukbd.c:958)
> >>> ukbd.o:(ukbd_probe)
> ...
Hi,
ukbd recently grew a dependency on the newly split uhid module. See
the 20210107 UPDATING entry for resolution.
On Tue, Dec 8, 2020 at 9:48 AM Mark Johnston wrote:
>
> On Tue, Dec 08, 2020 at 09:39:05AM -0600, Kyle Evans wrote:
> > On Tue, Dec 8, 2020 at 9:30 AM Mark Johnston wrote:
> > > kern_proc_filedesc_out() holds the fdtable shared lock thoughout all of
> > > this
On Tue, Dec 8, 2020 at 9:30 AM Mark Johnston wrote:
>
> On Tue, Dec 08, 2020 at 12:47:18PM +0100, Peter Holm wrote:
> > I just got this panic:
> >
> > Fatal trap 9: general protection fault while in kernel mode
> > cpuid = 9; apic id = 09
> > instruction pointer = 0x20:0x80bc6e22
> >
) on ZFS.
Tossing arichardson@ into CC as the committer
Tossing mmacy@ and freqlabs@ into CC as ZFS folks
Looking through sys/contrib/openzfs, there's special handling for mmap
on linux because it bypasses the page cache and relies on caching in
ARC. AFAICT the FreeBSD side seems to handle write
kdb_enter+0x37: movq $0,0x1fa9446(%rip)
> > > db>
> >
> > This looks like SMEP catching an issue, but it is not clear why.
>
> Probably fixed by r367783? The bug would have partially overwritten the
> stack frame, resulting in a jump to a user address
On Sun, Nov 15, 2020 at 2:05 PM Stefan Esser wrote:
>
> Am 15.11.20 um 20:41 schrieb Kyle Evans:
> > This is a separate (valid) problem, but not directly related to
> > Scott's work here. sysctlbyname now goes directly to the kernel with
> > no chance for the use
>
This is a separate (valid) problem, but not directly related to
Scott's work here. sysctlbyname now goes directly to the kernel with
no chance for the user.* sysctls to intercept. That should
independently be fixed to maintain the illusion that they're real
sysctl's.
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"
On Mon, Oct 5, 2020 at 9:54 AM Kyle Evans wrote:
>
> On Sun, Oct 4, 2020 at 11:55 PM Hartmann, O. wrote:
> >
> > For a couple of weeks now cross-compiling 12-STBALE on CURRENT fails
> > due to an compiler error in bin/cp/utils.c, see details below.
> >
> > A
hat shouldn't be the case on stable/12. It's clearly trying to
rebuild it into the src tree in the same way, though:
[/pool/sources/12-STABLE/src/bin/cp/utils.o] Error code 1
This is interesting, but I'm afraid I don't know the nanobsd build
well enough to
On Thu, Sep 17, 2020 at 4:15 PM Christian Weisgerber wrote:
>
> Kyle Evans:
>
> > > FWIW, I just committed a Got port (devel/got).
> >
> > This is probably better for a separate thread, but any idea if there
> > are plans to eventually support local filesystem
>
This is probably better for a separate thread, but any idea if there
are plans to eventually support local filesystem cloning in got?
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
e i've done to this system
> since the import of openzfs code, and iocage was operating without
> issues previously. i am wondering does iocage need to be rebuild
> against newer sources or did something else change recently?
>
Hi,
You'll need a ports tree >= r548105
On Sat, Sep 12, 2020 at 7:55 AM Mark Murray wrote:
>
> On 12 Sep 2020, at 12:18, Eric McCorkle wrote:
> >
> > I recently updated my other laptop, and now I'm getting a problem
> > loading zfs.ko at boot, relating to the lockstat_enabled symbol not
> > being defined (this happens during kernel
On Thu, Jul 30, 2020 at 2:48 PM David Wolfskill wrote:
>
> On Thu, Jul 30, 2020 at 06:46:40AM -0500, Kyle Evans wrote:
> > On Thu, Jul 30, 2020 at 6:24 AM David Wolfskill
> > wrote:
> > ...
> > > ld-elf.so.1: /common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/s
stallworld injects .WAIT between lib and
libexec + other subdirs, which is supposed to prevent stuff like this
(new binary got installed linked against new libc before new libc).
Running in a buildenv set SYSROOT and stripped out the .WAITs, leaving
me with an annoyance where I had to installworld
On Fri, Jul 24, 2020 at 3:24 PM Kyle Evans wrote:
>
> Hello!
>
> Just a little bit ago, I committed an update[0] to the valgrind-devel
> port that updates it to Paul Floyd's branch, where he has rebased us
> forward to 3.17.0 and largely fixed valgrind operation on both 1
on
FreeBSD, the status of which is summarized here:
- https://github.com/paulfloyd/freebsd_valgrind/wiki/Regtest-status
Some outstanding issues:
- https://github.com/paulfloyd/freebsd_valgrind/issues
Please go forth and test it!
Thanks,
Kyle Evans
[0] https://svnweb.freebsd.org/changeset/ports/543273
hat my loader.conf's needed a good s/vfs.zfs.arc_max/vfs.zfs.arc.max/
but I'm told a compat sysctl is on the TODO list to ease the
transition.
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/fre
ly
common need is represented. The (light-hearted?) self-deprecation near
the end of this makes me a bit uneasy- I certainly hope you didn't
feel like it was mandatory to acknowledge that he's a developer and
you're a hobbyist, because there's most assuredly more hobbyists (such
as myself) lurking with sim
ting
> of filesystems.
>
I seem to recall that you use or experiment with pkgbase -- double
check that pkg hasn't left *.pkgnew in your /etc/rc.d. These will
cause double processing.
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing lis
el "alias" hardlink, you get a panic.
>
> E.G:
>
> # ifconfig tun create name tun1
> # ifcondif tun create
>
> [... snip ...]
Whoops, good catch. =-( Will fix ASAP.
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mail
east transcribe the initial part of the panic message?
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"
odd
setup that I can never remember. For legacy setups, the bootpool
can/should be merged into your root pool if it's feasible.
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"
On Sun, Mar 29, 2020 at 10:16 PM Rebecca Cran wrote:
>
>
> > On Mar 29, 2020, at 9:11 PM, Nathan Whitehorn
> > wrote:
> >
> > The problem then is that we have treated loader as a
> > continuously-updatable part of the OS, like the kernel, and the update
> > system and development process
ct would just mean that
we have some tool that users use to update the ESP rather than
instructing them to examine/replace files manually.
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-
On Thu, Mar 19, 2020 at 12:11 PM Graham Perrin wrote:
>
> Is this maybe related to
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244847 or should I
> make a separate bug report?
>
Please throw a tentative "Me too" on that PR; I'm investigating it,
then we'll see if they're related or
On Fri, Feb 21, 2020 at 3:27 AM Pavel Timofeev wrote:
>
> пт, 10 янв. 2020 г. в 22:05, Kyle Evans :
> >
> > On Fri, Jan 10, 2020 at 12:59 PM Pavel Timofeev wrote:
> > >
> > > пт, 10 янв. 2020 г. в 17:48, Kyle Evans :
> > > >
> > > > On
a,
Can you scroll up and grab a bit more context? This excerpt is still
in the process of cascading errors, so there's not much telling what
caused it.
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"
lag when I am not using them for a
> while. I've adjusted time and started ntpd. In the past that would not fix
> the time lag permanently.
>
> I'll do a fresh buildworld and see whether that completes.
>
I mentioned this elsewhere, but I've opened a revie
(Resend because I suck at e-mail; sorry Marek)
On Tue, Jan 28, 2020 at 5:42 PM Marek Zarychta
wrote:
>
> W dniu 28.01.2020 o 22:28, Kyle Evans pisze:
> > On Tue, Jan 28, 2020 at 2:15 PM Mark Millard wrote:
> >>
> >> Marek Zarychta zarychtam at plan-b.pwste.edu.pl
On Tue, Jan 28, 2020 at 3:28 PM Kyle Evans wrote:
>
> On Tue, Jan 28, 2020 at 2:15 PM Mark Millard wrote:
> >
> > Marek Zarychta zarychtam at plan-b.pwste.edu.pl wrote on
> > Tue Jan 28 19:33:45 UTC 2020 :
> >
> > > W dniu 28.01.2020 o 19:11, Dimitry Andr
On Tue, Jan 28, 2020 at 2:15 PM Mark Millard wrote:
>
> Marek Zarychta zarychtam at plan-b.pwste.edu.pl wrote on
> Tue Jan 28 19:33:45 UTC 2020 :
>
> > W dniu 28.01.2020 o 19:11, Dimitry Andric pisze:
> > > On 28 Jan 2020, at 12:36, Nick Hibma wrote:
> > >>
> > >> Could anyone explain to me what
On Fri, Jan 10, 2020 at 12:59 PM Pavel Timofeev wrote:
>
> пт, 10 янв. 2020 г. в 17:48, Kyle Evans :
> >
> > On Fri, Jan 10, 2020 at 12:31 AM Pavel Timofeev wrote:
> > >
> > > чт, 9 янв. 2020 г. в 16:52, Pavel Timofeev :
> > > >
> > >
d be clear after r356602, but you'll need to
build WITHOUT_GOOGLETEST=yes for now with the gcc ports. There are
some fundamental issues with mips-gcc{6,9} trying to emit
__floatunsidf references, but that's a hidden symbol in our libgcc.
I expect to, by the end of the day, either have a fix pending
ce: flua is built as
bootstrap on older versions, so it will get built with bootstrap or
buildworld targets and MAKEOBJDIRPREFIX of sysent target must match
what bootstrap/world was built with. I'll MFC flua itself within the
next couple of days to make the process easier o
he KASSERT did not use sc either.
>
>
Whoops, sorry about that! Fixed in r355031.
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"
to build a kernel as described and put up for you to
download, as well, if you'd accept that.
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"
=2019-10-02%2001%3A20%3A14
>
Just to follow up with this for list' sake; this was fixed by r352952.
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"
that manu's recently tagged for
inclusion into a package to backup-and-restore manually around the
upgrade for the time being, but the PR will be resolved in due time.
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebs
quot;XXX A drm-current-kmod 2 /usr/local 3 drm-current-kmod 4 "
> >
> > suggestions welcome...
>
> (CCing Kyle)
>
> This behavior change is probably caused by r351799.
>
> I personally think the code before Kyle’s change and after it was buggy. It’s
> no
On Fri, Aug 30, 2019 at 2:26 PM Kyle Evans wrote:
>
> On Fri, Aug 30, 2019 at 2:11 PM John Baldwin wrote:
> >
> > On 8/30/19 10:42 AM, Kyle Evans wrote:
> > > On Fri, Aug 16, 2019 at 7:38 PM John Baldwin wrote:
> > >>
> > >> On 8/16/19 3:05
On Fri, Aug 30, 2019 at 2:11 PM John Baldwin wrote:
>
> On 8/30/19 10:42 AM, Kyle Evans wrote:
> > On Fri, Aug 16, 2019 at 7:38 PM John Baldwin wrote:
> >>
> >> On 8/16/19 3:05 AM, Gary Jennejohn wrote:
> >>> I tried to build a kernel today and it fai
with !empty(LOCAL_MODULES) &&
EXISTS(${LOCAL_MODULES_DIR}) or maybe just the latter condition to
prevent accidental foot-shooting... I was testing a problem with doing
this stuff in a poudriere build for swills@ and set LOCAL_MODULES=""
only to get an error because LOCAL_MODULES_DIR doesn't
rc/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
On Wed, Aug 14, 2019 at 1:04 PM Ian Lepore wrote:
>
> On Wed, 2019-08-14 at 19:55 +0200, Niclas Zeising wrote:
> > On 2019-08-14 19:23, Emmanuel Vadot wrote:
> > > On Wed, 14 Aug 2019 10:13:48 -0700
> > > John Baldwin wrote:
> > >
> > > > On 8/14/19 9:22 AM, Ian Lepore wrote:
> > > > > This all
On Tue, May 14, 2019 at 10:34 AM Kyle Evans wrote:
>
> On Tue, May 14, 2019 at 10:10 AM Mark Johnston wrote:
> >
> > Hi,
> >
> > I hit the following panic last night on a non-INVARIANTS kernel at
> > r347549. The workload involves running a number of bhyve VM
On Tue, May 14, 2019 at 10:10 AM Mark Johnston wrote:
>
> Hi,
>
> I hit the following panic last night on a non-INVARIANTS kernel at
> r347549. The workload involves running a number of bhyve VMs with
> frequent restarts, during which a tap interface is destroyed and
> recreated. I'm a bit
On Thu, May 9, 2019 at 8:27 AM Michael Butler
wrote:
>
> On 2019-05-09 09:07, Kyle Evans wrote:
> > On Thu, May 9, 2019 at 7:24 AM Michael Butler
> > wrote:
> >>
> >> Seems there's a lock or tuntap issue after recent changes. Restarting
> >> openvp
.org/~kevans/etherdetach.diff
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"
On Thu, May 2, 2019 at 11:42 AM Kyle Evans wrote:
>
> On Thu, May 2, 2019 at 11:40 AM Larry Rosenman wrote:
> >
> > On 05/02/2019 11:34 am, Larry Rosenman wrote:
> > > On 05/02/2019 11:10 am, Larry Rosenman wrote:
> > >> On 05/02/2019 10:58 am, Warner Losh
>> >
> >>>> >>> > BIOS or UEFI booting?
> >>>> >>>
> >>>> >>> UEFI boot.
> >>>> >>>
> >>>> >>
> >>>> >> So no change to \efi\boot\bootx64.efi (or whatever you a
On Thu, Apr 25, 2019 at 3:33 PM Michael Butler
wrote:
>
> Seems that the lib32 piece (on amd64) is now broken; as follows:
>
*sigh*
Strike two of three for me today, it seems. Should be fixed in
r346705... sorry about that, thanks for the report!
___
On Mon, Feb 25, 2019 at 8:18 PM Rebecca Cran wrote:
>
> I've been working on some EFI changes, and in the process found that
> i386 booting is broken. On real hardware - my MinnowBoard Turbot - the
> loader hangs when calling ExitBootServices, while in a VM I get a panic
> saying "exec returned".
On Mon, Feb 18, 2019 at 9:20 PM Graham Perrin wrote:
>
> On 19/02/2019 03:05, Kyle Evans wrote:
> > I'd be interested in seeing what happens when you apply this diff:
> > https://people.freebsd.org/~kevans/bectl-perf.diff
>
>
> Thanks, I'll let you know.
>
>
On Mon, Feb 18, 2019 at 8:34 PM Graham Perrin wrote:
>
> Preparing to update the OS, I created a new boot environment. Creation
> took a long time, subsequent bectl commands are extraordinarily slow.
>
> Whilst composing this e-mail I'm awaiting completion of a simple list.
>
> Any ideas?
>
>
required in directly, you'll need to run it
through config.load(). I intend to write up a wiki page or something
for converting common Forth-isms to either portable loader.conf(5)
directives or Lua-specific equivalents, depending on the feasibility
of the former.
Thanks,
Kyle Evans
On Fri, Jan 18, 2019 at 8:04 AM Olivier Cochard-Labbé
wrote:
>
> On Fri, Jan 18, 2019 at 2:10 PM Lev Serebryakov wrote:
>
> > On 18.01.2019 5:31, Rebecca Cran wrote:
> >
> >
> > > I was wondering if people will expect /boot.config to still be read and
> > so code should be added to loader to
On Wed, Nov 14, 2018 at 4:55 PM Subbsd wrote:
>
> On Thu, Nov 15, 2018 at 1:33 AM Kyle Evans wrote:
> >
> > On Wed, Nov 14, 2018 at 4:30 PM Kyle Evans wrote:
> > >
> > > On Wed, Nov 14, 2018 at 4:23 PM Subbsd wrote:
> > > >
>
On Wed, Nov 14, 2018 at 4:30 PM Kyle Evans wrote:
>
> On Wed, Nov 14, 2018 at 4:23 PM Subbsd wrote:
> >
> > On Thu, Nov 15, 2018 at 1:05 AM Subbsd wrote:
> > >
> > > On Thu, Nov 15, 2018 at 12:21 AM Rebecca Cran
> > > wrote:
> > > >
On Wed, Nov 14, 2018 at 4:23 PM Subbsd wrote:
>
> On Thu, Nov 15, 2018 at 1:05 AM Subbsd wrote:
> >
> > On Thu, Nov 15, 2018 at 12:21 AM Rebecca Cran wrote:
> > >
> > > On November 14, 2018 at 2:18:04 PM, Subbsd (sub...@gmail.com) wrote:
> > >>
> > >>
> > >> My current host: FreeBSD
On Tue, Nov 13, 2018 at 9:53 PM Rebecca Cran wrote:
>
> On Tuesday, 13 November 2018 18:57:25 MST Kyle Evans wrote:
>
> > However, because loader-land is funny in a not-ha-ha kind of way, can
> > you try replacing loader.efi on your guest VM with the Forth-flavored
> &g
r, because loader-land is funny in a not-ha-ha kind of way, can
you try replacing loader.efi on your guest VM with the Forth-flavored
version to rule that out or narrow it down, please?
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
ht
On Sat, Oct 27, 2018 at 10:49 AM Rebecca Cran wrote:
>
> When booting a recent 13-CURRENT installation, I’m seeing the following:
>
> Startup error in /boot/lua/loader.lua:
> LUA ERROR: /boot/lua/loader.lua:45: error loading module ‘local’ from file
> ‘/usr/local/lib/lua/5.3/local.so’:
>
, unfortunately- if
we didn't make uefi loader -> kernel transition, then we don't have
access to runtime services.
Thanks,
Kyle Evans
[0] https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.0/
On Tue, Oct 23, 2018 at 4:23 PM Harry Newton wrote:
>
> I set LOADER_DEFAULT_INTERP=4th
a000)
> [...]
>
> So, I do not have any Mellanox device, therefore I do not build nor install
> drivers
> and or modules (refering to the libmlx5.so.1).
>
You set WITHOUT_OFED=yes, right? That's a default now, so that'll stop
the dependency on ofed/ bits in libpcap. This is still
ly, there's the
> following:
>
> ...
> BootServicesData 7421d000 0a8b UC WC WT WB
> ...
> RuntimeServicesCode 7ab9f000 0070 UC WC WT WB
> ...
>
Hi,
I guess this patch might do it:
https://people.freebsd.org/~kevans/efi-bootmap.diff
Linux commit messages depict a tale in which they used to also only
map RUNTIME entries, but they were effectively forced to back down on
that because of buggy firmware that does exactly what you've described
and they later reintroduced the restrictive mapping for i386-only
where they'd not found such bugs.
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"
.
> Only _with_ 'OPTIONS EFIRT' enabled in the kernel _and_ deactivating it
> via efi.rt.disabled=1 in /boot/loader.conf, it works for me.
>
> An oddity is, that the spelling of the loader tuneable has to be
> efi.rt.disabled, not efi.rt_disabled (note the dot instead of an
>
xed for a few months now. Maybe some change needs to be adapted
> from the old to the new loader.
When you say "very slow" -- your autoboot counter is defaulting high,
or there's a perceptible longer-than-one-second delay between updates?
Thanks,
Kyle Evans
__
ake things out, so it's too late for this release I'm thinking. But
> if we do this after the freeze, then we're in good shape for having it in 13,
> or knowing why it's a bad idea.
>
I should probably have mentioned- the _loadflags solution is one I
feel comfortable with this late in the release cycle, but I would very
strongly prefer not to touch module_path in a stable branch (or
soon-to-be-stable branch) so that we have time to sort out the
ramifications for the odd-balls that depend on the current ordering
given its history. The ${kernel_path} override could allow something
like my described module_path change to happen in a stable branch, but
not for the upcoming release and any backport would most likely
involve changing the default to prepending ${kernel_path} so that
we're not surprising the aforementioned "odd-balls".
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"
1 - 100 of 167 matches
Mail list logo
