On 19 October 2015 at 16:50, John-Mark Gurney wrote:
> O. Hartmann wrote this message on Mon, Oct 19, 2015 at 06:19 +0200:
>> For me, I'd like to know what is the benefit/performance of each technique
>> and
>> a clear preparation of each ones advantages over the other. That would make
>> the
>>
On 11 February 2015 at 21:39, Glen Barber wrote:
> Hi,
>
> Within the next 24 hours, I will merge the release-install-debug branch
> into head, which will enable building and installing stripped debugging
> files by default.
>
> In general, this should have no significant impact, but any fallout w
On 18 November 2015 at 15:46, Luigi Rizzo wrote:
> i was going to suggest doing ldd on the binaries or a grep on the
> Makefile but the latter returns a surprisingly low number
> of matches.
That's because it's usually added via LIBADD=xo.
My grep turns up these: bin/df, bin/ls, bin/ps, sbin/sav
On 23 November 2015 at 08:33, Konstantin Belousov wrote:
>
> The revision 291171 changed layout of the dereferenced structure
> sysentvec. Was your kernel build clean, or did you used -DNO_CLEAN or
> similar option ? If yes, remove the kernel build directory and start
> from scratch.
Every time r
I disconnected kgzldr from the build in r291113 because I thought
kgzip was already disconnected. As it happens kgzip was disconnected
only from the release builds, in r281658.
kgzip / kgzldr only works on i386, and for quite some time the
recommended way to use a compressed kernel has been via lo
As of r291955 userland debug files are built and installed by default,
in order to facilitate debugging. They will be built as part of the
release process (in FreeBSD 11) so that they can be made available for
download either at install time, or later on to debug a core file
after a crash. (Release
On 22 December 2015 at 12:39, Vijay Rjah wrote:
>
> The only issue i have is that the boot process takes a lot of time..
> (similar to
> https://forums.freebsd.org/threads/new-motherboard-and-processor-kernel-load-very-slow.53511/
> ). the system ultimately boots, but boot times are around 4 - 5 M
On 18 January 2016 at 03:10, Dimitry Andric wrote:
> On 18 Jan 2016, at 07:20, O. Hartmann wrote:
>> Building NanoBSD images booting off from USB Flash drives and having two GPT
>> partitions, booting is stuck in the UEFI loader, presenting me with something
>> like:
>>
>> [...]
>> Probing 6 bloc
On 18 January 2016 at 15:26, Andrew Turner wrote:
>
> the issue was we were caching reads from the first filesystem we looked
> at. I've committed the fix in r294291 to force the code to re-read on
> each filesystem it looks at.
Thanks Andrew - my QEMU boot failure is not reproducible on a build
On 11 March 2014 at 20:38, David Chisnall wrote:
> On 12 Mar 2014, at 02:07, Roger Pau Monné wrote:
>
>> I've found out that the value PTHREAD_STACK_MIN is currently set (2048
>> bytes) seems to be way too low
>
> This looks like an error in your code. The spec says:
>
>> PTHREAD_STACK_MIN
>> Mi
Summary: If you're willing to help test the ELF Tool Chain tools and
you build -CURRENT from source, please set WITH_ELFCOPY_AS_OBJCOPY=yes
in /etc/src.conf, and report any build- or run-time issues you
experience with the base system, ports, or third-party software.
In SVN revision 295577 I updat
On 8 March 2016 at 18:52, Jean-Sébastien Pédron
wrote:
> Hi!
>
> I use Root on ZFS and my laptop doesn't boot with a kernel from r296548
> and world from r296491 (so older than kernel). Ed hits a similar crash.
>
> Here are the dmesg and backtrace of zfs(8):
> https://gist.github.com/dumbbell/c997
On 9 March 2016 at 01:39, Ed Maste wrote:
> On 8 March 2016 at 18:52, Jean-Sébastien Pédron
> wrote:
>> Hi!
>>
>> I use Root on ZFS and my laptop doesn't boot with a kernel from r296548
>> and world from r296491 (so older than kernel). Ed hits a similar
On 9 March 2016 at 08:28, Jean-Sébastien Pédron
wrote:
> On 09/03/2016 12:23, Alexander Motin wrote:
>> Should be fixed by r296563.
>>
>> Illumos assumes full sync between kernel and world, so they are quietly
>> breaking ABI as often as they want for any new feature. One more set of
>> compat sh
On 13 March 2016 at 19:16, Steve Kargl
wrote:
> JFYI,
>
> It appears that clang on up-to-date current may be
> miscompiling libm on at i686 class hardware.
Do you have an example of the suspected miscompilation?
___
freebsd-current@freebsd.org mailing
On 6 May 2016 at 14:47, O. Hartmann wrote:
> Buildworld on r299175 fails with the error shown below:
>
>
> [...]
> error: no such file or directory:
> '/usr/src/secure/lib/libcrypto/i386/crypt586.S'
If this was with -DNO_CLEAN you might want to try a clean build instead.
Can you confirm that se
On 30 May 2016 at 15:51, Steve Kargl wrote:
>
> It happens with both /usr/bin/ld and /usr/local/bin/ld. I remove the
> binutils port and still had the issue. I tried reverting recent changes
> to elftoolchain/libelftc, the resulting tree would not build.
The elftoolchain changes are a good cand
On 31 May 2016 at 12:21, Dimitry Andric wrote:
>
> Maybe elftoolchain's ar does something different? Assuming the .a files
> are built with the system ar, of course.
We don't use the ELF Tool Chain ar yet so it won't be that. (ELF Tool
Chain's ar, brandelf, elfdump are updated descendants of the
On 3 June 2016 at 12:49, Eric van Gyzen wrote:
> I'm running head from Tuesday (r301045). I just noticed that "ar" is
> missing the debuginfo for libarchive:
I discussed this with Eric off this thread, but for the sake of others
this is happening because WITH_DEBUG_FILES enables -g when building
On 20 June 2016 at 12:45, Trond Endrestøl
wrote:
>
> If you want textmode like in the old days, add this line to
> /boot/loader.conf:
>
> hw.vga.textmode="1"
One note, in textmode vt(4) is limited to cp437. The console still
uses Unicode internally but has a fixed lookup table to map to the
cp437
On 20 June 2016 at 14:29, Ernie Luzar wrote:
>
> I found the cause of this boot time message
> "vicontrol: setting cursor type: Inappropriate ioctl for device"
>
> In my rc.conf I had this statement
> vidcontrol -c blink -h 250
> From testing it seems that vt does not handle the "blink" option for
On 20 June 2016 at 23:22, John Baldwin wrote:
>
> There are tradeoffs in both directions. Neither console is a subset of the
> other. However, sc(4) is not really extendable to support the things it is
> missing. vt(4) is actively worked on, and patches for the features it lacks
> that you need
On the topic of vgl(3) specifically, in October 2014 I wrote on this list:
> vgl(3) is a graphics library for syscons(4) that provides some basic
> graphics operations (e.g. some mode setting, bitmaps, boxes,
> ellipses). Right now it does not support the newer vt(4) console.
>
> In order to help
dtc(1) is the Device Tree Compiler, used for embedded builds. We have
two versions of dtc(1) in the FreeBSD tree: a GPLv2 one from
https://git.kernel.org/cgit/utils/dtc/dtc.git and a BSD licensed one
in https://svn.freebsd.org/base/head/usr.bin/dtc.
We switched back to the GPL one since device tre
On 12 January 2017 at 18:50, Alan Somers wrote:
> I've seen three separate machines where FreeBSD11's vt(4) driver chops
> off the leftmost three columns of the screen. Rendering simply starts
> at the beginning of the fourth column. In all cases, setting
> "kern.vty=sc" corrects the problem.
O
On 18 January 2017 at 17:56, Piotr Kubaj wrote:
> It should also be stated properly that this patch doesn't implement ASLR, but
> ASR.
For better or worse the term ASLR is today in common use to refer to a
number of different approaches. Using what has become a generic term
allows the implementa
On 3 March 2017 at 12:24, Jochen Neumeister wrote:
> Hi current@
>
> I have a PR 217519 because of devel/pear: When WITH_LLD_IS_LD is set, the
> stage phase for devel/pear breaks.
Yes, there are issues building a number of ports with LLD at present.
There are some hacks / work in progress in both
On 19 March 2017 at 03:00, Adrian Chadd wrote:
> gcc version 5.3.0 (FreeBSD Ports Collection for mips)
>
> ... so uhm, why are we building libllvm?
As of the Clang 4.0.0 import we build Clang by default, on all
architectures other than those unsupported by Clang, if the
cross-compiler supports C+
On 1 April 2017 at 13:28, Ernie Luzar wrote:
>
> Is anyone working the these outstanding vt(4) bug reports?
I am not aware of anyone working on these right now.
> Bug 210446 - vt(4) when switching between virtual consoles there is a 4
> second hesitation in graph mode.
> https://bugs.freebsd.org
On 16 April 2017 at 04:10, Mark Millard wrote:
> Context: amd64 FreeBSD -r316952 as a VirtualBox guest
> that was built using WITH_LLD_IS_LD= . ports -r438577.
>
> x11/xorg-minimal indirectly gets to devel/libunwind and
> devel/libunwind fails to build from source:
>
>
> --- Lperf-simple ---
> lib
On 26 May 2017 at 12:18, Kurt Jaeger wrote:
> Hi!
>
>> For those running FreeBSD head, the ABI was majorly changed in r318736
>> for 64-bit inodes. This change was *backwards compatible* but not
>> *forward compatible*. This is normal and expected.
>
> Is any fall-out from this change already ha
On 27 May 2017 at 12:25, Thomas Laus wrote:
> After the
> first boot, I tried to install the pkg system. The first fault said
> that the libarchive.so.6 was missing.
Yes, the most recent package set available is built against a
pre-ino64 world and depends on older versions of libraries (like
lib
The ino64 project was committed to src last week[1][2] with
UPDATING notes added shortly thereafter [3][4][5].
As some people have been tripped up by the ino64 change I want to
emphasize again that the upgrade procedure described in UPDATING should
be followed exactly. The reboot after installing
On 29 May 2017 at 04:59, O. Hartmann wrote:
> After updating several boxes running CURRENT after introduction of ino64, I
> have one box which persitently rejects compiling and installing
> devel/libunwind, as you can finde below.
>
> The box in question is running FreeBSD 12.0-CURRENT #22 r31908
On 29 May 2017 at 10:49, Ed Maste wrote:
> The ino64 project was committed to src last week[1][2] with
> UPDATING notes added shortly thereafter [3][4][5].
I've now added an anti-foot-shooting test[6] which invokes the new
rescue binary prior to proceeding with installworld. This s
On 30 May 2017 at 12:49, O. Hartmann wrote:
>
> I got a kind of confused, since libunwind seemingly compiles on one box with
> both ino64
> AND WITH_LLD_IS_LD, while it failed after an update of a bunch of systems
> towards ino64.
So was this just confusion over what was actually built? I belie
On 30 June 2017 at 21:27, Benjamin Kaduk wrote:
>
> The preferred and easiest submission method is to use the XML generator [1]
>
> [1] https://www.FreeBSD.org/cgi/monthly.cgi
Note that Chrome has a bug when attempting to save the output of
monthly.cgi, and your work will be lost. Please do not u
On 11 July 2017 at 12:44, Don Lewis wrote:
> This is a really strange problem ...
>
> Last week I upgraded my 12.0-CURRENT package build box from r318774 to
> r320570. I also upgraded the poudriere jail to match. When I went to
> build packages, the virtualbox-ose build failed due to ar segfault
On 5 August 2017 at 16:16, Dimitry Andric wrote:
>
> I remember there being an issue with ar and/or ranlib choking when the
> .a files become too big. Ed, does that ring any bells?
Our ar (and ranlib, which is the same binary) will produce a corrupt
symbol table if the .a archive output is large
On 7 August 2017 at 00:32, Aijaz Baig wrote:
> That was some pretty relevant information Ed. Thanks.
Even though it's not a direct cause of the problem you encountered I
wanted to make sure a there was comprehensive reply to Dimitry's
question.
> Nonetheless, as I have indicated in my previous e
On 22 August 2017 at 07:46, David Wolfskill wrote:
>
> lldb's notion of the backtrace was fairly non-useful:
> g1-252(11.1-S)[7] lldb -c sh.core
Try:
% lldb /bin/sh -c sh.core
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailma
Mfiutil(8) is a commandline management tool for RAID controllers
supported by the mfi(4) driver. I have a couple of changes to the way
battery back up unit (BBU) state is reported and I would like to request
testing from any mfi(4) users who are able to try my patch.
If you're able to test it for
On Thu, Nov 03, 2011 at 07:05:54PM -0700, Craig Rodrigues wrote:
> On Fri, Oct 28, 2011 at 1:47 PM, Nima Misaghian
> wrote:
> > Hi,
> >
> > I have got code developed by Andre Albsmeier that is capable of
> > programming firmware of hard drives from several vendors and ?turned
> > it into a camco
On Tue, Nov 22, 2011 at 03:47:41PM +, Nima Misaghian wrote:
> We have added firmware download command to atacontrol at work, for
> which I have attached a patch against 8.2 to this email.
>
> The format of the command is similar to the camcontrol counterpart:
>
> atacontrol fwdownload
>
>
I have a patch to allow nextboot(8) to set arbitrary kernel environment
variables (not just the kernel dir and kernel_options). The usage becomes:
Usage: nextboot [-e variable=value] [-f] [-k kernel] [-o options]
nextboot -D
and the new option is documented as:
-e variable=value
On Mon, Jan 30, 2012 at 01:12:21PM -0700, Ian Lepore wrote:
> Minor nit:
>
> -It is not the most thoroughly tested code.
> +It is not the most throughly tested code.
>
> The original spelling is the correct one.
Nice catch, and thanks for the review. This came from an accidental
revert of
Rev 243674 with some minor local changes.
#12 0x80bfd775 in trap_fatal (frame=0xff800025e870,
eva=)
at /home/emaste/src/head-ro/sys/amd64/amd64/trap.c:867
#13 0x80bfda3a in trap_pfault (frame=0x0, usermode=0)
at /home/emaste/src/head-ro/sys/amd64/amd64/trap.c:698
#1
On 29 November 2012 17:36, Ed Maste wrote:
> #14 0x80bfd226 in trap (frame=0xff800025e870)
> at /home/emaste/src/head-ro/sys/amd64/amd64/trap.c:463
> #15 0x80be71a2 in calltrap () at /tmp/exception-N6d6io.s:179
> #16 0x808bb9c0 in rman_set_bustag ()
&g
> Please try this patch:
> http://people.freebsd.org/~avg/acpi_cpu_notify.2.diff
>
> I should have committed this earlier, but the fact that we were not getting
> much
> problems when updating resources in place lead me to believe that we would not
> get more problems when first deleting and then
Libfetch supports a username and password in a FTP or HTTP URL, but lacks
a method to specify '@' or ':' there, as they're used as URL component
separators. I discovered this issue because I have an FTP server that
uses an email address as the username, and I can't use fetch(1) or
libfetch against
On Mon, Apr 09, 2012 at 03:24:30PM -0700, Julian Elischer wrote:
> could you not parse the @ differently depending upon where it is?
>
> others must have covered this problem..
Indeed others have - none other than T. Berners-Lee, in RFC 1738 where
the format of a URL is specified:
In addition
I'm running CURRENT as of r236822 on my Thinkpad X220 and am starting
to experiment with the i915 kms driver. All packages are from the
pkgbeta repo; I haven't rebuilt anything yet. I have
xorg-server-1.7.7_5,1 and the vesa driver gets used. In this
configuration I have a reproducible panic unloa
On 18 September 2013 13:11, Baptiste Daroussin wrote:
>
> libexecinfo in base is exactly the same as the on from ports, so it should be
> a
> change that doesn't require any manual operations.
To clarify, it is not the same code, but provides exactly the same
interface. The one now in base come
On 4 November 2013 02:16, Kevin Oberman wrote:
> Excellent news. I'm really looking forward to newcons. Guess it's time to
> move my T520 to 10-Stable (or Beta)
I'm running a Newcons kernel on my Thinkpad X220 now and it's working
well, with a few minor quirks. This is with the X-related package
that might return bogus memory
map data. I intend to commit the patch below that disables it by
default.
The variable name is "hw.memtest.tests" as it's intended to be
extended to a bitmap of tests to run at boot, with other bits
representing more comprehensive tests.
-Ed
commit 58f50
The in-tree snapshot of LLDB is at a point where it's usable and
suitable for wider testing on amd64, and so I intend to enable it by
default in the near future.
Further information on the FreeBSD port of LLDB is on the wiki, at
https://wiki.freebsd.org/lldb
On my desktop LLDB added about 5 minut
On 17 December 2013 17:21, Navdeep Parhar wrote:
> Any plans to get kernel debugging working?
It's on the roadmap, but no concrete plans or timeline yet.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curr
On 10 February 2014 16:07, Alexey Dokuchaev wrote:
>
> 1. Before going X, switching consoles took considerable time (about or more
> than one second). Every time my monitor briefly displayed mode information
> pane like it does when new mode is being switched. It does not happen after
> X was lo
On 4 March 2014 12:22, Steve Kargl wrote:
>
> On Tue, Mar 04, 2014 at 12:17:18PM +, Thomas Mueller wrote:
> > What is the current status of clang, regarding known bugs, on
> > FreeBSD-current?
> >
> > There were reports of www/firefox failing to build because of bug in llvm.
>
> Still broken
On 11 March 2014 11:59, Steve Kargl wrote:
>
> Any chance that a manpage will ever show up?
Yes, a vt(4) man page, and updates for pages like vidcontrol, are
requirements for the project to be fully complete and shipped enabled
by default in a release.
On 10 April 2014 05:49, FreeBSD Tinderbox wrote:
>
> cc: error: no such file or directory:
> '/src/sys/boot/amd64/efi/../../ficl/libficl.a'
> cc: error: no such file or directory:
> '/src/sys/boot/amd64/efi/../../efi/libefi/libefi.a'
> *** Error code 1
Sorry about that - it should now be fixed
On 1 May 2014 05:05, Jakub Lach wrote:
> [...] no localised font in system console
Can you clarify what you mean here -- what character set do you wish
to use? The default Newcons font includes extended Latin, Greek, and
Cyrillic.
___
freebsd-current@f
On 1 May 2014 13:00, Jakub Lach wrote:
> As far as I can tell, the situation is the same on
> FreeBSD 10.0-STABLE #0 r265185 amd64.
>
> newcons uses my X font (terminus),
Newcons' font is built-in, it's not using your X font. (It just
happens that you and Ed made the same choice.)
> albeit it p
On 1 May 2014 17:31, Jakub Lach wrote:
> I'm aware of another problem though (and can
> clarify it now).
>
> If I use any other character than a basic latin set, my
> prompt is not preserved.
Thanks for testing! With which shell do you observe this? I don't
with csh from base and zsh from ports
On 6 May 2014 18:06, Oliver Pinter wrote:
> Hi Davide!
>
> See the attached patch.
This typo was fixed in r261908.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "f
On 8 May 2014 04:16, David Demelier wrote:
> Hi there,
>
> I'm currently trying vt(9) on a CURRENT kernel (only the kernel not the
> base). I have very small bugs, not really serious. I'm currently using the
> radeon KMS driver.
>
> * When I switch from a tty to X I can see the mouse appearing but
On 22 May 2014 11:32, Rafael Espíndola wrote:
> The attached patch causes both boot1 and loader.efi to switch to text
> mode. This only
> seems to make a difference on Macs where otherwise no information was being
> displayed.
>
> The ConsoleControl.h file is copied from
> EdkCompatibilityPkg/Foun
On 22 May 2014 11:32, Rafael Espíndola wrote:
>
> The ConsoleControl.h file is copied from
> EdkCompatibilityPkg/Foundation/Protocol/ConsoleControl in
> https://github.com/tianocore/edk2.
I'm not aware of the full ancestry of our EFI include files, but it
looks like the initial import made some a
On 25 May 2014 03:11, Kubilay Kocak wrote:
> On 24/05/2014 7:22 AM, Allan Jude wrote:
>
>> I think this makes good sense. I would definitely prefer it. Would it
>> make sense to maybe preserve the old behaviour behind a command line flag?
>>
>
> And an update to top(8) reflecting the algo :)I know
On 26 May 2014 11:51, Ed Maste wrote:
>
> The change in the patch is good, the new behaviour is much more
> usable. Note that we don't currently define "idle" in top(8); for
> this change maybe we should just state that non-idle processes may
> report 0% CPU due
On 30 June 2014 15:17, O. Hartmann wrote:
> I tried today the new vt console in CURRENT and followed the steps described
> in the
> manpage. Trying to compile a kernel with
>
> options VT_MAXWINDOWS=10
>
> issues an error:
>
> unknown option "VT_MAXWINDOWS"
>
> What is wrong?
Sorry about that. T
On 2 July 2014 10:23, O. Hartmann wrote:
> Compiling a most recent CURRENT kernel/world with sources r 268158 ends
> up in some error indication an unknown specifier DEV_SC. This is with
> the sources reeled in today as revision indicates above, the kernel is
> as shown here:
>
> FreeBSD 11.0-CURR
On 2 July 2014 14:51, Trond Endrestøl
wrote:
> Hi,
>
> Is it just me or is there something wrong with vidcontrol(1) in
> base/head, amd64, sc console, r268165?
Should be fixed in r268175.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd
On 3 July 2014 11:50, Trond Endrestøl
wrote:
>> 1.
>> http://raybsd.blogspot.com/2013/10/newcons-international-keyboard-input.html
>
> I tried to follow the instructions, but I honestly don't see any
> difference.
>
> I downloaded uakbd2ukbd.pl.gz, decompressed the file, installed
> converters/p5-
On 24 May 2014 19:39, Rafael Espíndola wrote:
>
> Yes, I got that in the mac laptops I tried, it worked on a Mac Pro. It
> might be the frame buffer corruption that Ed Maste was mentioning.
I purchased a new MacBook Air yesterday (model identifier
MacBookAir6,2). UEFI boot and vt(
Dear FreeBSD Community,
The April to June 2014 Quarterly Status Reports are being prepared
shortly. The submission deadline been extended to July 14, 2014, as
a call for submissions was not previously sent out due to an
oversight.
Status report submissions do not have to be very long -- basicall
On 18 July 2014 10:32, Daniel Peyrolon wrote:
> The problems arise when I try to use the console, the screen just shows a
> static image of the last xorg frame, with some weird colors.
I presume you mean you try to access the console by pressing
Ctrl-Alt-F1 (for example), and then see the static
On 18 July 2014 12:36, Daniel Peyrolon wrote:
> I basically installed from a FreeBSD VT enabled ISO.
Ok, it seems those are not available any longer.
To confirm that you're actually using vt, check "sysctl kern.vty". It
will report either sc, vt, or an error. If you get an error the
kernel pre
On 1 August 2014 17:18, John-Mark Gurney wrote:
> So, I decided to play around w/ vt after the recent UTF-8 discussion,
> and noticed some issues w/ it...
>
> First, if you load the gallant font, things don't look very good... This
> is probably because of the fact that I'm using the vga driver:
On 22 August 2014 16:45, Marcel Moolenaar wrote:
>
> I have so far not been able to boot an image created
> by mkimg with a FreeBSD-hosted qemu.
> o VMware and VirtualBox are fine.
> o A non-FreeBSD hosted qemu also works fine.
For what it's worth, I have no trouble booting a mkimg-created im
Dear FreeBSD Community,
The deadline for the next FreeBSD Quarterly Status update is October 7,
for work done in July through September.
Status report submissions do not have to be very long. They may be
about anything happening in the FreeBSD project and community, and
provide a great way to in
On 10 September 2014 15:00, Jean-Sébastien Pédron wrote:
> Hello!
>
> I tried the following FreeBSD snapshot on my Clevo W860CU with UEFI
> enabled:
> FreeBSD-11.0-CURRENT-amd64-20140903-r270990-memstick.img
Thanks for trying it out.
> The boot fails early with the following error:
> panic: BIOS
On 15 April 2013 16:12, Cy Schubert wrote:
> The existing license isn't that BSD-friendly either, which is why it lives
> in contrib/. I think the 5.1.X GPLv2 is about the same friendliness as
> Darren's IPF 4.1.X license. As long as it's not in GENERIC should be fine.
> A person can always load i
On Mon, 24 Oct 2022 at 22:11, void wrote:
>
> hello freebsd-current@,
>
> this started appearing in dmesg
>
> ns8250: UART FCR is broken
> ns8250: UART FCR is broken
This message was added as part of Colin's work to support FreeBSD in
the Firecracker VMM
https://cgit.freebsd.org/src/commit/?id=c4
On Thu, 16 Dec 2021 at 11:49, Gleb Smirnoff wrote:
>
> So I'm fine with removal [of ce, cp drivers] if anybody demonstrates
> me a non-zero cost of leaving the drivers in.
I just found PR264160: likely heap overflow in driver for Cronyx
[ce(4), cp(4)] adapters (others also possibly affected)
http
On Thu, 2 Mar 2023 at 05:14, Dimitry Andric wrote:
>
> WITHOUT_SYSTEM_COMPILER
> Do not opportunistically skip building a cross-compiler during
> the bootstrap phase of the build. Normally, if the currently
...
> I find the double negative phrasing "do not skip" alw
On Fri, 31 Mar 2023 at 12:38, Charlie Li wrote:
>
> Konstantin Belousov wrote:
> > The branch main has been updated by kib:
> >
> > URL:
> > https://cgit.FreeBSD.org/src/commit/?id=61194e9852e641d1533cd04a5679d6042ff975d3
> >
> > commit 61194e9852e641d1533cd04a5679d6042ff975d3
> > Author: Kon
FreeBSD supports up to 256 CPU cores in the default kernel configuration
(on Tier-1 architectures). Systems with more than 256 cores are
available now, and will become increasingly common over FreeBSD 14’s
lifetime. The FreeBSD Foundation is supporting the effort to increase
MAXCPU, and PR269572[
On Fri, 12 May 2023 at 09:26, Oleg Lelchuk wrote:
>
> I don't want to go through the hassle of filling a bug with my vendor. I will
> just wait for you, guys, to update the stand implementation. Thank you for
> explaining to me what causes this issue.
This issue is tracked in PR 265980 if you w
As previously mentioned[1] FreeBSD 14.0 will include OpenSSL 3.0. We
expect to merge the update to main in the near future (within the next
week or two) and are ready for wider testing.
Supported by the FreeBSD Foundation, Pierre Pronchery has been working
on the update in the src tree, with assi
Last night I merged OpenSSL 3.0 to main. This, along with the update
to Clang 16 and other recent changes may result in some challenges
over the next few days or weeks for folks following -CURRENT, such as
ports that need to be updated or unanticipated issues in the base
system.
We need to get thi
On Sat, 24 Jun 2023 at 07:11, David Wolfskill wrote:
>
> Running:
> FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #405
> main-n263767-764464af4968: Fri Jun 23 11:42:14 UTC 2023
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64 140009
> > > This could be a dependency issue; would you check if removing the
> > > following $OBJTOP subdirs addresses the issue:
> > >
> > > secure/lib/libcrypto
> > > secure/lib/libssl
> > > obj-lib32/secure/lib/libcrypto
> > > obj-lib32/secure/lib/libssl
> > >
> The build was successful; after the re
On Fri, 5 May 2023 at 09:38, Ed Maste wrote:
>
> FreeBSD supports up to 256 CPU cores in the default kernel configuration
> (on Tier-1 architectures). Systems with more than 256 cores are
> available now, and will become increasingly common over FreeBSD 14’s
> lifetime. The Fre
FreeBSD currently uses 9600 bps as the default for serial
communication -- in the boot loader, kernel serial console, /etc/ttys,
and so on. This was consistent with most equipment in the 90s, when
these defaults were established. Today 115200 bps seems to be much
more common, and I'm proposing that
On Fri, 8 Sept 2023 at 19:33, Glen Barber wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> The first BETA build of the 14.0-RELEASE release cycle is now available.
>
...
> The freebsd-update(8) utility supports binary upgrades of amd64 and i386
> systems running earlier FreeBSD rel
On Sat, 30 Sept 2023 at 14:24, Philip Homburg wrote:
>
> >Note, releases from 13.2 and earlier are
> >still problematic due to a file name being replaced with a directory of
> >the same name. A patch is being tested currently, and we hope to have
> >this resolved for 14.0-BETA4.
>
> I tried upgra
On Wed, 4 Oct 2023 at 05:42, Mariusz Zaborski wrote:
>
> On Tue, Oct 03, 2023 at 09:43:41PM -0700, Michael Dexter wrote:
> > In exercising the build options on 14.0-BETA4, WITHOUT_CAPSICUM and
> > WITHOUT_CASPER appear to be in an ambiguous state: They are present but
> > ignored. Fortunately src.
On Sat, 7 Oct 2023 at 13:35, György Pásztor wrote:
>
> Hi Glen,
>
> The new betas broke the functionality to boot from ventoy.
Unfortunately the way Ventoy handles FreeBSD booting is somewhat
fragile and this sort of breakage is not surprising. I suspect the
Ventoy authors will have to release an
On Thu, 12 Oct 2023 at 00:11, Cameron Katri wrote:
>
> The FreeBSD-14.0-BETA5-arm64-aarch64-zfs.raw.xz (maybe others, I didn't
> check) has a rc.conf with a ton of repeated lines. I tried looking at
> why this would be, but the release scripts to create this image went
> right over my head.
Would
101 - 200 of 345 matches
Mail list logo
