Re: change in /usr/bin/bc with CTRL-d no longer exit [fixed in -CURRENT]

Am 16.09.24 um 17:01 schrieb Cy Schubert: In message , Warner Losh writes: [...] The irony here is that i fixed thus very bug 2 or 3 years ago. Warner It's curious (or maybe not) how some bugs keep returning with a time and time again. Version 7.0.2 has just been committed to -CU

looking for feedback on the CURRENT stabilization cycle

Hi, we've been running the stabilization week of FreeBSD/main aka CURRENT since February. And it has been public since March. So we have had 5 cycles already and 4 were public. I'm eager to get some feedback from people who had been positively or negatively affected by this

random USB detach in CURRENT

Hi, Since a couple of weeks I'm start seeing random USB detach for all my devices once in a while. The issue doesn't occurs so often and there is no other details in the var log. I'm able to recover all my devices by just unplugging and re-plug the devices. I'm runni

Re: Is anyone using libzfs_core on 15-CURRENT?

On Wed, Jun 19, 2024 at 06:34:24PM +0100, David Chisnall wrote: > Hi all, > > I have some code using libzfs_core that works fine on 13, but seems not to on > 15-CURRENT. The lzc_snapshot function is failing with exactly the same nv > list argument. It is failing with errno 2 (E

Is anyone using libzfs_core on 15-CURRENT?

Hi all, I have some code using libzfs_core that works fine on 13, but seems not to on 15-CURRENT. The lzc_snapshot function is failing with exactly the same nv list argument. It is failing with errno 2 (ENOENT) from the ZFS ioctl (and not returning an nvlist of errors). My understanding is

Re: CURRENT: exec_machdep.c:80:2: error: KDB must be enabled in order for DDB

et this error while perfoming "make -jX > buildworld > buildkernel": > > [...] > /usr/src/sys/amd64/amd64/exec_machdep.c:80:2: error: KDB must be enabled in > order for DDB to > work! 80 | #error KDB must be enabled in order for DDB to work! > | ^ > [...]

CURRENT: exec_machdep.c:80:2: error: KDB must be enabled in order for DDB

DDB to work! 80 | #error KDB must be enabled in order for DDB to work! | ^ [...] Apart from the recommendation not to disable KDB in CURRENT, is there a way to disable debugging features and mimik a stable branch? Thanks in advance, oh -- O. Hartmann

Re: CURRENT kernel crash beyond git: 02d15215cef2

On 26/05/2024 13:45, Herbert J. Skuhra wrote: … No, idea why the fix hasn't been committed yet: … A few hours earlier: uma: Fix improper uses of UMA_MD_SMALL_ALLOC · freebsd/freebsd-src@d25ed65 HTH

Re: CURRENT kernel crash beyond git: 02d15215cef2

Am Sun, 26 May 2024 14:45:37 +0200 "Herbert J. Skuhra" schrieb: > On Sun, May 26, 2024 at 02:35:16PM +0200, FreeBSD User wrote: > > Hello, > > > > boxes running CURRENT are last good with FreeBSD 15.0-CURRENT #44 > > main-n270400-02d15215cef2: Sat May 25

Re: CURRENT kernel crash beyond git: 02d15215cef2

On Sun, May 26, 2024 at 02:35:16PM +0200, FreeBSD User wrote: > Hello, > > boxes running CURRENT are last good with FreeBSD 15.0-CURRENT #44 > main-n270400-02d15215cef2: > Sat May 25 10:56:09 CEST 2024 amd64. Customized kernel. > > After that commit, booting the kernel dies

Re: bsdinstall wifi setup is broken on CURRENT

On 18/05/24 11:33, Alfonso S. Siciliano wrote: On 5/16/24 20:40, Renato Botelho wrote: I saw some users on a .br group complaining bsdinstall was failing to setup wifi network on 15.0 snapshots and tried it myself.  I was able to reproduce the problem and also noticed another one. Thank you

Re: bsdinstall wifi setup is broken on CURRENT

On 18/05/24 11:33, Alfonso S. Siciliano wrote: On 5/16/24 20:40, Renato Botelho wrote: I saw some users on a .br group complaining bsdinstall was failing to setup wifi network on 15.0 snapshots and tried it myself.  I was able to reproduce the problem and also noticed another one. Thank you

Re: bsdinstall wifi setup is broken on CURRENT

On 5/16/24 20:40, Renato Botelho wrote: I saw some users on a .br group complaining bsdinstall was failing to setup wifi network on 15.0 snapshots and tried it myself.  I was able to reproduce the problem and also noticed another one. Thank you for your report, the video is highly appreciate

Re: bsdinstall wifi setup is broken on CURRENT

Renato Botelho writes: > I'm not sure about a good way to test it on a running system instead. Update your source tree, build and install world, run `sudo bsdconfig`, scroll down and select “Network Management”, then select “Wireless Networks”. DES -- Dag-Erling Smørgrav - d...@freebsd.org

Re: bsdinstall wifi setup is broken on CURRENT

Hello Renato, I will give it a try this weekend with bhyve since I have a passtrhu for iwlwifi card. Cheers, Renato Botelho escreveu (quinta, 16/05/2024 à(s) 19:56): > On 16/05/24 15:47, Jessica Clarke wrote: > > On 16 May 2024, at 19:40, Renato Botelho wrote: > >> > >> I saw some users on a

bsdinstall wifi setup is broken on CURRENT

Thank you for the information. The right email address is i...@aktionheizung.de Pay information exclusively to this email address. Thanks - On 16 May 2024, at 19:40, Renato Botelho wrote: I saw some users on a .br group complaining bsdinstall was

Re: bsdinstall wifi setup is broken on CURRENT

On 16/05/24 15:47, Jessica Clarke wrote: On 16 May 2024, at 19:40, Renato Botelho wrote: I saw some users on a .br group complaining bsdinstall was failing to setup wifi network on 15.0 snapshots and tried it myself. I was able to reproduce the problem and also noticed another one. I notic

Re: bsdinstall wifi setup is broken on CURRENT

On 16 May 2024, at 19:40, Renato Botelho wrote: > > I saw some users on a .br group complaining bsdinstall was failing to setup > wifi network on 15.0 snapshots and tried it myself. I was able to reproduce > the problem and also noticed another one. > > I noticed Network Selection screen only

bsdinstall wifi setup is broken on CURRENT

I saw some users on a .br group complaining bsdinstall was failing to setup wifi network on 15.0 snapshots and tried it myself. I was able to reproduce the problem and also noticed another one. I noticed Network Selection screen only shows one line, it's not beautiful to navigate through item

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, . . .] [Update to Host OSVERSION 1500018 did not help]

