Bug 195165

Summary: Kernel with drm panics, when xorg tries to load new drm-modules
Product: Base System Reporter: Mikhail T. <freebsd-2024>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Some People CC: emaste, rea, zeising
Priority: ---    
Version: 10.1-RELEASE   
Hardware: amd64   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193367
Attachments:
Description Flags
core.txt file from the panic none

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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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