From nobody Thu Mar 24 20:48:18 2022 X-Original-To: bugs@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 0FB3B1A3DBDE for ; Thu, 24 Mar 2022 20:48:19 +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 4KPckV5Bcnz4b6k for ; Thu, 24 Mar 2022 20:48:18 +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 8EE441F096 for ; Thu, 24 Mar 2022 20:48:18 +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 22OKmIF7045326 for ; Thu, 24 Mar 2022 20:48:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 22OKmIeb045325 for bugs@FreeBSD.org; Thu, 24 Mar 2022 20:48:18 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: bugs@FreeBSD.org Subject: [Bug 262765] Random lockups, data loss, and poor I/O and sound quality after 95edb10b47fc1a919cd1687aaf16be9e14456c89 Date: Thu, 24 Mar 2022 20:48:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tod.jackson@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: 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: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648154898; 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; bh=XWLuszHpPhOjSuk+tmGgf7WFB6PM2W48ivmWSsy03h8=; b=OPvLK2InJxx05tTjTZoeAmzDcF28HOA+IUeZMyHR84S9zoyDnDgWWk+m7CtKN7tElfXT1Y MdKFrG73HDKG7N7wCoTDKyrgUxLfn6qAOzLxRvEQH4qwGTi+P2tZxs73kl2RlgRJ8ducvJ F7OUCnXI8shsnwrndSVEPty6nAN170JOeK77udsMM+QTW+FhqeqboeZZfs1EG8YWbz1ljB wrui5e5YynNCjk9V2mTnyNTT4W/KwK8bSr5/TGQ5i7pSssou9sg0tlEgshfp/n3NjW4y+X CsNzMhw4FxJAiSVFK7mx68dG/mHT1vLW71Lv2lkdwBuEaPRadJy0OZuZ6PyJgw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648154898; a=rsa-sha256; cv=none; b=Cio0fZqIgee2LYLRJ79EwHVwp8wTUtQSjriBIY4ogG+kpKfTIgMKASkSWKHixcykzdaqc1 6yNTiqcaiw1wNDsRpl12rLu4RG/R1bcf+tpNfeYu0MMpByaxxaiLmOE0cLWNroBJ7Qq5Wy TpB9Z9NgWOdLYhygeiYPUDRAzjdhQI2nDlpBczAMDCEEGjDrJmjzdgEvA+JpGAhnkL3AAd W5Q8Z7oQfxMk4g4xGNd6zAuIYyjWD6wtmka6pnWa3YUVixYXUDdLXk8ygH1KXRo5C5xLLH OXd1CGV8NgmFtCZnLtdcQdAJabagjWBa1gjKEx712M/lKMokBjdUIUyJ9Lybig== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262765 Bug ID: 262765 Summary: Random lockups, data loss, and poor I/O and sound quality after 95edb10b47fc1a919cd1687aaf16be9e14456c89 Product: Base System Version: CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: tod.jackson@gmail.com This is way beyond my level, and one of the reasons I didn't want to move beyond 13.0. Reverting LinuxKPI: implement dma_sync_single_for_*, apply to (un)map singl= e/sg fixes all sorts of problems for me, but it's a big hammer that probably bre= aks things for everyone else. I have no idea who the culprit is. I first started having troubles in Linux a few years ago, and finally narro= wed it down here. It's entirely possible my firmware is broken, but is there anything we can do? My drm-kmod is aso devoid of panic(), but unluckily this doesn't manifest as panics. I had to make some stuff up or return (-ENOMEM) to accomodate these changes, but it's nothing of interest. This is really complicated because multiple drivers are trying to manage me= mory owned by the firmware, and they don't cooperate. I found my workaround, and it solves a sort of several year mystery, but ma= ybe we can do better. I don't even know what kind of quirk this could be. If I had to guess, the relevant parts are dma_sync_single_for_cpu and cache flushing. This is from some i915 documentation: Now the pagetables are a bit tricky. In the end, they're all in system memo= ry, but there are a few hoops to jump through to get at them. The GTT pagetables has just one level, so with a 4 byte entry size we need 2MB of contiguous pagetable space. The firmware allocates that for us from stolen memory (that is, a part of the system memory that is not listed in the e820 map, so it's= not managed by the Linux kernel). But we write these PTEs through an alias in t= he register mmio bar! The reason for that is to allow the SA to invalidate TLB= s. Note, though, that this only invalidates TLBs for cpu access. Any other acc= ess to the GTT (such as from the GT or the display block) has its own rules for= TLB invalidation. Also, on recent generations we need to (depending upon circumstances) manually invalidate the SA TLB by writing to a magic registe= r. To speed up map/unmap operations, we map that GTT PTE aliasing region in the mmio with wc (if this is possible, which means the cpu needs to support PAT= ). A lot of this is just stubbed or nonexistent right now, notably runtime PM = and the more complicated GT/engine bits. And we really have no idea what the Nv= idia driver is doing, aside from trying and failing to write in write-protected regions. I took this upstream, but nobody really cares because they don't w= ant to deal with a proprietary blob. scbus0 on ahcich1 bus 0: at scbus0 target 0 lun 0 (pass0,ada0) <> at scbus0 target -1 lun ffffffff () scbus1 on ahciem0 bus 0: at scbus1 target 0 lun 0 (pass1,ses0) <> at scbus1 target -1 lun ffffffff () scbus-1 on xpt0 bus 0: <> at scbus-1 target -1 lun ffffffff (xpt0) I can provide any relevant information, but I don't fully understand the problem. I'm on a few day old CURRENT with evadot's drm-subtree on top of i= t, but I don't think my drm-kmod grabs anything of interest from there. --=20 You are receiving this mail because: You are the assignee for the bug.=