Video playback random blackouts and flickering

[Susie1818]

Checklist [README]

• [X] Device is not undervolted nor overclocked
• [X] Device is using the latest drivers
• [X] Application is not cracked, modded and use the latest patch

Application [Required]

Netflix app (Windows)

Processor / Processor Number [Required]

intel Core i5-13500

Graphic Card [Required]

intel Arc A770

GPU Driver Version [Required]

31.0.101.4952

Rendering API [Required]

• [ ] Vulkan
• [ ] OpenGL
• [ ] DirectX12
• [ ] DirectX11
• [ ] DirectX10
• [ ] DirectX9
• [X] Not applicable

Windows Build Number [Required]

• [ ] Windows 11 22H2
• [ ] Windows 11 21H2
• [X] Windows 10 22H2
• [ ] Windows 10 21H2
• [ ] Other (Please specify)

Other Windows build number

No response

Intel System Support Utility report

SSU_20231105.txt

Description and steps to reproduce [Required]

Netflix, screen randomly blacks out. Easily triggers blackouts if you fast forward or rewind (the 10-second button) during playback.

Driver version 4952, 4900, 4887, 4885 all have this bug.

For the time being, a workaround is reverting the driver back to version 4826.

Device / Platform

No response

Crash dumps [Required, if applicable]

No response

Application / Windows logs

No response

[Karen-Intel]

@Susie1818 TY for your report! Adding to debug queue :)

Stay tuned!

Karen

[Jacoby1218]

this is a Widevine issue, easiest way to produce this issue

• Use Firefox and open Hulu, Netflix, or Disney+ (hulu most reliably produces this issue for me)

[Susie1818]

@jacob1218 Thank you for the supplementary remarks.

[Susie1818]

Today I found this glitch seems to occur only in fullscreen mode. It also happens when I playback local video files with Windows "Media Player" or Windows "Films & TV" apps as long as they are in fullscreen mode but no problem when in windowed mode.

[Susie1818]

WHQL driver v4953 still doesn't resolve the issue, and moreover this problem is not listed in the known issues in the release notes. I believe this issue is a very serious one and should definitely be listed in the know issues because playing videos in fullscreen is one of the most basic functions that should never be messed up.

[Susie1818]

Hey, I want to remind you guys that this issue has persisted through driver version 4885, 4887, 4900, 4952, 4953, 4972, and 5074. Still not fixed yet.

[akarnokd]

Hi. Is your monitor & cable HDCP compliant?

