[Letux-kernel] [PATCH 0/8] Get sound playback working on the Pandora again

H. Nikolaus Schaller hns at goldelico.com
Mon Jan 10 21:33:01 CET 2022



> Am 10.01.2022 um 18:03 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
>> 
>> Another subtle thing which may trigger it is the vibration. The nub
>> driver apparently communicates with the nubs' ATMEGA microcrontrollers
>> over the same I2C bus,
> 
> yes, it is the nub + touch peripheral bus.

Ok, have studied schematics...

Touch controller goes through SPI (I forgot).

This i2c connects directly to the bq27500 fuel gauge.
And through a level shifter to the nubs and an (optional?) mma7455.

The nubs can trigger an interrupt (on 1.8V level).

On the OMAP side there is an 1k0 pullup (quite strong IMHO) to 1.8V.
And on the Nub side there is also 1k0 pullup to VAUX4 (which also powers the nub
and the accelerometer).

VAUX4 comes from the twl4030 (which also does sound btw - but a different subsystem).
So either of the chips may make trouble.

I had not seen issues with 3.2 and zaxxon.

One idea: did you try to remove the battery for a while? Maybe the twl4030 is in a bad
state and has trouble generating VAUX4 properly? Even after simple "reboot" since the
backup battery may conserve state?

Now I have installed letux-4.19[.0] (built Oct 2018) and could not see or trigger
any of the issues (no sound of course).
Next I have tried letux-4.19.223 also without issues.
Next I tried letux-5.10[.0] quickly showed the I2C bug and nubs were non-responsive.
Interestingly the bq27500 did respond well.
Then I tried letux 5.4[.0] and got the same as with 5.10.
Back to 4.19.233 and all issues are gone. Nubs work and no I2C XUDF or
timeout messages.
Finally I tried again 5.4[.0]. This time there were XUDF errors before I could login
but the nubs were working.

So we know that 4.19.* is sane. 5.4 and 5.10 are broken. At least for I2C
(the eocz may be a different and independent bug in newer kernels).

The nubs may sometimes get stuck but not always.

This is a good start for further interval reduction to see where it appeared
for the first time.

Unfortunately it is too sporadic for an automated git bisect.

BR,
Nikolaus

PS: one more observation - I can sometimes trigger it by pure
kernel/processor activity. But not systematically.

[  258.423004] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  258.512725] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  261.585876] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  261.597564] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  261.611022] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  261.624511] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  261.635620] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  261.646209] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  261.656921] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  261.667327] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  261.677093] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  261.984924] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  262.045715] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  264.430969] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  264.506317] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
^C
root at letux:~# ls -lR / >/dev/null 2>&1
[  321.575622] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  321.592681] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  321.972381] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  322.062255] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  324.412506] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  324.502258] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  327.575561] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  327.592315] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  327.972045] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  328.061950] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  330.492126] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  333.575469] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  333.592193] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  333.972290] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  334.062164] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  336.396118] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
[  342.478332] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
root at letux:~# ls -lR / >/dev/null 2>&1
root at letux:~# ls -lR / >/dev/null 2>&1
root at letux:~# ls -lR / >/dev/null 2>&1
[  462.491333] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
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:~# 


More information about the Letux-kernel mailing list