# FreeBSD 13.0 freezes



## dacrackerx64 (Apr 14, 2021)

My laptop (Lenovo Thinkpad X1 Carbon Gen7) ran FreeBSD 12.2 without issues,
but as soon as I upgraded to 13.0 started to get random freezes. The entire
system becomes unresponsive, the fans run on max speed and the hardware
becomes very hot. 

My issue is probably the same as mentioned here:








						iichid.conf
					

GitHub Gist: instantly share code, notes, and snippets.




					gist.github.com
				




The suggested (sad) workaround seems to work so far:
`hint.hwpstate_intel.0.disabled="1"`

Does anyone know if this issue has been reported? Is anyone
working on it?


----------



## eternal_noob (Apr 14, 2021)

I experienced random freezes with the intel driver too. I solved it by deinstalling it and use modesetting instead.
So try removing the `xf86-video-intel` driver and any xorg config file refencing it in order to use the modesetting driver.


----------



## dacrackerx64 (Apr 14, 2021)

Thank you for the suggestion, though I don't think this is the problem in my
case since I experience the issue even when I don't run X11. But I'll try
removing the `xf86-video-intel` driver anyway.


----------



## aragats (Apr 14, 2021)

dacrackerx64 said:


> The suggested (sad) workaround seems to work so far:
> `hint.hwpstate_intel.0.disabled="1"`
> 
> Does anyone know if this issue has been reported?


My X1 Gen1 won't even boot without that. This is a new driver in 13.0. I filed a bug report PR 254915.


----------



## dacrackerx64 (Apr 14, 2021)

I see, thank you for the info! I guess we just have to wait and see if there's anyone
who is willing to fix it. I might give it a go if I have the time,  though it's tempting
to just re-install 12.2 as it works really well with my hardware.


----------



## zirias@ (Apr 14, 2021)

dacrackerx64 said:


> The suggested (sad) workaround seems to work so far:
> `hint.hwpstate_intel.0.disabled="1"`


If that's indeed the issue, then, yes, sad you can't use that nifty new feature  But at least, you won't lose anything compared to 12. This driver is new in 13 (and, if working, will eliminate the need to run powerd(8), as speed shifting is then controlled by the hardware itself).


----------



## dacrackerx64 (Apr 14, 2021)

Zirias said:


> If that's indeed the issue, then, yes, sad you can't use that nifty new feature  But at least, you won't lose anything compared to 12. This driver is new in 13 (and, if working, will eliminate the need to run powerd(8), as speed shifting is then controlled by the hardware itself).


Really? I could swear that my laptop drains more battery now. Though it could be my imagination or something unrelated. Thanks for the information!


----------



## phalange (Apr 17, 2021)

I'm getting the freeze with hyperactive fan too. For me I've found that closing the lid is one cause. This is a t460s, and lid close used to be trigger S3 sleep just fine.



dacrackerx64 said:


> Really? I could swear that my laptop drains more battery now. Though it could be my imagination or something unrelated. Thanks for the information!



Not your imagination. I'm burning through battery like crazy suddenly -- independent of the issue above.


----------



## dacrackerx64 (Apr 17, 2021)

phalange said:


> I'm getting the freeze with hyperactive fan too. For me I've found that closing the lid is one cause. This is a t460s, and lid close used to be trigger S3 sleep just fine.
> 
> 
> 
> Not your imagination. I'm burning through battery like crazy suddenly -- independent of the issue above.



Yeah, I'm going to reinstall FreeBSD 12.2. again. It works flawlessly while 13.0 introduce all kinds of
weird issues.


----------



## zirias@ (Apr 17, 2021)

dacrackerx64 said:


> Yeah, I'm going to reinstall FreeBSD 12.2. again. It works flawlessly while 13.0 introduce all kinds of weird issues.


For me, 13.0 works great so far, although I have my share of "weird issues" (and reported some of them), but I found workarounds for all of them, and the performance boost especially with virtual networking (with epairs and bridges) is a big plus for me 

