58 bytes, text/x-review-board-request
This bug was filed from the Socorro interface and is report bp-f304c896-109c-409b-af18-342372161103. ============================================================= I see a lot of Youtube URLs in these crashes, so I'm going to assume it is a hardware decoding issue like bug 1271525 or bug 1283892. This is Nightly-only. I'm guessing these two signatures are the same issue, but maybe not. There are about 45 of each in the last week. Here's a report from the kernelbase version: bp-5fdca4fb-dca9-4b85-8440-f57c32161103
Both signatures are correlated with DXVA2D3D11+. For igd11dxva64.dll | ntdll.dll@0x65e6f, on 52.0a2 and 53.0a1 over the past week, we have: - igd11dxva64.dll - 18.104.22.16863: 6 - 22.214.171.12452: 2 - 126.96.36.19944: 11 - 188.8.131.5254: 8 - 184.108.40.20690: 2 - 220.127.116.1180: 3 - 18.104.22.16864: 8 - 22.214.171.12477: 1 - 126.96.36.19900: 3 - 188.8.131.5260: 1 For igd11dxva64.dll | kernelbase.dll@0x175fe, on 52.0a2 and 53.0a1 over the past week, we have: - igd11dxva64.dll - 184.108.40.20663: 2 - 220.127.116.1126: 2 - 18.104.22.16844: 1 - 22.214.171.12454: 5 - 126.96.36.19990: 2 - 188.8.131.5231: 7 - 184.108.40.20664: 14 - 220.127.116.1160: 9 It looks like the 32-bit versions of some of these drivers are blocklisted: https://dxr.mozilla.org/mozilla-central/rev/0ddfec7126ec503b54df9c4b7c3b988906f6c882/modules/libpref/init/all.js#362. I suppose we should blocklist the 64-bit version as well, right? Should we revisit this blocklist? We have a lot of blocks for 32-bit drivers without equivalents for 64-bit ones.
3 years ago
Priority: -- → P1
Happy to block these driver versions (and a few more, if I extend the crash report period). I'd prefer to feed the list based on reports, instead of just copying between 32&64 bits.
Assignee: nobody → gsquelart
(In reply to Gerald Squelart [:gerald] from comment #2) > Happy to block these driver versions (and a few more, if I extend the crash > report period). > > I'd prefer to feed the list based on reports, instead of just copying > between 32&64 bits. Should we re-evaluate the blocklist actively, instead of waiting for bug reports, now that we've had D3D11 on release for a while? (I think the original blocklist was built on beta, right?). On release we have a larger and more diverse population, so we might be hitting crashes with driver versions that on beta nobody had. E.g. for igd10iumd32.dll (and igd10iumd64.dll), we have a bunch of 9.17.* (Windows 8, Direct X 11.0, according to http://www.intel.com/content/www/us/en/support/graphics-drivers/000005654.html) that we are not blocking but that might be causing crashes: https://crash-stats.mozilla.com/search/?signature=~igd10umd32.dll&app_notes=~DXVA2D3D11%2B&product=Firefox&date=%3E%3D2016-11-17T11%3A03%3A00.000Z&date=%3C2016-11-24T11%3A03%3A00.000Z&_sort=-date&_facets=signature&_facets=adapter_driver_version&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-adapter_driver_version. For nvwgf2um.dll, the same (bug 1292273). The same applies to other drivers.
I've filed bug 1320054 to re-evaluate the blocklist.
Firefox 53 supports out of process decoding which means we can take more risks with drivers. The penalty is a couple of seconds of recovery rather than a browser crash. Hopefully one day we'll be able to automate driver crash management.
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #6) > Firefox 53 supports out of process decoding which means we can take more > risks with drivers. The penalty is a couple of seconds of recovery rather > than a browser crash. Hopefully one day we'll be able to automate driver > crash management. Right now, the penalty is dropping out of acceleration (not just video decoding, but all of graphics.) We do not have the "restart the GPU process" working.
Comment on attachment 8813950 [details] Bug 1315089 - Block D3D11 for igd11dxva64.dll 20.19.15.X - https://reviewboard.mozilla.org/r/95252/#review98168
Attachment #8813950 - Flags: review?(ajones) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/c7ce65265593 Block D3D11 for igd11dxva64.dll 20.19.15.X - r=kentuckyfriedtakahe
Comment on attachment 8813950 [details] Bug 1315089 - Block D3D11 for igd11dxva64.dll 20.19.15.X - Approval Request Comment [Feature/Bug causing the regression]: Video decoding on some buggy Intel drivers [User impact if declined]: Crashes when playing videos [Is this code covered by automated tests?]: Yes, media tests [Has the fix been verified in Nightly?]: According to bug 1331086 comment 0, crashes stopped after 53.0a1 build 20170103030204 when this patch landed [Needs manual test from QE? If yes, steps to reproduce]: No (I think) [List of other uplifts needed for the feature/fix]: None [Is the change risky?]: No [Why is the change risky/not risky?]: Only adding more driver versions to blocking list [String changes made/needed]: None
Attachment #8813950 - Flags: approval-mozilla-aurora?
Comment on attachment 8813950 [details] Bug 1315089 - Block D3D11 for igd11dxva64.dll 20.19.15.X - d3d11 block list addition, aurora52+
Attachment #8813950 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Can we investigate and find a workaround or a fix to the crash, rather than just block it? I am having version 18.104.22.16854, yet to have any kind of crashes. With this bug is being closed, I will have to update driver. However, it depends on customized hardware drivers that the OEM provides. Suddenly, me and many users does not have D3D11 hardware acceleration. This will make battery life worse. Reconsider.
You need to log in before you can comment on or make changes to this bug.