On 2024-05-08 23:53:57 (+0800), Mark Millard wrote: On Apr 29, 2024, at 20:16, Mark Millard wrote: On Apr 29, 2024, at 20:11, Mark Millard wrote: On Apr 29, 2024, at 19:54, Mark Millard wrote: On Apr 28, 2024, at 18:06, Philip Paeps wrote: On 2024-04-18 23:14:22 (+0800), Mark Millard

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, . . .] [Update to Host OSVERSION 1500018 did not help]

On Apr 29, 2024, at 20:16, Mark Millard wrote: > On Apr 29, 2024, at 20:11, Mark Millard wrote: > >> On Apr 29, 2024, at 19:54, Mark Millard wrote: >> >>> On Apr 28, 2024, at 18:06, Philip Paeps wrote: >>> On 2024-04-18 23:14:22 (+0800), Mark Millard wrote: > On Apr 18, 2024, at 08

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]

On Apr 29, 2024, at 20:11, Mark Millard wrote: > On Apr 29, 2024, at 19:54, Mark Millard wrote: > >> On Apr 28, 2024, at 18:06, Philip Paeps wrote: >> >>> On 2024-04-18 23:14:22 (+0800), Mark Millard wrote: On Apr 18, 2024, at 08:02, Mark Millard wrote: > void wrote on > Dat

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]

On Apr 29, 2024, at 19:54, Mark Millard wrote: > On Apr 28, 2024, at 18:06, Philip Paeps wrote: > >> On 2024-04-18 23:14:22 (+0800), Mark Millard wrote: >>> On Apr 18, 2024, at 08:02, Mark Millard wrote: void wrote on Date: Thu, 18 Apr 2024 14:08:36 UTC : > Not sure where

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]

On Apr 28, 2024, at 18:06, Philip Paeps wrote: > On 2024-04-18 23:14:22 (+0800), Mark Millard wrote: >> On Apr 18, 2024, at 08:02, Mark Millard wrote: >>> void wrote on >>> Date: Thu, 18 Apr 2024 14:08:36 UTC : >>> Not sure where to post this.. The last bulk build for arm64 app

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]

