900029 - [buri][b2g18] drawLayerUsingCopybit: copybit stretch failed

Status: RESOLVED DUPLICATE of bug 905784

(Core :: Graphics: Layers, defect)

Description

[Ben Kelly [:bkelly, not reviewing]]

On my Buri running b2g18 I get a ton of these errors:

  E/msm7627a.hwcomposer(  447): drawLayerUsingCopybit: copybit stretch failed
  E/copybit (  447): copyBits failed (Invalid argument)
  E/copybit (  447): 0: src={w=320, h=416, f=1, rect={0,0,300,331}}
  E/copybit (  447):     dst={w=320, h=480, f=12, rect={20,149,300,331}}
  E/copybit (  447):     flags=00020000

This makes various apps like contacts and settings flash.  Sometimes the clock on the homescreen disappears.  See the video here:

  https://www.dropbox.com/s/90h5fadx8hbuh9n/20130723_contacts_sdcard_import.MOV

I get that kind of flashing doing other operations like just editing a contact as well.

This appears to be a buri specific issue.

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

I'm nom'ing for leo? (although its probably too late) because it makes the device close to unusable for me.  I don't know how other people can use the phone with this behavior.  (Or maybe its just isolated to a handful of faulty devices?)

If users are going to get this behavior it really does seem like a blocker to me.

Comment 2

[bhavana bajaj [:bajaj]]

Hey can can you please give more details on the build you are running ?

Also adding qawanted to see if they can help repro.

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

(In reply to bhavana bajaj [:bajaj] from comment #2)
> Hey can can you please give more details on the build you are running ?

mozilla-b2g18 at 119816:c4c6d2fe8d52

These errors seem to occur with either gaia/v1-train or gaia/master.

I've also tried flashing newer firmware from the vendor for the phone, but that does not seem to affect it.

> Also adding qawanted to see if they can help repro.

Thanks!

Comment 4

[Sotaro Ikeda [:sotaro]]

I feel it is a kernel/hw composer bug. I do not see this problem on v1.1 leo.

Comment 5

[Diego Wilson [:diego]]

bkelly: how do I add contacts to the sd card to begin with?

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Diego Wilson [:diego] from comment #5)
> bkelly: how do I add contacts to the sd card to begin with?

I enable the USB storage and copy the vCard file over.  It's easier to see with a larger file.

I also in unmount and disable USB storage before starting the import.

Comment 7

[Ben Kelly [:bkelly, not reviewing]]

Incidentally, the other failure mode I ran into today that caused me to file this bug:

  1) Flash gaia/master on b2g18 (I have not verified if gaia/v1-train triggers, but I suspect it does based on previous behavior.)
  2) Open contacts app
  3) Select a contact
  4) Edit the contact
  5) Add a phone number
  6) While typing in the phone number the screen started to exhibit the strange flashing behavior with certain layers just not drawing.  The copybit error above was in logcat.

In case its relevant this is the revision of the CAF device/qcom/msm7627a repository I am using currently with b2g18:

  5750d16c3b37827ee6e4061a94a3cce9127165a3

Comment 8

[Ben Kelly [:bkelly, not reviewing]]

Ok, now I can't reproduce the problem with the steps from comment 7.  The problem is definitely intermittent.

I am getting the sense, though, that I see it much more often when settings is involved.  For example:

  1) I see it with the import workflow the most and that goes through the contacts settings window.
  2) I saw the problem in comment 7 earlier today while working on bug 898992.  That bug requires leaving the contact form open while using the settings app to change the language.
  3) Just now while retesting, my device was acting fine until I opened the settings app.  I then saw the clock disappear from the homescreen behavior while switching back to contacts.

The intermittancy is somewhat maddening.  Its possible that the workflows I am using with settings are just triggering this more for me than it would for a normal user.  Or perhaps I'm just crazy.  Thank you all for looking into it.

Please let me know if there is any additional debug I can enable since my device seems to reproduce somewhat regularly with the import workflow.

Comment 9

[Ben Kelly [:bkelly, not reviewing]]

