# FreeBSD 13.1 in beta...



## freezr (Mar 11, 2022)

Hi Folks,

this is my very first time... But what does it mean is it in beta?
Should we wait until it is going to be "released"?

Honestly is still very confusing for me the way FreeBSD moves forward... 

Thanks!


----------



## VladiBG (Mar 11, 2022)

FreeBSD 13.1 Release Process
					

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.




					www.freebsd.org


----------



## sidetone (Mar 11, 2022)

You can use it. It's better than using STABLE, which is good enough for most purposes. The biggest inconvenience with STABLE, is that it doesn't have the ability to update the system by using `freebsd-update`. With a pre-release or upcoming release, you can upgrade beta and RC versions with `freebsd-update`, until time comes that it's a production release. You can wait for an RC branch, if you want.

Only if you're using a high end production environment, you may want to consider not using it.

My new upgrading strategy is to use `freebsd-update` for minor releases, then use a clean build for major releases. So, I plan to use `freebsd-update` from 13.0 to 13.1 and 13.2, and for beta and RC versions between these. I'll use a clean install for going to 14.0.


----------



## SirDice (Mar 11, 2022)

freezr said:


> But what does it mean is it in beta?


It means it's the first 'official' release of the next version. It may still contain bugs, hence the _beta_ life cycle. 



freezr said:


> Should we wait until it is going to be "released"?


It depends. You are very much invited to _test_ the beta in order to root out any of the bugs that might be present. But it likely will contain bugs so don't test it on anything important. If you just want to have a stable system, wait until the official release.


----------



## freezr (Mar 11, 2022)

SirDice

I thought a simple `freebsd-install fetch install` would work...

But from the HB I noticed that is used this command instead:


```
# freebsd-update -r 9.1-RELEASE upgrade
```

Is this meaning that in FreeBSD the release upgrade is only "declarative" and not generic?

Should I use this command then?


```
# freebsd-update -r 13.1-RELEASE upgrade
```

Thanks,

f.


----------



## freezr (Mar 11, 2022)

Something got wrong... 


```
freebsd-update -r 13.1-RELEASE upgrade
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching metadata signature for 13.0-RELEASE from update2.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic kernel/generic-dbg src/src world/base world/lib32

The following components of FreeBSD do not seem to be installed:
world/base-dbg world/lib32-dbg

Does this look reasonable (y/n)? y

Fetching metadata signature for 13.1-RELEASE from update2.freebsd.org... failed.
Fetching metadata signature for 13.1-RELEASE from update1.freebsd.org... failed.
No mirrors remaining, giving up.

This may be because upgrading from this platform (amd64)
or release (13.1-RELEASE) is unsupported by freebsd-update. Only
platforms with Tier 1 support can be upgraded by freebsd-update.
See https://www.freebsd.org/platforms/index.html for more info.

If unsupported, FreeBSD must be upgraded by source.
```


----------



## freezr (Mar 11, 2022)

solved...

`freebsd-update -r 13.1-BETA1 upgrade`


----------



## richardtoohey2 (Mar 11, 2022)

freezr said:


> Honestly is still very confusing for me the way FreeBSD moves forward


The software development release cycle of ALPHA, BETA, RC (release candidates) and then RELEASE etc. is pretty old and I don't _think_ FreeBSD does it any differently to other projects?

For example: https://en.wikipedia.org/wiki/Software_release_life_cycle

It's good to play/test with upcoming not-yet-finished releases (like BETAs and RCs) but if you aren't confident about doing so it might be easier/less stressful to stick with the RELEASE version.  Anything I want to be running day-in-day-out I'll use RELEASE for, but I will test BETA/RC versions to make sure everything I use FreeBSD for still seems to work before the next release.


----------



## grahamperrin@ (Mar 12, 2022)

freezr said:


> Honestly is still very confusing for me the way FreeBSD moves forward...



For giggles and simplicity: `CURRENT`, `STABLE` and `RELEASE` are pictured at <https://forums.freebsd.org/posts/552550>. `STABLE` is stable, but not as stable as being on dry land.


----------



## freezr (Mar 12, 2022)

Upgrading to the 13.1-BETA was a disaster on the virtual machine: constant crashes, missing free space, eventually the VM died by itself I hope to be able to recover the VM next Monday.

The procedure as newbie looks a bit convoluted I hope to not mess up also with the real installation...


----------



## grahamperrin@ (Mar 12, 2022)

freezr said:


> virtual machine: constant crashes



Kernel panics at startup, yes?

VirtualBox?


----------



## freezr (Mar 12, 2022)

grahamperrin said:


> Kernel panics at startup, yes?
> 
> VirtualBox?



Crashing during the download and the patches applying...

By the way now is asking me to edit the GROUP file with VI (why not EE?), what a disaster...

Is this painful procedure a punishment?


----------



## freezr (Mar 12, 2022)

Eventually I made it, has been pretty cumbersome based on my previous experience with other operative systems... Now I am worried that I am going to do the same procedure several time till 13.1-RELEASE...


----------



## richardtoohey2 (Mar 12, 2022)

I don’t think FreeBSD is for you; no-one is forcing you to use it or to post about your “painful” experiences here.

Don’t mean that rudely - the BSDs don’t seem to “click” with some people and there’s plenty of other choices out there.


----------



## yu shan wei (Mar 12, 2022)

升级到13.1-BETA1:
uname -a
FreeBSD sdf.xx.cn 13.0-RELEASE-p3 FreeBSD 13.0-RELEASE-p3 #0: Tue Jun 29 19:46:20 UTC 2021     root@amd64-builder.daemonology.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
咋的了？


----------



## grahamperrin@ (Mar 12, 2022)

yu shan wei said:


> 升级到13.1-BETA1:
> 
> `uname -a`
> `FreeBSD sdf.xx.cn 13.0-RELEASE-p3 FreeBSD 13.0-RELEASE-p3 #0: Tue Jun 29 19:46:20 UTC 2021     root@amd64-builder.daemonology.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64咋的了？`



Welcome to FreeBSD Forums. From <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262470#c3>: 



> … Did you remember to restart the operating system as an essential part of a freebsd-update routine? …



Please share output from this command: 

`freebsd-version -kru`

If you need help with freebsd-update(8), please see <https://docs.freebsd.org/en/books/handbook/cutting-edge/#freebsdupdate-upgrade>, in particular:


----------



## grahamperrin@ (Mar 12, 2022)

freezr said:


> … cumbersome based on my previous experience with other operative systems …



True. There's work in progress to bring ease of use, hopefully some time in 2022. Keyword: *PkgBase*. 









						PkgBase
					