On 2024-04-18 23:14:22 (+0800), Mark Millard wrote: On Apr 18, 2024, at 08:02, Mark Millard wrote: void wrote on Date: Thu, 18 Apr 2024 14:08:36 UTC : Not sure where to post this.. The last bulk build for arm64 appears to have happened around mid-March on ampere2. Is it broken? main-armv7

Re: TXT Kernel linking failed on -CURRENT

Konstantin, good day! 25.04.2024 0:09, Konstantin Belousov пишет: On Wed, Apr 24, 2024 at 01:12:39PM +0500, BSD USER wrote: linking kernel ld: error: undefined symbol: ktrcapfail referenced by vfs_lookup.c    vfs_lookup.o:(namei) referenced by vfs_lookup.c    vfs_look

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]

On Apr 26, 2024, at 18:55, Philip Paeps wrote: > On 2024-04-18 23:02:30 (+0800), Mark Millard wrote: >> void wrote on >> Date: Thu, 18 Apr 2024 14:08:36 UTC : >> >>> Not sure where to post this.. >>> >>> The last bulk build for arm64 appears to have happened around >>> mid-March on ampere2. Is

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]

On 2024-04-18 23:02:30 (+0800), Mark Millard wrote: void wrote on Date: Thu, 18 Apr 2024 14:08:36 UTC : Not sure where to post this.. The last bulk build for arm64 appears to have happened around mid-March on ampere2. Is it broken? main-armv7 building is broken and the last completed build

Re: TXT Kernel linking failed on -CURRENT

On Wed, Apr 24, 2024 at 01:12:39PM +0500, BSD USER wrote: > linking kernel > ld: error: undefined symbol: ktrcapfail > >>> referenced by vfs_lookup.c > >>>   vfs_lookup.o:(namei) > >>> referenced by vfs_lookup.c > >>>   vfs_lookup.o:(namei_setup) > >>> referenced by vfs_look

TXT Kernel linking failed on -CURRENT

Sorry for HTML-trash from previous mail :) Hi, FreeBSD Community! I have a teach with FreeBSD and use -CURRENT on my test machine. And some days ago after - git pull - make buildworld - make buildkernel There is /etc/src.conf and BSDSERV below, what can cause that error? Thanks for help! My

Kernel linking error on -CURRENT

Hi, FreeBSD Community! I have a teach with FreeBSD and use -CURRENT on my test machine.And some days ago after- git pull- make buildworld- make buildkernel There is /etc/src.conf and BSDSERV below, what can cause that error?Thanks for help! kernel building failed with such messages

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]

match the modern "Jail OSVERSION" that would be used? The package builders are due for a regular refresh to newer -CURRENT dogfood. I'll do the aarch64 builders first this time. I've set /root/stop-builds on them. I'll upgrade them when they go idle. Or I'll kill

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]

On Apr 19, 2024, at 07:16, Philip Paeps wrote: > On 2024-04-18 23:02:30 (+0800), Mark Millard wrote: > >> void wrote on >> Date: Thu, 18 Apr 2024 14:08:36 UTC : >> >>> Not sure where to post this.. >>> >>> The last bulk build for arm64 appears to have happened around >>> mid-March on ampere2.

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]

On 2024-04-18 23:02:30 (+0800), Mark Millard wrote: void wrote on Date: Thu, 18 Apr 2024 14:08:36 UTC : Not sure where to post this.. The last bulk build for arm64 appears to have happened around mid-March on ampere2. Is it broken? main-armv7 building is broken and the last completed build

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]

On Thu, Apr 18, 2024 at 08:02:30AM -0700, Mark Millard wrote: void wrote on Date: Thu, 18 Apr 2024 14:08:36 UTC : Not sure where to post this.. The last bulk build for arm64 appears to have happened around mid-March on ampere2. Is it broken? main-armv7 building is broken and the last comple

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]

On Apr 18, 2024, at 08:02, Mark Millard wrote: > void wrote on > Date: Thu, 18 Apr 2024 14:08:36 UTC : > >> Not sure where to post this.. >> >> The last bulk build for arm64 appears to have happened around >> mid-March on ampere2. Is it broken? > > main-armv7 building is broken and the las

pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]

void wrote on Date: Thu, 18 Apr 2024 14:08:36 UTC : > Not sure where to post this.. > > The last bulk build for arm64 appears to have happened around > mid-March on ampere2. Is it broken? main-armv7 building is broken and the last completed build was the one started on Mon, 19 Feb 2024 12:32:10

