firefox problem after 13.3->13.4

T

Todd M

I upgraded from 13.3 to 13.4 today, but `firefox` was failing to load. I did a `pkg upgrade` etc., but no good.

The very undescriptive error is "exiting due to channel error".

I could get it to open from the command line, but not from my window menu, and then it was in safe mode. The only way I could get it to start up from the menu and outside safe mode was to uncheck:

"Use recommended performance settings" & under it "Use hardware acceleration"

in settings.

I am using `kldload amdgpu` for my graphics.

Firefox seems to work now without the recommended performance settings.

Thoughts?
 
I see from my notes that in the past I have had to disable "webgl" in firefox, but not lately/currently....
 
I had to disable hardware acceleration on my laptop to work around this problem. Something in the upgrade broke OpenGL hardware acceleration, and I haven't had time to troubleshoot drm-kmod.

Does it launch in safe mode?
Code: 
firefox --safe-mode
in a terminal.
 
Yes, it launched in safe mode, and I was able to disable the hardware acceleration and launch it normally.

What happens next?
 
  • Thanks
Reactions: JAW
When going 13.2->13.3, drm-kmod had to be built from ports, or amdgpu would not load. (In fact, it would kernel fault.) But that was not the case going to 13.4. Everything seems fine with the graphics, the minimal graphics that I use with X windows that is, except for the hardware acceleration in firefox.

As you say, perhaps this will be resolved when 13.3 is truly gone.... (I never seem to know the best time to do these updates either.)
 
Yes, I can confirm that rebuilding graphics/drm-kmod in ports fixed this issue with firefox.

Also, I didn't notice until later, but I was also having an issue with dpms (screen saver) not triggering. This was also fixed with the updated drm-kmod.

But I have a question about the ports procedure:

Doing a 'make build' (or 'make install' or 'make reinstall') did not rebuild anything, because drm-kmod is a meta-port. So I did a 'pkg autoremove' to remove all the kmod stuff after 'make uninstall' of the drm-kmod port, then a 'make reinstall' on the port & everything builds. What is the more correct/elegant approach?

And then speaking of elegance, which of these ports do I really need? I have the `amdgpu` to run xorg/firefox, and that is it... this is a tower computer.

Do I need only drm-510-kmod which is most of what the build does? There is clearly a lot installed that my system doesn't use.
 
Multimedia/gaming? Really? It took me 5 minutes just to find this thread.

This was an issue caused by FreeBSD version update. Period.
 
Upgraded packages earlier and hit the same issue as the OP, both www/firefox-esr and mail/thunderbird exited immediately with the "exiting due to channel error" message.

Tried running glxinfo from graphics/glx-utils, and it printed out the first line and then hung.

The issue has been resolved by rebuilding graphics/drm-510-kmod as mentioned above.

In the past when there has been a mismatch between the kernel and the drm module the system would fail to boot, but this time everything appeared ok until I tried to run an OpenGL accelerated app. :-/
 
JAW said:
In the past when there has been a mismatch between the kernel and the drm module the system would fail to boot, but this time everything appeared ok until I tried to run an OpenGL accelerated app. :-/
Click to expand...
Yeah, same here. I thought the system was slow. Now I know why. I'm lazy so I'll probably wait until 13.3 goes EOL and I can just use the package for drm-kmod.
 
Jose said:
Now I know why. I'm lazy so I'll probably wait until 13.3 goes EOL and I can just use the package for drm-kmod.
Click to expand...

