Comparing the old and new 32-bit arm limits to arm64 . . .
arm:
-#defineMAXDSIZ (512UL*1024*1024) /* max data size */
+#defineMAXDSIZ (1856UL*1024*1024) /* max data size */
vs. arm64:
#define MAXDSIZ (1*1024*1024*1024) /* max data size */
On 2020-Dec-31, at 18:07, Mark Millard wrote:
> Comparing the old and new 32-bit arm limits to arm64 . . .
>
> arm:
>
> -#define MAXDSIZ (512UL*1024*1024) /* max data size */
> +#define MAXDSIZ (1856UL*1024*1024) /* max data size */
>
> vs. arm64:
>
> #
As of this update the only amd64 system that I have access
to (a ThreadRipper 1950X) now displays a blank screen until
kernel messages start showing up, with or without:
hw.vga.textmode="1"
The system is not configured for EFI booting of FreeBSD:
# gpart show -p /dev/nvd2
=>40 187538492
On 2021-Jan-2, at 20:37, Mark Millard wrote:
> As of this update the only amd64 system that I have access
> to (a ThreadRipper 1950X) now displays a blank screen until
> kernel messages start showing up, with or without:
>
> hw.vga.textmode="1"
>
> The system is not configured for EFI booting o
The following error message makes no mention of WITHOUT_WERROR= use and stops
the
build. As far as I can tell normally one does not use MK_WERROR= directly.
make: "/usr/fbsd/mm-src/share/mk/bsd.opts.mk" line 110: "NO_WERROR is defined,
but deprecated. Please use MK_WERROR=no instead."
Also: How
On 2021-Jan-7, at 14:16, Mark Millard wrote:
> The following error message makes no mention of WITHOUT_WERROR= use and stops
> the
> build. As far as I can tell normally one does not use MK_WERROR= directly.
>
> make: "/usr/fbsd/mm-src/share/mk/bsd.opts.mk" line 110: "NO_WERROR is
> defined
Jessica Clarke jrtc27 at freebsd.org wrote on
Fri Jan 8 19:13:36 UTC 2021 :
. . .
> This broke powerpc and powerpc64:
>
> In file included from ioctl.c:33:
> In file included from /home/jrtc27/src/sys/./cam/scsi/scsi_pass.h:35:
> In file included from /home/jrtc27/src/sys/cam/cam_ccb.h:46:
> In f
Dimitry Andric dim at FreeBSD.org wrote on
Fri Jan 8 22:39:16 UTC 2021 :
> . . .
> The general style in sbin/nvmecontrol apppears to print uint64_t types
> using %j, so I'm using that instead of the more general (but admittedly
> ugly) PRIu64.
> . . .
> - printf(" F
> The branch main has been updated by tuexen:
>
> URL:
> https://cgit.FreeBSD.org/src/commit/?id=6685e259e31995e20fa2f9cd7e19a292fcdc6877
>
>
> commit 6685e259e31995e20fa2f9cd7e19a292fcdc6877
> Author: Michael Tuexen
> AuthorDate: 2021-01-08 07:51:39 +
> Commit: Michael Tuexen
>
For:
> +#if defined(__i386__) || defined(__amd64__)
> mode = parse_uefi_con_out();
> +#else
> + mode = 0;
> +#endif
> if ((mode & (RB_SERIAL | RB_MULTIPLE)) == 0) {
> conout->EnableCursor(conout, FALSE);
> gfx_state.tg_cursor_visible = false;
I will not
This seems to have missed updates related to:
-rw-r--r-- 1 root wheel 10506 Jan 7 19:14:22 2021 sys/powerpc/conf/GENERIC64
-rw-r--r-- 1 root wheel 1413 Dec 24 15:17:15 2020
sys/powerpc/conf/GENERIC64-NODEBUG
There is also:
-rw-r--r-- 1 root wheel 9760 Jan 7 19:14:22 2021
sys/power
Ulrich Spörlein uqs at FreeBSD.org wrote on
Wed Jan 20 09:49:49 UTC 2021 :
> While here, drop the redundant branch name from the git output and don't
> count commits in shallow clones.
>
The branch name part of the patch breaks how I work with multiple
branches and I will be locally "re
On 2021-Jan-21, at 09:24, Mark Millard wrote:
> Ulrich Spörlein uqs at FreeBSD.org wrote on
> Wed Jan 20 09:49:49 UTC 2021 :
>
>>While here, drop the redundant branch name from the git output and don't
>>count commits in shallow clones.
>>
>
> The branch name part of the patch break
> On Sun, 31 Jan 2021 at 19:12, Antoine Brodin wrote:
> >
> > On Sun, Jan 10, 2021 at 12:12 PM Tijl Coosemans
> > wrote:
> > >
> > > On Thu, 7 Jan 2021 11:05:55 GMT Alex Richardson
> > > wrote:
. . .
> > > NO_WERROR is also used by some ports [1] (which have to build against
> > > multiple versi
Jessica Clarke jrtc27 at freebsd.org wrote on
Mon Jan 25 23:56:41 UTC 2021 :
> On 25 Jan 2021, at 22:42, Mateusz Guzik wrote:
> >
> > The branch main has been updated by mjg:
> >
> > URL:
> > https://cgit.FreeBSD.org/src/commit/?id=054ce2b0371042c0dbc4b3ab1d7e7795ad75d51e
> >
> > commit 054ce
Alexander V. Chernikov melifaro at freebsd.org wrote on
Tue Feb 16 21:26:00 UTC 2021 :
> 16.02.2021, 20:43, "Mateusz Guzik" :
> > This breaks the built at least without INET6.
> It would help if you could share the actual build error.
> I see -Wunused for 2 function (which I will fix soon), but I'
Nathan Whitehorn nwhitehorn at FreeBSD.org wrote on
Tue Feb 23 21:24:30 UTC 2021 :
> +# Update the ESP (EFI System Partition) with the new bootloader if we have
> an ESP
> +if [ -d "$BSDINSTALL_CHROOT/boot/efi" ]; then
> case $(uname -m) in
> arm64) ARCHBOOTNAME=aa64 ;;
>
Jessica Clarke jrtc27 at freebsd.org wrote on
Sun Feb 28 01:25:47 UTC 2021 :
> On 28 Feb 2021, at 01:22, Brandon Bergren wrote:
> >
> > On Sat, Feb 27, 2021, at 7:10 PM, Brandon Bergren wrote:
> >> This is mistakenly detecting pseries powerpc64* as an EFI platform and
> >> causing install to er
On 2021-Feb-27, at 23:22, Mark Millard wrote:
> Jessica Clarke jrtc27 at freebsd.org wrote on
> Sun Feb 28 01:25:47 UTC 2021 :
>
>> On 28 Feb 2021, at 01:22, Brandon Bergren wrote:
>>>
>>> On Sat, Feb 27, 2021, at 7:10 PM, Brandon Bergren wrote:
This is mistakenly detecting pseries powerp
bdragon at FreeBSD.org wrote on
Wed Mar 3 03:38:18 UTC 2021 :
> grep -q rather.
>
> In any case, instead of checking for directory existence, checking whether
> something is actually mounted there.
>
> On Tue, Mar 2, 2021, at 9:34 PM, Brandon Bergren wrote:
> > OK, how about this as an idea the
Nathan Whitehorn nwhitehorn at FreeBSD.org wrote on
Sat Mar 6 02:01:30 UTC 2021 :
> Restore /boot/efi to mtree.
>
> Instead of whether /boot/efi exists, which it now always does, including
> on systems that don't and can't use EFI, use whether /boot/efi is
> present in fstab t
On 2021-Mar-5, at 22:05, Mark Millard wrote:
>
> Nathan Whitehorn nwhitehorn at FreeBSD.org wrote on
> Sat Mar 6 02:01:30 UTC 2021 :
>
>>Restore /boot/efi to mtree.
>>
>>Instead of whether /boot/efi exists, which it now always does, including
>>on systems that don't and can't use
On 2021-Mar-6, at 01:01, Mark Millard wrote:
> On 2021-Mar-5, at 22:05, Mark Millard wrote:
>>
>> Nathan Whitehorn nwhitehorn at FreeBSD.org wrote on
>> Sat Mar 6 02:01:30 UTC 2021 :
>>
>>> Restore /boot/efi to mtree.
>>>
>>> Instead of whether /boot/efi exists, which it now always does
Jessica Clarke jrtc27 at freebsd.org wrote on
Wed Mar 10 18:36:39 UTC 2021 :
> On 10 Mar 2021, at 18:07, Olivier Houchard wrote:
> >
> > The branch main has been updated by cognet:
> >
> > URL:
> > https://cgit.FreeBSD.org/src/commit/?id=c328f64d81079bad5064c8a387883df50ab5aaed
> >
> > commit
John Baldwin jhb at FreeBSD.org wrote on
Fri Mar 12 19:45:17 UTC 2021 :
> On 3/12/21 11:06 AM, Dimitry Andric wrote:
> > On 12 Mar 2021, at 19:45, Alex Richardson
> > wrote:
> >>
> >> The branch main has been updated by arichardson:
> >>
> >> URL:
> >> https://cgit.FreeBSD.org/src/commit/?id=05
Konstantin Belousov kostikbel at gmail.com wrote on
Sat May 15 19:42:08 UTC 2021 :
> On Sat, May 15, 2021 at 07:01:07AM +, Lutz Donnerhacke wrote:
> > . . .
> > +static int
> > +IcmpAliasIn1(struct libalias *la, struct ip *pip)
> > +{
> > + LIBALIAS_LOCK_ASSERT(la);
> > struct alias_link
Hartmann, O. o.hartmann at walstatt.org wrote on
Sun Jun 20 21:18:13 UTC 2021 :
. ..
> > >> On 20 Jun 2021, at 15:58, Hartmann, O. > wrote:
> . . .
> > >>> running FreeBSD 14.0-CURRENT #13 main-n247423-7bd295750b1: Fri Jun 18
> > >>> 17:32:58 CEST
> > >>> 2021 amd64, buildworld fails with the
From: Doug Moore wrote oo
Date: Sat, 25 Dec 2021 11:56:10 -0600 :
Guido -
> I've made three vm changes this month, though it's taken me 6 commits to
> do it.
>
> The first change was trivial.
>
> The last commit before the second change was
> commit 02732f945ed2ec2b4fd03421923720608b28a615
> an
[Resending with dev-commits-src-main@FreeBSD.org CC'd.]
On 2021-Dec-29, at 13:38, Mark Millard wrote:
Building 33812d60b960 ( so after 6b1c5775d1c2 ) and installing
and rebooting did not put in place a /lib/libc++.so.1 but
delete-old-libs removed the /usr/lib/libc++.so.1 .
(Luckily my environme
From: Kyle Evans wrote on
Date: Fri, 31 Dec 2021 09:37:16 -0600 :
> . . .
> This is a mindset that we all take, but we really need to work towards
> improving. Once we're watching fallout logs on the official builders,
> we've already lost. This is the kind of thing that helps promote the
> ide
Warner Losh wrote on
Date: Wed, 5 Jan 2022 17:06:35 -0700 :
> On Wed, Jan 5, 2022 at 5:04 PM Gleb Smirnoff wrote:
>
> > On Wed, Jan 05, 2022 at 04:18:25PM -0700, Warner Losh wrote:
> > W> On Wed, Jan 5, 2022, 3:47 PM Gleb Smirnoff
> > wrote:
> > W>
> > W> > On Wed, Jan 05, 2022 at 08:13:03PM
Ed Maste emaste at FreeBSD.org wrote on
Tue Jul 27 21:24:57 UTC 2021 :
. . .
> diff --git a/tools/build/options/WITHOUT_KERNEL_SYMBOLS
> b/tools/build/options/WITHOUT_KERNEL_SYMBOLS
> index 79856e28c1aa..33fa2c4f1c97 100644
> --- a/tools/build/options/WITHOUT_KERNEL_SYMBOLS
> +++ b/tools/build/op
32 matches
Mail list logo