Re: Multiple issues with current (kldload failures, missing CTF stuff, pty issues, ...)

27;t the cause, next test is the CTF stuff in the kernel... A rather obscure problem was causing this. The "last" BE had canmount set to "on" instead of "noauto". No idea how this happened, but this resulted in the "last" BE to be mounted on "zfs m

Re: CURRENT on laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230

(For the not working Wifi chip, I use at the moment an USB-Wifi dongle, Realtek RTL8191S WLAN Adapter, which works fine). I also can't get Xorg plus twm up; it says in /var/log/Xorg.0.log at the end: .. REDWOOD, ATI Mobility Radeon Graphics, CEDAR, ATI FirePro 2270, ATI Radeon

Re: Multiple issues with current (kldload failures, missing CTF stuff, pty issues, ...)

On 3/29/24 16:52, Alexander Leidinger wrote: Hi, sources from 2024-03-11 work. Sources from 2024-03-25 and today don't work (see below for the issue). As the monthly stabilisation pass didn't find obvious issues, it is something related to my setup:  - not a generic kernel  - very modular ker

Re: Multiple issues with current (kldload failures, missing CTF stuff, pty issues, ...)

Am 2024-03-29 18:13, schrieb Mark Johnston: On Fri, Mar 29, 2024 at 04:52:55PM +0100, Alexander Leidinger wrote: Hi, sources from 2024-03-11 work. Sources from 2024-03-25 and today don't work (see below for the issue). As the monthly stabilisation pass didn't find obvious issues, it is somet

Re: Multiple issues with current (kldload failures, missing CTF stuff, pty issues, ...)

On Fri, Mar 29, 2024 at 04:52:55PM +0100, Alexander Leidinger wrote: > Hi, > > sources from 2024-03-11 work. Sources from 2024-03-25 and today don't work > (see below for the issue). As the monthly stabilisation pass didn't find > obvious issues, it is something related to my setup: > - not a gen

Multiple issues with current (kldload failures, missing CTF stuff, pty issues, ...)

Hi, sources from 2024-03-11 work. Sources from 2024-03-25 and today don't work (see below for the issue). As the monthly stabilisation pass didn't find obvious issues, it is something related to my setup: - not a generic kernel - very modular kernel (as much as possible as a module) - bind_

Re: CURRENT on laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230

mt7921 supports all 802.11 a/b/g/n/ac and ax the compatibility code currently only supports 802.11 a/b/g modes. Support for 802.11 n/ac is to come. BUGS Certainly. SEE ALSO wlan(4), ifconfig(8), wpa_supplicant(8) HISTORY The mt7921 driver first appeared in FreeBSD 14.0. FreeBSD 14.0-CURRENTApril 18, 2023FreeBSD 14.0-CURRENT

Re: CURRENT on laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230

El día miércoles, marzo 27, 2024 a las 10:37:48a. m. +0100, Matthias Apitz escribió: > > Hello, > > I bought the laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230 and managed to > boot FreeBSD with boot verbose messages from an USB key and I'm able to > login. The /var/log/messages are here > http://

Re: CURRENT on laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230

On Wed, Mar 27, 2024 at 12:38 PM Matthias Apitz wrote: > > > Hello, > > I bought the laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230 and managed to > boot FreeBSD with boot verbose messages from an USB key and I'm able to > login. The /var/log/messages are here > http://www.unixarea.de/ASUS-VivoBook-P

CURRENT on laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230

Hello, I bought the laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230 and managed to boot FreeBSD with boot verbose messages from an USB key and I'm able to login. The /var/log/messages are here http://www.unixarea.de/ASUS-VivoBook-Pro-14-messages.txt I can identify the harddisk as nda0 (correct), bu

CURRENT 220ee18f1964 memstick kernel panic, MacBookPro8,3

99a62f336fe2083bd&=&format=webp&quality=lossless&width=915&height=686> USB flash drive written from FreeBSD-15.0-CURRENT-amd64-20240314-220ee18f1964-268793-memstick.img.xz Broadcom Wi-Fi-related, maybe? <https://bsd-hardware.info/?probe=89647876db#pci:14e4-4331-106b-00d6>

Re: sysutils/pam_xdg: Cancelled on -CURRENT

