Delay in FreeBSD 14.0 release schedule

LibreQuest said:
All I know is my RX 6400 doesn't work and if there's anyway I can help make that dream a reality I will.
Click to expand...
There are the freebsd mailing lists and worst case, file bug reports. Sometimes it takes a little while to get any kind of response, but if you provide as much detail as you can, it helps in the long run. RX6400, that's AMD? I think AMD is that gray area where "should be fully supported but sometimes newer generations are behind" (that is my personal opinion and pure conjecture).
As for AMD stuff, you may want to take a look at DragonFlyBSD. It was forked from FreeBSD around 4.x/5.0 and Matt seems to have found/tweaked alot for AMD. It could be useful as a datapoint.

Just want to note, above is all my personal opinion, I'm just a long time user of FreeBSD, not officially anything, except maybe "that guy that's older than dirt"
 
mer said:
There are the freebsd mailing lists and worst case, file bug reports. Sometimes it takes a little while to get any kind of response, but if you provide as much detail as you can, it helps in the long run. RX6400, that's AMD? I think AMD is that gray area where "should be fully supported but sometimes newer generations are behind" (that is my personal opinion and pure conjecture).
As for AMD stuff, you may want to take a look at DragonFlyBSD. It was forked from FreeBSD around 4.x/5.0 and Matt seems to have found/tweaked alot for AMD. It could be useful as a datapoint.

Just want to note, above is all my personal opinion, I'm just a long time user of FreeBSD, not officially anything, except maybe "that guy that's older than dirt"
Click to expand...
Sounds good. I'm not interested in moving to another system right now. I'm just now getting adjusted to FreeBSD. I think I did give dragonfly an install at one point but was not for me honestly.
 
LibreQuest said:
Is there some place I could contribute hardware data for developers? All I know is my RX 6400 doesn't work and if there's anyway I can help make that dream a reality I will.
Click to expand...
yeah, it's called
bsd-hardware.info

BSD Hardware Database

A database of all the hardware that works under bsd
bsd-hardware.info bsd-hardware.info
... off the top of my head, FreeBSD does include some utilities to collect the hardware data and upload it there. I do think that RX 6400 should work under FreeBSD...
 
astyle said:
yeah, it's called
bsd-hardware.info

BSD Hardware Database

A database of all the hardware that works under bsd
bsd-hardware.info bsd-hardware.info
... off the top of my head, FreeBSD does include some utilities to collect the hardware data and upload it there. I do think that RX 6400 should work under FreeBSD...
Click to expand...
There is a driver, it and the 6500 were the last in the series to be released. So they are newer than the other 6000 series GPUs. I did load up 14 current but the driver does not work properly. It can render in frame buffer but any attempt at accel will do a hard lock up on the system.
 