All I can tell you is, this `hwpstate_intel` driver _is_ new on 13. If you have more battery drain, well, that's not nice, but the reason must be a different one.

But then, there's also a reason some people prefer to wait for a "dot 1" release before doing a major upgrade. _Some_ issues won't be identified before a new major release is actually in production, and chances are good most of them are identified and fixed for ".1".


----------



## dacrackerx64 (Apr 17, 2021)

Zirias said:


> For me, 13.0 works great so far, although I have my share of "weird issues" (and reported some of them), but I found workarounds for all of them, and the performance boost especially with virtual networking (with epairs and bridges) is a big plus for me
> 
> All I can tell you is, this `hwpstate_intel` driver _is_ new on 13. If you have more battery drain, well, that's not nice, but the reason must be a different one.
> 
> But then, there's also a reason some people prefer to wait for a "dot 1" release before doing a major upgrade. _Some_ issues won't be identified before a new major release is actually in production, and chances are good most of them are identified and fixed for ".1".


I'm sure 13.0 works great for most users. In my particular case it just feels like the power drain issues are too severe
for me to continue using 13.0 at the moment. I have no doubt that 13.x will be even better for me than 12.2 in a 
point release or two. But next time I upgrade I'll do some testing with boot environments first


----------



## zirias@ (Apr 17, 2021)

dacrackerx64 said:


> But next time I upgrade I'll do some testing with boot environments first


When using ZFS, there's really no reason _not_ to do that. I still have my 12.2 BEs here, but will probably delete them soon (and then upgrade the pool).


----------



## drhowarddrfine (Apr 17, 2021)

In the past, I always found that the reason my upgrades had problems were because I did something wrong with the original configuration or install that didn't bite me till the upgrade. If it was an application not working, it's cause I didn't upgrade some dependency. Or I upgraded out of order. It was always, always something I did wrong.


----------



## dacrackerx64 (Apr 18, 2021)

drhowarddrfine said:


> In the past, I always found that the reason my upgrades had problems were because I did something wrong with the original configuration or install that didn't bite me till the upgrade. If it was an application not working, it's cause I didn't upgrade some dependency. Or I upgraded out of order. It was always, always something I did wrong.


I'm new to FreeBSD so this might be the case. I have made quite a few settings related to power management and 
they might have unintended consequences in FreeBSD 13.0. I'll look into this the next time I'll attempt an 
upgrade (probably when 13.1 is out).


----------



## zirias@ (Apr 18, 2021)

drhowarddrfine said:


> It was always, always something I did wrong.


This is probably often the case, but still not a general rule. Just a quick selection of issues I ran into upgrading to 13:

with many epair(4)s and several bridge(4)s connecting them, I had one consistently missing from a bridge. Reordering /etc/rc.conf helped here, although this should never help, but the scripts for bringing up networking are really black magic 
my routing/firewalling VM didn't work at all, all vtnet(4)s were missing from bridge(4)s. The reason and my current workaround are described in PR 254343.
two NFS shares didn't work any more, it turned out sharing now fails for a dataset mounted with nullfs(5), this seems to be a regression, see PR 254282.
This list is not exhaustive, and the two bugs I reported are still present in -RELEASE. They're no deal-breakers because workarounds exist.


----------



## dacrackerx64 (Apr 18, 2021)

Zirias said:


> When using ZFS, there's really no reason _not_ to do that. I still have my 12.2 BEs here, but will probably delete them soon (and then upgrade the pool).


Yeah, I thought that I would figure it out after upgrading to 13.0. I am a little bit unsure about how to best handle boot environments. If you could point me at any good documentation  that would be highly appreciated. 

So far I’ve tried Vermaden’s beadm a little bit. Seems really cool and useful!


----------



## zirias@ (Apr 18, 2021)

I decided to go straight with bectl(8) because it's in base. But beadm(1) should work just as well. The key "trick" is to install into a boot environment that's currently not active. As I always install from source, that's what I did (in a nutshell), assuming `make buildworld` and `make buildkernel` are already done:

```
# bectl create 13.0
# bectl mount 13.0
Successfully mounted 13.0 at /tmp/be_mount.ivqL
# cd /usr/src
# make DESTDIR=/tmp/be_mount.ivqL installkernel
# make DESTDIR=/tmp/be_mount.ivqL installworld
# make DESTDIR=/tmp/be_mount.ivqL BATCH_DELETE_OLD_FILES=yes delete-old
# bectl umount 13.0
# rmdir /tmp/be_mount.ivqL
# bectl activate 13.0
# shutdown -r now
```
Now, when doing a binary upgrade with freebsd-update(8), I've seen howtos using a chroot(8) on the mountpoint for the boot environment to do that. I'm not sure this is really necessary because freebsd-update(8) has a flag `-b` that I think should serve the same purpose as giving `DESTDIR` when installing from source. But maybe someone actually using that might add their experience


----------



## dacrackerx64 (Apr 19, 2021)

Zirias said:


> I decided to go straight with bectl(8) because it's in base. But beadm(1) should work just as well. The key "trick" is to install into a boot environment that's currently not active. As I always install from source, that's what I did (in a nutshell), assuming `make buildworld` and `make buildkernel` are already done:
> 
> ```
> # bectl create 13.0
> ...


I really have to learn how to use boot environments properly, looks really cool and useful! One question though, it looks like you install your
FreeBSD 13.0 system under the tmp folder. How do you move your 13.0 base system to the root of the file hierarchy once you are sure that
you wish to go with 13.0? I suppose all ports have to be re-installed?


----------



## zirias@ (Apr 19, 2021)

dacrackerx64 said:


> One question though, it looks like you install your FreeBSD 13.0 system under the tmp folder.


`bectl mount` just creates a temporary mountpoint there.


dacrackerx64 said:


> How do you move your 13.0 base system to the root of the file hierarchy once you are sure that you wish to go with 13.0?


Not at all. In a nutshell, ZFS boot environments are implemented using different ZFS datasets that can all be mounted as /. In the default layout, you find them in zroot/ROOT/. Which one is active (the one the bootloader will actually set as root filesystem) can be selected by the `bootfs` property on the pool. `bectl activate` sets it.


----------



## grahamperrin@ (Apr 21, 2021)

dacrackerx64 said:


> … fans run on max speed and the hardware becomes very hot. …



A long shot, try *powerd++* sysutils/powerdxx – powerdxx(8) – and: 

`sysrc powerd_enable="NO" && sysrc powerdxx_enable="YES"`

– then restart, and run off the battery for as long as you can.


----------



## dacrackerx64 (Apr 22, 2021)

grahamperrin said:


> A long shot, try *powerd++* sysutils/powerdxx – powerdxx(8) – and:
> 
> `sysrc powerd_enable="NO" && sysrc powerdxx_enable="YES"`
> 
> – then restart, and run off the battery for as long as you can.


I’m already a powerdxx user and it works very well on 12.2. Sadly I got
the problem with powerdxx enabled on 13.0. Thank you for the suggestion!


----------



## grahamperrin@ (Apr 22, 2021)

dacrackerx64 said:


> … I got the problem with powerdxx enabled on 13.0. …



Have you tried powerd(8) instead? 

If I understand correctly, powerdxx(8) defaults might not suit all use cases … something like that. (For myself, I reverted to powerd(8).)


----------



## scottro (Apr 22, 2021)

For using beadm or bectl, I've found the Michael Lucas post very helpful. 


			FreeBSD and beadm – Michael W Lucas
		


Even without mounting, in a nutshell, you create a new boot environment, switch to it, and do the upgrade. If it breaks, you can go back to the previous boot environment.


----------



## grahamperrin@ (Apr 22, 2021)

to habitual use of boot environments – not only for system upgrades, also for package updates.

For anyone who's not already aware: there's sometimes encouragement to demonstrate use of bectl(8) in guides, because it's integral to FreeBSD.


----------



## scottro (Apr 22, 2021)

For awhile, there was a problem where bectl was sometimes failing to destroy no longer needed boot environments. I'm too lazy to find the thread, I was on it and vermaden added their wisdom. 

It was filed as a bug, marked fixed, but still occurred. Note that this was NOT a common thing. It just happened on rare occasions, and at those times, both for me, and others hit by it, using beadm fixed the issue.

I've gone back to using bectrl and haven't had that problem in awhile. Its use with boot environments is the same as beadm's, as explained by the Michael Lucas article.  I also agree with grahamperrin about using it with package upgrades, though, to be honest, I only do that when there are a lot of upgrades at a time, or it's some essential thing for my workflow, e.g., the nvidia driver.  

To sum up, yes, bectl is part of the base, but it has had minor problems in the past, which, as far as my experience, haven't occurred recently.


----------



## grahamperrin@ (Apr 22, 2021)

scottro said:


> … bectl was sometimes failing to destroy no longer needed boot environments …



If I understand correctly, this is by design for some situations … for no longer needed _snapshots_.

I previously misunderstood the manual page. After (hopefully) learning: <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254428#c2>. tl;dr when I most recently encountered the warning, I knew to use something other than bectl to (if necessary) destroy the remaining snapshot(s); and I recall thinking that the snapshots might have been a product of beadm.

Notable bugs include:

239702 – sysutils/openzfs bectl activate … cannot promote … not a cloned filesystem … did not successfully activate boot environment, to which I have paid no attention in a long time
254441 – bectl should prevent creating BEs with unbootable names
*Postscript* (afterthought): long ago I did find that some _boot environments_ were indestructible. It puzzled me but not enough to raise a bug, I might have found the BEs indestructible with both beadm *and* bectl. Whatever the problem was – maybe (?) the result of me creating a boot environment whilst _not_ running the 'most recent' environment – eventually it disappeared. I found it possible to destroy the environments.


----------



## sidetone (Apr 24, 2021)

I got freezes on FreeBSD 13.0 too. Then, I simplified my settings, and reverted to the kernel that came with the install for it to work for now.

On my running system, this shows up:
`dmesg | grep -i acpi | egrep -i 'warning|error'`

```
Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x0000000000000000/0x1 (20201113/tbfadt-796)
Firmware Error (ACPI): Could not resolve symbol [\134_SB.ALIB], AE_NOT_FOUND (20201113/psargs-503)
ACPI Error: Aborting method \134_SB.PCI0.VGA.ATC0 due to previous error (AE_NOT_FOUND) (20201113/psparse-689)
ACPI Error: Aborting method \134_SB.PCI0.VGA.ATCS due to previous error (AE_NOT_FOUND) (20201113/psparse-689)
```
These error messages or similar ones also showed up before more fatal error warnings and system freeze.

It's likely the power settings or the video driver causing overheating or another fatal issue. My CPU indication was a little hot when looking at BIOS.

* Edit: this is a desktop with an AMD CPU/GPU.


----------



## driesm (Apr 24, 2021)

dacrackerx64 said:


> Does anyone know if this issue has been reported? Is anyone
> working on it?


Just FYI but this problem seems like some specific race condition with P-states and Lenovo systems. (and I also think only U series processors).






						253288 – hwpstate_intel: modern ThinkPads wedge under any kind of load or during boot
					






					bugs.freebsd.org
				








						248659 – Specific intel chips lock up with P-states active
					






					bugs.freebsd.org
				




The more people subscribe to the bug(s), the more attention they well get .


----------



## dacrackerx64 (Apr 25, 2021)

Duffyx said:


> Just FYI but this problem seems like some specific race condition with P-states and Lenovo systems. (and I also think only U series processors.
> 
> 
> 
> ...


I'll subscribe to both of these bugs, thank you very much for this information!


----------