On 2024-03-19 16:02, Emmanuel Vadot wrote: > On Tue, 19 Mar 2024 07:55:15 + > Alastair Hogge wrote: > >> On 2024-03-19 15:23, Emmanuel Vadot wrote: >> > Hi, >> >> Hey Emmanuel, >> >> > On Tue, 19 Mar 2024 06:54:27 + >> > Alastair Hogge wrote: >> > >> >> Hello, >> >> >> >> Recently a

Re: sysutils/pam_xdg: Cancelled on -CURRENT

On Tue, 19 Mar 2024 07:55:15 + Alastair Hogge wrote: > On 2024-03-19 15:23, Emmanuel Vadot wrote: > > Hi, > > Hey Emmanuel, > > > On Tue, 19 Mar 2024 06:54:27 + > > Alastair Hogge wrote: > > > >> Hello, > >> > >> Recently a similar module (PAM) mentioned in the subject was committed

Re: sysutils/pam_xdg: Cancelled on -CURRENT

On 2024-03-19 15:23, Emmanuel Vadot wrote: > Hi, Hey Emmanuel, > On Tue, 19 Mar 2024 06:54:27 + > Alastair Hogge wrote: > >> Hello, >> >> Recently a similar module (PAM) mentioned in the subject was committed >> to base[1]. The module in base masks the currently installed Port, the >> man

Re: sysutils/pam_xdg: Cancelled on -CURRENT

Hi, On Tue, 19 Mar 2024 06:54:27 + Alastair Hogge wrote: > Hello, > > Recently a similar module (PAM) mentioned in the subject was committed > to base[1]. The module in base masks the currently installed Port, the > man page can be accessed with man -M /usr/local/share/man 8 pam_xdg, > h

sysutils/pam_xdg: Cancelled on -CURRENT

Hello, Recently a similar module (PAM) mentioned in the subject was committed to base[1]. The module in base masks the currently installed Port, the man page can be accessed with man -M /usr/local/share/man 8 pam_xdg, however, I can now no longer build the Port. I noticed that the base module has

Re: Unable to boot -CURRENT on Thinkpad P16s G2

follow-up: disabling uart0 and uart1 at the loader prompt allowed > us > | to boot and install FreeBSD (the -CURRENT snapshot from 2024-02-29 in > case > | it matters). > > UARTS on AMD can be a bit different. Some BIOS implementations seem > to set them up to work like legacy port

Re: Unable to boot -CURRENT on Thinkpad P16s G2

and install FreeBSD (the -CURRENT snapshot from 2024-02-29 in case | it matters). UARTS on AMD can be a bit different. Some BIOS implementations seem to set them up to work like legacy ports others do not. On a Naples platform I helped add support for them since they were not setup in the leg

Re: Unable to boot -CURRENT on Thinkpad P16s G2

On 2/28/24 21:10, Philipp Ost wrote: [boot log stripped] Does anyone have any suggestions on how to proceed at this point? [...] Short follow-up: disabling uart0 and uart1 at the loader prompt allowed us to boot and install FreeBSD (the -CURRENT snapshot from 2024-02-29 in case it matters

Unable to boot -CURRENT on Thinkpad P16s G2

Hi everyone, we have a Lenovo Thinkpad P16s Gen2 (Type 21K9) here with an AMD Ryzen 7 CPU which we would like to install FreeBSD on. Alas, it won't boot. The FreeBSD 15-CURRENT amd64 snapshot from February 22 hangs after: [...] acpi_acad0: on acpi0 battery0: on acpi0 A verbose

Re: Missing files on -current

On Sat, Feb 24, 2024 at 03:59:01PM +, Gary Jennejohn wrote: > > The function run_rc_scripts is defined in /usr/src/libexec/rc/rc.subr and > is called in /usr/src/libexec/rc/rc. /etc/rc includes /etc/rc.subr. > > So, maybe one of these files is not up to date under /etc? > My fault, etcupda

Re: Missing files on -current

On Sat, 24 Feb 2024 06:53:37 -0800 bob prohaska wrote: > A Pi4 running -current completed a build/install cycle for world and kernel > without obvious errors but failed to reboot, reporting: > ... > Warning: no time-of-day clock registered, system time will not be set > ac

Re: Missing files on -current

~ # However, the same is true of a Pi3 running 14-release p5. It boots reliably once it reaches loader. I wouldn't expect this part of the boot process to be platform dependent. Maybe -current and -release do things differently? > * /etc/rc.subr is missing. Present and accounted f

Missing files on -current

A Pi4 running -current completed a build/install cycle for world and kernel without obvious errors but failed to reboot, reporting: ... Warning: no time-of-day clock registered, system time will not be set accurately Dual Console: Serial Primary, Video Secondary /etc/rc: run_rc_scripts: not found

Re: FreeBSD CURRENT stabilization cycle

Hi, And whom do you want to „stab“ with this? ;) Why not do the same thing that ports does and call this „monthly“ which is pretty much what it is and easy to understand and you can have one build at the end of that week? Cheers, Franco > On 24. Feb 2024, at 12:51, Kirill Ponomarev wrote: >

