Re: Problem building kernel

> On Dec 24, 2023, at 12:27, Vladimir Kondratyev wrote: > > 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 >>

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

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

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

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

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

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 --- >

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

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

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

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. >>

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

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

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

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

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

Re: What is rc.d/opensm?

24.11.23 12:20, Alexander Leidinger: Hi, for my work on service jails (https://reviews.freebsd.org/D40370) I try to find out what opensm is. On my amd64 system I don't have a man page nor the binary (and man.freebsd.org doesn't know either about opensm). Bye, Alexander. See man

Re: openzfs and block cloning question

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 cloning enabled by default how can I

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

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. > > I recently had reason to use the DBG kernel and found

Re: uSB: uslcom: CP2102 weirdness when serial communication via cu/tip/cutecom

Am Thu, 23 Nov 2023 20:37:26 +0100 FreeBSD User schrieb: > Hello, > > I'm facing some strange behaviour when connecting to a CP2102 USB-UART bridge > built-in into > a I2C-USB device (I2C is handled by an Amtel88, USB-UART is handled by an > CP2102, see here: > >

Re: db> reset -> panic: acquiring blockable sleep lock with spinlock or critical section held ...

On 11/20/23 15:40, Bjoern A. Zeeb wrote: On Mon, 20 Nov 2023, Mitchell Horne wrote: Hi Mitchell, On 11/16/23 18:21, Bjoern A. Zeeb wrote: Hi, I seem to remember changes related to that a while ago but my cache is miss for the actual change.  Are we suppoed to handle this case? It would be

Re: NFS exports of ZFS snapshots broken

In any case, > > >> it seems to me that mnt_exjail should be set properly, e.g. by duping > > >> the one in the original mount structure. Probably ZFS is the only > > >> file system type that would need this added. > > > I've created a patch that I think does

Re: NFS exports of ZFS snapshots broken

d it here (this diff doesn't use -U99, so it might be > > easier to apply). > > It works for me in 13-stable, and looks plausible. The patch has now been fixed so that there is no race between vfs_exjail_clone() and a jail dying. I believe the current patch fixes the problem. The patch can be fou

Re: RFC: #f FreeBSD_version of #ifdef for OpenZFS pull request

Thanks, I've gone with B, rick On Wed, Nov 22, 2023 at 1:30 PM Warner Losh wrote: > > > > On Wed, Nov 22, 2023, 1:24 PM Rick Macklem wrote: >> >> Hi, >> >> I have a patch currently under review at D42672 that fixes visibility >> of snapshots under .zfs/snapshot for NFS clients. >> It adds a new

Re: RFC: #f FreeBSD_version of #ifdef for OpenZFS pull request

On Wed, Nov 22, 2023, 1:24 PM Rick Macklem wrote: > Hi, > > I have a patch currently under review at D42672 that fixes visibility > of snapshots under .zfs/snapshot for NFS clients. > It adds a new function called vfs_exjail_clone(), which the ZFS > code needs to use to fill in the mnt_exjail

Re: bl[ao]cklistd, some first impressions...

Hi, > On 21 Nov 2023, at 11:46, Poul-Henning Kamp wrote: > > I have played around with bl[ao]cklistd on 13.2 and I am not terribly > impressed: > [etc] We came up with a similar list of objections and built our own solution. -- Bob Bishop r...@gid.co.uk

Re: HEADSUP: panic: running without device atpic requires a local APIC on UEFI systems after 0b01d45783c3

On Mon, Nov 20, 2023 at 8:48 PM Xin Li wrote: > On 2023-11-20 19:33, Warner Losh wrote: > > > > > > On Mon, Nov 20, 2023 at 6:21 PM Xin Li > > wrote: > > > > Hi, > > > > It seems that the recent improvements of ACPI detection (e0f3dc82727f > > and

Re: HEADSUP: panic: running without device atpic requires a local APIC on UEFI systems after 0b01d45783c3

On 2023-11-20 19:33, Warner Losh wrote: On Mon, Nov 20, 2023 at 6:21 PM Xin Li > wrote: Hi, It seems that the recent improvements of ACPI detection (e0f3dc82727f and 0b01d45783c3) would leave the system in an unbootable state if the UEFI files are

Re: HEADSUP: panic: running without device atpic requires a local APIC on UEFI systems after 0b01d45783c3

On Mon, Nov 20, 2023 at 6:21 PM Xin Li wrote: > Hi, > > It seems that the recent improvements of ACPI detection (e0f3dc82727f > and 0b01d45783c3) would leave the system in an unbootable state if the > UEFI files are not being updated at the same time of "make > installworld". At early boot the

Re: HEADSUP: panic: running without device atpic requires a local APIC on UEFI systems after 0b01d45783c3

I have a patch cooking for this... I was almost done when I had to leave for karate. Warner On Mon, Nov 20, 2023, 6:21 PM Xin Li wrote: > Hi, > > It seems that the recent improvements of ACPI detection (e0f3dc82727f > and 0b01d45783c3) would leave the system in an unbootable state if the >

Re: db> reset -> panic: acquiring blockable sleep lock with spinlock or critical section held ...

On Mon, 20 Nov 2023, Mitchell Horne wrote: Hi Mitchell, On 11/16/23 18:21, Bjoern A. Zeeb wrote: Hi, I seem to remember changes related to that a while ago but my cache is miss for the actual change.  Are we suppoed to handle this case? It would be nice if "reset" would reset again the

Re: db> reset -> panic: acquiring blockable sleep lock with spinlock or critical section held ...

On 11/16/23 18:21, Bjoern A. Zeeb wrote: Hi, I seem to remember changes related to that a while ago but my cache is miss for the actual change.  Are we suppoed to handle this case? It would be nice if "reset" would reset again the first time ... Hi Bjoern, This is still my fault, I am

Re: How much survives an install/reboot cycle?

On Mon, Nov 20, 2023 at 09:12:45AM +0800, Zhenlei Huang wrote: > > > > On Nov 19, 2023, at 11:51 PM, bob prohaska wrote: > > > > How much of a running system's state survives a reboot? I used to think > > the answer was "nothing", but from time to time a second reboot behaves > > a little

Re: db> reset -> panic: acquiring blockable sleep lock with spinlock or critical section held ...

On Thu, Nov 16, 2023 at 10:21:38PM +, Bjoern A. Zeeb wrote: > Hi, > > I seem to remember changes related to that a while ago but my cache > is miss for the actual change. Are we suppoed to handle this case? > > It would be nice if "reset" would reset again the first time ... We should

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