[PATCH v4 0/5] powervr: MT8173 GPU support
YoungJoon Lee
getfeus at gmail.com
Wed Jul 29 02:34:46 PDT 2026
Hi Chen-Yu,
A follow-up to my previous email.
The official v1.1 firmware did fix the original "GPU device lost"
problem.
The following now works correctly:
PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vulkaninfo --summary
The driver initializes successfully and detects the PowerVR Rogue
GX6250.
However, while testing actual rendering, I found another issue which
appears to be unrelated to the firmware.
Kernel:
Linux 7.2.0-rc5-next-20260727-stb-cbm-next-pvr-v4+
Board:
Google Elm (Acer Chromebook R13 / MT8173)
Mesa:
mesa 26.1.5
vulkan-powervr 26.1.5
Firmware:
rogue_4.40.2.51_v1.fw
FW version v1.1 (build 6976702 OS)
Kernel command line:
powervr.exp_hw_support=1
Test command:
PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 glmark2-es2-drm
Renderer:
GL_RENDERER:
zink Vulkan 1.2
(PowerVR Rogue GX6250)
The benchmark progresses normally:
build (VBO off) 212 FPS
build (VBO on) 216 FPS
texture nearest 174 FPS
texture linear 173 FPS
texture mipmap 174 FPS
shading gouraud 165 FPS
shading blinn-phong 135 FPS
shading phong 99 FPS
It consistently hangs at:
shading=cel
Immediately afterwards the kernel reports:
refcount_t: underflow; use-after-free
The first warning is:
pvr_free_list_put()
-> pvr_hwrt_dataset_release()
-> pvr_hwrt_dataset_put()
-> pvr_ioctl_destroy_hwrt_dataset()
followed by:
refcount_warn_saturate()
Shortly afterwards another kernel Oops occurs:
Unable to handle kernel NULL pointer dereference
The second backtrace shows:
pvr_gem_object_create()
-> pvr_fw_object_create()
-> pvr_hwrt_dataset_create()
-> pvr_ioctl_create_hwrt_dataset()
The glmark2 process remains as:
glmark2-es2-drm <defunct>
The system is otherwise still reachable through SSH.
I collected additional diagnostics, including:
- complete dmesg
- complete kernel journal
- kernel configuration
- PowerVR module information
- userspace package versions
- process/thread state
- runtime PM state
- running Device Tree
I can send any of these if they would help.
Also, please disregard my previous Tested-by tag for now, since this
rendering issue was discovered afterwards.
Thank you again for your help.
Best regards,
YoungJoon Lee
2026年7月29日(水) 13:38 YoungJoon Lee <getfeus at gmail.com>:
>
> Hi Chen-Yu,
>
> Thank you. Updating the firmware fixed the issue.
>
> I replaced my previous firmware blob with the official v1.1 firmware:
>
> FW version v1.1 (build 6976702 OS)
>
> SHA256:
> e6bf10aaf442798fd81df9b9122e7e85900aafe77fcbec34b426af435c2b1c44
>
> After rebooting, the driver loaded the new firmware successfully:
>
> powervr 13000000.gpu: [drm] loaded firmware
> powervr/rogue_4.40.2.51_v1.fw
> powervr 13000000.gpu: [drm] FW version v1.1
> (build 6976702 OS)
>
> I then ran:
>
> PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vulkaninfo --summary
>
> This now completes successfully and detects the PowerVR Rogue GX6250.
> The previous "GPU device lost" error no longer occurs.
>
> So the issue was caused by the older, non-official firmware blob I was
> using, rather than the v4 kernel series or my kernel configuration.
>
> Thank you for pointing this out, and sorry for the noise.
>
> Tested-by: YoungJoon Lee <getfeus at gmail.com>
>
> Best regards,
> YoungJoon
>
> 2026年7月29日(水) 12:32 Chen-Yu Tsai <wenst at chromium.org>:
> >
> > On Wed, Jul 29, 2026 at 8:08 AM YoungJoon Lee <getfeus at gmail.com> wrote:
> > >
> > > Hi Chen-Yu,
> > >
> > > Thank you for posting the v4 series.
> > >
> > > I tested the complete v4 series on my MT8173 Chromebook, but I am
> > > seeing a GPU device loss as soon as Mesa initializes the Vulkan device.
> > >
> > > My current setup is:
> > >
> > > Board: Google Elm / Acer Chromebook R13 (CB5-312T)
> > > Kernel:
> > > linux-next next-20260727
> > > commit: 33d6e5134c70446eddafbb3fd5ad088e848a7ad6
> > > (next-20260727-5-g33d6e5134c70)
> > >
> > > Kernel release: 7.2.0-rc5-next-20260727-stb-cbm-next-pvr-v4+
> > >
> > > Mesa: 26.1.5
> > > vulkan-powervr: 26.1.5
> > > Firmware:
> > > rogue_4.40.2.51_v1.fw
> > > SHA256:
> > > f44b7056992fb4057c987dcd7073468bec628aa56cb9815b1162f1cb7c1d73f2
> >
> > My firmware blob is different from yours:
> >
> > powervr 13000000.gpu: [drm] loaded firmware powervr/rogue_4.40.2.51_v1.fw
> > powervr 13000000.gpu: [drm] FW version v1.0 (build 6503725 OS)
> >
> > SHA256: 1456504351bd041f0bf96667403ad32460fc7b807c09858df1f083e207323e4a
> >
> > Funny thing is neither of ours match the official firmware blobs released
> > by Imagination [1].
> >
> > The latest version is "FW version v1.1 (build 6976702 OS)" with
> > SHA256: e6bf10aaf442798fd81df9b9122e7e85900aafe77fcbec34b426af435c2b1c44
> >
> > This version also works for me.
> >
> > The "initial version" is "FW version v1.0 (build 6734358 OS)" with
> > SHA256: baa227de4f297b7c0928c6535d15affd80aa9c5f528d2d5dc4b764ad050d22f2
> >
> > And this version also works.
> >
> > It seems your firmware build is even older than mine. I suggest you
> > update it and try again?
> >
> > [1] https://gitlab.freedesktop.org/imagination/linux-firmware/-/blob/powervr/powervr/rogue_4.40.2.51_v1.fw
> >
> >
> > > All five patches applied cleanly. The PowerVR driver probes, loads the
> > > firmware, and creates the DRM render node successfully.
> > >
> > > However, when I run the following from an SSH session without GDM or
> > > another graphical session running:
> > >
> > > PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vulkaninfo --summary
> > >
> > > Mesa prints the expected GX6250 warnings:
> > >
> > > Missing reset support for brn51764
> > > Missing reset support for brn58839
> > > Missing support for brn62269
> > >
> > > The command then hangs, and the kernel reports:
> > >
> > > powervr 13000000.gpu: [drm] *ERROR* GPU device lost
> > >
> > > There are no additional timeout, MMU fault, firmware, clock, or runtime
> > > PM messages immediately before the device-lost message.
> > >
> > > I originally also observed the same failure when GDM started GNOME
> > > Shell, but reproducing it with vulkaninfo from a non-graphical SSH
> > > session indicates that this is not specific to Mutter or GNOME.
> > >
> > > Since your cover letter reports that vkmark and glmark2-es2-drm work
> > > with Mesa 26.1.5, I suspect that there may be a difference in the
> > > kernel configuration or another part of the test environment.
> > >
> > > Could you please share the following details from your working setup?
> > >
> > > 1. The exact Chromebook board/model used for testing
> >
> > The codename is "telesu", which is basically a hana in a different case.
> >
> > > 2. The exact kernel base commit
> >
> > I have a whole bunch of patches on top of next-20260727, but none
> > that should affect this.
> >
> > > 3. The kernel configuration, or at least the relevant DRM, PM,
> > > generic power-domain, IOMMU, and MediaTek clock options
> >
> > All relevant options are built-in.
> >
> > > 4. Whether CONFIG_DRM_POWERVR was built-in or built as a module
> >
> > Module.
> >
> > > 5. The firmware SHA256
> >
> > See above.
> >
> > > 6. The kernel command line and bootloader used
> >
> > Chromebook's builtin bootloader.
> >
> > cmdline:
> >
> > cros_secure root=PARTUUID=824526A4-24EE-344D-85A2-20630C42D31A
> > console=tty0 console=ttyS0,115200n8 earlycon ro text drm.debug=0x106
> > panic=30 rootwait log_buf_len=1M no_console_suspend
> >
> > AFAICT nothing special.
> >
> > > 7. Whether `vulkaninfo --summary` also completes successfully
> > >
> > > My current relevant configuration includes:
> > >
> > > CONFIG_PM_SLEEP=y
> > > CONFIG_PM=y
> > > CONFIG_PM_GENERIC_DOMAINS=y
> > > CONFIG_MODULES=y
> > > CONFIG_DMA_SHARED_BUFFER=y
> > > CONFIG_DRM_POWERVR=m
> > > CONFIG_DRM_MEDIATEK=y
> > > CONFIG_SYNC_FILE=y
> > > CONFIG_COMMON_CLK_MT8173_MFGTOP=y
> > > CONFIG_IOMMU_SUPPORT=y
> > > CONFIG_ARM_SMMU=y
> > > CONFIG_MTK_IOMMU=y
> > >
> > > I would be happy to test additional patches or provide any further
> > > logs, kernel configuration, or debugging information if that would
> > > help.
> >
> > As mentioned above, please try updating your firmware blob. Your
> > version is even older than mine, and neither of ours is the "official"
> > release.
> >
> >
> > Thanks
> > ChenYu
> >
> >
> > > Thanks,
> > > YoungJoon Lee
> > >
> > > 2026年7月29日(水) 0:28 AngeloGioacchino Del Regno
> > > <angelogioacchino.delregno at collabora.com>:
> > > >
> > > > On 7/28/26 16:44, Chen-Yu Tsai wrote:
> > > > > On Tue, Jul 28, 2026 at 10:33 PM AngeloGioacchino Del Regno
> > > > > <angelogioacchino.delregno at collabora.com> wrote:
> > > > >>
> > > > >> On 7/28/26 15:13, Chen-Yu Tsai wrote:
> > > > >>> On Tue, Jul 28, 2026 at 9:10 PM Brian Masney <bmasney at redhat.com> wrote:
> > > > >>>>
> > > > >>>> Hi Chen-Yu,
> > > > >>>>
> > > > >>>> On Tue, Jul 28, 2026 at 05:17:58PM +0800, Chen-Yu Tsai wrote:
> > > > >>>>> Hi everyone,
> > > > >>>>>
> > > > >>>>> This is v4 of my MT8173 PowerVR GPU support series.
> > > > >>>>>
> > > > >>>>> This time around Mesa was ready for basic testing, using both vulkanmark
> > > > >>>>> and glmark2-es2-drm (with Zink). Details below.
> > > > >>>>>
> > > > >>>>> Changes since v3 (all in the clk driver patch):
> > > > >>>>> - Changed pm_runtime_put() to pm_runtime_put_sync()
> > > > >>>>> - Added missing of_node_put() in remove function
> > > > >>>>>
> > > > >>>>> Changes since v2 (all in the clk driver patch):
> > > > >>>>> - Made COMMON_CLK_MT8173_MFGTOP depend on PM
> > > > >>>>> - Needed since the driver implements PM domains using the generic PM
> > > > >>>>> domain library, which also depends on PM
> > > > >>>>> - Fixes build breakage (kernel test robot)
> > > > >>>>> - Fixed "RST_DELAY_CNT" name (Brian)
> > > > >>>>> - Dropped unused mfg_desc (Brian)
> > > > >>>>> - Added check of clk_prepare_enable()'s return value in
> > > > >>>>> clk_mt8173_mfgtop_power_on() (Brian)
> > > > >>>>> - Saved error value for return in IS_ERR(data->clk_26m) branch
> > > > >>>>> (Dan Carpenter / kernel test robot w/ smatch)
> > > > >>>>>
> > > > >>>>> Changes since v1:
> > > > >>>>> - Adapted to changed DT bindings
> > > > >>>>> - Dropped driver change
> > > > >>>>> - Use same power domain for "a" and "b" GPU power domains
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> This series enables the PowerVR GPU found in the MT8173 SoC, found in
> > > > >>>>> some Chromebooks.
> > > > >>>>
> > > > >>>> I'm making a pull for Stephen for the clk changes. Should patches 1,2,4
> > > > >>>> go through the clk tree? Patches 3,5 go through the DRM tree?
> > > > >>>
> > > > >>> Only patches 1 and 2 should go through the clock tree.
> > > > >>>
> > > > >>> Patch 3, 4, 5 can all go through the soc tree if Angelo wants to pick up
> > > > >>> DT binding patches. Otherwise I can push patch 3 through drm-misc.
> > > > >>>
> > > > >>
> > > > >> Not sure if I can really take the DRM bindings patch through soc.
> > > > >>
> > > > >> I will take the devicetree ones exactly right now, even though it's going to
> > > > >> give warnings.
> > > > >>
> > > > >> I trust that you'll make the binding get into linux-next before it's too late.
> > > > >
> > > > > Rob beat me to it. :D
> > > >
> > > > Love it!
> > > >
> > > > Thanks Rob :-D
> > > >
> > > > Cheers,
> > > > Angelo
More information about the Linux-mediatek
mailing list