search

raspberrypi / Raspberry-Pi-OS-64bit

Repository for containing issues on the 64 bit operating system (as distinct from the 32 bit one)
466 stars 21 forks source link

Blank screen before reaching login prompt #231

Open tilfaeldig opened 2 years ago

tilfaeldig commented 2 years ago

Still - since release in February so about time to report it ?

Booting (or rebooting) ends with a black screen & a solution that works is; turn the screen off & back on again by pulling the power-plug. (long live »the IT-crowd« ;O) then the login-screen appears as 'expected'.

I have a Samsung s22e391h - if I take the RaspBerry Pi over to my brother it boots just fine and dandy on his screen ...

It have never been an issue with 32bit RaspBerry Pi OS so I still run the 32 bit version :(

lurch commented 2 years ago

Possibly something to do with the EDID in your particular monitor, and the way that (AIUI) the EDID gets parsed differently in the 32-bit (by firmware-code) and 64-bit (by userland-code) OSes? ping @popcornmix and @6by9

6by9 commented 2 years ago

Kernel version being used for your 32 bit and 64 bit installs please.

tilfaeldig commented 2 years ago

Possibly something to do with the EDID in your particular monitor, and the way that (AIUI) the EDID gets parsed differently in the 32-bit (by firmware-code) and 64-bit (by userland-code) OSes? ping @popcornmix and @6by9

I've found a few posts on that and they're talking about editing »config.txt« & as one comment to that; It's not a solution - it's a workaround (and adding to that; not a 'beautifull' one ;P)

tilfaeldig commented 2 years ago

Kernel version being used for your 32 bit and 64 bit installs please.

32bit = 5.10.103-v7l+ 64bit = 5.15.32-v8+

But both SD-cards I've used since February have upgraded from previously kernel-versions several times. As I said; I run daily on the 32bit and I try the 64bit at least on monthly basis now (weekly to begin with ;O) to see if an update 'fix' it ...

and btw; THX to the both of you responding to this ! :)))))

popcornmix commented 2 years ago

Possibly something to do with the EDID in your particular monitor, and the way that (AIUI) the EDID gets parsed differently in the 32-bit (by firmware-code) and 64-bit (by userland-code) OSes?

There should be no difference in 32-bit vs 64-bit. Obviously there may be differences between 5.10 and 5.15 kernels (especially as 5.10 is likely buster and so fkms, and 5.15 is likely bullseye and kms).

lurch commented 2 years ago

Right, I think the difference between fkms and kms is probably what I meant, but I wasn't aware that the split was along 5.10 / 5.15 and not 32-bit / 64-bit. Please excuse my ignorance :wink:

tilfaeldig commented 1 year ago

eehmm ok ... I know it's not the most important issue in the Raspi-world ... so would I have to go buy myself a new screen ? and how would I know which one to buy to ensure not having the same issue ? :) In short; please give a 'hint' to; if this issue will ever be looked into & will it be 2023 or 2024 ? :) (it is SO MUCH easier to be 'patient' if getting a wee information ;P) OR do I need to answer any above posts in this thread ?

IDK if I can help with the following addendum; I use my phone as a modem (USB tethering) It doesn't matter if it's connected before turning the Raspi on or not what seems to matter is; I need to hit »dismiss« to the pop-up message on the phone asking to grant access at a VERY specific time during startup I'm NOT able to recreate it 'at-will' - it is a VERY small window that 'works' ... or magically random ? ;O (it's like 1 out of 20 times I do it right) and really rare I instead get the brown screen mentioned in various other places

I know it's not related to this thread but; if I want to access the phone via the USB cable it needs to be connected to the Raspi before turning the Raspi on AND not to be used for tethering beforehand.

In hoping all above is received as being meant with only good intentions ! :)

JamesH65 commented 1 year ago

There are constant changes to the software in this area (because even major monitor manufacturers seem unable to get EDID's correct in some cases), so have you tried the latest Raspberry Pi OS to see if this has been fixed?

For the phone thing, please use the forums where it will get a much bigger audience.

popcornmix commented 1 year ago

I use my phone as a modem (USB tethering) It doesn't matter if it's connected before turning the Raspi on or not what seems to matter is; I need to hit »dismiss« to the pop-up message on the phone asking to grant access at a VERY specific time during startup

This is almost certainly unrelated, and should be reported in a separate issue.

As said earlier this is almost certainly not a 32-bit vs 64-bit issue but a buster vs bullseye issue, and my guess would be a fkms (the default on buster) vs kms (the default on bullseye) issue.

If you want to progress this issue, I'd suggest you find a spare sdcard, and try installing the latest bullseye image, first 32-bit and then 64-bit and without changing anything, report the behaviour (e.g. does boot end with a blank screen, and does powering display off and on again fix it?)

tilfaeldig commented 1 year ago

There are constant changes to the software in this area (because even major monitor manufacturers seem unable to get EDID's correct in some cases), so have you tried the latest Raspberry Pi OS to see if this has been fixed?

I have run the latest (64bit) since July & I update it every week And the screen is somewhat ancient by now (I believe I bought it in 2015) And per below; »and I started out in my very first post here stating it is NOT an issue with the 32bit version ! :)))« thus the EDID did ok ?

