13.2 Stable kld load system panic ?.

T

Tridac

Long term FreeBSD user, embedded systems work. Most recent server, a Sun X3-2, a single i5
machine, running for over year with 12.3 release. New server to be a 2u DL380 G8, to gain more
pcie slots.

Have a generic rc.conf that is edited, ip and hostname etc, on each new machine. More or less
standardised on amd V3900 on all machines. Don't need fancy graphics, just reasonable 2d
desktop performance and the v3900 is cheap and good on power at around 10 watts.

All the usual packages installed: xorg, xfce4, slim, drm-kmod. Also installed the old xf86-video-ati,
but makes no difference.

On reboot, system panic at the kld load stage in rc.conf. Commented out, everything normal,
but a kldload from the command line also panics. Tried various things.

* Package update, but tells me everything is up to date

* Deinstall amd packages and reinstall, even tried rebuilding from ports.

* All the amd files do seem to be in place in /usr/boot/modules

Include a screenshot of the panic. Takes a power cycle to recover.

Running out of ideas. All usually works out of the box with no issues, so what am I missing here ?...


crash-small.jpg
 

Attachments

  • crash-small.jpg
    crash-small.jpg
    1,023.9 KB · Views: 43
Don't know why this was moved to desktop, as it's obviously a kernel related issue. Anyway, tried a few more things, but same result, so backtracked and installed 12.4. Identical setup, packages etc. Reboot and the system correctly loads the graphics .ko image, sets screen resolution, as expected. That's kernel side ok, but X startup fails and needed an X -configure to create an xorg.conf. Istr, had to do that on the original 12 setup, so not a problem.

So why the issue with 13.2 stable ?. Obviously a bug, but not part of the dev infrastructure here, so hopefully someone else will pick this up and find a fix. Makes 13.2 unusable here...
 
Tridac said:
Don't know why this was moved to desktop, as it's obviously a kernel related issue
Click to expand...
It is related to the graphics/drm-kmod kernel module. It's only used for display servers, so it's more at place here.

I suggest building the appropriate graphics/gpu-firmware-kmod slave from ports as it's quite possible your -STABLE version isn't the exact same -STABLE version as the packages in the repositories are built with. Kernel modules like these are quite finicky when it comes to exact kernel versions. Best to build these from ports on -STABLE.

Note that graphics/gpu-firmware-kmod is a so-called "meta port", it doesn't install anything of itself, it merely depends on a whole bunch of graphics/gpu-firmware-*-kmod ports/packages. Uninstalling and rebuilding only graphics/gpu-firmware-kmod from ports is mostly a no-op, it doesn't do anything.

I suggest running pkg delete drm-kmod gpu-firmware-kmod and running pkg autoremove to remove all the parts, then build graphics/drm-kmod from ports.
 
SirDice said:
It is related to the graphics/drm-kmod kernel module. It's only used for display servers, so it's more at place here.

I suggest building the appropriate graphics/gpu-firmware-kmod slave from ports as it's quite possible your -STABLE version isn't the exact same -STABLE version as the packages in the repositories are built with. Kernel modules like these are quite finicky when it comes to exact kernel versions. Best to build these from ports on -STABLE.

Note that graphics/gpu-firmware-kmod is a so-called "meta port", it doesn't install anything of itself, it merely depends on a whole bunch of graphics/gpu-firmware-*-kmod ports/packages. Uninstalling and rebuilding only graphics/gpu-firmware-kmod from ports is mostly a no-op, it doesn't do anything.

I suggest running pkg delete drm-kmod gpu-firmware-kmod and running pkg autoremove to remove all the parts, then build graphics/drm-kmod from ports.
Click to expand...
SirDice said:
It is related to the graphics/drm-kmod kernel module. It's only used for display servers, so it's more at place here.

I suggest building the appropriate graphics/gpu-firmware-kmod slave from ports as it's quite possible your -STABLE version isn't the exact same -STABLE version as the packages in the repositories are built with. Kernel modules like these are quite finicky when it comes to exact kernel versions. Best to build these from ports on -STABLE.

