Regression: Acer D501 Dock update issue

[d4s]

Describe the bug
Update of the Acer D501 Dock (VID/PID: 0502/1195) fails with fwupd v1.9.16.
NB: Works well with v1.9.10.

The update/install is failed with the same error, output from update:

* fwupdmgr update d58a9b10-fb95-58ec-91a2-13764eca99f9 --json
  Exit status: 3
  Duration: 7.329288005828857

  Devices with no available firmware updates:.
   • Acer D501 Dock HDMI Converter
   • Acer D501 Dock USB Hub
   • DA4128
   • Touchpad
  {
    "Error" : {
      "Domain" : "FwupdError",
      "Code" : 8,
      "Message" : "failed to get device before update: device ID 5f243d853fc3575318c9189b5b8d85fd7a71edeb was not found"
    }
  }

Attached logs of failed 1.9.16 and successful 1.9.10 updates:
cros_ec_update_fail_1.9.16.log
fwupd_update_fail_1.9.16.log
cros_ec_update_success_1.9.10.log
fwupd_update_success_1.9.10.log

Have no access to HW to check with bisect or debug the issue.

Steps to Reproduce
Use Acer D501 Dock with F/W 2.0.8843 and try to update or install the newer version 2.0.10832:

• fwupdmgr update d58a9b10-fb95-58ec-91a2-13764eca99f9 --json
• CACHE_DIRECTORY='/var/cache/fwupd' fwupdmgr local-install --json --allow-older --allow-reinstall https://fwupd.org/downloads/1aca09b306293eab77af46f02c4ef913538ac99d33e53ff8cc70f71850ef405a-Baklava_11022021_sign.cab 5f243d853fc3575318c9189b5b8d85fd7a71edeb

Expected behavior

The F/W of Acer D501 Dock must updated successfully from 2.0.8843 to 2.0.10832.

fwupd version information

Fwupd v1.9.16 on ChromeOS.

Additional questions

• Operating system and version:
  ChromeOS version: R126-15885.0.0 / 126.0.6473.0 (Official Build) unknown (64-bit)
• Have you tried rebooting?
  yes
• Is this a regression?
  yes

[hughsie]

Aha, I know what this could be. Perhaps 20c24a9 -- maybe! d58a9b10-fb95-58ec-91a2-13764eca99f9 is USB\VID_0502&PID_1195 which was made a generic ID -- ohh no -- that wasn't until 1.9.17. Looking at the fail log I see c805da4e-d5f4-547d-b980-e508aec88cdb <- baklava so false alarm.

@d4s can you upload the complete fwupd logs for pass/fail please -- there are a few weird differences:

invalid release version 0x4e7fdf9522e2800: value 353530343039313920 was above maximum 4294967295

(maybe you can get me a backtrace of why we're hitting that)

Another thing that's interesting seems to be that the failed update seems to be interacting with another device -- perhaps:

$ git diff 1.9.10..1.9.16 plugins/rts54hub/
diff --git a/plugins/rts54hub/rts54hub.quirk b/plugins/rts54hub/rts54hub.quirk
index bce311952..cfb0858a7 100644
--- a/plugins/rts54hub/rts54hub.quirk
+++ b/plugins/rts54hub/rts54hub.quirk
@@ -42,3 +42,34 @@ Rts54TargetAddr = 0x20
 Rts54I2cSpeed = 0x2
 Rts54RegisterAddrLen = 0x04
 
+#Acer T34 Dock gen1
+[USB\VID_0502&PID_0702]
+Plugin = rts54hub
+Flags = updatable
+GType = FuRts54HubDevice
+FirmwareSizeMin = 0x10000
+FirmwareSizeMax = 0x20000
+
+#Acer T34 Dock gen2
+[USB\VID_0502&PID_0701]
+Plugin = rts54hub
+Flags = updatable
+GType = FuRts54HubDevice
+FirmwareSizeMin = 0x10000
+FirmwareSizeMax = 0x20000
+
+#Acer U33 Dock gen2
+[USB\VID_0502&PID_0801]
+Plugin = rts54hub
+Flags = updatable
+GType = FuRts54HubDevice
+FirmwareSizeMin = 0x10000
+FirmwareSizeMax = 0x20000
+
+#Acer U33 Dock gen1
+[USB\VID_0502&PID_0802]
+Plugin = rts54hub
+Flags = updatable
+GType = FuRts54HubDevice
+FirmwareSizeMin = 0x10000
+FirmwareSizeMax = 0x20000

Is one of those a device on the Baklava board? If so, can you try removing the entry from rts54hub.quirk and see if it fixes the update please. If it fixes it we can dig deeper and work out why.

[d4s]

@hughsie hmmm... more complete log is available from failing install -- looks like it includes the full log from a previous update attempt.
fwupd_install_fail_1.9.16.log

And it is full of messages like:

failed on try 3 of 100: failed to detach: failed to write I2C @0x6a:31: failed to write I2C: endpoint stalled or request not supported

For successful update only a shrank variant is available, but it also contains those messages
fwupd_install_success_1.9.10.log

[d4s]

@hughsie looks like it is possible to test that. However, I don't think we can get backtrace. Also, I have no access to device itself.
So, if I correctly understood your idea, we could try to ask:

1. Take rts54hub.quirk from 1.9.10 and put it to /var/lib/fwupd/quirks.d/
2. Stop the fwupd service
3. Try the update with fwupdtool -vv -- and it should to contain all needed info

Would it be enough?

[hughsie]

Would it be enough?

Nah, that only works for adding quirks, not taking them away. Maybe try setting DisabledPlugins=rts54hub in fwupd.conf?

[d4s]

Nah, that only works for adding quirks, not taking them away. Maybe try setting DisabledPlugins=rts54hub in fwupd.conf?

Hm... @hughsie it has been updated successfully. Do you need the successful update log?
Requested to obtain the log of failure with extended information.

[d4s]

Verbose logs attached:

• successful update and disabled plugin rts54hub
  fwupd-success-14768.log
• failed update with plugin enabled
  fwupd-fail-6163.log and from restarted fwupd right after failure, just in case if it contains something useful
  fwupd-12-6989.log

[d4s]

@hughsie any ideas?

[hughsie]

Will look tomorrow, sorry was ETOOBUSY today.

[hughsie]

I've added you to the email chain -- the tl;dr: seems to be that the cros_ec plugin is fighting with the rts54hub plugin -- trying to probe the same silicon at the same time. If that's true, then 825cf474ef needs to be reverted.