Re: Problem building kernel

On 24.12.2023 14:18, tue...@freebsd.org wrote: Dear all, I just tried to build world and kernel on a 64-bit PPC system. make -j 32 buildworld ran without problems. However make kernel KERNCONF=GENERIC breaks with .. --- all_subdir_accf_data --- --- accf_data.kld --- ld -m elf32ppc_fbsd

Problem building kernel

Dear all, I just tried to build world and kernel on a 64-bit PPC system. make -j 32 buildworld ran without problems. However make kernel KERNCONF=GENERIC breaks with .. --- all_subdir_accf_data --- --- accf_data.kld --- ld -m elf32ppc_fbsd -warn-common --build-id=sha1 --no-toc-optimize -r

Re: Proposal: Disable compression of newsyslog by default

On Sat, 23 Dec 2023 15:14:20 -0800 Xin Li wrote: > On 2023-12-23 07:09, Enji Cooper wrote: > > This impacts embedded systems or jails which use UFS as the default > > /var/log backed device. There are quite a few larger consumers of > > FreeBSD out there that still use UFS instead of ZFS. > > I

Re: Proposal: Disable compression of newsyslog by default

On 23 December 2023 09:18:23 EET, Xin Li wrote: >Hi, > >Inspired by D42961, I propose that we move forward with disabling the >compression by default in newsyslog, as implemented in >https://reviews.freebsd.org/D43169 > >Historically, newsyslog has compressed rotated log files to save disk

[LAST OFFICIAL REMINDER] Call for 2023Q4 status reports

Dear FreeBSD Community, The deadline for the next FreeBSD Status Report update is December, 31st 2023 for work done since the last round of quarterly reports: October 2023 - December 2023. I would like to remind you that reports are published on a quarterly basis and are usually collected during

Re: Proposal: Disable compression of newsyslog by default

On 2023-12-23 07:09, Enji Cooper wrote: This impacts embedded systems or jails which use UFS as the default /var/log backed device. There are quite a few larger consumers of FreeBSD out there that still use UFS instead of ZFS. I appreciate your feedback! Thank you for pointing out the

Re: Proposal: Disable compression of newsyslog by default

On 2023-12-23 10:17, Ceri Davies wrote: I really don’t like the idea of adding flags that make the program ignore a config file. I also think this is premature until ZFS installs are default on all architectures. However, if you must (and I see you have) change this, please don’t call the

Re: Proposal: Disable compression of newsyslog by default

On 2023-12-23 13:08, Steve Kargl wrote: On Sat, Dec 23, 2023 at 11:13:23AM -0800, Xin Li wrote: I appreciate your perspective on this issue. However, I believe there are additional benefits to modifying the newsyslog code (which is already done in commit 906748d208d3, by the way) beyond what

Re: Proposal: Disable compression of newsyslog by default

