Tvservice locks up in vc_tv_hdmi_ddc_read on pi3

[Ealdwulf]

tvservice locks up in vc_tv_hdmi_ddc_read (waiting for futex), on raspberry pi 3.

This happens 70% of the time in Kano OS 2.4 (which is using raspbian as a base).
It happens with a rather lower frequency, bit is still reproducable, in vanilla raspbian. I have not yet figured out what causes the variation (it's not config.txt).

To reproduce using 2016-03-18-raspbian-jessie
set hdmi_force_hotplug=1 in /boot/config.txt

Run tvservice repeatedly, eg
for ((i=0;i<100;i++)) do tvservice -d e ; echo $i ; done
You might need to run it a few times.

Once it has locked up, further tvservice commands don't return, and the pi doesn't want to reboot either.

[popcornmix]

I can reproduce this. Let me see what is going on.

[popcornmix]

Can you try with this test firmware:
https://dl.dropboxusercontent.com/u/3669512/temp/firmware_imask.zip

[Ealdwulf]

This seems to fix the problem - ran 10000 calls to tvservice without issue.
Since I imagine that a fix will take a while to make it into raspbian, is there an obvious workaround - For example, is the problem specific to hdmi_force_hotplug=1, so we can avoid it by not doing that?
Thanks!

[popcornmix]

The bug occurs when the EDID is being read through I2C at the same time as another I2C operation occurs. The other I2C operation may be changing the voltage of the SMPS (when enabling/disabling turbo mode), and when reading state from the GPIO expander (e.g. under-voltage and HDMI hotplug).

I don't see a reason why hdmi_force_hotplug=1 will cause an issue (in theory it should remove one of the conflicting accesses), so I'm not convinced the presence or absence of that is significant.

The fix will appear in next rpi-update firmware (possibly later tonight). It will come to apt-get firmware later (maybe a months time).

[popcornmix]

The fix should now be in rpi-update firmware

[Ealdwulf]

Thanks!

[Ealdwulf]

Is there any chance that we could get a build with this fix based on https://github.com/raspberrypi/firmware/tree/1.20160315? I'm having some problem getting the a32be14... version to work with our OS and we're quite close to releasing so it's a bit awkward. Not sure what the problem here is yet, but it it happens to be easy to do a build of that, it would be a greate help.

[popcornmix]

No. Firmware builds come off a single branch.
If there is an issue with current head, then you need to create a new issue and we'll try to resolve it.

[Ealdwulf]

We are still seeing problems with this. It doesn't seem to happen on the occasions when it did previously, but we've seen it lock up under ordinary usage on our OS twice, and we've got customer reports which we think can be traced back to it. I replicated it on raspbian again:
Using 2016-03-18-raspbian-jessie updated to firmware f063c24a8307ae57040eda58f4751a97efdf7ab8 and ran got a lockup after ~4000 calls to tvservice (this time without modifying config.txt).

[Ruffio]

@Ealdwulf had this issue been resolved?

[Ruffio]

@Ealdwulf have you tried the new firmware? How is it?

[Ealdwulf]

Oops, I was missing these messages because they went to another email address. I'll check it out...

[Ealdwulf]

It seems to be working now, thanks!

[popcornmix]

Okay, thanks for testing. I'll close now. You can always reopen if the problem reoccurs.