Hi all!
I've got a Raspberry Pi 3b+ with Fedora 30 on SD cards running armv7 and aarch64. I recently installed updates with dnf on both after a few weeks, and after reboot I can no longer get into a graphical login.
The shell fails to find a GPU which leads the session to fail:
--------- Apr 26 02:49:52 lilbit gnome-shell[916]: Failed to create backend: No GPUs found with udev Apr 26 02:49:52 lilbit gnome-session[889]: gnome-session-binary[889]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1 Apr 26 02:49:52 lilbit gnome-session-binary[889]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1 Apr 26 02:49:52 lilbit gnome-session-binary[889]: Unrecoverable failure in required component org.gnome.Shell.desktop Apr 26 02:49:52 lilbit systemd-logind[725]: Failed to restore VT, ignoring: Input/output error ---------
(Don't mind the wrong date, the system clock is wrong until networking comes up.)
These SD cards were originally installed with Fedora 29 and upgraded via dnf-system-upgrade, so that might lead to something funky in the boot partitions perhaps; if that's an expected sort of failure I can just reinstall. :)
Thanks for any advice!
-- brion
Hi Brion,
I've got a Raspberry Pi 3b+ with Fedora 30 on SD cards running armv7 and aarch64. I recently installed updates with dnf on both after a few weeks, and after reboot I can no longer get into a graphical login.
What kernel is this? I'm presuming you're running the Workstation images here, and not something hand crafted.
The shell fails to find a GPU which leads the session to fail:
Apr 26 02:49:52 lilbit gnome-shell[916]: Failed to create backend: No GPUs found with udev Apr 26 02:49:52 lilbit gnome-session[889]: gnome-session-binary[889]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1 Apr 26 02:49:52 lilbit gnome-session-binary[889]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1 Apr 26 02:49:52 lilbit gnome-session-binary[889]: Unrecoverable failure in required component org.gnome.Shell.desktop Apr 26 02:49:52 lilbit systemd-logind[725]: Failed to restore VT, ignoring: Input/output error
(Don't mind the wrong date, the system clock is wrong until networking comes up.)
These SD cards were originally installed with Fedora 29 and upgraded via dnf-system-upgrade, so that might lead to something funky in the boot partitions perhaps; if that's an expected sort of failure I can just reinstall. :)
Thanks for any advice!
-- brion
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Hi,
On 09.06.19 18:52, Brion Vibber wrote:
Hi all!
I've got a Raspberry Pi 3b+ with Fedora 30 on SD cards running armv7 and aarch64. I recently installed updates with dnf on both after a few weeks, and after reboot I can no longer get into a graphical login.
the output of the kernel log would be more helpful.
Regards Stefan
Hi all,
after F-30 runs from MicroSD for me now I tried to run X (so far I had runlevel "3") and I get the same messages.
Nothing important, I can try also new installation of F-30.
On Thu, 20 Jun 2019 12:03:59 +0200, Peter Robinson wrote:
What kernel is this?
kernel-5.2.0-0.rc5.git0.1.fc31.aarch64
I'm presuming you're running the Workstation images here, and not something hand crafted.
The same as OP - F-29 upgraded to F-30. I do not remember which image it was but I expect Workstation as I have also fedora-release-workstation-30-4.noarch.
On Thu, 20 Jun 2019 13:03:34 +0200, Stefan Wahren wrote:
the output of the kernel log would be more helpful.
Attached.
Jan
Hi Jan,
On 24.06.19 16:41, Jan Kratochvil wrote:
Hi all,
after F-30 runs from MicroSD for me now I tried to run X (so far I had runlevel "3") and I get the same messages.
Nothing important, I can try also new installation of F-30.
On Thu, 20 Jun 2019 12:03:59 +0200, Peter Robinson wrote:
What kernel is this?
kernel-5.2.0-0.rc5.git0.1.fc31.aarch64
I'm presuming you're running the Workstation images here, and not something hand crafted.
The same as OP - F-29 upgraded to F-30. I do not remember which image it was but I expect Workstation as I have also fedora-release-workstation-30-4.noarch.
On Thu, 20 Jun 2019 13:03:34 +0200, Stefan Wahren wrote:
the output of the kernel log would be more helpful.
Attached.
thanks this is very helpful, unfortunately this is a know but unresolved issue:
[ 33.547901] bcm2835-power bcm2835-power: Timeout waiting for grafx power OK
https://github.com/anholt/linux/issues/153
Jan
On Mon, 24 Jun 2019 17:09:38 +0200, Stefan Wahren wrote:
thanks this is very helpful, unfortunately this is a know but unresolved issue:
...
For you X works on RPi3B+? As we all should have the same hardware.
Jan
On Mon, Jun 24, 2019 at 4:09 PM Stefan Wahren stefan.wahren@i2se.com wrote:
Hi Jan,
On 24.06.19 16:41, Jan Kratochvil wrote:
Hi all,
after F-30 runs from MicroSD for me now I tried to run X (so far I had runlevel "3") and I get the same messages.
Nothing important, I can try also new installation of F-30.
On Thu, 20 Jun 2019 12:03:59 +0200, Peter Robinson wrote:
What kernel is this?
kernel-5.2.0-0.rc5.git0.1.fc31.aarch64
I'm presuming you're running the Workstation images here, and not something hand crafted.
The same as OP - F-29 upgraded to F-30. I do not remember which image it was but I expect Workstation as I have also fedora-release-workstation-30-4.noarch.
On Thu, 20 Jun 2019 13:03:34 +0200, Stefan Wahren wrote:
the output of the kernel log would be more helpful.
Attached.
thanks this is very helpful, unfortunately this is a know but unresolved issue:
[ 33.547901] bcm2835-power bcm2835-power: Timeout waiting for grafx power OK
So at at quick glance that looks to be due to the new power driver?
On 24.06.19 17:44, Peter Robinson wrote:
On Mon, Jun 24, 2019 at 4:09 PM Stefan Wahren stefan.wahren@i2se.com wrote:
Hi Jan,
On 24.06.19 16:41, Jan Kratochvil wrote:
Hi all,
after F-30 runs from MicroSD for me now I tried to run X (so far I had runlevel "3") and I get the same messages.
Nothing important, I can try also new installation of F-30.
On Thu, 20 Jun 2019 12:03:59 +0200, Peter Robinson wrote:
What kernel is this?
kernel-5.2.0-0.rc5.git0.1.fc31.aarch64
I'm presuming you're running the Workstation images here, and not something hand crafted.
The same as OP - F-29 upgraded to F-30. I do not remember which image it was but I expect Workstation as I have also fedora-release-workstation-30-4.noarch.
On Thu, 20 Jun 2019 13:03:34 +0200, Stefan Wahren wrote:
the output of the kernel log would be more helpful.
Attached.
thanks this is very helpful, unfortunately this is a know but unresolved issue:
[ 33.547901] bcm2835-power bcm2835-power: Timeout waiting for grafx power OK
So at at quick glance that looks to be due to the new power driver?
Correct
I wasn't able to reproduce this on my available boards.
Are you able to reproduce it?
On Tue, Jun 25, 2019 at 6:51 AM Stefan Wahren stefan.wahren@i2se.com wrote:
On 24.06.19 17:44, Peter Robinson wrote:
On Mon, Jun 24, 2019 at 4:09 PM Stefan Wahren stefan.wahren@i2se.com wrote:
Hi Jan,
On 24.06.19 16:41, Jan Kratochvil wrote:
Hi all,
after F-30 runs from MicroSD for me now I tried to run X (so far I had runlevel "3") and I get the same messages.
Nothing important, I can try also new installation of F-30.
On Thu, 20 Jun 2019 12:03:59 +0200, Peter Robinson wrote:
What kernel is this?
kernel-5.2.0-0.rc5.git0.1.fc31.aarch64
I'm presuming you're running the Workstation images here, and not something hand crafted.
The same as OP - F-29 upgraded to F-30. I do not remember which image it was but I expect Workstation as I have also fedora-release-workstation-30-4.noarch.
On Thu, 20 Jun 2019 13:03:34 +0200, Stefan Wahren wrote:
the output of the kernel log would be more helpful.
Attached.
thanks this is very helpful, unfortunately this is a know but unresolved issue:
[ 33.547901] bcm2835-power bcm2835-power: Timeout waiting for grafx power OK
So at at quick glance that looks to be due to the new power driver?
Correct
I wasn't able to reproduce this on my available boards.
Are you able to reproduce it?
Well I see the "bcm2835-power bcm2835-power: Timeout waiting for grafx power OK" error across a pair of 3Bs and a 3A+, I don't see it on a 3B+ but that one is loading the firmware provided DT and enabling the Sense HAT and I suspect the version of the firmware DT, from around late March/early April doesn't have the DT bits for that driver and hence it's not being activated. All are currently on 5.2-rc5 kernel.
Let me know what other details you need.
Peter
On Tue, Jun 25, 2019 at 9:03 AM Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Jun 25, 2019 at 6:51 AM Stefan Wahren stefan.wahren@i2se.com wrote:
On 24.06.19 17:44, Peter Robinson wrote:
On Mon, Jun 24, 2019 at 4:09 PM Stefan Wahren stefan.wahren@i2se.com wrote:
Hi Jan,
On 24.06.19 16:41, Jan Kratochvil wrote:
Hi all,
after F-30 runs from MicroSD for me now I tried to run X (so far I had runlevel "3") and I get the same messages.
Nothing important, I can try also new installation of F-30.
On Thu, 20 Jun 2019 12:03:59 +0200, Peter Robinson wrote:
What kernel is this?
kernel-5.2.0-0.rc5.git0.1.fc31.aarch64
I'm presuming you're running the Workstation images here, and not something hand crafted.
The same as OP - F-29 upgraded to F-30. I do not remember which image it was but I expect Workstation as I have also fedora-release-workstation-30-4.noarch.
On Thu, 20 Jun 2019 13:03:34 +0200, Stefan Wahren wrote:
the output of the kernel log would be more helpful.
Attached.
thanks this is very helpful, unfortunately this is a know but unresolved issue:
[ 33.547901] bcm2835-power bcm2835-power: Timeout waiting for grafx power OK
So at at quick glance that looks to be due to the new power driver?
Correct
I wasn't able to reproduce this on my available boards.
Are you able to reproduce it?
Well I see the "bcm2835-power bcm2835-power: Timeout waiting for grafx power OK" error across a pair of 3Bs and a 3A+, I don't see it on a 3B+ but that one is loading the firmware provided DT and enabling the Sense HAT and I suspect the version of the firmware DT, from around late March/early April doesn't have the DT bits for that driver and hence it's not being activated. All are currently on 5.2-rc5 kernel.
For reference, updating to the latest firmware/firmware DT the driver loads but I don't get an error, just: bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
That's a minimal text only image, display attached but just at a linux console login.
P
Hi Peter,
On 25.06.19 10:10, Peter Robinson wrote:
On Tue, Jun 25, 2019 at 9:03 AM Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Jun 25, 2019 at 6:51 AM Stefan Wahren stefan.wahren@i2se.com wrote:
On 24.06.19 17:44, Peter Robinson wrote:
On Mon, Jun 24, 2019 at 4:09 PM Stefan Wahren stefan.wahren@i2se.com wrote:
Hi Jan,
On 24.06.19 16:41, Jan Kratochvil wrote:
Hi all,
after F-30 runs from MicroSD for me now I tried to run X (so far I had runlevel "3") and I get the same messages.
Nothing important, I can try also new installation of F-30.
On Thu, 20 Jun 2019 12:03:59 +0200, Peter Robinson wrote: > What kernel is this? kernel-5.2.0-0.rc5.git0.1.fc31.aarch64
> I'm presuming you're running the Workstation > images here, and not something hand crafted. The same as OP - F-29 upgraded to F-30. I do not remember which image it was but I expect Workstation as I have also fedora-release-workstation-30-4.noarch.
On Thu, 20 Jun 2019 13:03:34 +0200, Stefan Wahren wrote: > the output of the kernel log would be more helpful. Attached.
thanks this is very helpful, unfortunately this is a know but unresolved issue:
[ 33.547901] bcm2835-power bcm2835-power: Timeout waiting for grafx power OK
So at at quick glance that looks to be due to the new power driver?
Correct
I wasn't able to reproduce this on my available boards.
Are you able to reproduce it?
Well I see the "bcm2835-power bcm2835-power: Timeout waiting for grafx power OK" error across a pair of 3Bs and a 3A+, I don't see it on a 3B+ but that one is loading the firmware provided DT and enabling the Sense HAT and I suspect the version of the firmware DT, from around late March/early April doesn't have the DT bits for that driver and hence it's not being activated. All are currently on 5.2-rc5 kernel.
Thanks
I'm not sure we have the same unterstanding. bcm2835-power requires changes to the DTB from the mainline kernel, but it should be independent from the firmware. bcm2835-power doesn't work without raspberrypi-power, so it's currently a extension, not a full replacement.
For reference, updating to the latest firmware/firmware DT the driver
What file do you mean with firmware DT?
loads but I don't get an error, just: bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
That's a minimal text only image, display attached but just at a linux console login.
Could you please so kind and make an ASCII table for the bad cases with the following columns Raspberry Pi type, kernel, DTB, firmware and add them to the github issue?
P
Hi Stefan,
I wasn't able to reproduce this on my available boards.
Are you able to reproduce it?
Well I see the "bcm2835-power bcm2835-power: Timeout waiting for grafx power OK" error across a pair of 3Bs and a 3A+, I don't see it on a 3B+ but that one is loading the firmware provided DT and enabling the Sense HAT and I suspect the version of the firmware DT, from around late March/early April doesn't have the DT bits for that driver and hence it's not being activated. All are currently on 5.2-rc5 kernel.
Thanks
Sorry for the delay on this.
I'm not sure we have the same unterstanding. bcm2835-power requires changes to the DTB from the mainline kernel, but it should be independent from the firmware. bcm2835-power doesn't work without raspberrypi-power, so it's currently a extension, not a full replacement.
No, that's my understanding as well, I suspect I didn't explain myself well enough.
For reference, updating to the latest firmware/firmware DT the driver
What file do you mean with firmware DT?
The DTs provided by Raspberry Pi in the firmware repo vs the DTs that come with the upstream linux kernel.
loads but I don't get an error, just: bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
That's a minimal text only image, display attached but just at a linux console login.
Could you please so kind and make an ASCII table for the bad cases with the following columns Raspberry Pi type, kernel, DTB, firmware and add them to the github issue?
Sorry, I've not had time to do all that testing across the matrix of devices, it will take some time and I have around 10 days of travel starting on Thursday.
The first test I did do was one of my regular desktop testing devices which has consistently had the issue I did some testing. It's an original RPi 3B with Fedora 30 Workstation (GNOME).
v5.2-rc7 - fails with the following errors, interesting no messages about vc4 driver at all.
[ 6.791023] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver [ 32.891912] bcm2835-power bcm2835-power: Timeout waiting for grafx power OK [ 32.937340] bcm2835-power bcm2835-power: Timeout waiting for grafx power OK
I then did a build, same kernel as above but with the bcm2835-power driver disabled: # CONFIG_BCM2835_POWER is not set
No mention of bcm2835-power (as expected), and just this error from vc4: [ 30.873633] vc4_v3d 3fc00000.v3d: ignoring dependency for device, assuming no driver
Then with the same kernel as the last test (v5.2-rc7 bcm2835-power disabled) plus the following two DT patches reverted:
e1dc2b2e1bef7237fd8fc055fe1ec2a6ff001f91 ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware. 81fc035f07d230c0f687ef09d5ecf2c885dba8ae ARM: bcm283x: Extend the WDT DT node out to cover the whole PM block. (v4)
I have GNOME login back and the following vc4 output from the kernel: [ 30.642235] rc rc0: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0 [ 30.713329] input: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0/input0 [ 30.723690] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping ok [ 30.723755] vc4_hdmi 3f902000.hdmi: ASoC: no DMI vendor name! [ 30.727159] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4]) [ 30.727360] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4]) [ 30.727485] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4]) [ 30.727578] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4]) [ 30.728130] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 30.850400] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 30.865912] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 30.898857] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4]) [ 30.912535] fb0: switching to vc4drmfb from simple [ 30.945281] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0 [ 31.031461] vc4-drm soc:gpu: fb0: vc4drmfb frame buffer device
Finally with GNOME back working again I tried the original v5.2-rc7 kernel (that has the bcm2835-power driver enabled) with the two reverts above for the DT and I get the gnome login again. No output from bcm2835-power (as I'd expected given that it's not enabled in the DT) and the following output for vc4:
[ 30.496519] rc rc0: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0 [ 30.527759] input: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0/input13 [ 30.568408] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping ok [ 30.585494] vc4_hdmi 3f902000.hdmi: ASoC: no DMI vendor name! [ 30.623168] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4]) [ 30.658189] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4]) [ 30.674271] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4]) [ 30.691323] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4]) [ 30.707155] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 30.723158] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 30.739244] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 30.774104] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4]) [ 30.788546] fb0: switching to vc4drmfb from simple [ 30.828593] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0 [ 30.921643] vc4-drm soc:gpu: fb0: vc4drmfb frame buffer device
Let me know what else I can assist with and I'll en-devour to get it done before I leave for travel.
Peter
BTW what's the status of this slightly related patch going upstream (we did pull it in locally): https://patchwork.kernel.org/patch/10945031/
Hi Peter,
On 03.07.19 14:10, Peter Robinson wrote:
Hi Stefan,
loads but I don't get an error, just: bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
That's a minimal text only image, display attached but just at a linux console login.
Could you please so kind and make an ASCII table for the bad cases with the following columns Raspberry Pi type, kernel, DTB, firmware and add them to the github issue?
Sorry, I've not had time to do all that testing across the matrix of devices, it will take some time and I have around 10 days of travel starting on Thursday.
The first test I did do was one of my regular desktop testing devices which has consistently had the issue I did some testing. It's an original RPi 3B with Fedora 30 Workstation (GNOME).
v5.2-rc7 - fails with the following errors, interesting no messages about vc4 driver at all.
[ 6.791023] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver [ 32.891912] bcm2835-power bcm2835-power: Timeout waiting for grafx power OK [ 32.937340] bcm2835-power bcm2835-power: Timeout waiting for grafx power OK
could you please provide the RPi firmware version from dmesg?
I then did a build, same kernel as above but with the bcm2835-power driver disabled: # CONFIG_BCM2835_POWER is not set
No mention of bcm2835-power (as expected), and just this error from vc4: [ 30.873633] vc4_v3d 3fc00000.v3d: ignoring dependency for device, assuming no driver
Then with the same kernel as the last test (v5.2-rc7 bcm2835-power disabled) plus the following two DT patches reverted:
e1dc2b2e1bef7237fd8fc055fe1ec2a6ff001f91 ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware. 81fc035f07d230c0f687ef09d5ecf2c885dba8ae ARM: bcm283x: Extend the WDT DT node out to cover the whole PM block. (v4)
Yes, reverting those patches is the last option. But i only want go this way, in case the new bcm2835 is really broken. Btw the RPi 4 relies on this driver.
Since not all RPis are affected, it isn't clear to me what causes these timeouts (timing, hardware tolerances, power supply, firmware version, overclocking configuration).
Let me know what else I can assist with and I'll en-devour to get it done before I leave for travel.
Peter
BTW what's the status of this slightly related patch going upstream (we did pull it in locally): https://patchwork.kernel.org/patch/10945031/
Apologize, i missed to add a Fixes tag. Except from this the patch has been applied and will be in Linux 5.3:
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/com...
But i don't know why this branch isn't merged into linux-next.
Best regards Stefan
On Wed, Jul 3, 2019 at 3:14 PM Stefan Wahren stefan.wahren@i2se.com wrote:
Hi Peter,
On 03.07.19 14:10, Peter Robinson wrote:
Hi Stefan,
loads but I don't get an error, just: bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
That's a minimal text only image, display attached but just at a linux console login.
Could you please so kind and make an ASCII table for the bad cases with the following columns Raspberry Pi type, kernel, DTB, firmware and add them to the github issue?
Sorry, I've not had time to do all that testing across the matrix of devices, it will take some time and I have around 10 days of travel starting on Thursday.
The first test I did do was one of my regular desktop testing devices which has consistently had the issue I did some testing. It's an original RPi 3B with Fedora 30 Workstation (GNOME).
v5.2-rc7 - fails with the following errors, interesting no messages about vc4 driver at all.
[ 6.791023] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver [ 32.891912] bcm2835-power bcm2835-power: Timeout waiting for grafx power OK [ 32.937340] bcm2835-power bcm2835-power: Timeout waiting for grafx power OK
could you please provide the RPi firmware version from dmesg?
"2019-03-27 15:48" (git commit 9fd387c)
I then did a build, same kernel as above but with the bcm2835-power driver disabled: # CONFIG_BCM2835_POWER is not set
No mention of bcm2835-power (as expected), and just this error from vc4: [ 30.873633] vc4_v3d 3fc00000.v3d: ignoring dependency for device, assuming no driver
Then with the same kernel as the last test (v5.2-rc7 bcm2835-power disabled) plus the following two DT patches reverted:
e1dc2b2e1bef7237fd8fc055fe1ec2a6ff001f91 ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware. 81fc035f07d230c0f687ef09d5ecf2c885dba8ae ARM: bcm283x: Extend the WDT DT node out to cover the whole PM block. (v4)
Yes, reverting those patches is the last option. But i only want go this way, in case the new bcm2835 is really broken. Btw the RPi 4 relies on this driver.
I'm considering reverting them for our stable releases (so 5.1.x kernel) so users can get back to working devices, and I can stop the deluge of support queries, and then we can debug this on 5.2. Are you OK with that?
If figured it would be required for RPi4, but that's a different DT anyway, and a little while off.
Since not all RPis are affected, it isn't clear to me what causes these timeouts (timing, hardware tolerances, power supply, firmware version, overclocking configuration).
We've been on that one firmware for all of F-30, the upstream releases slowed (no doubt due to an upstream focus on the RPi4) and there was nothing really worth us moving to anything newer.
Let me know what else I can assist with and I'll en-devour to get it done before I leave for travel.
Peter
BTW what's the status of this slightly related patch going upstream (we did pull it in locally): https://patchwork.kernel.org/patch/10945031/
Apologize, i missed to add a Fixes tag. Except from this the patch has been applied and will be in Linux 5.3:
No issues, just wanted to make sure it wasn't lost.
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/com...
But i don't know why this branch isn't merged into linux-next.
Best regards Stefan
Hi,
On 03.07.19 17:11, Peter Robinson wrote:
On Wed, Jul 3, 2019 at 3:14 PM Stefan Wahren stefan.wahren@i2se.com wrote:
Hi Peter,
On 03.07.19 14:10, Peter Robinson wrote:
Hi Stefan,
loads but I don't get an error, just: bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
That's a minimal text only image, display attached but just at a linux console login.
Could you please so kind and make an ASCII table for the bad cases with the following columns Raspberry Pi type, kernel, DTB, firmware and add them to the github issue?
Sorry, I've not had time to do all that testing across the matrix of devices, it will take some time and I have around 10 days of travel starting on Thursday.
The first test I did do was one of my regular desktop testing devices which has consistently had the issue I did some testing. It's an original RPi 3B with Fedora 30 Workstation (GNOME).
v5.2-rc7 - fails with the following errors, interesting no messages about vc4 driver at all.
[ 6.791023] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver [ 32.891912] bcm2835-power bcm2835-power: Timeout waiting for grafx power OK [ 32.937340] bcm2835-power bcm2835-power: Timeout waiting for grafx power OK
could you please provide the RPi firmware version from dmesg?
"2019-03-27 15:48" (git commit 9fd387c)
I then did a build, same kernel as above but with the bcm2835-power driver disabled: # CONFIG_BCM2835_POWER is not set
No mention of bcm2835-power (as expected), and just this error from vc4: [ 30.873633] vc4_v3d 3fc00000.v3d: ignoring dependency for device, assuming no driver
Then with the same kernel as the last test (v5.2-rc7 bcm2835-power disabled) plus the following two DT patches reverted:
e1dc2b2e1bef7237fd8fc055fe1ec2a6ff001f91 ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware. 81fc035f07d230c0f687ef09d5ecf2c885dba8ae ARM: bcm283x: Extend the WDT DT node out to cover the whole PM block. (v4)
Yes, reverting those patches is the last option. But i only want go this way, in case the new bcm2835 is really broken. Btw the RPi 4 relies on this driver.
I'm considering reverting them for our stable releases (so 5.1.x kernel) so users can get back to working devices, and I can stop the deluge of support queries, and then we can debug this on 5.2. Are you OK with that?
If figured it would be required for RPi4, but that's a different DT anyway, and a little while off.
there is small progress on this issue. I was able to reproduce this issue on my RPi 3B+. More details here [1]. So from my POV this is definitely a driver issue.
Since Eric doesn't work for Broadcom anymore and the Raspberry Pi Trading isn't able to provide more information about this, i plan to revert
e1dc2b2e1bef7237fd8fc055fe1ec2a6ff001f91 ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware.
with the release of Linux 5.4-rc1.
Best regards Stefan
-
Brion Vibber -
Jan Kratochvil -
Peter Robinson -
Stefan Wahren