For the phone thing, please use the forums where it will get a much bigger audience.

I have no idea where to go with that - as I said; I know it's not related - now I add; maybe it helps to understand the issue ? (the phone/USB - maybe - being able to 'cancel-out' the issue)

tilfaeldig commented 1 year ago

This is almost certainly unrelated, and should be reported in a separate issue.

Maybe I explained to poorly ? :) The issue is NOT an issue now-and-then AND the only thing I can point to - besides random - is hitting dismiss at the 'right' time (I'm an Asperger & believe me; I've spend A LOT of time trying to figure out what cause the issue to be present and what do not)

As said earlier this is almost certainly not a 32-bit vs 64-bit issue but a buster vs bullseye issue, and my guess would be a fkms (the default on buster) vs kms (the default on bullseye) issue.

and I started out in my very first post here stating it is NOT an issue with the 32bit version ! :)))

If you want to progress this issue, I'd suggest you find a spare sdcard, and try installing the latest bullseye image, first 32-bit and then 64-bit and without changing anything, report the behaviour (e.g. does boot end with a blank screen, and does powering display off and on again fix it?)

So it seems the 32bit thing by now is off the table ? :) Are you're saying it's not 'enough' I've run the (64bit) image from back in the summer with ALL upgrades pos ?

popcornmix commented 1 year ago

and I started out in my very first post here stating it is NOT an issue with the 32bit version ! :)))

and you posted:

32bit = 5.10.103-v7l+ 64bit = 5.15.32-v8+

which means you are testing a much older (likely buster) 32-bit image compared to the newer (likely bullseye) 64-bit image. I believe the age of the image is more significant than it being 32-bit or 64-bit.

Are you're saying it's not 'enough' I've run the image from back in the summer with ALL upgrades pos ?

Correct. If you want to get support you need to follow the requests. An image you have been running since the summer has likely had numerous settings changes and packages installed that may be contributing to your issue.

We want to know if a clean, new image has the issue. And in addition is the issue present on a 32-bit image and/or a 64-bit image.

tilfaeldig commented 1 year ago

ehmm not likely ? :) For sure 32bit is Buster & 64bit is Bullseye ?

Currently my kernel is 5.15.76-v8+

I really don't grasp your request - I started this thread based on a clean new 64bit image & a VERY 'used' older 32bit image Used meaning added packages Where the 32bit (older) had no issues but the 64bit (brand new) had -- and had have from back in November 2021 constantly testing new images as they were released

So will above change your request to me ? -- and could you PLEASE tell me how I should have 'guessed' that request based on the writings from July ! :)

lurch commented 1 year ago

For sure 32bit is Buster & 64bit is Bullseye ?

Not necessarily. A 32-bit image can be either Buster or Bullseye, a 64-bit image will be Bullseye. See https://www.raspberrypi.com/software/operating-systems/ for all the different download options. (32-bit Buster images are now Legacy)

I started this thread based on a clean new 64bit image

64-bit, so likely to be a Bullseye image.

a VERY 'used' older 32bit image

An old 32-bit install, so likely to be a Buster image.

Note that an old "upgraded" 32-bit Buster image (Debian 10) is still very different from a 32-bit Bullseye image (Debian 11). This is why people have been asking you to test a new install (of 32-bit Bullseye) on a spare SD card, as this will help narrow down whether the problem is due to a difference in Buster vs. Bullseye, or due to a difference in 32-bit Bullseye vs. 64-bit Bullseye. Trying to compare 32-bit Buster to 64-bit Bullseye simply involves too many different factors.

tilfaeldig commented 1 year ago

Trying to compare 32-bit Buster to 64-bit Bullseye simply involves too many different factors.

.. ok ... I'm gonna volunteer for that approach then ... and basically 'ignore' everything else in this thread except;

could you PLEASE tell me how I should have 'guessed' that request based on the writings from July ! :)

