STICKY: Bullseye - Comments and bug reports thread.

[twilightened]

RPI 4 (4gb), 32 bit RPI OS with the latest updates. Desktop stops responding after a short while right after a boot. It is momentarily, lasts around 20 seconds. This started to happen within the last 2 months or so after a set of updates. Still happens. It is not a big deal but it is a nuissance to wait for it to get back to responsive. Like i said it happens only once (well maybe twice, second one is usually shorter) right after a log on. Maybe a change in the boot process is to blame. I don't know.

[dom]

RPI 4 (4gb), 32 bit RPI OS with the latest updates. Desktop stops responding after a short while right after a boot. It is momentarily, lasts around 20 seconds. This started to happen within the last 2 months or so after a set of updates. Still happens. It is not a big deal but it is a nuissance to wait for it to get back to responsive. Like i said it happens only once (well maybe twice, second one is usually shorter) right after a log on. Maybe a change in the boot process is to blame. I don't know.

If you have a spare sdcard, then testing whether a clean sdcard install has the issue would be useful.
If it doesn't then allow the normal apt updates - does it do it then?

[twilightened]

RPI 4 (4gb), 32 bit RPI OS with the latest updates. Desktop stops responding after a short while right after a boot. It is momentarily, lasts around 20 seconds. This started to happen within the last 2 months or so after a set of updates. Still happens. It is not a big deal but it is a nuissance to wait for it to get back to responsive. Like i said it happens only once (well maybe twice, second one is usually shorter) right after a log on. Maybe a change in the boot process is to blame. I don't know.

If you have a spare sdcard, then testing whether a clean sdcard install has the issue would be useful.
If it doesn't then allow the normal apt updates - does it do it then?

I think i have found the issue:

Run 1
prepare-file;0;0;5039;9
seq-write;0;0;7797;15
rand-4k-write;0;0;2620;655
rand-4k-read;11391;2847;0;0
Sequential write speed 7797 KB/sec (target 10000) - FAIL
Note that sequential write speed declines over time as a card is used - your card may require reformatting
Random write speed 655 IOPS (target 500) - PASS
Random read speed 2847 IOPS (target 1500) - PASS

Run 2
prepare-file;0;0;6142;11
seq-write;0;0;6038;11
rand-4k-write;0;0;2088;522
rand-4k-read;11090;2772;0;0
Sequential write speed 6038 KB/sec (target 10000) - FAIL
Note that sequential write speed declines over time as a card is used - your card may require reformatting
Random write speed 522 IOPS (target 500) - PASS
Random read speed 2772 IOPS (target 1500) - PASS

Run 3
prepare-file;0;0;6115;11
seq-write;0;0;6066;11
rand-4k-write;0;0;2039;509
rand-4k-read;11047;2761;0;0
Sequential write speed 6066 KB/sec (target 10000) - FAIL
Note that sequential write speed declines over time as a card is used - your card may require reformatting
Random write speed 509 IOPS (target 500) - PASS
Random read speed 2761 IOPS (target 1500) - PASS
Test FAIL

[hippy]

Desktop stops responding after a short while right after a boot. It is momentarily, lasts around 20 seconds.

I think i have found the issue:

Sequential write speed 7797 KB/sec (target 10000) - FAIL

It seems unlikely to me that the SD Card not being quite as fast as might be desirable is the cause of the Pi going unresponsive for so long. I have used Pi with far slower cards than that and haven't observed any problems seemingly caused by doing so. In fact I have only recently used cards which don't fail the tests.

If it were a card speed issue then all a faster card would do is reduce the period of unresponsiveness. You aren't too far off the targets so would seem to be needing a card many times faster than the target to reduce that period to almost nothing, which doesn't seem plausible.

That said my Pi 3B does, more regularly than I'd like, go unresponsive for 15 seconds or so at a time. Never figured out why, and that's 32-bit Buster, so, if it is a systemic issue, it pre-dates Bullseye.

