tus quo has been such for 18 years and some may want to
go back to that. I've personally been bitten by it a couple too many
times to be happy with the current situation.
(Takes off loader ballcap)
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 worry about naming. It also gives us more flexibility
> for things in the future. The time to propose it, however, was May so we
> could shake 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"
en fixed 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
duce with, then.
> 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 (
f I'm understanding it correctly, 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"
gt; [...]
>
> 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. Thi
, 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_
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’:
> dynamic
nvoked.
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
version to rule that out or narrow it down, please?
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org
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
> >
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 13.0-CURRENT
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: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 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 cont
likely can't be 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.
Tha
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?
>
> zpoo
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 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 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!
___
f
>> >
> >>>> >>> > BIOS or UEFI booting?
> >>>> >>>
> >>>> >>> UEFI boot.
> >>>> >>>
> >>>> >>
> >>>> >> So no change to \efi\boot\bootx64.efi (or whatever you a
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
eebsd.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 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
> >> open
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 short
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 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 s
/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
&g
this 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_D
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
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 A
t;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
those 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://li
us&dt=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"
lling 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"
so the 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"
on ThinkPads would have it.
>
> If so, disable it INSTEAD OF "Security Chip" and try.
>
>
> On Fri, 18 Mar 2016 15:54:46 -0500
> Kyle Evans wrote:
>
> > Hello!
> >
> > I recently purchased an older Thinkpad Yoga 11e and now I've installed
> &
Hello!
I recently purchased an older Thinkpad Yoga 11e and now I've installed
10.3RC2 to it. It appears that the Security Chip feature causes
problems in attempting to boot 10.3RC2 (and a slightly older -CURRENT,
as well, but re-tested with 10.3RC2 just for the sake of
verification). The following
On Fri, Mar 18, 2016 at 3:54 PM, Kyle Evans wrote:
> Hello!
>
> I recently purchased an older Thinkpad Yoga 11e and now I've installed
> 10.3RC2 to it. It appears that the Security Chip feature causes
> problems in attempting to boot 10.3RC2 (and a slightly older -CURREN
Hello!
I've had this odd behavior [1] on one of my machines with vt(4)
misbehaving in graphics mode following the beastie loader's screen.
Any ideas what might cause something like this, or if it's just
something unsupported? I have a PR open at [2] with pciconf -lv
output.
Than
ghlighted of search matches irritates as
well.
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"
tirely does
not change the situation on my side, unfortunately. =(
I couldn't think of anything else to try that might affect it, but
open to suggestions.
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mail
option seems to have been accidentally
broken by r317703 [1] ("bsdgrep: fix -w flag matching with an empty
pattern").
Ed, Kyle, any idea where the problem might be?
-Dimitry
[1] https://svnweb.freebsd.org/base?view=revision&revision=317703
Hi,
This is addressed by https://reviews.f
On Fri, May 5, 2017 at 9:31 AM, Kyle Evans wrote:
> On May 5, 2017 8:39 AM, "Dimitry Andric" wrote:
>
>
> This appears to be caused by bsdgrep. :-/ The build for lib/libsysdecode
> uses a shell script, mkioctls, to generate a ioctl.c file at build time.
> This s
nel.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
s... d_write/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
5c8de23c22bde/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
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:
>
ror code 1
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
fully that'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
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 that
line and output the leading context again + terminate
again.
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
rintline() with 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/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 dupli
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
BSD_version shims or something.
Thanks,
Kyle Evans
[0]
https://github.com/ventoy/Ventoy/tree/master/Unix/ventoy_unix_src/FreeBSD/geom_ventoy_src
ickly
repurpose some PID for a non-u2f thing, much less in a way that we care
about.
Thanks,
Kyle Evans
e,
O. 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
it- thanks. I suspect it just needs an extra helping of
`__BSD_VISIBLE` sprinkled in.
Thanks,
Kyle Evans
ushed 9333e1cbd028 ("include: ssp: hide ppoll redirect behind
__BSD_VISIBLE") and audited a bit for similar issues in the other ssp
headers, but didn't see any off-hand. With that change:
100% tests passed, 0 tests failed out of 267
Thanks,
Kyle Evans
On 7/30/24 16:16, Cy Schubert wrote:
In message , Gleb Smirnoff writes:
On Tue, Jul 23, 2024 at 01:39:23PM -0700, Gleb Smirnoff wrote:
T> On Mon, Jul 22, 2024 at 01:00:11AM -0700, Gleb Smirnoff wrote:
T> T> This is an automated email to inform you that the July 2024 stabilizati
on week
T> T> sta
On 7/31/24 14:31, Gleb Smirnoff wrote:
On Tue, Jul 30, 2024 at 05:05:33PM -0500, Kyle Evans wrote:
K> > > commit ce220b82ad546d3518a805750e5ee6add73f1fbf
K> > > Author: Alfonso Siciliano
K> > > Date: Sat May 25 02:42:46 2024 +0200
K> > >
K> > >
r the
beginning/end of a file.
The fix was applied in base r326084; please test port updates with an
updated patch(1) to avoid build failures on -HEAD.
A sweep of the ports tree was done by portmgr@ to correct current cases of
these candidate patches.
Thanks,
Kyle
On Tue, Jan 16, 2018 at 5:00 PM, Oleg Ginzburg wrote:
> Looks like https://svnweb.freebsd.org/base?view=revision&revision=r328032
> breaks any other arguments except '-j' for service(8)
Apologies, fixed in r328060 =(
___
freebsd-current@freebsd.org mail
Hello!
On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor wrote:
> I have done a full build of r329555 to test the new Lua boot loader.
>
> Both the new and the old kernels panic after being loaded with:
>
> panic: running without device atpic requires a local APIC
>
> For reasons unknown,
On Mon, Feb 19, 2018 at 3:37 PM, Warner Losh wrote:
>
>
> On Feb 19, 2018 1:23 PM, "Kyle Evans" wrote:
>
> Hello!
>
> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor
> wrote:
>> I have done a full build of r329555 to test the new Lua boot loader
On Mon, Feb 19, 2018 at 4:32 PM, Warner Losh wrote:
>
>
> On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske wrote:
>>
>>
>>
>> > On Feb 19, 2018, at 2:21 PM, Kyle Evans wrote:
>> >
>> > It seems that the Forth loader might be doing something sne
On Feb 19, 2018 5:44 PM, "Peter Lei" wrote:
On 2/19/18 2:21 PM, Kyle Evans wrote:
> Hello!
>
> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor
wrote:
>> I have done a full build of r329555 to test the new Lua boot loader.
>>
>> Both the new
gets sOn Mon, Feb 19, 2018 at 6:11 PM, Peter Lei wrote:
>
>
> On 2/19/18 5:48 PM, Kyle Evans wrote:
>>
>>
>> On Feb 19, 2018 5:44 PM, "Peter Lei" > <mailto:peter@ieee.org>> wrote:
>>
>>
>>
>> On 2/19/18 2:21 PM, Ky
ot/kernel.old/kernel
> Command failed
> OK boot kernel
> Command failed
>
> On the other hand, just "boot" works.
>
This part should work as expected as of r329674, so please give that a
shot. I'm still trying to
On Wed, Feb 21, 2018 at 4:43 AM, Juan Ramón Molina Menor wrote:
> Le 20/02/2018 à 22:45, Kyle Evans a écrit :
>>
>> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor
>> wrote:
>>>
>>> [... snip ...]
>>>
>>> Moreover, the "bo
On Wed, Feb 21, 2018 at 6:36 AM, David Wolfskill wrote:
> The Lua loader appears to be using a mechanism other than the
> "kernels=..." specification in /boot/loader.conf to slect potential
> kernels to load. I'm not claiming this is "bad" -- just "different."
>
> I noticed because I sometimes bu
On Wed, Feb 21, 2018 at 8:55 AM, Warner Losh wrote:
>
>
> On Wed, Feb 21, 2018 at 6:58 AM, Kyle Evans wrote:
>>
>> On Wed, Feb 21, 2018 at 4:43 AM, Juan Ramón Molina Menor
>> wrote:
>> > Le 20/02/2018 à 22:45, Kyle Evans a écrit :
>> >>
>>
missed something?
>
You have missed how silly this behavior was. =)
Fixed in r329748, sorry about that!
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send a
On Wed, Feb 21, 2018 at 12:18 PM, Rodney W. Grimes
wrote:
>> On Wed, Feb 21, 2018 at 6:11 AM, Kyle Evans wrote:
>> > On Wed, Feb 21, 2018 at 6:36 AM, David Wolfskill
>> > wrote:
>> >>
>> >> ...
>> >> kernels="kernel kernel.old k
could be problematic. The
new version handles all of that a little better and respects
loader_menu_frame to boot.
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send
On Fri, Mar 2, 2018 at 9:52 AM, Renato Botelho wrote:
> On 02/03/18 12:31, Kyle Evans wrote:
>> On Fri, Mar 2, 2018 at 6:06 AM, Renato Botelho wrote:
>>> Kyle,
>>>
>>> I've moved to Lua loader to help testing and it worked fine. The only
>>> o
) weeks from now on April 4th.
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, Mar 22, 2018 at 6:09 AM, M&S - Krasznai András
wrote:
>> -Eredeti üzenet-
>> Feladó: owner-freebsd-curr...@freebsd.org
>> [mailto:owner-freebsd-curr...@freebsd.org] Meghatalmazó Toomas Soome
>> Küldve: 2018. március 22. 11:52
>> Címzett: FreeBSD Current
>> Tárgy: Re: Call for Test
emoval has been reverted in r331353. A couple of inquiries for you:
1.) Before loading efirt, can you show me what `sysctl
machdep.efi_map` looks like?
2.) After `kldload efirt` and getting a panic, can you show me what
`show registers` looks like?
3.) Have you used efirt successfully before?
Thank
On Thu, Mar 22, 2018 at 10:18 AM, Kyle Evans wrote:
> On Thu, Mar 22, 2018 at 10:16 AM, Peter Lei wrote:
>> On 3/22/18 8:56 AM, Tomoaki AOKI wrote:
>>> Hi.
>>> For problem 2, try reverting r331241 alone.
>>> This worked for my ThinkPad T420.
>>
>>
On Thu, Mar 22, 2018 at 10:16 AM, Peter Lei wrote:
> On 3/22/18 8:56 AM, Tomoaki AOKI wrote:
>> Hi.
>> For problem 2, try reverting r331241 alone.
>> This worked for my ThinkPad T420.
>
>
> I also hit this after updating to latest and was about to post when I
> saw this thread -
>
> I build efirt
On Thu, Mar 22, 2018 at 11:56 AM, Renato Botelho wrote:
> On 21/03/18 21:45, Kyle Evans wrote:
>> Hello!
>>
>> A number of changes have gone in recently pertaining to UEFI booting
>> and UEFI runtime services. The changes with the most damaging
>> potential a
On Tue, Mar 27, 2018 at 11:06 AM, Stefan Esser wrote:
> A few weeks ago I tried the LUA boot and found, that my kernel did not start
> (i.e. did not print the initial FreeBSD version line), but instead stopped
> with:
Oy =/
> panic: No heap setup
>
> I recovered by booting from an alternate boot
On Tue, Mar 27, 2018 at 6:39 PM, Stefan Esser wrote:
> Am 27.03.18 um 21:31 schrieb Kyle Evans:
>>
>> On Tue, Mar 27, 2018 at 11:06 AM, Stefan Esser wrote:
>>>
>>> A few weeks ago I tried the LUA boot and found, that my kernel did not
>>> start
>>&
On Sun, Apr 1, 2018 at 7:38 AM, Tomoaki AOKI wrote:
> Confirmed both loader (with boot1) part and efirt.ko part.
> Working OK on my ThinkPad420 (with nvidia GPU) at r331864.
>
> No benefit (VGA resolution) but no new harm (no panic nor silent
> reboot).
>
> *Maybe gracefully falling back to mode
range, maybe by actual access to UEFI RS.
>> > With r331241 without r331361 causes instant panic on loading efirt.ko.
>> > So all 3 (4) revs should be MFC'ed together.
>> >
>> > Sorry for delay.
>> >
>> >
>> > On Thu, 22 Mar
;re looking at 80x25
> text... which is ... 800 x 600 -ish? The kernel definately wants graphics
> again ... but ... I dunno ... is it getting it? Is the 80x25 text mode
> emulated on a bitmapped screen?
>
>
> On Mon, Apr 2, 2018 at 9:07 PM, Kyle Evans wrote:
>>
>>
On Tue, Apr 3, 2018 at 3:17 PM, Kyle Evans wrote:
> Hi,
>
> Right- so, `gop set 0` should've immediately cleared your screen and
> put it into 1920x1080, full stop. If it did not, I think that's
> indicative of some kind of interestingly broken firmware...
>
> R
On Wed, Mar 21, 2018 at 7:45 PM, Kyle Evans wrote:
> Hello!
>
> A number of changes have gone in recently pertaining to UEFI booting
> and UEFI runtime services. The changes with the most damaging
> potential are:
>
> We now put UEFI runtime services into virtual address m
ndleattr: md10 bio_length 24 len 31 -> EFAULT
> kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
> kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
> [pho@freefall ~/public_html/stress/log]$
>
FYI- this should be fixed by r332070.
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"
executes the kernel.
Maybe it'll fix it?
Thanks,
Kyle Evans
[1] https://people.freebsd.org/~kevans/loader.diff
___
freebsd-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 Tue, Apr 17, 2018 at 9:47 AM, Beeblebrox wrote:
> I have (possibly) similar problem, running kernel from March 29 as
> fall-back (older kernel, latest world).
>
> * OS: HardenedBSD-12 on amd64 Athlon II X3 460
> * Kernels built yesterday: MYKERN & HARDENEDBSD (GENERIC with Debug).
> Both kern
> Regards, STefan
Hmm... what does `grep -V` look like, just to confirm?
These are the results on my local system:
root@viper:/tmp/grep# ./grep-test.sh
All/mpfr-3.1.7.tgz
0.10 real 0.10 user 0.00 sys
All/mpfr-3.1.7.tgz
On Thu, May 3, 2018 at 12:54 PM, Stefan Esser wrote:
> Am 03.05.18 um 17:28 schrieb Kyle Evans:
>> On Thu, May 3, 2018 at 10:19 AM, Stefan Esser wrote:
>>> Am 03.05.18 um 16:41 schrieb Kyle Evans:
>>>> Hmm... what does `grep -V` look like, just to confir
alleviate this that will
hopefully land later today.
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"
,
> toomas
>
Hmm... that's less than great. Is this worth an MFC + 11.2 EN? I'd
suspect it's not an entirely common case at all, but loader.efi is
highly visible and actually updated in stable/11 (vs. soon-to-be
thrown on ESP in head.
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 Fri, Aug 3, 2018 at 10:10 PM, Eitan Adler wrote:
> Hi all,
>
> After installing the latest current kernel I get the following panic:
>
> panic: mutex pmap not owned at ... efirt_machdep.c:255
> cpuid =3
> time = 1
> ...
> mtx_assert()
> efi_arch_enter()
> efirt_modevents()
> module_register_ini
On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov wrote:
> On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans wrote:
>>
>> This seems odd- pmap lock is acquired at [1], then asserted shortly
>> later at [2]... I avoid some of this stuff as well as I can, but is it
>
On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov wrote:
> On Sat, Aug 04, 2018 at 08:05:24AM -0500, Kyle Evans wrote:
>> On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov
>> wrote:
>> > On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans wrote:
>> >>
1 - 100 of 171 matches
Mail list logo