I really fail to see HOW I should have seen/known/'guessed' I were expected to do that testing ! :( I merely point this out in order for people to learn ? :) (I have now spend a LOT of energy trying to see how I could learn & failed so far thus if anyone likes to teach me; please go ahead ;O)

popcornmix commented 1 year ago

The way github issues work is they pop up in notifications when someone creates one or comments, and they usually get a response from a dev here. Usually that triggers a response from original reporter and they appear back in notifications for another cycle.

There is also a lower priority task for us to trawl through older issue seeing if they have been resolved and can be closed or if additional information is needed to progress them. But time is limited.

This issue ended with comments from a couple of devs with no response, so fell into the low priority task. I accept it wasn't clear that you running additional tests was desired.

In future, if an issue is still affecting you, and the issue seems stalled, then a "I'm still getting this issue, anything I can do to help?" message is fine. Even better if you have discovered any additional information that will help narrow it down.

In addition to testing a clean 32/64-bit image, I would be curious if changing: dtoverlay=vc4-kms-v3d to dtoverlay=vc4-fkms-v3d in /boot/config.txt on your failing (bullseye/64-bit) image avoids the problem.

It's just a guess, but that switches back one of the main changes that occurred between buster and bullseye.

tilfaeldig commented 1 year ago

This issue ended with comments from a couple of devs with no response, so fell into the low priority task.

and I figured that to be; they're on to this now and eventually it will yell a end result ;O

I accept it wasn't clear that you running additional tests was desired.

THX :) - I would've if you'd asked me to back then ! :)

In future, if an issue is still affecting you, and the issue seems stalled, then a "I'm still getting this issue, anything I can do to help?" message is fine.

That's what I 'attempted' ? :)

Even better if you have discovered any additional information that will help narrow it down.

Jaer and that's the phone apparently tricking an USB-event ?

In addition to testing a clean 32/64-bit image, I would be curious if changing: dtoverlay=vc4-kms-v3d to dtoverlay=vc4-fkms-v3d in /boot/config.txt on your failing (bullseye/64-bit) image avoids the problem.

It's just a guess, but that switches back one of the main changes that occurred between buster and bullseye.

It is described in various fora among the one @ Raspberrypi.com on 64bit issues & I failed to write that out properly in my July 2. post SORRY It do give a work-a-round (even someone claimed one can't do that as it is ignored during boot-up) ... so will that information annul the request for testing fresh images ?

lurch commented 1 year ago

thus if anyone likes to teach me; please go ahead ;O)

That's what I 'attempted' ? :man_shrugging:

so will that information annul the request for testing fresh images ?

I think it's fair to assume that if there was anything that would "annul" the testing request, @popcornmix wouldn't be asking you to do these tests...

tilfaeldig commented 1 year ago

thus if anyone likes to teach me; please go ahead ;O)

That's what I 'attempted' ? man_shrugging

Not in respect to the fact I failed to see back in July that I had misunderstood a lot ?

so will that information annul the request for testing fresh images ?

I think it's fair to assume that if there was anything that would "annul" the testing request, @popcornmix wouldn't be asking you to do these tests...

But Popcornmix asked BEFORE I made it clear ? (or not ? ;O) that switching kms to fkms is a workaround thus it is a changed situation by now ? :) ... (or not ? ;O)

tilfaeldig commented 1 year ago

It would be nice to hear @popcornmix say if he read that switching from kms to fkms is a work-around that 'fix' the issue & if he still want a test between a new clean 32bit image versus a ditto 64bit ? THANKS in advance for help/reply ! :)

pelwell commented 1 year ago

It's not that difficult. @popcornmix said:

In addition to testing a clean 32/64-bit image, I would be curious if changing: dtoverlay=vc4-kms-v3d to dtoverlay=vc4-fkms-v3d in /boot/config.txt on your failing (bullseye/64-bit) image avoids the problem.

Notice that "In addition", which means that the fkms test is secondary. If that was a gating test then it would have come first.

popcornmix commented 1 year ago

Yes, the test I suggested (switch kms to fkms) is still a very useful data point.

I suspect your issue may be fixed by https://github.com/raspberrypi/linux/pull/5317, but only if a few experiments have certain values. One of which is if a switch from kms to fkms avoids the issue.

Other useful tests are when the screen is blank does it return when you: unplug/replug the hdmi cable switch display into standby and back on switch av input on display to a different source and then back again

If most of the results of these tests get the display back, then I have a good idea what the issue is and there's hopefully an upcoming fix.

tilfaeldig commented 1 year ago

sorry for not being fluent in English ;O As per what is written in various posts in this thread I were lead to believe that I'd be in for; First test images and then not coming closer to what the issue were then switch from kms to fkms ... oh well

tilfaeldig commented 1 year ago

test(s) done now

I've used the 2022-09-22 Bullseye 32bit & 64bit images Both images act identically ! :)

pelwell commented 1 year ago

sorry for not being fluent in English ;O

No, I'm sorry - thanks for the reminder.

popcornmix commented 1 year ago

Switching to fkms is a work-around Pulling the power plug to the screen and turning power back on works

Okay, this is reasonably convincing that your issue could be fixed by https://github.com/raspberrypi/linux/pull/5317

It is also likely that running latest rpi-update firmware and adding to config.txt

hdmi_ignore_hotplug:0=1
hdmi_ignore_hotplug:1=1

will work around the problem (by preventing the firmware from setting up HDMI).

There will be a proper fix based on the linked PR once further testing has been done.

tilfaeldig commented 1 year ago

No, I'm sorry - thanks for the reminder.

:)

I guess I'm a wee frustrated about all this by now I see it as obviously being about kms from what is responded to me in this thread & what I've read elsewhere (and on top of that there's some USB thingie now with my Raspi so I have to unplug/plug the keyboard all the time)

tilfaeldig commented 1 year ago

There will be a proper fix based on the linked PR once further testing has been done.

As per my 2nd post in this thread; I'd like to await the real fix

popcornmix commented 1 year ago

You may wait for the update. It may fix your issue. It will likely appear in rpi-update in next week or two. It will take longer for an apt release.

If you choose, you can follow my previous suggestion which, assuming it works will provide more evidence your issue is the same as the one the PR targets. That will also provide a workaround for your issue until the fix is released.

tilfaeldig commented 1 year ago

You may wait for the update. It may fix your issue. It will likely appear in rpi-update in next week or two. It will take longer for an apt release.

Longer = within a few months ! :)))))

If you choose, you can follow my previous suggestion which, assuming it works will provide more evidence your issue is the same as the one the PR targets. That will also provide a workaround for your issue until the fix is released.

With my system 'untouched' (no rpi-update)

I have back in January 2022 tried out various work-around suggestions to modifying »config.txt« but stopped because some »apt« updates kept changing my changes in »config.txt«

popcornmix commented 1 year ago

With my system 'untouched' (no rpi-update)

The instructions were to run rpi-update first. That's because there are known problems with using hdmi_ignore_hotplug without the update.

tilfaeldig commented 1 year ago

The instructions were to run rpi-update first. That's because there are known problems with using hdmi_ignore_hotplug without the update.

oh well ... so far I've experienced none ;O ... and it's much 'easier' to revert a line in »config.txt« than a rpi-update ? ;)

Would be nice if what I did could 'just' be taken in as information to add to the case - I think

tilfaeldig commented 1 year ago

Upgrading to the 20230306 kernel update is not a fix - is it supposed to be that ?

popcornmix commented 1 year ago

It contains a fix for displays that remain blank when they don't see a AVMUTE clear packet (as described here).

I said:

I suspect your issue may be fixed by https://github.com/raspberrypi/linux/pull/5317, but only if a few experiments have certain values. One of which is if a switch from kms to fkms avoids the issue.

but you seemed reluctant to run the experiments that would help narrow it down, so it was never clear whether your issue was the same.

tilfaeldig commented 1 year ago

It contains a fix for displays that remain blank when they don't see a AVMUTE clear packet (as described here).

And I just said;

Upgrading to the 20230306 kernel update is not a fix

[that is working (on my sys)]

:)

I said:

I suspect your issue may be fixed by raspberrypi/linux#5317, but only if a few experiments have certain values. One of which is if a switch from kms to fkms avoids the issue.

but you seemed reluctant to run the experiments that would help narrow it down, so it was never clear whether your issue was the same.

And you seem 'reluctant' to read what I write & have written ! :)))))

I VERY much DO appreciate you and anyone else helping & working on loads of stuff BUT as often as I read 'complains' about users not searching/reading etc. thoroughly before 'asking' for other peoples time I feel like this thread shows it sometimes is a 2 way street ? :)))))

What experiments have I 'failed' to read I'm asked (and reluctant) to do ? (I've re-read the entire thread just now and I cant find I've 'missed' any requests)

I'm VERY keen on helping to solve this issue ! - but please be ... better ? at asking/guiding what will be the next step

THX in advance for all your time & help ! :)

Addendum So the 20230317-1 kernel seems to fix the 'issue' (it would have been really dandy if someone would have said that !) though the login box is exchanged for black (instead of the missing part of the desktop pattern where the login window were) after one hits enter to login before the login actually happens ...