* Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
@ 2022-09-22 14:54 Marc Kleine-Budde
2022-09-22 15:06 ` Maxime Ripard
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: Marc Kleine-Budde @ 2022-09-22 14:54 UTC (permalink / raw)
To: Emma Anholt, Maxime Ripard, dri-devel, linux-rpi-kernel
[-- Attachment #1: Type: text/plain, Size: 5712 bytes --]
Hello,
I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
| [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
| [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
9-01)
| [ 0.000000] Machine model: Raspberry Pi 3 Model B+
| [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
As soon a the vc4 module is loaded the following warnings hits 4
times, then the machine stops.
| [ 66.839210] Console: switching to colour dummy device 80x25
| [ 66.861282] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
| [ 66.868418] ------------[ cut here ]------------
| [ 66.873110] WARNING: CPU: 3 PID: 611 at drivers/gpu/drm/vc4/vc4_hdmi_regs.h:456 vc4_hdmi_reset+0x3e8/0x540 [vc4]
| [ 66.883495] Modules linked in: vc4(+) ccm cpufreq_userspace cpufreq_powersave cpufreq_ondemand cpufreq_conservative nls_ascii nls_cp437 vfat fat ext4 mbcache jbd2 hci_uart btqca btrtl btbcm btintel btsdio bluetooth bcm2835_v4l2(C) bcm2835_mmal_vchiq(C) jitterentropy_rng
| videobuf2_vmalloc sha512_generic videobuf2_memops rt2800usb snd_soc_core videobuf2_v4l2 rt2x00usb microchip videobuf2_common snd_bcm2835(C) rt2800lib snd_pcm_dmaengine sha512_arm64 bridge videodev snd_pcm rt2x00lib snd_timer aes_neon_bs lan78xx mc cec stp snd mac80211 aes_n
| eon_blk rc_core brcmfmac llc drm_display_helper soundcore drm_cma_helper of_mdio cpufreq_dt drbg libarc4 fixed_phy drm_kms_helper brcmutil fwnode_mdio libphy ansi_cprng cfg80211 vchiq(C) ecdh_generic raspberrypi_cpufreq ecc bcm2835_rng crc16 bcm2835_thermal rng_core rfkill
| pwm_bcm2835 bcm2835_wdt leds_gpio fuse drm configfs lz4 lz4_compress zram zsmalloc ip_tables x_tables autofs4 btrfs blake2b_generic xor xor_neon raid6_pq zstd_compress libcrc32c
| [ 66.883758] crc32c_generic xxhash_generic dwc2 udc_core roles usbcore sdhci_iproc sdhci_pltfm crct10dif_ce crct10dif_common usb_common sdhci bcm2835 i2c_bcm2835 phy_generic
| [ 66.987722] CPU: 3 PID: 611 Comm: insmod Tainted: G C 5.19.0-1-arm64 #1 Debian 5.19.6-1
| [ 66.997253] Hardware name: Raspberry Pi 3 Model B+ (DT)
| [ 67.002549] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| [ 67.009610] pc : vc4_hdmi_reset+0x3e8/0x540 [vc4]
| [ 67.014426] lr : vc4_hdmi_reset+0x24/0x540 [vc4]
| [ 67.019153] sp : ffff80000ab83660
| [ 67.022510] x29: ffff80000ab83660 x28: 00000000055fd460 x27: ffff000009465080
| [ 67.029753] x26: 0000000000000000 x25: ffff800008fbe740 x24: ffff800009d582f0
| [ 67.036995] x23: ffff00000dabb000 x22: ffff000005144000 x21: ffff000013dc7180
| [ 67.044237] x20: 0000000000000000 x19: ffff000009465080 x18: ffffffffffffffff
| [ 67.051479] x17: 0000000000000000 x16: 0000000000000000 x15: ffff000013dc7f14
| [ 67.058721] x14: ffffffffffffffff x13: ffff000013dc7f10 x12: 0101010101010101
| [ 67.065963] x11: 0000000000000040 x10: fffffffff8858c10 x9 : ffff80000173ceb4
| [ 67.073205] x8 : 0101010101010101 x7 : 0000000000000000 x6 : ffff00000b3ad140
| [ 67.080447] x5 : ffff000009465ca8 x4 : 0000000000000000 x3 : ffff000009465ca8
| [ 67.087689] x2 : 0000000000000001 x1 : 0000000000000002 x0 : ffff800001753090
| [ 67.094932] Call trace:
| [ 67.097407] vc4_hdmi_reset+0x3e8/0x540 [vc4]
| [ 67.101869] vc4_hdmi_runtime_resume+0x74/0x360 [vc4]
| [ 67.107036] vc4_hdmi_bind+0x218/0xa20 [vc4]
| [ 67.111407] component_bind_all+0x130/0x290
| [ 67.115653] vc4_drm_bind+0x10c/0x2e0 [vc4]
| [ 67.119936] try_to_bring_up_aggregate_device+0x230/0x320
| [ 67.125411] component_master_add_with_match+0xd4/0x11c
| [ 67.130710] vc4_platform_drm_probe+0xd0/0x110 [vc4]
| [ 67.135787] platform_probe+0x74/0xf0
| [ 67.139501] really_probe+0x19c/0x3f0
| [ 67.143213] __driver_probe_device+0x11c/0x190
| [ 67.147719] driver_probe_device+0x44/0xf4
| [ 67.151872] __driver_attach+0xd8/0x220
| [ 67.155760] bus_for_each_dev+0x7c/0xe0
| [ 67.159649] driver_attach+0x30/0x40
| [ 67.163272] bus_add_driver+0x154/0x240
| [ 67.167162] driver_register+0x84/0x140
| [ 67.171051] __platform_driver_register+0x34/0x40
| [ 67.175821] vc4_drm_register+0x5c/0x1000 [vc4]
| [ 67.180456] do_one_initcall+0x50/0x240
| [ 67.184347] do_init_module+0x50/0x1fc
| [ 67.188150] load_module+0x1c5c/0x2060
| [ 67.191951] __do_sys_finit_module+0xac/0x130
| [ 67.196369] __arm64_sys_finit_module+0x2c/0x40
| [ 67.200964] invoke_syscall+0x50/0x120
| [ 67.204766] el0_svc_common.constprop.0+0x4c/0x100
| [ 67.209626] do_el0_svc+0x3c/0xd0
| [ 67.212987] el0_svc+0x3c/0x100
| [ 67.216174] el0t_64_sync_handler+0xbc/0x140
| [ 67.220502] el0t_64_sync+0x18c/0x190
| [ 67.224216] ---[ end trace 0000000000000000 ]---
| [ 67.228942] ------------[ cut here ]------------
Is this a known problem?
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-22 14:54 Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume() Marc Kleine-Budde
@ 2022-09-22 15:06 ` Maxime Ripard
2022-09-26 10:21 ` Marc Kleine-Budde
2022-09-22 16:19 ` Stefan Wahren
2022-09-27 7:51 ` Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume() #forregzbot Thorsten Leemhuis
2 siblings, 1 reply; 23+ messages in thread
From: Maxime Ripard @ 2022-09-22 15:06 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: dri-devel, Emma Anholt, linux-rpi-kernel
[-- Attachment #1: Type: text/plain, Size: 5805 bytes --]
Hi,
On Thu, Sep 22, 2022 at 04:54:48PM +0200, Marc Kleine-Budde wrote:
> Hello,
>
> I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
> using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
>
> | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
> 9-01)
> | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
> | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
>
> As soon a the vc4 module is loaded the following warnings hits 4
> times, then the machine stops.
>
> | [ 66.839210] Console: switching to colour dummy device 80x25
> | [ 66.861282] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
> | [ 66.868418] ------------[ cut here ]------------
> | [ 66.873110] WARNING: CPU: 3 PID: 611 at drivers/gpu/drm/vc4/vc4_hdmi_regs.h:456 vc4_hdmi_reset+0x3e8/0x540 [vc4]
> | [ 66.883495] Modules linked in: vc4(+) ccm cpufreq_userspace cpufreq_powersave cpufreq_ondemand cpufreq_conservative nls_ascii nls_cp437 vfat fat ext4 mbcache jbd2 hci_uart btqca btrtl btbcm btintel btsdio bluetooth bcm2835_v4l2(C) bcm2835_mmal_vchiq(C) jitterentropy_rng
> | videobuf2_vmalloc sha512_generic videobuf2_memops rt2800usb snd_soc_core videobuf2_v4l2 rt2x00usb microchip videobuf2_common snd_bcm2835(C) rt2800lib snd_pcm_dmaengine sha512_arm64 bridge videodev snd_pcm rt2x00lib snd_timer aes_neon_bs lan78xx mc cec stp snd mac80211 aes_n
> | eon_blk rc_core brcmfmac llc drm_display_helper soundcore drm_cma_helper of_mdio cpufreq_dt drbg libarc4 fixed_phy drm_kms_helper brcmutil fwnode_mdio libphy ansi_cprng cfg80211 vchiq(C) ecdh_generic raspberrypi_cpufreq ecc bcm2835_rng crc16 bcm2835_thermal rng_core rfkill
> | pwm_bcm2835 bcm2835_wdt leds_gpio fuse drm configfs lz4 lz4_compress zram zsmalloc ip_tables x_tables autofs4 btrfs blake2b_generic xor xor_neon raid6_pq zstd_compress libcrc32c
> | [ 66.883758] crc32c_generic xxhash_generic dwc2 udc_core roles usbcore sdhci_iproc sdhci_pltfm crct10dif_ce crct10dif_common usb_common sdhci bcm2835 i2c_bcm2835 phy_generic
> | [ 66.987722] CPU: 3 PID: 611 Comm: insmod Tainted: G C 5.19.0-1-arm64 #1 Debian 5.19.6-1
> | [ 66.997253] Hardware name: Raspberry Pi 3 Model B+ (DT)
> | [ 67.002549] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> | [ 67.009610] pc : vc4_hdmi_reset+0x3e8/0x540 [vc4]
> | [ 67.014426] lr : vc4_hdmi_reset+0x24/0x540 [vc4]
> | [ 67.019153] sp : ffff80000ab83660
> | [ 67.022510] x29: ffff80000ab83660 x28: 00000000055fd460 x27: ffff000009465080
> | [ 67.029753] x26: 0000000000000000 x25: ffff800008fbe740 x24: ffff800009d582f0
> | [ 67.036995] x23: ffff00000dabb000 x22: ffff000005144000 x21: ffff000013dc7180
> | [ 67.044237] x20: 0000000000000000 x19: ffff000009465080 x18: ffffffffffffffff
> | [ 67.051479] x17: 0000000000000000 x16: 0000000000000000 x15: ffff000013dc7f14
> | [ 67.058721] x14: ffffffffffffffff x13: ffff000013dc7f10 x12: 0101010101010101
> | [ 67.065963] x11: 0000000000000040 x10: fffffffff8858c10 x9 : ffff80000173ceb4
> | [ 67.073205] x8 : 0101010101010101 x7 : 0000000000000000 x6 : ffff00000b3ad140
> | [ 67.080447] x5 : ffff000009465ca8 x4 : 0000000000000000 x3 : ffff000009465ca8
> | [ 67.087689] x2 : 0000000000000001 x1 : 0000000000000002 x0 : ffff800001753090
> | [ 67.094932] Call trace:
> | [ 67.097407] vc4_hdmi_reset+0x3e8/0x540 [vc4]
> | [ 67.101869] vc4_hdmi_runtime_resume+0x74/0x360 [vc4]
> | [ 67.107036] vc4_hdmi_bind+0x218/0xa20 [vc4]
> | [ 67.111407] component_bind_all+0x130/0x290
> | [ 67.115653] vc4_drm_bind+0x10c/0x2e0 [vc4]
> | [ 67.119936] try_to_bring_up_aggregate_device+0x230/0x320
> | [ 67.125411] component_master_add_with_match+0xd4/0x11c
> | [ 67.130710] vc4_platform_drm_probe+0xd0/0x110 [vc4]
> | [ 67.135787] platform_probe+0x74/0xf0
> | [ 67.139501] really_probe+0x19c/0x3f0
> | [ 67.143213] __driver_probe_device+0x11c/0x190
> | [ 67.147719] driver_probe_device+0x44/0xf4
> | [ 67.151872] __driver_attach+0xd8/0x220
> | [ 67.155760] bus_for_each_dev+0x7c/0xe0
> | [ 67.159649] driver_attach+0x30/0x40
> | [ 67.163272] bus_add_driver+0x154/0x240
> | [ 67.167162] driver_register+0x84/0x140
> | [ 67.171051] __platform_driver_register+0x34/0x40
> | [ 67.175821] vc4_drm_register+0x5c/0x1000 [vc4]
> | [ 67.180456] do_one_initcall+0x50/0x240
> | [ 67.184347] do_init_module+0x50/0x1fc
> | [ 67.188150] load_module+0x1c5c/0x2060
> | [ 67.191951] __do_sys_finit_module+0xac/0x130
> | [ 67.196369] __arm64_sys_finit_module+0x2c/0x40
> | [ 67.200964] invoke_syscall+0x50/0x120
> | [ 67.204766] el0_svc_common.constprop.0+0x4c/0x100
> | [ 67.209626] do_el0_svc+0x3c/0xd0
> | [ 67.212987] el0_svc+0x3c/0x100
> | [ 67.216174] el0t_64_sync_handler+0xbc/0x140
> | [ 67.220502] el0t_64_sync+0x18c/0x190
> | [ 67.224216] ---[ end trace 0000000000000000 ]---
> | [ 67.228942] ------------[ cut here ]------------
>
> Is this a known problem?
The warning itself is fixed, both upstream and in stable (5.19.7). It
shouldn't have any relation to the hang though. Can you share your setup?
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-22 14:54 Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume() Marc Kleine-Budde
2022-09-22 15:06 ` Maxime Ripard
@ 2022-09-22 16:19 ` Stefan Wahren
2022-09-27 7:51 ` Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume() #forregzbot Thorsten Leemhuis
2 siblings, 0 replies; 23+ messages in thread
From: Stefan Wahren @ 2022-09-22 16:19 UTC (permalink / raw)
To: Marc Kleine-Budde, Emma Anholt, Maxime Ripard, dri-devel,
linux-rpi-kernel
Hi Marc,
Am 22.09.22 um 16:54 schrieb Marc Kleine-Budde:
> Hello,
>
> I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
> using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
>
> | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
> 9-01)
> | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
> | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
>
> As soon a the vc4 module is loaded the following warnings hits 4
> times, then the machine stops.
additionally to Maxime's reply, could you also please provide md5sum and
filesize of your bcm2837-rpi-3-b-plus.dtb
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-22 15:06 ` Maxime Ripard
@ 2022-09-26 10:21 ` Marc Kleine-Budde
2022-09-26 12:08 ` Stefan Wahren
0 siblings, 1 reply; 23+ messages in thread
From: Marc Kleine-Budde @ 2022-09-26 10:21 UTC (permalink / raw)
To: Maxime Ripard; +Cc: dri-devel, Emma Anholt, linux-rpi-kernel
[-- Attachment #1: Type: text/plain, Size: 2613 bytes --]
On 22.09.2022 17:06:00, Maxime Ripard wrote:
> > I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
> > using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
> >
> > | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> > | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
> > 9-01)
> > | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
> > | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
> >
> > As soon a the vc4 module is loaded the following warnings hits 4
> > times, then the machine stops.
[...]
> The warning itself is fixed, both upstream and in stable (5.19.7).
Ok. Debian is using 5.19.6
> It shouldn't have any relation to the hang though. Can you share your
> setup?
- config.txt:
-------->8-------->8-------->8-------->8--------
gpu_mem=16
disable_splash=1
arm_64bit=1
enable_uart=1
uart_2ndstage=1
os_prefix=/u-boot/
[pi3]
force_turbo=1
-------->8-------->8-------->8-------->8--------
- Raspberry Pi 3 Model B+
- no HDMI connected
- firmware 2022-03-24T13:21:11
which boot u-boot:
- u-boot 2022.04+dfsg-2+b1 (Debian testing)
I'm using the "/usr/lib/u-boot/rpi_3/u-boot.bin"
u-boot start:
- Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org)
kernel and dtb are unmodified Debian's linux-image-5.19.0-1-arm64
$ ls -l /boot/dtbs/5.19.0-1-arm64/broadcom/bcm2837-rpi-3-b-plus.dtb
-rwxr-xr-x 1 root root 15351 Sep 22 09:52 /boot/dtbs/5.19.0-1-arm64/broadcom/bcm2837-rpi-3-b-plus.dtb*
$ md5sum /boot/dtbs/5.19.0-1-arm64/broadcom/bcm2837-rpi-3-b-plus.dtb
4a9c76c3c4dcafac7d69872ee88ac5fc /boot/dtbs/5.19.0-1-arm64/broadcom/bcm2837-rpi-3-b-plus.dtb
- currently, I've blacklisted vc4, but systems hangs after modprobe vc4
(4x backtrace, then hang)
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-26 10:21 ` Marc Kleine-Budde
@ 2022-09-26 12:08 ` Stefan Wahren
2022-09-26 12:40 ` Marc Kleine-Budde
0 siblings, 1 reply; 23+ messages in thread
From: Stefan Wahren @ 2022-09-26 12:08 UTC (permalink / raw)
To: Marc Kleine-Budde, Maxime Ripard; +Cc: dri-devel, Emma Anholt, linux-rpi-kernel
Hi Marc,
Am 26.09.22 um 12:21 schrieb Marc Kleine-Budde:
> On 22.09.2022 17:06:00, Maxime Ripard wrote:
>>> I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
>>> using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
>>>
>>> | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
>>> | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
>>> 9-01)
>>> | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
>>> | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
>>>
>>> As soon a the vc4 module is loaded the following warnings hits 4
>>> times, then the machine stops.
> [...]
>
>> The warning itself is fixed, both upstream and in stable (5.19.7).
> Ok. Debian is using 5.19.6
>
>> It shouldn't have any relation to the hang though. Can you share your
>> setup?
> - config.txt:
>
> -------->8-------->8-------->8-------->8--------
> gpu_mem=16
> disable_splash=1
>
> arm_64bit=1
> enable_uart=1
> uart_2ndstage=1
>
> os_prefix=/u-boot/
>
> [pi3]
> force_turbo=1
> -------->8-------->8-------->8-------->8--------
>
> - Raspberry Pi 3 Model B+
> - no HDMI connected
Thanks
Does it mean, the issue only occurs without HDMI connected?
If you didn't test with HDMI yet, could you please do?
> - firmware 2022-03-24T13:21:11
> which boot u-boot:
> - u-boot 2022.04+dfsg-2+b1 (Debian testing)
> I'm using the "/usr/lib/u-boot/rpi_3/u-boot.bin"
> u-boot start:
> - Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org)
> kernel and dtb are unmodified Debian's linux-image-5.19.0-1-arm64
> $ ls -l /boot/dtbs/5.19.0-1-arm64/broadcom/bcm2837-rpi-3-b-plus.dtb
> -rwxr-xr-x 1 root root 15351 Sep 22 09:52 /boot/dtbs/5.19.0-1-arm64/broadcom/bcm2837-rpi-3-b-plus.dtb*
> $ md5sum /boot/dtbs/5.19.0-1-arm64/broadcom/bcm2837-rpi-3-b-plus.dtb
> 4a9c76c3c4dcafac7d69872ee88ac5fc /boot/dtbs/5.19.0-1-arm64/broadcom/bcm2837-rpi-3-b-plus.dtb
> - currently, I've blacklisted vc4, but systems hangs after modprobe vc4
> (4x backtrace, then hang)
>
> regards,
> Marc
>
>
> _______________________________________________
> linux-rpi-kernel mailing list
> linux-rpi-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-26 12:08 ` Stefan Wahren
@ 2022-09-26 12:40 ` Marc Kleine-Budde
2022-09-26 12:47 ` Maxime Ripard
0 siblings, 1 reply; 23+ messages in thread
From: Marc Kleine-Budde @ 2022-09-26 12:40 UTC (permalink / raw)
To: Stefan Wahren; +Cc: dri-devel, Maxime Ripard, Emma Anholt, linux-rpi-kernel
[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]
On 26.09.2022 14:08:04, Stefan Wahren wrote:
> Hi Marc,
>
> Am 26.09.22 um 12:21 schrieb Marc Kleine-Budde:
> > On 22.09.2022 17:06:00, Maxime Ripard wrote:
> > > > I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
> > > > using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
> > > >
> > > > | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> > > > | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
> > > > 9-01)
> > > > | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
> > > > | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
> > > >
> > > > As soon a the vc4 module is loaded the following warnings hits 4
> > > > times, then the machine stops.
> > [...]
> >
> > > The warning itself is fixed, both upstream and in stable (5.19.7).
> > Ok. Debian is using 5.19.6
> >
> > > It shouldn't have any relation to the hang though. Can you share your
> > > setup?
> > - config.txt:
> >
> > -------->8-------->8-------->8-------->8--------
> > gpu_mem=16
> > disable_splash=1
> >
> > arm_64bit=1
> > enable_uart=1
> > uart_2ndstage=1
> >
> > os_prefix=/u-boot/
> >
> > [pi3]
> > force_turbo=1
> > -------->8-------->8-------->8-------->8--------
> >
> > - Raspberry Pi 3 Model B+
> > - no HDMI connected
>
> Does it mean, the issue only occurs without HDMI connected?
> If you didn't test with HDMI yet, could you please do?
The error occurs with HDMI not connected, as vc4 is the gfx driver I
thought this might be of interest. :)
I don't have a HDMI monitor here, but I'll come back to you as soon as I
get access to one (might take some time).
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-26 12:40 ` Marc Kleine-Budde
@ 2022-09-26 12:47 ` Maxime Ripard
2022-09-26 18:50 ` Stefan Wahren
0 siblings, 1 reply; 23+ messages in thread
From: Maxime Ripard @ 2022-09-26 12:47 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: Stefan Wahren, dri-devel, Emma Anholt, linux-rpi-kernel
[-- Attachment #1: Type: text/plain, Size: 2177 bytes --]
On Mon, Sep 26, 2022 at 02:40:48PM +0200, Marc Kleine-Budde wrote:
> On 26.09.2022 14:08:04, Stefan Wahren wrote:
> > Hi Marc,
> >
> > Am 26.09.22 um 12:21 schrieb Marc Kleine-Budde:
> > > On 22.09.2022 17:06:00, Maxime Ripard wrote:
> > > > > I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
> > > > > using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
> > > > >
> > > > > | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> > > > > | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
> > > > > 9-01)
> > > > > | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
> > > > > | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
> > > > >
> > > > > As soon a the vc4 module is loaded the following warnings hits 4
> > > > > times, then the machine stops.
> > > [...]
> > >
> > > > The warning itself is fixed, both upstream and in stable (5.19.7).
> > > Ok. Debian is using 5.19.6
> > >
> > > > It shouldn't have any relation to the hang though. Can you share your
> > > > setup?
> > > - config.txt:
> > >
> > > -------->8-------->8-------->8-------->8--------
> > > gpu_mem=16
> > > disable_splash=1
> > >
> > > arm_64bit=1
> > > enable_uart=1
> > > uart_2ndstage=1
> > >
> > > os_prefix=/u-boot/
> > >
> > > [pi3]
> > > force_turbo=1
> > > -------->8-------->8-------->8-------->8--------
> > >
> > > - Raspberry Pi 3 Model B+
> > > - no HDMI connected
> >
> > Does it mean, the issue only occurs without HDMI connected?
> > If you didn't test with HDMI yet, could you please do?
>
> The error occurs with HDMI not connected, as vc4 is the gfx driver I
> thought this might be of interest. :)
>
> I don't have a HDMI monitor here, but I'll come back to you as soon as I
> get access to one (might take some time).
It's not the first time an issue like this one would occur. I'm trying
to make my Pi3 boot again, and will try to bisect the issue.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-26 12:47 ` Maxime Ripard
@ 2022-09-26 18:50 ` Stefan Wahren
2022-09-27 7:25 ` Maxime Ripard
0 siblings, 1 reply; 23+ messages in thread
From: Stefan Wahren @ 2022-09-26 18:50 UTC (permalink / raw)
To: Maxime Ripard, Marc Kleine-Budde; +Cc: dri-devel, Emma Anholt, linux-rpi-kernel
Hi Maxime,
Am 26.09.22 um 14:47 schrieb Maxime Ripard:
> On Mon, Sep 26, 2022 at 02:40:48PM +0200, Marc Kleine-Budde wrote:
>> On 26.09.2022 14:08:04, Stefan Wahren wrote:
>>> Hi Marc,
>>>
>>> Am 26.09.22 um 12:21 schrieb Marc Kleine-Budde:
>>>> On 22.09.2022 17:06:00, Maxime Ripard wrote:
>>>>>> I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
>>>>>> using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
>>>>>>
>>>>>> | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
>>>>>> | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
>>>>>> 9-01)
>>>>>> | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
>>>>>> | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
>>>>>>
>>>>>> As soon a the vc4 module is loaded the following warnings hits 4
>>>>>> times, then the machine stops.
>>>> [...]
>>>>
>>>>> The warning itself is fixed, both upstream and in stable (5.19.7).
>>>> Ok. Debian is using 5.19.6
>>>>
>>>>> It shouldn't have any relation to the hang though. Can you share your
>>>>> setup?
>>>> - config.txt:
>>>>
>>>> -------->8-------->8-------->8-------->8--------
>>>> gpu_mem=16
>>>> disable_splash=1
>>>>
>>>> arm_64bit=1
>>>> enable_uart=1
>>>> uart_2ndstage=1
>>>>
>>>> os_prefix=/u-boot/
>>>>
>>>> [pi3]
>>>> force_turbo=1
>>>> -------->8-------->8-------->8-------->8--------
>>>>
>>>> - Raspberry Pi 3 Model B+
>>>> - no HDMI connected
>>> Does it mean, the issue only occurs without HDMI connected?
>>> If you didn't test with HDMI yet, could you please do?
>> The error occurs with HDMI not connected, as vc4 is the gfx driver I
>> thought this might be of interest. :)
>>
>> I don't have a HDMI monitor here, but I'll come back to you as soon as I
>> get access to one (might take some time).
> It's not the first time an issue like this one would occur. I'm trying
> to make my Pi3 boot again, and will try to bisect the issue.
yes the issue is only triggered without HDMI connected. I was able to
reproduce with an older vc4 firmware from 2020 (don't want to upgrade
yet). Kernel was also an arm64 build with defconfig.
Here some rough starting point for bisection:
5.18.0 good
5.19.0 bad
5.19.6 bad
>
> Maxime
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-26 18:50 ` Stefan Wahren
@ 2022-09-27 7:25 ` Maxime Ripard
2022-09-27 8:56 ` Stefan Wahren
2022-09-27 9:42 ` Maxime Ripard
0 siblings, 2 replies; 23+ messages in thread
From: Maxime Ripard @ 2022-09-27 7:25 UTC (permalink / raw)
To: Stefan Wahren; +Cc: Marc Kleine-Budde, dri-devel, Emma Anholt, linux-rpi-kernel
Hi Stefan,
On Mon, Sep 26, 2022 at 08:50:12PM +0200, Stefan Wahren wrote:
> Am 26.09.22 um 14:47 schrieb Maxime Ripard:
> > On Mon, Sep 26, 2022 at 02:40:48PM +0200, Marc Kleine-Budde wrote:
> > > On 26.09.2022 14:08:04, Stefan Wahren wrote:
> > > > Hi Marc,
> > > >
> > > > Am 26.09.22 um 12:21 schrieb Marc Kleine-Budde:
> > > > > On 22.09.2022 17:06:00, Maxime Ripard wrote:
> > > > > > > I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
> > > > > > > using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
> > > > > > >
> > > > > > > | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> > > > > > > | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
> > > > > > > 9-01)
> > > > > > > | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
> > > > > > > | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
> > > > > > >
> > > > > > > As soon a the vc4 module is loaded the following warnings hits 4
> > > > > > > times, then the machine stops.
> > > > > [...]
> > > > >
> > > > > > The warning itself is fixed, both upstream and in stable (5.19.7).
> > > > > Ok. Debian is using 5.19.6
> > > > >
> > > > > > It shouldn't have any relation to the hang though. Can you share your
> > > > > > setup?
> > > > > - config.txt:
> > > > >
> > > > > -------->8-------->8-------->8-------->8--------
> > > > > gpu_mem=16
> > > > > disable_splash=1
> > > > >
> > > > > arm_64bit=1
> > > > > enable_uart=1
> > > > > uart_2ndstage=1
> > > > >
> > > > > os_prefix=/u-boot/
> > > > >
> > > > > [pi3]
> > > > > force_turbo=1
> > > > > -------->8-------->8-------->8-------->8--------
> > > > >
> > > > > - Raspberry Pi 3 Model B+
> > > > > - no HDMI connected
> > > > Does it mean, the issue only occurs without HDMI connected?
> > > > If you didn't test with HDMI yet, could you please do?
> > > The error occurs with HDMI not connected, as vc4 is the gfx driver I
> > > thought this might be of interest. :)
> > >
> > > I don't have a HDMI monitor here, but I'll come back to you as soon as I
> > > get access to one (might take some time).
> > It's not the first time an issue like this one would occur. I'm trying
> > to make my Pi3 boot again, and will try to bisect the issue.
>
> yes the issue is only triggered without HDMI connected. I was able to
> reproduce with an older vc4 firmware from 2020 (don't want to upgrade yet).
> Kernel was also an arm64 build with defconfig.
>
> Here some rough starting point for bisection:
>
> 5.18.0 good
> 5.19.0 bad
> 5.19.6 bad
Sorry it took a bit of time, it looks like I found another bug while
trying to test this yesterday.
Your datapoints are interesting though. I have a custom configuration
and it does boot 5.19 without an HDMI connected.
So I guess it leaves us with either the firmware version being different
(I'm using a newer version, from March 2022), or the configuration. I'll
test with defconfig.
Maxime
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume() #forregzbot
2022-09-22 14:54 Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume() Marc Kleine-Budde
2022-09-22 15:06 ` Maxime Ripard
2022-09-22 16:19 ` Stefan Wahren
@ 2022-09-27 7:51 ` Thorsten Leemhuis
2 siblings, 0 replies; 23+ messages in thread
From: Thorsten Leemhuis @ 2022-09-27 7:51 UTC (permalink / raw)
To: dri-devel, linux-rpi-kernel, regressions
TWIMC: this mail is primarily send for documentation purposes and for
regzbot, my Linux kernel regression tracking bot. These mails usually
contain '#forregzbot' in the subject, to make them easy to spot and filter.
[TLDR: I'm adding this regression report to the list of tracked
regressions; all text from me you find below is based on a few templates
paragraphs you might have encountered already already in similar form.]
Hi, this is your Linux kernel regression tracker.
On 22.09.22 16:54, Marc Kleine-Budde wrote:
> Hello,
>
> I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
> using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
>
> | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
> 9-01)
> | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
> | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
>
> As soon a the vc4 module is loaded the following warnings hits 4
> times, then the machine stops.
>
> | [ 66.839210] Console: switching to colour dummy device 80x25
> | [ 66.861282] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
> | [ 66.868418] ------------[ cut here ]------------
> | [ 66.873110] WARNING: CPU: 3 PID: 611 at drivers/gpu/drm/vc4/vc4_hdmi_regs.h:456 vc4_hdmi_reset+0x3e8/0x540 [vc4]
> | [ 66.883495] Modules linked in: vc4(+) ccm cpufreq_userspace cpufreq_powersave cpufreq_ondemand cpufreq_conservative nls_ascii nls_cp437 vfat fat ext4 mbcache jbd2 hci_uart btqca btrtl btbcm btintel btsdio bluetooth bcm2835_v4l2(C) bcm2835_mmal_vchiq(C) jitterentropy_rng
> | videobuf2_vmalloc sha512_generic videobuf2_memops rt2800usb snd_soc_core videobuf2_v4l2 rt2x00usb microchip videobuf2_common snd_bcm2835(C) rt2800lib snd_pcm_dmaengine sha512_arm64 bridge videodev snd_pcm rt2x00lib snd_timer aes_neon_bs lan78xx mc cec stp snd mac80211 aes_n
> | eon_blk rc_core brcmfmac llc drm_display_helper soundcore drm_cma_helper of_mdio cpufreq_dt drbg libarc4 fixed_phy drm_kms_helper brcmutil fwnode_mdio libphy ansi_cprng cfg80211 vchiq(C) ecdh_generic raspberrypi_cpufreq ecc bcm2835_rng crc16 bcm2835_thermal rng_core rfkill
> | pwm_bcm2835 bcm2835_wdt leds_gpio fuse drm configfs lz4 lz4_compress zram zsmalloc ip_tables x_tables autofs4 btrfs blake2b_generic xor xor_neon raid6_pq zstd_compress libcrc32c
> | [ 66.883758] crc32c_generic xxhash_generic dwc2 udc_core roles usbcore sdhci_iproc sdhci_pltfm crct10dif_ce crct10dif_common usb_common sdhci bcm2835 i2c_bcm2835 phy_generic
> | [ 66.987722] CPU: 3 PID: 611 Comm: insmod Tainted: G C 5.19.0-1-arm64 #1 Debian 5.19.6-1
> | [ 66.997253] Hardware name: Raspberry Pi 3 Model B+ (DT)
> | [ 67.002549] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> | [ 67.009610] pc : vc4_hdmi_reset+0x3e8/0x540 [vc4]
> | [ 67.014426] lr : vc4_hdmi_reset+0x24/0x540 [vc4]
> | [ 67.019153] sp : ffff80000ab83660
> | [ 67.022510] x29: ffff80000ab83660 x28: 00000000055fd460 x27: ffff000009465080
> | [ 67.029753] x26: 0000000000000000 x25: ffff800008fbe740 x24: ffff800009d582f0
> | [ 67.036995] x23: ffff00000dabb000 x22: ffff000005144000 x21: ffff000013dc7180
> | [ 67.044237] x20: 0000000000000000 x19: ffff000009465080 x18: ffffffffffffffff
> | [ 67.051479] x17: 0000000000000000 x16: 0000000000000000 x15: ffff000013dc7f14
> | [ 67.058721] x14: ffffffffffffffff x13: ffff000013dc7f10 x12: 0101010101010101
> | [ 67.065963] x11: 0000000000000040 x10: fffffffff8858c10 x9 : ffff80000173ceb4
> | [ 67.073205] x8 : 0101010101010101 x7 : 0000000000000000 x6 : ffff00000b3ad140
> | [ 67.080447] x5 : ffff000009465ca8 x4 : 0000000000000000 x3 : ffff000009465ca8
> | [ 67.087689] x2 : 0000000000000001 x1 : 0000000000000002 x0 : ffff800001753090
> | [ 67.094932] Call trace:
> | [ 67.097407] vc4_hdmi_reset+0x3e8/0x540 [vc4]
> | [ 67.101869] vc4_hdmi_runtime_resume+0x74/0x360 [vc4]
> | [ 67.107036] vc4_hdmi_bind+0x218/0xa20 [vc4]
> | [ 67.111407] component_bind_all+0x130/0x290
> | [ 67.115653] vc4_drm_bind+0x10c/0x2e0 [vc4]
> | [ 67.119936] try_to_bring_up_aggregate_device+0x230/0x320
> | [ 67.125411] component_master_add_with_match+0xd4/0x11c
> | [ 67.130710] vc4_platform_drm_probe+0xd0/0x110 [vc4]
> | [ 67.135787] platform_probe+0x74/0xf0
> | [ 67.139501] really_probe+0x19c/0x3f0
> | [ 67.143213] __driver_probe_device+0x11c/0x190
> | [ 67.147719] driver_probe_device+0x44/0xf4
> | [ 67.151872] __driver_attach+0xd8/0x220
> | [ 67.155760] bus_for_each_dev+0x7c/0xe0
> | [ 67.159649] driver_attach+0x30/0x40
> | [ 67.163272] bus_add_driver+0x154/0x240
> | [ 67.167162] driver_register+0x84/0x140
> | [ 67.171051] __platform_driver_register+0x34/0x40
> | [ 67.175821] vc4_drm_register+0x5c/0x1000 [vc4]
> | [ 67.180456] do_one_initcall+0x50/0x240
> | [ 67.184347] do_init_module+0x50/0x1fc
> | [ 67.188150] load_module+0x1c5c/0x2060
> | [ 67.191951] __do_sys_finit_module+0xac/0x130
> | [ 67.196369] __arm64_sys_finit_module+0x2c/0x40
> | [ 67.200964] invoke_syscall+0x50/0x120
> | [ 67.204766] el0_svc_common.constprop.0+0x4c/0x100
> | [ 67.209626] do_el0_svc+0x3c/0xd0
> | [ 67.212987] el0_svc+0x3c/0x100
> | [ 67.216174] el0t_64_sync_handler+0xbc/0x140
> | [ 67.220502] el0t_64_sync+0x18c/0x190
> | [ 67.224216] ---[ end trace 0000000000000000 ]---
> | [ 67.228942] ------------[ cut here ]------------
>
> Is this a known problem?
Thanks for the report. To be sure below issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression
tracking bot:
#regzbot ^introduced v5.18..v5.19
#regzbot title dri: vc4: Raspberry Pi 3 Model B+ hangs in
vc4_hdmi_runtime_resume()
#regzbot ignore-activity
This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply -- ideally with also
telling regzbot about it, as explained here:
https://linux-regtracking.leemhuis.info/tracked-regression/
Reminder for developers: When fixing the issue, add 'Link:' tags
pointing to the report (the mail this one replies to), as explained for
in the Linux kernel's documentation; above webpage explains why this is
important for tracked regressions.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-27 7:25 ` Maxime Ripard
@ 2022-09-27 8:56 ` Stefan Wahren
2022-09-27 9:42 ` Maxime Ripard
1 sibling, 0 replies; 23+ messages in thread
From: Stefan Wahren @ 2022-09-27 8:56 UTC (permalink / raw)
To: Maxime Ripard
Cc: regressions, Marc Kleine-Budde, dri-devel, Emma Anholt, linux-rpi-kernel
Hi Maxime,
Am 27.09.22 um 09:25 schrieb Maxime Ripard:
> Hi Stefan,
>
> On Mon, Sep 26, 2022 at 08:50:12PM +0200, Stefan Wahren wrote:
>> Am 26.09.22 um 14:47 schrieb Maxime Ripard:
>>> On Mon, Sep 26, 2022 at 02:40:48PM +0200, Marc Kleine-Budde wrote:
>>>> On 26.09.2022 14:08:04, Stefan Wahren wrote:
>>>>> Hi Marc,
>>>>>
>>>>> Am 26.09.22 um 12:21 schrieb Marc Kleine-Budde:
>>>>>> On 22.09.2022 17:06:00, Maxime Ripard wrote:
>>>>>>>> I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
>>>>>>>> using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
>>>>>>>>
>>>>>>>> | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
>>>>>>>> | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
>>>>>>>> 9-01)
>>>>>>>> | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
>>>>>>>> | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
>>>>>>>>
>>>>>>>> As soon a the vc4 module is loaded the following warnings hits 4
>>>>>>>> times, then the machine stops.
>>>>>> [...]
>>>>>>
>>>>>>> The warning itself is fixed, both upstream and in stable (5.19.7).
>>>>>> Ok. Debian is using 5.19.6
>>>>>>
>>>>>>> It shouldn't have any relation to the hang though. Can you share your
>>>>>>> setup?
>>>>>> - config.txt:
>>>>>>
>>>>>> -------->8-------->8-------->8-------->8--------
>>>>>> gpu_mem=16
>>>>>> disable_splash=1
>>>>>>
>>>>>> arm_64bit=1
>>>>>> enable_uart=1
>>>>>> uart_2ndstage=1
>>>>>>
>>>>>> os_prefix=/u-boot/
>>>>>>
>>>>>> [pi3]
>>>>>> force_turbo=1
>>>>>> -------->8-------->8-------->8-------->8--------
>>>>>>
>>>>>> - Raspberry Pi 3 Model B+
>>>>>> - no HDMI connected
>>>>> Does it mean, the issue only occurs without HDMI connected?
>>>>> If you didn't test with HDMI yet, could you please do?
>>>> The error occurs with HDMI not connected, as vc4 is the gfx driver I
>>>> thought this might be of interest. :)
>>>>
>>>> I don't have a HDMI monitor here, but I'll come back to you as soon as I
>>>> get access to one (might take some time).
>>> It's not the first time an issue like this one would occur. I'm trying
>>> to make my Pi3 boot again, and will try to bisect the issue.
>> yes the issue is only triggered without HDMI connected. I was able to
>> reproduce with an older vc4 firmware from 2020 (don't want to upgrade yet).
>> Kernel was also an arm64 build with defconfig.
>>
>> Here some rough starting point for bisection:
>>
>> 5.18.0 good
>> 5.19.0 bad
>> 5.19.6 bad
> Sorry it took a bit of time, it looks like I found another bug while
> trying to test this yesterday.
>
> Your datapoints are interesting though. I have a custom configuration
> and it does boot 5.19 without an HDMI connected.
i will try to bisect this, too.
>
> So I guess it leaves us with either the firmware version being different
> (I'm using a newer version, from March 2022), or the configuration. I'll
> test with defconfig.
>
> Maxime
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-27 7:25 ` Maxime Ripard
2022-09-27 8:56 ` Stefan Wahren
@ 2022-09-27 9:42 ` Maxime Ripard
2022-09-27 11:12 ` Stefan Wahren
1 sibling, 1 reply; 23+ messages in thread
From: Maxime Ripard @ 2022-09-27 9:42 UTC (permalink / raw)
To: Stefan Wahren; +Cc: Marc Kleine-Budde, dri-devel, Emma Anholt, linux-rpi-kernel
On Tue, Sep 27, 2022 at 09:25:54AM +0200, Maxime Ripard wrote:
> Hi Stefan,
>
> On Mon, Sep 26, 2022 at 08:50:12PM +0200, Stefan Wahren wrote:
> > Am 26.09.22 um 14:47 schrieb Maxime Ripard:
> > > On Mon, Sep 26, 2022 at 02:40:48PM +0200, Marc Kleine-Budde wrote:
> > > > On 26.09.2022 14:08:04, Stefan Wahren wrote:
> > > > > Hi Marc,
> > > > >
> > > > > Am 26.09.22 um 12:21 schrieb Marc Kleine-Budde:
> > > > > > On 22.09.2022 17:06:00, Maxime Ripard wrote:
> > > > > > > > I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
> > > > > > > > using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
> > > > > > > >
> > > > > > > > | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> > > > > > > > | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
> > > > > > > > 9-01)
> > > > > > > > | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
> > > > > > > > | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
> > > > > > > >
> > > > > > > > As soon a the vc4 module is loaded the following warnings hits 4
> > > > > > > > times, then the machine stops.
> > > > > > [...]
> > > > > >
> > > > > > > The warning itself is fixed, both upstream and in stable (5.19.7).
> > > > > > Ok. Debian is using 5.19.6
> > > > > >
> > > > > > > It shouldn't have any relation to the hang though. Can you share your
> > > > > > > setup?
> > > > > > - config.txt:
> > > > > >
> > > > > > -------->8-------->8-------->8-------->8--------
> > > > > > gpu_mem=16
> > > > > > disable_splash=1
> > > > > >
> > > > > > arm_64bit=1
> > > > > > enable_uart=1
> > > > > > uart_2ndstage=1
> > > > > >
> > > > > > os_prefix=/u-boot/
> > > > > >
> > > > > > [pi3]
> > > > > > force_turbo=1
> > > > > > -------->8-------->8-------->8-------->8--------
> > > > > >
> > > > > > - Raspberry Pi 3 Model B+
> > > > > > - no HDMI connected
> > > > > Does it mean, the issue only occurs without HDMI connected?
> > > > > If you didn't test with HDMI yet, could you please do?
> > > > The error occurs with HDMI not connected, as vc4 is the gfx driver I
> > > > thought this might be of interest. :)
> > > >
> > > > I don't have a HDMI monitor here, but I'll come back to you as soon as I
> > > > get access to one (might take some time).
> > > It's not the first time an issue like this one would occur. I'm trying
> > > to make my Pi3 boot again, and will try to bisect the issue.
> >
> > yes the issue is only triggered without HDMI connected. I was able to
> > reproduce with an older vc4 firmware from 2020 (don't want to upgrade yet).
> > Kernel was also an arm64 build with defconfig.
> >
> > Here some rough starting point for bisection:
> >
> > 5.18.0 good
> > 5.19.0 bad
> > 5.19.6 bad
>
> Sorry it took a bit of time, it looks like I found another bug while
> trying to test this yesterday.
>
> Your datapoints are interesting though. I have a custom configuration
> and it does boot 5.19 without an HDMI connected.
>
> So I guess it leaves us with either the firmware version being different
> (I'm using a newer version, from March 2022), or the configuration. I'll
> test with defconfig.
So it turns out compiling vc4 as a module is the culprit.
It's not clear to me why at this point, but the first register write in
vc4_hdmi_reset stalls.
Maxime
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-27 9:42 ` Maxime Ripard
@ 2022-09-27 11:12 ` Stefan Wahren
2022-09-27 11:36 ` Marc Kleine-Budde
2022-09-27 11:42 ` Maxime Ripard
0 siblings, 2 replies; 23+ messages in thread
From: Stefan Wahren @ 2022-09-27 11:12 UTC (permalink / raw)
To: Maxime Ripard; +Cc: Marc Kleine-Budde, dri-devel, Emma Anholt, linux-rpi-kernel
Am 27.09.22 um 11:42 schrieb Maxime Ripard:
> On Tue, Sep 27, 2022 at 09:25:54AM +0200, Maxime Ripard wrote:
>> Hi Stefan,
>>
>> On Mon, Sep 26, 2022 at 08:50:12PM +0200, Stefan Wahren wrote:
>>> Am 26.09.22 um 14:47 schrieb Maxime Ripard:
>>>> On Mon, Sep 26, 2022 at 02:40:48PM +0200, Marc Kleine-Budde wrote:
>>>>> On 26.09.2022 14:08:04, Stefan Wahren wrote:
>>>>>> Hi Marc,
>>>>>>
>>>>>> Am 26.09.22 um 12:21 schrieb Marc Kleine-Budde:
>>>>>>> On 22.09.2022 17:06:00, Maxime Ripard wrote:
>>>>>>>>> I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
>>>>>>>>> using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
>>>>>>>>>
>>>>>>>>> | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
>>>>>>>>> | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
>>>>>>>>> 9-01)
>>>>>>>>> | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
>>>>>>>>> | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
>>>>>>>>>
>>>>>>>>> As soon a the vc4 module is loaded the following warnings hits 4
>>>>>>>>> times, then the machine stops.
>>>>>>> [...]
>>>>>>>
>>>>>>>> The warning itself is fixed, both upstream and in stable (5.19.7).
>>>>>>> Ok. Debian is using 5.19.6
>>>>>>>
>>>>>>>> It shouldn't have any relation to the hang though. Can you share your
>>>>>>>> setup?
>>>>>>> - config.txt:
>>>>>>>
>>>>>>> -------->8-------->8-------->8-------->8--------
>>>>>>> gpu_mem=16
>>>>>>> disable_splash=1
>>>>>>>
>>>>>>> arm_64bit=1
>>>>>>> enable_uart=1
>>>>>>> uart_2ndstage=1
>>>>>>>
>>>>>>> os_prefix=/u-boot/
>>>>>>>
>>>>>>> [pi3]
>>>>>>> force_turbo=1
>>>>>>> -------->8-------->8-------->8-------->8--------
>>>>>>>
>>>>>>> - Raspberry Pi 3 Model B+
>>>>>>> - no HDMI connected
>>>>>> Does it mean, the issue only occurs without HDMI connected?
>>>>>> If you didn't test with HDMI yet, could you please do?
>>>>> The error occurs with HDMI not connected, as vc4 is the gfx driver I
>>>>> thought this might be of interest. :)
>>>>>
>>>>> I don't have a HDMI monitor here, but I'll come back to you as soon as I
>>>>> get access to one (might take some time).
>>>> It's not the first time an issue like this one would occur. I'm trying
>>>> to make my Pi3 boot again, and will try to bisect the issue.
>>> yes the issue is only triggered without HDMI connected. I was able to
>>> reproduce with an older vc4 firmware from 2020 (don't want to upgrade yet).
>>> Kernel was also an arm64 build with defconfig.
>>>
>>> Here some rough starting point for bisection:
>>>
>>> 5.18.0 good
>>> 5.19.0 bad
>>> 5.19.6 bad
>> Sorry it took a bit of time, it looks like I found another bug while
>> trying to test this yesterday.
>>
>> Your datapoints are interesting though. I have a custom configuration
>> and it does boot 5.19 without an HDMI connected.
>>
>> So I guess it leaves us with either the firmware version being different
>> (I'm using a newer version, from March 2022), or the configuration. I'll
>> test with defconfig.
> So it turns out compiling vc4 as a module is the culprit.
Do you mean regardless of the kernel version in your case?
In my test cases i build vc4 always as module.
> It's not clear to me why at this point, but the first register write in
> vc4_hdmi_reset stalls.
Sounds like timing issue or a missing dependency (clock or power domain)
>
> Maxime
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-27 11:12 ` Stefan Wahren
@ 2022-09-27 11:36 ` Marc Kleine-Budde
2022-09-27 11:42 ` Maxime Ripard
1 sibling, 0 replies; 23+ messages in thread
From: Marc Kleine-Budde @ 2022-09-27 11:36 UTC (permalink / raw)
To: Stefan Wahren; +Cc: dri-devel, Maxime Ripard, Emma Anholt, linux-rpi-kernel
[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]
On 27.09.2022 13:12:35, Stefan Wahren wrote:
> > > > yes the issue is only triggered without HDMI connected. I was able to
> > > > reproduce with an older vc4 firmware from 2020 (don't want to upgrade yet).
> > > > Kernel was also an arm64 build with defconfig.
> > > >
> > > > Here some rough starting point for bisection:
> > > >
> > > > 5.18.0 good
> > > > 5.19.0 bad
> > > > 5.19.6 bad
> > > Sorry it took a bit of time, it looks like I found another bug while
> > > trying to test this yesterday.
> > >
> > > Your datapoints are interesting though. I have a custom configuration
> > > and it does boot 5.19 without an HDMI connected.
> > >
> > > So I guess it leaves us with either the firmware version being different
> > > (I'm using a newer version, from March 2022), or the configuration. I'll
> > > test with defconfig.
> > So it turns out compiling vc4 as a module is the culprit.
>
> Do you mean regardless of the kernel version in your case?
On Debian vc4 is a module, too, both on 5.18.x (good) and 5.19.6 (bad).
> In my test cases i build vc4 always as module.
>
> > It's not clear to me why at this point, but the first register write in
> > vc4_hdmi_reset stalls.
>
> Sounds like timing issue or a missing dependency (clock or power domain)
Here it fails 100%, regardless if the module is automatically loaded by
udev or later on an idle system via insmod.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 484 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-27 11:12 ` Stefan Wahren
2022-09-27 11:36 ` Marc Kleine-Budde
@ 2022-09-27 11:42 ` Maxime Ripard
2022-09-27 12:25 ` Maxime Ripard
1 sibling, 1 reply; 23+ messages in thread
From: Maxime Ripard @ 2022-09-27 11:42 UTC (permalink / raw)
To: Stefan Wahren; +Cc: Marc Kleine-Budde, dri-devel, Emma Anholt, linux-rpi-kernel
On Tue, Sep 27, 2022 at 01:12:35PM +0200, Stefan Wahren wrote:
> Am 27.09.22 um 11:42 schrieb Maxime Ripard:
> > On Tue, Sep 27, 2022 at 09:25:54AM +0200, Maxime Ripard wrote:
> > > Hi Stefan,
> > >
> > > On Mon, Sep 26, 2022 at 08:50:12PM +0200, Stefan Wahren wrote:
> > > > Am 26.09.22 um 14:47 schrieb Maxime Ripard:
> > > > > On Mon, Sep 26, 2022 at 02:40:48PM +0200, Marc Kleine-Budde wrote:
> > > > > > On 26.09.2022 14:08:04, Stefan Wahren wrote:
> > > > > > > Hi Marc,
> > > > > > >
> > > > > > > Am 26.09.22 um 12:21 schrieb Marc Kleine-Budde:
> > > > > > > > On 22.09.2022 17:06:00, Maxime Ripard wrote:
> > > > > > > > > > I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
> > > > > > > > > > using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
> > > > > > > > > >
> > > > > > > > > > | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> > > > > > > > > > | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
> > > > > > > > > > 9-01)
> > > > > > > > > > | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
> > > > > > > > > > | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
> > > > > > > > > >
> > > > > > > > > > As soon a the vc4 module is loaded the following warnings hits 4
> > > > > > > > > > times, then the machine stops.
> > > > > > > > [...]
> > > > > > > >
> > > > > > > > > The warning itself is fixed, both upstream and in stable (5.19.7).
> > > > > > > > Ok. Debian is using 5.19.6
> > > > > > > >
> > > > > > > > > It shouldn't have any relation to the hang though. Can you share your
> > > > > > > > > setup?
> > > > > > > > - config.txt:
> > > > > > > >
> > > > > > > > -------->8-------->8-------->8-------->8--------
> > > > > > > > gpu_mem=16
> > > > > > > > disable_splash=1
> > > > > > > >
> > > > > > > > arm_64bit=1
> > > > > > > > enable_uart=1
> > > > > > > > uart_2ndstage=1
> > > > > > > >
> > > > > > > > os_prefix=/u-boot/
> > > > > > > >
> > > > > > > > [pi3]
> > > > > > > > force_turbo=1
> > > > > > > > -------->8-------->8-------->8-------->8--------
> > > > > > > >
> > > > > > > > - Raspberry Pi 3 Model B+
> > > > > > > > - no HDMI connected
> > > > > > > Does it mean, the issue only occurs without HDMI connected?
> > > > > > > If you didn't test with HDMI yet, could you please do?
> > > > > > The error occurs with HDMI not connected, as vc4 is the gfx driver I
> > > > > > thought this might be of interest. :)
> > > > > >
> > > > > > I don't have a HDMI monitor here, but I'll come back to you as soon as I
> > > > > > get access to one (might take some time).
> > > > > It's not the first time an issue like this one would occur. I'm trying
> > > > > to make my Pi3 boot again, and will try to bisect the issue.
> > > > yes the issue is only triggered without HDMI connected. I was able to
> > > > reproduce with an older vc4 firmware from 2020 (don't want to upgrade yet).
> > > > Kernel was also an arm64 build with defconfig.
> > > >
> > > > Here some rough starting point for bisection:
> > > >
> > > > 5.18.0 good
> > > > 5.19.0 bad
> > > > 5.19.6 bad
> > > Sorry it took a bit of time, it looks like I found another bug while
> > > trying to test this yesterday.
> > >
> > > Your datapoints are interesting though. I have a custom configuration
> > > and it does boot 5.19 without an HDMI connected.
> > >
> > > So I guess it leaves us with either the firmware version being different
> > > (I'm using a newer version, from March 2022), or the configuration. I'll
> > > test with defconfig.
> > So it turns out compiling vc4 as a module is the culprit.
>
> Do you mean regardless of the kernel version in your case?
No, I mean that, with vc4 as a module, 5.18 works but 5.19 doesn't, like
Marc said. But if vc4 is built in, both work.
> In my test cases i build vc4 always as module.
>
> > It's not clear to me why at this point, but the first register write in
> > vc4_hdmi_reset stalls.
>
> Sounds like timing issue or a missing dependency (clock or power domain)
It felt like a clock or power domain issue to me indeed, but adding
clk_ignore_unused and pd_ignore_unused isn't enough, so it's probably
something a bit more complicated than just the clock / PD being
disabled.
Maxime
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-27 11:42 ` Maxime Ripard
@ 2022-09-27 12:25 ` Maxime Ripard
2022-09-27 13:15 ` Maxime Ripard
0 siblings, 1 reply; 23+ messages in thread
From: Maxime Ripard @ 2022-09-27 12:25 UTC (permalink / raw)
To: Stefan Wahren; +Cc: Marc Kleine-Budde, dri-devel, Emma Anholt, linux-rpi-kernel
On Tue, Sep 27, 2022 at 01:42:40PM +0200, Maxime Ripard wrote:
> On Tue, Sep 27, 2022 at 01:12:35PM +0200, Stefan Wahren wrote:
> > Am 27.09.22 um 11:42 schrieb Maxime Ripard:
> > > On Tue, Sep 27, 2022 at 09:25:54AM +0200, Maxime Ripard wrote:
> > > > Hi Stefan,
> > > >
> > > > On Mon, Sep 26, 2022 at 08:50:12PM +0200, Stefan Wahren wrote:
> > > > > Am 26.09.22 um 14:47 schrieb Maxime Ripard:
> > > > > > On Mon, Sep 26, 2022 at 02:40:48PM +0200, Marc Kleine-Budde wrote:
> > > > > > > On 26.09.2022 14:08:04, Stefan Wahren wrote:
> > > > > > > > Hi Marc,
> > > > > > > >
> > > > > > > > Am 26.09.22 um 12:21 schrieb Marc Kleine-Budde:
> > > > > > > > > On 22.09.2022 17:06:00, Maxime Ripard wrote:
> > > > > > > > > > > I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
> > > > > > > > > > > using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
> > > > > > > > > > >
> > > > > > > > > > > | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> > > > > > > > > > > | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
> > > > > > > > > > > 9-01)
> > > > > > > > > > > | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
> > > > > > > > > > > | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
> > > > > > > > > > >
> > > > > > > > > > > As soon a the vc4 module is loaded the following warnings hits 4
> > > > > > > > > > > times, then the machine stops.
> > > > > > > > > [...]
> > > > > > > > >
> > > > > > > > > > The warning itself is fixed, both upstream and in stable (5.19.7).
> > > > > > > > > Ok. Debian is using 5.19.6
> > > > > > > > >
> > > > > > > > > > It shouldn't have any relation to the hang though. Can you share your
> > > > > > > > > > setup?
> > > > > > > > > - config.txt:
> > > > > > > > >
> > > > > > > > > -------->8-------->8-------->8-------->8--------
> > > > > > > > > gpu_mem=16
> > > > > > > > > disable_splash=1
> > > > > > > > >
> > > > > > > > > arm_64bit=1
> > > > > > > > > enable_uart=1
> > > > > > > > > uart_2ndstage=1
> > > > > > > > >
> > > > > > > > > os_prefix=/u-boot/
> > > > > > > > >
> > > > > > > > > [pi3]
> > > > > > > > > force_turbo=1
> > > > > > > > > -------->8-------->8-------->8-------->8--------
> > > > > > > > >
> > > > > > > > > - Raspberry Pi 3 Model B+
> > > > > > > > > - no HDMI connected
> > > > > > > > Does it mean, the issue only occurs without HDMI connected?
> > > > > > > > If you didn't test with HDMI yet, could you please do?
> > > > > > > The error occurs with HDMI not connected, as vc4 is the gfx driver I
> > > > > > > thought this might be of interest. :)
> > > > > > >
> > > > > > > I don't have a HDMI monitor here, but I'll come back to you as soon as I
> > > > > > > get access to one (might take some time).
> > > > > > It's not the first time an issue like this one would occur. I'm trying
> > > > > > to make my Pi3 boot again, and will try to bisect the issue.
> > > > > yes the issue is only triggered without HDMI connected. I was able to
> > > > > reproduce with an older vc4 firmware from 2020 (don't want to upgrade yet).
> > > > > Kernel was also an arm64 build with defconfig.
> > > > >
> > > > > Here some rough starting point for bisection:
> > > > >
> > > > > 5.18.0 good
> > > > > 5.19.0 bad
> > > > > 5.19.6 bad
> > > > Sorry it took a bit of time, it looks like I found another bug while
> > > > trying to test this yesterday.
> > > >
> > > > Your datapoints are interesting though. I have a custom configuration
> > > > and it does boot 5.19 without an HDMI connected.
> > > >
> > > > So I guess it leaves us with either the firmware version being different
> > > > (I'm using a newer version, from March 2022), or the configuration. I'll
> > > > test with defconfig.
> > > So it turns out compiling vc4 as a module is the culprit.
> >
> > Do you mean regardless of the kernel version in your case?
>
> No, I mean that, with vc4 as a module, 5.18 works but 5.19 doesn't, like
> Marc said. But if vc4 is built in, both work.
>
> > In my test cases i build vc4 always as module.
> >
> > > It's not clear to me why at this point, but the first register write in
> > > vc4_hdmi_reset stalls.
> >
> > Sounds like timing issue or a missing dependency (clock or power domain)
>
> It felt like a clock or power domain issue to me indeed, but adding
> clk_ignore_unused and pd_ignore_unused isn't enough, so it's probably
> something a bit more complicated than just the clock / PD being
> disabled.
I found the offending patch:
https://lore.kernel.org/dri-devel/20220225143534.405820-13-maxime@cerno.tech/
That code was removed because it was made irrelevant by that earlier patch:
https://lore.kernel.org/dri-devel/20220225143534.405820-10-maxime@cerno.tech/
But it turns out that while it works when the driver is built-in, it
doesn't when it's a module. If we add a clk_hw_get_rate() call right
after that call to raspberrypi_fw_set_rate(), the rate returned is 0.
I'm not entirely sure why, but I wonder if it's related to:
https://github.com/raspberrypi/linux/issues/4962#issuecomment-1228593439
Maxime
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-27 12:25 ` Maxime Ripard
@ 2022-09-27 13:15 ` Maxime Ripard
2022-09-27 13:35 ` Maxime Ripard
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: Maxime Ripard @ 2022-09-27 13:15 UTC (permalink / raw)
To: Stefan Wahren; +Cc: Marc Kleine-Budde, dri-devel, Emma Anholt, linux-rpi-kernel
On Tue, Sep 27, 2022 at 02:25:12PM +0200, Maxime Ripard wrote:
> On Tue, Sep 27, 2022 at 01:42:40PM +0200, Maxime Ripard wrote:
> > On Tue, Sep 27, 2022 at 01:12:35PM +0200, Stefan Wahren wrote:
> > > Am 27.09.22 um 11:42 schrieb Maxime Ripard:
> > > > On Tue, Sep 27, 2022 at 09:25:54AM +0200, Maxime Ripard wrote:
> > > > > Hi Stefan,
> > > > >
> > > > > On Mon, Sep 26, 2022 at 08:50:12PM +0200, Stefan Wahren wrote:
> > > > > > Am 26.09.22 um 14:47 schrieb Maxime Ripard:
> > > > > > > On Mon, Sep 26, 2022 at 02:40:48PM +0200, Marc Kleine-Budde wrote:
> > > > > > > > On 26.09.2022 14:08:04, Stefan Wahren wrote:
> > > > > > > > > Hi Marc,
> > > > > > > > >
> > > > > > > > > Am 26.09.22 um 12:21 schrieb Marc Kleine-Budde:
> > > > > > > > > > On 22.09.2022 17:06:00, Maxime Ripard wrote:
> > > > > > > > > > > > I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
> > > > > > > > > > > > using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
> > > > > > > > > > > >
> > > > > > > > > > > > | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> > > > > > > > > > > > | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
> > > > > > > > > > > > 9-01)
> > > > > > > > > > > > | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
> > > > > > > > > > > > | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
> > > > > > > > > > > >
> > > > > > > > > > > > As soon a the vc4 module is loaded the following warnings hits 4
> > > > > > > > > > > > times, then the machine stops.
> > > > > > > > > > [...]
> > > > > > > > > >
> > > > > > > > > > > The warning itself is fixed, both upstream and in stable (5.19.7).
> > > > > > > > > > Ok. Debian is using 5.19.6
> > > > > > > > > >
> > > > > > > > > > > It shouldn't have any relation to the hang though. Can you share your
> > > > > > > > > > > setup?
> > > > > > > > > > - config.txt:
> > > > > > > > > >
> > > > > > > > > > -------->8-------->8-------->8-------->8--------
> > > > > > > > > > gpu_mem=16
> > > > > > > > > > disable_splash=1
> > > > > > > > > >
> > > > > > > > > > arm_64bit=1
> > > > > > > > > > enable_uart=1
> > > > > > > > > > uart_2ndstage=1
> > > > > > > > > >
> > > > > > > > > > os_prefix=/u-boot/
> > > > > > > > > >
> > > > > > > > > > [pi3]
> > > > > > > > > > force_turbo=1
> > > > > > > > > > -------->8-------->8-------->8-------->8--------
> > > > > > > > > >
> > > > > > > > > > - Raspberry Pi 3 Model B+
> > > > > > > > > > - no HDMI connected
> > > > > > > > > Does it mean, the issue only occurs without HDMI connected?
> > > > > > > > > If you didn't test with HDMI yet, could you please do?
> > > > > > > > The error occurs with HDMI not connected, as vc4 is the gfx driver I
> > > > > > > > thought this might be of interest. :)
> > > > > > > >
> > > > > > > > I don't have a HDMI monitor here, but I'll come back to you as soon as I
> > > > > > > > get access to one (might take some time).
> > > > > > > It's not the first time an issue like this one would occur. I'm trying
> > > > > > > to make my Pi3 boot again, and will try to bisect the issue.
> > > > > > yes the issue is only triggered without HDMI connected. I was able to
> > > > > > reproduce with an older vc4 firmware from 2020 (don't want to upgrade yet).
> > > > > > Kernel was also an arm64 build with defconfig.
> > > > > >
> > > > > > Here some rough starting point for bisection:
> > > > > >
> > > > > > 5.18.0 good
> > > > > > 5.19.0 bad
> > > > > > 5.19.6 bad
> > > > > Sorry it took a bit of time, it looks like I found another bug while
> > > > > trying to test this yesterday.
> > > > >
> > > > > Your datapoints are interesting though. I have a custom configuration
> > > > > and it does boot 5.19 without an HDMI connected.
> > > > >
> > > > > So I guess it leaves us with either the firmware version being different
> > > > > (I'm using a newer version, from March 2022), or the configuration. I'll
> > > > > test with defconfig.
> > > > So it turns out compiling vc4 as a module is the culprit.
> > >
> > > Do you mean regardless of the kernel version in your case?
> >
> > No, I mean that, with vc4 as a module, 5.18 works but 5.19 doesn't, like
> > Marc said. But if vc4 is built in, both work.
> >
> > > In my test cases i build vc4 always as module.
> > >
> > > > It's not clear to me why at this point, but the first register write in
> > > > vc4_hdmi_reset stalls.
> > >
> > > Sounds like timing issue or a missing dependency (clock or power domain)
> >
> > It felt like a clock or power domain issue to me indeed, but adding
> > clk_ignore_unused and pd_ignore_unused isn't enough, so it's probably
> > something a bit more complicated than just the clock / PD being
> > disabled.
>
> I found the offending patch:
> https://lore.kernel.org/dri-devel/20220225143534.405820-13-maxime@cerno.tech/
>
> That code was removed because it was made irrelevant by that earlier patch:
> https://lore.kernel.org/dri-devel/20220225143534.405820-10-maxime@cerno.tech/
>
> But it turns out that while it works when the driver is built-in, it
> doesn't when it's a module. If we add a clk_hw_get_rate() call right
> after that call to raspberrypi_fw_set_rate(), the rate returned is 0.
>
> I'm not entirely sure why, but I wonder if it's related to:
> https://github.com/raspberrypi/linux/issues/4962#issuecomment-1228593439
Turns out it's not, since the Pi3 is using the clk-bcm2835 driver.
However, even reverting that patch fails. clk_set_min_rate fails because
the rate is protected, but it doesn't look like it is anywhere for that
clock, so I'm a bit confused.
Even if we do remove the clock protection check in
clk_core_set_rate_nolock(), clk_calc_new_rates() will then fail because
the bcm2835 driver will round the clock rate below the minimum, which is
rejected.
I'm not entirely sure what to do at this point. I guess the proper fix
would be to:
- Figure out why it's considered protected when it's not (or shouldn't be)
- Make the driver compute an acceptable rate for that clock
- Reintroduce the clk_set_min_rate call to HDMI's runtime_resume, or
some other equivalent code
Maxime
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-27 13:15 ` Maxime Ripard
@ 2022-09-27 13:35 ` Maxime Ripard
2022-09-27 18:45 ` Stefan Wahren
2022-09-29 9:35 ` Maxime Ripard
2 siblings, 0 replies; 23+ messages in thread
From: Maxime Ripard @ 2022-09-27 13:35 UTC (permalink / raw)
To: Stefan Wahren; +Cc: Marc Kleine-Budde, dri-devel, Emma Anholt, linux-rpi-kernel
On Tue, Sep 27, 2022 at 03:15:17PM +0200, Maxime Ripard wrote:
> On Tue, Sep 27, 2022 at 02:25:12PM +0200, Maxime Ripard wrote:
> > On Tue, Sep 27, 2022 at 01:42:40PM +0200, Maxime Ripard wrote:
> > > On Tue, Sep 27, 2022 at 01:12:35PM +0200, Stefan Wahren wrote:
> > > > Am 27.09.22 um 11:42 schrieb Maxime Ripard:
> > > > > On Tue, Sep 27, 2022 at 09:25:54AM +0200, Maxime Ripard wrote:
> > > > > > Hi Stefan,
> > > > > >
> > > > > > On Mon, Sep 26, 2022 at 08:50:12PM +0200, Stefan Wahren wrote:
> > > > > > > Am 26.09.22 um 14:47 schrieb Maxime Ripard:
> > > > > > > > On Mon, Sep 26, 2022 at 02:40:48PM +0200, Marc Kleine-Budde wrote:
> > > > > > > > > On 26.09.2022 14:08:04, Stefan Wahren wrote:
> > > > > > > > > > Hi Marc,
> > > > > > > > > >
> > > > > > > > > > Am 26.09.22 um 12:21 schrieb Marc Kleine-Budde:
> > > > > > > > > > > On 22.09.2022 17:06:00, Maxime Ripard wrote:
> > > > > > > > > > > > > I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
> > > > > > > > > > > > > using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
> > > > > > > > > > > > >
> > > > > > > > > > > > > | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> > > > > > > > > > > > > | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
> > > > > > > > > > > > > 9-01)
> > > > > > > > > > > > > | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
> > > > > > > > > > > > > | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
> > > > > > > > > > > > >
> > > > > > > > > > > > > As soon a the vc4 module is loaded the following warnings hits 4
> > > > > > > > > > > > > times, then the machine stops.
> > > > > > > > > > > [...]
> > > > > > > > > > >
> > > > > > > > > > > > The warning itself is fixed, both upstream and in stable (5.19.7).
> > > > > > > > > > > Ok. Debian is using 5.19.6
> > > > > > > > > > >
> > > > > > > > > > > > It shouldn't have any relation to the hang though. Can you share your
> > > > > > > > > > > > setup?
> > > > > > > > > > > - config.txt:
> > > > > > > > > > >
> > > > > > > > > > > -------->8-------->8-------->8-------->8--------
> > > > > > > > > > > gpu_mem=16
> > > > > > > > > > > disable_splash=1
> > > > > > > > > > >
> > > > > > > > > > > arm_64bit=1
> > > > > > > > > > > enable_uart=1
> > > > > > > > > > > uart_2ndstage=1
> > > > > > > > > > >
> > > > > > > > > > > os_prefix=/u-boot/
> > > > > > > > > > >
> > > > > > > > > > > [pi3]
> > > > > > > > > > > force_turbo=1
> > > > > > > > > > > -------->8-------->8-------->8-------->8--------
> > > > > > > > > > >
> > > > > > > > > > > - Raspberry Pi 3 Model B+
> > > > > > > > > > > - no HDMI connected
> > > > > > > > > > Does it mean, the issue only occurs without HDMI connected?
> > > > > > > > > > If you didn't test with HDMI yet, could you please do?
> > > > > > > > > The error occurs with HDMI not connected, as vc4 is the gfx driver I
> > > > > > > > > thought this might be of interest. :)
> > > > > > > > >
> > > > > > > > > I don't have a HDMI monitor here, but I'll come back to you as soon as I
> > > > > > > > > get access to one (might take some time).
> > > > > > > > It's not the first time an issue like this one would occur. I'm trying
> > > > > > > > to make my Pi3 boot again, and will try to bisect the issue.
> > > > > > > yes the issue is only triggered without HDMI connected. I was able to
> > > > > > > reproduce with an older vc4 firmware from 2020 (don't want to upgrade yet).
> > > > > > > Kernel was also an arm64 build with defconfig.
> > > > > > >
> > > > > > > Here some rough starting point for bisection:
> > > > > > >
> > > > > > > 5.18.0 good
> > > > > > > 5.19.0 bad
> > > > > > > 5.19.6 bad
> > > > > > Sorry it took a bit of time, it looks like I found another bug while
> > > > > > trying to test this yesterday.
> > > > > >
> > > > > > Your datapoints are interesting though. I have a custom configuration
> > > > > > and it does boot 5.19 without an HDMI connected.
> > > > > >
> > > > > > So I guess it leaves us with either the firmware version being different
> > > > > > (I'm using a newer version, from March 2022), or the configuration. I'll
> > > > > > test with defconfig.
> > > > > So it turns out compiling vc4 as a module is the culprit.
> > > >
> > > > Do you mean regardless of the kernel version in your case?
> > >
> > > No, I mean that, with vc4 as a module, 5.18 works but 5.19 doesn't, like
> > > Marc said. But if vc4 is built in, both work.
> > >
> > > > In my test cases i build vc4 always as module.
> > > >
> > > > > It's not clear to me why at this point, but the first register write in
> > > > > vc4_hdmi_reset stalls.
> > > >
> > > > Sounds like timing issue or a missing dependency (clock or power domain)
> > >
> > > It felt like a clock or power domain issue to me indeed, but adding
> > > clk_ignore_unused and pd_ignore_unused isn't enough, so it's probably
> > > something a bit more complicated than just the clock / PD being
> > > disabled.
> >
> > I found the offending patch:
> > https://lore.kernel.org/dri-devel/20220225143534.405820-13-maxime@cerno.tech/
> >
> > That code was removed because it was made irrelevant by that earlier patch:
> > https://lore.kernel.org/dri-devel/20220225143534.405820-10-maxime@cerno.tech/
> >
> > But it turns out that while it works when the driver is built-in, it
> > doesn't when it's a module. If we add a clk_hw_get_rate() call right
> > after that call to raspberrypi_fw_set_rate(), the rate returned is 0.
> >
> > I'm not entirely sure why, but I wonder if it's related to:
> > https://github.com/raspberrypi/linux/issues/4962#issuecomment-1228593439
>
> Turns out it's not, since the Pi3 is using the clk-bcm2835 driver.
>
> However, even reverting that patch fails. clk_set_min_rate fails because
> the rate is protected, but it doesn't look like it is anywhere for that
> clock, so I'm a bit confused.
>
> Even if we do remove the clock protection check in
> clk_core_set_rate_nolock(), clk_calc_new_rates() will then fail because
> the bcm2835 driver will round the clock rate below the minimum, which is
> rejected.
>
> I'm not entirely sure what to do at this point. I guess the proper fix
> would be to:
> - Figure out why it's considered protected when it's not (or shouldn't be)
Found out that one. The HSM clock has CLK_SET_RATE_GATE that will
protect the rate for as long as the clock is enabled, so
clk_prepare_enable / clk_set_min_rate doesn't work, but clk_set_min_rate
/ clk_prepare_enable does.
Maxime
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-27 13:15 ` Maxime Ripard
2022-09-27 13:35 ` Maxime Ripard
@ 2022-09-27 18:45 ` Stefan Wahren
2022-09-27 18:47 ` Info Skymem
2022-09-29 9:35 ` Maxime Ripard
2 siblings, 1 reply; 23+ messages in thread
From: Stefan Wahren @ 2022-09-27 18:45 UTC (permalink / raw)
To: Maxime Ripard; +Cc: Marc Kleine-Budde, dri-devel, Emma Anholt, linux-rpi-kernel
Hi Maxime,
Am 27.09.22 um 15:15 schrieb Maxime Ripard:
> On Tue, Sep 27, 2022 at 02:25:12PM +0200, Maxime Ripard wrote:
>> On Tue, Sep 27, 2022 at 01:42:40PM +0200, Maxime Ripard wrote:
>>> On Tue, Sep 27, 2022 at 01:12:35PM +0200, Stefan Wahren wrote:
>>>> Am 27.09.22 um 11:42 schrieb Maxime Ripard:
>>>>> On Tue, Sep 27, 2022 at 09:25:54AM +0200, Maxime Ripard wrote:
>>>>>> Hi Stefan,
>>>>>>
>>>>>> On Mon, Sep 26, 2022 at 08:50:12PM +0200, Stefan Wahren wrote:
>>>>>>> Am 26.09.22 um 14:47 schrieb Maxime Ripard:
>>>>>>>> On Mon, Sep 26, 2022 at 02:40:48PM +0200, Marc Kleine-Budde wrote:
>>>>>>>>> On 26.09.2022 14:08:04, Stefan Wahren wrote:
>>>>>>>>>> Hi Marc,
>>>>>>>>>>
>>>>>>>>>> Am 26.09.22 um 12:21 schrieb Marc Kleine-Budde:
>>>>>>>>>>> On 22.09.2022 17:06:00, Maxime Ripard wrote:
>>>>>>>>>>>>> I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
>>>>>>>>>>>>> using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
>>>>>>>>>>>>>
>>>>>>>>>>>>> | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
>>>>>>>>>>>>> | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
>>>>>>>>>>>>> 9-01)
>>>>>>>>>>>>> | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
>>>>>>>>>>>>> | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
>>>>>>>>>>>>>
>>>>>>>>>>>>> As soon a the vc4 module is loaded the following warnings hits 4
>>>>>>>>>>>>> times, then the machine stops.
>>>>>>>>>>> [...]
>>>>>>>>>>>
>>>>>>>>>>>> The warning itself is fixed, both upstream and in stable (5.19.7).
>>>>>>>>>>> Ok. Debian is using 5.19.6
>>>>>>>>>>>
>>>>>>>>>>>> It shouldn't have any relation to the hang though. Can you share your
>>>>>>>>>>>> setup?
>>>>>>>>>>> - config.txt:
>>>>>>>>>>>
>>>>>>>>>>> -------->8-------->8-------->8-------->8--------
>>>>>>>>>>> gpu_mem=16
>>>>>>>>>>> disable_splash=1
>>>>>>>>>>>
>>>>>>>>>>> arm_64bit=1
>>>>>>>>>>> enable_uart=1
>>>>>>>>>>> uart_2ndstage=1
>>>>>>>>>>>
>>>>>>>>>>> os_prefix=/u-boot/
>>>>>>>>>>>
>>>>>>>>>>> [pi3]
>>>>>>>>>>> force_turbo=1
>>>>>>>>>>> -------->8-------->8-------->8-------->8--------
>>>>>>>>>>>
>>>>>>>>>>> - Raspberry Pi 3 Model B+
>>>>>>>>>>> - no HDMI connected
>>>>>>>>>> Does it mean, the issue only occurs without HDMI connected?
>>>>>>>>>> If you didn't test with HDMI yet, could you please do?
>>>>>>>>> The error occurs with HDMI not connected, as vc4 is the gfx driver I
>>>>>>>>> thought this might be of interest. :)
>>>>>>>>>
>>>>>>>>> I don't have a HDMI monitor here, but I'll come back to you as soon as I
>>>>>>>>> get access to one (might take some time).
>>>>>>>> It's not the first time an issue like this one would occur. I'm trying
>>>>>>>> to make my Pi3 boot again, and will try to bisect the issue.
>>>>>>> yes the issue is only triggered without HDMI connected. I was able to
>>>>>>> reproduce with an older vc4 firmware from 2020 (don't want to upgrade yet).
>>>>>>> Kernel was also an arm64 build with defconfig.
>>>>>>>
>>>>>>> Here some rough starting point for bisection:
>>>>>>>
>>>>>>> 5.18.0 good
>>>>>>> 5.19.0 bad
>>>>>>> 5.19.6 bad
>>>>>> Sorry it took a bit of time, it looks like I found another bug while
>>>>>> trying to test this yesterday.
>>>>>>
>>>>>> Your datapoints are interesting though. I have a custom configuration
>>>>>> and it does boot 5.19 without an HDMI connected.
>>>>>>
>>>>>> So I guess it leaves us with either the firmware version being different
>>>>>> (I'm using a newer version, from March 2022), or the configuration. I'll
>>>>>> test with defconfig.
>>>>> So it turns out compiling vc4 as a module is the culprit.
>>>> Do you mean regardless of the kernel version in your case?
>>> No, I mean that, with vc4 as a module, 5.18 works but 5.19 doesn't, like
>>> Marc said. But if vc4 is built in, both work.
>>>
>>>> In my test cases i build vc4 always as module.
>>>>
>>>>> It's not clear to me why at this point, but the first register write in
>>>>> vc4_hdmi_reset stalls.
>>>> Sounds like timing issue or a missing dependency (clock or power domain)
>>> It felt like a clock or power domain issue to me indeed, but adding
>>> clk_ignore_unused and pd_ignore_unused isn't enough, so it's probably
>>> something a bit more complicated than just the clock / PD being
>>> disabled.
>> I found the offending patch:
>> https://lore.kernel.org/dri-devel/20220225143534.405820-13-maxime@cerno.tech/
>>
>> That code was removed because it was made irrelevant by that earlier patch:
>> https://lore.kernel.org/dri-devel/20220225143534.405820-10-maxime@cerno.tech/
>>
>> But it turns out that while it works when the driver is built-in, it
>> doesn't when it's a module. If we add a clk_hw_get_rate() call right
>> after that call to raspberrypi_fw_set_rate(), the rate returned is 0.
>>
>> I'm not entirely sure why, but I wonder if it's related to:
>> https://github.com/raspberrypi/linux/issues/4962#issuecomment-1228593439
> Turns out it's not, since the Pi3 is using the clk-bcm2835 driver.
FWIW i can confirm, that i see the same behavior:
fd5894fa2413cca3e6a3ea713b2bd57281af2e86 bad
5b6ef06ea6225570bc0b33325306c7b8c6bdf5eb good
>
> However, even reverting that patch fails. clk_set_min_rate fails because
> the rate is protected, but it doesn't look like it is anywhere for that
> clock, so I'm a bit confused.
>
> Even if we do remove the clock protection check in
> clk_core_set_rate_nolock(), clk_calc_new_rates() will then fail because
> the bcm2835 driver will round the clock rate below the minimum, which is
> rejected.
>
> I'm not entirely sure what to do at this point. I guess the proper fix
> would be to:
> - Figure out why it's considered protected when it's not (or shouldn't be)
> - Make the driver compute an acceptable rate for that clock
> - Reintroduce the clk_set_min_rate call to HDMI's runtime_resume, or
> some other equivalent code
>
> Maxime
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-27 18:45 ` Stefan Wahren
@ 2022-09-27 18:47 ` Info Skymem
0 siblings, 0 replies; 23+ messages in thread
From: Info Skymem @ 2022-09-27 18:47 UTC (permalink / raw)
To: Stefan Wahren; +Cc: linux-rpi-kernel, Maxime Ripard, dri-devel, Emma Anholt
Hi,
thank you for your information.
On our website you can find email addresses of companies and people.
https://www.skymem.info
In short, it’s like Google for emails.
Best regards,
Robert,
Skymem team
On Tue, Sep 27, 2022 at 8:46 PM Stefan Wahren <stefan.wahren@i2se.com> wrote:
>
> Hi Maxime,
>
> Am 27.09.22 um 15:15 schrieb Maxime Ripard:
> > On Tue, Sep 27, 2022 at 02:25:12PM +0200, Maxime Ripard wrote:
> >> On Tue, Sep 27, 2022 at 01:42:40PM +0200, Maxime Ripard wrote:
> >>> On Tue, Sep 27, 2022 at 01:12:35PM +0200, Stefan Wahren wrote:
> >>>> Am 27.09.22 um 11:42 schrieb Maxime Ripard:
> >>>>> On Tue, Sep 27, 2022 at 09:25:54AM +0200, Maxime Ripard wrote:
> >>>>>> Hi Stefan,
> >>>>>>
> >>>>>> On Mon, Sep 26, 2022 at 08:50:12PM +0200, Stefan Wahren wrote:
> >>>>>>> Am 26.09.22 um 14:47 schrieb Maxime Ripard:
> >>>>>>>> On Mon, Sep 26, 2022 at 02:40:48PM +0200, Marc Kleine-Budde wrote:
> >>>>>>>>> On 26.09.2022 14:08:04, Stefan Wahren wrote:
> >>>>>>>>>> Hi Marc,
> >>>>>>>>>>
> >>>>>>>>>> Am 26.09.22 um 12:21 schrieb Marc Kleine-Budde:
> >>>>>>>>>>> On 22.09.2022 17:06:00, Maxime Ripard wrote:
> >>>>>>>>>>>>> I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
> >>>>>>>>>>>>> using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> >>>>>>>>>>>>> | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
> >>>>>>>>>>>>> 9-01)
> >>>>>>>>>>>>> | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
> >>>>>>>>>>>>> | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> As soon a the vc4 module is loaded the following warnings hits 4
> >>>>>>>>>>>>> times, then the machine stops.
> >>>>>>>>>>> [...]
> >>>>>>>>>>>
> >>>>>>>>>>>> The warning itself is fixed, both upstream and in stable (5.19.7).
> >>>>>>>>>>> Ok. Debian is using 5.19.6
> >>>>>>>>>>>
> >>>>>>>>>>>> It shouldn't have any relation to the hang though. Can you share your
> >>>>>>>>>>>> setup?
> >>>>>>>>>>> - config.txt:
> >>>>>>>>>>>
> >>>>>>>>>>> -------->8-------->8-------->8-------->8--------
> >>>>>>>>>>> gpu_mem=16
> >>>>>>>>>>> disable_splash=1
> >>>>>>>>>>>
> >>>>>>>>>>> arm_64bit=1
> >>>>>>>>>>> enable_uart=1
> >>>>>>>>>>> uart_2ndstage=1
> >>>>>>>>>>>
> >>>>>>>>>>> os_prefix=/u-boot/
> >>>>>>>>>>>
> >>>>>>>>>>> [pi3]
> >>>>>>>>>>> force_turbo=1
> >>>>>>>>>>> -------->8-------->8-------->8-------->8--------
> >>>>>>>>>>>
> >>>>>>>>>>> - Raspberry Pi 3 Model B+
> >>>>>>>>>>> - no HDMI connected
> >>>>>>>>>> Does it mean, the issue only occurs without HDMI connected?
> >>>>>>>>>> If you didn't test with HDMI yet, could you please do?
> >>>>>>>>> The error occurs with HDMI not connected, as vc4 is the gfx driver I
> >>>>>>>>> thought this might be of interest. :)
> >>>>>>>>>
> >>>>>>>>> I don't have a HDMI monitor here, but I'll come back to you as soon as I
> >>>>>>>>> get access to one (might take some time).
> >>>>>>>> It's not the first time an issue like this one would occur. I'm trying
> >>>>>>>> to make my Pi3 boot again, and will try to bisect the issue.
> >>>>>>> yes the issue is only triggered without HDMI connected. I was able to
> >>>>>>> reproduce with an older vc4 firmware from 2020 (don't want to upgrade yet).
> >>>>>>> Kernel was also an arm64 build with defconfig.
> >>>>>>>
> >>>>>>> Here some rough starting point for bisection:
> >>>>>>>
> >>>>>>> 5.18.0 good
> >>>>>>> 5.19.0 bad
> >>>>>>> 5.19.6 bad
> >>>>>> Sorry it took a bit of time, it looks like I found another bug while
> >>>>>> trying to test this yesterday.
> >>>>>>
> >>>>>> Your datapoints are interesting though. I have a custom configuration
> >>>>>> and it does boot 5.19 without an HDMI connected.
> >>>>>>
> >>>>>> So I guess it leaves us with either the firmware version being different
> >>>>>> (I'm using a newer version, from March 2022), or the configuration. I'll
> >>>>>> test with defconfig.
> >>>>> So it turns out compiling vc4 as a module is the culprit.
> >>>> Do you mean regardless of the kernel version in your case?
> >>> No, I mean that, with vc4 as a module, 5.18 works but 5.19 doesn't, like
> >>> Marc said. But if vc4 is built in, both work.
> >>>
> >>>> In my test cases i build vc4 always as module.
> >>>>
> >>>>> It's not clear to me why at this point, but the first register write in
> >>>>> vc4_hdmi_reset stalls.
> >>>> Sounds like timing issue or a missing dependency (clock or power domain)
> >>> It felt like a clock or power domain issue to me indeed, but adding
> >>> clk_ignore_unused and pd_ignore_unused isn't enough, so it's probably
> >>> something a bit more complicated than just the clock / PD being
> >>> disabled.
> >> I found the offending patch:
> >> https://lore.kernel.org/dri-devel/20220225143534.405820-13-maxime@cerno.tech/
> >>
> >> That code was removed because it was made irrelevant by that earlier patch:
> >> https://lore.kernel.org/dri-devel/20220225143534.405820-10-maxime@cerno.tech/
> >>
> >> But it turns out that while it works when the driver is built-in, it
> >> doesn't when it's a module. If we add a clk_hw_get_rate() call right
> >> after that call to raspberrypi_fw_set_rate(), the rate returned is 0.
> >>
> >> I'm not entirely sure why, but I wonder if it's related to:
> >> https://github.com/raspberrypi/linux/issues/4962#issuecomment-1228593439
> > Turns out it's not, since the Pi3 is using the clk-bcm2835 driver.
>
> FWIW i can confirm, that i see the same behavior:
>
> fd5894fa2413cca3e6a3ea713b2bd57281af2e86 bad
>
> 5b6ef06ea6225570bc0b33325306c7b8c6bdf5eb good
>
> >
> > However, even reverting that patch fails. clk_set_min_rate fails because
> > the rate is protected, but it doesn't look like it is anywhere for that
> > clock, so I'm a bit confused.
> >
> > Even if we do remove the clock protection check in
> > clk_core_set_rate_nolock(), clk_calc_new_rates() will then fail because
> > the bcm2835 driver will round the clock rate below the minimum, which is
> > rejected.
> >
> > I'm not entirely sure what to do at this point. I guess the proper fix
> > would be to:
> > - Figure out why it's considered protected when it's not (or shouldn't be)
> > - Make the driver compute an acceptable rate for that clock
> > - Reintroduce the clk_set_min_rate call to HDMI's runtime_resume, or
> > some other equivalent code
> >
> > Maxime
>
> _______________________________________________
> linux-rpi-kernel mailing list
> linux-rpi-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-27 13:15 ` Maxime Ripard
2022-09-27 13:35 ` Maxime Ripard
2022-09-27 18:45 ` Stefan Wahren
@ 2022-09-29 9:35 ` Maxime Ripard
2022-09-29 13:46 ` Stefan Wahren
2 siblings, 1 reply; 23+ messages in thread
From: Maxime Ripard @ 2022-09-29 9:35 UTC (permalink / raw)
To: Stefan Wahren; +Cc: Marc Kleine-Budde, dri-devel, Emma Anholt, linux-rpi-kernel
[-- Attachment #1: Type: text/plain, Size: 7007 bytes --]
On Tue, Sep 27, 2022 at 03:15:17PM +0200, Maxime Ripard wrote:
> On Tue, Sep 27, 2022 at 02:25:12PM +0200, Maxime Ripard wrote:
> > On Tue, Sep 27, 2022 at 01:42:40PM +0200, Maxime Ripard wrote:
> > > On Tue, Sep 27, 2022 at 01:12:35PM +0200, Stefan Wahren wrote:
> > > > Am 27.09.22 um 11:42 schrieb Maxime Ripard:
> > > > > On Tue, Sep 27, 2022 at 09:25:54AM +0200, Maxime Ripard wrote:
> > > > > > Hi Stefan,
> > > > > >
> > > > > > On Mon, Sep 26, 2022 at 08:50:12PM +0200, Stefan Wahren wrote:
> > > > > > > Am 26.09.22 um 14:47 schrieb Maxime Ripard:
> > > > > > > > On Mon, Sep 26, 2022 at 02:40:48PM +0200, Marc Kleine-Budde wrote:
> > > > > > > > > On 26.09.2022 14:08:04, Stefan Wahren wrote:
> > > > > > > > > > Hi Marc,
> > > > > > > > > >
> > > > > > > > > > Am 26.09.22 um 12:21 schrieb Marc Kleine-Budde:
> > > > > > > > > > > On 22.09.2022 17:06:00, Maxime Ripard wrote:
> > > > > > > > > > > > > I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
> > > > > > > > > > > > > using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
> > > > > > > > > > > > >
> > > > > > > > > > > > > | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> > > > > > > > > > > > > | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
> > > > > > > > > > > > > 9-01)
> > > > > > > > > > > > > | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
> > > > > > > > > > > > > | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
> > > > > > > > > > > > >
> > > > > > > > > > > > > As soon a the vc4 module is loaded the following warnings hits 4
> > > > > > > > > > > > > times, then the machine stops.
> > > > > > > > > > > [...]
> > > > > > > > > > >
> > > > > > > > > > > > The warning itself is fixed, both upstream and in stable (5.19.7).
> > > > > > > > > > > Ok. Debian is using 5.19.6
> > > > > > > > > > >
> > > > > > > > > > > > It shouldn't have any relation to the hang though. Can you share your
> > > > > > > > > > > > setup?
> > > > > > > > > > > - config.txt:
> > > > > > > > > > >
> > > > > > > > > > > -------->8-------->8-------->8-------->8--------
> > > > > > > > > > > gpu_mem=16
> > > > > > > > > > > disable_splash=1
> > > > > > > > > > >
> > > > > > > > > > > arm_64bit=1
> > > > > > > > > > > enable_uart=1
> > > > > > > > > > > uart_2ndstage=1
> > > > > > > > > > >
> > > > > > > > > > > os_prefix=/u-boot/
> > > > > > > > > > >
> > > > > > > > > > > [pi3]
> > > > > > > > > > > force_turbo=1
> > > > > > > > > > > -------->8-------->8-------->8-------->8--------
> > > > > > > > > > >
> > > > > > > > > > > - Raspberry Pi 3 Model B+
> > > > > > > > > > > - no HDMI connected
> > > > > > > > > > Does it mean, the issue only occurs without HDMI connected?
> > > > > > > > > > If you didn't test with HDMI yet, could you please do?
> > > > > > > > > The error occurs with HDMI not connected, as vc4 is the gfx driver I
> > > > > > > > > thought this might be of interest. :)
> > > > > > > > >
> > > > > > > > > I don't have a HDMI monitor here, but I'll come back to you as soon as I
> > > > > > > > > get access to one (might take some time).
> > > > > > > > It's not the first time an issue like this one would occur. I'm trying
> > > > > > > > to make my Pi3 boot again, and will try to bisect the issue.
> > > > > > > yes the issue is only triggered without HDMI connected. I was able to
> > > > > > > reproduce with an older vc4 firmware from 2020 (don't want to upgrade yet).
> > > > > > > Kernel was also an arm64 build with defconfig.
> > > > > > >
> > > > > > > Here some rough starting point for bisection:
> > > > > > >
> > > > > > > 5.18.0 good
> > > > > > > 5.19.0 bad
> > > > > > > 5.19.6 bad
> > > > > > Sorry it took a bit of time, it looks like I found another bug while
> > > > > > trying to test this yesterday.
> > > > > >
> > > > > > Your datapoints are interesting though. I have a custom configuration
> > > > > > and it does boot 5.19 without an HDMI connected.
> > > > > >
> > > > > > So I guess it leaves us with either the firmware version being different
> > > > > > (I'm using a newer version, from March 2022), or the configuration. I'll
> > > > > > test with defconfig.
> > > > > So it turns out compiling vc4 as a module is the culprit.
> > > >
> > > > Do you mean regardless of the kernel version in your case?
> > >
> > > No, I mean that, with vc4 as a module, 5.18 works but 5.19 doesn't, like
> > > Marc said. But if vc4 is built in, both work.
> > >
> > > > In my test cases i build vc4 always as module.
> > > >
> > > > > It's not clear to me why at this point, but the first register write in
> > > > > vc4_hdmi_reset stalls.
> > > >
> > > > Sounds like timing issue or a missing dependency (clock or power domain)
> > >
> > > It felt like a clock or power domain issue to me indeed, but adding
> > > clk_ignore_unused and pd_ignore_unused isn't enough, so it's probably
> > > something a bit more complicated than just the clock / PD being
> > > disabled.
> >
> > I found the offending patch:
> > https://lore.kernel.org/dri-devel/20220225143534.405820-13-maxime@cerno.tech/
> >
> > That code was removed because it was made irrelevant by that earlier patch:
> > https://lore.kernel.org/dri-devel/20220225143534.405820-10-maxime@cerno.tech/
> >
> > But it turns out that while it works when the driver is built-in, it
> > doesn't when it's a module. If we add a clk_hw_get_rate() call right
> > after that call to raspberrypi_fw_set_rate(), the rate returned is 0.
> >
> > I'm not entirely sure why, but I wonder if it's related to:
> > https://github.com/raspberrypi/linux/issues/4962#issuecomment-1228593439
>
> Turns out it's not, since the Pi3 is using the clk-bcm2835 driver.
>
> However, even reverting that patch fails. clk_set_min_rate fails because
> the rate is protected, but it doesn't look like it is anywhere for that
> clock, so I'm a bit confused.
>
> Even if we do remove the clock protection check in
> clk_core_set_rate_nolock(), clk_calc_new_rates() will then fail because
> the bcm2835 driver will round the clock rate below the minimum, which is
> rejected.
>
> I'm not entirely sure what to do at this point. I guess the proper fix
> would be to:
> - Figure out why it's considered protected when it's not (or shouldn't be)
> - Make the driver compute an acceptable rate for that clock
This was due to 5.19.7 missing 88110a9f6209
> - Reintroduce the clk_set_min_rate call to HDMI's runtime_resume, or
> some other equivalent code
I just sent a series addressing this here:
https://lore.kernel.org/r/20220929-rpi-pi3-unplugged-fixes-v1-0-cd22e962296c@cerno.tech
Thanks for the report and the help :)
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-29 9:35 ` Maxime Ripard
@ 2022-09-29 13:46 ` Stefan Wahren
2022-09-29 14:15 ` Maxime Ripard
0 siblings, 1 reply; 23+ messages in thread
From: Stefan Wahren @ 2022-09-29 13:46 UTC (permalink / raw)
To: Maxime Ripard; +Cc: Marc Kleine-Budde, dri-devel, Emma Anholt, linux-rpi-kernel
Am 29.09.22 um 11:35 schrieb Maxime Ripard:
> On Tue, Sep 27, 2022 at 03:15:17PM +0200, Maxime Ripard wrote:
>> On Tue, Sep 27, 2022 at 02:25:12PM +0200, Maxime Ripard wrote:
>>> On Tue, Sep 27, 2022 at 01:42:40PM +0200, Maxime Ripard wrote:
>>>> On Tue, Sep 27, 2022 at 01:12:35PM +0200, Stefan Wahren wrote:
>>>>> Am 27.09.22 um 11:42 schrieb Maxime Ripard:
>>>>>> On Tue, Sep 27, 2022 at 09:25:54AM +0200, Maxime Ripard wrote:
>>>>>>> Hi Stefan,
>>>>>>>
>>>>>>> On Mon, Sep 26, 2022 at 08:50:12PM +0200, Stefan Wahren wrote:
>>>>>>>> Am 26.09.22 um 14:47 schrieb Maxime Ripard:
>>>>>>>>> On Mon, Sep 26, 2022 at 02:40:48PM +0200, Marc Kleine-Budde wrote:
>>>>>>>>>> On 26.09.2022 14:08:04, Stefan Wahren wrote:
>>>>>>>>>>> Hi Marc,
>>>>>>>>>>>
>>>>>>>>>>> Am 26.09.22 um 12:21 schrieb Marc Kleine-Budde:
>>>>>>>>>>>> On 22.09.2022 17:06:00, Maxime Ripard wrote:
>>>>>>>>>>>>>> I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
>>>>>>>>>>>>>> using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
>>>>>>>>>>>>>> | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
>>>>>>>>>>>>>> 9-01)
>>>>>>>>>>>>>> | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
>>>>>>>>>>>>>> | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As soon a the vc4 module is loaded the following warnings hits 4
>>>>>>>>>>>>>> times, then the machine stops.
>>>>>>>>>>>> [...]
>>>>>>>>>>>>
>>>>>>>>>>>>> The warning itself is fixed, both upstream and in stable (5.19.7).
>>>>>>>>>>>> Ok. Debian is using 5.19.6
>>>>>>>>>>>>
>>>>>>>>>>>>> It shouldn't have any relation to the hang though. Can you share your
>>>>>>>>>>>>> setup?
>>>>>>>>>>>> - config.txt:
>>>>>>>>>>>>
>>>>>>>>>>>> -------->8-------->8-------->8-------->8--------
>>>>>>>>>>>> gpu_mem=16
>>>>>>>>>>>> disable_splash=1
>>>>>>>>>>>>
>>>>>>>>>>>> arm_64bit=1
>>>>>>>>>>>> enable_uart=1
>>>>>>>>>>>> uart_2ndstage=1
>>>>>>>>>>>>
>>>>>>>>>>>> os_prefix=/u-boot/
>>>>>>>>>>>>
>>>>>>>>>>>> [pi3]
>>>>>>>>>>>> force_turbo=1
>>>>>>>>>>>> -------->8-------->8-------->8-------->8--------
>>>>>>>>>>>>
>>>>>>>>>>>> - Raspberry Pi 3 Model B+
>>>>>>>>>>>> - no HDMI connected
>>>>>>>>>>> Does it mean, the issue only occurs without HDMI connected?
>>>>>>>>>>> If you didn't test with HDMI yet, could you please do?
>>>>>>>>>> The error occurs with HDMI not connected, as vc4 is the gfx driver I
>>>>>>>>>> thought this might be of interest. :)
>>>>>>>>>>
>>>>>>>>>> I don't have a HDMI monitor here, but I'll come back to you as soon as I
>>>>>>>>>> get access to one (might take some time).
>>>>>>>>> It's not the first time an issue like this one would occur. I'm trying
>>>>>>>>> to make my Pi3 boot again, and will try to bisect the issue.
>>>>>>>> yes the issue is only triggered without HDMI connected. I was able to
>>>>>>>> reproduce with an older vc4 firmware from 2020 (don't want to upgrade yet).
>>>>>>>> Kernel was also an arm64 build with defconfig.
>>>>>>>>
>>>>>>>> Here some rough starting point for bisection:
>>>>>>>>
>>>>>>>> 5.18.0 good
>>>>>>>> 5.19.0 bad
>>>>>>>> 5.19.6 bad
>>>>>>> Sorry it took a bit of time, it looks like I found another bug while
>>>>>>> trying to test this yesterday.
>>>>>>>
>>>>>>> Your datapoints are interesting though. I have a custom configuration
>>>>>>> and it does boot 5.19 without an HDMI connected.
>>>>>>>
>>>>>>> So I guess it leaves us with either the firmware version being different
>>>>>>> (I'm using a newer version, from March 2022), or the configuration. I'll
>>>>>>> test with defconfig.
>>>>>> So it turns out compiling vc4 as a module is the culprit.
>>>>> Do you mean regardless of the kernel version in your case?
>>>> No, I mean that, with vc4 as a module, 5.18 works but 5.19 doesn't, like
>>>> Marc said. But if vc4 is built in, both work.
>>>>
>>>>> In my test cases i build vc4 always as module.
>>>>>
>>>>>> It's not clear to me why at this point, but the first register write in
>>>>>> vc4_hdmi_reset stalls.
>>>>> Sounds like timing issue or a missing dependency (clock or power domain)
>>>> It felt like a clock or power domain issue to me indeed, but adding
>>>> clk_ignore_unused and pd_ignore_unused isn't enough, so it's probably
>>>> something a bit more complicated than just the clock / PD being
>>>> disabled.
>>> I found the offending patch:
>>> https://lore.kernel.org/dri-devel/20220225143534.405820-13-maxime@cerno.tech/
>>>
>>> That code was removed because it was made irrelevant by that earlier patch:
>>> https://lore.kernel.org/dri-devel/20220225143534.405820-10-maxime@cerno.tech/
>>>
>>> But it turns out that while it works when the driver is built-in, it
>>> doesn't when it's a module. If we add a clk_hw_get_rate() call right
>>> after that call to raspberrypi_fw_set_rate(), the rate returned is 0.
>>>
>>> I'm not entirely sure why, but I wonder if it's related to:
>>> https://github.com/raspberrypi/linux/issues/4962#issuecomment-1228593439
>> Turns out it's not, since the Pi3 is using the clk-bcm2835 driver.
>>
>> However, even reverting that patch fails. clk_set_min_rate fails because
>> the rate is protected, but it doesn't look like it is anywhere for that
>> clock, so I'm a bit confused.
>>
>> Even if we do remove the clock protection check in
>> clk_core_set_rate_nolock(), clk_calc_new_rates() will then fail because
>> the bcm2835 driver will round the clock rate below the minimum, which is
>> rejected.
>>
>> I'm not entirely sure what to do at this point. I guess the proper fix
>> would be to:
>> - Figure out why it's considered protected when it's not (or shouldn't be)
>> - Make the driver compute an acceptable rate for that clock
> This was due to 5.19.7 missing 88110a9f6209
Do you really mean this commit ("clk: bcm2835: fix
bcm2835_clock_choose_div")?
I think this is applied in 5.19.7:
https://elixir.bootlin.com/linux/v5.19.7/source/drivers/clk/bcm/clk-bcm2835.c#L944
>
>> - Reintroduce the clk_set_min_rate call to HDMI's runtime_resume, or
>> some other equivalent code
> I just sent a series addressing this here:
> https://lore.kernel.org/r/20220929-rpi-pi3-unplugged-fixes-v1-0-cd22e962296c@cerno.tech
Thanks
>
> Thanks for the report and the help :)
> Maxime
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
2022-09-29 13:46 ` Stefan Wahren
@ 2022-09-29 14:15 ` Maxime Ripard
0 siblings, 0 replies; 23+ messages in thread
From: Maxime Ripard @ 2022-09-29 14:15 UTC (permalink / raw)
To: Stefan Wahren; +Cc: Marc Kleine-Budde, dri-devel, Emma Anholt, linux-rpi-kernel
[-- Attachment #1: Type: text/plain, Size: 7607 bytes --]
On Thu, Sep 29, 2022 at 03:46:01PM +0200, Stefan Wahren wrote:
> Am 29.09.22 um 11:35 schrieb Maxime Ripard:
> > On Tue, Sep 27, 2022 at 03:15:17PM +0200, Maxime Ripard wrote:
> > > On Tue, Sep 27, 2022 at 02:25:12PM +0200, Maxime Ripard wrote:
> > > > On Tue, Sep 27, 2022 at 01:42:40PM +0200, Maxime Ripard wrote:
> > > > > On Tue, Sep 27, 2022 at 01:12:35PM +0200, Stefan Wahren wrote:
> > > > > > Am 27.09.22 um 11:42 schrieb Maxime Ripard:
> > > > > > > On Tue, Sep 27, 2022 at 09:25:54AM +0200, Maxime Ripard wrote:
> > > > > > > > Hi Stefan,
> > > > > > > >
> > > > > > > > On Mon, Sep 26, 2022 at 08:50:12PM +0200, Stefan Wahren wrote:
> > > > > > > > > Am 26.09.22 um 14:47 schrieb Maxime Ripard:
> > > > > > > > > > On Mon, Sep 26, 2022 at 02:40:48PM +0200, Marc Kleine-Budde wrote:
> > > > > > > > > > > On 26.09.2022 14:08:04, Stefan Wahren wrote:
> > > > > > > > > > > > Hi Marc,
> > > > > > > > > > > >
> > > > > > > > > > > > Am 26.09.22 um 12:21 schrieb Marc Kleine-Budde:
> > > > > > > > > > > > > On 22.09.2022 17:06:00, Maxime Ripard wrote:
> > > > > > > > > > > > > > > I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64,
> > > > > > > > > > > > > > > using Debian's v5.19 kernel (Debian's v5.18 was working flawless).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> > > > > > > > > > > > > > > | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0
> > > > > > > > > > > > > > > 9-01)
> > > > > > > > > > > > > > > | [ 0.000000] Machine model: Raspberry Pi 3 Model B+
> > > > > > > > > > > > > > > | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > As soon a the vc4 module is loaded the following warnings hits 4
> > > > > > > > > > > > > > > times, then the machine stops.
> > > > > > > > > > > > > [...]
> > > > > > > > > > > > >
> > > > > > > > > > > > > > The warning itself is fixed, both upstream and in stable (5.19.7).
> > > > > > > > > > > > > Ok. Debian is using 5.19.6
> > > > > > > > > > > > >
> > > > > > > > > > > > > > It shouldn't have any relation to the hang though. Can you share your
> > > > > > > > > > > > > > setup?
> > > > > > > > > > > > > - config.txt:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -------->8-------->8-------->8-------->8--------
> > > > > > > > > > > > > gpu_mem=16
> > > > > > > > > > > > > disable_splash=1
> > > > > > > > > > > > >
> > > > > > > > > > > > > arm_64bit=1
> > > > > > > > > > > > > enable_uart=1
> > > > > > > > > > > > > uart_2ndstage=1
> > > > > > > > > > > > >
> > > > > > > > > > > > > os_prefix=/u-boot/
> > > > > > > > > > > > >
> > > > > > > > > > > > > [pi3]
> > > > > > > > > > > > > force_turbo=1
> > > > > > > > > > > > > -------->8-------->8-------->8-------->8--------
> > > > > > > > > > > > >
> > > > > > > > > > > > > - Raspberry Pi 3 Model B+
> > > > > > > > > > > > > - no HDMI connected
> > > > > > > > > > > > Does it mean, the issue only occurs without HDMI connected?
> > > > > > > > > > > > If you didn't test with HDMI yet, could you please do?
> > > > > > > > > > > The error occurs with HDMI not connected, as vc4 is the gfx driver I
> > > > > > > > > > > thought this might be of interest. :)
> > > > > > > > > > >
> > > > > > > > > > > I don't have a HDMI monitor here, but I'll come back to you as soon as I
> > > > > > > > > > > get access to one (might take some time).
> > > > > > > > > > It's not the first time an issue like this one would occur. I'm trying
> > > > > > > > > > to make my Pi3 boot again, and will try to bisect the issue.
> > > > > > > > > yes the issue is only triggered without HDMI connected. I was able to
> > > > > > > > > reproduce with an older vc4 firmware from 2020 (don't want to upgrade yet).
> > > > > > > > > Kernel was also an arm64 build with defconfig.
> > > > > > > > >
> > > > > > > > > Here some rough starting point for bisection:
> > > > > > > > >
> > > > > > > > > 5.18.0 good
> > > > > > > > > 5.19.0 bad
> > > > > > > > > 5.19.6 bad
> > > > > > > > Sorry it took a bit of time, it looks like I found another bug while
> > > > > > > > trying to test this yesterday.
> > > > > > > >
> > > > > > > > Your datapoints are interesting though. I have a custom configuration
> > > > > > > > and it does boot 5.19 without an HDMI connected.
> > > > > > > >
> > > > > > > > So I guess it leaves us with either the firmware version being different
> > > > > > > > (I'm using a newer version, from March 2022), or the configuration. I'll
> > > > > > > > test with defconfig.
> > > > > > > So it turns out compiling vc4 as a module is the culprit.
> > > > > > Do you mean regardless of the kernel version in your case?
> > > > > No, I mean that, with vc4 as a module, 5.18 works but 5.19 doesn't, like
> > > > > Marc said. But if vc4 is built in, both work.
> > > > >
> > > > > > In my test cases i build vc4 always as module.
> > > > > >
> > > > > > > It's not clear to me why at this point, but the first register write in
> > > > > > > vc4_hdmi_reset stalls.
> > > > > > Sounds like timing issue or a missing dependency (clock or power domain)
> > > > > It felt like a clock or power domain issue to me indeed, but adding
> > > > > clk_ignore_unused and pd_ignore_unused isn't enough, so it's probably
> > > > > something a bit more complicated than just the clock / PD being
> > > > > disabled.
> > > > I found the offending patch:
> > > > https://lore.kernel.org/dri-devel/20220225143534.405820-13-maxime@cerno.tech/
> > > >
> > > > That code was removed because it was made irrelevant by that earlier patch:
> > > > https://lore.kernel.org/dri-devel/20220225143534.405820-10-maxime@cerno.tech/
> > > >
> > > > But it turns out that while it works when the driver is built-in, it
> > > > doesn't when it's a module. If we add a clk_hw_get_rate() call right
> > > > after that call to raspberrypi_fw_set_rate(), the rate returned is 0.
> > > >
> > > > I'm not entirely sure why, but I wonder if it's related to:
> > > > https://github.com/raspberrypi/linux/issues/4962#issuecomment-1228593439
> > > Turns out it's not, since the Pi3 is using the clk-bcm2835 driver.
> > >
> > > However, even reverting that patch fails. clk_set_min_rate fails because
> > > the rate is protected, but it doesn't look like it is anywhere for that
> > > clock, so I'm a bit confused.
> > >
> > > Even if we do remove the clock protection check in
> > > clk_core_set_rate_nolock(), clk_calc_new_rates() will then fail because
> > > the bcm2835 driver will round the clock rate below the minimum, which is
> > > rejected.
> > >
> > > I'm not entirely sure what to do at this point. I guess the proper fix
> > > would be to:
> > > - Figure out why it's considered protected when it's not (or shouldn't be)
> > > - Make the driver compute an acceptable rate for that clock
> > This was due to 5.19.7 missing 88110a9f6209
>
> Do you really mean this commit ("clk: bcm2835: fix
> bcm2835_clock_choose_div")?
>
> I think this is applied in 5.19.7:
>
> https://elixir.bootlin.com/linux/v5.19.7/source/drivers/clk/bcm/clk-bcm2835.c#L944
You're right, I got confused and encountered this issue while bisecting,
so half-way from 5.18 through 5.19.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2022-09-29 14:15 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-22 14:54 Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume() Marc Kleine-Budde
2022-09-22 15:06 ` Maxime Ripard
2022-09-26 10:21 ` Marc Kleine-Budde
2022-09-26 12:08 ` Stefan Wahren
2022-09-26 12:40 ` Marc Kleine-Budde
2022-09-26 12:47 ` Maxime Ripard
2022-09-26 18:50 ` Stefan Wahren
2022-09-27 7:25 ` Maxime Ripard
2022-09-27 8:56 ` Stefan Wahren
2022-09-27 9:42 ` Maxime Ripard
2022-09-27 11:12 ` Stefan Wahren
2022-09-27 11:36 ` Marc Kleine-Budde
2022-09-27 11:42 ` Maxime Ripard
2022-09-27 12:25 ` Maxime Ripard
2022-09-27 13:15 ` Maxime Ripard
2022-09-27 13:35 ` Maxime Ripard
2022-09-27 18:45 ` Stefan Wahren
2022-09-27 18:47 ` Info Skymem
2022-09-29 9:35 ` Maxime Ripard
2022-09-29 13:46 ` Stefan Wahren
2022-09-29 14:15 ` Maxime Ripard
2022-09-22 16:19 ` Stefan Wahren
2022-09-27 7:51 ` Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume() #forregzbot Thorsten Leemhuis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).