… how to safely update the system (regardless of how far out of date) reliably. …   Let's assume that PkgBase is the way forward.   and so on.  https://lists.freebsd.org/mailman/listinfo/freebsd-pkgbase  In addition to the list, there's sometimes discussion of PkgBase in IRC for FreeBSD...




					forums.freebsd.org
				




It's on the roadmap: 









						Technology Roadmap
					

https://freebsdfoundation.org/blog/technology-roadmap/  Enjoy.




					forums.freebsd.org
				






freezr said:


> … VI (why not EE?), what a disaster...
> 
> Is this painful procedure a punishment? …



I feel your pain. 









						Ask whether the default system-wide editor should be ee or vi · Issue #3 · yangzhong-freebsd/lua-httpd
					

Implementation Something like this: Which command-line editor should be the system-wide default? ee (easy editor) vi I don't know This system-wide default will apply to sh. Per-user defaults fo...




					github.com
				




I don't expect the feature to be implemented in that repo, but it was as good a place as any to attempt a rational approach.
Now, please be prepared for possible trampling of this topic …


----------



## grahamperrin@ (Mar 12, 2022)

grahamperrin said:


> … If you need help with freebsd-update(8), please see <https://docs.freebsd.org/en/books/handbook/cutting-edge/#freebsdupdate-upgrade>, …



yu shan wei this might be better for you: 

<https://docs.freebsd.org/zh-cn/books/handbook/cutting-edge/#freebsdupdate-upgrade>

It is not entirely translated, sorry.


----------



## freezr (Mar 13, 2022)

richardtoohey2 said:


> I don’t think FreeBSD is for you; no-one is forcing you to use it or to post about your “painful” experiences here.
> 
> Don’t mean that rudely - the BSDs don’t seem to “click” with some people and there’s plenty of other choices out there.



I kindly disagree, the updating process is quite convoluted and required a couple of rebooting. The documentation doesn't provide enough information, luckily I was half prepared, but what happened later was totally unexpected.

I am not sure why FreeBSD patches the system rather than downloading all the packages, to avoid bandwidth? It took a lot of time too.

Nothing delicate as an OS upgrade looks intuitive or doable the very first time, even the most polish one, there are people with a lot of experience that a certain point lost the sight if someone works fine or not, they just know what they have to do, it is an automation or the strength of the habit; that's apply to me as well, I have of plenty experience with other operative systems, windows is even worst, Debian is enough easy although it is faster   fresh installation rather than download everything from Internet.

There is a description in the marketing section of the portal that says: "FreeBSD is easy to install" but forgot to add "but is hard to upgrade"...


----------



## freezr (Mar 13, 2022)

grahamperrin said:


> I feel your pain.
> 
> 
> 
> ...



Ahahaha Thanks! 

A lot of Linux distro removed VI as default editor if not the package itself.
VI/VIM should be put optionally this modern days, computers are approached also by people like me without any informatics background but just curiosity; I don't need to learn VI in order to edit a file, I can understand is an heritage from the past but looks also intentionally malicious... Open-source software should promote the freedom of use also eliminating such useless barrier; EE is easy to use to understand and to use and should be the default editor.


----------



## grahamperrin@ (Mar 13, 2022)

freezr said:


> Ahahaha … VI/VIM should be put optionally …



vi must remain integral to FreeBSD. Its presence is assumed, or required, by many things (and people). 

▼









						What is your favorite text editor?
					

I would like to know which text editor you use in FreeBSD, I like vim very much to program, for very simple things I usually use nano.  Which one is your favorite?  PD: This does not try to be a flame "emacs vs vim" just a nice debate.




					forums.freebsd.org


----------



## grahamperrin@ (Mar 13, 2022)

freezr said:


> … what happened later was totally unexpected. …



FYI <https://old.reddit.com/r/freebsd/comments/tbm1va/-/i080tsx/>, there's a link to an introduction that:

