Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #211553 > unrolled thread

Re: Psychedelic GUI after stable update to buster

Back to article view | Back to linux.debian.user

Contents

  Re: Psychedelic GUI after stable update to buster hobie@rumormillnews.com - 2019-07-19 22:30 +0200
    Re: Psychedelic GUI after stable update to buster Étienne Mollier <etienne.mollier@mailoo.org> - 2019-07-20 00:20 +0200
      Re: Psychedelic GUI after stable update to buster hobie@rumormillnews.com - 2019-07-20 02:10 +0200
        Re: [SPAM] Re: Psychedelic GUI after stable update to buster Étienne Mollier <etienne.mollier@mailoo.org> - 2019-07-20 10:10 +0200
          Re: Psychedelic GUI after stable update to buster hobie@rumormillnews.com - 2019-07-21 22:10 +0200
            Re: Psychedelic GUI after stable update to buster Étienne Mollier <etienne.mollier@mailoo.org> - 2019-07-21 22:20 +0200
            Re: Psychedelic GUI after stable update to buster Felix Miata <mrmazda@earthlink.net> - 2019-07-22 00:10 +0200
              Re: Psychedelic GUI after stable update to buster Curt <curty@free.fr> - 2019-07-22 09:40 +0200

#211553 — Re: Psychedelic GUI after stable update to buster

> hobie, on 2019-07-17:
>> I did the edit you suggested - changing the *.si to *.cik on that
second
>> readeon reference - but can't tell if anything was affected by it.
Psychedelic colors still return on leaving the desktop and coming back
to
>> it, and output of inxi -Gxxxz also appears the same:
>> Graphics:
>>   Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK
>>   driver: N/A bus ID: 00:01.0 chip ID: 1002:130f
>>   Display: x11 server: X.Org 1.20.4 driver: ati,vesa
>>   unloaded: fbdev,modesetting,radeon resolution: 1600x900~N/A
>>   OpenGL: renderer: llvmpipe (LLVM 7.0 128 bits)
>>   v: 3.3 Mesa 18.3.6 compat-v: 3.1 direct render: Yes
>> Also, I've moved all files from /etc/modprobe.d to a backup directory;
their absence does not appear to have made any difference, either.
> Good Day,
> It seems that some more information is needed to have a clue
> about what is going on with that driver loading.  Would it be
> possible to run the following commands and publish the result?
> 	$ dpkg -l | grep -iE 'amd-graphics|amdgpu|\<ati\>|fglrx|radeon' $ sudo
dmesg | grep -iE 'amd-graphics|amdgpu|\<ati\>|fglrx|radeon'

Thanks, Etienne. :)  Here's the output:

dpkg -l | grep -iE 'amd-graphics|amdgpu|\<ati\>|fglrx|radeon'
ii  firmware-amd-graphics                                       20190114-1
                                 all          Binary firmware for AMD/ATI
graphics chips
ii  libdrm-amdgpu1:amd64                                        2.4.97-1
                                 amd64        Userspace interface to
amdgpu-specific kernel DRM services -- runtime
ii  libdrm-radeon1:amd64                                        2.4.97-1
                                 amd64        Userspace interface to
radeon-specific kernel DRM services -- runtime
ii  radeontop                                                   1.1-2
                                 amd64        Utility to show Radeon GPU
utilization
ii  xserver-xorg-video-amdgpu
18.1.99+git20190207-1                       amd64        X.Org X server --
AMDGPU display driver
ii  xserver-xorg-video-ati                                      1:19.0.1-1
                                 amd64        X.Org X server -- AMD/ATI
display driver wrapper
ii  xserver-xorg-video-mach64                                   6.9.6-1
                                 amd64        X.Org X server -- ATI Mach64
display driver
ii  xserver-xorg-video-r128                                     6.12.0-1
                                 amd64        X.Org X server -- ATI r128
display driver
ii  xserver-xorg-video-radeon                                   1:19.0.1-1
                                 amd64        X.Org X server -- AMD/ATI
Radeon display driver

- - -

dmesg | grep -iE 'amd-graphics|amdgpu|\<ati\>|fglrx|radeon'
[    0.340065] smpboot: CPU0: AMD A10-7860K Radeon R7, 12 Compute Cores
4C+8G (family: 0x15, model: 0x38, stepping: 0x1)
[    1.927704] [drm] VGACON disable radeon kernel modesetting.
[    1.927756] [drm:radeon_init [radeon]] *ERROR* No UMS support in radeon
module!
[    2.085794] [drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables amdgpu
kernel modesetting.
[   10.423460] [drm] VGACON disable radeon kernel modesetting.
[   10.423512] [drm:radeon_init [radeon]] *ERROR* No UMS support in radeon
module!
[   10.859252] [drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables amdgpu
kernel modesetting.

[toc] | [next] | [standalone]

#211556

[Multipart message — attachments visible in raw view] — view raw

Hi,

hobie, on 2019-07-19 :
> dpkg -l | grep -iE 'amd-graphics|amdgpu|\<ati\>|fglrx|radeon'
> ii  firmware-amd-graphics     [...]
> ii  libdrm-amdgpu1:amd64      [...]
> ii  libdrm-radeon1:amd64      [...]
> ii  radeontop                 [...]
> ii  xserver-xorg-video-amdgpu [...]
> ii  xserver-xorg-video-ati    [...]
> ii  xserver-xorg-video-mach64 [...]
> ii  xserver-xorg-video-r128   [...]
> ii  xserver-xorg-video-radeon [...]

Well, there seem to be everything we need here, even a bit more.

> dmesg | grep -iE 'amd-graphics|amdgpu|\<ati\>|fglrx|radeon'
> [    0.340065] smpboot: CPU0: AMD A10-7860K Radeon R7, 12 Compute Cores 4C+8G (family: 0x15, model: 0x38, stepping: 0x1)
> [    1.927704] [drm] VGACON disable radeon kernel modesetting.
> [    1.927756] [drm:radeon_init [radeon]] *ERROR* No UMS support in radeon module!
> [    2.085794] [drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables amdgpu kernel modesetting.
> [   10.423460] [drm] VGACON disable radeon kernel modesetting.
> [   10.423512] [drm:radeon_init [radeon]] *ERROR* No UMS support in radeon module!
> [   10.859252] [drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables amdgpu kernel modesetting.

Now, this is interesting!  While browsing the web independently
on the two error messages "VGACON disables amdgpu kernel
modesetting" and "No UMS support in radeon module!", in both
case the culprit was seemingly Kernel ModeSetting (KMS) being
disabled :

	https://unix.stackexchange.com/questions/273471/how-to-solve-drmradeon-init-radeon-error-no-ums-support-in-radeon-module
	https://bbs.archlinux.org/viewtopic.php?id=166037
	https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/884333-vgacon-disables-amdgpu-kernel-modesetting

This confirms the statement from Alexander V. Makartsev:
> Kernel mode setting (modeset) is often required to be enabled
> with recent kernels. "-1" usually means "auto".

It looks to me that you still have something somewhere, perhaps
not in /etc/modprobe.d since you cleaned that directory up, but
maybe lurking in some place else, maybe like /etc/default/grub,
which might still disable KMS.  Which command line is currently
applied ?

	$ cat /proc/cmdline

Are there particular settings applied to Grub, in case it
affects boot environment?

	$ cat /etc/default/grub

I suppose that once the question of KMS is cleared, it will be
possible to go further with other good advices given previously.

Kind Regards,
-- 
Étienne Mollier <etienne.mollier@mailoo.org>
               5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D

PS: please, reply to the list, not myself with the list in copy,
    I had to glue the debian-user address, but am not sure it
    will be properly followed up in the archive:

	https://lists.debian.org/debian-user/2019/07/thrd2.html

[toc] | [prev] | [next] | [standalone]

#211559

> Hi,
>
> hobie, on 2019-07-19 :
>> dpkg -l | grep -iE 'amd-graphics|amdgpu|\<ati\>|fglrx|radeon'
>> ii  firmware-amd-graphics     [...]
>> ii  libdrm-amdgpu1:amd64      [...]
>> ii  libdrm-radeon1:amd64      [...]
>> ii  radeontop                 [...]
>> ii  xserver-xorg-video-amdgpu [...]
>> ii  xserver-xorg-video-ati    [...]
>> ii  xserver-xorg-video-mach64 [...]
>> ii  xserver-xorg-video-r128   [...]
>> ii  xserver-xorg-video-radeon [...]
>
> Well, there seem to be everything we need here, even a bit more.
>
>> dmesg | grep -iE 'amd-graphics|amdgpu|\<ati\>|fglrx|radeon'
>> [    0.340065] smpboot: CPU0: AMD A10-7860K Radeon R7, 12 Compute Cores
>> 4C+8G (family: 0x15, model: 0x38, stepping: 0x1)
>> [    1.927704] [drm] VGACON disable radeon kernel modesetting.
>> [    1.927756] [drm:radeon_init [radeon]] *ERROR* No UMS support in
>> radeon module!
>> [    2.085794] [drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables amdgpu
>> kernel modesetting.
>> [   10.423460] [drm] VGACON disable radeon kernel modesetting.
>> [   10.423512] [drm:radeon_init [radeon]] *ERROR* No UMS support in
>> radeon module!
>> [   10.859252] [drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables amdgpu
>> kernel modesetting.
>
> Now, this is interesting!  While browsing the web independently
> on the two error messages "VGACON disables amdgpu kernel
> modesetting" and "No UMS support in radeon module!", in both
> case the culprit was seemingly Kernel ModeSetting (KMS) being
> disabled :
>
> 	https://unix.stackexchange.com/questions/273471/how-to-solve-drmradeon-init-radeon-error-no-ums-support-in-radeon-module
> 	https://bbs.archlinux.org/viewtopic.php?id=166037
> 	https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/884333-vgacon-disables-amdgpu-kernel-modesetting
>
> This confirms the statement from Alexander V. Makartsev:
>> Kernel mode setting (modeset) is often required to be enabled
>> with recent kernels. "-1" usually means "auto".
>
> It looks to me that you still have something somewhere, perhaps
> not in /etc/modprobe.d since you cleaned that directory up, but
> maybe lurking in some place else, maybe like /etc/default/grub,
> which might still disable KMS.  Which command line is currently
> applied ?
>
> 	$ cat /proc/cmdline
>
> Are there particular settings applied to Grub, in case it
> affects boot environment?
>
> 	$ cat /etc/default/grub
>
> I suppose that once the question of KMS is cleared, it will be
> possible to go further with other good advices given previously.

Thanks. :)  I have a faint memory of inserting 'nomodeset' long years ago
in the interest of keeping my console screen at 80x25.

cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64
root=UUID=c378147d-1aca-4d98-a589-6b47f02e0ef7 ro nomodeset reboot=pci
quiet


Contents of /etc/default/grub:

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX="nomodeset reboot=pci"

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
GRUB_TERMINAL=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=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

--hobie

[toc] | [prev] | [next] | [standalone]

#211562 — Re: [SPAM] Re: Psychedelic GUI after stable update to buster

[Multipart message — attachments visible in raw view] — view raw

hobie, on 2019-07-20 :
> Thanks. :)  I have a faint memory of inserting 'nomodeset' long years ago
> in the interest of keeping my console screen at 80x25.
>
> cat /proc/cmdline
> BOOT_IMAGE=/boot/vmlinuz-[...] root=UUID=[...] ro nomodeset reboot=pci quiet
                                     There it is:   ^~~~~~~~~

I'm not sure about the "reboot=pci" but you might want to remove
"nomodeset" from your GRUB_CMDLINE_LINUX in /etc/default/grub,
then `sudo update-grub`.

Otherwise said, in details:

> Contents of /etc/default/grub:
>
> GRUB_DEFAULT=0
> GRUB_TIMEOUT=5
> GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
> GRUB_CMDLINE_LINUX_DEFAULT="quiet"
> GRUB_CMDLINE_LINUX="nomodeset reboot=pci"
Remove this:          ^~~~~~~~~~

[...]
> # 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=640x480
  ^~~~~~~~~~~~~~~~~~~~~
And you might also want to uncomment that and introduce the
variable GRUB_GFXPAYLOAD_LINUX=keep to keep your Linux console
down to 80×25 characters, so the paragraph would become:

	# 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=640x480
	GRUB_GFXPAYLOAD_LINUX=keep

Not every graphical driver take this properly in account, but it
should be okay with raedon and amdgpu.

Once this is done, run the following command, and while it runs,
you should see your various kernels being listed.  This will
update the command lines at boot time:

	$ sudo update-grub

See how things evolve after issuing a reboot.

Kind Regards,
-- 
Étienne Mollier <etienne.mollier@mailoo.org>
               5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D

[toc] | [prev] | [next] | [standalone]

#211614

> hobie, on 2019-07-20 :
>> Thanks. :)  I have a faint memory of inserting 'nomodeset' long years
>> ago
>> in the interest of keeping my console screen at 80x25.
>>
>> cat /proc/cmdline
>> BOOT_IMAGE=/boot/vmlinuz-[...] root=UUID=[...] ro nomodeset reboot=pci
>> quiet
>                                      There it is:   ^~~~~~~~~
>
> I'm not sure about the "reboot=pci" but you might want to remove
> "nomodeset" from your GRUB_CMDLINE_LINUX in /etc/default/grub,
> then `sudo update-grub`.
>
> Otherwise said, in details:
>
>> Contents of /etc/default/grub:
>>
>> GRUB_DEFAULT=0
>> GRUB_TIMEOUT=5
>> GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
>> GRUB_CMDLINE_LINUX_DEFAULT="quiet"
>> GRUB_CMDLINE_LINUX="nomodeset reboot=pci"
> Remove this:          ^~~~~~~~~~
>
> [...]
>> # 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=640x480
>   ^~~~~~~~~~~~~~~~~~~~~
> And you might also want to uncomment that and introduce the
> variable GRUB_GFXPAYLOAD_LINUX=keep to keep your Linux console
> down to 80×25 characters, so the paragraph would become:
>
> 	# 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=640x480
> 	GRUB_GFXPAYLOAD_LINUX=keep
>
> Not every graphical driver take this properly in account, but it
> should be okay with raedon and amdgpu.
>
> Once this is done, run the following command, and while it runs,
> you should see your various kernels being listed.  This will
> update the command lines at boot time:
>
> 	$ sudo update-grub
>
> See how things evolve after issuing a reboot.
>
> Kind Regards,
> --
> Étienne Mollier <etienne.mollier@mailoo.org>
>                5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D

Thanks. :)  Result: no observable change.  Thankfully, my console's still
at 80x25.  But the shift to psychedelic colors is still there, too.

What the heck is this all about...??

--hobie

[toc] | [prev] | [next] | [standalone]

#211615

[Multipart message — attachments visible in raw view] — view raw

On 21/07/2019 22.04, hobie@rumormillnews.com wrote:
> Thanks. :)  Result: no observable change.  Thankfully, my console's still
> at 80x25.  But the shift to psychedelic colors is still there, too.
> 
> What the heck is this all about...??

Greetings,

That is a good question.  What does your kernel tell you this
time?  (Use the command dmesg, and perhaps inxi if the driver
loads happily, to get this information hopefully.)

Kind Regards,
-- 
Étienne Mollier <etienne.mollier@mailoo.org>
               5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D

[toc] | [prev] | [next] | [standalone]

#211618

hobie@rumormillnews.com composed on 2019-07-21 16:04 (UTC-0400):

> Thanks. :)  Result: no observable change.  Thankfully, my console's still
> at 80x25.  But the shift to psychedelic colors is still there, too.

> What the heck is this all about...?? 

IME, problems with random screen colors typically indicates RAM trouble. If you
have more than one RAM module installed, try removing one at a time to see if it
makes any difference. AMD A10-7860K Radeon R7 seems to be an onboard graphics
configuration. Usually that means system RAM is used for video.

Maybe you should photograph your screen while it is doing this, so we can be sure
we understand your description.

inxi -Gxx output for your GCN 2nd gen Kaveri should be reporting:

	Display: x11 server: X.Org 1.20.4 driver: amdgpu (preferred)
or
	Display: x11 server: X.Org 1.20.4 driver: modesetting (fallback)

As yet I have not seen either reported in this thread, so if RAM is not the
problem, and neither is some other hardware failure, then virtually certainly not
using the amdgpu DDX or the modesetting DDX is. The ati DDX is for older AMD/ATI
hardware.

Asking the AMD experts via https://lists.x.org/mailman/listinfo/xorg-driver-ati
may be in order for solving this if RAM is not found to be an issue.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#211625

On 2019-07-21, Felix Miata <mrmazda@earthlink.net> wrote:
>
>> What the heck is this all about...?? 
>
> IME, problems with random screen colors typically indicates RAM trouble. If you
>

I had a CRT monitor once that died psychedelically.

So did Aldous Huxley. But I digress.

-- 
“We are all in the gutter, but some of us are looking at the stars.” 
― Oscar Wilde, Lady Windermere's Fan

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web