8086:2562 Flash 11.2 content displays in shades of green and purple only, and in a horizontally compressed space

This change was made by a bot.

The BIOS version offered there is A05 (http://www.dell.com/support/drivers/us/en/19/DriverDetails/Product/dimension-2400?driverId=R70278&osCode=WW1&fileId=2731128804&languageCode=en&categoryId=BI).

But this machine is already running A05 (noted above -- dmi.bios.version: A05).

(I imagine you were glancing at dmi.board.version: A01 just a couple lines below that.)

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report[0]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

Please follow the instructions on the wiki page[0]. The first step is to email the appropriate mailing list. If no response is received, then a bug may be opened on bugzilla.kernel.org.

Once this bug is reported upstream, please add the tag: 'kernel-bug-reported-upstream'.

I just now finished preparing a report and emailed it to the maintainer's list for the "Intel DRM Drivers."

I did test the latest mainline kernel, but as of this moment don't have a clue about how to test the latest Xorg stack or bisect a regression. (Though if I wanted to get a clue about bisecting a regression, I could follow your link regarding that, thanks.)

The online archive of the email begins with my email at http://lists.freedesktop.org/archives/dri-devel/2013-August/043876.html

Happily for me as regards my time investment on this problem, but perhaps unhappily as regards fixing the problem, Chris Wilson from the Intel Open Source Technology Centre rendered this summary judgment in a reply:

"It's a flash bug. They ignore the format of the Window that they PutImage to. (Worse, they create an image of the right depth or else X would reject the PutImage with a BadMatch and then render incorrect pixel data into it.)"

If his assessment is on the mark, and if you have a PC with affected Intel graphics that you want to display Flash content, it would seem that the only recourse is to install a supported non-Intel video card.

I have seen the issue with any Flash content I encountered.

But to reproduce it, as far as I know you need to be using one of the affected Intel graphics chipsets. The machine I was reporting from has an 845G chipset. It has also been reported for 855G and 865G (see http://ubuntuforums.org/showthread.php?t=2132368, and https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1178982 Comment #21).

In addition, from what I have read all of the affected machines are Dell's, but that may be a simple consequence of the popularity of those Dell PC's. (I have 4 Dell Dimension 2400's here and several more near cousins.)

In my thread on the Lubuntu email list, one regular on the list said "all of my older Dell machines have the problem." (OK, that's verging toward hearsay.)

That makes sense to me, but I was even less equipped to disagree with a maintainer.

It seems that "Kernel Bisection" is not as scary a procedure as the term might lead one to imagine.

OK, Flash 11.2 performs normally with the 3.7.0-7.15 kernel, but fails with 3.8.0-0.2.

On 8/17/2013 4:24 PM, Christopher M. Penalver wrote:
> John Hupp, the next step is to commit bisect from 3.7.0-7.15 to
> 3.8.0-0.2 in order to identify the commit that caused this problem via
> https://wiki.ubuntu.com/Kernel/KernelBisection .
>
That instruction has a FAQ about how to proceed when git bisect start
generates "Bisecting: a merge base must be tested," but it seems to
assume that one has completed at least one git bisect start. How do I
proceed if that is the result with the very first attempt?

In an off-Launchpad direct exchange, I received some direction that "You would want to bisect the mainline kernel instead of the Ubuntu kernel."

I should say more directly that I have never done kernel bisection until now, though I'm game for the effort. Nonetheless, very little can be taken for granted.

Does the above direction mean that when I get to the procedure "Commit bisecting Ubuntu kernel versions" at https://wiki.ubuntu.com/Kernel/KernelBisection, I should use it only as some sort of a general guideline and switch to commit bisecting mainline kernels?

If so, I'm not seeing how. Still assuming that I should use git bisect, I'm not seeing an identifiable *mainline* git repo at http://kernel.ubuntu.com/git, and alternatively I'm not seeing *git* repos at http://kernel.ubuntu.com/~kernel-ppa/mainline/. Perhaps there are non-Ubuntu-related mainline git repos somewhere that I should be using.

I'm sure this is all laughably self-evident to any developer reading this, but I'm just a somewhat experienced user trying to work in the higher realms where bugs are fixed, so kindly indulge me.

I was in the process of building the mainline kernel for the first commit identified by git bisect. (I skipped the exercise of building the two mainline kernels that mapped from the good and bad Ubuntu kernels.) I ran this command at step 8:
        make -j `getconf _NPROCESSORS_ONLN` deb-pkg LOCALVERSION=-MainlineBisect1
(substituting "MainlineBisect1" for "custom").

The machine worked on this for perhaps 8 hours (I stopped monitoring at some point and let it run overnight). I found these warnings/errors at the end of the results:

dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe
dpkg-deb: building package `linux-firmware-image' in `../linux-firmware-image_3.7.0-MainlineBisect1-1_i386.deb'.
dpkg-gencontrol: error: illegal package name 'linux-headers-3.7.0-MainlineBisect1': character 'M' not allowed
make[1]: *** [deb-pkg] Error 255
make: *** [deb-pkg] Error 2

It did produce linux-firmware-image_3.7.0-MainlineBisect1-1_i386.deb (a 1.1MB file), but nothing else.

A couple questions then:

1) Was "MainlineBisect1" not allowed as a string substitute for "custom"? If not, what is allowed?

2) Do I have to back up to perhaps "make clean" and do the 8-hour thing over again, or can I salvage whatever it was doing for 8 hours?

On 8/30/2013 7:23 AM, Christopher M. Penalver wrote:
> John Hupp, also change your naming structure to be all lower case. ;)
>

I decided to proceed with another overnight opportunity. I changed to
all lower case and without a numeral, and that worked.

More newbie questions from an end-user:

1) Https://wiki.ubuntu.com/KernelTeam/GitKernelBuild instructions after making the kernel: "Now install the .deb files. In this example, the files are linux-image-2.6.24-rc5-custom_2.6.24-rc5-custom-10.00.Custom_i386.deb and linux-headers-2.6.24-rc5-custom_2.6.24-rc5-custom-10.00.Custom_i386.deb. You may receive warnings about '/lib/firmware/2.6.24-rc5-custom/' - this is expected and will only be problematic if the driver you are trying to test requires firmware."