*does forewarn about vi*
does not forewarn that vi can occur in the context of an upgrade (fair enough – it's a fairly concise introduction to _the system_ – updates and upgrades are out of scope).
<https://forums.freebsd.org/profile-posts/comments/7169> is relevant to the upgrade routine. Thanks bsduck


----------



## tux2bsd (Mar 13, 2022)

freezr you'd problably like OpenBSD, its updates/upgrades are exemplary.  Don't get me started on `freebsd-update`...


----------



## kpedersen (Mar 13, 2022)

freezr said:


> A lot of Linux distro removed VI as default editor if not the package itself.


They pretty much provide vim(-tiny) instead which functions similar. Our Vi, which is (n)vi has never really penetrated the Linux world because it is a "UNIX" util and the GNU world tends to implement their own. Same reason why our awk, our sh and tar hasn't replaced gawk, bash and gtar respectively.



freezr said:


> EE is easy to use to understand and to use and should be the default editor.


From the FreeBSD introduction:


> While easy editor [ee] is a great utility for a new user, many more experienced users will find the utility to be limited and time-consuming to use.


Obviously it is probably good enough for editing config files. Arguably (n)vi is also quite time consuming to use which is why for larger text editing tasks, most people jump to Vim (I personally use (n)vi but need to merge it with tmux and other tools to be effective with it).

The question whether it should be the default is an awkward one. Really it all simply depends on what the EDITOR variable in your .profile script contains by default (so is trivial to change). The question is, are there more beginner FreeBSD users (ee) compared to experienced FreeBSD users (vi) in this community? In Windows or Ubuntu, I would say yes but for something a bit more niche like FreeBSD, I am inclined to say no.


----------



## Alain De Vos (Mar 13, 2022)

To use it from source you can clone "releng/13.1",

```
git clone -o freebsd -b releng/13.1  https://git.FreeBSD.org/src.git    /usr/src
```






						src - FreeBSD source tree
					






					cgit.freebsd.org


----------



## grahamperrin@ (Mar 13, 2022)

checkpoint said:


> … another issue, packages in 13.1-BETA1 are three-to-four months lag behind those in 13.0-RELEASE. WTF ?



checkpoint sorry, I can't visualise this lag, can you offer an example? 

(I installed KDE Plasma etc. from quarterly, things continued to work after I switched to latest. I paid very little attention to versions or dates of packages.)


----------



## checkpoint (Mar 14, 2022)

grahamperrin said:


> checkpoint sorry, I can't visualise this lag, can you offer an example?



The problem was in misconfigured pkg that uses quarterly updates by default. Sorry for missguiding.


----------



## freezr (Mar 14, 2022)

kpedersen said:


> The question whether it should be the default is an awkward one. Really it all simply depends on what the EDITOR variable in your .profile script contains by default (so is trivial to change). The question is, are there more beginner FreeBSD users (ee) compared to experienced FreeBSD users (vi) in this community? In Windows or Ubuntu, I would say yes but for something a bit more niche like FreeBSD, I am inclined to say no.



Well, let us put in this way, the installer might be so kind to put as *option "*EE" and describing it as _"recommended for beginner users" _; in this way veteran and advanced users won't hurt their feelings while beginners can avoid to deal with VI... 

For instance I write (not code) a lot on the terminal with *Micro: it is my daily driver editor!*


----------



## kpedersen (Mar 14, 2022)

freezr said:


> Well, let us put in this way, the installer might be so kind to put as *option "*EE" and describing it as _"recommended for beginner users"_


No other OS really does that. Would it set it globally by adding it to i.e /usr/share/skel/dot.profile? For all users regardless of beginner or advanced? For example the guy installing the OS might have quite different needs to the users actually utilizing the system. More likely this should be an option in the "adduser" flow when creating a new user rather than a systemwide default. Something like here (from the old sysinstall):






Another example is moving on from the EDITOR slightly, what about the default PAGER (less, more) or SHELL? It is very "micro managery" to set all of these during install in my opinion and seems inconsistent to only specify some.

I possibly instead recommend adding this info to the "post install" help. I.e: https://docs.freebsd.org/doc/6.1-RELEASE/usr/share/doc/handbook/install-post.html
(apologies for the old link, they recently "modernized" the handbook and it is crap to search in)

Or yes, similar to what you mentioned; an optional menu in the installer that perhaps isn't in main flow (so not to convolute the process). Perhaps a similar menu to the "Security tasks" that appears allowing you to hide process IDs between Jails, etc.



freezr said:


> in this way veteran and advanced users won't hurt their feelings while beginners can avoid to deal with VI...


I don't particularly think it will be the advanced users that will need to be convinced or have their feelings maintained. More likely it will be the FreeBSD developers who as you might imagine are quite familiar with (n)vi by now.


----------



## grahamperrin@ (Mar 14, 2022)

grahamperrin said:


> FreeBSD 13.1-RELEASE Release Notes
> 
> 
> FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.
> ...



Comment <https://github.com/freebsd/freebsd-...e12c0ad34c4726ca68aacb#commitcomment-68634628> refers to a bug report for a new feature.


----------



## grahamperrin@ (Mar 14, 2022)

bsduck said:


> … graphics/drm-fbsd13-kmod suffers from PR 253801 making it unreliable on 13.0-RELEASE.



bsduck if you can, please test with `13.1-BETA1-p0` with graphics/drm-devel-kmod (built from ports): 

first, without x11-drivers/xf86-video-intel
then – *only if* the kernel panics at wake/resume time _without_ this legacy software – with xf86-video-intel.
Thanks


----------



## bsduck (Mar 14, 2022)

If drm-devel-kmod can be built on 13.1-BETA1, I'm almost sure it will work fine.
I'm currently using it without suspend issues on 13.1-STABLE, which is at the moment very similar to 13.1-BETA1.
The bug is in drm-fbsd13-kmod, not in the base system. It will probably disappear upon a future major upgrade of this port.


----------



## freezr (Mar 14, 2022)

kpedersen said:


> No other OS really does that. [...] More likely it will be the FreeBSD developers who as you might imagine are quite familiar with (n)vi by now.



All your ideas are super... 

Based on your suggestions maybe the easier solution would be to add a big disclaimer box on how changing temporarily VI as default editor right after the Title Section in the handbook...


----------



## chrbr (Mar 14, 2022)

freezr said:


> Based on your suggestions maybe the easier solution would be to add a big disclaimer box on how changing temporarily VI as default editor right after the Title Section in the handbook...


I am not sure. For very basic editing with vi only a few commands are really necessary. Once you have started you can improve gradually.

BTW: The worst editing experience I had was with a Debian rescue disk. There was no vi but some pico/nano like one without any information about the control key assignment. The second worse one was long ago when I have had to use edlin which was the only editor on a DOS rescue disk. Fortunately I have had a small book with the edlin manual.


----------



## kpedersen (Mar 14, 2022)

freezr said:


> right after the Title Section in the handbook...


Not *right* after the title section. That position is reserved for the disclaimer of how to exit out of Vi! 



chrbr said:


> I am not sure. For very basic editing with vi only a few commands are really necessary. Once you have started you can improve gradually.


It is a good point. Lets say ee has ~1% of the features of vi. Only around 1% of features are needed anyway for basic text editing and you can learn that amount of vi in about 15 mins.


----------



## Erichans (Mar 14, 2022)

chrbr said:


> I am not sure. For very basic editing with vi only a few commands are really necessary. Once you have started you can improve gradually.


One could try to make a small, like a one page A4/letter size, survival guide for vi, based on the biggest stumbling blocks that users new to vi experience. Not cramming most and every conceivable command into that piece of information but centered on the very basic editing commands and curcor movements. I think the aspect of modal editing should be front and center*.

This sounds trivial but I fear it isn't: it means condensing all users' previous attitudes and experiences into such a small space that it would be usefull to all across different learning styles. New individual users probably could, when stumbling again and again on the same stuff, make such a small _individual_ survival guide by trial and error learning. That presupposes that they do not consult some of the fine tutorials/guides that describe (n)vi(m) in depth. This doesn't mean that they will have to gell with vi as the latest** greatest thing since sliced bread as their editor of choice, or that they would (need to) become proficient with vi; or that they have to like it: just to survive with it.

That said: _if_ there will be a selection mechanism that selects either vi or another (non-modal) editor and that selection can also be made after installation (also not a trivial task covering for all eventualities), then I would be fine with that.

___
* not particularly explaining what that is in depth but more so explaining what kind of (unexpected) behaviour one can experience in the wrong mode and what to do to get out of that.
** well, ... actually one of the oldest


----------



## grahamperrin@ (Mar 14, 2022)

freezr said:


> * "*EE" and describing it





freezr said:


> Micro: it is my daily driver editor!





chrbr said:


> with vi





Erichans said:


> for vi,











						What is your favorite text editor?
					

I would like to know which text editor you use in FreeBSD, I like vim very much to program, for very simple things I usually use nano.  Which one is your favorite?  PD: This does not try to be a flame "emacs vs vim" just a nice debate.




					forums.freebsd.org
				




(Maybe better to discuss 13.1-BETA in this 13.1-BETA topic? Thanks.)


----------



## sidetone (Mar 14, 2022)

For emergency mode boot ups, `vi` and other commands from /rescue/ are useful. In this setting, the whole directory with the command must be used: `/rescue/vi`.

What's helpful for normal uses of vi, is to create .nexrc, in your home (plus including root) directory, and add to it:

```
set showmode
set verbose
```
This adds a text display to the bottom right corner of vi, to show which mode it's in. This helps a lot, so I don't have to guess if it's in command mode or append mode.


----------



## freezr (Mar 14, 2022)

Guys seriously... in the middle of a panic attac understanding why VI is so hardly convoluted is not what you want learning.  

The point is you don't need any 30", 1', 5', 15" tutorial to learn how to use Nano(Pico) or EE; the fact that is supposed to learn a tutorial to edit or remove a line is just diabolic!


----------



## sidetone (Mar 14, 2022)

Nano (Pico) and EE aren't in rescue mode, as they're not in the /rescue/ directory.

For the configuration file in the home directory, that may not accessible from rescue mode anyway, If you use other text editors that may not be needed. You'll need basic configuration files like that anyway to use FreeBSD.


----------



## kpedersen (Mar 14, 2022)

freezr said:


> The point is you don't need any 30", 1', 5', 15" tutorial to learn how to use Nano(Pico) or EE


Similar to chrbr's point. nano or ee don't even support the functionality of `"n,` so why would someone suddenly feel they need it when using vi? Stick to the basics until they are more experienced.

... or they could simply just run `ee` rather than `vi` from the shell.


----------



## scottro (Mar 14, 2022)

I just ran a freebsd-update on a pretty much unused laptop (shared with Linux distros) and it went quite smoothly. The FreeBSD install is on ZFS so ran bectl create before upgrading in case I ran into issues. However, there were none. Upgrade was smooth, all packages continued to work, including X which uses drm-kmod (Built with package, not port).  I'm not confident enough to upgrade on my main workstation, but I had no probems on this machine, which admittedly, doesn't have too much on it.


----------



## covacat (Mar 14, 2022)

freebsd 14 will have ee replaced with teco


----------



## checkpoint (Mar 14, 2022)

kpedersen said:


> It is a good point. Lets say ee has ~1% of the features of vi. Only around 1% of features are needed anyway for basic text editing and you can learn that amount of vi in about 15 mins.


Please, please, leave vi alone, don't change it to ee! It's not about features, it is about the nature of Unix. Let beginners feel the nature of Unix from the start, let them use vi(1). My suggestion is to show a brief  vi cheatsheet before invoking editor for beginners, tell them how to save and quit.


----------



## kpedersen (Mar 14, 2022)

checkpoint said:


> it is about the nature of Unix. Let beginners feel the nature of Unix from the start


Indeed. It goes even further. vi is part of the UNIX specification - Shell and Utilities (XCU). It needs to remain for potential certification and I don't believe are optional components:

https://en.wikipedia.org/wiki/Single_UNIX_Specification

Whilst certification doesn't mean too much in this day and age, I think what some beginners are suggesting these days is change the "default" UNIX editor to `ee` which I (and I imagine many others) are a little skeptical about.


----------



## grahamperrin@ (Mar 14, 2022)

grahamperrin said:


> Now, please be prepared for possible trampling of this topic …



For anyone who would like to discuss FreeBSD 13.1-BETA, instead of text editors, there's this 𠄶– begun by vermaden:

FreeBSD 13.1-BETA1 Now Available


----------



## kpedersen (Mar 14, 2022)

grahamperrin said:


> For anyone who would like to discuss FreeBSD 13.1-BETA, instead of text editors, there's this 𠄶– begun by vermaden:


In an empty 4 days old thread on reddit with just one comment (removed by moderator)?

 I think people would rather take their chances in here even though the discussion has devolved into text editors (partly my fault, I admit).


----------



## Phishfry (Mar 14, 2022)

covacat said:


> freebsd 14 will have ee replaced with teco


Please tell me this is an early Aprils Fools joke.
Bad enough to change the default shell but easy editor nixed too?


----------



## scottro (Mar 14, 2022)

I do remember some sort of joke, maybe a facial expression or something, or maybe a shocked cat, with the caption, someone who just ssh'd into Debian and can't get out of nano. (On Debian, I believe nano is their default editor)

I've told this story before, but I thought I was cool because I knew how to use pico. It was my first IT job and my boss asked me to do something on the AIX server. I telnetted in (this was a LONG) time ago, and then had to call him back, "They don't have pico on there." He said, "You don't know how to use vi? Never mind, I'll do it"
That night I learned the vi basics. He was a good guy, and amused by it, and probably more amused by how embarrassed I was. 
And yeah, I assume covacat, (who has one of my favorite icons here, by the way), is joking.


----------



## freezr (Mar 15, 2022)

kpedersen said:


> Similar to chrbr's point. nano or ee don't even support the functionality of `"n,` so why would someone suddenly feel they need it when using vi? Stick to the basics until they are more experienced.
> 
> ... or they could simply just run `ee` rather than `vi` from the shell.



Sincerely I didn't understand the irony... (is not a complain) 

I don't care about the elitism of *BSD, Unix, etc. I totally endorse it! 

I discovered the *BSDs and I liked them more than Linux, *I think the BSD licenses preserve the software freedom much better than the GPLs* (although I am not against the GPL at all, simply BSD licenses are more effective from my point of view), I would like to use the *BSDs as much as I can, however I have my limitations as well as my aspirations (but not as sysad, devops, coders and the likes).

Please just give me tools that I understand and I can use and put them visible, I can't go as a "dowser" looking for answers when I don't even know the questions...


----------



## grahamperrin@ (Mar 16, 2022)

> FreeBSD 13.1 in beta …​



Open bug reports for `13.1-RELEASE`:

<https://bugs.freebsd.org/bugzilla/b...04&query_format=advanced&version=13.1-RELEASE>


----------



## grahamperrin@ (Mar 16, 2022)

bsduck said:


> If drm-devel-kmod can be built on 13.1-BETA1,



Confirmed (screen recording).


----------



## checkpoint (Mar 17, 2022)

drm-devel-kmod can be built on 13.1-BETA1, but Xorg 1.20.14 (also 1.20.13) crashes while accessing amdgpu. Here how it looks like on my AMD Ryzen 5 (Cezanne) based laptop:


```
Id Refs Address                Size Name
 1  186 0xffffffff80200000  1f2f7a8 kernel
 2    1 0xffffffff82af9000     639c linprocfs.ko
 3    6 0xffffffff82b00000    10a40 linux_common.ko
 4    1 0xffffffff82b11000     3284 linsysfs.ko
 5    1 0xffffffff82b15000     3530 fdescfs.ko
 6    1 0xffffffff82b19000    17310 if_iwm.ko
 7    1 0xffffffff82b31000    fd1b8 iwm7265Dfw.ko
 8    1 0xffffffff82c2f000   1223d8 iwm7265fw.ko
 9    1 0xffffffff82e00000   391370 amdgpu.ko
10    2 0xffffffff82d52000    7ec58 drm.ko
11    3 0xffffffff82dd1000     b490 linuxkpi_gplv2.ko
12    1 0xffffffff82ddd000     2328 lindebugfs.ko
13    1 0xffffffff82de0000     e768 ttm.ko
14    1 0xffffffff82def000     2218 amdgpu_renoir_gpu_info_bin.ko
15    1 0xffffffff82df2000     64d8 amdgpu_renoir_sdma_bin.ko
16    1 0xffffffff83192000    2e2d8 amdgpu_renoir_asd_bin.ko
17    1 0xffffffff831c1000     7558 amdgpu_renoir_pfp_bin.ko
18    1 0xffffffff82df9000     6558 amdgpu_renoir_me_bin.ko
19    1 0xffffffff831c9000     4558 amdgpu_renoir_ce_bin.ko
20    1 0xffffffff831ce000     b8d0 amdgpu_renoir_rlc_bin.ko
21    1 0xffffffff831da000    437e8 amdgpu_renoir_mec_bin.ko
22    1 0xffffffff8321e000    437e8 amdgpu_renoir_mec2_bin.ko
23    1 0xffffffff83262000    1f160 amdgpu_renoir_dmcub_bin.ko
24    1 0xffffffff83282000    71d58 amdgpu_renoir_vcn_bin.ko
25    1 0xffffffff832f4000    fd310 nvidia-modeset.ko
26    1 0xffffffff83400000  234e958 nvidia.ko
27    2 0xffffffff8574f000    38070 linux.ko
28    1 0xffffffff85788000    11cd8 fusefs.ko
29    1 0xffffffff833f2000     6730 cuse.ko
30    1 0xffffffff833f9000     5e7c ig4.ko
31    2 0xffffffff8579a000     433c iicbus.ko
32    1 0xffffffff8579f000     3240 iichid.ko
33    6 0xffffffff857a3000     31f8 hidbus.ko
34    1 0xffffffff857a7000    184c8 smbfs.ko
35    2 0xffffffff857c0000     4798 libiconv.ko
36    2 0xffffffff857c5000     3090 libmchain.ko
37    1 0xffffffff857c9000     3378 acpi_wmi.ko
38    2 0xffffffff857cd000     22b0 hconf.ko
39    1 0xffffffff857d0000     21e8 hms.ko
40    1 0xffffffff857d3000     30a8 hidmap.ko
41    1 0xffffffff857d7000     3328 hmt.ko
42    1 0xffffffff857db000     3218 intpm.ko
43    1 0xffffffff857df000     2180 smbus.ko
44    1 0xffffffff857e2000     2340 uhid.ko
45    1 0xffffffff857e5000     4350 ums.ko
46    1 0xffffffff857ea000     3380 usbhid.ko
47    1 0xffffffff857ee000     3320 wmt.ko
48    1 0xffffffff857f2000     4d00 ng_ubt.ko
49    3 0xffffffff857f7000     aac8 netgraph.ko
50    2 0xffffffff85802000     a238 ng_hci.ko
51    2 0xffffffff8580d000     25a8 ng_bluetooth.ko
52    1 0xffffffff85810000    32208 linux64.ko
53    1 0xffffffff85843000     2260 pty.ko
54    1 0xffffffff85846000     5af8 autofs.ko
55    1 0xffffffff8584c000     2a08 mac_ntpd.ko
```


```
rz@butterfly:~ % cat /var/log/Xorg.0.log
[ 88580.568]
X.Org X Server 1.20.14
X Protocol Version 11, Revision 0
[ 88580.568] Build Operating System: FreeBSD 13.1-BETA1 amd64
[ 88580.568] Current Operating System: FreeBSD butterfly 13.1-BETA1 FreeBSD 13.1-BETA1 #3: Sun Mar 13 06:28:35 +05 2022     rz@butterfly:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
[ 88580.568] Build Date: 15 March 2022  03:38:05AM
[ 88580.568]
[ 88580.568] Current version of pixman: 0.40.0
[ 88580.568]     Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
[ 88580.568] Markers: (--) probed, (**) from config file, (==) default setting,
    (++) from command line, (!!) notice, (II) informational,
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 88580.568] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Mar 18 02:19:26 2022
[ 88580.569] (==) Using config file: "/etc/X11/xorg.conf"
[ 88580.569] (==) Using system config directory "/usr/local/share/X11/xorg.conf.d"
[ 88580.569] (==) ServerLayout "layout"
[ 88580.569] (**) |-->Screen "iGPU" (0)
[ 88580.569] (**) |   |-->Monitor "<default monitor>"
[ 88580.569] (**) |   |-->Device "iGPU"
[ 88580.569] (**) |   |-->GPUDevice "dGPU"
[ 88580.569] (==) No monitor specified for screen "iGPU".
    Using a default monitor configuration.
[ 88580.569] (**) |-->Input Device "Keyboard0"
[ 88580.569] (**) |-->Input Device "Mouse0"
[ 88580.569] (==) Automatically adding devices
[ 88580.569] (==) Automatically enabling devices
[ 88580.569] (==) Not automatically adding GPU devices
[ 88580.569] (==) Max clients allowed: 256, resource mask: 0x1fffff
[ 88580.570] (WW) The directory "/usr/local/lib/X11/fonts/jmk/" does not exist.
[ 88580.570]     Entry deleted from font path.
[ 88580.570] (**) FontPath set to:
    /usr/local/share/fonts/ChromeOS/,
    /usr/local/share/fonts/misc/,
    /usr/local/share/fonts/TTF/,
    /usr/local/share/fonts/OTF/,
    /usr/local/share/fonts/Type1/,
    /usr/local/share/fonts/100dpi/,
    /usr/local/share/fonts/75dpi/,
    catalogue:/usr/local/etc/X11/fontpath.d
[ 88580.570] (==) ModulePath set to "/usr/local/lib/xorg/modules"
[ 88580.570] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[ 88580.570] (WW) Disabling Keyboard0
[ 88580.570] (WW) Disabling Mouse0
[ 88580.570] (II) Loader magic: 0x433270
[ 88580.570] (II) Module ABI versions:
[ 88580.570]     X.Org ANSI C Emulation: 0.4
[ 88580.570]     X.Org Video Driver: 24.1
[ 88580.570]     X.Org XInput driver : 24.1
[ 88580.570]     X.Org Server Extension : 10.0
[ 88580.570] (--) PCI: (1@0:0:0) 10de:25a2:17aa:3a5d rev 161, Mem @ 0xd0000000/16777216, 0xfb00000000/4294967296, 0xfc00000000/33554432, I/O @ 0x00003000/128
[ 88580.570] (--) PCI:*(5@0:0:0) 1002:1638:17aa:3a5d rev 198, Mem @ 0xfc10000000/268435456, 0xfc20000000/2097152, 0xd1400000/524288, I/O @ 0x00001000/256, BIOS @ 0x????????/65536
[ 88580.570] (II) LoadModule: "glx"
[ 88580.570] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so
[ 88580.571] (II) Module glx: vendor="X.Org Foundation"
[ 88580.571]     compiled for 1.20.14, module version = 1.0.0
[ 88580.571]     ABI class: X.Org Server Extension, version 10.0
[ 88580.571] (II) LoadModule: "amdgpu"
[ 88580.571] (II) Loading /usr/local/lib/xorg/modules/drivers/amdgpu_drv.so
[ 88580.571] (II) Module amdgpu: vendor="X.Org Foundation"
[ 88580.571]     compiled for 1.20.13, module version = 19.1.0
[ 88580.571]     Module class: X.Org Video Driver
[ 88580.571]     ABI class: X.Org Video Driver, version 24.1
[ 88580.571] (II) LoadModule: "nvidia"
[ 88580.571] (II) Loading /usr/local/lib/xorg/modules/drivers/nvidia_drv.so
[ 88580.572] (II) Module nvidia: vendor="NVIDIA Corporation"
[ 88580.572]     compiled for 1.6.99.901, module version = 1.0.0
[ 88580.572]     Module class: X.Org Video Driver
[ 88580.572] (II) AMDGPU: Driver for AMD Radeon:
    All GPUs supported by the amdgpu kernel driver
[ 88580.572] (II) NVIDIA dlloader X Driver  510.54  Tue Feb  8 04:29:15 UTC 2022
[ 88580.572] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
[ 88580.572] (--) Using syscons driver with X support (version 2.0)
[ 88580.572] (--) using VT number 9

[ 88580.590] (II) AMDGPU(0): [KMS] Kernel modesetting enabled.
[ 88580.593] (II) Loading sub module "fb"
[ 88580.593] (II) LoadModule: "fb"
[ 88580.593] (II) Loading /usr/local/lib/xorg/modules/libfb.so
[ 88580.593] (II) Module fb: vendor="X.Org Foundation"
[ 88580.593]     compiled for 1.20.14, module version = 1.0.0
[ 88580.593]     ABI class: X.Org ANSI C Emulation, version 0.4
[ 88580.593] (II) Loading sub module "wfb"
[ 88580.593] (II) LoadModule: "wfb"
[ 88580.593] (II) Loading /usr/local/lib/xorg/modules/libwfb.so
[ 88580.593] (II) Module wfb: vendor="X.Org Foundation"
[ 88580.593]     compiled for 1.20.14, module version = 1.0.0
[ 88580.593]     ABI class: X.Org ANSI C Emulation, version 0.4
[ 88580.593] (II) Loading sub module "ramdac"
[ 88580.593] (II) LoadModule: "ramdac"
[ 88580.593] (II) Module "ramdac" already built-in
[ 88580.593] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[ 88580.593] (EE) Screen 1 deleted because of no matching config section.
[ 88580.593] (II) UnloadModule: "nvidia"
[ 88580.593] (II) UnloadSubModule: "wfb"
[ 88580.593] (II) UnloadSubModule: "fb"
[ 88580.593] (II) AMDGPU(0): Creating default Display subsection in Screen section
    "iGPU" for depth/fbbpp 24/32
[ 88580.594] (==) AMDGPU(0): Depth 24, (--) framebuffer bpp 32
[ 88580.594] (II) AMDGPU(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
[ 88580.594] (==) AMDGPU(0): Default visual is TrueColor
[ 88580.594] (==) AMDGPU(0): RGB weight 888
[ 88580.594] (II) AMDGPU(0): Using 8 bits per RGB (8 bit DAC)
[ 88580.594] (--) AMDGPU(0): Chipset: "Unknown AMD Radeon GPU" (ChipID = 0x1638)
[ 88580.594] (II) Loading sub module "fb"
[ 88580.594] (II) LoadModule: "fb"
[ 88580.594] (II) Loading /usr/local/lib/xorg/modules/libfb.so
[ 88580.594] (II) Module fb: vendor="X.Org Foundation"
[ 88580.594]     compiled for 1.20.14, module version = 1.0.0
[ 88580.594]     ABI class: X.Org ANSI C Emulation, version 0.4
[ 88580.594] (II) Loading sub module "dri2"
[ 88580.594] (II) LoadModule: "dri2"
[ 88580.594] (II) Module "dri2" already built-in
[ 88580.629] (II) Loading sub module "glamoregl"
[ 88580.629] (II) LoadModule: "glamoregl"
[ 88580.629] (II) Loading /usr/local/lib/xorg/modules/libglamoregl.so
[ 88580.635] (II) Module glamoregl: vendor="X.Org Foundation"
[ 88580.635]     compiled for 1.20.14, module version = 1.0.1
[ 88580.635]     ABI class: X.Org ANSI C Emulation, version 0.4
[ 88580.641] (EE) AMDGPU(0): eglGetDisplay() failed
[ 88580.641] (EE) AMDGPU(0): glamor detected, failed to initialize EGL.
[ 88580.641] (WW) AMDGPU(0): amdgpu_glamor_pre_init returned FALSE, using ShadowFB
[ 88580.641] (II) Loading sub module "shadow"
[ 88580.641] (II) LoadModule: "shadow"
[ 88580.641] (II) Loading /usr/local/lib/xorg/modules/libshadow.so
[ 88580.641] (II) Module shadow: vendor="X.Org Foundation"
[ 88580.641]     compiled for 1.20.14, module version = 1.1.0
[ 88580.641]     ABI class: X.Org ANSI C Emulation, version 0.4
[ 88580.641] (II) AMDGPU(0): KMS Pageflipping: enabled
[ 88580.642] (II) AMDGPU(0): Output eDP has no monitor section
[ 88580.642] (II) AMDGPU(0): Output HDMI-A-0 has no monitor section
[ 88580.652] (WW) EDID timing clock 166.01 exceeds claimed max 145MHz, fixing
[ 88580.652] (II) AMDGPU(0): EDID for output eDP
[ 88580.652] (II) AMDGPU(0): Manufacturer: AUO  Model: 4a99  Serial#: 0
[ 88580.652] (II) AMDGPU(0): Year: 2021  Week: 1
[ 88580.652] (II) AMDGPU(0): EDID Version: 1.4
[ 88580.652] (II) AMDGPU(0): Digital Display Input
[ 88580.652] (II) AMDGPU(0): 8 bits per channel
[ 88580.652] (II) AMDGPU(0): Digital interface is DisplayPort
[ 88580.652] (II) AMDGPU(0): Max Image Size [cm]: horiz.: 34  vert.: 19
[ 88580.652] (II) AMDGPU(0): Gamma: 2.20
[ 88580.652] (II) AMDGPU(0): No DPMS capabilities specified
[ 88580.652] (II) AMDGPU(0): Supported color encodings: RGB 4:4:4
[ 88580.652] (II) AMDGPU(0): First detailed timing is preferred mode
[ 88580.652] (II) AMDGPU(0): Preferred mode is native pixel format and refresh rate
[ 88580.652] (II) AMDGPU(0): Display is continuous-frequency
[ 88580.652] (II) AMDGPU(0): redX: 0.575 redY: 0.346   greenX: 0.347 greenY: 0.572
[ 88580.652] (II) AMDGPU(0): blueX: 0.158 blueY: 0.117   whiteX: 0.313 whiteY: 0.329
[ 88580.652] (II) AMDGPU(0): Manufacturer's mask: 0
[ 88580.652] (II) AMDGPU(0): Supported detailed timing:
[ 88580.652] (II) AMDGPU(0): clock: 166.0 MHz   Image Size:  344 x 194 mm
[ 88580.652] (II) AMDGPU(0): h_active: 1920  h_sync: 2028  h_sync_end 2076 h_blank_end 2120 h_border: 0
[ 88580.652] (II) AMDGPU(0): v_active: 1080  v_sync: 1090  v_sync_end 1100 v_blanking: 1304 v_border: 0
[ 88580.652] (II) AMDGPU(0): Unknown vendor-specific block f
[ 88580.652] (II) AMDGPU(0): Ranges: V min: 48 V max: 60 Hz, H min: 68 H max: 68 kHz, PixClock max 167 MHz
[ 88580.652] (II) AMDGPU(0):  B156HAN02.1
[ 88580.652] (II) AMDGPU(0): EDID (in hex):
[ 88580.652] (II) AMDGPU(0):     00ffffffffffff0006af994a00000000
[ 88580.652] (II) AMDGPU(0):     011f0104a5221378036e859358589228
[ 88580.652] (II) AMDGPU(0):     1e505400000001010101010101010101
[ 88580.652] (II) AMDGPU(0):     010101010101d94080c87038e0406c30
[ 88580.652] (II) AMDGPU(0):     aa0058c2100000180000000f00000000
[ 88580.652] (II) AMDGPU(0):     00000000000000000020000000fd0030
[ 88580.652] (II) AMDGPU(0):     3c44440e010a202020202020000000fe
[ 88580.652] (II) AMDGPU(0):     004231353648414e30322e310a2000ea
[ 88580.652] (II) AMDGPU(0): Printing probed modes for output eDP
[ 88580.652] (II) AMDGPU(0): Modeline "1920x1080"x60.1  166.01  1920 2028 2076 2120  1080 1090 1100 1304 -hsync -vsync (78.3 kHz eP)
[ 88580.652] (II) AMDGPU(0): Modeline "1680x1050"x60.1  166.01  1680 2028 2076 2120  1050 1090 1100 1304 -hsync -vsync (78.3 kHz e)
[ 88580.652] (II) AMDGPU(0): Modeline "1280x1024"x60.1  166.01  1280 2028 2076 2120  1024 1090 1100 1304 -hsync -vsync (78.3 kHz e)
[ 88580.652] (II) AMDGPU(0): Modeline "1440x900"x60.1  166.01  1440 2028 2076 2120  900 1090 1100 1304 -hsync -vsync (78.3 kHz e)
[ 88580.652] (II) AMDGPU(0): Modeline "1280x800"x60.1  166.01  1280 2028 2076 2120  800 1090 1100 1304 -hsync -vsync (78.3 kHz e)
[ 88580.652] (II) AMDGPU(0): Modeline "1280x720"x60.1  166.01  1280 2028 2076 2120  720 1090 1100 1304 -hsync -vsync (78.3 kHz e)
[ 88580.652] (II) AMDGPU(0): Modeline "1024x768"x60.1  166.01  1024 2028 2076 2120  768 1090 1100 1304 -hsync -vsync (78.3 kHz e)
[ 88580.652] (II) AMDGPU(0): Modeline "800x600"x60.1  166.01  800 2028 2076 2120  600 1090 1100 1304 -hsync -vsync (78.3 kHz e)
[ 88580.652] (II) AMDGPU(0): Modeline "640x480"x60.1  166.01  640 2028 2076 2120  480 1090 1100 1304 -hsync -vsync (78.3 kHz e)
[ 88580.652] (II) AMDGPU(0): EDID for output HDMI-A-0
[ 88580.652] (II) AMDGPU(0): Output eDP connected
[ 88580.652] (II) AMDGPU(0): Output HDMI-A-0 disconnected
[ 88580.652] (II) AMDGPU(0): Using exact sizes for initial modes
[ 88580.652] (II) AMDGPU(0): Output eDP using initial mode 1920x1080 +0+0
[ 88580.652] (II) AMDGPU(0): mem size init: gart size :ffb6d000 vram size: s:fe379000 visible:fe379000
[ 88580.652] (==) AMDGPU(0): DPI set to (96, 96)
[ 88580.652] (==) AMDGPU(0): Using gamma correction (1.0, 1.0, 1.0)
[ 88580.652] (II) Loading sub module "ramdac"
[ 88580.652] (II) LoadModule: "ramdac"
[ 88580.652] (II) Module "ramdac" already built-in
[ 88580.652] (II) AMDGPU(0): Front buffer pitch: 7680 bytes
[ 88580.652] (==) AMDGPU(0): DRI3 disabled
[ 88580.652] (==) AMDGPU(0): Backing store enabled
[ 88580.652] (WW) AMDGPU(0): Direct rendering disabled
[ 88580.652] (II) AMDGPU(0): 2D and 3D acceleration disabled
[ 88580.652] (==) AMDGPU(0): DPMS enabled
[ 88580.652] (==) AMDGPU(0): Silken mouse enabled
[ 88580.669] (II) Initializing extension Generic Event Extension
[ 88580.669] (II) Initializing extension SHAPE
[ 88580.669] (II) Initializing extension MIT-SHM
[ 88580.669] (II) Initializing extension XInputExtension
[ 88580.669] (II) Initializing extension XTEST
[ 88580.670] (II) Initializing extension BIG-REQUESTS
[ 88580.670] (II) Initializing extension SYNC
[ 88580.670] (II) Initializing extension XKEYBOARD
[ 88580.670] (II) Initializing extension XC-MISC
[ 88580.670] (II) Initializing extension SECURITY
[ 88580.670] (II) Initializing extension XFIXES
[ 88580.670] (II) Initializing extension RENDER
[ 88580.670] (II) Initializing extension RANDR
[ 88580.671] (II) Initializing extension COMPOSITE
[ 88580.671] (II) Initializing extension DAMAGE
[ 88580.671] (II) Initializing extension MIT-SCREEN-SAVER
[ 88580.671] (II) Initializing extension DOUBLE-BUFFER
[ 88580.671] (II) Initializing extension RECORD
[ 88580.671] (II) Initializing extension DPMS
[ 88580.671] (II) Initializing extension Present
[ 88580.671] (II) Initializing extension DRI3
[ 88580.671] (II) Initializing extension X-Resource
[ 88580.671] (II) Initializing extension XVideo
[ 88580.672] (II) Initializing extension XVideo-MotionCompensation
[ 88580.672] (II) Initializing extension GLX
[ 88580.672] (II) AIGLX: Screen 0 is not DRI2 capable
[ 88580.674] (II) IGLX: Loaded and initialized swrast
[ 88580.674] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[ 88580.674] (II) Initializing extension XFree86-VidModeExtension
[ 88580.674] (II) Initializing extension XFree86-DGA
[ 88580.674] (II) Initializing extension XFree86-DRI
[ 88580.674] (II) Initializing extension DRI2
[ 88580.674] (II) AMDGPU(0): Setting screen physical size to 508 x 285
[ 88580.699] (EE)
[ 88580.699] (EE) Backtrace:
[ 88580.701] (EE) 0: /usr/local/bin/Xorg (OsInit+0x38a) [0x41c96a]
[ 88580.704] (EE) unw_get_proc_name failed: no unwind info found [-10]
[ 88580.704] (EE) 1: /lib/libthr.so.3 (?+0x0) [0x80093158e]
[ 88580.706] (EE) unw_get_proc_name failed: no unwind info found [-10]
[ 88580.706] (EE) 2: /lib/libthr.so.3 (?+0x0) [0x800930b3f]
[ 88580.707] (EE) 3: ? (?+0x0) [0x7ffffffff8a3]
[ 88580.710] (EE) unw_get_proc_name failed: no unwind info found [-10]
[ 88580.710] (EE) 4: /lib/libc.so.7 (?+0x0) [0x800a7c2ca]
[ 88580.712] (EE) unw_get_proc_name failed: no unwind info found [-10]
[ 88580.712] (EE) 5: /lib/libthr.so.3 (?+0x0) [0x800930a00]
[ 88580.713] (EE) 6: ? (?+0x0) [0x0]
[ 88580.715] (EE) unw_get_proc_name failed: no unwind info found [-10]
[ 88580.715] (EE) 7: /lib/libc.so.7 (?+0x0) [0x8009f4c74]
[ 88580.715] (EE) unw_step failed: unspecified (general) error [-1]
[ 88580.715] (EE)
[ 88580.715] (EE)
Fatal server error:
[ 88580.715] (EE) Caught signal 6 (Abort trap). Server aborting
[ 88580.715] (EE)
[ 88580.715] (EE)
Please consult the The X.Org Foundation support
     at http://wiki.x.org
 for help.
[ 88580.715] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
```


----------



## grahamperrin@ (Mar 17, 2022)

Thanks, 



checkpoint said:


> drm-devel-kmod can be built on 13.1-BETA1, but Xorg 1.20.14 (also 1.20.13) crashes while accessing amdgpu. … AMD Ryzen 5 (Cezanne)



Is Cezanne more modern than Renoir? 

<https://old.reddit.com/r/freebsd/comments/td76na/-/i0q4xsf/>, 



> I can confirm that my AMD Renoir (4750G) APU works with drm-devel-kmod-5.7.19 compiled from ports on 13.1-BETA1.


----------



## checkpoint (Mar 17, 2022)

grahamperrin said:


> Is Cezanne more modern than Renoir?



Yes, here's what Wikipedia says:


```
Cezanne
General Info
Designer    AMD
Manufacturer    TSMC
Introduction    January 12, 2021 (announced)
```


```
Renoir
General Info
Designer    AMD
Manufacturer    TSMC
Introduction    January 6, 2020 (announced)
January 6, 2020 (launched)
```

Here's what pciconf reports:


```
vgapci1@pci0:5:0:0:    class=0x030000 rev=0xc6 hdr=0x00 vendor=0x1002 device=0x1638 subvendor=0x17aa subdevice=0x3a5d
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'Cezanne'
    class      = display
    subclass   = VGA
```

In the drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c I could find:


```
/* Renoir */
        {0x1002, 0x15E7, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RENOIR|AMD_IS_APU},
        {0x1002, 0x1636, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RENOIR|AMD_IS_APU},
        {0x1002, 0x1638, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RENOIR|AMD_IS_APU},
        {0x1002, 0x164C, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RENOIR|AMD_IS_APU},
```

So, Cezanne is supported by the amdgpu driver inside of drm-devel-kmod, yet Xorg has problems switching mode on it.


----------



## checkpoint (Mar 17, 2022)

grahamperrin, I can do some more tests if necessary, just tell me what ever to try.


----------



## freezr (Mar 18, 2022)

Can I put here the Rclone issue with 13.1-Beta?









						Solved - [13.1-BETA] Rclone does not mount remote webdav folder
					

Hi folks,  I am not sure if this is a bug related with RCLONE or 13.1-BETA, but the former doesn't mount the webdav resouces locally anymore.  So far I uninstalled and reinstalled RCLONE and redone the procedure a bunch of time, but I could not mount this remote resource.  This command has...




					forums.freebsd.org
				




Since the version across 13.7 and 13.1-Beta is still the same I guess the culprit is the base system but I don't have the knowledge to understand why...


----------

