Greetings. I recently purchased a Lenovo v15 g4 laptop, intel core i7 processor. It's not "officially" support, but I've installed FreeBSD 15 and I've managed to get it working pretty well. There are still a couple of issues with suspend/resume and bluetooth. Anyone available for a couple of questions?

numberoneson: good job +1

looks like a nice laptop

Thanks. I'm pretty happy so far. It would be nice to get bluetooth working, though, and I'm afraid that's outside my area of expertise. usbconfig shows it's there and apparently alive, but I can't configure it.

15 really is a gigantic step backward on my machines performance wise. I think I am going to roll back at least a couple of them to 14, ugh.

amigan: Is the performance lose across the board or I/O related?

It seems to be all IO related.

I installed 15 on this lenovo laptop since I needed up to date iwlwifi, but I've noticed that IO seems a lot poorer than I'd expected. I was thinking/hoping I could buy a higher end ssd but now I don't know if it's worth it.

Network, disk, doesn't matter. And I'm seeing some very weird behaviors, for example I always had alias precmd 'history -S; history -M' to merge the histfile across multiple shells. Under 15, it takes comparatively forever to complete this precmd and return a new prompt. I ktraced the shell and it's stuck in a giant block of thousands of sigprocmask(2) and setitimer(2)

On another machine, garage (an S3-compatible object store daemon) saturating the disks leads to utter 5 second hangups of ssh just echoing characters

Seeing behaviors on amd64 boxes, aarch64, zfs and UFS

Interesting. I'll try the same thing & see what I get. I have a 5+ year old dell tower running 14.3 and it's prob twice the speed of this new laptop.

Yeah. And my firewall apparently can no longer do line speed with iperf in one direction. Tops out at 570Mb/s, even with pf disabled.

No bencharks, though. I'm just comparing how it feels/acts while eg compiling in the background.

Yes, same here. I'm just going by every day use. Also, poudriere runs definitely take longer.

Hmm. My firewall is opnsense on a small supermicro. They're still using 14.

No problems there.

I'm a moron and upgraded everyone at once. I've never regretted it before.

Firewall is just vanilla FreeBSD

:) Same... I've just spent enough time getting 15 usable on this laptop that I haven't had time to upgrade my others yet.

FWIW I've been very happy with opnsense.

Yeah, I would hold off. Normally I am totally fine with being a guinea pig and report bugs but this is kind of ridiculous

You know what they say about .0 releases.

But I'm going to try to collect some useful data, anyhow.

Lol, yeah. But none of the .0s I've gone through in the past were bad. It was always a step forward.

I

wonder if pkgbase will make downgrading less painful

Some of these machines are UFS and while I do have full backups of 14, it will be a pain

I'd be interested to hear how it goes. The spirit hasn't yet moved me to switch to pkgbase.

I'm thinking, downgrade base, and downgrade packages before rebooting so I don't run into any ABI incompatibilities

Yeah. pkgbase is definitely a step forward. I build -STABLE for my whole network normally, and mounting /usr/src /usr/obj over NFS was always janky af

i didn't find nfs:/usr/obj janky at al

l

It worked, sure. But it was not as clean as pkgbase

I've been doing NFS /usr/obj for 20 years, this is nicer

Sounds good. I'm tempted to buy a new drive (i'm afraid prices are going to shoot through the roof thanks to ai...) and try it that way. I have good backups.

I've also been using NFS /usr/obj for many years & it works, which is a big part of why I haven't experimented with pkgbase yet. Thanks for the push..

Yeah, the best time to start building and hoarding components was 6 months ago. The next best time is right now. I just built a box a few weeks ago, my first in a decade. Hope it lasts me another decade considering how much I spent on dram.

OK, my plan is now to buy a new 2tb drive, add it to my tower, & install 15 on it. Then I can compare buildworlds/compiling libreoffice.

Or compiling rust. Both are pretty time-consuming.

Yup, rust, llvm19 (for postgres), and mongodb are the heavyweights in my poudriere runs. If you try to MAKE_JOBS llvm it will just start ooming. Working set sizes over 2GB per process during LTO

