Closed Bug 843273 Opened 11 years ago Closed 11 years ago

Graphics driver block request: Intel driver <= 8.15.10.2302/HD Graphics for Direct2D on Windows 7

Categories

(Core :: Graphics, defect)

19 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla22
Tracking Status
firefox20 + fixed
firefox21 + fixed
firefox22 --- fixed
firefox23 --- verified

People

(Reporter: scoobidiver, Assigned: bjacob)

References

(Blocks 1 open bug)

Details

(Whiteboard: [gfx])

Attachments

(2 files)

OS: WINNT 6.1
Vendor:  0x8086
Devices: 0x0046
Feature: DIRECT2D
Feature status: BLOCKED_DRIVER_VERSION
Driver version: 8.15.10.2302
Driver version comparator: LESS_THAN_OR_EQUAL

Homepage and other references and contact info: 

Reasons: bug 806786
Benoit - would you be comfortable pushing out a remote blocklist in support of top crasher bug 806786? I ask from the perspective of both risk (we could alternatively do this as an in-product block) and impact (does the gfx community have a good way of identifying the usage of a specific vendor/device?).
Flags: needinfo?(bjacob)
Assignee: nobody → bjacob
ni? -> milan
Flags: needinfo?(bjacob) → needinfo?(milan)
Sorry for the long delay.

Since this rule doesn't involve any recently added field or value (these have all been around since Firefox 4) this should be safe to push through the downloadable blacklist.

But only do that if that has some urgency, as otherwise the built-in blacklist works too and is less risky to use.
Clearing the Need Info flag as Benoit answered in comment 3.

