Hi Dave,
Am 25.10.24 um 18:56 schrieb Dave Stevenson:
On Fri, 25 Oct 2024 at 17:31, Stefan Wahren <wahrenst@xxxxxxx> wrote:
Hi Dave,
Am 25.10.24 um 16:38 schrieb Dave Stevenson:
Hi Stefan
On Fri, 25 Oct 2024 at 14:36, Stefan Wahren <wahrenst@xxxxxxx> wrote:
...
Based on that log I think your force_turbo=1 is a red-herring, or at
least needs further investigation.
Is this on a 3B, or 3B+?
Definitely a 3B+ from the year 2017 (mainline devicetree)
Snippets from your log as we resume:
[ 216.797764] PM: suspend exit
[ 216.800473] lan78xx 1-1.1.1:1.0 eth0: Link is Down
AFAIK only the 3B+ has a Microchip LAN7800
Absolutely right. I was heading down the wrong track there.
[ 216.804503] vc4-drm soc:gpu:
[drm:drm_helper_probe_single_connector_modes] [CONNECTOR:33:HDMI-A-1]
[ 216.804584] vc4-drm soc:gpu:
[drm:drm_helper_probe_single_connector_modes] [CONNECTOR:33:HDMI-A-1]
status updated from connected to disconnected
[ 216.804648] vc4-drm soc:gpu:
[drm:drm_helper_probe_single_connector_modes] [CONNECTOR:33:HDMI-A-1]
disconnected
- So hotplug has signalled disconnected
...
[ 216.816990] vc4-drm soc:gpu: [drm:drm_mode_setcrtc] [CONNECTOR:33:HDMI-A-1]
[ 216.817079] vc4-drm soc:gpu:
[drm:drm_atomic_helper_connector_hdmi_check] Trying with a 8 bpc
output
[ 216.817107] vc4-drm soc:gpu:
[drm:drm_atomic_helper_connector_hdmi_check] Trying RGB output format
[ 216.817166] vc4-drm soc:gpu:
[drm:drm_atomic_helper_connector_hdmi_check] RGB Format, checking the
constraints.
[ 216.817186] vc4-drm soc:gpu: [drm] HDMI Sink doesn't support RGB,
something's wrong.
- This is correct as the output is disconnected
...
[ 227.075847] vc4-drm soc:gpu: [drm:update_display_info.part.0]
[CONNECTOR:33:HDMI-A-1] HDMI: DVI dual 0, max TMDS clock 0 kHz
[ 227.075912] vc4-drm soc:gpu: [drm:update_display_info.part.0]
[CONNECTOR:33:HDMI-A-1] ELD monitor HP ZR2440w
[ 227.075942] vc4-drm soc:gpu: [drm:update_display_info.part.0]
[CONNECTOR:33:HDMI-A-1] HDMI: latency present 0 0, video latency 0 0,
audio latency 0 0
[ 227.075971] vc4-drm soc:gpu: [drm:update_display_info.part.0]
[CONNECTOR:33:HDMI-A-1] ELD size 36, SAD count 1
[ 227.076014] vc4-drm soc:gpu: [drm:output_poll_execute]
[CONNECTOR:33:HDMI-A-1] status updated from disconnected to connected
[ 227.076040] vc4-drm soc:gpu: [drm:output_poll_execute]
[CONNECTOR:33:HDMI-A-1] epoch counter 3 -> 4
[ 227.076072] vc4-drm soc:gpu: [drm:drm_sysfs_hotplug_event]
generating hotplug event
[ 227.076170] vc4-drm soc:gpu: [drm:drm_client_dev_hotplug] fbdev: ret=0
- We now get a connect again.
The 10 second interval is why I'm suspecting you're on a 3B - we have
no interrupts for the GPIO used there (expgpio 4), whereas we do on
3B+ (gpio 28). The poll period is 10seconds in the absence of
interrupts.
gpiochip0 - 54 lines:
line 0: "ID_SDA" unused input active-high
line 1: "ID_SCL" unused input active-high
line 2: "SDA1" unused input active-high
line 3: "SCL1" unused input active-high
...
line 27: "GPIO27" unused input active-high
line 28: "HDMI_HPD_N" "hpd" input active-low [used]
line 29: "STATUS_LED_G" "ACT" output active-high [used]
line 30: "CTS0" unused input active-high
In which case I'm totally bemused by the significant delay.
I'm not aware of any path in the software that can create this effect,
so it would point to the connected device (ie HDMI switch).
Another cause could be related to these messages from log:
[ 167.371865] NOHZ tick-stop error: local softirq work is pending,
handler #08!!!
[ 186.932178] NOHZ tick-stop error: local softirq work is pending,
handler #08!!!
Maybe this comes from the lan78xx driver? This messages doesn't occur in
the bad case.
Sorry, I missed a possible important information. The Raspberry Pi 3B+
is not directly connected to the display. There is a passive Logilink
HDMI switch in between.
Is it truly passive? That's unusual for anything handling high
bandwidth signals such as HDMI. Have you got a product link?
Maybe passive is the wrong wording here. I meant not powered by a power
supply.
http://www.logilink.de/media/datasheets/HD0006.pdf
There is a low current 5V supply available from all HDMI sources
(intended for the EDID EEPROM) which can power some of these devices.
We have also seen KVM switches do odd things when they lose the input
signal, as they try to find another active input.
On that suspend you were suspended for 16 seconds. Previous suspends
were for 9 and 12 seconds.
I waited 20 seconds multiple times with and without force_hdmi and
wasn't able to reproduce it more reliable. But I agree this not a prove.
Maybe this is caused by the HDMI switch. At the end this is not
critical. My only concern was that this is an in suspend/resume handling.
I will try need to investigate this ...Thanks for your help. Stefan
No problem. I'm interested in solving this one too.
Dave
