On 2020-12-26 18:44 -0500, The Wanderer wrote:
> On 2020-12-26 at 18:28, Felix Miata wrote:
>
>> I suggest a good place to start would be to goto /etc/default/grub
>> and switch from whichever mode is employed to the other, either plain
>> text to graphical, or vice versa, then regenerate grub.cfg
On Sb, 26 dec 20, 17:19:32, The Wanderer wrote:
>
> With the new GPU in place, I get video output during POST and in the
> BIOS (yes, this machine is old enough that it doesn't have a UEFI)
> without problems. That demonstrates that the GPU isn't dead on arrival,
> and that signal is getting throu
On Sat 26 Dec 2020 at 17:19:32 (-0500), The Wanderer wrote:
> I have for some years been running Debian with an older model of AMD GPU
> (Radeon HD 6870) for graphics.
>
> I recently purchased a relatively recent model of GPU (Radeon RX 5700
> XT), and today swapped it in and attempted to boot wit
Hello Rainer!
I assume bios just doesn't support some functions that kernel is
trying to query. You could try to update bios, if possible. But as
you say you don't see any real problems, maybe it's better not to fix
something that is working already. I get similar messages on boot
(Debian Buster),
On 2020-12-26 at 19:50, Tony Rowe wrote:
> On Sat, Dec 26, 2020 at 05:19:32PM -0500, The Wanderer wrote:
>
>> With the new GPU in place, I get video output during POST and in
>> the BIOS (yes, this machine is old enough that it doesn't have a
>> UEFI)
>
> Since you did not mention it (or anyone
On Sat, Dec 26, 2020 at 05:19:32PM -0500, The Wanderer wrote:
> With the new GPU in place, I get video output during POST and in the
> BIOS (yes, this machine is old enough that it doesn't have a UEFI)
Since you did not mention it (or anyone else, I think), did you
check that your bios version is
On 2020-12-26 at 19:49, Linux-Fan wrote:
> The Wanderer writes:
>
>> On 2020-12-26 at 18:50, Linux-Fan wrote:
>>> Curious, what machine does not do UEFI yet but still benefits
>>> from large GPUs such as the RX 5700?
>>
>> One I built from parts back when the 6870 was still in the sweet
>> spot
The Wanderer writes:
On 2020-12-26 at 18:50, Linux-Fan wrote:
> Georgi Naplatanov writes:
>
>> On 12/27/20 12:19 AM, The Wanderer wrote:
>> > I have for some years been running Debian with an older model of AMD GPU
>> > (Radeon HD 6870) for graphics.
>> >
>> > I recently purchased a relatively
Hi,
I have a Tuxedo Aura 15 and after installing Debian bullseye, I see during
boot a few
acpi bios error: could not resolve symbol
messages.
See https://nc.d5x.de/s/3BYL8Fg88Xb5GRJ for a "screenshot".
Does anybody understand what these messages want to tell me (so far I did not
see anything
The Wanderer composed on 2020-12-26 18:44 (UTC-0500):
> Felix Miata wrote:
>> I suggest a good place to start would be to goto /etc/default/grub
>> and switch from whichever mode is employed to the other, either plain
>> text to graphical, or vice versa, then regenerate grub.cfg and try
>> bootin
On 2020-12-26 at 18:50, Linux-Fan wrote:
> Georgi Naplatanov writes:
>
>> On 12/27/20 12:19 AM, The Wanderer wrote:
>> > I have for some years been running Debian with an older model of AMD GPU
>> > (Radeon HD 6870) for graphics.
>> >
>> > I recently purchased a relatively recent model of GPU (Ra
Georgi Naplatanov writes:
On 12/27/20 12:19 AM, The Wanderer wrote:
> I have for some years been running Debian with an older model of AMD GPU
> (Radeon HD 6870) for graphics.
>
> I recently purchased a relatively recent model of GPU (Radeon RX 5700
> XT), and today swapped it in and attempted t
On 2020-12-26 at 18:28, Felix Miata wrote:
> I suggest a good place to start would be to goto /etc/default/grub
> and switch from whichever mode is employed to the other, either plain
> text to graphical, or vice versa, then regenerate grub.cfg and try
> booting.
That's a good suggestion, except
The Wanderer composed on 2020-12-26 17:19 (UTC-0500):
...
I suggest a good place to start would be to goto /etc/default/grub and switch
from
whichever mode is employed to the other, either plain text to graphical, or vice
versa, then regenerate grub.cfg and try booting. While in /etc/default/grub,
On 2020-12-26 at 17:33, Georgi Naplatanov wrote:
> On 12/27/20 12:19 AM, The Wanderer wrote:
>
>> I have for some years been running Debian with an older model of AMD GPU
>> (Radeon HD 6870) for graphics.
>>
>> I recently purchased a relatively recent model of GPU (Radeon RX 5700
>> XT), and toda
On Mon, 21 Dec 2020 15:45:37 +
"Andrew M.A. Cater" wrote:
> >
> Well, that's a good start :) The test suite we used to test for
> stable release CDs is here:
> https://wiki.debian.org/Teams/DebianCD/ReleaseTesting/Buster_r7?highlight=%28testing%29%7C%28cd%29%7C%2810.7%29
First test subjec
On 12/27/20 12:19 AM, The Wanderer wrote:
> I have for some years been running Debian with an older model of AMD GPU
> (Radeon HD 6870) for graphics.
>
> I recently purchased a relatively recent model of GPU (Radeon RX 5700
> XT), and today swapped it in and attempted to boot with it.
>
> I was e
[ Beware: User of Core 2 Duo machines talking here. ]
> It might turn out to be pointless.
I strongly disagree here: it's by reporting such bugs that you can show
there is still interest in supporting such hardware.
> Users of older hardware, particularly Southern Islands and Sea Islands
> user
I have for some years been running Debian with an older model of AMD GPU
(Radeon HD 6870) for graphics.
I recently purchased a relatively recent model of GPU (Radeon RX 5700
XT), and today swapped it in and attempted to boot with it.
I was expecting to get no graphics support (e.g., X, et cetera)
Guyenne Tsui composed on 2020-12-26 21:37 (UTC):
> Felix Miata wrote:
>> I don't remember seeing that one before. Radeon Dynamic Power Management.
>> Nice you found it!
> Should I file a bug? I mean it may be a problem with dpm or a
> compatibility issue that users have to figure it out themsel
On 12/26/20 8:51 PM, Felix Miata wrote:
I don't remember seeing that one before. Radeon Dynamic Power Management.
Nice you found it!
Should I file a bug? I mean it may be a problem with dpm or a
compatibility issue that users have to figure it out themselves?
Guyenne Tsui composed on 2020-12-26 20:35 (UTC):
> #apt purge xserver-xorg-video-amdgpu xserver-xorg-video-ati:
...
> The following packages will be REMOVED:
>task-desktop* task-kde-desktop* xserver-xorg-video-all*
Those three are meta-packages, so nothing important would be lost.
> xserver
The issue only occurs with ditros based on Debian Testing, such as
Pop!_OS. This does not occur with my Debian Stable.
Anyway I solved the initial issue. Apparently, the boot parameter
`radeon.dpm=0` solved the initial issue. Apparently, on newer kernels
(testing) the boot parameter is automat
#apt purge xserver-xorg-video-amdgpu xserver-xorg-video-ati:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer
required:
apper apper-data espeak-ng-data fonts-symbola gir1.2-atspi-2.0
g
On Sat, Dec 26, 2020 at 04:05:50PM +, shadowma...@logorroici.org wrote:
> Hello everybody:
> I am new to this forum, but not to GNU/Linux. I am in a Windows 10 Machine
> with an AMD x64 architecture. I am unable to install from a distro image
> (firmware-10.7.0-amd64-netinst.iso) because loadli
Hello everybody:
I am new to this forum, but not to GNU/Linux. I am in a Windows 10
Machine with an AMD x64 architecture. I am unable to install from a
distro image (firmware-10.7.0-amd64-netinst.iso) because loadlin.exe is
not working anymore in my OS. I want to dual boot the computer, but I a
On Sb, 26 dec 20, 11:38:30, to...@tuxteam.de wrote:
>
> This is not 100% clear. For one, some terminal emulators do have escape
> sequences to change "cursor style" on the fly (xterm [1], among others),
> so a terminal-based application /could/ try to make use of that,
(Neo)Vim can take advantag
On Fri, Dec 25, 2020 at 08:46:02PM -0500, Bob Bernstein wrote:
> On Fri, 25 Dec 2020, to...@tuxteam.de wrote:
>
> >Perhaps what you have to do is to change the shape of your
> >terminal's cursor, and nano inherits it.
>
> Firstly, thanks to ALL of you who took time out on this holiday to
> answer
Jdhvra yblcdhfqt svwcmh!
29 matches
Mail list logo
