On 14 Feb 2020, at 18:18, Ed Maste wrote:
Hi Ed,
Although the specific deprecation steps aren't yet fleshed out I'm
sending this as an early notice that I plan to disable libwrap support
from the base system sshd and that FreeBSD 13 will not support it.
I’ll be sad to run inetd again on syste
On 2/15/20, Stefan Eßer wrote:
> Hi Mateusz,
>
> your optimization of systrace checks has made KDTRACE_HOOKS mandatory,
> since there are unprotected assignments to systrace_enabled (which is
> defined as constant 0 in kernels without KDTRACE_HOOKS due to your
> change):
>
> /sys/cddl/dev/systrace
Am 15.02.20 um 14:47 schrieb Mateusz Guzik:
> On 2/15/20, Stefan Eßer wrote:
>> Hi Mateusz,
>>
>> your optimization of systrace checks has made KDTRACE_HOOKS mandatory,
>> since there are unprotected assignments to systrace_enabled (which is
>> defined as constant 0 in kernels without KDTRACE_HOOK
Am 15.02.20 um 15:40 schrieb Stefan Eßer:
> Am 15.02.20 um 14:47 schrieb Mateusz Guzik:
>> On 2/15/20, Stefan Eßer wrote:
>>> Hi Mateusz,
>>>
>>> your optimization of systrace checks has made KDTRACE_HOOKS mandatory,
>>> since there are unprotected assignments to systrace_enabled (which is
>>> def
On Sat, Feb 15, 2020 at 03:58:06PM +0100, Stefan Eßer wrote:
> Am 15.02.20 um 15:40 schrieb Stefan Eßer:
> > Am 15.02.20 um 14:47 schrieb Mateusz Guzik:
> >> On 2/15/20, Stefan Eßer wrote:
> >>> Hi Mateusz,
> >>>
> >>> your optimization of systrace checks has made KDTRACE_HOOKS mandatory,
> >>> si
Hello Current,
CURRENT r357966 on amd64, on host with 4G of memory (and Atom CPU) panics
with page fault right after kernel load (before any kernel output).
Stacktrace (typed from photo of screen, all trap-related functions are
omitted):
uma_zalloc_arg()
malloc()
sysctl_handle_string()
On Sat, Feb 15, 2020 at 08:54:15PM +0300, Lev Serebryakov wrote:
> Hello Current,
>
> CURRENT r357966 on amd64, on host with 4G of memory (and Atom CPU) panics
> with page fault right after kernel load (before any kernel output).
>
> Stacktrace (typed from photo of screen, all trap-related fu
Hello David,
Saturday, February 15, 2020, 9:02:53 PM, you wrote:
>> CURRENT r357966 on amd64, on host with 4G of memory (and Atom CPU) panics
>> with page fault right after kernel load (before any kernel output).
>>
>> Stacktrace (typed from photo of screen, all trap-related functions are
>>
Hello David,
Saturday, February 15, 2020, 9:02:53 PM, you wrote:
> My last CURRENT build was at r357959 (and which booted without issue --
> though the systems in question don't use ZFS); only commits I see to
> head after r357959 are r357962 & r357967.
r357508 works on "big iron" (Xeon E3-1220
Hello!
>> My last CURRENT build was at r357959 (and which booted without issue --
>> though the systems in question don't use ZFS); only commits I see to
>> head after r357959 are r357962 & r357967.
> r357508 works on "big iron" (Xeon E3-1220 with 32G of RAM) but pagefaults
> somewhat later:
>
From: Lev Serebryakov
Subject: CURRENT panciks right after kernel load (r357966)
Date: Sat, 15 Feb 2020 20:54:15 +0300
> CURRENT r357966 on amd64, on host with 4G of memory (and Atom CPU) panics
> with page fault right after kernel load (before any kernel output).
I tried kernel update from r3
Hello Yasuhiro,
Saturday, February 15, 2020, 9:54:25 PM, you wrote:
>> CURRENT r357966 on amd64, on host with 4G of memory (and Atom CPU) panics
>> with page fault right after kernel load (before any kernel output).
> I tried kernel update from r357653 to r357969 and boot completes
> successfu
On Sat, 15 Feb 2020 22:00:39 +0300
Lev Serebryakov wrote:
> Hello Yasuhiro,
>
> Saturday, February 15, 2020, 9:54:25 PM, you wrote:
>
> >> CURRENT r357966 on amd64, on host with 4G of memory (and Atom CPU) panics
> >> with page fault right after kernel load (before any kernel output).
>
>
From: Lev Serebryakov
Subject: Re: CURRENT panciks right after kernel load (r357966)
Date: Sat, 15 Feb 2020 21:12:27 +0300
> I didn't update this "firmware" for almost a year, and don't have results
> for revision between r349299 (works) and r357763 (panics). It is too much
> for bi-sect :-(
Th
Hello Yasuhiro,
Saturday, February 15, 2020, 10:24:25 PM, you wrote:
> From: Lev Serebryakov
> Subject: Re: CURRENT panciks right after kernel load (r357966)
> Date: Sat, 15 Feb 2020 21:12:27 +0300
>> I didn't update this "firmware" for almost a year, and don't have results
>> for revision bet
Am 15.02.20 um 18:45 schrieb Konstantin Belousov:
> On Sat, Feb 15, 2020 at 03:58:06PM +0100, Stefan Eßer wrote:
>> Am 15.02.20 um 15:40 schrieb Stefan Eßer:
>>> Am 15.02.20 um 14:47 schrieb Mateusz Guzik:
On 2/15/20, Stefan Eßer wrote:
> Hi Mateusz,
>
> your optimization of systr
Hi folks,
I upgraded vmware fusion to version 11 recently and noticed that my -amd64 VM
stops booting immediately after printing EFI framebuffer information.
VM pops up a message stating that "The firmware encountered an unexpected
exception. The virtual machine cannot boot."
Further digging r
> On 15. Feb 2020, at 22:19, Alexander V. Chernikov wrote:
>
> Hi folks,
>
> I upgraded vmware fusion to version 11 recently and noticed that my -amd64 VM
> stops booting immediately after printing EFI framebuffer information.
>
> VM pops up a message stating that "The firmware encountered
15.02.2020, 20:44, "Toomas Soome" :
>> On 15. Feb 2020, at 22:19, Alexander V. Chernikov wrote:
>>
>> Hi folks,
>>
>> I upgraded vmware fusion to version 11 recently and noticed that my -amd64
>> VM stops booting immediately after printing EFI framebuffer information.
>>
>> VM pops up a messa
I built world && kernel from within a jail. When I attempt to
perform an install to DESTDIR, I receive the following:
releng12:/usr/src # mkdir -p /REL
releng12:/usr/src # make installworld DESTDIR=/REL
...
--
Installing everything
---
On Sat, 15 Feb 2020 13:55:09 -0800 bsd-li...@bsdforge.com said
I built world && kernel from within a jail. When I attempt to
perform an install to DESTDIR, I receive the following:
releng12:/usr/src # mkdir -p /REL
releng12:/usr/src # make installworld DESTDIR=/REL
...
-
21 matches
Mail list logo