On 23 Dec 2023, at 15:23, Craig Leres wrote: > On 12/23/23 06:52, Konstantin Belousov wrote: >> This is strange change at best. I have no opinion about the disabling >> of compression of the rotated logs by default, but we already have knobs >> to do that. Adding a knob that disables (or

Re: Proposal: Disable compression of newsyslog by default

On 12/23/23 06:52, Konstantin Belousov wrote: This is strange change at best. I have no opinion about the disabling of compression of the rotated logs by default, but we already have knobs to do that. Adding a knob that disables (or enables) other knobs to work is weird. I totally agree.

Re: Proposal: Disable compression of newsyslog by default

On Sat, Dec 23, 2023 at 11:13:23AM -0800, Xin Li wrote: > > I appreciate your perspective on this issue. However, I believe there are > additional benefits to modifying the newsyslog code (which is already done > in commit 906748d208d3, by the way) beyond what can be achieved by simply >

Re: Proposal: Disable compression of newsyslog by default

On 2023-12-23 06:52, Konstantin Belousov wrote: On Fri, Dec 22, 2023 at 11:18:23PM -0800, Xin Li wrote: Hi, Inspired by D42961, I propose that we move forward with disabling the compression by default in newsyslog, as implemented in https://reviews.freebsd.org/D43169 Historically, newsyslog

Re: Proposal: Disable compression of newsyslog by default

On 2023-12-23 00:51, Miroslav Lachman wrote: On 23/12/2023 08:18, Xin Li wrote: Hi, Inspired by D42961, I propose that we move forward with disabling the compression by default in newsyslog, as implemented in https://reviews.freebsd.org/D43169 Historically, newsyslog has compressed rotated

Re: Proposal: Disable compression of newsyslog by default

> On 23. Dec 2023, at 16:10, Enji Cooper wrote: > >  >> On Dec 22, 2023, at 23:18, Xin Li wrote: >> >> Hi, >> >> Inspired by D42961, I propose that we move forward with disabling the >> compression by default in newsyslog, as implemented in >> https://reviews.freebsd.org/D43169 >> >>

Re: Proposal: Disable compression of newsyslog by default

> On Dec 22, 2023, at 23:18, Xin Li wrote: > > Hi, > > Inspired by D42961, I propose that we move forward with disabling the > compression by default in newsyslog, as implemented in > https://reviews.freebsd.org/D43169 > > Historically, newsyslog has compressed rotated log files to save

Re: Proposal: Disable compression of newsyslog by default

On Fri, Dec 22, 2023 at 11:18:23PM -0800, Xin Li wrote: > Hi, > > Inspired by D42961, I propose that we move forward with disabling the > compression by default in newsyslog, as implemented in > https://reviews.freebsd.org/D43169 > > Historically, newsyslog has compressed rotated log files to

Re: Proposal: Disable compression of newsyslog by default

W dniu 23.12.2023 o 09:51, Miroslav Lachman pisze: On 23/12/2023 08:18, Xin Li wrote: Hi, Inspired by D42961, I propose that we move forward with disabling the compression by default in newsyslog, as implemented in https://reviews.freebsd.org/D43169 Historically, newsyslog has compressed

Re: Proposal: Disable compression of newsyslog by default

On 23/12/2023 08:18, Xin Li wrote: Hi, Inspired by D42961, I propose that we move forward with disabling the compression by default in newsyslog, as implemented in https://reviews.freebsd.org/D43169 Historically, newsyslog has compressed rotated log files to save disk space. This approach

Re: Proposal: Disable compression of newsyslog by default

Xin Li wrote on 2023-12-22 at 23:18:23: > Inspired by D42961, I propose that we move forward with disabling the > compression by default in newsyslog, as implemented in > https://reviews.freebsd.org/D43169 [...] > Therefore I would propose that we change the default compression setting > to

Proposal: Disable compression of newsyslog by default

Hi, Inspired by D42961, I propose that we move forward with disabling the compression by default in newsyslog, as implemented in https://reviews.freebsd.org/D43169 Historically, newsyslog has compressed rotated log files to save disk space. This approach was valuable in the early days where

Re: symlink to /boot/loader.efi

On Fri, 22 Dec 2023 12:17:15 -0700 Warner Losh wrote: > On Fri, Dec 22, 2023 at 2:36 AM Toomas Soome wrote: > > > > > > > > On 22. Dec 2023, at 11:09, Mark Millard wrote: > > > > > > Tomoaki AOKI wrote on > > > Date: Thu, 21 Dec 2023 23:21:00 UTC : > > > > > >> On Thu, 21 Dec 2023 14:22:14

Re: symlink to /boot/loader.efi

On Dec 22, 2023, at 13:49, Konstantin Belousov wrote: > On Fri, Dec 22, 2023 at 02:03:56PM -0700, Warner Losh wrote: >> Yes. I'd prefer to make this more parameterized, maybe with sanity checks. >> >> That is, there'd be a tool that would do the right thing, based on what you >> tell it to do.

Re: symlink to /boot/loader.efi

On Fri, Dec 22, 2023 at 02:03:56PM -0700, Warner Losh wrote: > Yes. I'd prefer to make this more parameterized, maybe with sanity checks. > > That is, there'd be a tool that would do the right thing, based on what you > tell it to do. we'd set the defaults to be a default install. If you want >

Re: symlink to /boot/loader.efi

On Fri, Dec 22, 2023 at 8:00 AM Tomoaki AOKI wrote: > On Fri, 22 Dec 2023 12:02:54 +0200 > Toomas Soome wrote: > > > > On 22. Dec 2023, at 11:54, Mark Millard wrote: > > > > > > On Dec 22, 2023, at 01:36, Toomas Soome wrote: > > >> > > >> > > >> > > >>> On 22. Dec 2023, at 11:09, Mark Millard

Re: symlink to /boot/loader.efi

On Fri, Dec 22, 2023 at 2:36 AM Toomas Soome wrote: > > > > On 22. Dec 2023, at 11:09, Mark Millard wrote: > > > > Tomoaki AOKI wrote on > > Date: Thu, 21 Dec 2023 23:21:00 UTC : > > > >> On Thu, 21 Dec 2023 14:22:14 +0100 > >> Dimitry Andric wrote: > >> > >>> Yeah, my procedure is the same

Re: symlink to /boot/loader.efi

On Fri, 22 Dec 2023 16:15:42 +0200 Toomas Soome wrote: > > > > On 22. Dec 2023, at 16:07, Konstantin Belousov wrote: > > > > On Fri, Dec 22, 2023 at 11:36:24AM +0200, Toomas Soome wrote: > >> > >> > >>> On 22. Dec 2023, at 11:09, Mark Millard wrote: > >>> > >>> Tomoaki AOKI wrote on >

Re: symlink to /boot/loader.efi

On Fri, 22 Dec 2023 12:02:54 +0200 Toomas Soome wrote: > > On 22. Dec 2023, at 11:54, Mark Millard wrote: > > > > On Dec 22, 2023, at 01:36, Toomas Soome wrote: > >> > >> > >> > >>> On 22. Dec 2023, at 11:09, Mark Millard wrote: > >>> > >>> Tomoaki AOKI wrote on > >>> Date: Thu, 21 Dec

Re: symlink to /boot/loader.efi

> On 22. Dec 2023, at 16:07, Konstantin Belousov wrote: > > On Fri, Dec 22, 2023 at 11:36:24AM +0200, Toomas Soome wrote: >> >> >>> On 22. Dec 2023, at 11:09, Mark Millard wrote: >>> >>> Tomoaki AOKI wrote on >>> Date: Thu, 21 Dec 2023 23:21:00 UTC : >>> On Thu, 21 Dec 2023 14:22:14

Re: symlink to /boot/loader.efi

On Fri, Dec 22, 2023 at 11:36:24AM +0200, Toomas Soome wrote: > > > > On 22. Dec 2023, at 11:09, Mark Millard wrote: > > > > Tomoaki AOKI wrote on > > Date: Thu, 21 Dec 2023 23:21:00 UTC : > > > >> On Thu, 21 Dec 2023 14:22:14 +0100 > >> Dimitry Andric wrote: > >> > >>> Yeah, my procedure

Re: symlink to /boot/loader.efi

> On 22. Dec 2023, at 11:54, Mark Millard wrote: > > On Dec 22, 2023, at 01:36, Toomas Soome wrote: >> >> >> >>> On 22. Dec 2023, at 11:09, Mark Millard wrote: >>> >>> Tomoaki AOKI wrote on >>> Date: Thu, 21 Dec 2023 23:21:00 UTC : >>> On Thu, 21 Dec 2023 14:22:14 +0100

Re: symlink to /boot/loader.efi

On Dec 22, 2023, at 01:36, Toomas Soome wrote: > > > >> On 22. Dec 2023, at 11:09, Mark Millard wrote: >> >> Tomoaki AOKI wrote on >> Date: Thu, 21 Dec 2023 23:21:00 UTC : >> >>> On Thu, 21 Dec 2023 14:22:14 +0100 >>> Dimitry Andric wrote: >>> Yeah, my procedure is the same as

Re: symlink to /boot/loader.efi

> On 22. Dec 2023, at 11:09, Mark Millard wrote: > > Tomoaki AOKI wrote on > Date: Thu, 21 Dec 2023 23:21:00 UTC : > >> On Thu, 21 Dec 2023 14:22:14 +0100 >> Dimitry Andric wrote: >> >>> Yeah, my procedure is the same as yours: I first copy >>> /boot/efi/efi/freebsd/loader.efi to

Re: symlink to /boot/loader.efi

Tomoaki AOKI wrote on Date: Thu, 21 Dec 2023 23:21:00 UTC : > On Thu, 21 Dec 2023 14:22:14 +0100 > Dimitry Andric wrote: > > > Yeah, my procedure is the same as yours: I first copy > > /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, then > > copy the freshly built and

Re: symlink to /boot/loader.efi

On Thu, 21 Dec 2023 14:22:14 +0100 Dimitry Andric wrote: > Yeah, my procedure is the same as yours: I first copy > /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, then > copy the freshly built and installed /boot/loader.efi to > /boot/efi/efi/freebsd/loader.efi. I don't

Re: symlink to /boot/loader.efi

On Thu, Dec 21, 2023, 8:18 AM Jeffrey Bouquet wrote: > I am wondering if all the information in this thread present and future > should be included in > the scenarios at the bottom of /usr/ports/UPDATING with technical > explanations about > how and why? AFAIK the file was created before UEFI

Re: symlink to /boot/loader.efi

I am wondering if all the information in this thread present and future should be included in the scenarios at the bottom of /usr/ports/UPDATING with technical explanations about how and why? AFAIK the file was created before UEFI and thus in that regard obsolete. On Thu, 21 Dec 2023 12:59:54

Re: symlink to /boot/loader.efi

Yeah, my procedure is the same as yours: I first copy /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, then copy the freshly built and installed /boot/loader.efi to /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why this could not be just another step in

Re: symlink to /boot/loader.efi

Hello Dimitry, For a moment I forgot that efiboot is a fat system... I am inspired on what installworld does to kernel and kernel.old. I was thinking in something like it but with efi boot, something automatic. Thanks! Dimitry Andric escreveu no dia quinta, 21/12/2023 à(s) 12:48: > On 21 Dec

Re: symlink to /boot/loader.efi

On 21 Dec 2023, at 13:22, Nuno Teixeira wrote: > > On every current upgrade I update efi/freebsd/loader.efi (amd64) and > efi/boot/boota64 (aarch64) with new copies on /boot/loader.efi. > For safety reasons I always have a copy of last running loader by appending > "-old.efi" to loader or

symlink to /boot/loader.efi

Hello all, On every current upgrade I update efi/freebsd/loader.efi (amd64) and efi/boot/boota64 (aarch64) with new copies on /boot/loader.efi. For safety reasons I always have a copy of last running loader by appending "-old.efi" to loader or boota64 and use beinstall to get BEs if needed. Is

Re: The ports quarterly tree 2023Q4 is borked for www/firefox

On 12/18/23 08:35, Dimitry Andric wrote: On 18 Dec 2023, at 13:59, Dennis Clarke wrote: I do not know where else to post this. Seems that a bug report about the problem does not mean much : Bug 275814 - www/firefox has the wrong version in the Makefile

Re: The ports quarterly tree 2023Q4 is borked for www/firefox

On 18 Dec 2023, at 13:59, Dennis Clarke wrote: > > > I do not know where else to post this. Seems that a bug report about the > problem does not mean much : > > > Bug 275814 - www/firefox has the wrong version in the Makefile > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275814 Should

The ports quarterly tree 2023Q4 is borked for www/firefox

I do not know where else to post this. Seems that a bug report about the problem does not mean much : Bug 275814 - www/firefox has the wrong version in the Makefile https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275814 This issue is pretty clear. This morning I flushed out my ports tree

[2 WEEKS LEFT REMINDER] Call for 2023Q4 status reports

Dear FreeBSD Community, The deadline for the next FreeBSD Status Report update is December, 31st 2023 for work done since the last round of quarterly reports: October 2023 - December 2023. I would like to remind you that reports are published on a quarterly basis and are usually collected during

Re: make installworld fails because /usr/include/c++/v1/__tuple is a file

On 13 Dec 2023, at 19:07, John Baldwin wrote: > > On 12/10/23 8:43 AM, Dimitry Andric wrote: >> On 10 Dec 2023, at 15:11, Herbert J. Skuhra wrote: >>> >>> On Sun, Dec 10, 2023 at 01:22:38PM +, John F Carr wrote: On arm64 running CURRENT from two weeks ago I updated to

Re: make installworld fails because /usr/include/c++/v1/__tuple is a file

On 12/10/23 8:43 AM, Dimitry Andric wrote: On 10 Dec 2023, at 15:11, Herbert J. Skuhra wrote: On Sun, Dec 10, 2023 at 01:22:38PM +, John F Carr wrote: On arm64 running CURRENT from two weeks ago I updated to c711af772782 Bump __FreeBSD_version for llvm 17.0.6 merge and built and

Re: compile 13.2p8 on a recent current fails: compiler issue ?

Dimitry Andric writes: > henry vogt writes: > > ===> usr.sbin/zic (obj,all,install) > > Building /usr/obj/usr/src/13.2/amd64.amd64/tmp/obj-tools/usr.sbin/zic/zic.o > > --- zic.o --- > > /usr/src/13.2/contrib/tzcode/zic.c:464:8: error: an attribute list cannot > > appear here > > 464 | static

Re: compile 13.2p8 on a recent current fails: compiler issue ?

On 13 Dec 2023, at 13:08, henry vogt wrote: > > attempt to compile 13.2p8 on a recent current fails: compiler issue ? > > ... > > ===> usr.sbin/zic (obj,all,install) > Building /usr/obj/usr/src/13.2/amd64.amd64/tmp/obj-tools/usr.sbin/zic/zic.o > --- zic.o --- >

compile 13.2p8 on a recent current fails: compiler issue ?

Hi attempt to compile 13.2p8 on a recent current fails: compiler issue ? ... ===> usr.sbin/zic (obj,all,install) Building /usr/obj/usr/src/13.2/amd64.amd64/tmp/obj-tools/usr.sbin/zic/zic.o --- zic.o --- /usr/src/13.2/contrib/tzcode/zic.c:464:8: error: an attribute list cannot appear here  

Re: upgrade failure

I think you are now left with a half-installed libc++ from the previous broken installworld. That is not likely to work correctly. Probably the way forward is to restore your /usr/include directory from a backup, and do the buildworld again after that. Alternatively, buildworld on another

Re: upgrade failure

On 12/12/23 1:16 PM, AN wrote: Hi Pete: After running make clean I now get the following error: i think Warner mentioned in this thread that a "make delete-old" or possibly "make delete-old-libs" to clean up some stuff. i've run into similar issues in the past and that seemed to

Re: upgrade failure

Hi Pete: On Mon, 11 Dec 2023, Pete Wright wrote: On 12/11/23 18:19, AN wrote: I just had this failure trying to upgrade from 14 to 15.  Any help fixing this would be appreciated. --- _SERINS --- install  -C -o root -g wheel -m 444

Re: upgrade failure

I think this is the make delete-old issue You usually can get away w/o running that step, but not this time, alas. Warner On Mon, Dec 11, 2023 at 8:24 PM Pete Wright wrote: > > > On 12/11/23 18:19, AN wrote: > > I just had this failure trying to upgrade from 14 to 15. Any help > > fixing

Re: upgrade failure

On 12/11/23 18:19, AN wrote: I just had this failure trying to upgrade from 14 to 15.  Any help fixing this would be appreciated. --- _SERINS --- install  -C -o root -g wheel -m 444 /usr/src/contrib/llvm-project/libcxx/include/__system_error/errc.h

upgrade failure

I just had this failure trying to upgrade from 14 to 15. Any help fixing this would be appreciated. --- _SERINS --- install -C -o root -g wheel -m 444 /usr/src/contrib/llvm-project/libcxx/include/__system_error/errc.h

Re: make installworld fails because /usr/include/c++/v1/__tuple is a file

On 10 Dec 2023, at 15:11, Herbert J. Skuhra wrote: > > On Sun, Dec 10, 2023 at 01:22:38PM +, John F Carr wrote: >> On arm64 running CURRENT from two weeks ago I updated to >> >> c711af772782 Bump __FreeBSD_version for llvm 17.0.6 merge >> >> and built and installed from source. make

Re: make installworld fails because /usr/include/c++/v1/__tuple is a file

On Sun, Dec 10, 2023 at 01:22:38PM +, John F Carr wrote: > On arm64 running CURRENT from two weeks ago I updated to > > c711af772782 Bump __FreeBSD_version for llvm 17.0.6 merge > > and built and installed from source. make installworld failed: > > install: target directory

make installworld fails because /usr/include/c++/v1/__tuple is a file

On arm64 running CURRENT from two weeks ago I updated to c711af772782 Bump __FreeBSD_version for llvm 17.0.6 merge and built and installed from source. make installworld failed: install: target directory `/usr/include/c++/v1/__tuple/' does not exist That pathname is a file: -r--r--r--

Re: nvme timeout issues with hardware and bhyve vm's

On Thu, Dec 07, 2023 at 04:19:12PM -0800, Chuck Tuffli wrote: > On Thu, Dec 7, 2023 at 2:39 PM Pete Wright wrote: > ... > > Hi Warner, just resurfacing this thread because I've had a few lockups > > on my workstation running 14.0-STABLE. I was able to capture a photo of > > the hang and this

Re: nvme timeout issues with hardware and bhyve vm's

Thanks. It may be worth checking the temp periodically and warning the user in case it is too high (70ºC+ or something). Even for devices that allow internal throttling, a user might wish to know whether the device neads a (better) heatsink. > On Dec 7, 2023, at 5:02 PM, Maxim Sobolev wrote:

Re: nvme timeout issues with hardware and bhyve vm's

How quickly it heats up depends on lots of factors. Usually those devices burn some 3-7 watts per stick at 100% load, so maybe this would give you some idea. At least some of them support several toggleable performance modes, which use throttling internally to limit power consumption to a certain

Re: nvme timeout issues with hardware and bhyve vm's

On Thu, Dec 7, 2023 at 2:39 PM Pete Wright wrote: ... > Hi Warner, just resurfacing this thread because I've had a few lockups > on my workstation running 14.0-STABLE. I was able to capture a photo of > the hang and this seems to be the most important line: > > nvme0: Resetting controller due to

Re: nvme timeout issues with hardware and bhyve vm's

On Dec 7, 2023, at 3:59 PM, Warner Losh wrote: > > > *Overheating caused hang of NVMe controller or PCI bridge on SSD, or > > Yes. Most drive's firmware when it overheats resets. There might be something > that the pci code can do when this happens to retrain the link, reprogram the > config

Re: nvme timeout issues with hardware and bhyve vm's

On Thu, Dec 7, 2023 at 4:09 PM Tomoaki AOKI wrote: > On Thu, 7 Dec 2023 14:38:37 -0800 > Pete Wright wrote: > > > > > > > On 10/13/23 7:34 PM, Warner Losh wrote: > > > > > > > > > > > the messages i posted in the start of the thread are from the VM > itself > > > (13.2-RELEASE). The

Re: nvme timeout issues with hardware and bhyve vm's

On 12/7/23 3:16 PM, Craig Leres wrote: On 12/7/23 15:09, Tomoaki AOKI wrote: If I myself encounter this kind of problem ON BARE METAL HARDWARE, I would usually suspect   *Overheating caused hang of NVMe controller or PCI bridge on SSD, or This would also be my first guess. Five years ago

Re: nvme timeout issues with hardware and bhyve vm's

On 12/7/23 2:49 PM, Warner Losh wrote: On Thu, Dec 7, 2023 at 3:38 PM Pete Wright > wrote: On 10/13/23 7:34 PM, Warner Losh wrote: > > >     the messages i posted in the start of the thread are from the VM itself >     

Re: nvme timeout issues with hardware and bhyve vm's

On 12/7/23 15:09, Tomoaki AOKI wrote: If I myself encounter this kind of problem ON BARE METAL HARDWARE, I would usually suspect *Overheating caused hang of NVMe controller or PCI bridge on SSD, or This would also be my first guess. Five years ago I had an nmve in an intel nuc that would

Re: nvme timeout issues with hardware and bhyve vm's

On Thu, 7 Dec 2023 14:38:37 -0800 Pete Wright wrote: > > > On 10/13/23 7:34 PM, Warner Losh wrote: > > > > > > > the messages i posted in the start of the thread are from the VM itself > > (13.2-RELEASE).  The zpool on the hypervisor (13.2-RELEASE) showed no > > such issues. > >

Re: nvme timeout issues with hardware and bhyve vm's

On Thu, Dec 7, 2023 at 3:38 PM Pete Wright wrote: > > > On 10/13/23 7:34 PM, Warner Losh wrote: > > > > > > > the messages i posted in the start of the thread are from the VM > itself > > (13.2-RELEASE). The zpool on the hypervisor (13.2-RELEASE) showed no > > such issues. > > > >

Re: nvme timeout issues with hardware and bhyve vm's

On 10/13/23 7:34 PM, Warner Losh wrote: the messages i posted in the start of the thread are from the VM itself (13.2-RELEASE).  The zpool on the hypervisor (13.2-RELEASE) showed no such issues. Based on your comment about the improvements in 14 I'll focus my efforts

Re: aarch64 and armv6 vs. armv7 support: armv6 is not supported, despite what "man arch" reports

On Dec 7, 2023, at 01:19, Dimitry Andric wrote: > On 7 Dec 2023, at 05:31, Mark Millard wrote: >> >> man arch reports: >> >> QUOTE >>Some machines support more than one FreeBSD ABI. Typically these are >>64-bit machines, where the “native” LP64 execution environment is >>

Re: aarch64 and armv6 vs. armv7 support: armv6 is not supported, despite what "man arch" reports

On Thu, Dec 7, 2023, 2:19 AM Dimitry Andric wrote: > On 7 Dec 2023, at 05:31, Mark Millard wrote: > > > > man arch reports: > > > > QUOTE > > Some machines support more than one FreeBSD ABI. Typically these are > > 64-bit machines, where the “native” LP64 execution environment is > >

Re: aarch64 and armv6 vs. armv7 support: armv6 is not supported, despite what "man arch" reports

Hi; Am Wed, Dec 06, 2023 at 08:31:13PM -0800 schrieb Mark Millard: > man arch reports: > > QUOTE > Some machines support more than one FreeBSD ABI. Typically these are > 64-bit machines, where the “native” LP64 execution environment is > accompanied by the “legacy” ILP32

Re: aarch64 and armv6 vs. armv7 support: armv6 is not supported, despite what "man arch" reports

On 7 Dec 2023, at 05:31, Mark Millard wrote: > > man arch reports: > > QUOTE > Some machines support more than one FreeBSD ABI. Typically these are > 64-bit machines, where the “native” LP64 execution environment is > accompanied by the “legacy” ILP32 environment, which was the

aarch64 and armv6 vs. armv7 support: armv6 is not supported, despite what "man arch" reports

man arch reports: QUOTE Some machines support more than one FreeBSD ABI. Typically these are 64-bit machines, where the “native” LP64 execution environment is accompanied by the “legacy” ILP32 environment, which was the historical 32-bit predecessor for 64-bit evolution.

installkernel with PORTS_MODULES+=graphics/drm-515-kmod stopped working

I build{world,kernel} on one machine but install everything from the target machine, with /usr/obj and /usr/src from the build machine nfs mounted. /etc/src.conf (on target and build machines) has PORTS_MODULES+=graphics/drm-515-kmod to build this port at the same time. This used to work at least

main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information

The following sort of thing is happening a lot: Ryzen 9 7950X3D using a USB Ethernet dongle that I've historically used on occasion, sometimes for long periods . . . Example contexts for the issue have been: FreeBSD 15.0-CURRENT #126 main-n266130-d521abdff236-dirty: Tue Oct 24 18:17:40 PDT

Re: "options MAXMEMDOM=2" vs. amd64 DBG kernel booting: 3000+ "kernel: Process (pid 1) got signal 5" notices during booting

On Nov 23, 2023, at 13:28, Mark Millard wrote: > On Nov 21, 2023, at 21:43, Mark Millard wrote: > >> While my kernel/world build procedures build both DBG and NODBG >> kernels and worlds, I normally run the NODBG kernel and world, >> using DBG only when I need to for problem investigation. >>

Call for 2023Q4 status reports

Dear FreeBSD Community, The deadline for the next FreeBSD Status Report update is December, 31st 2023 for work done since the last round of quarterly reports: October 2023 - December 2023. I would like to remind you that reports are published on a quarterly basis and are usually collected during

Re: How do I update the kernel of FreeBSD-CURRENT

On Nov 29, 2023, at 12:21 PM, Manoel Games wrote: > > I am a new FreeBSD user, and I am using FreeBSD-CURRENT. How do I update the > FreeBSD-CURRENT kernel, and is it done through pkg? I installed > FreeBSD-CURRENT without src. As a new user you should probably run a supported release

How do I update the kernel of FreeBSD-CURRENT

I am a new FreeBSD user, and I am using FreeBSD-CURRENT. How do I update the FreeBSD-CURRENT kernel, and is it done through pkg? I installed FreeBSD-CURRENT without src.

Re: CDE on FreeBSD 14.0 Release

In message <20231127172506.horde.iibmvttnl5om_j0h4cvd...@webmail.in-berlin.d e>, "Rolf M. Dietze" writes: > Hi, > > might be that I am on the wrong list for this, since my Problem > exists on 14.0Release. > > After an out of the box install of FreeBSD 14.0 Release and following >

Re: problem updating to CURRENT from source

Gary Jennejohn asks: Did you do a clean build? This isn't mentioned in the "To rebuild everything" text, but since you're building a different branch I suspect that a clean build would be necessary. Define "clean build". The script for rebuilding world has both "make cleanworld"

Re: problem updating to CURRENT from source

On Tue, 28 Nov 2023 12:01:47 -0500 Robert Huff wrote: > Hello: > I am trying to update a system running "14.0 CURRENT #0" to last > night's Current using source. > I read the RELNOTES; I read the directions in UPDATING under "To > rebuild everything". > I built world; built

problem updating to CURRENT from source

Hello: I am trying to update a system running "14.0 CURRENT #0" to last night's Current using source. I read the RELNOTES; I read the directions in UPDATING under "To rebuild everything". I built world; built kernel; installed kernel; rebooted single user - no problem. Ran

Re: CDE on FreeBSD 14.0 Release

Hi, uh, I forgot the entry in services, thanks for the link:) Rolf Quoting Mario Marietto : I asked the same recently and I'd got a good answer,here : https://forums.FreeBSD.org/threads/cde-users-unite.85143/post-576559 On Mon, Nov 27, 2023 at 5:25 PM Rolf M. Dietze wrote: Hi, might

Re: CDE on FreeBSD 14.0 Release

Hello! After installing CDE: # edit /etc/rc.conf dtlogin_enable="YES" or # edit /etc/rc.local /usr/local/dt/bin/dtlogin -nodaemon # edit /usr/local/etc/X11/Xwrapper.config allowed_users=anybody # shutdown -r now There's nothing else you need to do On Tue, Nov 28, 2023 at 12:21 AM Rolf M.

Re: CDE on FreeBSD 14.0 Release

Hi, sorry for this, user error... I did put a dtlogin_enable="YES" in /etc/rc.conf having the dtlogin copied to /usr/local/etc/rcd This did not work. Just having a /usr/local/dt/bin/dtlogin in /etc/rc.local as it is outlined in the link below, does work. Still, having an issue with dtspc

Re: CDE on FreeBSD 14.0 Release

I asked the same recently and I'd got a good answer,here : https://forums.FreeBSD.org/threads/cde-users-unite.85143/post-576559 On Mon, Nov 27, 2023 at 5:25 PM Rolf M. Dietze wrote: > Hi, > > might be that I am on the wrong list for this, since my Problem > exists on 14.0Release. > > After an

CDE on FreeBSD 14.0 Release

Hi, might be that I am on the wrong list for this, since my Problem exists on 14.0Release. After an out of the box install of FreeBSD 14.0 Release and following https://forums.freebsd.org/threads/setting-up-common-desktop-environment-for-modern-use.69475/ I am stuck with CDE. CDE loads, dtlogin

Heads up: lots of churn, nothing interesting will come of it (I hope)

OK. I have pushed 4 series of commits. (1) remove sccs IDs by and large (a couple of exceptions where @(#) didn't mark an SCCS id). (2) remove if 0'd copyright strings. (3) Mechanical changes to most of the tree to cleanup style divots after these changes (and the $FreeBSD$ removal) (4) cdefs.h

Re: [resolved] After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource

On Sat, 25 Nov 2023 12:16:49 -0800 David Wolfskill wrote: > On Sun, Nov 26, 2023 at 04:36:33AM +0900, Tomoaki AOKI wrote: > > Hi. > > > > Not tested, but does upgrading to commit ed88eef140a1 [1] and later > > help? (I'm still at commit 5d4f897f88ed on main.) > > > > [1] > >

Re: Should we boot the FreeBSD kernel in ELF format or in zImage format ? How?

I really don't know where to start. It sounds too technical for me. I don't even know what to ask to understand where to start. mmm...can someone provide some documentation ? but not too much dense with technicalities. Thanks. On Sat, Nov 25, 2023 at 6:02 PM Warner Losh wrote: > > > On Sat, Nov

Re: [resolved] After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource

On Sun, Nov 26, 2023 at 04:36:33AM +0900, Tomoaki AOKI wrote: > Hi. > > Not tested, but does upgrading to commit ed88eef140a1 [1] and later > help? (I'm still at commit 5d4f897f88ed on main.) > > [1] > https://cgit.freebsd.org/src/commit/?id=ed88eef140a1c3d57d546f409c216806dd3da809 > > Regards.

Re: After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource

On Sun, Nov 26, 2023 at 04:36:33AM +0900, Tomoaki AOKI wrote: > Hi. > > Not tested, but does upgrading to commit ed88eef140a1 [1] and later > help? (I'm still at commit 5d4f897f88ed on main.) > > [1] > https://cgit.freebsd.org/src/commit/?id=ed88eef140a1c3d57d546f409c216806dd3da809 > > Regards.

Re: After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource

Hi. Not tested, but does upgrading to commit ed88eef140a1 [1] and later help? (I'm still at commit 5d4f897f88ed on main.) [1] https://cgit.freebsd.org/src/commit/?id=ed88eef140a1c3d57d546f409c216806dd3da809 Regards. On Sat, 25 Nov 2023 05:45:24 -0800 David Wolfskill wrote: > After I saw this

Re: Should we boot the FreeBSD kernel in ELF format or in zImage format ? How?

On Sat, Nov 25, 2023 at 4:41 AM Mario Marietto wrote: > Hello to everyone. > > we have just virtualized Debian 12 on our arm (32 bit) Chromebook. As host > / dom0 we have chosen Devuan 5,and for guest / domU,Debian 12. It works > great. But our goal is different. We want to virtualize FreeBSD as

After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource

After I saw this with both my headless "build machine" and a laptop (and verified that there were no more recent commits to main), I figured it might be worth reporting. This was after a source update from: FreeBSD 15.0-CURRENT #473 main-n266588-2a35f3cdf63d-dirty: Fri Nov 24 13:11:48 UTC 2023

Fwd: Should we boot the FreeBSD kernel in ELF format or in zImage format ? How?

Hello to everyone. we have just virtualized Debian 12 on our arm (32 bit) Chromebook. As host / dom0 we have chosen Devuan 5,and for guest / domU,Debian 12. It works great. But our goal is different. We want to virtualize FreeBSD as domU. Can we have a working Xen PV network driver for a FreeBSD

Re: openzfs and block cloning question

24.11.23 10:17, Alexander Leidinger: Am 2023-11-24 08:10, schrieb Oleksandr Kryvulia: Hi, Recently cperciva@ published in his twitter [1] that enabling block cloning feature tends to data lost on 14.  Is this statement true for the current? Since I am using current for daily work and block

<    3   4   5   6   7   8   9   10   11   12   >