Bug 195165 - Kernel with drm panics, when xorg tries to load new drm-modules
Summary: Kernel with drm panics, when xorg tries to load new drm-modules
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.1-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-19 13:49 UTC by Mikhail T.
Modified: 2019-02-01 12:48 UTC (History)
3 users (show)

See Also:


Attachments
core.txt file from the panic (95.23 KB, text/plain)
2014-11-19 13:49 UTC, Mikhail T.
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail T. 2014-11-19 13:49:54 UTC
Created attachment 149586 [details]
core.txt file from the panic

I had a fairly solid system running 9.x and decided to upgrade to 10.1.

The rebuild went smoothly, the same kernel-config was built cleanly. I rebuilt all of the X11-ports and tried starting xdm as usual.

The machine rebooted after a panic (see attachment for more details):

panic: make_dev_credv: bad si_name (error=17, si_name=dri/card0)

Apparently, this is problem has been known to the x11@ folks for a while -- when the new X11-drivers try to load DRM2, the kernels with the "old" DRM in them will panic:

http://lists.freebsd.org/pipermail/freebsd-stable/2014-September/079868.html

While the recommended work-around -- remove "device drm" and "device radeondrm" from kernel config -- helped me get going, it should not be necessary:

 1. There must be no panic
 2. If DRM2 can not coexist with DRM, it must check for the condition and report
    an error.
 3. If DRM2 is a replacement for DRM, why not remove the old "device" altogether?

No doubt, the x11@ group is aware of the problem. This ticket is intended to help them track it.
Comment 1 Eygene Ryabinkin freebsd_committer 2014-11-28 12:46:16 UTC
Mikhail, good day.

I had just patched DRM w.r.t. off-by-one access that will be provoked by the userland that is KMS-enabled on the kernel that doesn't support KMS.

The patch is now only in -CURRENT, but you can try to apply
  http://codelabs.ru/fbsd/patches/drm2/fix-drm_drv-off-by-one.diff
to your 10.x sources and rebuild kernel: it may eliminate the panic.

Could you, please, test?
Comment 2 Eygene Ryabinkin freebsd_committer 2014-11-28 12:49:19 UTC
Also, a backtrace from the panic (kgdb /boot/$DRM-ENABLED-KERNEL/kernel.debug /var/crash/vmcore.1 and "bt" from inside kgdb) will be great here.
Comment 3 Mikhail T. 2014-11-29 05:58:08 UTC
Thanks, Eugene, for the prompt response, but I've already figured, that I am much happier with the xf86-video-ati-ums driver for my card -- it has no GL hardware and the newest drivers were outrageously slow on it, even though DRM worked.

I've rebuilt my kernel here a number of times since encountering that panic and can no longer obtain the backtrace...
Comment 4 Niclas Zeising freebsd_committer 2019-01-30 10:00:00 UTC
Is this still an issue with the updated DRM drivers and a more recent version of FreeBSD?
Comment 5 Niclas Zeising freebsd_committer 2019-02-01 12:48:03 UTC
Looking at your comments, it seems this is no longer an issue, so I'm closing this.  If it's an issue, please re-open this bug or create a new one.
Regards
Niclas