Re: FreeBSD CURRENT stabilization cycle

On 02/23, Mark Millard wrote: > Gleb Smirnoff wrote on > Date: Sat, 24 Feb 2024 04:32:52 UTC : > > > More seriously speaking, I > > actually hope that in some future snapshots.FreeBSD.org will start using > > these > > points for snapshot generation. > > How about also the likes of: > > https:

RE: FreeBSD CURRENT stabilization cycle

Gleb Smirnoff wrote on Date: Sat, 24 Feb 2024 04:32:52 UTC : > More seriously speaking, I > actually hope that in some future snapshots.FreeBSD.org will start using these > points for snapshot generation. How about also the likes of: https://pkg.freebsd.org/FreeBSD:15:aarch64/stabweek/ for pkg

FreeBSD CURRENT stabilization cycle

Hi FreeBSD CURRENT users, back in November I came up with a proposal of providing some stabilization cadence to development of the main branch, also known as FreeBSD CURRENT. Here is a video with the initial proposal and following discussion at VendorBSD Conference (18 minutes): https

Re: nvme controller reset failures on recent -CURRENT

Hi all, > Am 13.02.2024 um 20:56 schrieb Pete Wright : > 1. M.2 nvme really does need proper cooling, much more so than traditional > SATA/SAS/SCSI drives. I recently found a tool named "Scrutiny" that presents a nice dashboard of all your disk devices and their SMART data including crucial poin

Re: nvme controller reset failures on recent -CURRENT

I had issues with a nvme drive in an intel nuc. When I asked freebsd-hackers, overheating was the first guess: https://lists.freebsd.org/pipermail/freebsd-hackers/2018-May/052783.html I blew the dust out of the fan assembly and changed the bios fan settings to be more aggressive and the syste

Re: nvme controller reset failures on recent -CURRENT

There's a tiny chance that this could be something more exotic, but my money is on hardware gone bad after 2 years of service. I don't think this is 'wear out' of the NAND (it's only 15TB written, but it could be if this drive is really really crappy nand: first generation QLC maybe, but it seems

Re: nvme controller reset failures on recent -CURRENT

hpowerup.com/ssd-specs/intel-660p-512-gb.d437 I've seen comments that these generally don't need cooling. I just ordered a heatsink with some nice big fins, but it will take a week or more to arrive. > >> > On Mon, Feb 12, 2024, 4:28 PM Don Lewis wrote: >> > >

Re: nvme controller reset failures on recent -CURRENT

first generation QLC maybe, but it seems too new). It might also be a connector problem that's developed over time. There might be a few other things too, but I don't think this is a U.2 drive with funky cables. Warner > > On Mon, Feb 12, 2024, 4:28 PM Don Lewis wrote: > > &

Re: nvme controller reset failures on recent -CURRENT

e a while. > On Mon, Feb 12, 2024, 4:28 PM Don Lewis wrote: > >> I just upgraded my package build machine to: >> FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e >> from: >> FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38 >> and I've had two n

Re: nvme controller reset failures on recent -CURRENT

On 12 Feb, Mark Johnston wrote: > On Mon, Feb 12, 2024 at 04:28:10PM -0800, Don Lewis wrote: >> I just upgraded my package build machine to: >> FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e >> from: >> FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38 >>

Re: nvme controller reset failures on recent -CURRENT

On Mon, Feb 12, 2024 at 04:28:10PM -0800, Don Lewis wrote: > I just upgraded my package build machine to: > FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e > from: > FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38 > and I've had two nvme-triggered panics in the la

Re: nvme controller reset failures on recent -CURRENT

