From nobody Fri Dec 31 22:01:57 2021 X-Original-To: x11@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B9814192A418 for ; Fri, 31 Dec 2021 22:01:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQfHn45jyz4dRb for ; Fri, 31 Dec 2021 22:01:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 6881D133F6 for ; Fri, 31 Dec 2021 22:01:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 1BVM1vDZ078800 for ; Fri, 31 Dec 2021 22:01:57 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1BVM1vDA078789 for x11@FreeBSD.org; Fri, 31 Dec 2021 22:01:57 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 237544] graphics/drm-fbsd12.0-kmod: panic on 12-STABLE with Radeon HD 7450 (but not with drm-fbsd11.2-kmod) Date: Fri, 31 Dec 2021 22:01:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: noisetube@gmail.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: x11@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: X11 List-Archive: https://lists.freebsd.org/archives/freebsd-x11 List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-x11@freebsd.org X-BeenThere: freebsd-x11@freebsd.org MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640988117; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cKChbVDusyZ/pqqrDWfbF9UuUueqF3gCgECQ+p+C3GM=; b=GDdjSTQmV/DSRYEvb6ukiCZZTJYHB/Re+huXZQ5Sg4/NAMQU2xC8y1XU6gMAqHtkh8f4oF GFChlLEMO/wSehKKS46WQznOM8MTKuENVH+48UovKAfjp2CLtdr9l+72qSWHlYQDLSbmXR +AElyNJJdKIT8lpdnJ0UIv85A0HiKLMiaGX2BbIkKVRsmoX4iYovkRGzzlLOwokNhX/Blt I+Ml89sNGG2Kaik2wJ0Jh9p7zLR37ZxziV6pN2bwkqp9YP8VfpwCsma0pFUf/mAoflZglo Hqozt9A0DrOew7G7fLnYWZAQhFOYEBypukXywZJ6lXdRjgBjGaFIy82yDkv5PQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640988117; a=rsa-sha256; cv=none; b=I2ku5kyIAZGaiJ5mwqMv1IWCxh8eI/amQFr5vVg4fuSxCnQBJCeR6TQOjAdxcxTZHJ/or2 Bvt6jLMIere8kdioCBHgCGLPwVZWEmRzMNfDvUhUI1ZNh0pqXYkk4PJmJ5llynJ+jFomrE Y/VBIb3Yd4RqCwWk9dqmUW6AtO4eaBUX3ypDTVmcwjng8utkTjHLjiJdksGwPQCNaFt+Gr J5xBuRqDz1qgHcCE2XjBgCEceEhiQLqoZMphUlrupMtWBI3DM+x1x07+hnYd6e1X1CGNYo fOUTpehc3fZVZK/qjp4n7X2lt0CnekzzRD8+vE9JYnYL7G+mu6EC0mIhr86xqg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237544 --- Comment #13 from Bill Paul --- > But radeonkms still panics. As you said it's really old hardware at this = point[...] I really don't think it's fair to call it really old hardware. It may not be current hardware, but it's still perfectly serviceable, and I suspect it wo= uld work fine with the same driver code in Linux. I think the real problem here= is a bug in the Linux compatibility code, and the fact that it only happens to trip with Radeon hardware is just dumb luck. To be fair, the reason I have this hardware in the first place is that I've been salvaging it from the e-waste bin at work. Bear in mind, sometimes stu= ff just ends up in there because it was used for one project and then forgotte= n. (I have a 32-core, 32GB system at work because of this.) As a result, I have several Radeon graphics cards, and recently I also ended up with a laptop w= ith built-in R600/SUMO graphics as well. The laptop works great with FreeBSD 12= .3 on it, except for the stupid panic in the radeonkms driver. Now that I seem= to have worked around that too, I have no complaints. Anyway, if I understand you correctly, it sounds like the problem is still present in FreeBSD 14-CURRENT. From what I can tell, the major difference f= rom the older drm-fbsd11.2-kmod code and the later code is that the dmafence co= de was updated to include support for some new APIs in Linux. In particular, t= here is a dma_fence_get_status() function which wasn't there before, and support= for tracking timestamps. There also seems to be a dma_fence_get_rcu_locked() routine which wasn't there before (there was just dma_fence_get_rcu()). I suspect that the implementation of these routines is not quite correct, but only the Radeon driver seems to use them in a way which causes them to fail. Note that these routines are used both by the Radeon driver directly and internally by other modules, e.g. linux_sync_file and drm_syncobj. The use patterns may also depend on how the user-space drivers that are part of the= X server use these facilities too, and I don't know much about that. > Oh wow seems like you narrowed it down a lot. I think I've narrowed it down even more. I realized that the only function difference in linux_dmafence.c between the 11.2 and 12.0 cases is the addit= ion of the dma_fence_get_status() function, so I created a smaller patch for th= is module that just #ifdefs this function off and leaves everything else alone. I'm using that code right now, and it seems to be holding up. I updated the tarball with the new patch: http://people.freebsd.org/~wpaul/radeon/drm-fbsd12.0-kmod.tar.gz This means that right now, the only major difference is that I'm using the older version of dma-fence.h from the drm-fbsd11.2-kmod code, with only one minor compatibility fixup in linux_sync_file.c. Unfortunately I can't easily analyze the 14-CURRENT code right now because I don't have a machine with it installed. I might be able to fix that once I = get back to the office next week. One thing I've noticed is that the linuxkpi directory in the drm-fbsd-kmod package gets smaller for more recent version= s of FreeBSD. I guess this is because the GPL'ed modules in the drm driver are gradually being rewritten and migrated into the FreeBSD kernel sources prop= er. I don't know if the dma-fence code is part of that. It seems that at least = for drm-fbsd13.0-kmod the dma-fence code is still in the driver package, but I haven't checked for -CURRENT yet If the dma-fence code is still in the driver package, then it may still have the same bug, but I can't easily kludge up a patch for it just yet. > When I'm done shuffling hardware I'm gonna get my radeonkms test computer= back > on my desk and leave it running and gather more infos on crashes if= that helps[...] It would be interesting to see if the stack traces are similar. I would exp= ect to see the same drm_ioctl()->drm_ioctl_kernel()->radeon_cs() path as that s= eems to be the most common. What would really help is if whoever put together the dma-fence support in = the linuxkpi module would step forward and maybe review it a bit and maybe offer some guidance. I'm only vaguely familiar with what facility is even for; it would be nice if someone with some more insight would comment. Also, my other question remains: should I open an new PR for this? --=20 You are receiving this mail because: You are the assignee for the bug.=