(Ever since 4885, I get temporary monitor disconnects when loading up Netflix, Apple TV+, Spotify, Amazon Prime for the first time in a day/machine restart. It doesn't happen repeatedly once I watch the videos. My monitor is old and is not HDCP compliant. Something changed between 4672 and 4885 that brought this up for me.)

[Susie1818]

Hi. Is your monitor & cable HDCP compliant?

Cable is irrelevant to HDCP compliance. My monitor is compliant with HDCP 2.2.

[Susie1818]

(Ever since 4885, I get temporary monitor disconnects when loading up Netflix, Apple TV+, Spotify, Amazon Prime for the first time in a day/machine restart. It doesn't happen repeatedly once I watch the videos. My monitor is old and is not HDCP compliant. Something changed between 4672 and 4885 that brought this up for me.)

I can still watch videos without screen flickering and blackouts as long as I don't switch those apps to fullscreen mode. It's just a bug. Driver v.4826 and earlier versions didn't have this problem.

[freak2fast4u]

I've been having these full blackout issues on Linux also, and not only when watching videos, simply idling on the desktop or browsing in general (though I wasn't especially careful wether I had a youtube tab open or not in the background). I don't know to what extent the driver code is shared between windows and linux but it's safe to assume it might be an issue with the latest VBIOS (1068). I don't remember having these problems with VBIOS 1064. I'm also not too sure if my problem has the same root cause, but it might be a clue. Depending on Intel's answer I'll open a separate ticket. Another clue is that from one reboot to the next, I can encounter either 0 blackouts, or dozens in a hour. It also doesn't seem to happen while I'm gaming, only on the desktop (both valid in windows AND linux, wierd huh ?). Would it be correlated to low GPU usage ? Aggressive power-saving measures in the VBIOS ? I'll try messing around with the ASPM settings in the BIOS one more time to see if that leads anywhere, it might take a few days to get a deterministic conclusion, if possible. I vaguely remember I was messing with ASPM at the same time that the VBIOS 1068 rolled out, so it could be an unfortunate coincidence.

[Susie1818]

It's possible that the issue is caused by the VBIOS but I cannot confirm this. I am just pretty sure that this issue did not exist until the driver 4885 update. I don't know whether the VBIOS was flashed AGAIN by 4885 or not. I hate it that intel flashed the VBIOS for no apparent reason (and even did it multiple times).

[akarnokd]

FWIW, the firmware flash log is located in c:\Intel\FWUpdateService\ as IntelGFXFwUpdateToolLog_<date_time>.log and indicated by GPU FW Progress: 2/100: 2% entries.

[Karen-Intel]

Thanks for the update! This issue has been running away from me in my regular systems (both AMD and Intel) so we're looking for a closer match in HW, specially the board. @Susie1818 can you share your display specs? I tested with a regular HD system on both and can't seem to repro Help!

Karen

[freak2fast4u]

Here's some new info from my side :

Message translates to : "igfxnd display driver stopped responding".

I started having blackouts while playing Final Fantasy XV (Steam version) just today, so I went to the event viewer and saw a few of these 4101 error ID's that seemed to correspond at different moments where I had these today. It turns out there's a ton of them, and these might be all the occurences of screen blackouts I'm having. Somehow, the driver comes back to life half a second later and the game resumes as if nothing was wrong. One single time the game crashed completely.

It can't be Widevine related in my case because I'm not watching DRM-protected video.

As you can see, there are days when I get plenty, and days when I get none (I use my computer every single day).

I use a 1440p 144hz monitor from Agon (AOC AG241QG4 AG241QX, which connects via DP 1.2) if that's of any help.

Also, I re-checked my ASPM settings which were all back to default (Auto in the BIOS, and Max Performance in Windows, not power-save), so I doubt that's the issue.

Edit : no new occurences since my report 2 hours ago (I've being playing the game non-stop). Wierd. Really Wierd. Edit2 : fixed monitor model, windows was mis-reporting it as something else

[Susie1818]

@Karen-Intel

can you share your display specs?

AGON AG273FXR 1920×1080 using DP 1.4 connection with VRR enabled

[freak2fast4u]

Also possibly related :

By comparison, on AMD RX 5700XT, I have round numbers to choose from (60.000, 100.000, 120.000, 144.000). I have no idea how to check if these numbers are accurate since my screen OSD seems to round them off too (shows 144hz instead of 143.912Hz)

[Karen-Intel]

Ok so your displays are kind of similar (AOC AG241QG and AGON AG273FXR), I'll find out if we have one in the lab!

Karen

[Susie1818]

@Karen-Intel

The blackouts actually behave just like what you see when you change monitor refresh rate. The signal re-establishes and the audio is also temporarily interrupted until the video shows up again.

[Susie1818]

@Karen-Intel

Hey, I just found something that might be helpful for finding the root cause. The blackouts I mentioned in ticket #595 behaves exactly the same as this one -- (when I play the game "Immortals Fenyx Rising" using DXVK,) the DP signal is actually disconnected for a while because the audio (my PC plays audio via display) is also interrupted until it re-establishes the connection. I guess the problem is caused by Arc GPU trying to change the monitor refresh rate.

[freak2fast4u]

Funnily enough, using DXVK seems to fix the problem for this user in another game : https://github.com/IGCIT/Intel-GPU-Community-Issue-Tracker-IGCIT/issues/635#issue-2038856651

[Karen-Intel]

Thank you both @Susie1818 and @freak2fast4u! Let's hope user in #635 confirms having the same or similar display. We will have results on a system on our end most likely by next week, we're in the process if getting our hands on an AGON AOC display in the lab:)

Karen

[Susie1818]

@Karen-Intel

Hey, I just found something more interesting! This might not be monitor related but content related. And now I am pretty sure it's due to refresh rate change.

I found the blackouts don't happen with some videos but do happen with some others, so I turned on my monitor's refresh rate indicator on its OSD. With Netflix, I found some videos don't go blackout, for example, "The Witcher". When it was playing, the monitor refresh rate kept at 120Hz for the whole time. And some videos go blackouts such as "The Queen's Gambit" because when it is playing it will change refresh rate to 48Hz, and when it changes, the signal disconnects and comes back in a second, but if I click on the fast-forward or rewind buttons, it changes the refresh rate back to 120 so it goes blackout again, and then after it comes back at 120Hz for a while, it changes to 48Hz again, so it goes blackout again.

I tried this with driver 4826 (now I start to believe it's VBIOS related) and when the refresh rate changes to 48Hz while playing "The Quess's Gambit", the signal was not lost, the OSD just showed the refresh rate jumped to 48 from 120 like when you play games with VRR so the screen didn't go blackout.

This also happens when I play videos using Windows Media Player. If I use it in windowed mode, there is no problem, but if I switch it to fullscreen mode, and if the source video is 60FPS, it will attempt to change the monitor refresh rate to 60 and then it goes blackout. If the source video is 30FPS, it won't change the monitor refresh rate and keeps playing at 120Hz and no blackouts.

Summary: If the video content material is actually 24 or 60 FPS, it will attempt to change the refresh rate and then cause blackouts. If the video is 30FPS then this problem won't manifest. (My monitor refresh rate is set at 120Hz)

And driver 4826 (or probably its VBIOS) behaves in a way that even though when you switch to fullscreen the refresh rate will still change as mentioned above, the screen won't go blackout and the video output signal won't disconnect and it just acts like VRR as I can see the refresh rate changes on the OSD.

[Susie1818]

@Karen-Intel

Another experiment for you:

Since the problem goes with 60FPS video files on Windows Media Player, I tried to set my monitor refresh rate to 60Hz, and again I found something very interesting.

If I set the monitor refresh rate to 60.000Hz, the problem persists -- in fullscreen mode, it goes blackout. If I set the monitor refresh rate to 59.940Hz, the problem doesn't occur when playing the 60FPS video! So I guess the video file I played is actually 59.94 FPS and the VBIOS wouldn't attempt to change the monitor refresh rate.

Unfortunately, in the drop-down menu of the monitor refresh rate list, I only have 120.000Hz and don't have 119.880Hz as an option, so I can't test and don't know if the problem can be resolved as long as the refresh rate is an integer multiply of the source framerate (23.976 and 29.97 and 59.94).

However, I have to reiterate that this problem doesn't exist with driver 4826 (or its VBIOS) and earlier versions.

[Susie1818]

@Karen-Intel

I just tried playing Netflix videos with my Nvidia RTX4070, and I found it just won't change monitor refresh rate in fullscreen mode no matter what content material is being played back. So, I don't understand why intel Arc's media engine needs to change monitor refresh rate when it plays back videos.

[Karen-Intel]

Hey @Susie1818 thank you for all your experiments! I'll find out how it looks on my end after I complete the series of experiments. I will share my internal report number soon

Karen

[Karen-Intel]

Hey @Susie1818 could you record a small video for me? I think I found the blackouts in fast playback but I just want to make sure. @freak2fast4u you're welcome to share evidence also please! That will help my report a lot, appreciate in advance :)

Karen

[Susie1818]

@Karen-Intel

Okay, here you are. Driver (or maybe VBIOS) version is the latest, 5074.

By the way, I don't know if this is relevant or not, but my A770 is the Acer Predator BiFrost variant.

[freak2fast4u]

I managed to catch it on camera, and as you'll hear in the commentary (sorry for the mild swearing :p), it's the first time it's been that bad. Computer was on all night as usual, I turned the screen on after my morning coffee, came to browse IGCIT for a few minutes without any problems, and I watched @Susie1818's video on youtube (excellent evidence btw !), everything went fine. Then I started searching if my OSD had a refresh rate indicator I could use (turns out it doesn't), and out of nowhere, my display started going black multiple times in a row all while doing seemingly nothing (moving the mouse ? does that even count ?) : https://youtu.be/Sm35gMNQYJQ

Also, the events shown in the even viewer towards the end of the video aren't relevant because they are timestamped from before I started recording (I checked after I finished recording), so you can disregard that part AFAICT.

Also, I've been using the computer for about half an hour since I captured the video, and no black screens in sight.

Incidentally, I went back to my OSD a few minutes later, and instead of showing 144hz, now the V.Frequency option shows "FreeSync", except I didn't touch anything ...

While it was freaking out (as seen in the video) :

Now (stable) :

Are there any logs I can enable somewhere ? The Intel folder in the event viewer isn't really that populated (this is "Application", and "System" is empty) :

[Susie1818]

@Karen-Intel @freak2fast4u

I found a temporary workaround to avoid blackouts. It's disabling the monitor's FreeSync (Adaptive-Sync) support via the monitor's OSD menu. If I do so, the monitor refresh rate cannot be changed by Arc's media engine during video playback. I played some videos that originally would change my monitor refresh rate to 48 or 60, and now they can't do that anymore, and the refresh rate just stays at 120 for good.

If I leave the monitor's FreeSync (Adaptive-Sync) feature ON in the OSD, then even if I turn off all possible VRR options in (1) Windows Display settings→Graphics settings, and in (2) Intel® Graphics Command Center, and in (3) Intel® Arc™ Control, the Arc's media engine (since driver 4885) can still change monitor's refresh rate to 48Hz or 60Hz at will and causes blackouts. (Driver 4826 and before also changes refresh rate but doesn't cause blackouts)

The root cause of this issue must be related to VRR because this monitor actually doesn't have a "48Hz" option in the refresh rate drop-down menu for you to select. It's merely that it supports VRR range 48Hz-144Hz.

But, basically I don't think anyone would like to disable Adaptive-Sync feature of the monitor. So, this workaround is not practical.

[Karen-Intel]

Hi guys. Thanks again @Susie1818 and @freak2fast4u Here's a small evidence. Took me a while to capture the capping in my Intel ARC System on Chrome + Netflix + Avatar the last airbender. In the first part of the video you will see there is no FPS capping in windowed mode, but it is in fullscreen. System has adaptive sync ON and VRR is also ON, which leads me to think in this display I will not get the blackouts at all. In the second part, in my NVIDIA system using another 4k monitor, you will see there is no capping to 48 FPS, Adaptive sync is ON and no blackouts there either. So I think we have 2 issues here - The capping, not related to the display, and the blackouts. I need to confirm my blackout theory in the AGON display next week and I will let you know also how we will proceed with the capping issue :) Stay tuned

Karen

[Susie1818]

@Karen-Intel

In fact I think taking advantage of VRR for video playback is a brilliant idea because video synchronization is a very big problem when the display's (fixed) refresh rate is not exactly an integer multiply of the framerate of the video content. I believe it works like a charm. However, the driver (probably the VBIOS I guess) since version 4885 screwed it up. I have tried rolling back to 4826 (I confirmed that it also flashed the firmware during installation) and then there was not this screen blackout problem.

You guys at intel really have to confess the reason why you had to flash the firmware in the first place. So far all these Arc firmware updates only introduced problems (abnormal fan speed and video playback blackouts) and no benefits at all. You know, I have been using Nvidia GPUs for many many years and I've never heard even once that they included a firmware(VBIOS) update in a driver update.

[Susie1818]

@Karen-Intel

I think if you really need to flash the VBIOS to fix some bugs, you should make it a standalone package rather than binding it with every driver update. Your current method of doing it (binding) is very anti-consumer and very risky. Technically speaking, a FIRMware itself is not designed to be updated so frequently as software in the first place. So, your way of doing it just like you are students doing some sort of experiments in labs -- updating firmware so often -- is very immature because the Arc GPU is already a commercial product.

[freak2fast4u]

There's an oopsie on my side, my screen is in fact a AG241QX, being mis-reported by windows as AG241QG4 ... that might even be part of the problem.

Edit : oh well, maybe not, even Agon's I-Menu software reports it as such : facepalm

[Susie1818]

@Karen-Intel @freak2fast4u

Just want to let you guys know that video playback is fixed with the latest driver v.5081.

Take a look. VRR is working with video playback now, just like how it did with driver 4826 (and before).

[pcslide]

@Karen-Intel @Susie1818 If you play a movie shot in 24fps on a display supporting VRR, the display is supposed to lower its refresh rate to 48hz or 24hz(if it supports it), isn't it? I haven't check this on NVidia card, but I suppose the implementation on Intel's side works perfectly in this case. My question is why can't 3rd party video player like Potplayer use this feature? Anyone know how to enable this feature in a 3rd party video player?

[pcslide]

@Susie1818 Could you check if Intel drivers try to load firmware interface and to flash v.bios on every boot?
If it does, entries should be under Computer Management->System tools-> Event Viewer -> Windows logs -> System

[freak2fast4u]

Installed latest WHQL driver yesterday. Here's the kicker : I left the computer on all night (as per usual these days), and turned the screen on around 10am. Then I checked in the OSD, and it was synchronized to 144hz, not FreeSync. This leads me to believe that some init/re-init/wake-up procedure randomly goes either to FreeSync mode or to constant 144hz mode (as per OSD indication).

With the previous driver, as long as the display was engaged in Freesync mode, I got no blackouts at all, but when synced to a constant 144hz ... I got blackouts with the previous driver, so I'll try using the computer like this (in constant 144hz mode) and see if the blackouts stop happening. Edit : running any 3D app yields a solid black screen immediately, and a "sync loop" begins, where the gpu and screen keep trying to sync without succeeding, I can't even open the OSD to see what's happening because the screen is getting reinitialized over and over by the GPU, so it's still a problem :/ Edit 2 : opening the Microsoft Store and using it produces blackouts everytime the window opens or is interacted with when the monitor isn't engaged in Freesync mode. That's as easy as it gets to reproduce the issue.

I'm 99% certain that if I reboot the computer, it will go directly into FreeSync mode after entering windows and the issue will disappear, until next time I leave the computer on with the screen off. I did that same test a few days back, for 3 hours (afternoon walk), and the screen turned back on into Freesync mode. This time, it was over 8 hours (overnight), and it failed (144hz constant).

As a workaround, I'll try what this user suggested, using a custom resolution @ 142hz with CRU : https://github.com/IGCIT/Intel-GPU-Community-Issue-Tracker-IGCIT/issues/379

(Comment updated after more testing)

[Susie1818]

Could you check if Intel drivers try to load firmware interface and to flash v.bios on every boot? If it does, entries should be under Computer Management->System tools-> Event Viewer -> Windows logs -> System

There is no sign of VBIOS being flashed during boot process.

[freak2fast4u]

Well, I turned the screen on this morning after leaving the computer on over night, and this time it resumed to FreeSync mode, not 144hz constant mode, though I slept a little less this time. So either the synchronisation mode is random and/or rare, or there's a very long delay (8h ? 10h ?) involved.

I'll try boot-looping my system over and over with the screen off and see if it's random from boot. If not, then it's related to a "very long idle time", whatever that might be.

[freak2fast4u]

Some news about this problem on my end : Now that I'm confident enough to flash different VBIOS/firmware files, after a little more specific testing, it would seem VBIOS 1068 alleviates this blackout problem (it is shipped with driver 4952 and up AFAICT), however Freesync still doesn't always engage when it should. At least, now, when the driver fails to engage Freesync with the monitor, it manages to sync to a constant 144hz without any blackouts, so all of a sudden Windows got much more useable for me. Don't take my word for it just yet, I'll see how my system behaves for a few more days before I draw a definitive conclusion, but I found a way to make it blackout on-demand with VBIOS 1064 (something quicker than waiting for 10+ hours every night), and that method doesn't work with 1068, so it's a good sign. Edit : ... well, launching a game while the screen was at a fixed 144hz made it blackout (it's FF XV in my case but I doubt that matters). Alt-tab restores the display (I can select another window), but when I select the game window, it blacks out again ... sigh getting kinda frustrated over here ...

Now, I'm stuck between a rock and a hard place. I use multi-boot for windows/linux setup, and VBIOS 1068 won't allow me to reboot into linux. Only a cold boot will work (power off + power on, not a reset), most of the times, but not always. With VBIOS 1064 on the other hand, I have no problems rebooting from windows to linux and vice-versa without doing a full power cycle, so I believe VBIOS 1068 has a regression related to power-on vs. reset events. It's wierd I don't have problems rebooting under Windows and only under Linux, but under Linux I tried many different kernel versions (6.1, 6.2, 6.6, 6.7...) and variants (liquorix, xanmod, zen, ubuntu, etc.), mesa versions (23.1, 23.3, 24.0-git, 24.0-rc2), different distros (Linux Mint, Manjaro, some Live CD's like Fedora KDE spin, etc.), and they ALL, without fail, crash at the login prompt/session manager. Sometimes even before that. I am systematically greeted with this garbage with rebooting into linux on VBIOS 1068 :

https://github.com/IGCIT/Intel-GPU-Community-Issue-Tracker-IGCIT/assets/3486369/507ac3f5-ed11-482f-a450-94fc7985ffb0

@Karen-Intel, @IGCIT : what do you suggest I do about this ? Should I open a new issue here ? Or rather with the devs over at freedesktop/mesa ? Considering the VBIOS version definitely has an incidence I'm hoping you guys could maybe take it from here ? I'll be happy to open a ticket over at mesa but ... it's an issue only someone that uses both windows and linux on the same machine would notice. A full-time Linux user will still be using VBIOS 1053 or maybe older in the current state of things ...

Edit: Actually, I just remembered there's one test I haven't done yet, that is to switch my linux installs from using i915 to the new xe kernel driver and see if that fixes it. Will report back on that in a while.

[freak2fast4u]

Well, using CRU (Custom Resolution Utility) to replace 144hz with 142hz actually does solve the blackout issue when the monitor is in constant refresh mode, which happens every time the screen is turned on after being turned off for longer than 10 hours. So I have a workaround, great ! Thanks @gargamel314 for sharing this tip ! (see issue 379 : https://github.com/IGCIT/Intel-GPU-Community-Issue-Tracker-IGCIT/issues/379). To re-engage Freesync when this happens, changing the refresh rate in the windows settings actually works. So does using ToggleMonitorRefreshRate, for which I conveniently created a shortcut to on the desktop with "142" as a parameter (the tool can be grabbed here : https://github.com/kostasvl/ToggleMonitorRefreshRate)

There's still a problem with the DisplayPort Freesync implementation on Intel's side IMHO. This is with 5085 drivers and VBIOS 1064. I'm willing to test VBIOS 1068 again, but as mentioned above, I can't really use it for anything else than testing because Linux (the i915.ko more specifically ? I can't tell) doesn't like it ATM, and the new Linux xe.ko is still experimental. I'll give it a whirl when kernel 6.8-rc1 comes out and see how that behaves.

Edit 22/01/2024 : well, Linux kernel 6.8-rc1 behaves exactly the same as the previous kernels on VBIOS 1068, wether I use the i915 or xe modules => I randomly get garbage on the screen instead of the session manager. I also witnessed a cold-boot producing garbage, and a reset leading to a functioning session, so all my previous observations about reset vs cold-boot went out the window, and for any practical purpose, consider it's random.

[freak2fast4u]

I'm back on VBIOS 1068 for some testing (with latest drivers, 5085), will report back in a while.

[Karen-Intel]

Some news about this problem on my end : Now that I'm confident enough to flash different VBIOS/firmware files, after a little more specific testing, ~it would seem VBIOS 1068 alleviates this blackout problem (it is shipped with driver 4952 and up AFAICT), however Freesync still doesn't always engage when it should. At least, now, when the driver fails to engage Freesync with the monitor, it manages to sync to a constant 144hz without any blackouts, so all of a sudden Windows got much more useable for me. Don't take my word for it just yet, I'll see how my system behaves for a few more days before I draw a definitive conclusion, but I found a way to make it blackout on-demand with VBIOS 1064 (something quicker than waiting for 10+ hours every night), and that method doesn't work with 1068, so it's a good sign.~ Edit : ... well, launching a game while the screen was at a fixed 144hz made it blackout (it's FF XV in my case but I doubt that matters). Alt-tab restores the display (I can select another window), but when I select the game window, it blacks out again ... sigh getting kinda frustrated over here ...

Now, I'm stuck between a rock and a hard place. I use multi-boot for windows/linux setup, and VBIOS 1068 won't allow me to reboot into linux. Only a cold boot will work (power off + power on, not a reset), most of the times, but not always. With VBIOS 1064 on the other hand, I have no problems rebooting from windows to linux and vice-versa without doing a full power cycle, so I believe VBIOS 1068 has a regression related to power-on vs. reset events. It's wierd I don't have problems rebooting under Windows and only under Linux, but under Linux I tried many different kernel versions (6.1, 6.2, 6.6, 6.7...) and variants (liquorix, xanmod, zen, ubuntu, etc.), mesa versions (23.1, 23.3, 24.0-git, 24.0-rc2), different distros (Linux Mint, Manjaro, some Live CD's like Fedora KDE spin, etc.), and they ALL, without fail, crash at the login prompt/session manager. Sometimes even before that. I am systematically greeted with this garbage with rebooting into linux on VBIOS 1068 :

VID_20231211_181735_edit.mp4 @Karen-Intel, @IGCIT : what do you suggest I do about this ? Should I open a new issue here ? Or rather with the devs over at freedesktop/mesa ? Considering the VBIOS version definitely has an incidence I'm hoping you guys could maybe take it from here ? I'll be happy to open a ticket over at mesa but ... it's an issue only someone that uses both windows and linux on the same machine would notice. A full-time Linux user will still be using VBIOS 1053 or maybe older in the current state of things ...

Edit: Actually, I just remembered there's one test I haven't done yet, that is to switch my linux installs from using i915 to the new xe kernel driver and see if that fixes it. Will report back on that in a while.

Hey @freak2fast4u thanks. About Linux, you can open a new thread here and tag this thread

Karen

[Karen-Intel]

Hi guys! Any updates in this issue?

[Susie1818]

@Karen-Intel

I think the original ticket can be closed since it has been resolved. Hopefully the issue won't happen again in future driver updates.

[Karen-Intel]

@Susie1818 thank you for replying so quickly! We will proceed to do so @Arturo-Intel, help me out please :)

Have a wonderful day!

Karen