Closed Bug 722538 Opened 8 years ago Closed 8 years ago

block AMD Radeon HD 6290/6300/6310/6320 for DIRECT2D

Categories

(Toolkit :: Blocklist Policy Requests, defect)

x86
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
Tracking Status
firefox10 + ---
firefox12 - ---

People

(Reporter: jbecerra, Assigned: jorgev)

References

(Depends on 1 open bug, Blocks 5 open bugs)

Details

(Whiteboard: [gfx])

Attachments

(2 files)

We'd like to remote blacklist some AMD Radeon cards according to: https://bugzilla.mozilla.org/show_bug.cgi?id=700288#c15

These are involved in the #3 top crash in Firefox 10.b6. We are about to ship Fx10 tomorrow, January 31.

I don't know how to define what exactly to block, but the comment points to several graphics cards in the 6xxx range with a driver up to 8.92
We need someone (kairo?) to enumerate the affected video cards and driver versions by looking at the crash reports. All of this information is available in the crash reports themselves.
Blocks: 700288
Assignee: nobody → joe
Kairo, you will be online earlier than any of us. Can you get this info together for Joe?
OS: Mac OS X → Windows 7
Here's an early first cut at data for all the bugs in the dependency, I see that we need to improve on that some more.
Still, this data seems to show that it's not all the same vendor in all those crashes and that driver 8.93 even still shows some crashes on some of them :(
OK, here's the vendor/adapter data only for those crash signatures and reports coming in on 2012-01-29 and on version 10.0 - I think it's up to Joe to decide what is reasonable to block based on this, or should someone else decide it actually?
It looks like at least two of those signatures are not really only on those specific chips, so I'm not sure we can base the decision too firmly on those.
Still, it looks to me like the ones to block based on this might be:
AdapterVendorID: 1002, AdapterDeviceID: 9802-9807
I'm OK with blocking these cards, but it looks like it'll be a very coarse block, as kairo has already pointed out that it's happening in all versions up till AMD's very latest:

http://developer.amd.com/download/ccc/pages/default.aspx
The blocklist should be considered as a workaround to let the time to investigate those bugs. Once they are fixed in Firefox, those GPUs should be unblocked.
The crashiest device is Vendor ID 1002, Device ID 9802, which is an AMD Radeon HD 6310, the graphics card in AMD netbook CPUs. Unfortunately these crashes are not _restricted_ to these graphics devices, so it's not a clear open-and-shut case.

It's possible that the devices (CPU/GPU combination) are inherently very crashy. The drivers potentially might corrupt our address space. It's also possible that we have some underlying corruption that these graphics drivers or cards expose.
I have no idea whether I still need to run SQL to insert blocklist entries. I suspect not; Wil Clouser says there's a frontend.

It looks like this only happens on Windows 7 with Direct2D/Direct3D 10. Please correct me if I'm wrong.

What we need blocked:

OS: WINNT 6.1
Vendor: 0x1002
Devices: 0x9802 0x9803 0x9803 0x9804 0x9805 0x9806 0x9807
Feature: DIRECT2D
Reason: BLOCKED_DEVICE

Leave driver version and driver version comparator blank; they should _not_ be output in the blocklist XML.
(This block will block all those devices on all versions of the driver from using Direct2D.)
To help give perspective, here are the crash counts for the last week for each signature, which total up to 2750 (count will be higher because we throttle on beta)

mozilla::gfx::BaseRect<int, nsRect, nsPoint, nsSize, nsMargin>::UnionEdges(nsRect const&) - 1358
nsFrame::DisplayBorderBackgroundOutline(nsDisplayListBuilder*, nsDisplayListSet const&, bool) 336
xul.dll@0xba28d | nsHTMLScrollFrame::PlaceScrollArea(ScrollReflowState const&, nsPoint const&) 9
xul.dll@0xc584d | nsHTMLScrollFrame::PlaceScrollArea(ScrollReflowState const&, nsPoint const&) 238
xul.dll@0xba28d | nsIFrame::GetOverflowRect(nsOverflowType) 31
xul.dll@0xc584d | nsIFrame::GetOverflowRect(nsOverflowType) 681
nsTableRowGroupFrame::ReflowChildren(nsPresContext*, nsHTMLReflowMetrics&, nsRowGroupReflowState&, unsigned int&, bool*) 97