Attachment: sample vcard file

Diego, here is a sample vcard file you can put on your sdcard using the USB storage option in the settings app. This seems to trigger the issue for me well enough.

(Do also have some other screenshots, etc on the sdcard as well, though.  I doubt that is relevant, but it does take longer to scan the disk for the vcard.)

Comment 10

[Ben Kelly [:bkelly, not reviewing]]

Finally, I was able to get the copybit errors using the following procedure on v1-train/b2g18:

  1) Reboot device
  2) Open contacts app
  3) Open contacts settings
  4) Long-press home button and kill contacts app
  5) Repeat steps 2 through 4

The copybit errors appeared the third time opening the contacts settings or sooner on 9 out of 10 reboots.

Comment 11

[Jason Smith [:jsmith]]

The STR in comment 10 doesn't reproduce for me on a b2g18 unagi build from 8/1/2013. I'll try Buri in a second.

Comment 12

[Jason Smith [:jsmith]]

Also can't reproduce this on Buri on a 7/25 Partner build.

Comment 13

[Diego Wilson [:diego]]

Ben,

I also can't reproduce the contacts import or any of the other issues described on buri with the latest v1.1 vendor build as of 7/29.

Perhaps you need an update from the vendor?

Comment 14

[Ben Kelly [:bkelly, not reviewing]]

I flashed within the last two weeks which I thought was fairly recent.  I'll try the 1.1 vendor build tomorrow.  Perhaps this particular handset has a hardware issue.

If the vendor build is good, though, I would be curious what the differences between the two are.

In any case, I am happy as long as users aren't going to run into this.  I don't see this problem with m-c (although the Buri has other compositor issues there such as bug 881970 and bug 899247).

Thanks again for testing.

Comment 15

[Lukas Blakk [:lsblakk] use ?needinfo]

Sounds like this was fixed partner-side, not blocking.

Comment 16

[Ben Kelly [:bkelly, not reviewing]]

Diego, is it possible this is related to the specific version of the hardware?  Looking under the battery I see a label with "4012A - 2BALMX1".

I understand there is also a 4012B.  I wonder if this issue only occurs on the A variant.

Diego, what variant did you use to try to reproduce this?

Comment 17

[Diego Wilson [:diego]]

(In reply to Ben Kelly [:bkelly] from comment #16)
> Looking under the battery I see a label with "4012A - 2BALMX1".

This is the exact same label on my device. As I mentioned before, I can't reproduce the issue there.

Have you gotten a vendor build update? I'm using vendor build AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.171

Comment 18

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Diego Wilson [:diego] from comment #17)
> (In reply to Ben Kelly [:bkelly] from comment #16)
> > Looking under the battery I see a label with "4012A - 2BALMX1".
> 
> This is the exact same label on my device. As I mentioned before, I can't
> reproduce the issue there.

Thanks for checking.  Just wanted to rule that out.

> Have you gotten a vendor build update? I'm using vendor build
> AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.171

I've been unable to get the flashing tool to run today.  After entering username/password nothing happens.

Comment 19

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Diego Wilson [:diego] from comment #17)
> Have you gotten a vendor build update? I'm using vendor build
> AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.171

So I'm not sure how to get this exact string from the image I flashed, but the vendor image does indeed fix the problem on my device.

I tried extracting the firmware as a new backup-hamachi and rebuilding using our b2g repo.  Unfortunately, the problem still returns with a local build using an updated v1-train b2g-manifest and mozilla-b2g18.

So this doesn't appear to be a user facing issue, but it does make development on the device difficult.

Is there any way we can get whatever fixes the vendor has for the hwc incorporated into our repo?

Comment 20

[Diego Wilson [:diego]]

The vendor build should not have any hwc gecko patches that have not already landed in mozilla-b2g18.

The vendor build may have some patches in the kernel, libhwcomposer.so and/or libcopybit.so. You may see issues if you replace any of these as part of your local build. IMO you shouldn't be doing this in the first place.

mwu,

Does Mozilla replace any of the gonk pieces I mentioned above after they get a vendor build?

Comment 21

[Ben Kelly [:bkelly, not reviewing]]

Just to clarify what I did:

1) Flash phone with vendor tool.

I could not reproduce the problem at this point.

2) Remove b2g out dir and gecko objdir