Note that graphics/gpu-firmware-kmod is a so-called "meta port", it doesn't install anything of itself, it merely depends on a whole bunch of graphics/gpu-firmware-*-kmod ports/packages. Uninstalling and rebuilding only graphics/gpu-firmware-kmod from ports is mostly a no-op, it doesn't do anything.

I suggest running pkg delete drm-kmod gpu-firmware-kmod and running pkg autoremove to remove all the parts, then build graphics/drm-kmod from ports.
Click to expand...
Thanks for detailed info. Will leave the 12 install initially, as that was what was runnng on the old machine, and have a load of packages and setup transferred and installed now. Have a couple more drives, which I wil try again with 13.2 a bit later . I know 12 is old, but has been running without issue for over a year now, dual use as an nfs server and for embedded system development. Here, once an install is stable, very rarely change anything, other than out of need, but 12 looks like being eol soon. Reason for the -stable install, was that it won't be eol until 2027, afaics...
 
Tridac said:
… 13.2 stable …
Click to expand...

Which version, exactly?

freebsd-version -kru ; uname -aKU

Tridac said:
… obviously a kernel related issue. …
Click to expand...

Kernel panics are always kernel in Bugzilla for FreeBSD, not necessarily so here.

Tridac said:
… Reason for the -stable install, was that it won't be eol until 2027, afaics...
Click to expand...

You'll get the same five-year support with RELEASE.

273795 – Correct the expected end of life for stable/13; add stable/14 and 14.0-RELEASE

bugs.freebsd.org bugs.freebsd.org
 
One hint If you must run stable: add a PORTS_MODULES+=graphics/drm-XXX-kmod to /etc/src.conf to always build & install the relevant drm-firmware-XXX-port along with kernel build & install. Replace XXX with the drm version port for your FreeBSD version. I think you may still need to periodically clear out the port work files from time to time.
 
The way ports are built , if a port is updated, it doesn't rebuild. There are dependencies (on the kernel itself, which is why you have to build it with the kernel) but they don't fit in the ports system model. So if the port is updated due to some kernel API changing, it won't rebuild (since /usr/obj/.../sys/GENERIC/usr/ports/graphics/drm-XXX-kmod/work dir will have a .build_done.drm-XXX-kmod._usr_local file.

Edit: this might not be true. I need to look deeper into why I had to do a rebuild a few days ago.
 
Tridac said:
Thanks for detailed info. Will leave the 12 install initially, as that was what was runnng on the old machine, and have a load of packages and setup transferred and installed now. Have a couple more drives, which I wil try again with 13.2 a bit later . I know 12 is old, but has been running without issue for over a year now, dual use as an nfs server and for embedded system development. Here, once an install is stable, very rarely change anything, other than out of need, but 12 looks like being eol soon. Reason for the -stable install, was that it won't be eol until 2027, afaics...
Click to expand...
 
Had another go at this yesterday. Different drive pair for a zfs root. Usual install including the ports collection and sources. Installed pkg, xorg, xfce and slim. Then, in case others find it useful:
  • cd /usr/ports/graphics/drm-kmod
  • make install
  • in /etc/rc. conf:
  • kld_list="/boot/modules/radeonkms.ko"
    dbus_enable="YES"
    hald_enable="YES"
    slim_enable="YES"
  • Copy .xinitrc to user home directory from old machine
  • run "X -configure" and copy xorg.conf.new to /etc/X11/xorg.conf
The copy of .xinitrc is precautionary, as installs of some older xfce versions need this to start the session, others don't. The xfce install may have put that somewhere, but no idea where. The X -configure is often needed for install on a server class machine with onboard graphics console and an added graphics card. X won' t always pick the right hardware card, so did a pciconf -lv to find the card bus id, then made sure the xorg.conf "Device" BusId points to the added graphics card, not the onboard console. Such as:

Identifier "Card0"
Driver "modesetting"
BusID "PCI:7:0:1" (BusID for a DL380 G8, x16 pcie riser slot)

Reboot and we get a slim login screen, then an xfce desktop. Spent hours trying to fix this, but a useful lesson learned about -STABLE versions. Thanks again for the help with this...
 