[twilightened]

Desktop stops responding after a short while right after a boot. It is momentarily, lasts around 20 seconds.

I think i have found the issue:

Sequential write speed 7797 KB/sec (target 10000) - FAIL

It seems unlikely to me that the SD Card not being quite as fast as might be desirable is the cause of the Pi going unresponsive for so long. I have used Pi with far slower cards than that and haven't observed any problems seemingly caused by doing so. In fact I have only recently used cards which don't fail the tests.

If it were a card speed issue then all a faster card would do is reduce the period of unresponsiveness. You aren't too far off the targets so would seem to be needing a card many times faster than the target to reduce that period to almost nothing, which doesn't seem plausible.

That said my Pi 3B does, more regularly than I'd like, go unresponsive for 15 seconds or so at a time. Never figured out why, and that's 32-bit Buster, so, if it is a systemic issue, it pre-dates Bullseye.

I had my own doubts about that so thanks for the support. I am living with it. Not a big issue to be honest. In the end, RPI is not the fastest computer anyway. So it is ok to wait for some time for it to come back alive. I am an old and slow guy myself 40 something. Not big on exercise. I love playing basketball though. Oh i should shut up now.

[tinker2much]

I've noticed that I can rerun failed sd card speed tests just a few minutes later, and get wildly better results. I have many pi models and many makes/models/sizes/vintages of cards, and I haven't fully investigated this. The particular examples below are from a 2B and a Samsung Evo+ 32GB card. The random and sequential writes are the ones that change so much. Could some mysterious process running or writing during the first try explain the slowness? It's hard to believe that the performance of the card itself is that variable...

Here's one example (slow first), the results of a script of mine giving hostname, pi details, sd card details, hdparm test results reformatted to look like sdtest results (with an arbitrary norm of 20MB/sec), and then the usual sd card test stuff:

Code: Select all

pi2
2B      1.1     1GB
Samsung Evo+    U1      32      82
buffered disk reads: 31.26 MB/sec (target 20.00) - PASS 156%
Random read speed 2981 IOPS (target 1500) - PASS 198%
Random write speed 413 IOPS (target 500) - FAIL 82%
Sequential write speed 19015 KB/sec (target 10000) - PASS 190%

Now, the faster version (same pi, same card):

Code: Select all

pi2
2B	1.1	1GB
Samsung	Evo+	U1	32	82
buffered disk reads: 31.23 MB/sec (target 20.00) - PASS 156%
Random read speed 3061 IOPS (target 1500) - PASS 204%
Random write speed 917 IOPS (target 500) - PASS 183%
Sequential write speed 21140 KB/sec (target 10000) - PASS 211%

[tinker2much]

Here's the same situation - widely different speed test results, in particular the writes, this time on a Zero W, with a SanDisk card. And, yes, both the 2B and the ZeroW are bullseye, 32-bit.

Code: Select all

pi0w5
Zero W	1.1	512MB
SanDisk	Ultra PLUS	U1	16	93
buffered disk reads: 22.11 MB/sec (target 20.00) - PASS 110%
Random read speed 1748 IOPS (target 1500) - PASS 116%
Random write speed 611 IOPS (target 500) - PASS 122%
Sequential write speed 7059 KB/sec (target 10000) - FAIL 70%

Code: Select all

pi0w5
Zero W	1.1	512MB
SanDisk	Ultra PLUS	U1	16	93
buffered disk reads: 21.90 MB/sec (target 20.00) - PASS 109%
Random read speed 1754 IOPS (target 1500) - PASS 116%
Random write speed 790 IOPS (target 500) - PASS 158%
Sequential write speed 13557 KB/sec (target 10000) - PASS 135%

[beta-tester]

i guess the differences in speed comes from the different tasks running in the background.

[pidd]

Could also be the cpu frequency governor, by default it is in ondemand mode which varies frequency considerably depending on load.

[twilightened]