(In reply to Benoit Jacob [:bjacob] from comment #3)
> But only do that if that has some urgency
It has as crashes spiked in 19.0 and are now #14 top browser crasher.
Flags: needinfo?(milan)
The block has been staged, in case we want to pursue this.
(In reply to Benoit Jacob [:bjacob] from comment #3)

> But only do that if that has some urgency, as otherwise the built-in
> blacklist works too and is less risky to use.

Benoit can you prepare this patch and get it landed on trunk & nominated for beta/aurora before Tues Mar 12th when we build beta 4?
Attachment #721873 - Flags: review?(joe) → review+
Comment on attachment 721873 [details] [diff] [review]
block d2d on intel hd on old enough drivers

[Approval Request Comment]
Bug caused by (feature/regressing bug #): driver bug, not a regression for all I know
User impact if declined: bug 806786, topcrasher on Windows
Testing completed (on m-c, etc.): inbound just now
Risk to taking this patch (and alternatives if risky): very low risk: simple compiled-in blacklist edit. green on try.
String or UUID changes made by this patch: none
Attachment #721873 - Flags: approval-mozilla-beta?
Attachment #721873 - Flags: approval-mozilla-aurora?
Comment on attachment 721873 [details] [diff] [review]
block d2d on intel hd on old enough drivers

Approving for beta/aurora so this can get uplifted first thing tomorrow morning assuming the merge to central will have been done.
Attachment #721873 - Flags: approval-mozilla-beta?
Attachment #721873 - Flags: approval-mozilla-beta+
Attachment #721873 - Flags: approval-mozilla-aurora?
Attachment #721873 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/mozilla-central/rev/2d4a7e7ca118
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Looks like this missed QA on staging/try. Flagging for verification now that it is live.
Keywords: verifyme
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #13)
> Looks like this missed QA on staging/try. Flagging for verification now that
> it is live.

Just to confirm, these drivers should be blocked out-of-the-box with a new Firefox install, right? In other words I don't need to ping the production AMO blocklist?
Component: Blocklisting → Graphics
Product: addons.mozilla.org → Core
Target Milestone: --- → mozilla22
Version: unspecified → 19 Branch
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #14)
> (In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #13)
> > Looks like this missed QA on staging/try. Flagging for verification now that
> > it is live.
> 
> Just to confirm, these drivers should be blocked out-of-the-box with a new
> Firefox install, right? In other words I don't need to ping the production
> AMO blocklist?

What happened is we decided to go for the builtin blacklist here instead of the downloadable one.
Thanks for clarifying, Benoit.

Paul, can you please verify this blocklist is working correctly? Direct2D on Windows 7 should be blocked upon installation of Firefox 20.0b5, 21.0a2, and 22.0a1 with Intel GPU driver <= 8.15.10.2302.

Thanks
QA Contact: paul.silaghi
I only found an Intel G41 GPU machine and it's not blocked on FF 20b5, 	21.0a2 (2013-03-18), 22.0a1 (2013-03-18) Win 7 x86:

Adapter Description: Intel(R) G41 Express Chipset
Adapter Drivers: igdumdx32 igd10umd32
Adapter RAM: Unknown
Device ID: 0x2e32
Direct2D Enabled: true
DirectWrite Enabled: true (6.2.9200.16492)
Driver Date: 2-11-2011
Driver Version: 8.15.10.2302
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 10
Vendor ID: 0x8086
WebGL Renderer: Google Inc. -- ANGLE (Intel(R) G41 Express Chipset)
AzureCanvasBackend: direct2d
AzureContentBackend: direct2d
AzureFallbackCanvasBackend: cairo
The device ID in comment 18 is 0x2e32 ("G41 Express Chipset"). My patch only blocks device 0x0046 ("Mobile HD graphics") according to what was asked for in comment 0. If people feel that other devices such as 0x2e32 should be blocked too I can make a patch.
I finally found an Intel HD 3000 GPU machine, but there is no way I could find a driver version <= 8.15.10.2302 to download.
(In reply to Paul Silaghi [QA] from comment #20)
> I finally found an Intel HD 3000 GPU machine, but there is no way I could
> find a driver version <= 8.15.10.2302 to download.

Can you at least confirm the blocklist.xml in your installation directory has the correct blocklist information? If you can at least confirm that I think we'll have to call this verified based on trust.
(In reply to Paul Silaghi [QA] from comment #20)
> I finally found an Intel HD 3000 GPU machine, but there is no way I could
> find a driver version <= 8.15.10.2302 to download.
You can spoof your graphics version with MOZ_GFX_SPOOF_DRIVER_VERSION (see bug 604771).

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #21)
> Can you at least confirm the blocklist.xml in your installation directory
> has the correct blocklist information?
It's not a downloaded graphics blocklist but a compiled-in one.
(In reply to Scoobidiver from comment #22)
> (In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #21)
> > Can you at least confirm the blocklist.xml in your installation directory
> > has the correct blocklist information?
> It's not a downloaded graphics blocklist but a compiled-in one.

Yes, which is why I stated "blocklist.xml in your installation directory". It is my understanding the pre-compiled blocklist exists in the installation directory whereas downloaded blocklists exist in your profile directory. Is this not correct?
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #23)
> Is this not correct?
No. The compiled-in blocklist is in the code. The difference between blocklist.xml in the installation directory and profile is caused by new blocklists (add-on or graphics) that have been added since the latest installation.
(In reply to Scoobidiver from comment #24)
> (In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #23)
> > Is this not correct?
> No. The compiled-in blocklist is in the code. The difference between
> blocklist.xml in the installation directory and profile is caused by new
> blocklists (add-on or graphics) that have been added since the latest
> installation.

Indeed.  There is really no good way to test this without having the setup that is being blacklisted.
(In reply to Milan Sreckovic [:milan] from comment #25)
> (In reply to Scoobidiver from comment #24)
> > (In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #23)
> > > Is this not correct?
> > No. The compiled-in blocklist is in the code. The difference between
> > blocklist.xml in the installation directory and profile is caused by new
> > blocklists (add-on or graphics) that have been added since the latest
> > installation.
> 
> Indeed.  There is really no good way to test this without having the setup
> that is being blacklisted.

We have the hardware but can't seem to find the drivers. Intel certainly does not make them easy to find. I've tried googling for old driver installers but haven't been able to find one that works. As such I don't think we'll be able to verify this is working as expected. 

I think we should keep tracking this and monitor feedback channels once Firefox 20 is released.
Keywords: verifyme
Whiteboard: [gfx] → [gfx][qa-]
Please use the spoofing as stated in comment 22.
Keywords: verifyme
Whiteboard: [gfx][qa-] → [gfx]
(In reply to Scoobidiver from comment #27)
> Please use the spoofing as stated in comment 22.

Paul can you give this one last try with the spoofing in comment 22?
I've tested this with an Intel HD 2500 GPU.
Original values:
Device ID: 0x0152
Driver Version: 9.17.10.2867

Spoofing the device id and the driver version:
Adapter Description: Intel(R) HD Graphics
Adapter Drivers: sigdumd64 igd10umd64 igd10umd64 igdumd32 igd10umd32 igd10umd32
Adapter RAM: Unknown
Device ID: 0x0046
Direct2D Enabled: Blocked for your graphics driver version.
DirectWrite Enabled: false (6.1.7601.17789)
Driver Date: 9-26-2012
Driver Version: 9.17.10.2866
GPU #2 Active: false
GPU Accelerated Windows: 0/1 Basic
Vendor ID: 0x8086
WebGL Renderer: Google Inc. -- ANGLE (Intel(R) HD Graphics)
AzureCanvasBackend: cairo
AzureContentBackend: none
AzureFallbackCanvasBackend: none

Conclusion: Everything < than the current driver version is blocked.
(In reply to Paul Silaghi [QA] from comment #29)
> Driver Version: 9.17.10.2866
This version number is higher than 8.15.10.2302. It shouldn't have been blocked.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I've also tested that method with a .bat in the installation folder and I can confirm any Intel device IDs are blocked for any versions except for my current version (8.15.10.2869).

For NVIDIA and ATI, there's no issue. I was able to determine the version threshold (8.17.12.5721 for NVIDIA and 8.741.0.0 for ATI) by spoofing.
Does the broken Intel spoofing highlight an issue with Intel blocklisting?
Flags: needinfo?(bjacob)
Paul, can you spoof it (8.15.10.2302 and 8.15.10.2303 - see https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers#How_to_force-enable_blocked_graphics_features) on a computer with a NVIDIA or AMD GPU as spoofing your own vendor ID doesn't work?
Tested on a Win 7 x64 machine, Nvidia 210 GPU.
The original driver version is 9.18.13.1070.
It is not blocked if I spoof it to 9.18.13.1069. So, the wrong behavior in comment 29 doesn't apply here.
Paul, on that machine, you need to spoof the vendor and device IDs (0x8086 and 0x0046) and set the version to 8.15.10.2302 (blocked) then 8.15.10.2303 (not blocked) to verify this bug.
Sorry, I am a bit lost, lots of information here :-)

I re-read the patch and I can't make sense of the fact that it would not work as expected. 

However I wonder if we might be getting hit by the trickiness of the gfx.blacklist preferences here. These prefs are used to cache blacklisting decisions, and they might be causing us trouble here.

Could you please check that gfx.blacklist preferences are not set (if they are, reset them) and retry?
Flags: needinfo?(bjacob)
(In reply to Benoit Jacob [:bjacob] from comment #36)
> Could you please check that gfx.blacklist preferences are not set (if they
> are, reset them) and retry?
It was with a new profile. If I set SET MOZ_GFX_SPOOF_VENDOR_ID=0x8086 or I don't declare it, the result is the same, Direct2D is blocked except when MOZ_GFX_SPOOF_DRIVER_VERSION matches my current version.

Let's wait Paul's result and if it's OK I'll file a bug about spoofing your own vendor ID.
Flags: needinfo?(paul.silaghi)
Ouch. Thanks Scoobidiver, I understand a bit better now... so I reread the code where we spoof driver versions, and it's BEFORE we do a special Intel-specific check that overrides it. The attached patch fixes it. Sorry for the wasted time.
Attachment #728653 - Flags: review?(joe)
Attachment #728653 - Flags: review?(joe) → review+
So the bug is fixed and the new patch will help verifying it in m-c.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
(In reply to Scoobidiver from comment #39)
> So the bug is fixed and the new patch will help verifying it in m-c.

(In reply to Scoobidiver from comment #35)
> Paul, on that machine, you need to spoof the vendor and device IDs (0x8086
> and 0x0046) and set the version to 8.15.10.2302 (blocked) then 8.15.10.2303
> (not blocked) to verify this bug.
Still doesn't seem to work properly. All versions are blocked now after spoofing the vendor id, device id and driver version. Tested on nightly 2013-03-24.
Flags: needinfo?(paul.silaghi)
Benoit, can you land the spoofing patch?
Flags: needinfo?(bjacob)
In 23.0a1/20130408, it's blocked for 8.15.10.2302:
Device ID	0x0046
Direct2D Enabled	Blocked for your graphics driver version.
DirectWrite Enabled	false (6.2.9200.16492)
Driver Version	8.15.10.2302
GPU Accelerated Windows	1/1 Direct3D 9
Vendor ID	0x8086
AzureCanvasBackend	skia
AzureContentBackend	none
AzureFallbackCanvasBackend	cairo

and not blocked for 8.15.10.2303:
Device ID	0x0046
Direct2D Enabled	true
DirectWrite Enabled	true (6.2.9200.16492)
Driver Version	8.15.10.2303
GPU Accelerated Windows	1/1 Direct3D 10
Vendor ID	0x8086
AzureCanvasBackend	direct2d
AzureContentBackend	direct2d
AzureFallbackCanvasBackend	cairo
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: