1.) I can't access this facebook based page. I do not have a FB account,
can't even read the info... due FB or my tracking protection. So I don't
know if my other problem is adressed there. Possible to find a solution
without FB? That really sucks!
2.) I use bluestar since several years on an old Intel Atom and it
needed to switch to the correct LVDS lane for screen output to the HDMI
Port... (the motherbord also has an internal LVDS connector) bluestar
was one of the distros which did it correct right away... since the last
update I did, after the bios splash screen, my display loses the signal
(I can login to the desktop - I see it in the ssh session while
monitoring the processes...). So I guess bluestar stoped selecting the
correct LVDS lane. How to restore it?
Thanks
--
Unterschrift
Mit freundlichem Gruß
With best regards
Danny
So, I'm guessing some update, probably an updated kernel driver, changed
the display device or how it's chosen. I haven't changed anything
related to display choice in a looong time. LVDS can be specified via
your grub config (kernel command line), and you can change it easily if
you can log in via ssh. The addition to the command line is "
video=LVDS-N:c", where N is the display number (0 or 1 usually) and 'c'
is the command - 'd' for disable, 'e' for enable. So, to enable LVDS-0,
you would add 'video=LVDS-0:e'. to disable LVDS-1, you would add
'video=LVDS-1:d' The file to change is /etc/default/grub (find the
kernel command line at the top), insert the LVDS setting or modify the
existing one, then run grub-mkconfig -o /boot/grub/grub.cfg. It would
help to know what's in your current /etc/default/grub file at the
moment. Also, run xrandr and send me the output.
1.) I can't access this facebook based page. I do not have a FB account,
can't even read the info... due FB or my tracking protection. So I don't
know if my other problem is adressed there. Possible to find a solution
without FB? That really sucks!
2.) I use bluestar since several years on an old Intel Atom and it
needed to switch to the correct LVDS lane for screen output to the HDMI
Port... (the motherbord also has an internal LVDS connector) bluestar
was one of the distros which did it correct right away... since the last
update I did, after the bios splash screen, my display loses the signal
(I can login to the desktop - I see it in the ssh session while
monitoring the processes...). So I guess bluestar stoped selecting the
correct LVDS lane. How to restore it?
Thanks
--
Unterschrift
Mit freundlichem Gruß
With best regards
Danny
checked and reinstalled the uvesafb from bluestar/uvesafb-dkms
[danny@littleatom]:~$trizen-Ssuvesafbbluestar/uvesafb-dkms1.0.4-1[Installiert]uvesafbdkmsdriverandv86duserspacehelperforuvesafbthatrunsx86codeinanemulatedenvironmentaur/uvesafb-dkms1.0.4-1[installed][10+][0.07%][2 Jan 2021]uvesafbdkmsdriverandv86duserspacehelperforuvesafbthatrunsx86codeinanemulatedenvironmentaur/v86d0.1.10-9[unmaintained][4+][0.28%][5 May 2020]userspacehelperforuvesafbthatrunsx86codeinanemulatedenvironment
But the system shows both as installed
bluestar/uvesafb-dkms
and
aur/uvesafb-dkms
... any further Ideas?
like better install aur/uvesafb-dkms ?
Last edit: Danny Schneider 2021-10-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hi Danny. the issue may be the changes i had to make for 1.0.4. a little over a year ago the arch64 folks removed an option from the kernel config file that provided the video buffer modes used by uvesafb. i opened a bug report to have them restored, but at the time i received no response. in fact, it took about 9 months before they finally fixed it. meanwhile, i had to cut the vb modes from the older kernel source code and paste it into the uvesafb-dkms code base so that it could continue to be used. i'm not certain that this is the issue, but i have a new 1.0.3 build of uvesafb-dkms that again uses the modes built into the kernel, now that the kernel config option has finally been restored. i've uploaded it to https://sourceforge.net/projects/bluestarlinux/files/extra/uvesafb-dkms-1.0.3-2-x86_64.pkg.tar.zst. could you give that one a try? it can be installed with 'pacman -U uvesafb-dkms-1.0.3-2-x86_64.pkg.tar.zst' once it's been downloaded. let me know if that fixes it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks, bud. there should be a uvesafb.0 directory there and, obviously, there's not. i checked out the signature checking and that appears to be a non-issue, so next i'll take a look at the code itself. i have a little atom netbook like yours that i haven't turned on for a while - the fan's messed up - but i'll see if it also fails and if so, if it leaves more to find in the logs.
Last edit: Jeff Hodd 2021-10-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
not so good news on my testing, Danny. mine loaded without any problems on a D2500 netbook (same gma3600 graphics hardware). that message is basically telling you that something else in your system has already reserved those particular I/O ports (0x3c0-0x3e0) - i'm assuming another graphics driver. could you run 'lsmod' on your system and let me know what's returned?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yeah, i've known all about the gma500_gfx driver pretty much since its inception. it should be there. hypothetically, we should be able to use only that graphics driver, and in fact it kinda worked for a long time, but its vsync was dodgy when used with the D2xxx atom processors. it is linux's official gma3600 driver. unfortunately, it seems to have stopped working completely now. i used to be able to boot up the live system from the generic boot entry (with dodgy vsync), but now i just get a blank screen. i thought i might do a little more tinkering with the linux command line to see if i can;t get it working again. i know there have been updates to the driver as recently as this past september (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/gpu/drm/gma500?h=v5.14.15). i have to assume that the goal of updating the driver is to make it work better, not worse.
in any case, note that the gma500 driver uses an I/O port range starting at 20d0, whereas the uvesa frame buffer driver (uvesafb) wants access starting at 3c0. they shouldn't be interfering with each other.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
what i was saying was that one used to be able to boot up generically and the system's graphics would load and use the gma500 module although the vsync was wobbly. now you can;t do that anymore. you get a blank screen if you try it that way now. 2 different issues. i plan on trying a couple of different things to see if i can use the gma500 modules from boot, but i need a fresh installation, which i don;t have. yet. the gma500_gfx module is still needed. the one thing i pointed out clearly was that gma500_gfx and uvesafb use completely different I/O ports so the gma500_gfx module was not what's interfering with the uvesafb module load.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the issue on your system is that something is grabbing that I/O port range (0x3c0=0x3e0) before the kernel gets to loading uvesafb. i don;t know what that might be. could be part of the core kernel. could be another kernel module. i know it's not happening on my d2500 system, so whatever it is, i'm not using whatever it is that's interfering with your uvesafb module. that means i can't replicate your error condition.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yeah. that's why i'm trying a different approach. i'd like to see if the latest version of gma500_gfx can be made to work now if configured correctly. that would be good for you and good for me. i'd prefer dropping support for uvesafb if the actual driver can be made to work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
GRUB_DEFAULT=0GRUB_TIMEOUT=5GRUB_DISTRIBUTOR="Bluestar"#GRUB_CMDLINE_LINUX_DEFAULT="quiet ipv6.disable=1 loglevel=3 logo.nologo console=tty1 splash=silent,fadein,fadeout,theme:bslx-splash i8042.reset i8042.nomux i8042.nopnp i8042.noloop video=LVDS-0:d enable_mtrr_cleanup"GRUB_CMDLINE_LINUX_DEFAULT="quiet loglevel=3 logo.nologo console=tty1 splash=silent,fadein,fadeout,theme:bslx-splash i8042.reset i8042.nomux i8042.nopnp i8042.noloop video=LVDS-0:d enable_mtrr_cleanup"GRUB_CMDLINE_LINUX=""# Preload both GPT and MBR modules so that they are not missedGRUB_PRELOAD_MODULES="part_gpt part_msdos"# Uncomment to enable Hidden Menu, and optionally hide the timeout count#GRUB_HIDDEN_TIMEOUT=5#GRUB_HIDDEN_TIMEOUT_QUIET=true# Uncomment to use basic consoleGRUB_TERMINAL_INPUT=console# Uncomment to disable graphical terminal#GRUB_TERMINAL_OUTPUT=console# The resolution used on graphical terminal# note that you can use only modes which your graphic card supports via VBE# you can see them in real GRUB with the command `vbeinfo'GRUB_GFXMODE=auto# Uncomment to allow the kernel use the same resolution used by grubGRUB_GFXPAYLOAD_LINUX=keep# Uncomment if you want GRUB to pass to the Linux kernel the old parameter# format "root=/dev/xxx" instead of "root=/dev/disk/by-uuid/xxx"#GRUB_DISABLE_LINUX_UUID=true# Uncomment to disable generation of recovery mode menu entriesGRUB_DISABLE_RECOVERY=true# Uncomment and set to the desired menu colors. Used by normal and wallpaper# modes only. Entries specified as foreground/background.#GRUB_COLOR_NORMAL="light-blue/black"#GRUB_COLOR_HIGHLIGHT="light-cyan/blue"# Uncomment one of them for the gfx desired, a image background or a gfxtheme#GRUB_BACKGROUND="/path/to/wallpaper"#GRUB_THEME="/path/to/gfxtheme"# Uncomment to get a beep at GRUB start#GRUB_INIT_TUNE="480 440 1"#GRUB_SAVEDEFAULT="true"
last modified 14 Jul 2016 :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks, bud. was just checking for the "video=LVDS-?:d" parameter so i'd know how to change your command line. man, you are running an old installation aren;t you.
i think i'd prefer to have you change it via the grub boot menu, though. that way we can test it and make it permanent afterwards.
the first thing to do is to edit your /etc/mkinitcpio.conf file and add gma500_gfx to the MODULES entry:
MODULES="gma500_gfx"
then run (as root) 'mkinitcpio -p linux'. that's easy enough to back out if we need to.
reboot and enter the letter 'e' when you get to the grub menu - you should have at least 5 seconds to do so. you'll then be in edit mode. scroll down to the command line - it's going to look exactly like the GRUB_CMDLINE_LINUX_DEFAULT string above. if you've never edited the command line before, be sure not to break up this line in any way.
before the 'video=...' parameter add these two parameters (just position your cursor and type it in):
disablehooks=v86d modprobe.blacklist=uvesafb
enter ctrl-X to 'save' it (it's not really saved, just not discarded), and let it boot up. your screen is likely to go black until the X server is started. if you use sddm, you'll see the login screen; if not, it should boot straight into your desktop.
if that restores your desktop, we'll go to the next step where we remove the v86d hook and the uvesafb.conf file reference from mkinitcpio.conf and remove the uvesafb-dkms package from your system. you won;t have to change your /etc/default/grub config file.
if your desktop comes up with the wrong resolution, open systemsettings and go to Displays and Monitors and use the drop-down to set the correct resolution (i'm guessing 1024x600). you may have some work to do to restore the locations of any widgets on your desktop. the next time you boot, you'll have to use the desktop menu to 'Leave...' so that your changed settings are saved.
but we'll cross those bridges when we get there. meanwhile, get back to me on how the initial test goes.
the last piece i'm trying to solve is that black screen during boot up. i'd prefer it if that were visible but haven;t figured out how to get that to happen yet. i may have to hit up the forum to get to the developer. however, it could be specific to my system and maybe you'll have full visibility. please let me know that too. since you're still using fbsplash, you might see that instead of a black screen, btw.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
give me a day or two... currently I don't even get the bios splash screen nor the grub menue (which all worked like a week ago) . I want to exclude a hardware issue first... Maybe my littleatom is dying a slow death.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1.) I can't access this facebook based page. I do not have a FB account,
can't even read the info... due FB or my tracking protection. So I don't
know if my other problem is adressed there. Possible to find a solution
without FB? That really sucks!
2.) I use bluestar since several years on an old Intel Atom and it
needed to switch to the correct LVDS lane for screen output to the HDMI
Port... (the motherbord also has an internal LVDS connector) bluestar
was one of the distros which did it correct right away... since the last
update I did, after the bios splash screen, my display loses the signal
(I can login to the desktop - I see it in the ssh session while
monitoring the processes...). So I guess bluestar stoped selecting the
correct LVDS lane. How to restore it?
Thanks
--
Unterschrift
Mit freundlichem Gruß
With best regards
Danny
Hi Danny.
You can use this email address for support.
So, I'm guessing some update, probably an updated kernel driver, changed
the display device or how it's chosen. I haven't changed anything
related to display choice in a looong time. LVDS can be specified via
your grub config (kernel command line), and you can change it easily if
you can log in via ssh. The addition to the command line is "
video=LVDS-N:c", where N is the display number (0 or 1 usually) and 'c'
is the command - 'd' for disable, 'e' for enable. So, to enable LVDS-0,
you would add 'video=LVDS-0:e'. to disable LVDS-1, you would add
'video=LVDS-1:d' The file to change is /etc/default/grub (find the
kernel command line at the top), insert the LVDS setting or modify the
existing one, then run grub-mkconfig -o /boot/grub/grub.cfg. It would
help to know what's in your current /etc/default/grub file at the
moment. Also, run xrandr and send me the output.
Also, you could try booting up with the latest image which you can find
here - https://sourceforge.net/projects/bluestarlinux/files/distro/
https://sourceforge.net/projects/bluestarlinux/files/distro/.
Let me know anything you think might be helpful.
Cheers
Jeff
On 10/13/21 15:23, Danny Schneider wrote:
Thx for the answer,
guess the Problem is not related with the LVDS line, but with this:
checked and reinstalled the uvesafb from bluestar/uvesafb-dkms
But the system shows both as installed
bluestar/uvesafb-dkms
and
aur/uvesafb-dkms
... any further Ideas?
like better install aur/uvesafb-dkms ?
Last edit: Danny Schneider 2021-10-29
... just build/installed aur/uvesafb-dkms
same result
hi Danny. the issue may be the changes i had to make for 1.0.4. a little over a year ago the arch64 folks removed an option from the kernel config file that provided the video buffer modes used by uvesafb. i opened a bug report to have them restored, but at the time i received no response. in fact, it took about 9 months before they finally fixed it. meanwhile, i had to cut the vb modes from the older kernel source code and paste it into the uvesafb-dkms code base so that it could continue to be used. i'm not certain that this is the issue, but i have a new 1.0.3 build of uvesafb-dkms that again uses the modes built into the kernel, now that the kernel config option has finally been restored. i've uploaded it to https://sourceforge.net/projects/bluestarlinux/files/extra/uvesafb-dkms-1.0.3-2-x86_64.pkg.tar.zst. could you give that one a try? it can be installed with 'pacman -U uvesafb-dkms-1.0.3-2-x86_64.pkg.tar.zst' once it's been downloaded. let me know if that fixes it.
Hello,
Sorry, no luck.
it produces the same messages in the syslog.
hey Danny. could you list /sys/bus/platform/drivers/uvesafb and let me know what's in there?
Of course. At your service!
thanks, bud. there should be a uvesafb.0 directory there and, obviously, there's not. i checked out the signature checking and that appears to be a non-issue, so next i'll take a look at the code itself. i have a little atom netbook like yours that i haven't turned on for a while - the fan's messed up - but i'll see if it also fails and if so, if it leaves more to find in the logs.
Last edit: Jeff Hodd 2021-10-31
If there is something to test, just drop me a note...
not so good news on my testing, Danny. mine loaded without any problems on a D2500 netbook (same gma3600 graphics hardware). that message is basically telling you that something else in your system has already reserved those particular I/O ports (0x3c0-0x3e0) - i'm assuming another graphics driver. could you run 'lsmod' on your system and let me know what's returned?
lspci -v
00:00.0 Host bridge: Intel Corporation Atom Processor D2xxx/N2xxx DRAM Controller (rev 03)
Subsystem: Intel Corporation Device 2014
Flags: bus master, fast devsel, latency 0
00:02.0 VGA compatible controller: Intel Corporation Atom Processor D2xxx/N2xxx Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
DeviceName: Intel(R) GMA 3600 Video Device
Subsystem: Intel Corporation Device 2014
Flags: bus master, fast devsel, latency 0, IRQ 28
Memory at d0100000 (32-bit, non-prefetchable) [size=1M]
I/O ports at 20d0 [size=8]
Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
Capabilities: <access denied="">
Kernel driver in use: gma500
Kernel modules: gma500_gfx</access>
yeah, i've known all about the gma500_gfx driver pretty much since its inception. it should be there. hypothetically, we should be able to use only that graphics driver, and in fact it kinda worked for a long time, but its vsync was dodgy when used with the D2xxx atom processors. it is linux's official gma3600 driver. unfortunately, it seems to have stopped working completely now. i used to be able to boot up the live system from the generic boot entry (with dodgy vsync), but now i just get a blank screen. i thought i might do a little more tinkering with the linux command line to see if i can;t get it working again. i know there have been updates to the driver as recently as this past september (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/gpu/drm/gma500?h=v5.14.15). i have to assume that the goal of updating the driver is to make it work better, not worse.
in any case, note that the gma500 driver uses an I/O port range starting at 20d0, whereas the uvesa frame buffer driver (uvesafb) wants access starting at 3c0. they shouldn't be interfering with each other.
so preventing gma500_gfx module from loading should give me back the X Window?
no. you need the gma500_gfx module. here's my module listing:
what i was saying was that one used to be able to boot up generically and the system's graphics would load and use the gma500 module although the vsync was wobbly. now you can;t do that anymore. you get a blank screen if you try it that way now. 2 different issues. i plan on trying a couple of different things to see if i can use the gma500 modules from boot, but i need a fresh installation, which i don;t have. yet. the gma500_gfx module is still needed. the one thing i pointed out clearly was that gma500_gfx and uvesafb use completely different I/O ports so the gma500_gfx module was not what's interfering with the uvesafb module load.
the issue on your system is that something is grabbing that I/O port range (0x3c0=0x3e0) before the kernel gets to loading uvesafb. i don;t know what that might be. could be part of the core kernel. could be another kernel module. i know it's not happening on my d2500 system, so whatever it is, i'm not using whatever it is that's interfering with your uvesafb module. that means i can't replicate your error condition.
does not seem to be useful... (its mostly the same on my new ryzen2 system)
yeah. that's why i'm trying a different approach. i'd like to see if the latest version of gma500_gfx can be made to work now if configured correctly. that would be good for you and good for me. i'd prefer dropping support for uvesafb if the actual driver can be made to work.
well. good news. the gma500_gfx driver now works:
i'm working on some instructions for you.
ok, Danny. could you please send me your kernel command line from /etc/default/grub?
last modified 14 Jul 2016 :-)
thanks, bud. was just checking for the "video=LVDS-?:d" parameter so i'd know how to change your command line. man, you are running an old installation aren;t you.
i think i'd prefer to have you change it via the grub boot menu, though. that way we can test it and make it permanent afterwards.
the first thing to do is to edit your /etc/mkinitcpio.conf file and add gma500_gfx to the MODULES entry:
MODULES="gma500_gfx"
then run (as root) 'mkinitcpio -p linux'. that's easy enough to back out if we need to.
reboot and enter the letter 'e' when you get to the grub menu - you should have at least 5 seconds to do so. you'll then be in edit mode. scroll down to the command line - it's going to look exactly like the GRUB_CMDLINE_LINUX_DEFAULT string above. if you've never edited the command line before, be sure not to break up this line in any way.
before the 'video=...' parameter add these two parameters (just position your cursor and type it in):
disablehooks=v86d modprobe.blacklist=uvesafb
enter ctrl-X to 'save' it (it's not really saved, just not discarded), and let it boot up. your screen is likely to go black until the X server is started. if you use sddm, you'll see the login screen; if not, it should boot straight into your desktop.
if that restores your desktop, we'll go to the next step where we remove the v86d hook and the uvesafb.conf file reference from mkinitcpio.conf and remove the uvesafb-dkms package from your system. you won;t have to change your /etc/default/grub config file.
if your desktop comes up with the wrong resolution, open systemsettings and go to Displays and Monitors and use the drop-down to set the correct resolution (i'm guessing 1024x600). you may have some work to do to restore the locations of any widgets on your desktop. the next time you boot, you'll have to use the desktop menu to 'Leave...' so that your changed settings are saved.
but we'll cross those bridges when we get there. meanwhile, get back to me on how the initial test goes.
the last piece i'm trying to solve is that black screen during boot up. i'd prefer it if that were visible but haven;t figured out how to get that to happen yet. i may have to hit up the forum to get to the developer. however, it could be specific to my system and maybe you'll have full visibility. please let me know that too. since you're still using fbsplash, you might see that instead of a black screen, btw.
give me a day or two... currently I don't even get the bios splash screen nor the grub menue (which all worked like a week ago) . I want to exclude a hardware issue first... Maybe my littleatom is dying a slow death.
np, Danny. whenever you can get to it is fine.