I don't remember seeing any updates for the last two weeks or so. Is that normal? sudo apt update says everything is up to date. It has been saying that for a long time now.

[bensimmo]

Quite normal, happens for a while every now and again.
That and Bookworm is the new Debian, so all Debian work goes there and I guess RPiOS will be too. (no RPiOS version of it though, yet...)

[JumpZero]

I refer to the problem previously mentioned here 2 months ago.
So it seems my screen blanking issue is solved, but anyway it is strange:
Today I added a second monitor to my pi400 and the screen blanking started to work as expected!
The config is the following:
HDMI1 = HP2311x
HDMI2 = Samsung S24D340H

- with both screens and vc4-kms-v3d enabled in config.txt screen blanking is working
- with only 1 screen (HDMI1) = Samsung S24D340H and vc4-kms-v3d enabled in config.txt screen blanking is working
- with only 1 screen (HDMI1) = HP2311x and vc4-kms-v3d enabled in config.txt screen blanking is NOT working

For this later configuration, as previously mentioned, I must revert from vc4-kms-v3d to vc4-fkms-v3d to have screen blanking working.

So I conclude that the problem is with this HP2311x screen. Does it meet the full HDMI specs?...
As already said the screen goes blanking but just for a few seconds. I wonder what event causes it to wake up. Xevent didn't find anything.
Ok not a big deal!

[twilightened]

I refer to the problem previously mentioned here 2 months ago.
So it seems my screen blanking issue is solved, but anyway it is strange:
Today I added a second monitor to my pi400 and the screen blanking started to work as expected!
The config is the following:
HDMI1 = HP2311x
HDMI2 = Samsung S24D340H

- with both screens and vc4-kms-v3d enabled in config.txt screen blanking is working
- with only 1 screen (HDMI1) = Samsung S24D340H and vc4-kms-v3d enabled in config.txt screen blanking is working
- with only 1 screen (HDMI1) = HP2311x and vc4-kms-v3d enabled in config.txt screen blanking is NOT working

For this later configuration, as previously mentioned, I must revert from vc4-kms-v3d to vc4-fkms-v3d to have screen blanking working.

So I conclude that the problem is with this HP2311x screen. Does it meet the full HDMI specs?...
As already said the screen goes blanking but just for a few seconds. I wonder what event causes it to wake up. Xevent didn't find anything.
Ok not a big deal!

swap hdmi cables and try. it might be the culprit.

[JumpZero]

I refer to the problem previously mentioned here 2 months ago.
So it seems my screen blanking issue is solved, but anyway it is strange:
Today I added a second monitor to my pi400 and the screen blanking started to work as expected!
The config is the following:
HDMI1 = HP2311x
HDMI2 = Samsung S24D340H

- with both screens and vc4-kms-v3d enabled in config.txt screen blanking is working
- with only 1 screen (HDMI1) = Samsung S24D340H and vc4-kms-v3d enabled in config.txt screen blanking is working
- with only 1 screen (HDMI1) = HP2311x and vc4-kms-v3d enabled in config.txt screen blanking is NOT working

For this later configuration, as previously mentioned, I must revert from vc4-kms-v3d to vc4-fkms-v3d to have screen blanking working.

So I conclude that the problem is with this HP2311x screen. Does it meet the full HDMI specs?...
As already said the screen goes blanking but just for a few seconds. I wonder what event causes it to wake up. Xevent didn't find anything.
Ok not a big deal!

swap hdmi cables and try. it might be the culprit.

Good point! Tested today but no the cable isn't the culprit. Screen blanking isn't working only when the HP2311x monitor is alone on HDMI1. In all other configurations (S24D340H alone, S24D340H + HP2311x in HDMI1 or 2) screen blanking works.

[easy-and-simple]

BUGS REPORT

