Re: i915drm broken in 9.1?

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Fri, 20 Dec 2024 11:58:44 -0500 (EST)
> From: Mouse <mouse%Rodents-Montreal.ORG@localhost>
> 
> >> At work, we just tried to build a 9.1 kernel with the i915drm line
> >> uncommented (we also left i915drmkms uncommented).  The kernel build
> >> exploded badly - it looks to me as though some file is expecting u8
> >> to be typedeffed but doesn't bother making sure it is.
> > Pre-KMS DRM (like i915drm) and DRM/KMS (like i915drmkms) are
> > definitely not expected to coexist in the same kernel.
> 
> Would the presence of i915drmkms cause i915drm to fail to _compile_?

Yes.  There are two DRM code bases defining various symbols like
drm_ioctl, drm_open, &c.; the i915drm driver uses the old legacy one
and the i915drmkms driver uses the new one.  These code bases cannot
coexist in the same kernel.

> > [i915drm] might work if you're lucky, once you disable all the
> > DRM/KMS drivers, but it has undoubtedly bitrotted.
> 
> > What's your motivation for using the i915drm driver?
> 
> An issue trying to make the product work on a particular monitor.  I'm
> relatively peripheral to that project; they appear to be Easter egging,
> trying various things in the hope that one of them will work.  The
> reason i915 support is a suspect is the boot-time message from
> i915_firmware_load_error_print about CONFIG_EXTRA_FIRMWARE or "your
> initrd/initramfs image"

This only affects runtime power management, which NetBSD's drivers
currently don't support anyway.  These firmware images are optional.

>                         (which really sounds to me like a Linuxism that
> never got fixed when it was imported to NetBSD - the code is also full
> of -ENOENT and -ENOMEM and the like, also a Linux signature).

I haven't adjusted all the error messages to avoid Linuxisms.  The
message is better in 10, though.  We have been pretty careful about
error codes to identify the transition between Linux and NetBSD style,
and to avoid nasty edge cases like Linux's ERESTARTSYS.

Have you tried NetBSD 10?  There have been a lot of changes and fixes
in 10 that have not gone into 9 and probably never will.  You can just
try booting a NetBSD 10 kernel once, no need to install the 10
userland.

There have also been a handful of fixes between 9.1 and 9.4, though
mainly memory leaks -- and one possible hang arising from taking an
adaptive lock with a spin lock held -- but it sounds like your issue
is probably not those.

Can you share any other symptoms like dmesg, maybe with boot -vx?