3) Remove b2g backup-hamachi

4) ./repo sync in b2g (originally created with BRANCH=v1-train ./config.sh hamachi)

5) ./build.sh which recreates the backup-hamachi from the newly flashed device

6) ./flash.sh

I can now reproduce the problem.

Comment 22

[Ben Kelly [:bkelly, not reviewing]]

So it appears I can avoid this problem by only doing a "./flash.sh gecko" after flashing the vendor build.  This suggests that its in the kernel or other libraries included in the full ./flash.sh.

Comment 23

[Michael Wu [:mwu]]

A full flash.sh is not recommended procedure unless you have good reason for doing so. ./flash.sh gecko and ./flash.sh gaia is always the recommendation unless you need to debug system libraries.

We use patches at https://www.codeaurora.org/cgit/quic/lf/build/tree/patch?h=v1 but vendors can always add their own additional things which we wouldn't know about.

Comment 24

[Michael Wu [:mwu]]

Note that we haven't updating the patch set (AFAIK) in a while. If there's new hwc patches for v1.1, maybe we need to update.

Comment 25

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Michael Wu [:mwu] from comment #23)
> A full flash.sh is not recommended procedure unless you have good reason for
> doing so. ./flash.sh gecko and ./flash.sh gaia is always the recommendation
> unless you need to debug system libraries.

Ah, I was not aware of that.  I apologize for wasting everyone's time.

Perhaps we should add a note about that here?

  https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Building

Of course, not all contributors will have access to the vendor builds, so that guidance may not be useful for volunteers.

It does seem like it would be useful to update our patches, if possible.  Should I leave this bug open to track that or just mark INVALID?

Thanks!

Comment 26

[Sotaro Ikeda [:sotaro]]

Hi Diego, I have the following questions related to "copybit stretch failed". Can you answer them?

[1] Can copybit hw handle only pmem or also handle system heap correctly?   
    gralloc buffer uses system heap when out-of-pmem.
https://www.codeaurora.org/cgit/external/gigabyte/platform/hardware/qcom/display/tree/libgralloc/alloc_controller.cpp?h=caf/b2g/ics_strawberry_v1#n306

[2] In canFallback() on Current b2g, QCCompositionType::getInstance().getCompositionType() returns COMPOSITION_TYPE_CPU(0x4)
Is it a correct value? Is there a reason why the value is not COMPOSITION_TYPE_MDP(0x1)

https://www.codeaurora.org/cgit/external/gigabyte/platform/hardware/qcom/display/tree/libgralloc/alloc_controller.cpp?h=caf/b2g/ics_strawberry_v1#n66

Comment 27

[Sushil]

For [2]:

Yes, it should be COMPOSITION_TYPE_MDP (0x1). I assume it is 7627a device. Please check "/system/build.prop" on the device and make sure it has:
debug.sf.hw=1
debug.composition.7x27A.type=mdp

If debug.sf.hw is 0, composition type will be set as COMPOSITION_TYPE_CPU (i.e. S/W Composition). I checked and confirmed it on 7627a device, it returns COMPOSITION_TYPE_MDP. Let me know, if it works.

Comment 28

[Sushil]

For [1]:

Copybit mdp can handle PMEM but it cannot handle system heap as it needs physically contiguous memory. That is why, canFallback() returns false, if composition type is MDP.

Comment 29

[Diego Wilson [:diego]]

(In reply to Ben Kelly [:bkelly] from comment #25)
> It does seem like it would be useful to update our patches, if possible. 
> Should I leave this bug open to track that or just mark INVALID?
> 
> Thanks!

May I suggest closing this bug and perhaps opening another bug for updating Mozilla's patches?

Comment 30

[Sotaro Ikeda [:sotaro]]

I created Bug 905784 for "debug.sf.hw=1" on hamachi/buri.