It is not possible to log-in to desktop via realvnc ii wayland is enabled, because login prompt can't be removed, and if login promt appear desktop can't be entered via realvnc no matter with or without wayland.
So from there we have 2 issues:
1. Can't log-in to desktop vie vnc if user is not already logged-in. If user is auto logged-in and log-out it can't log-in again via realvnc connection
2. If wayland is enabled desktop auto log-in doesn't work and as a result desktop can't be accessed via realvnc

Next issue is with RDP
User root and default user can't log-in via RDP. If new user is created it can log-in but can't do anything because there are no groups assigned to it. Because sudo group is most important I assign at first sudo group and it can log-in and perform sudo command but user is limited and for example can't see camera window. If I add some other group to the new user in addition to sudo user can't log-in via RDP

Chrome browser have super lag if user is logged-in via realvnc and is completely useless. In same conditions firefox is responsive. There is no such issue if user is logged via RDP

[bensimmo]

Wayland
https://help.realvnc.com/hc/en-us/artic ... C-Connect-

Use something else.

[HermannSW]

Wayland
https://help.realvnc.com/hc/en-us/artic ... C-Connect-

Use something else.

I have this problem, the Ubuntu 22.04 on 7600X CPU runs Wayland.
I had disabled Wayland by the method you pointed to, and just did it again.
After that Ubuntu "Settings" does show X11 and not Wayland.
And gimp is able to take screenshots, only black with Wayland:

no_wayland.png

no_wayland.png (19.32 KiB) Viewed 2882 times

The question I have is, which pair of vnc client(64bit PiOS) and vnc server(Ubuntu) does work?
I tried xtightvncclient/xtightvncserver and see grey empty screen only...


I really would like to get rid of 2nd keyboard and mouse I have to use currently:
viewtopic.php?p=2116569#p2116569

[easy-and-simple]

Wayland
https://help.realvnc.com/hc/en-us/artic ... C-Connect-

Use something else.

This link is for other issue. I don;t have blank screen. I see desktop, but VNC server can't log me in after I enter password.Also black screen is not caused by wayland. I am sure because I had this issue while I tried to find solution for my issue.
You didn't read what is the broblem. Problem is in unsuccessful login not in wayland. Read more carefully
Your logic "use something else" is bad

[pidd]

Wayland
https://help.realvnc.com/hc/en-us/artic ... C-Connect-

Use something else.

This link is for other issue. I don;t have blank screen. I see desktop, but VNC server can't log me in after I enter password.Also black screen is not caused by wayland. I am sure because I had this issue while I tried to find solution for my issue.
You didn't read what is the broblem. Problem is in unsuccessful login not in wayland. Read more carefully
Your logic "use something else" is bad

Regardless of what you consider to be your problem, you are using wayland and RealVNC is not compatible with waylaid,. Fix that problem and maybe a miracle will happen and all your problems may go away.

I fail to follow your logic that you should continue to use something that is known not to work. "use something else" appears to be the most logical answer.

[bensimmo]

Wayland
https://help.realvnc.com/hc/en-us/artic ... C-Connect-

Use something else.

This link is for other issue. I don;t have blank screen. I see desktop, but VNC server can't log me in after I enter password.Also black screen is not caused by wayland. I am sure because I had this issue while I tried to find solution for my issue.
You didn't read what is the broblem. Problem is in unsuccessful login not in wayland. Read more carefully
Your logic "use something else" is bad

I did read, I was just replying to the Wayland issue only. Maybe this one is better
https://help.realvnc.com/hc/en-us/artic ... g-on-Linux

Not the general issue if Wayland is not used and you still cannot log in.
I'm sure others will be able to help with your problem where Wayland is disabled.
But RealVNC have a support section, use them too.

[easy-and-simple]

Wayland
https://help.realvnc.com/hc/en-us/artic ... C-Connect-

Use something else.

This link is for other issue. I don;t have blank screen. I see desktop, but VNC server can't log me in after I enter password.Also black screen is not caused by wayland. I am sure because I had this issue while I tried to find solution for my issue.
You didn't read what is the broblem. Problem is in unsuccessful login not in wayland. Read more carefully
Your logic "use something else" is bad