I just use drm-515-kmod pkg for now (it happens to work on 14.2-R where drm-61-kmod pkg doesn't without ports compile)

For Firefox, I have gfx.webrender.all set (Intel DDX) which also makes it render all-black if OpenGL isn't available. Also serves as a quick check if OpenGL happens to randomly not be available :p

glxinfo | grep renderer is also a quick check; if it says LLVM/software, something likely isn't right.

Todd M said:
Do I need only drm-510-kmod which is most of what the build does? There is clearly a lot installed that my system doesn't use.
Click to expand...

With Intel UHD 630, all I need is drm-61-kmod (or 515) and gpu-firmware-intel-kmod-kabylake. I haven't tried anything else, but I'm thinking the same would work for AMD with a specific gpu-firmware-amd-kmod-* package also manually installed (kabylake isn't exactly obvious for a coffeelake GPU so you'll likely want to double-check what firmware you install or just install em all)
 
Jose said:
Yeah, same here. I thought the system was slow. Now I know why. I'm lazy so I'll probably wait until 13.3 goes EOL and I can just use the package for drm-kmod.
Click to expand...
When it came to firefox hardware acceleration, I was going to wait. That's not something that really affects me, although having a default setting cause an application not to launch is generally alarming....

However, when I noticed the dpms wasn't working, I didn't want to waste screen/power, so got it done.

I still feel like if this is going to be necessary on a regular basis, there should be a simpler procedure for doing the update from ports....
 
JAW said:
In the past when there has been a mismatch between the kernel and the drm module the system would fail to boot, but this time everything appeared ok until I tried to run an OpenGL accelerated app. :-/
Click to expand...
Yes, at first I thought things were fine. There's another reason I thought things were fine, though.

The release notes for 13.4 state very clearly in the section about updating "third party apps" that this step should be done only if freebsd-install says that it's necessary. freebsd-install didn't say anything, so I didn't do anything. I thought I was following the instructions.
 
I think you mean freebsd-update rather than freebsd-install?

This thing with the some-functionality-means-you-might-have-to-wait-until-minor-version-EOL catches out a lot of people. I don't use any of the graphics/desktop components, or Virtual Box (that seems to be the other main sticking point) so the upgrades are usually painless for my use cases.

But if you use anything that is linked to a specific kernel - then your life gets complicated if you use binary packages (which is advised.)

There seem to be various discussions and proposals, but if there was an easy answer then there would presumably have been a solution implemented by now.

It always pays to read all the release notes:

www.freebsd.org

FreeBSD 13.4-RELEASE Release Notes

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

Says:

Upgrading from Previous Releases of FreeBSD

Binary upgrades between RELEASE versions (and snapshots of the various security branches) are supported using the freebsd-update(8) utility. See the release-specific upgrade procedure, FreeBSD 13.4-RELEASE upgrade information, with more details in the FreeBSD handbook binary upgrade procedure. This will update unmodified userland utilities, as well as unmodified GENERIC kernels distributed as a part of an official FreeBSD release. The freebsd-update(8) utility requires that the host being upgraded have Internet connectivity.

(My emphasis)

If you go to the linked page:

docs.freebsd.org

Chapter 26. Updating and Upgrading FreeBSD

Information about how to keep a FreeBSD system up-to-date with freebsd-update or Git, how to rebuild and reinstall the entire base system, etc
docs.freebsd.org docs.freebsd.org

At the very start of that section it has a prominent warning; but it maybe needs some examples e.g. re. graphics drivers and Virtual Box.
 
richardtoohey2 said:
I think you mean freebsd-update rather than freebsd-install?
Click to expand...
Right, yes.

And I think there are basically two discussions going on. I see the other discussion, which is how to link these kernel modules into the main system in such a way that updates don't involve ports at all. But my question was more like, if we're going to be doing it this way, how about some clear instructions?

(I've been using FreeBSD as my main desktop since the 1990s, and this is the first period where I've had to do this kind of kernel mod business.... And the thing is, the older hardware that doesn't require these sorts of kernel mods isn't even current. So if you buy current hardware, you're forced down this road....)
 
Todd M said:
how about some clear instructions
Click to expand...
I'm just an outside observer so this is based on these forum threads I've read rather than any expert knowledge - isn't part of the problem that instructions will be hard to get right, because it really depends on what hardware you've got plus if you run Virtual Box, and so on.

For people who don't need to do anything, the instructions would just be extra noise (that wouldn't bother me personally.)

But if you have graphics hardware X, and you need to do XX, but if you have hardware Y you need to do YY, and if you run Virtual Box with extension Z then you need to do ZZ etc. etc.

Going to be a bit unwieldly, isn't it?

It does seem to be catching a lot of people out and it would be nice to have fewer forum threads about it but I can see it might not be that easy to fix or document.

But maybe a bit of extra text in freebsd-update to warn you. But if you do a certain invocation of freebsd-update it will be too late - the upgrades will be under way? Unless it printed the warning message and then gave you 10 seconds to abort.
 
How about something like:

cd ports/graphics/drm-kmod
make really-do-the-update

The idea of the drm-kmod port is already that it installs everything you might need. But it doesn't update unless you "trick" it, and that leads to questions about just what part needs to get updated anyway....
 
richardtoohey2 said:
There seem to be various discussions and proposals, but if there was an easy answer then there would presumably have been a solution implemented by now.
Click to expand...
Yes, this is a thorny problem that trips up a lot of users. It is not new. It may go away in 15:
SirDice

Post in thread 'Discussion: FreeBSD 14.2-RELEASE Available'

It would probably be a lot of wasted effort if the DRM drivers get included in the base with 15. Time that could be better spent on making other improvements.

Lots of good info in that thread.
 
Todd M said:
Yes, I can confirm that rebuilding graphics/drm-kmod in ports fixed this issue with firefox.
Click to expand...
drm-510-kmodis the earliest linux release after drm-kmod. /usr/src/sys was intentionally skipped by me during my initial install, so the first rebuild task is to install it after the fact. For future benefit of people struggling with a similar situation, here's my drm-510-kmod rebuild procedure to obtain newer i915 modules:

#fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/13.4-RELEASE/src.txz
# tar -xvf src.txz -C /
# pkg delete drm-kmod
# pkg delete drm-510-kmod
# cd /usr/ports/
# make search name=drm-510-kmod
# cd /usr/ports/graphics/drm-510-kmod
# make config-recursive install clean

Thank you Espionage724 for your tip about drm-515-kmod.
 
You must log in or register to reply here.
Back
Top