zirias@ said:
That would be a good reason indeed! But it isn't even simple when done just in base, there's also 3rd-party software (e.g. heimdal) included relying on OpenSSL :(
Click to expand...
It's entirely possible I don't know what I'm talking about :) In my decidedly underinformed opinion, changing the TLS implementation in base is a much smaller and tractable project than changing the TLS implementation for ports. I know fetch(1) needs it, and the Heimdal libraries you mention.

zirias@ said:
Having used OpenSSL API myself just a tiny little bit (for basic TLS support in "poser"), I'd rather claim it's unfixable. Of course, "forking" doesn't improve anything either when the problems already start with the API, which nevertheless became the "de-facto standard" :oops:
Click to expand...
But that's exactly what Libtls aims to be. A sane TLS API built on top of Libressl, free of Openssl legacy cruft.
github.com

libtls/TUTORIAL.md at master · bob-beck/libtls

libtls tutorial, exercises, test CA and exercise solutions - bob-beck/libtls
github.com github.com
 
Charlie_ said:
14.0: delay stable/14 branch point by one week
FreeBSD 14.0 Release Process
Click to expand...

Most likely because of the issues the (broken by design) Intel E-cores are still causing on CPUs with only E-cores, e.g. N100:

And/or because of some ZFS deadlocks for which a patch is available, but it depends on other patches that haven't been committed yet:


I was eager to test the first snapshot of stable/14 on my thinkpad T16, so I was (loosely) following what's going on on the -current mailing list for the last few days and I already suspected there will be a delay due to those two issues...
 
sko said:
Most likely because of the issues the (broken by design) Intel E-cores are still causing on CPUs with only E-cores, e.g. N100:

And/or because of some ZFS deadlocks for which a patch is available, but it depends on other patches that haven't been committed yet:


I was eager to test the first snapshot of stable/14 on my thinkpad T16, so I was (loosely) following what's going on on the -current mailing list for the last few days and I already suspected there will be a delay due to those two issues...
Click to expand...
No, it's because of some git issues. The issues you pointed out should not hold branching, but certainly can hold release.
 
  • Thanks
Reactions: sko
Hello, long time no see. Just a HEADSUP - for some reason 14-STABLE has kern.vt.enable_bell=0 by default which in combination with new syntax of mixer and new mixer errors in dmesg convinced me I have no sound. Which apparently is not true. So that's good I suppose.
 
The mixer is described in src/UPDATING.
Code: 
20210922:
        As of commit 903873ce1560, the mixer(8) utility has got a slightly
        new syntax. Please refer to the mixer(8) manual page for more
        information. The old mixer utility can be installed from ports:
        audio/freebsd-13-mixer
audio/freebsd-13-mixer
 
Fair enough. That there is a new mixer I've noticed quite promptly, the problem (as always) was a combination of assumptions, which usually were true. So maybe it will be of some use to somebody.
 
SirDice said:
Looks like I have something to do this weekend.
Click to expand...
Upgraded two systems from 13/stable to 14/stable. Few things to note for intrepid admins. There is no misc/compat13x yet. So don't run make delete-old-libs or all your installed 13.x packages are going to fail. Package repository for 14 isn't up to date either, so you will need to build your own. Packages are being built as we speak but there's still a few thousand packages to go.

Custom kernel? Do NOT remove COMPAT_FREEBSD11, 12 and 13. Rust will fail to build if COMPAT_FREEBSD11 is missing.
 
I also upgraded my Thinkpad T16 from 13.2-RELEASE to the 14.0-BETA3 14.0-ALPHA3 snapshot earlier in a new BE. The poudriere build for my packages is currently running, if everything goes well I may set up a VM with 14/stable for that...

I currently have the crippled (aka E-) cores of the i7-1255U in that laptop disabled - can anyone confirm that the patches to prevent various bugs with those cores (especially ZFS deadlocks and data corruption) have been merged?
 
sko said:
I also upgraded my Thinkpad T16 from 13.2-RELEASE to the 14.0-BETA3 snapshot earlier in a new BE. The poudriere build for my packages is currently running, if everything goes well I may set up a VM with 14/stable for that...

I currently have the crippled (aka E-) cores of the i7-1255U in that laptop disabled - can anyone confirm that the patches to prevent various bugs with those cores (especially ZFS deadlocks and data corruption) have been merged?
Click to expand...
I am on 13.2 running a machine with a 12700k. Release 13.2 works and is stable without any problems with e-cores enabled. So I am sure 14 will be even better.
 
larshenrikoern said:
I am on 13.2 running a machine with a 12700k. Release 13.2 works and is stable without any problems with e-cores enabled. So I am sure 14 will be even better.
Click to expand...
I also ran 13.2-RELEASE (actually I ran 13.2 since RC1) on that laptop and had the e-cores enabled for most of the time and didn't see any problems. I disabled them as a precaution after seeing some reports about race conditions with those crippled cores that may lead to ZFS data corruption and some other things like e.g. some port builds failing as well. I didn't follow those threads on the mailing list very closely, so I have no idea if the fixes are already merged - IIRC for ZFS there already were some mitigations. There is still ongoing work with FAT32, especially for systems that only have E-cores.
 
sko said:
I also upgraded my Thinkpad T16 from 13.2-RELEASE to the 14.0-BETA3 snapshot earlier in a new BE.
Click to expand...
There is no BETA3 release yet? Did you mean ALPHA3? There's no releng/14.0 yet.
 
Hehe, you're moving too fast. Need to get through BETA1 and 2 first ;)
 
Great - freedesktop.org's gitlab instance seems to be down (again...), so no more testing today I guess as this means most X11 and xfce4 related ports are skipped...
 
SirDice said:
Upgraded two systems from 13/stable to 14/stable. Few things to note for intrepid admins. There is no misc/compat13x yet. So don't run make delete-old-libs or all your installed 13.x packages are going to fail. Package repository for 14 isn't up to date either, so you will need to build your own. Packages are being built as we speak but there's still a few thousand packages to go.

Custom kernel? Do NOT remove COMPAT_FREEBSD11, 12 and 13. Rust will fail to build if COMPAT_FREEBSD11 is missing.
Click to expand...
yeah, this kind of pitfalls (which frankly are part of the dear old dependency hell that even BSD's can't escape) are why people are frankly reluctant to upgrade their systems. ? Well, BSD fans do take those pitfalls and live with 'em.
 
SirDice said:
Upgraded two systems from 13/stable to 14/stable. Few things to note for intrepid admins. There is no misc/compat13x yet. So don't run make delete-old-libs or all your installed 13.x packages are going to fail. Package repository for 14 isn't up to date either, so you will need to build your own. Packages are being built as we speak but there's still a few thousand packages to go.

Custom kernel? Do NOT remove COMPAT_FREEBSD11, 12 and 13. Rust will fail to build if COMPAT_FREEBSD11 is missing.
Click to expand...

I vaguely remembered that I needed COMPAT_FREEBSD11 for some reason, so adding to that 13 was a good call.

Speaking of custom kernels/modules - do take notice of ath_pci / ath change and new linuxkpi_hdmi module. Speaking of make delete-old-libs, I ran that with suprisingly minimal fallout (libcrypto), though ymmv and I still have misc/compat12x.
 
You must log in or register to reply here.
Back
Top