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"
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 (
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
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"
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"
cal disk
We'll hopefully be having a bisect session tomorrow to figure out
where exactly this broke so that maybe Brett has a chance to upgrade
to 12.0, unless this sounds familiar to someone and the cause is
obvious. =)
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"
turns out
to be a better solution, one of which I think I see.
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, Aug 20, 2018 at 12:44 PM, Manfred Antar wrote:
>
>
>> On Aug 20, 2018, at 9:20 AM, Warner Losh wrote:
>>
>>
>>
>> On Mon, Aug 20, 2018 at 9:55 AM, Kyle Evans wrote:
>> On Mon, Aug 20, 2018 at 10:39 AM, Manfred Antar
>> wrote:
>> &
(space or comma separated) "efi" then do
not draw a menu (fall back to autoboot routine).
if $beastie_disable is set to "YES" (case insensitive), then do not
draw a menu (fall back to autoboot routine).
We are clearly doing this wrong. I will fix it ASAP.
Thanks,
Kyle Evans
_
On Sun, Aug 19, 2018 at 12:33 PM, O. Hartmann wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Just updated some boxes to 12-CURRENT r338057 and I face a very strange
> behaviour:
>
> on non-UEFI booting boxes (older Fujitsu and Dell servers from 2008/2009,
> PCengine APU
> 2C4), l
On Sun, Aug 19, 2018 at 11:58 AM, John Baldwin wrote:
> On 8/19/18 5:28 PM, Kyle Evans wrote:
>> On Sun, Aug 19, 2018 at 10:42 AM, Warner Losh wrote:
>>> On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman wrote:
>>>
>>>> On Sun, Aug 19, 2018 at 09:33:18AM
On Sun, Aug 19, 2018 at 11:35 AM, Larry Rosenman wrote:
> On Sun, Aug 19, 2018 at 11:28:10AM -0500, Kyle Evans wrote:
>> > filesystem?
>> >
>>
>> (CC'ing jhb@ and tychon@, who might have better insight)
>>
>> If we can swing it, I think the best m
>> POLA?
>>
>
> Unlikely, but a couple of questions. Have you always used the LUA loader,
> or is this a change with the recent default switch?
>
> And to be clear, you expect the host's file to be used for this, not the VM
> filesystem?
>
(CC'i
On Wed, Aug 15, 2018 at 7:53 AM, Kyle Evans wrote:
> On Wed, Aug 15, 2018 at 7:40 AM, David Wolfskill wrote:
>> I'm tracking head/amd64 daily twice on each of two machines: my "build
>> machine" ("freebeast") and my laptop, each first using the tradition
past day was the update to
5.3.5 and removal of some float stuff- the former was pretty tiny, and
the latter was unused cruft anyways.
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"
ical error and completely changed
the calculations for this stuff and possibly sent you on dramatically
different path. There's not too many commits to this area that haven't
yet landed back in stable/11, fortunately.
Thanks,
Kyle Evans
___
fr
On Tue, Aug 14, 2018 at 10:56 PM, Pete Wright wrote:
>
> On 8/14/18 8:45 PM, Kyle Evans wrote:
>>
>> On Tue, Aug 14, 2018 at 10:41 PM, Pete Wright wrote:
>>>
>>> On 8/14/18 6:13 PM, Kyle Evans wrote:
>>>>
>>>> On Tue, Aug 14, 2018 at 7:
On Tue, Aug 14, 2018 at 10:41 PM, Pete Wright wrote:
>
> On 8/14/18 6:13 PM, Kyle Evans wrote:
>>
>> On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright wrote:
>>>
>>> i also attempted to boot using UEFI but the system hangs very early in
>>> the
>>
ed.
Hi Pete,
Where in the process does it hang with UEFI? I can't help much with
any of your other problems, but I am curious about this one. =)
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman
On Tue, Aug 14, 2018 at 3:00 PM, Matthias Gamsjager
wrote:
> Ok missed the solution posted earlier: adding ' efi.rt.disabled=1' to
> loader.conf fixed the issue for me as well
Is your kernel up to r337773 yet? That should have addressed the EFIRT
boot issue.
Tha
Ah, this should be fixed by https://reviews.freebsd.org/D16618 --
immediate workaround is set efi.rt.disabled=1 in loader.conf(5) or at
loader prompt. Apologies for the hassle.
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.f
On Tue, Aug 7, 2018 at 12:09 AM, Eitan Adler wrote:
> On Mon, 6 Aug 2018 at 11:27, Kyle Evans wrote:
>>
>> On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov
>> wrote:
>> > On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote:
>> >>
>> &
On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov wrote:
> On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote:
>>
>> He now gets a little further, but ends up with the same panic due to
>> efirtc_probe trying to get time to verify the rtc's actually
>> im
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:
>> On Fri, Aug 3, 2018 at 10:10 PM, Eitan Adler wrote:
>> > Hi all,
>> >
>> > After installing the latest current kernel I get the followin
On Sat, Aug 4, 2018 at 9:51 AM, Ian Lepore wrote:
> On Sat, 2018-08-04 at 08:56 -0500, Kyle Evans wrote:
>> On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov > com> wrote:
>> >
>> > On Sat, Aug 04, 2018 at 08:05:24AM -0500, Kyle Evans wrote:
>> &g
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:
>> >>
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 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
,
> 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"
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"
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
> 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 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
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"
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"
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
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
;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:
>>
>>
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
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
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 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 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 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 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.
>>
>>
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 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
) 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 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
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 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
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 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 :
>> >>
>>
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 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
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
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
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
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 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
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 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
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 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
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
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
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"
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
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 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 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
> &
101 - 171 of 171 matches
Mail list logo
