[Letux-kernel] Pandora: XUDF and other issues

H. Nikolaus Schaller hns at goldelico.com
Fri Feb 18 11:52:26 CET 2022


Hi,
this topic isn't forgotten but really difficult to solve.

So I have changed the Subject.

> Am 03.02.2022 um 16:52 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> Hi,
> sorry for not working on this issue... I have not forgotten but there are
> too many other important things ahead.
> 
> But I have a minor observation in addition to this:
> 
>> Am 10.01.2022 um 21:33 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 
>> PS: one more observation - I can sometimes trigger it by pure
>> kernel/processor activity. But not systematically.
>> root at letux:~# 
>> root at letux:~# ./high-load    
>> 100% load stress test for 1 cores running loop
>> Mon Jan 10 20:32:26 UTC 2022 51° 3853mV 600MHz
>> Mon Jan 10 20:32:26 UTC 2022 51° 3859mV 600MHz
>> Mon Jan 10 20:32:28 UTC 2022 52° 3853mV 600MHz
>> [  747.156127] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
>> [  747.168548] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
>> [  747.438201] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
>> [  747.529113] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
>> Mon Jan 10 20:32:29 UTC 2022 54° 3853mV 600MHz
>> Mon Jan 10 20:32:32 UTC 2022 54° 3853mV 600MHz
>> [  750.409240] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
>> [  750.499999] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
>> Mon Jan 10 20:32:33 UTC 2022 54° 3847mV 600MHz
>> [  753.147277] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
>> [  753.168212] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
>> [  753.177795] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
>> [  753.187408] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
>> Mon Jan 10 20:32:35 UTC 2022 54° 3847mV 600MHz
>> [  753.448516] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
>> [  753.538452] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
>> ^Ckill 3692
>> 
>> root at letux:~#
> 
> running
> 
> 	timeout 30s /root/high-load >/dev/null; dmesg | fgrep -q XUDF && echo "bad" || echo good
> 
> quite reliably triggers and reports the XUDF issue. But only if I run full letux-5.4.
> 
> Not, if I just add some minor tweaks to upstream v5.4 (which then has no display and
> no hubs of course).
> 
> Well, there are a lot of no-yet upstreamed patches in between, e.g. for display
> or the nubs itself. So it could be expected that the bug is not visible with v5.4.
> 
> On the other hand it is also not visible on v5.1 or full letux-5.1.
> 
> So I think it may be an upstream change that only manifests itself on a full
> letux kernel.
> 
> Maybe I have to set up a more complete letux patch set on top of bisecting
> upstream between v5.1 and v5.4. That is additionally challenging to get
> something that merges and compiles well in all intermediate steps...

I have started to work on this but it is the most challenging bisect I ever had.

The problem is that v5.1 and v5.4 compile and run, but many intermediate
versions needed for bisect don't. Well, you can always compile the upstream
versions using omap2plus_defconfig - but then you won't get the Pandora
config with a working display. And it seems as if there is no XUDF without
active display/X11 (i.e. no I2C traffic for the nubs?).

Finally I have bisected one smaller issue which made compilation of v5.2-rc1..v5.4-rc4
fail. With this (optionally applied) fix it appears as if I can now compile and
test all intermediate steps.

But the display is now broken. It seems to depend on the letux_defconfig
which also has changed between letux-5.1 and letux-5.4. Interestingly
it works for v5.1 if I take the letux-5.1 defconfig but not v5.4. The latter
config fails for both.

Another hurdle is that I still have to swap the SD card for installing a bisect
step kernel and reboot using the shoulder button. This means I can't run
this unattended over night. If anyone knows how to make an SD card
autoboot (i.e. choose boot from SD:1 in the right shoulder button boot
menu automatically) this can be improved.

To summarize: there are still pieces missing to be able to run the final bisect
and look out how XUDF depends on some kernel patches.

And today I once got the XUDF messages when running 5.1. Something
I had never observed before. So it may be that the symptom has some random
component which usually makes the complete bisect fail. And a random
influence is either some unitialized variable or some hardware effect?

So far for the status.

BR,
Nikolaus

PS: letux-5.17-rc4 also shows the musb issue seen on the GTA04 and the
same revert helps.


More information about the Letux-kernel mailing list