Might be an overheating. Today's nvme drives are notoriously flaky if you run them without proper heat sink attached to it. -Max On Mon, Feb 12, 2024, 4:28 PM Don Lewis wrote: > I just upgraded my package build machine to: > FreeBSD 15.0-CURRENT #110 main-n268161-4015c064

nvme controller reset failures on recent -CURRENT

I just upgraded my package build machine to: FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e from: FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38 and I've had two nvme-triggered panics in the last day. nvme is being used for swap and L2ARC. I'm not able to get a crash dump

Re: make buildworld failure on arm64 on -current n267777

On Fri, 26 Jan 2024, at 00:14, void wrote: > In /usr/src # git rev-list --count --first-parent HEAD > 26 in /usr/src, a 'git reset --hard' followed by 'git pull' and then 'git checkout main' fixed this. For some reason, 'git pull --ff-only' didn't pull /usr/src/sys/contrib/dev/acpica/include

make buildworld failure on arm64 on -current n267777

In /usr/src # git rev-list --count --first-parent HEAD 26 include/machine -> /usr/src/sys/arm64/include Building /usr/obj/usr/src/arm64.aarch64/stand/efi/loader_4th/vers.c Building /usr/obj/usr/src/arm64.aarch64/stand/efi/loader_4th/8x16.c Building /usr/obj/usr/src/arm64.aarch64/stand/efi/l

Re: NFSv4 crash of CURRENT

t; > > > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 2; apic id = 04 > > > fault virtual address = 0x89 > > > fault code = supervisor read data, page not present > > > instruction pointer = 0x20:0xffff8

Re: NFSv4 crash of CURRENT

pen'd for > >> some reason. I've never looked at autofs. > >> > >>> > >>> Peter > >>> > >>> On 15 Jan 2024, at 09:31, Peter Blok >>> <mailto:pb...@bsd4all.org>> > >>> wrote: &

Re: NFSv4 crash of CURRENT

:0x809645d4 > > stack pointer = 0x28:0xfe00acadb830 > > frame pointer = 0x28:0xfe00acadb830 > > code segment= base 0x0, limit 0xf, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran

Re: NFSv4 crash of CURRENT

a NFS client with stable of today >>> (4c4633fdffbe8e4b6d328c2bc9bb3edacc9ab50a). It is also autofs related. >>> Maybe it is the same problem. >>> >>> I have ports automounted on /am/ports. When I do cd /am/ports/sys and type >>> tab to autocomp

Re: NFSv4 crash of CURRENT

hes with the below stack trace. If I plainly >> mount ports on /usr/ports and do the same everything works. I am using NFSv3 >> >> Peter >> >> >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 2; apic id = 04 >> fault vi

Re: NFSv4 crash of CURRENT

04 > fault virtual address = 0x89 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x809645d4 > stack pointer= 0x28:0xfe00acadb830 > frame pointer= 0x28:0xfe00acadb830 > code segment = base 0x0, limit 0xfff

Re: NFSv4 crash of CURRENT

pointer = 0x20:0x809645d4 > stack pointer = 0x28:0xfe00acadb830 > frame pointer = 0x28:0xfe00acadb830 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interr

Re: NFSv4 crash of CURRENT

, IOPL = 0 current process = 6869 (csh) trap number = 12 panic: page fault cpuid = 2 time = 1705306940 KDB: stack backtrace: #0 0x806232f5 at kdb_backtrace+0x65 #1 0x805d7a02 at vpanic+0x152 #2 0x805d78a3 at panic+0x43 #3 0x809d58ad at trap_fatal

Re: NFSv4 crash of CURRENT

Am Sun, 14 Jan 2024 20:34:12 -0800 Cy Schubert schrieb: > In message om> > , Rick Macklem writes: > > On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop = > > wrote: > > > > > > > > > Van: FreeBSD User > > > Datum: 13 januari 2024

Re: NFSv4 crash of CURRENT

In message , Rick Macklem writes: > On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop = > wrote: > > > > > > Van: FreeBSD User > > Datum: 13 januari 2024 19:34 > > Aan: FreeBSD CURRENT > > Onderwerp: NFSv4 crash of CURRENT > > > > Hello

Re: NFSv4 crash of CURRENT

Am Sat, 13 Jan 2024 19:41:30 -0800 Rick Macklem schrieb: > On Sat, Jan 13, 2024 at 12:39 PM Ronald Klop wrote: > > > > > > Van: FreeBSD User > > Datum: 13 januari 2024 19:34 > > Aan: FreeBSD CURRENT > > Onderwerp: NFSv4 crash of CURRENT > > >