That is, it only specifies installation of linux-image*.deb and linux-headers*.deb. My build also produced a linux-firmware-image*.deb and linux-libc-dev*.deb. Can I/should I leave those uninstalled here?

2) Https://wiki.ubuntu.com/Kernel/KernelBisection instructions after installing and testing the first new kernel: "Repeat the process: build, install, test, and report back test results with git bisect good or bad."

But it seems to me that I would not repeat the entire process from https://wiki.ubuntu.com/KernelTeam/GitKernelBuild. Do I start again with "make clean" in the linux folder?

Not hearing anything here, I installed just the linux-headers and linux-image deb files, and not the linux-firmware or linux-libc-dev debs.

I also started the next kernel build at the "make clean" step from the linux folder, but the build process then injected a bunch of prompts very similar to what I saw when I was updating the kernel configuration file during the first kernel build. So I now think that succeeding kernel builds must repeat every step except "git clone." I hope that doesn't foul up the bisection results.

I finally got through the git bisect process:

57779d06367a915ee03e6cb918d7575f0a46e419 is the first bad commit
commit 57779d06367a915ee03e6cb918d7575f0a46e419
Author: Ville Syrjälä <email address hidden>
Date: Wed Oct 31 17:50:14 2012 +0200

    drm/i915: Fix display pixel format handling

    Fix support for all RGB/BGR pixel formats (except the 16:16:16:16 float
    format).

    Fix intel_init_framebuffer() to match hardware and driver limitations:
    * RGB332 is not supported at all
    * CI8 is supported
    * XRGB1555 & co. are supported on Gen3 and earlier
    * XRGB210101010 & co. are supported from Gen4 onwards
    * BGR formats are supported from Gen4 onwards
    * YUV formats are supported from Gen5 onwards (driver limitation)

    Signed-off-by: Ville Syrjälä <email address hidden>
    Reviewed-by: Jesse Barnes <email address hidden>
    Signed-off-by: Daniel Vetter <email address hidden>

:040000 040000 334e1536b3513d0c329a8bb6360593d12065b71d bf0996ec13cbee07156c5e9f98dcdee30200e658 M drivers

The latest mainline kernel (3.11.0-031100-generic, modified 9-2-13) still suffers from the bug.

Software Update also offered an updated version of the Flashplugin-Installer (updating 11.2.202.297 to 11.2.202.297), but that did not fix the problem either.

