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

Grond grond66 at riseup.net
Mon Jan 10 17:46:33 CET 2022


On Sun, Jan 09, 2022 at 06:26:57PM +0100, H. Nikolaus Schaller wrote:
> Hi Stefan and Grond,
> 
> 
> > Am 08.01.2022 um 17:30 schrieb Stefan Leichter <sle85276 at gmx.de>:
> > 
> > Hello Grond,
> > 
> > On 07.01.22 23:01, Grond wrote:
> >> On Fri, Jan 07, 2022 at 09:17:50PM +0100, Stefan Leichter wrote:
> >>> Hi Grond,
> >>> 
> >>> I can wait longer between the startup an the ssh login, just suggest a duration.
> >>> 
> >>> If I first login at the console the playback device will appear directly at the first aplay call after the login, even if I did not wait for five minutes after starting the pandora.
> >> The reason I mention that it might be a timing issue is that the console
> >> login is not very well-coupled to the audio driver stack. It seems
> >> really unlikely that logging in on the console actually *causes* sound
> >> card probe to succeed. But I would be really interested to see what
> >> dmesg looks like after the sound card probe has succeeded. Also, if you
> >> could try compiling a kernel with DYNAMIC_DEBUG enabled, you can see all
> >> of the ASoC core debug messages, which I've found is really helpful in
> >> running down the root cause of why the sound card driver isn't loading.
> >> (I would suggest adding dyndbg="file sound/* +fp" to the kernel command
> >> line as well.)
> >> 
> > I don't see anything new in the dmesg output after the console login.
> 
> here is what I see when trying to ssh into the pandora while it is booting:
> 
> iMac:~ hns$ ssh root at 192.168.0.202 aplay -L
> ssh: connect to host 192.168.0.202 port 22: Connection refused
> iMac:~ hns$ ssh root at 192.168.0.202 aplay -L
> null
>     Discard all samples (playback) or generate zero samples (capture)
> default:CARD=omap3pandora
>     omap3pandora, HiFi Out pcm1773-hifi-0
>     Default Audio Device
> sysdefault:CARD=omap3pandora
>     omap3pandora, HiFi Out pcm1773-hifi-0
>     Default Audio Device
> dmix:CARD=omap3pandora,DEV=0
>     omap3pandora, HiFi Out pcm1773-hifi-0
>     Direct sample mixing device
> dsnoop:CARD=omap3pandora,DEV=0
>     omap3pandora, HiFi Out pcm1773-hifi-0
>     Direct sample snooping device
> hw:CARD=omap3pandora,DEV=0
>     omap3pandora, HiFi Out pcm1773-hifi-0
>     Direct hardware device without any conversions
> plughw:CARD=omap3pandora,DEV=0
>     omap3pandora, HiFi Out pcm1773-hifi-0
>     Hardware device with all software conversions
> iMac:~ hns$ ssh root at 192.168.0.202 uname -a
> Linux letux 5.16.0-rc8-letux+ #7911 SMP PREEMPT Sun Jan 9 16:14:23 CET 2022 armv7l GNU/Linux
> iMac:~ hns$ ssh root at 192.168.0.202 dmesg|fgrep 517
> [    0.000030] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 65535999984741ns
> [   11.474975] omap3pandora-sound omap3pandora-sound: Failed to register sound card: -517
> iMac:~ hns$ 
> 
> So, yes there is a (temporary) message "Failed to register sound card: -517"
> but the sound card is available when the first ssh succeeds (it is refused
> initially because the sshd isn't listening on port 22 yet).
> 
> I still see the 
> 
> [ 2438.947601] ti-soc-thermal 48002524.bandgap: eocz timed out waiting h
> [ 2583.399780] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
> 
> coming more in bursts - and unclear if it is related to ssh traffic over USB.
> The reason why I think about that is that it starts (sometimes) if I run
> apt-get update && apt-get upgrade over ssh. Or some git checkout. And stops when done.
> Or it may just happen on high processor load.

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, and the XUDF bit/i2c controller timeout messages
can be triggered just by moving the nubs slightly (even inadvertently).
You might want to try blacklisting the nub driver and see if you can
still trigger the timeout when using apt.

> 
> This all looks like an issue with power management/idling of the processor.
> Or some interrupt is blocked and not re-enabled.

I'm not so sure about this explanation. It does not explain how this bug
continues to crop up on my unit when running the original OpenPandora
3.2 kernel. Has anyone else tried running the original kernel after
encountering this bug? It presents slightly differently in that version;
there is no mention of "XUDF bit" (which is the result of a later errata
workaround failing) but the "omap_i2c.3: controller timed out" message
(which happens after the XUDF message on the letux kernel) likely
indicates that the same failure is present.

> 
> BR,
> Nikolaus
> 
> PS:
> 
> [ 1581.203582] ti-soc-thermal 48002524.bandgap: eocz timed out waiting high
> can be triggered every now and then by
> 
> 	while true; do cat /sys/class/thermal/thermal_zone0/temp; done
> 
> while
> [ 1583.790405] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
> can be treiggered sometimes by
> 
> 	apt-get update
> 
> On the other hand, a
> 
> 	wget -O /dev/null http://download.goldelico.com/letux-debian-rootfs/2021/20210825-jessie-8.11-i386-lxde.tbz
> 
> does not.

-- 

Attached is my PGP public key.
Primary key fingerprint: B7C7 AD66 D9AF 4348 0238  168E 2C53 D8FA 55D8 9FD9

If you have a PGP key (and a minute to spare)
please send it in reply to this email.

If you have no idea what PGP is, feel free
to ignore all this gobbledegook.


More information about the Letux-kernel mailing list