If we want to be conservative, we can wait to see how this signature plays out before doing anything.

In the meantime QA will try to see if one of our vendors has the machine/graphics card Joe notes in Comment 9, or procure one ourselves to do some testing on.
(In reply to Marcia Knous [:marcia] from comment #12)
> To help give perspective, here are the crash counts for the last week for
> each signature, which total up to 2750 (count will be higher because we
> throttle on beta)

Beta is not being throttled, only the Firefox release channel is.
Joe, let us know what you want done here, e.g. block staged on addons-dev or what.
Joe: Would machines with AMD Radeon HD 6310M also qualify to use to test - when doing a search I find both - not sure what the "M" at the end means.
It's easier to tell from the processor. C-30, C-50, C-60, E-240, E-300, E-350, E-450 are all fine. E-240, E-300, or E-350 are probably the best choices since they corresponds to device ID 9802, which most of our crashes are on.
Blocks: 714320
Juan found an Acer machine yesterday in the office, but it didn't have the right Graphics card. I found http://www.amazon.com/HP-Pavilion-Dual-Core-Processor-Discrete-Class/dp/B004IN85QQ/ref=sr_1_8?s=electronics&ie=UTF8&qid=1328121470&sr=1-8 on Amazon that seems to be a good match. Unless I hear otherwise I can have IT order this machine ASAP.
Summary: block AMD Radeon HD 6xxx with driver version up to 8.92 → block AMD Radeon HD 6290/6300/6310/6320 with driver version up to 8.92
Summary: block AMD Radeon HD 6290/6300/6310/6320 with driver version up to 8.92 → block AMD Radeon HD 6290/6300/6310/6320 for DIRECT2D
Blocks: 728533
https://bugzilla.mozilla.org/show_bug.cgi?id=700288#c19 suggests we have access to the machine now and are trying to come up with a repro case.
Joe - do we need a repro case to warrant blocklisting the AMD drivers based upon the number of bugs currently blocked on resolution of this bug? What's the minimum set of info we need to perform a blocklist here?
Blocks: 568487
We don't have to have STR, but it would be nice if we could verify that blocking these devices will actually help us. I'd be willing to do a test with our beta population if we see enough of the crashes there.
(In reply to Joe Drew (:JOEDREW!) from comment #20)
> We don't have to have STR, but it would be nice if we could verify that
> blocking these devices will actually help us. I'd be willing to do a test
> with our beta population if we see enough of the crashes there.

What's the user experience when their video card is blocked? Is it just a perf hit when doing graphics accelerated tasks?

From the query in [1], it does appear that we have enough crashes in bug 728533 alone to notice the difference after blocking. I'd be up for moving forward with a test like this in FF11 beta 5 (go-to-build tomorrow 2/28) if you think this is our best chance at quashing all of the bugs blocked here and the user effect isn't too severe.

[1] https://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A11.0b4&range_value=2&range_unit=weeks&date=02%2F27%2F2012+21%3A29%3A10&query_search=signature&query_type=exact&query=nsIFrame%3A%3ABuildDisplayListForChild%28nsDisplayListBuilder*%2C+nsIFrame*%2C+nsRect+const%26%2C+nsDisplayListSet+const%26%2C+unsigned+int%29&reason=&build_id=&process_type=any&hang_type=any&do_query=1
We procured a machine with the specs in Comment c15 but I was never able to reproduce the crash. If anyone else in Mt. View wants to try the machine is on the standup table and is marked "Radeon."
Tracking because it blocks bug 568487.
Are we going to go ahead and blocklist these. Seems like this will help bug 728533 and bug 568487. Who makes the call on this and who does the blocklisting?
(In reply to Sheila Mooney from comment #24)
> Are we going to go ahead and blocklist these. Seems like this will help bug
> 728533 and bug 568487. Who makes the call on this and who does the
> blocklisting?

My assumption has been that Joe would make the final call. We should move forward with the remote blocklist with our beta audience and watch for feedback unless the possible user effect is too significant (I need more background on the remote driver blocklist).
What do you need to know?

Our remote blocklist works just like our built-in blocklist, except you need to wait for a blocklist ping for it to be applied (and even then, it's only applied on the next startup). Therefore, it can't fix startup crashes.
(In reply to Joe Drew (:JOEDREW!) from comment #26)
> What do you need to know?
> 
> Our remote blocklist works just like our built-in blocklist, except you need
> to wait for a blocklist ping for it to be applied (and even then, it's only
> applied on the next startup). Therefore, it can't fix startup crashes.

I was curious what the worst case would be if the blocklist didn't have the intended effect. Having spoken with juanb in QA, I now understand that we have fallback paths for graphics acceleration whenever possible.

Who takes the next action here? Are we ready to have the AMO guys stage a blocklist for beta users and ask smooney to watch the crash data?
Justin,

In order to test the theory that the AMD drivers are causing instability, we need a blocklist entry to be created with the contents of comment 10. 

It needs to be sent only to users of Firefox beta. Is that possible?
Assignee: joe → fligtar
Taking this.

The block is in place in addons-dev now. Here are the instructions for beta users to test this block: https://wiki.mozilla.org/Blocklisting/Testing
Assignee: fligtar → jorge
(In reply to Jorge Villalobos [:jorgev] from comment #29)
> Taking this.
> 
> The block is in place in addons-dev now. Here are the instructions for beta
> users to test this block: https://wiki.mozilla.org/Blocklisting/Testing

We don't have any internal repros here, so no manual testing - do we expect users to start picking up the new blocklist within 24 hours?
(In reply to Alex Keybl [:akeybl] from comment #30)
> We don't have any internal repros here, so no manual testing - do we expect
> users to start picking up the new blocklist within 24 hours?

Graphics blocks are not limited by Firefox version, which is why staged blocks are done in our test domain (addons-dev.allizom.org). So, we do need manual testing in order to verify the test block is working.
(In reply to Jorge Villalobos [:jorgev] from comment #31)
> Graphics blocks are not limited by Firefox version, which is why staged
> blocks are done in our test domain (addons-dev.allizom.org). So, we do need
> manual testing in order to verify the test block is working.

Thanks for the explanation Jorge. Sounds like we have no really good way to test the block before rolling it out, since we're unable to repro internally and we can't test with just our beta population.

Joe - is anything preventing us from performing the blocklist on the GA and seeing if our crash numbers drop? Can we revert the blocklist afterwards?
Yes, we can remove the blocklist afterwards. I'm not in favour of doing this experiment, but if we have to, we have to.
Well, I think what we can test is on a machine with one of those graphics chips (if we have one) we could see that using a default build D2D gets enabled (listed in about:support, right?) and when setting the blocklist URL to addons-dev.allizom.org and getting a new blocklist from there, D2D gets disabled.
We might not be able to QA the crashes going away if we can't repro them in the first place, but we should be able to QA the blocklist working, I guess.
(In reply to Joe Drew (:JOEDREW!) from comment #33)
> Yes, we can remove the blocklist afterwards. I'm not in favour of doing this
> experiment, but if we have to, we have to.

Do we have any alternatives given the number of dupes that have piled up?

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #34)
> We might not be able to QA the crashes going away if we can't repro them in
> the first place, but we should be able to QA the blocklist working, I guess.

Would this testing make you any more comfortable Joe? Or is the issue ensuring that the blocklist actually resolves the crashes prior to pushing to our users? I'm trying to understand what would green light the experiment in your mind.
We shouldn't block on seeing whether the blocklist resolves the crashes, but should be prepared for the blocklist to *not* resolve them.
(In reply to Joe Drew (:JOEDREW!) from comment #36)
> We shouldn't block on seeing whether the blocklist resolves the crashes, but
> should be prepared for the blocklist to *not* resolve them.

Let's move ahead with the blocklist in this case. Thanks!
Actually, we have access to hardware to test the staged version. Please go on Marcia's verification.
I am testing on a HP Pavilion Laptop, AMD Radeon HD 6310 Graphics/Driver Version 8.863.0.0. So far I haven't been able to verify that the staged blocklist works. I changed to the staging server and pasted the snipped, but after restart I am not seeing the blocklist take effect. I tested with both FF 11 and 10.0.2 so far. Will try to testing this again tomorrow.
I changed the pref to point to addons-dev.allizom.org and forced a blocklist ping. I can see the entry in blocklist.xml:

    <gfxBlacklistEntry  blockID="g73">
      <os>WINNT 6.1</os>
      <vendor>0x1002</vendor>
              <devices>
                      <device>0x9802</device>
                      <device>0x9803</device>
                      <device>0x9803</device>
                      <device>0x9804</device>
                      <device>0x9805</device>
                      <device>0x9806</device>
                      <device>0x9807</device>
                  </devices>
            <feature>DIRECT2D</feature>
      <featureStatus></featureStatus>
      <driverVersion></driverVersion>
      <driverVersionComparator></driverVersionComparator>
    </gfxBlacklistEntry>

Marcia, can you verify that you see this too?
It is entirely possible that the blocklist is broken on 11. Try a build with the patches for bug 711656 (i.e., the blocklist change backouts).
(In reply to Joe Drew (:JOEDREW!) from comment #41)
> It is entirely possible that the blocklist is broken on 11. Try a build with
> the patches for bug 711656 (i.e., the blocklist change backouts).

Marcia mentioned "I tested with both FF 11 and 10.0.2 so far."

We should verify the contents of the blocklist.xml though.
Also the Graphics section of about:support.
Adding qawanted and emailed QA to get eyes on this.
Keywords: qawanted
Here are my latest testing results:

1. Start with a fresh build of Firefox 11
2. Change the URL in about:config as instructed in https://wiki.mozilla.org/Blocklisting/Testing
3. Paste the snippet in Error Console

Received the following message: Timestamp: 3/19/2012 3:34:36 PM
Error: CSP: Couldn't parse invalid host addons-dev-cdn.allizom.org/

Graphics

        Adapter Description
        AMD Radeon HD 6310 Graphics

        Vendor ID
        1002

        Device ID
        9802

        Adapter RAM
        384

        Adapter Drivers
        aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64

        Driver Version
        8.863.0.0

        Driver Date
        6-28-2011

        Direct2D Enabled
        true

        DirectWrite Enabled
        true (6.1.7601.17776)

        ClearType Parameters
        ClearType parameters not found

        WebGL Renderer
        Google Inc. -- ANGLE (AMD Radeon HD 6310 Graphics) -- OpenGL ES 2.0 (ANGLE 1.0.0.930)

        GPU Accelerated Windows
        2/2 Direct3D 10

        AzureBackend
        direct2d

In addition I do not see the entry in blocklist.xml.
Blocklisting D2D won't help. See bug 714320 comment 42.
(In reply to Scoobidiver from comment #46)
> Blocklisting D2D won't help. See bug 714320 comment 42.

This is not necessarily true - https://bugzilla.mozilla.org/show_bug.cgi?id=714320#c43
Tested on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20100101 Firefox/12.0.

1) Change the preference per https://wiki.mozilla.org/Blocklisting/Testing
2) Force load the blocklist as explained in the same page. (I see the same errors as comment #45).
3) Check blocklist.xml

Result:
I see the blocklist entry in comment #40.
1.1) Close Firefox.
1.2) Delete blocklist.xml from the profile.
1.3) Start Firefox.

I don't know if these steps are necessary.
I was able to retest this using Firefox 12 B2 candidate:  Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0 on the same HP machine I was testing before that has AMD Radeon HD 6310 Graphics.

I can confirm that I do see the blocklist.xml entry in Comment 40 during testing this time. I did not need to perform the steps in Comment 49.

about:support now looks like:

Graphics

        Adapter Description
        AMD Radeon HD 6310 Graphics

        Vendor ID
        0x1002

        Device ID
        0x9802

        Adapter RAM
        384

        Adapter Drivers
        aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64

        Driver Version
        8.863.0.0

        Driver Date
        6-28-2011

        Direct2D Enabled
        true

        DirectWrite Enabled
        true (6.1.7601.17776)

        ClearType Parameters
        ClearType parameters not found

        WebGL Renderer
        Google Inc. -- ANGLE (AMD Radeon HD 6310 Graphics) -- OpenGL ES 2.0 (ANGLE 1.0.0.963)

        GPU Accelerated Windows
        1/1 Direct3D 10

        AzureBackend
        direct2d
No longer blocks: 568487
(In reply to juan becerra [:juanb] from comment #0)
> These are involved in the #3 top crash in Firefox 10.b6. We are about to
> ship Fx10 tomorrow, January 31.
With combined signatures that depends on this bug, it's #248 top browser crasher in 10.0.2, #19 in 11.0 (caused by bug 700288 and bug 722312), and #300 in 12.0b1.

(In reply to Marcia Knous [:marcia] from comment #50)
> about:support now looks like:
>         DirectWrite Enabled
>         true (6.1.7601.17776)
It doesn't seem blocklisted for Direct2D. Are you sure it's after the blocklisting?
Yes, I just checked and that is what about:support says. 

> 
> (In reply to Marcia Knous [:marcia] from comment #50)
> > about:support now looks like:
> >         DirectWrite Enabled
> >         true (6.1.7601.17776)
> It doesn't seem blocklisted for Direct2D. Are you sure it's after the
> blocklisting?
Does comment 52 confirm the blocklist is working correctly? What more is needed to satisfy qawanted?
(In reply to Jorge Villalobos [:jorgev] from comment #40)
> I changed the pref to point to addons-dev.allizom.org and forced a blocklist
> ping. I can see the entry in blocklist.xml:
> 
>     <gfxBlacklistEntry  blockID="g73">
>       <os>WINNT 6.1</os>
>       <vendor>0x1002</vendor>
>               <devices>
>                       <device>0x9802</device>
>                       <device>0x9803</device>
>                       <device>0x9803</device>
>                       <device>0x9804</device>
>                       <device>0x9805</device>
>                       <device>0x9806</device>
>                       <device>0x9807</device>
>                   </devices>
>             <feature>DIRECT2D</feature>
>       <featureStatus></featureStatus>

This is wrong. This needs to be set to BLOCKED_DEVICE, not empty.

>       <driverVersion></driverVersion>
>       <driverVersionComparator></driverVersionComparator>

These two should not be output at all in the XML.
(In reply to Joe Drew (:JOEDREW!) from comment #54)
> (In reply to Jorge Villalobos [:jorgev] from comment #40)
> >       <featureStatus></featureStatus>
> 
> This is wrong. This needs to be set to BLOCKED_DEVICE, not empty.

I've updated the entry accordingly, thanks. Marcia, please test again.

> 
> >       <driverVersion></driverVersion>
> >       <driverVersionComparator></driverVersionComparator>
> 
> These two should not be output at all in the XML.

This is handled by our admin tools, so all I do is fill out a form. I don't think I can remove those empty nodes. Do you think that can be a problem?
Retesting using  Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox, here is the output from the XML file:


 <gfxBlacklistEntry  blockID="g73">
      <os>WINNT 6.1</os>
      <vendor>0x1002</vendor>
              <devices>
                      <device>0x9802</device>
                      <device>0x9803</device>
                      <device>0x9803</device>
                      <device>0x9804</device>
                      <device>0x9805</device>
                      <device>0x9806</device>
                      <device>0x9807</device>
                  </devices>
            <feature>DIRECT2D</feature>
      <featureStatus>BLOCKED_DEVICE</featureStatus>
      <driverVersion></driverVersion>
      <driverVersionComparator></driverVersionComparator>
    </gfxBlacklistEntry>
    </gfxItems>


Info from about:support:

Graphics

        Adapter Description
        AMD Radeon HD 6310 Graphics

        Vendor ID
        0x1002

        Device ID
        0x9802

        Adapter RAM
        384

        Adapter Drivers
        aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64

        Driver Version
        8.863.0.0

        Driver Date
        6-28-2011

        Direct2D Enabled
        true

        DirectWrite Enabled
        true (6.1.7601.17776)

        ClearType Parameters
        ClearType parameters not found

        WebGL Renderer
        Google Inc. -- ANGLE (AMD Radeon HD 6310 Graphics) -- OpenGL ES 2.0 (ANGLE 1.0.0.963)

        GPU Accelerated Windows
        1/1 Direct3D 10

        AzureBackend
        direct2d
Comment 51 suggests that DirectWrite Enabled should be set to true, but I note in the retest although the blocklist.xml is correct that pref is still set to true.
Can you paste in the prefs section of about:support?
(In reply to Jorge Villalobos [:jorgev] from comment #55)
> > >       <driverVersion></driverVersion>
> > >       <driverVersionComparator></driverVersionComparator>
> > 
> > These two should not be output at all in the XML.
> 
> This is handled by our admin tools, so all I do is fill out a form. I don't
> think I can remove those empty nodes. Do you think that can be a problem?

Yes, if this is still not working, these empty nodes are the problem.
Important Modified Preferences

      Name

      Value

        browser.cache.disk.capacity
        1048576

        browser.cache.disk.smart_size.first_run
        false

        browser.cache.disk.smart_size_cached_value
        1048576

        browser.places.smartBookmarksVersion
        3

        browser.startup.homepage_override.buildID
        20120321033733

        browser.startup.homepage_override.mstone
        rv:12.0

        extensions.lastAppVersion
        12.0

        gfx.direct3d.prefer_10_1
        true

        network.cookie.prefsMigrated
        true

        places.database.lastMaintenance
        1332872971

        places.history.expiration.transient_current_max_pages
        96716

        privacy.sanitize.migrateFx3Prefs
        true

        security.warn_viewing_mixed
        false


(In reply to Joe Drew (:JOEDREW!) from comment #58)
> Can you paste in the prefs section of about:support?
Yep, it's the blank elements doing this.
Depends on: 739767
I filed bug 739767 to correct this on AMO, but it sounds like this is also something that should be fixed on Firefox. It doesn't make sense (to me at least) that empty nodes and no nodes have different interpretations. Is there a bug filed for this?
Bug 739767 has been fixed in addons-dev. I can confirm the empty nodes no longer appear.

Marcia: well, you know :)
Retesting, using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0 with a fresh profile:

Blocklist.xml File

<gfxBlacklistEntry  blockID="g73">      <os>WINNT 6.1</os>      <vendor>0x1002</vendor>              <devices>
                      <device>0x9802</device>
                      <device>0x9803</device>
                      <device>0x9803</device>
                      <device>0x9804</device>
                      <device>0x9805</device>
                      <device>0x9806</device>
                      <device>0x9807</device>
                  </devices>
            <feature>DIRECT2D</feature>      <featureStatus>BLOCKED_DEVICE</featureStatus>    </gfxBlacklistEntry>
    </gfxItems>


 Important Modified Preferences

      Name

      Value

        browser.cache.disk.capacity
        1048576

        browser.cache.disk.smart_size.first_run
        false

        browser.places.smartBookmarksVersion
        2

        browser.startup.homepage_override.buildID
        20120321033733

        browser.startup.homepage_override.mstone
        rv:12.0

        extensions.lastAppVersion
        12.0

        network.cookie.prefsMigrated
        true

        places.history.expiration.transient_current_max_pages
        96716

        privacy.sanitize.migrateFx3Prefs
        true

  Graphics

        Adapter Description
        AMD Radeon HD 6310 Graphics

        Vendor ID
        0x1002

        Device ID
        0x9802

        Adapter RAM
        384

        Adapter Drivers
        aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64

        Driver Version
        8.863.0.0

        Driver Date
        6-28-2011

        Direct2D Enabled
        true

        DirectWrite Enabled
        true (6.1.7601.17776)

        ClearType Parameters
        ClearType parameters not found

        WebGL Renderer
        Google Inc. -- ANGLE (AMD Radeon HD 6310 Graphics) -- OpenGL ES 2.0 (ANGLE 1.0.0.963)

        GPU Accelerated Windows
        1/1 Direct3D 10

        AzureBackend
        direct2d
Alright, at this point someone needs to step through this on an affected machine. We have tests that verify blocklists work, so clearly we've missed a case here.
Marcia, do you (or someone else in QA) have access to the affected machine so we can investigate this RE comment 65?
I am going to retest this morning, and if it fails again then we will hold a remote debugging session as planned by Alex.

(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #66)
> Marcia, do you (or someone else in QA) have access to the affected machine
> so we can investigate this RE comment 65?
I have also (finally!) set up remote debugging on an AMD C50 computer, so I am going to remote debug right now too.
Jorge: Is this block still staged as blockID=g73?
It is staged as blockID=g81
OK, discovered the bug. We don't actually support blocklist entries with no version specified, despite my claims to the contrary. I'll fix this shortly, but in the mean time:

Jorge, can you add to the blocklist entry the following:

A version of 1.0.0.0
A version comparator of GREATER_THAN_OR_EQUAL

This should let the blocklist entry work.
Done. It should take 15 mins or so for the served blocklist to be updated.
I tested the staged block in Comment 70 on the Radeon Machine and it doesn't seem to be picking up the block at all in blocklist.xml.

STR:
1. Load a fresh Firefox 12 build.
2. Set params according to https://wiki.mozilla.org/Blocklisting/Testing and include https://addons-dev.allizom.org/en-US/firefox/blocked/p81 for the block.
3. Ping by pasting the snippet in the error console

  Application Basics

        Name
        Firefox

        Version
        12.0

        User Agent
        Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0

        Profile Directory

          Show Folder

        Enabled Plugins

          about:plugins

        Build Configuration

          about:buildconfig

        Crash Reports

          about:crashes

        Memory Use

          about:memory

  Extensions

        Name

        Version

        Enabled

        ID

        Feedback
        1.1.2
        true
        testpilot@labs.mozilla.com

        Ad Muncher Browser Extensions
        2.0
        false
        {3ED591BC-7CC7-495B-A526-B2431356EDC1}

        avast! WebRep
        7.0.1426
        false
        wrc@avast.com

        Roboform Toolbar for Firefox
        7.6.0
        false
        {22119944-ED35-4ab1-910B-E619EA06A115}

  Important Modified Preferences

      Name

      Value

        browser.cache.disk.capacity
        1048576

        browser.cache.disk.smart_size.first_run
        false

        browser.cache.disk.smart_size_cached_value
        1048576

        browser.places.smartBookmarksVersion
        2

        browser.startup.homepage_override.buildID
        20120403211507

        browser.startup.homepage_override.mstone
        rv:12.0

        extensions.lastAppVersion
        12.0

        network.cookie.prefsMigrated
        true

        places.history.expiration.transient_current_max_pages
        96716

        privacy.sanitize.migrateFx3Prefs
        true

  Graphics

        Adapter Description
        AMD Radeon HD 6310 Graphics

        Vendor ID
        0x1002

        Device ID
        0x9802

        Adapter RAM
        384

        Adapter Drivers
        aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64

        Driver Version
        8.863.0.0

        Driver Date
        6-28-2011

        Direct2D Enabled
        true

        DirectWrite Enabled
        true (6.1.7601.17776)

        ClearType Parameters
        ClearType parameters not found

        WebGL Renderer
        Google Inc. -- ANGLE (AMD Radeon HD 6310 Graphics) -- OpenGL ES 2.0 (ANGLE 1.0.0.963)

        GPU Accelerated Windows
        1/1 Direct3D 10

        AzureBackend
        direct2d
Yeah, it's no longer being served by addons-dev.allizom.org, it seems.
Yeah, the staging data was reset sometime yesterday. The block is back up now.

Sorry for that.
The block for Direct2D now works!
Retesting with the staged block I see this now is working:


  Application Basics

        Name
        Firefox

        Version
        12.0

        User Agent
        Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0

        Profile Directory

          Show Folder

        Enabled Plugins

          about:plugins

        Build Configuration

          about:buildconfig

        Crash Reports

          about:crashes

        Memory Use

          about:memory

  Extensions

        Name

        Version

        Enabled

        ID

        Feedback
        1.1.2
        true
        testpilot@labs.mozilla.com

        Ad Muncher Browser Extensions
        2.0
        false
        {3ED591BC-7CC7-495B-A526-B2431356EDC1}

        avast! WebRep
        7.0.1426
        false
        wrc@avast.com

        Roboform Toolbar for Firefox
        7.6.0
        false
        {22119944-ED35-4ab1-910B-E619EA06A115}

  Important Modified Preferences

      Name

      Value

        browser.cache.disk.capacity
        1048576

        browser.cache.disk.smart_size.first_run
        false

        browser.cache.disk.smart_size_cached_value
        1048576

        browser.places.smartBookmarksVersion
        2

        browser.startup.homepage_override.buildID
        20120403211507

        browser.startup.homepage_override.mstone
        rv:12.0

        extensions.lastAppVersion
        12.0

        gfx.blacklist.direct2d
        4

        network.cookie.prefsMigrated
        true

        places.history.expiration.transient_current_max_pages
        96716

        privacy.sanitize.migrateFx3Prefs
        true

  Graphics

        Adapter Description
        AMD Radeon HD 6310 Graphics

        Vendor ID
        0x1002

        Device ID
        0x9802

        Adapter RAM
        384

        Adapter Drivers
        aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64

        Driver Version
        8.863.0.0

        Driver Date
        6-28-2011

        Direct2D Enabled
        Blocked for your graphics card because of unresolved driver issues.

        DirectWrite Enabled
        false (6.1.7601.17776)

        ClearType Parameters
        ClearType parameters not found

        WebGL Renderer
        Google Inc. -- ANGLE (AMD Radeon HD 6310 Graphics) -- OpenGL ES 2.0 (ANGLE 1.0.0.963)

        GPU Accelerated Windows
        0
(In reply to Marcia Knous [:marcia] from comment #77)
> Retesting with the staged block I see this now is working:

Thanks Marcia!

Let's push this to production tomorrow and see if crash #s drop.
I'll be unavailable until Monday because of Easter holidays. We can wait until then or I can reassign this to fligtar if it is necessary to do it this week.
Blocked in production.
Status: NEW → RESOLVED
Closed: 8 years ago
Keywords: qawanted
Resolution: --- → FIXED
Whiteboard: [gfx]
(In reply to Justin Scott [:fligtar] from comment #80)
> Blocked in production.

Thanks! I don't think we need to track for FF12 anymore at this point.
https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers hasn't been updated.
I think there should be something automatic like for add-on.
(In reply to Scoobidiver from comment #82)
> https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers hasn't been
> updated.
I did it.
I just filed bug 755974 to block the same devices for Direct3D 9 too.
Blocks: 745515
No longer blocks: 700288
Blocks: 700288
Running previous versions of firefox and catalyst drivers with my HD6310, I've tried

gfx.direct2d.force-enabled=true
layers.acceleration.force-enabled=true
webgl.force-enabled=true

but this has only demonstrated why this driver was blacklisted, I got garbled screens, now using firefox 15.0.1 with Catalyst 8.982.0.0

I can report that the driver appears to work perfectly and with much improved speed, is the time right to revoke the blacklist?
Depends on: 790169
Depends on: 840161
Product: addons.mozilla.org → Toolkit
Depends on: 1335925
You need to log in before you can comment on or make changes to this bug.