Re: NFSv4 crash of CURRENT

On Sat, Jan 13, 2024 at 12:39 PM Ronald Klop wrote: > > > Van: FreeBSD User > Datum: 13 januari 2024 19:34 > Aan: FreeBSD CURRENT > Onderwerp: NFSv4 crash of CURRENT > > Hello, > > running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a: > Sat

Re: NFSv4 crash of CURRENT

Van: FreeBSD User Datum: 13 januari 2024 19:34 Aan: FreeBSD CURRENT Onderwerp: NFSv4 crash of CURRENT Hello, running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a: Sat Jan 13 18:08:32 CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned client, other

Re: route ipv6 errors on bootup in -current main-n267425-aa1223ac3afc on arm64

) >> subsystem)… >> Cheers! >> -Enji > > world/kernel was built with WITHOUT_INET6= in /etc/src.conf > > I made the problem go away with removing WITHOUT_INET6= and rebuilding. > The system was installed by taking > FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20240

Re: route ipv6 errors on bootup in -current main-n267425-aa1223ac3afc on arm64

= in /etc/src.conf >>> >>> I made the problem go away with removing WITHOUT_INET6= and rebuilding. >> >> I'll re-add this to try and replicate the problem with the same sources >> (main-n267425-aa1223ac3afc) and if it happens again I'll make a PR fo

Re: kernel: fatal trap 12 on CURRENT, when using WireGuard

Am 09.01.24 um 21:40 schrieb Gleb Smirnoff: Rainer, On Tue, Jan 09, 2024 at 09:23:54PM +0100, Rainer Hurling wrote: R> I tried to update my 15.0-CURRENT box from n267335-499e84e16f56 to a very R> recent commit. The build and install went fine. After booting with new R> base, I g

Re: kernel: fatal trap 12 on CURRENT, when using WireGuard

Rainer, On Tue, Jan 09, 2024 at 09:23:54PM +0100, Rainer Hurling wrote: R> I tried to update my 15.0-CURRENT box from n267335-499e84e16f56 to a very R> recent commit. The build and install went fine. After booting with new R> base, I got a page fault with the following error: Sorry

kernel: fatal trap 12 on CURRENT, when using WireGuard

I tried to update my 15.0-CURRENT box from n267335-499e84e16f56 to a very recent commit. The build and install went fine. After booting with new base, I got a page fault with the following error: Kernel page fault with the following non-sleepable locks held: shared rm netlink lock (netlink

Re: route ipv6 errors on bootup in -current main-n267425-aa1223ac3afc on arm64

nd if it happens again I'll make a PR for it I forgot about this line: options INET6 # IPv6 communications protocols which, on current/arm64 lives in std.arm64 which gets included by GENERIC which is included by GENERIC-MMCCAM which is included by GENERIC-MMCC

Re: route ipv6 errors on bootup in -current main-n267425-aa1223ac3afc on arm64

On Tue, Jan 09, 2024 at 10:24:53AM +, void wrote: On Mon, Jan 08, 2024 at 01:07:30PM -0800, Enji Cooper wrote: Was the kernel/utility built with IPv6? If not, that’s a general bug which should be filed (which can be easily checked/avoided using the FEATURES(9) subsystem)… Cheers! -Enji

Re: route ipv6 errors on bootup in -current main-n267425-aa1223ac3afc on arm64

/src.conf I made the problem go away with removing WITHOUT_INET6= and rebuilding. The system was installed by taking FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20240104-8bf0882e186e-267378.img and dd-ing it to a usb3-connected hd. Where can I read about features? % man features No manual entry for

[Bug 197921] scheduler: Allow non-migratable threads to bind to their current CPU

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197921 Zhenlei Huang changed: What|Removed |Added CC||z...@freebsd.org --- Comment #3 fr

Re: route ipv6 errors on bootup in -current main-n267425-aa1223ac3afc on arm64

> On Jan 7, 2024, at 6:29 AM, void wrote: > > Hi, > > on a rpi4/8GB, my rc.conf looks like so. It's an ipv4-only system on a LAN > not directly connected to the internet > > hostname="generic.home.arpa" > ifconfig_genet0="inet 192.168.1.199 netmask 255.255.255.0" > defaultrouter="192.168.1.1"

  1   2   3   4   5   6   7   8   9   10   >