John Hupp, the issue you are reporting is an upstream one. Could you please report this problem through the appropriate channel by following the instructions _verbatim_ at https://wiki.ubuntu.com/Bugs/Upstream/kernel#KernelTeam.2BAC8-KernelTeamBugPolicies.Overview_on_Reporting_Bugs_Upstream ?

Thank you for your understanding.

On 9/13/2013 6:31 AM, Christopher M. Penalver wrote:
> John Hupp, the issue you are reporting is an upstream one. Could you
> please report this problem through the appropriate channel by following
> the instructions _verbatim_ at
> https://wiki.ubuntu.com/Bugs/Upstream/kernel#KernelTeam.2BAC8-KernelTeamBugPolicies.Overview_on_Reporting_Bugs_Upstream
> ?
>
> Thank you for your understanding.
>
> ** Tags removed: kernel-bug-exists-upstream-v3.11-rc5
> ** Tags added: kernel-bug-exists-upstream-v3.11
>
> ** Tags removed: needs-upstream-testing
>
> ** Changed in: linux (Ubuntu)
> Status: Incomplete => Confirmed
>

I followed that procedure and emailed the maintainers on 8/15 (Comments
#6 and #8), so I have just now resent it, adding the results of the
kernel bisection and also noting that the latest mainline kernel still
suffers from the problem (and that the recent update to
flashplugin-installer, 11.2.202.310, did not fix it either).

Given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We are approaching release and would like to confirm if this bug is still present. Please test again with the latest development kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get dist-upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

Thank you for your help, we really do appreciate it.

Going back to the bug description:

...
WORKAROUND: Setting the Intel driver's acceleration method to UXA rather than its default SNA *always* fixes the Flash problem, but causes a garbled login screen under LightDM that so far has no workaround.
...

This 'UXA' workaround makes the graphics rendering work in my old IBM Thinkcentre with old Intel graphics.

$ lspci
00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02)
00:06.0 System peripheral: Intel Corporation 82865G/PE/P Processor to I/O Memory Interface (rev 02)
00:1d.0 USB controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02)
00:1d.1 USB controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02)
00:1d.2 USB controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02)
00:1d.3 USB controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02)
00:1d.7 USB controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02)
00:1f.5 Multimedia audio controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02)
03:08.0 Ethernet controller: Intel Corporation 82562EZ 10/100 Ethernet Controller (rev 02)
-----

But the current daily build does not solve my problem. There has never been a garbled screen in my case, only the ugly rendering, and it is still there, maybe there are only 256 colours. Even Lubuntu's default background picture looks bad. I guess this old Intel chip will need UXA also in the future.

sudodus, if you have a bug in Ubuntu, the Ubuntu Kernel team, Ubuntu Bug Control team, and Ubuntu Bug Squad would like you to please file a new report by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report would delay your problem being addressed as quickly as possible.

No need exists to comment here at this time. After reading the above documentation in it's entirety, if you have further questions, you are welcome to redirect them to the appropriate mailing list or forum via http://www.ubuntu.com/support/community/mailinglists , or you may contact me directly.

Thank you for your understanding.

On 9/20/2013 6:39 PM, Joseph Salisbury wrote:
> Given the number of bugs that the Kernel Team receives during any
> development cycle it is impossible for us to review them all. Therefore,
> we occasionally resort to using automated bots to request further
> testing. This is such a request.
>
> We are approaching release and would like to confirm if this bug is
> still present. Please test again with the latest development kernel and
> indicate in the bug if this issue still exists or not.
>
> You can update to the latest development kernel by simply running the
> following commands in a terminal window:
>
> sudo apt-get update
> sudo apt-get dist-upgrade
>
> If the bug still exists, change the bug status from Incomplete to
> Confirmed. If the bug no longer exists, change the bug status from
> Incomplete to Fix Released.
>
> Thank you for your help, we really do appreciate it.
>
>
> ** Changed in: linux (Ubuntu)
> Status: Confirmed => Incomplete
>
> ** Tags added: kernel-request-3.11.0-7.14
>

Sudo apt-get update
Sudo apt-get dist-upgrade

This does not install for me anything more recent than 3.11.0-031100,
which I had already installed as part of the earlier testing.