I was really excited to move my big hypervisor (the new box) from linux to FreeBSD but I don't think it's in the cards for a bit with these regressions.

I'm actually pretty new to irc; just getting started. But I plan to stick around & I plan to share my results after a 14.3-15 side-by-side comparison.

amigan: are you on 15/stable or -release?

i just started moving 3 of my systems to 15/stable from source but i'll keep an eye out for any noticible perf regressions

aquamo4k1: both

lounge.swee.codes/uploads/47ee2328968ac48f/2026-01-01%2020-00-39.mp4 finally upgraded to 15.0-RELEASE, tried virtio_p9fs again

okay so adding virtio_p9fs to kld_list like the man page said seemed to help

oh, another one! `kldload ipmi` insta-bricks my machine, not even a kernel panic

i have that happen with some versions of amdgpu.ko on hardenedbsd

so you aren't alone with some kmods instabricking the system

I don't think you're using the term "brick" right.

"Brick" means to turn something into a brick.

If you can restart it, it's not bricked.

Anything is a brick if you throw it hard enough!

CrtxReavr: They're referring to the rapid restart behaviour I encounter with some kernel modules.

Still not bricked.

Yes - and continuing the pedantry once you have rightly dispelled the incorrect terminology is not helpful at this point. The behaviour has been clearly described, it is not bricking, but it is an incorrect behaviour (a kernel is restarting without being asked and without panicking)

Noting FTR that it wasn't just pedantry, but wwrong, since "brick" as a verb *does* have the meaning of "rendering nonfunctional". See eg, merriam-webster.com/dictionary/brick (verb meaning 2).

I have a problem where sshd keeps dying on a few VMs. I started migrating to new 15.0 VMs, thinking it might put an end to my problem, but it's started on one of them, too:

Jan 2 09:47:33 freehawk15 kernel: pid 3897 (sshd), jid 0, uid 0: exited on signal 10 (no core dump - sugid process denied by kern.sugid_coredump)

thoughts? thanks

mmlj4: that's a bus error, either hardware failure or a bug in the hypervisor?

I can accept that, thanks

it's a lab system, no big deal... thanks :-)

so next question... what in that log entry tells you it's a bus error?

"10 SIGBUS create core image bus error" (courtesy of "man signal")

ah, thanks

Three machines rolled back to 14.3. I guess this was a good DR test.

... Has a release ever been backed out?

Last I can remember is 5.2.1

mmlj4, Overclocking too far can also be a source of bus errors.

Just a thought. Since you said "lab system".

something I've never done, not since I started in the 90s, was overclock

...but yeah, that makes sense

the problem is I got a RAID5 stack and a disk I need to replace, it's got Smart errors

it came in, I just need to take the box down and do it

the problems started about the same time the errors showed up, so...

If it is only RAID5 and degraded then I suggest not delaying. I am in the camp of people who has seen too many problems with RAID5 in degraded mode failing further.

aye

I became a RAID6 in defense of the RAID5 is not quite enough problem.

the next time out will be with non-spinning drives, so I'll go for RAID5

heat's been my problem, I'm glad it's only 3 platters extra in this box

In theory though RAID5 in degraded mode should still have correct data coming off it though so that should not be the source of bus error faults.

Heat? If the box is too hot that could also induce hardware faults like bus errors too.

aye

I can't tell you how many times we have had lab systems opened up with the case off and a house fan blowing on them to get more airflow for prototype systems.

all 3 drives read ~95F, according to my temp scan gun... entirely too bloody hot, I know

If the machine is working correctly then one should never see a bus error. Experimental compiler-assemblers can produce incorrect machine code.

I suppose that writing random data into executable program files could also corrupt the program image and result in a bus error too. So many possible ways for things to go badly. Only one correct way for things to work correctly!

I borked something doing an upgrade from 14.3-RELEASE to 15.0, now there's a kernel mismatch (I think I missed the nextboot invocation). I'm wondering if it'll end up faster to grab a live USB boot to that, or to try to fix things from single-user mode

hm, kernel.old booted just fine