slarm64 This forum is for the discussion of slarm64. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
|
05-16-2022, 01:25 AM
|
#16
|
Senior Member
Registered: Aug 2014
Posts: 2,123
Original Poster
Rep: 
|
|
|
1 members found this post helpful.
|
06-26-2022, 01:58 AM
|
#17
|
Senior Member
Registered: Aug 2014
Posts: 2,123
Original Poster
Rep: 
|
|
|
1 members found this post helpful.
|
06-27-2022, 02:28 PM
|
#18
|
Senior Member
Registered: Aug 2014
Posts: 2,123
Original Poster
Rep: 
|
|
|
1 members found this post helpful.
|
07-08-2022, 02:46 PM
|
#19
|
Senior Member
Registered: Aug 2014
Posts: 2,123
Original Poster
Rep: 
|
|
|
1 members found this post helpful.
|
07-16-2022, 09:19 PM
|
#20
|
Member
Registered: Mar 2019
Distribution: Slackware
Posts: 302
Rep: 
|
latest xorg updates kinda break display on both legacy and next
This one has me scratching my head. I run a Quartz64-A legacy image daily. When I installed the latest batch of xorg updates (on 15.0, not current), my default screen resolution dropped from 1920x1080 down to 1200x1080. I know it was the xorg updates because everything was working like normal before those, and I updated nothing else.
I checked a freshly-built quartz64-a next image, and it boots up just fine. However, if you run the updates and let the xorg updates install, then on reboot, X does not start at all, regardless of the resolution.
I am going to try some older images to isolate if any specific kernels, u-boot versions, or ATF blobs change anything. I just wanted to give you a heads up on this one because you can probably check it yourself (just update any xfce image for the quartz-a and see if X behaves any differently afterwards).
I checked other machines, and the Pinebook seems to be affected also. X starts but then is completely blank, no output at all. None of my x86 machines are acting like this, so it seems slarm64 or aarch64 specific maybe? I can also test my Rock64.
Or maybe this is just me? I only have one monitor to test, sadly. If anyone notices anything similar with the xorg updates on any quartz64 images, I would love to hear about it. Thanks.
Last edited by shelldweller; 07-16-2022 at 11:36 PM.
Reason: updated info for Pinebook and 15.0 branch
|
|
|
07-17-2022, 03:10 AM
|
#21
|
Senior Member
Registered: Aug 2014
Posts: 2,123
Original Poster
Rep: 
|
let's see dmesg and Xorg.0.log
|
|
1 members found this post helpful.
|
07-17-2022, 08:34 AM
|
#22
|
Senior Member
Registered: Aug 2014
Posts: 2,123
Original Poster
Rep: 
|
|
|
1 members found this post helpful.
|
07-17-2022, 08:42 AM
|
#23
|
Senior Member
Registered: Aug 2014
Posts: 2,123
Original Poster
Rep: 
|
Quote:
Originally Posted by shelldweller
This one has me scratching my head. I run a Quartz64-A legacy image daily. When I installed the latest batch of xorg updates (on 15.0, not current), my default screen resolution dropped from 1920x1080 down to 1200x1080. I know it was the xorg updates because everything was working like normal before those, and I updated nothing else.
I checked a freshly-built quartz64-a next image, and it boots up just fine. However, if you run the updates and let the xorg updates install, then on reboot, X does not start at all, regardless of the resolution.
I am going to try some older images to isolate if any specific kernels, u-boot versions, or ATF blobs change anything. I just wanted to give you a heads up on this one because you can probably check it yourself (just update any xfce image for the quartz-a and see if X behaves any differently afterwards).
I checked other machines, and the Pinebook seems to be affected also. X starts but then is completely blank, no output at all. None of my x86 machines are acting like this, so it seems slarm64 or aarch64 specific maybe? I can also test my Rock64.
Or maybe this is just me? I only have one monitor to test, sadly. If anyone notices anything similar with the xorg updates on any quartz64 images, I would love to hear about it. Thanks.
|
i built a new image kernel-5.19.0-rc6 with the latest xorg:
Code:
xorg-server-1.20.14-aarch64-4
xorg-server-xephyr-1.20.14-aarch64-4
xorg-server-xnest-1.20.14-aarch64-4
xorg-server-xvfb-1.20.14-aarch64-4
xorg works:
Last edited by sndwvs; 07-17-2022 at 08:48 AM.
|
|
1 members found this post helpful.
|
07-18-2022, 10:09 PM
|
#24
|
Member
Registered: Mar 2019
Distribution: Slackware
Posts: 302
Rep: 
|
Quote:
Originally Posted by sndwvs
i built a new image kernel-5.19.0-rc6 with the latest xorg:
Code:
xorg-server-1.20.14-aarch64-4
xorg-server-xephyr-1.20.14-aarch64-4
xorg-server-xnest-1.20.14-aarch64-4
xorg-server-xvfb-1.20.14-aarch64-4
xorg works:
|
I have been able to isolate this to the stable 15.0 branch. The problem is present on Rock64, Pinebook, and Quartz64 (legacy and next), only as long as I am on the stable branch. Checking the current branch, I see the problem is not there. So this has something to do with the stable xorg updates.
I will try to generate some logs. I can say for sure on the Pinebook the error message is "no display found". Stay tuned for more info. I was busy testing my other boards to try to isolate the issue.
|
|
|
07-19-2022, 10:10 AM
|
#25
|
Member
Registered: Mar 2019
Distribution: Slackware
Posts: 302
Rep: 
|
Quote:
Originally Posted by sndwvs
let's see dmesg and Xorg.0.log
|
I know I should always generate logs before I even report here. In any case, here are the relevant logs for a recent Quartz64-A next image on the 15.0 stable branch:
https://slarmboards.3space.xyz/quartz64/logs/
Xorg.0.log, dmesg, and also Xorg.1.log are there as text files, renamed for the board and kernel branch.
I will generate more logs as I have time.
|
|
|
07-19-2022, 11:05 AM
|
#26
|
Senior Member
Registered: Aug 2014
Posts: 2,123
Original Poster
Rep: 
|
Quote:
Originally Posted by shelldweller
I know I should always generate logs before I even report here. In any case, here are the relevant logs for a recent Quartz64-A next image on the 15.0 stable branch:
https://slarmboards.3space.xyz/quartz64/logs/
Xorg.0.log, dmesg, and also Xorg.1.log are there as text files, renamed for the board and kernel branch.
I will generate more logs as I have time.
|
Thanks for the logs.
it is not immediately clear why lib instead of lib64 (clearly, in 15.0 it is)
error in this: modesetting_drv.so: undefined symbol: shadowRemove
Code:
[ 656.768] (II) LoadModule: "modesetting"
[ 656.769] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[ 656.769] (EE) Failed to load /usr/lib/xorg/modules/drivers/modesetting_drv.so: /usr/lib/xorg/modules/drivers/modesetting_drv.so: undefined symbol: shadowRemove
[ 656.769] (EE) Failed to load module "modesetting" (loader failed, 0)
[ 656.769] (II) LoadModule: "fbdev"
Last edited by sndwvs; 07-19-2022 at 11:08 AM.
|
|
1 members found this post helpful.
|
07-19-2022, 12:23 PM
|
#27
|
Member
Registered: Mar 2019
Distribution: Slackware
Posts: 302
Rep: 
|
Quote:
Originally Posted by sndwvs
Thanks for the logs.
it is not immediately clear why lib instead of lib64 (clearly, in 15.0 it is)
error in this: modesetting_drv.so: undefined symbol: shadowRemove
Code:
[ 656.768] (II) LoadModule: "modesetting"
[ 656.769] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[ 656.769] (EE) Failed to load /usr/lib/xorg/modules/drivers/modesetting_drv.so: /usr/lib/xorg/modules/drivers/modesetting_drv.so: undefined symbol: shadowRemove
[ 656.769] (EE) Failed to load module "modesetting" (loader failed, 0)
[ 656.769] (II) LoadModule: "fbdev"
|
Good catch. Yeah I saw that too, but I was not sure what to make of it. Looking around the 'net, I found this thread:
https://forums.gentoo.org/viewtopic-...8-start-0.html
They mention the same problem and a fix. I tried the fix on a Rock64 that was behaving exactly the same as the Quartz64. I added a Modules section to /etc/X11/xorg.conf.d/10-monitor.conf. I put in the same modules that were used in the other thread. Upon booting, X seems to start fine now, but I have no keyboard or mouse at all. Maybe I have to add these too? Or maybe I added the wrong modules. In any case, X starts now, which is interesting. I think if I can just figure out the right modules and the right order, this might correct the problem.
Thanks for the lead, that helped.
|
|
|
07-19-2022, 01:02 PM
|
#28
|
LQ Guru
Registered: Jan 2006
Location: Ireland
Distribution: Slackware, Slarm64 & Android
Posts: 17,262
|
For some mad reason I was compiling Mesa (version 18 or 19?) when it went over to some crazy build system. My first reaction was that some friend of the devs must have cobbled it up, and bought the drinks  .
Alien Bob promptly did a build script for it, which tied every single detail and didn't allow it to do any thinking at all. If you guys building the OS asked him nicely, I'm sure you'd get a copy. I did, many years ago.
Last edited by business_kid; 07-19-2022 at 01:04 PM.
|
|
|
07-19-2022, 01:20 PM
|
#29
|
Senior Member
Registered: Aug 2014
Posts: 2,123
Original Poster
Rep: 
|
the solution is simple, when building in patches, all flags were applied, and deleting flags CFLAGS -fno-plt, CXXFLAGS -fno-plt, LDFLAGS -z,now solves this problem.
packages updated.
|
|
1 members found this post helpful.
|
07-19-2022, 07:00 PM
|
#30
|
Member
Registered: Mar 2019
Distribution: Slackware
Posts: 302
Rep: 
|
Quote:
Originally Posted by sndwvs
the solution is simple, when building in patches, all flags were applied, and deleting flags CFLAGS -fno-plt, CXXFLAGS -fno-plt, LDFLAGS -z,now solves this problem.
packages updated.
|
Yes, that did the trick, problem solved here. Thank you!
|
|
|
All times are GMT -5. The time now is 04:13 PM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|