I did read, I was just replying to the Wayland issue only. Maybe this one is better
https://help.realvnc.com/hc/en-us/artic ... g-on-Linux

Not the general issue if Wayland is not used and you still cannot log in.
I'm sure others will be able to help with your problem where Wayland is disabled.
But RealVNC have a support section, use them too.

No this is not the issue, because wayland doesn't cause video problems. Problem is caused obviously by vnc server itself, because it can't log-in user to desktop. On other side there is problem with raspi-config because it cant set desktop auto log-in then wayland is enabled

[bensimmo]

Of course it is RealVNC, it just doesn't work with Wayland. RealVNC tell you that. I linked to a page telling you that.
You can try all you like to use Wayland.
You cannot use Wayland with RealVNC, until RealVNC fix it.
To find out more, ask them, they may have a fix in testing.

Perhaps there is something missing in yours and my descriptions to each other.

Auto-login with no Wayland is a different issue.

So disable Wayland, tell us your Pi/Computer setup in a new thread/topic post and people can help.


----
This is as far as I've got..

We are assuming you have PiOS installed on a RaspberryPi of some sort and you have enabled RealVNC and the 'in testing, not recommend for use Wayland option'.
You are then connecting from another computer

We know Wayland will not work with the VNC setup, so that needs to go.

You then say there is still a problem.
When you log over VNC it doesn't auto log in.?
Post about that in a new Topic.

[twilightened]

I used to have problems with my bluetooth earbuds connecting to my RPI4. Everytime i wanted to connect, i was forced to "remove" the device and then repair it. Connection without repairing wouldn't work.

Now that i have a second (and different) pair of BT earbuds, i thought it would be different, but it is exactly the same.

Why am i having these connection issues with BT earbuds in RPI? Is this normal? Are everybodys' experience the same when it comes to BT audio connections?

[klricks]

I used to have problems with my bluetooth earbuds connecting to my RPI4. Everytime i wanted to connect, i was forced to "remove" the device and then repair it. Connection without repairing wouldn't work.

Now that i have a second (and different) pair of BT earbuds, i thought it would be different, but it is exactly the same.

Why am i having these connection issues with BT earbuds in RPI? Is this normal? Are everybodys' experience the same when it comes to BT audio connections?

I have no problem with my cheap Onn BT earbuds.
Make sure that the earbud is not connecting to another BT device such as a phone. If so turn off BT on the phone before attempting to connect with the RPi.

[twilightened]

I used to have problems with my bluetooth earbuds connecting to my RPI4. Everytime i wanted to connect, i was forced to "remove" the device and then repair it. Connection without repairing wouldn't work.

Now that i have a second (and different) pair of BT earbuds, i thought it would be different, but it is exactly the same.

Why am i having these connection issues with BT earbuds in RPI? Is this normal? Are everybodys' experience the same when it comes to BT audio connections?

I have no problem with my cheap Onn BT earbuds.
Make sure that the earbud is not connecting to another BT device such as a phone. If so turn off BT on the phone before attempting to connect with the RPi.

I used to have a pair of Lenovos. Every time i had to re-pair them (remove them from the bluetooth memory and then reconnect). They are gone now and i have a pair of Omthing Airfree earbuds (they are pretty decent). It is pretty much the same story. Sometimes when i take them out of the box, i again have to re-pair them (remove first and pair after) just to have them connected as an audio target. Otherwise if i select them as audio output, i get a connection error.

However, i also have a bluetooth speaker and it just connects instantly. I had no issues whatsoever. So i guess it has a far better BT chip inside. I am unlucky with my BT earbuds.

"Failed to connect, resource temporarily unavailable". This is the error i get when i try to select my BT earbuds as audio output. In that case, what i have to do is to "remove" BT earbuds from paired devices. Then search for BT devices and re-pair them. Only after that i can select them as output.

So why does this happen?