I had been bisecting the *mainline* kernel following
https://wiki.ubuntu.com/Kernel/KernelBisection. That gives no
instructions for any sort of a wrap-up after finding the first bad
commit. But from other reading I have some recollection of using 'git
bisect reset' after such a process to return to another branch. Is that
what I need to do?

Or is there another way to install 3.11.0-7.14?

John Hupp, I would disregard https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1212455/comments/28 for now as it's a robo-comment. Please continue to bisect and then we can circle back on newer kernel testing after.

On 9/27/2013 6:42 AM, Christopher M. Penalver wrote:
> John Hupp, I would disregard
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1212455/comments/28
> for now as it's a robo-comment. Please continue to bisect and then we
> can circle back on newer kernel testing after.
>
> ** Tags removed: kernel-request-3.11.0-7.14
> ** Tags added: bot-stop-nagging
>
I finished the bisect (#23) and also emailed the upstream maintainers
with the updated results on 9/13, but have not heard anything from
them. So after 2 weeks of silence there, perhaps it's time to file a
bug at Bugzilla.kernel.org.

John Hupp, regarding your latest post http://lists.freedesktop.org/archives/dri-devel/2013-September/045293.html , I would recommend changing the BODY of your e-mail to the Summary of this report or it risks being ignored as being general, and undetailed.

Despite this, one would not want to use kernel.org for a potential bug in Flash itself, as this is not their upstream bug tracker. Instead, one would want to first test the latest mainline kernel http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-rc2-saucy/ . Assuming it's still reproducible, it would be best to bring in Flash upstream to comment to Chris Wilson's assertion on http://lists.freedesktop.org/archives/dri-devel/2013-August/043876.html . One may file a report with Flash upstream using the upstream format noted in https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Kernel.org_Format via https://bugbase.adobe.com/?event=home .

Please feel free to post the report URL when completed.

On 9/28/2013 10:08 AM, Christopher M. Penalver wrote:
> John Hupp, regarding your latest post
> http://lists.freedesktop.org/archives/dri-
> devel/2013-September/045293.html , I would recommend changing the BODY
> of your e-mail to the Summary of this report or it risks being ignored
> as being general, and undetailed.

I'm not sure I understand the recommendation. Do you mean move the
update info (the git bisect results, etc) to the end of "THE ORIGINAL
REPORT" into currently-empty section "[X.] Other notes, patches, fixes,
workarounds:"?

In other words, follow the precise format for emailing the upstream
maintainers given at
http://wiki.ubuntu.com/Bugs/Upstream/kernel#KernelTeam.2BAC8-KernelTeamBugPolicies.Overview_on_Reporting_Bugs_Upstream,
but adding the git bisect results, etc. in section [X.]?

John Hupp, when I typed BODY I intended SUBJECT, sorry for the confusion.

That part is easily done (and now has been done).

John Hupp, great. Could you please provide a URL to your Flash upstream bug report?

Good news -- Daniel Vetter from the upstream maintainers list responded to the email with the more descriptive SUBJECT.

He wrote:

Still a flash bug. This commit simply enables rgb555 in the kernel, which sna likes to use on gen2/3. Flash is just too dense and always presumes xrgb8888.

Adding

Section "Screen"
        Identifier "igd"
        DefaultDepth 24
EndSection

to your xorg.conf will work around.

-------------

And doing so here did successfully work around the behavior for the machines I reported on.

I note for other users that just the snippet above in an otherwise blank xorg.conf will do. And many users, like me, will have no existing xorg.conf but will have to create one, such as I did at /etc/X11/xorg.conf (though there are many other locations where X will find the file).

John Hupp, marking Triaged against Adobe given upstream discussion. Hence, the issue you are reporting is an upstream one. It would be nice if somebody having it could send the bug to the developers of the software via https://bugbase.adobe.com/?event=newBug :
Product: Adobe Flash Player
Version: 11.2
Product Area: Graphics
Frequency: Some users will encounter
Failure Type: Incorrect w/ Workaround
Found in Build: 11.2.202.262
* Unfortunately, 11.2.202.332 is not an option. I would just make a comment to this.
App Language: English
OS Language: English
Platform: Linux
Browser: Firefox All

If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about the status. Thanks in advance.

Helpful bug reporting tips:
https://help.ubuntu.com/community/ReportingBugs

Declining the linux (Ubuntu) task as this would be a bug in Flash, not the linux kernel.