Thanks.

If you find the origin of this:

Tridac said:
hald_enable="YES"
Click to expand...

– and if the origin is editable, please request an edit.

old.reddit.com

2001 is a distant memory. HAL is retired.

If you still have HAL – and if your system and packages are up-to-date – maybe it's time: `sudo pkg autoremove` – and be prepared to edit...
old.reddit.com old.reddit.com


Comparably archaic:

kld_list="/boot/modules/radeonkms.ko"
Click to expand...

Instead, for modern systems:

kld_list="radeonkms"
 
grahamperrin said:
Which version, exactly?

freebsd-version -kru ; uname -aKU



Kernel panics are always kernel in Bugzilla for FreeBSD, not necessarily so here.



You'll get the same five-year support with RELEASE.

273795 – Correct the expected end of life for stable/13; add stable/14 and 14.0-RELEASE

bugs.freebsd.org bugs.freebsd.org
Click to expand...
Re: Your question:

FreeBSD darkstar 13.2-STABLE FreeBSD 13.2-STABLE stable/13-n256575-6c4855c18eed GENERIC amd64 1302508 1302508

Thing is, i've never had any serious issue with FreeBSD of any version and once a machine is setup with all the usual packages and tweaks, tend to leave it alone until a hardware upgrade, which can be up to a couple of years. I know it's frowned upon, but stability is key and the machine is a tool for software dev and tech related stuff, on a well insulated subnet, so really don't need to be at the bleeding edge.
 
Potentially ?. I guess I will be able to upgrade that, but for now, need to get a stake in the ground so I can replace the old 12.4 machine, which has been rock solid, but every so often, a zpool status will tell me a disk in the zroot or raidz data pool is faulty. Has locked up the machine as well. A zpool clear and reboot fixes that with no errors, but it's a warning and suggests an intermittent hardware fault. What is the point of STABLE, what appears to be an esr release, if it's something different than what it appears to be ?. Not a criticism, but see my point ?...
 
Stable gets cherry picked changes from current so things are much less likely to break but they can still break. My rule of thumb is to use stable only when it offers something that I really want but it is not in the latest release. I use a local script to read/review git log messages (from the stable or current version I am running in some VM). I avoid updating if there are lots of changes occurring.
 
Thanks, understood. Had a look at the stable mailng list, which does show a few issues with zfs, but with one of them, it looked like they were thrashing the system to bits, more like a stress test. FreeBSD really is solid, some issues always to be expected, but the system load and / or apps are not demanding here. Idle much of the time.

As for stability, run a public ntp server, FreeBSD 12, text only install, on a tiny pc with small ssd. It's on a ups, but this is what is reported:

root@ntp-host:~ # uname -a
FreeBSD ntp-host 12.0-RELEASE-p6 FreeBSD 12.0-RELEASE-p6 GENERIC amd64
root@ntp-host:~ # uptime
11:16PM up 802 days, 8:44, 1 user, load averages: 0.13, 0.21, 0.22

Over two years uptime !!!...
 
Tridac said:
STABLE, what appears to be an esr release
Click to expand...

The word and the ways in which it's presented are sources of confusion.

If you pick a point in time on the stable/13 branch, think of it as a lucky dip with a fair chance of winning.

If you pick a RELEASE point in time, you should:
  1. think of it as a very carefully engineered product
  2. use freebsd-update(8) to gain products of equal care.
Either way: if you refrain from updating and then encounter a problem, the solution may involve or require an update.
 
grahamperrin said:
lucky dip
Click to expand...

Matches for revert on stable/13: <https://cgit.freebsd.org/src/log/?h=stable/13&qt=grep&q=revert>.

Tridac said:
stake in the ground
Click to expand...

If your make next weekend's stable/13 your stake: it might hold firm, or there might arise a need to pull up pegs and re-pitch the tent. Luck.

If you make next week's releng/14.0 your stake: there's far greater certainty that it will hold firm.

(14.0-RELEASE, press release expected on Tuesday, is the result of very careful release engineering (releng).)

stable/13:
Release engineering:
 
You must log in or register to reply here.
Back
Top