[e10s] + Optimus (NVidia) crash in [ nvwgf2um.dll@0x134a04 ] [@ CShaderResourceView::CLS::FinalConstruct(CContext *,CShaderResourceView::TConstructorArgs const *) ]

VERIFIED FIXED in mozilla34

Status

()

defect
--
critical
VERIFIED FIXED
5 years ago
3 years ago

People

(Reporter: xtc4uall, Assigned: handyman, NeedInfo)

Tracking

(Depends on 1 bug, {crash})

Trunk
mozilla34
x86
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s?)

Details

(crash signature)

Attachments

(2 attachments, 5 obsolete attachments)

This bug was filed from the Socorro interface and is 
report bp-7ec03cf0-e5fe-4154-9297-17a3d2140511.
=============================================================

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 ID:20140511030203 CSet: 20ca234fd62b

On my Optimus Notebook with Intel HD (1st generation) + NVidia 310M there's a start-up crash when Firefox is run against the NVidia GPU.

Against the Intel GPU is WFM.

Also happens if a standard/non-e10s enabled Firefox profile is run against the NVidia GPU & a new Window using "New e10s Windows" is opened -> instant crash as above.

FWIW, running the NVidia GPU against an only-OMTC enabled profile is also WFM.

Adapter Description: Intel(R) HD Graphics
Adapter Description (GPU #2): NVIDIA GeForce 310M
Adapter Drivers: igdumd64 igd10umd64 igdumdx32 igd10umd32
Adapter Drivers (GPU #2): nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Adapter RAM: Unknown
Adapter RAM (GPU #2): 512
ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 300
Device ID: 0x0046
Device ID (GPU #2): 0x0a70
Direct2D Enabled: true
DirectWrite Enabled: true (6.2.9200.16571)
Driver Date: 1-30-2013
Driver Date (GPU #2): 3-4-2014
Driver Version: 8.15.10.2993
Driver Version (GPU #2): 9.18.13.3523
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 10
Vendor ID: 0x8086
Vendor ID (GPU #2): 0x10de
WebGL Renderer: NVIDIA Corporation -- GeForce 310M/PCIe/SSE2
windowLayerManagerRemote: false
AzureCanvasBackend: direct2d
AzureContentBackend: direct2d
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0
Assignee: nobody → davidparks21
Posted patch WIP some issues with Cairo (obsolete) — Splinter Review
Assignee: davidparks21 → davidp99
Attachment #8427428 - Attachment is obsolete: true
Flags: needinfo?(wmccloskey)
Flags: needinfo?(xtc4uall)
No idea why you NI'ed me, but I applied attachment 8427439 [details] [diff] [review] locally (hopefully the correct way) against http://hg.mozilla.org/integration/mozilla-inbound/rev/e91fc820b8c3 and a build with it doesn't fix the crash (bp-1b353ac5-6cac-425b-b854-3e41a2140523) :-/

Maybe you can provide a Win32 Opt Try Build just to be sure?
Flags: needinfo?(xtc4uall) → needinfo?(davidp99)
I must have not hit Save Changes when I wrote my previous comment.  I was in fact going to ask you to try the patch -- it was a long shot.  If you are game for running builds on that machine then I may need your help again (I don't have a machine with this card).

Here's a link to the try build.  If you can run the debug, that would be even better (the debug info in your attachments is wrecked by the crash):

* Debug build: https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/wmccloskey@mozilla.com-1f1ae3c1f9a2/try-win32-debug/firefox-32.0a1.en-US.win32.installer.exe

* Release build: https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/wmccloskey@mozilla.com-1f1ae3c1f9a2/try-win32/firefox-32.0a1.en-US.win32.installer.exe

Thanks!
Flags: needinfo?(davidp99)
Debug build console output:
###!!! [Child][MessageChannel::SendAndWait] Error: Channel error: cannot send/recv
[Child 1848] WARNING: failed to forward Layers transaction: file c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\gfx\layers\client/ClientLayerManager.cpp, line 481
###!!! [Child][OnMaybeDequeueOne] Error: Channel error: cannot send/recv
###!!! [Child][MessageChannel] Error: Channel error: cannot send/recv
[Child 1848] WARNING: content process _exit()ing: file c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/dom/ipc/ContentChild.cpp, line 1428

the release build crashed equally as my local build.
http://www.geforce.com/whats-new/articles/nvidia-geforce-337-88-whql-watch-dog-drivers

Can you please install the latest 337.88 beta drivers and see if it helps?
(In reply to NVD from comment #6)
> Can you please install the latest 337.88 beta drivers and see if it helps?

It's actually not a beta but final driver.
Well, made no difference apart of shifting NVidia's driver adress when crashing.
Crash Signature: [@ nvwgf2um.dll@0x134a04] [@ CShaderResourceView::CLS::FinalConstruct(CContext *,CShaderResourceView::TConstructorArgs const *) ] → [@ nvwgf2um.dll@0x134a04] [@ nvwgf2um.dll@0x26d141] [@ CShaderResourceView::CLS::FinalConstruct(CContext *,CShaderResourceView::TConstructorArgs const *) ]
Thanks Xtc4uall for trying the builds.  I've got a few more ideas on this bug but not the hardware to test on.  This is a huge help.


This graphics card's DX11 drivers are notoriously bad.  Many times, the solution is to run DX9 versions of applications.  It would appear that this is how the World of Warcraft folks have gone at the problem: 
http://us.battle.net/wow/en/forum/topic/9793040694?page=1

Randomly, this old thread suggests issues since version 306.97:
https://forums.geforce.com/default/topic/528454/geforce-drivers/dx10-11-games-crashing-nvwgf2um-dll/

But I've got another line of thought.  Here are a collection of bugs related to the same spot in the same internal driver function (nvwgf2um.dll@0x134a04):
https://crash-stats.mozilla.com/report/list?product=Firefox&signature=nvwgf2um.dll%400x134a04#tab-reports

These call stacks aren't trashed by the crash.  Its definitely not certain that they are related.  But they all seem to have the same issue here:
http://hg.mozilla.org/releases/mozilla-beta/annotate/f572a9d3afc8/gfx/layers/d3d10/ImageLayerD3D10.cpp#l160

My focus is on the GetData call in the conditional above the block:
http://hg.mozilla.org/releases/mozilla-beta/annotate/f572a9d3afc8/gfx/layers/d3d10/ImageLayerD3D10.cpp#l147

The GetData call is supposed to synchronize graphics objects across processes.  But it doesn't necessarily do that.  The suspect part of the function is here:
http://dxr.mozilla.org/mozilla-central/source/gfx/layers/D3D9SurfaceImage.cpp#93

and the suspect part is obvious:
>   int iterations = 0;
>   while (iterations < 10 && S_FALSE == mQuery->GetData(nullptr, 0, D3DGETDATA_FLUSH)) {
>     Sleep(1);
>     iterations++;
>   }

The code spins while it waits for DirectX to finish sync across processes.  This is explained as 'borrowed from Chromium' starting with the thread here:
https://bugzilla.mozilla.org/show_bug.cgi?id=847267#c16

Its clear that the drivers for this card are bad but I'd like to check to see if the issue is something this basic (and general, as the list of related crashes seems large) before blacklisting the card to DX9.  This means getting input from cpearce and Bas.  But today I'm on holiday...
Status: NEW → ASSIGNED
> My focus is on the GetData call in the conditional above the block:
> http://hg.mozilla.org/releases/mozilla-beta/annotate/f572a9d3afc8/gfx/layers/
> d3d10/ImageLayerD3D10.cpp#l147

Update: That should have said "the GetShareHandle() call" a few lines beneath that:
http://hg.mozilla.org/releases/mozilla-beta/annotate/f572a9d3afc8/gfx/layers/d3d10/ImageLayerD3D10.cpp#l152
http://www.geforce.com/hardware/notebook-gpus/geforce-310m/specifications

310M is a DX10/OGL3 class hardware, not even sure why you're refering to DX11, it can't run DX11 apps at all.

Also Nvidia will end driver updates for their DX10 class hardware with Release 340 drivers on April 1, 2016.

http://nvidia.custhelp.com/app/answers/detail/a_id/3473
XTC4uall, if you are still up for it, I've got another build I'd like you to try.  It'll simply log a message if the condition we want to test for actually happens.  The build is here:

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/davidp99@gmail.com-5bb5f224b74a/try-win32/firefox-32.0a1.en-US.win32.installer.exe

Now, in order to see the log message, you'll need an app from Microsoft called DebugView that shows debug messages:
http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx

There isn't much to doing this but there are a few things to know:
* First, run DebugView as administrator (right-click and choose "Run as administrator")
* Make sure that the following "Capture" sub-menu items are checked: "Capture Win32", "Capture Global Win32", "Capture Kernel", "Pass-thru" and "Capture Events".  (Most of these will already be checked)
* Then, launch firefox and make it crash.
* "Save" the contents of the output to a file and add that file as an attachment to this bug. 

FYI, when the synchronization of the buffer fails, we expect to see a message like this in the output:

[e10s] ERROR: D3D9 surface was not synchronized

Thanks again!
Flags: needinfo?(xtc4uall)
(In reply to David Parks [:handyman] from comment #12)

Tried above and got no output at all when crashing.
DebugView itself works though since it logs output of the Google Update service - so it's not an issue with DebugView's config.
Flags: needinfo?(xtc4uall) → needinfo?(davidp99)
Thanks for your help, XTC4uall.  This concludes the random guessing portion of the bug fixing.  

I'm going to propose that we either pick up a machine with this card for debugging or we blacklist this card to use the soft compositor.
Flags: needinfo?(davidp99)
We can do both. Black list for now and file a follow up bug to investigate further.
Flags: needinfo?(wmccloskey)
Posted patch nv310m-reject.patch (obsolete) — Splinter Review
Put NV310M on D2D blacklist
Hi XTC4uall,
I've made a build that should put this card on the Direct2D blacklist.  Would you mind running the build to report back if it works on the NV310M:

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/davidp99@gmail.com-0a1c42e394d4/try-win32/firefox-32.0a1.en-US.win32.installer.exe

Because I think this may be a symptom of a bigger issue, I'm also going to file a new bug as suggested in comment 15.  Would you be open to helping with a little additional experimentation in the future?
Flags: needinfo?(xtc4uall)
See Also: → 1018438
(In reply to David Parks [:handyman] from comment #18)

I was about building locally when I saw you patch posted ;-)
Unfortunately the blocklist does not work for some reason. Maybe because of Bug 628129 & Co?

> Would you be open to helping
> with a little additional experimentation in the future?

Definitely :-)
Flags: needinfo?(xtc4uall) → needinfo?(davidp99)
(In reply to XtC4UaLL [:xtc4uall] from comment #19)
> 
> Maybe because of Bug 628129 & Co?
> 

Could be.  The crash log reports the correct (NVidia) card as the 'second' adapter and the Intel as the first.  I guess this means that the blocklist test only checks the Intel.  However, the ids are not mixed up as described in most of the bug comments.  Still, this is a likely culprit.
Flags: needinfo?(davidp99)
Nvidia released GeForce 340.43 beta drivers, could you install and test?

http://www.nvidia.com/download/driverResults.aspx/76512/en-us
Hi XtC4UaLL, would you mind trying out this build:

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/davidp99@gmail.com-0bfbf213f519/try-win32/firefox-32.0a1.en-US.win32.installer.exe

It's another attempt to blocklist D2D on the NVidia 310M in this configuration.  In theory, it should run fine on that machine.
Flags: needinfo?(xtc4uall)
(In reply to David Parks [:handyman] from comment #22)

a) The D2D blocklisting unfortunately works against *both* GPUs, i.e. even when explicitly running Firefox against the Intel GPU :-/.

Adapter Description: Intel(R) HD Graphics
Adapter Description (GPU #2): NVIDIA GeForce 310M
Adapter Drivers: igdumd64 igd10umd64 igdumdx32 igd10umd32
Adapter Drivers (GPU #2): nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Adapter RAM: Unknown
Adapter RAM (GPU #2): 512
ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 300
Device ID: 0x0046
Device ID (GPU #2): 0x0a70
Direct2D Enabled: Blocked for your graphics card because of unresolved driver issues.
DirectWrite Enabled: false (6.2.9200.16571)
Driver Date: 1-30-2013
Driver Date (GPU #2): 6-12-2014
Driver Version: 8.15.10.2993
Driver Version (GPU #2): 9.18.13.4043
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Vendor ID: 0x8086
Vendor ID (GPU #2): 0x10de
WebGL Renderer: Google Inc. -- ANGLE (Intel(R) HD Graphics Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote: true
AzureCanvasBackend: skia
AzureContentBackend: cairo
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0

b) the crashing stack changed reproducibly since upgrading the NVidia driver to 340.43 beta:
bp-0e33dc5c-2792-4f1d-891c-a30222140624 [@ InterlockedDecrement ]
Flags: needinfo?(xtc4uall)
Hmm... Looks like I need to work on the fallback mechanism.  I'll take another look and get back to you.
XTC4uall,

I've got another build for you to try:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/davidp99@gmail.com-6d0bc8501e42/try-win32/firefox-34.0a1.en-US.win32.installer.exe

We try to be more aggressive in differentiating between the two cards so that the blocklisting is properly applied.  Let me know how it goes.  Thanks again!
Flags: needinfo?(xtc4uall)
Blocklist ist unfortunatelly still not working and thus crashing in e10s mode.

bp-aed0d10a-88d0-43ba-9354-64f082140726 [@ nvwgf2um.dll@0xd5de2 ]
bp-2e62f1cd-07b0-4bd3-b3f0-c34772140726 [@ InterlockedDecrement ]

current about:support output when ran against the NVidia GPU in non-e10s mode:

Adapter Description: Intel(R) HD Graphics
Adapter Description (GPU #2): NVIDIA GeForce 310M
Adapter Drivers: igdumd64 igd10umd64 igdumdx32 igd10umd32
Adapter Drivers (GPU #2): nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Adapter RAM: Unknown
Adapter RAM (GPU #2): 512
ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 300
Device ID: 0x0046
Device ID (GPU #2): 0x0a70
Direct2D Enabled: true
DirectWrite Enabled: true (6.2.9200.16571)
Driver Date: 1-30-2013
Driver Date (GPU #2): 6-12-2014
Driver Version: 8.15.10.2993
Driver Version (GPU #2): 9.18.13.4043
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Subsys ID: 395717aa
Subsys ID (GPU #2): 396617aa
Vendor ID: 0x8086
Vendor ID (GPU #2): 0x10de
WebGL Renderer: Google Inc. -- ANGLE (Intel(R) HD Graphics Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d
AzureContentBackend: direct2d
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0
Flags: needinfo?(xtc4uall)
Thanks XTC4uall.  I was afraid of that.

I'm going to advocate that, for the moment, we go with the patch that made the previous build you tested -- that blocked D2D regardless of the card you selected.  We'll need to switch mechanisms to get this to work properly.  To be clear, XTC4uall, the build you were talking about in comment 23 did *run* ok, right?  The only issue was that it used software rendering for D2D?  For now, I think we can accept that.

Code details on the future of the implementation:
I'm recommending that we re-implement the windows GfxInfo code to use DirectX instead of the old GDI stuff we are using, which is known to fail... a lot (search StackOverflow for "EnumDisplayDevices").  In fact, its only reporting one of the graphics cards on my machine, regardless of which I actually run with.  DirectX is more likely to return the correct values.  The function we want is IDXGIFactory::EnumAdapters:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb174538%28v=vs.85%29.aspx
Flags: needinfo?(xtc4uall)
(In reply to David Parks [:handyman] from comment #28)
> To be clear, XTC4uall, the build you were talking about in comment 23 did *run*
> ok, right?  The only issue was that it used software rendering for D2D?

Yep, that one ran crash-less against both GPUs in e10s mode.

I'm still wondering why there hasn't been more reports of nightly users testing e10s and having Optimus systems - I doubt I'm the only one ;-)
Does QA have such boxes?
Probably other than the 310m are also affected.
Flags: needinfo?(xtc4uall)
I'm pretty sure you're right about there being more affected systems but its commonly the case that some driver/hardware combinations behave much worse than others.  The only thing we can do is confront the bad ones as they come in.  Looking at crash reports, I agree that this isn't unique.  Blocking D2D whenever we get a whiff of the card is a sledgehammer, which works, but a rewrite to use DX would be much more surgical (and, since everything uses DX these days, its likely to have fewer bugs).

Thanks again.  I'll ping you when I post a redo of the prior 'working' build soon for you to try and re-confirm.
The patch.

XTC4uall, can you take a look at this build and confirm that it still blocks D2D on both GPUs?

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/davidp99@gmail.com-638309dea34d/try-win32/firefox-33.0a1.en-US.win32.installer.exe
Attachment #8431851 - Attachment is obsolete: true
Flags: needinfo?(xtc4uall)
Blocklisting works as intended testing against both GPUs.

about:support output of NVidia GPU in e10s mode:
Adapter Description: Intel(R) HD Graphics
Adapter Description (GPU #2): NVIDIA GeForce 310M
Adapter Drivers: igdumd64 igd10umd64 igdumdx32 igd10umd32
Adapter Drivers (GPU #2): nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Adapter RAM: Unknown
Adapter RAM (GPU #2): 512
ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 300
Device ID: 0x0046
Device ID (GPU #2): 0x0a70
Direct2D Enabled: Blocked for your graphics card because of unresolved driver issues.
DirectWrite Enabled: false (6.2.9200.16571)
Driver Date: 1-30-2013
Driver Date (GPU #2): 6-12-2014
Driver Version: 8.15.10.2993
Driver Version (GPU #2): 9.18.13.4043
GPU #2 Active: false
GPU Accelerated Windows: 2/2 Direct3D 11 (OMTC)
Vendor ID: 0x8086
Vendor ID (GPU #2): 0x10de
WebGL Renderer: Google Inc. -- ANGLE (Intel(R) HD Graphics Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote: true
AzureCanvasBackend: skia
AzureContentBackend: cairo
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0
Flags: needinfo?(xtc4uall)
Fantastic.  Big thanks for sticking with me while we worked through this.  Now, I've just got to finalize it.
http://www.geforce.com/whats-new/articles/nvidia-geforce-340-52-whql-driver

Last driver series for D3D10 class GPUs, R343 & later drivers onwards will only support D3D11 class GPUs.
Yeah, that was the wrong file.
Attachment #8463206 - Attachment is obsolete: true
Comment on attachment 8427439 [details] [diff] [review]
Fix for some Cairo bugs that would cause weird crashes.

Setting Bas for review (to reassign as he pleases).

A note-to-self on the next steps: 
blassey has suggested that I drop a line to release-drivers at mozilla.org when altering blocklisting behavior.  They monitor for unexpected consequences.
Attachment #8427439 - Flags: review?(bas)
Attachment #8464141 - Flags: review?(bas)
Latest Aurora 33.a2

Hello, I have been experiencing similar problems (such as crash when I attempt to start Aurora) along with "flickering" while watching youtube videos followed by a crash. The problem recently started around when I updated to Aurora 33.
I have an Nvidia GeForce GT 740M and an Intel(R) HD Graphics 4000. I'm currently using the Intel GPU for Aurora as of now and WFM.
Comment on attachment 8464141 [details] [diff] [review]
Reject D2D when NV310M is primary or secondary adapter

Review of attachment 8464141 [details] [diff] [review]:
-----------------------------------------------------------------

Bjacob knows this code a lot better, I don't feel comfortable saying for sure this will work.
Attachment #8464141 - Flags: review?(bas) → review?(bjacob)
Comment on attachment 8427439 [details] [diff] [review]
Fix for some Cairo bugs that would cause weird crashes.

Review of attachment 8427439 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/cairo/cairo/src/cairo-d2d-surface.cpp
@@ +271,5 @@
>  							&device->mTextTextureView);
>  
>      return &device->base;
>  FAILED:
> +    delete device;

This change should make no difference. But since it makes no difference, I don't really mind either :).
Attachment #8427439 - Flags: review?(bas) → review+
This isn't my code either, I just happen to have been suckered more often into it :-)

One design question about this review:
if we need this, that seems to mean that our detection of which GPU we're using (in dual-GPU systems) is unreliable; but then, doesn't that imply that we should check _all_ blocklist rules against both GPUs? That would allow to avoid some special-casing here.
Flags: needinfo?(davidp99)
The idea behind the special handling for this GPU combo (which is indeed a strange thing to do) was that we wanted to limit the scope of the change to avoid surprises.  Its a short-term 'fix' for M1.  For sure, a more grand scheme is in order -- check comment 28 for the future plan.  Always blocking based on the secondary GPU would change the behavior for many configurations we've already tested so it was seen as much more of a risk in the short-term.  It would also unnecessarily dump a lot of machines off onto the software renderer.  Even the 'more likely to be correct' DirectX solution would change the behavior for so many people that we wanted to postpone it.
Flags: needinfo?(davidp99)
Flags: needinfo?(bjacob)
Ah. If this is a minimal/temporary fix, then, instead of introducing new fields in existing structs, you could go even much more minimal and non-intrusive and just hack a 3-line patch directly to GetFeatureStatus or GetFeatureStatusImpl? Interested in your thoughts on that.
Flags: needinfo?(bjacob) → needinfo?(davidp99)
I was torn between short and hacky or larger and slightly more organized -- Im good either way.  But this is a much more localized solution.

Try build results:
https://tbpl.mozilla.org/?tree=Try&rev=192211e630a2

If it looks good, I'll ask XTC4uall to check out the build when its ready.
Attachment #8464141 - Attachment is obsolete: true
Attachment #8464141 - Flags: review?(bjacob)
Attachment #8471124 - Flags: review?(bjacob)
Flags: needinfo?(davidp99)
Hi XTC4uall,

To be thorough, would you mind running a quick check of this new patch?  

The build is here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/davidp99@gmail.com-192211e630a2/try-win32/firefox-34.0a1.en-US.win32.installer.exe

Expected behavior:
Same as before -- D2D blocked on that machine when run using either graphics card.

Thanks again for the assist.
Flags: needinfo?(xtc4uall)
(In reply to David Parks [:handyman] from comment #46)

Blocklisting does not work with that one - on neither GPUs.
Flags: needinfo?(xtc4uall) → needinfo?(davidp99)
Comment on attachment 8471124 [details] [diff] [review]
Reject D2D when NV310M is primary or secondary adapter

Review of attachment 8471124 [details] [diff] [review]:
-----------------------------------------------------------------

R+ as I don't see why this doesn't work, but obviously Xtc4uall's comment 47 has to be investigated before this can land.

As long as you know the exact strings on Xtc4uall's machine (from his about:support) you should probably be able to reproduce by spoofing strings on your machine.

(In reply to David Parks [:handyman] from comment #45)
> Created attachment 8471124 [details] [diff] [review]
> Reject D2D when NV310M is primary or secondary adapter
> 
> I was torn between short and hacky or larger and slightly more organized --
> Im good either way.  But this is a much more localized solution.

Yeah, more localized is why I prefer this - as long as this works - as a short term solution, especially if the long-term solution is going to be different anyway.

Thanks though for the previous, more elaborate patch, it was a "good citizen" approach, and we'll take it if it's too much work to figure why this one doesn't block correctly Xtc4uall's machine.
Attachment #8471124 - Flags: review?(bjacob) → review+
Thanks both.  I think the issue was minor -- lets see if we can't finish this.

XTC4uall, here's a new build for you, based on the new patch:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/davidp99@gmail.com-0eca6513a0ca/try-win32/firefox-34.0a1.en-US.win32.installer.exe

Can you run the same experiment?
Attachment #8471124 - Attachment is obsolete: true
Flags: needinfo?(davidp99) → needinfo?(xtc4uall)
(In reply to David Parks [:handyman] from comment #49)
That one works and both GPUs are blocked for D2D.
Flags: needinfo?(xtc4uall) → needinfo?(davidp99)
> That one works and both GPUs are blocked for D2D.

Good news, thanks.  It looks like we're set.

Try build results here:
https://tbpl.mozilla.org/?tree=Try&rev=0eca6513a0ca
Flags: needinfo?(davidp99)
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/9c339e14c720
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Depends on: 1054729
Removing dep since the real cause of bug 1054729 is bug 1035227. this only exposed it.
while i'm at it verifying fixed this.
Status: RESOLVED → VERIFIED
No longer depends on: 1054729
Depends on: 1056116
Why is the Intel-GPU being blocked from HWA to fix a crash with the nVidia-GPU, although Firefox is set by the driver to NOT use the nVidia-GPU by default?
Flags: needinfo?(davidp99)
You need to log in before you can comment on or make changes to this bug.