FreeBSD 13.0 freezes

dacrackerx64

dacrackerx64

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:
gist.github.com

iichid.conf

GitHub Gist: instantly share code, notes, and snippets.
gist.github.com 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?
 
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.
 
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.
 
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.
 
dacrackerx64 said:
The suggested (sad) workaround seems to work so far:
hint.hwpstate_intel.0.disabled="1"
Click to expand...
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).
 
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).
Click to expand...
Really? I could swear that my laptop drains more battery now. Though it could be my imagination or something unrelated. Thanks for the information!
 
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!
Click to expand...

Not your imagination. I'm burning through battery like crazy suddenly -- independent of the issue above.
 
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.
Click to expand...

Yeah, I'm going to reinstall FreeBSD 12.2. again. It works flawlessly while 13.0 introduce all kinds of
weird issues.
 
dacrackerx64 said:
Yeah, I'm going to reinstall FreeBSD 12.2. again. It works flawlessly while 13.0 introduce all kinds of weird issues.
Click to expand...
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".
 
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".
Click to expand...
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 :)
 
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.
 
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.
Click to expand...
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).
 
drhowarddrfine said:
It was always, always something I did wrong.
Click to expand...
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.
 
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).
Click to expand...
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!
 
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:
Code: 
# 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 ;)
 
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:
Code: 
# 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 ;)
Click to expand...
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?
 
dacrackerx64 said:
One question though, it looks like you install your FreeBSD 13.0 system under the tmp folder.
Click to expand...
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?
Click to expand...
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.
 
? 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.
 
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.
 
You must log in or register to reply here.
Back
Top