Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #230005 > unrolled thread
| Started by | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| First post | 2020-12-26 23:30 +0100 |
| Last post | 2020-12-30 04:10 +0100 |
| Articles | 20 on this page of 72 — 14 participants |
Back to article view | Back to linux.debian.user
No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-26 23:30 +0100
Re: No GRUB with brand-new GPU Georgi Naplatanov <gosho@oles.biz> - 2020-12-26 23:40 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-26 23:50 +0100
Re: No GRUB with brand-new GPU Linux-Fan <Ma_Sys.ma@web.de> - 2020-12-27 01:00 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-27 01:20 +0100
Re: No GRUB with brand-new GPU Linux-Fan <Ma_Sys.ma@web.de> - 2020-12-27 01:50 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-27 02:00 +0100
Re: No GRUB with brand-new GPU Felix Miata <mrmazda@earthlink.net> - 2020-12-27 00:30 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-27 00:50 +0100
Re: No GRUB with brand-new GPU Felix Miata <mrmazda@earthlink.net> - 2020-12-27 01:40 +0100
Re: No GRUB with brand-new GPU Sven Joachim <svenjoac@gmx.de> - 2020-12-27 09:00 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-27 13:20 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-27 16:30 +0100
Re: No GRUB with brand-new GPU Anssi Saari <as@sci.fi> - 2020-12-27 22:40 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-27 23:10 +0100
Re: No GRUB with brand-new GPU <tomas@tuxteam.de> - 2020-12-27 23:30 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-27 23:40 +0100
Re: No GRUB with brand-new GPU Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-28 09:20 +0100
Re: No GRUB with brand-new GPU Anssi Saari <as@sci.fi> - 2020-12-28 13:50 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-28 14:00 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-28 22:20 +0100
Re: No GRUB with brand-new GPU Felix Miata <mrmazda@earthlink.net> - 2020-12-28 23:10 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-28 23:30 +0100
Re: No GRUB with brand-new GPU Felix Miata <mrmazda@earthlink.net> - 2020-12-29 00:30 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-29 00:40 +0100
Re: No GRUB with brand-new GPU Felix Miata <mrmazda@earthlink.net> - 2020-12-29 01:30 +0100
Re: No GRUB with brand-new GPU Linux-Fan <Ma_Sys.ma@web.de> - 2020-12-29 02:40 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-29 13:30 +0100
Re: No GRUB with brand-new GPU Anssi Saari <as@sci.fi> - 2020-12-29 11:20 +0100
Re: No GRUB with brand-new GPU "Thomas Schmitt" <scdbackup@gmx.net> - 2020-12-29 12:10 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-29 13:00 +0100
Re: No GRUB with brand-new GPU Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-29 19:10 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-29 19:20 +0100
Re: No GRUB with brand-new GPU Romualdas Taluntis <romualdas@taluntis.lt> - 2020-12-29 20:30 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-29 20:30 +0100
Re: No GRUB with brand-new GPU Romualdas Taluntis <romualdas@taluntis.lt> - 2020-12-29 21:00 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-29 21:20 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-29 21:40 +0100
Re: No GRUB with brand-new GPU Georgi Naplatanov <gosho@oles.biz> - 2020-12-29 21:40 +0100
Re: No GRUB with brand-new GPU Michael Stone <mstone@debian.org> - 2020-12-29 21:20 +0100
Re: No GRUB with brand-new GPU Felix Miata <mrmazda@earthlink.net> - 2020-12-29 22:50 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-29 23:00 +0100
Re: No GRUB with brand-new GPU Michael Stone <mstone@debian.org> - 2020-12-29 23:40 +0100
Re: No GRUB with brand-new GPU Felix Miata <mrmazda@earthlink.net> - 2020-12-30 03:50 +0100
Re: No GRUB with brand-new GPU Michael Stone <mstone@debian.org> - 2020-12-30 04:40 +0100
Re: No GRUB with brand-new GPU Felix Miata <mrmazda@earthlink.net> - 2020-12-30 05:00 +0100
Re: No GRUB with brand-new GPU Doug McGarrett <dmcgarrett@optonline.net> - 2020-12-30 06:00 +0100
Re: No GRUB with brand-new GPU <tomas@tuxteam.de> - 2020-12-30 10:20 +0100
Re: No GRUB with brand-new GPU Michael Stone <mstone@debian.org> - 2020-12-30 15:00 +0100
Re: No GRUB with brand-new GPU Felix Miata <mrmazda@earthlink.net> - 2020-12-30 19:40 +0100
Re: No GRUB with brand-new GPU Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-30 20:10 +0100
Re: No GRUB with brand-new GPU Michael Stone <mstone@debian.org> - 2020-12-30 20:20 +0100
Re: No GRUB with brand-new GPU Felix Miata <mrmazda@earthlink.net> - 2020-12-30 22:10 +0100
Re: No GRUB with brand-new GPU Michael Stone <mstone@debian.org> - 2020-12-30 22:40 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-29 13:20 +0100
Re: No GRUB with brand-new GPU Anssi Saari <as@sci.fi> - 2020-12-29 22:50 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-29 23:00 +0100
Re: No GRUB with brand-new GPU Tony Rowe <torowe@gmail.com> - 2020-12-27 02:10 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-27 02:20 +0100
Re: No GRUB with brand-new GPU David Wright <deblis@lionunicorn.co.uk> - 2020-12-27 05:10 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-27 13:10 +0100
Re: No GRUB with brand-new GPU David Wright <deblis@lionunicorn.co.uk> - 2020-12-28 02:50 +0100
Re: No GRUB with brand-new GPU Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-27 08:40 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-27 13:10 +0100
Re: No GRUB with brand-new GPU Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-28 09:30 +0100
Re: No GRUB with brand-new GPU Romualdas Taluntis <romualdas@taluntis.lt> - 2020-12-29 14:00 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-29 14:00 +0100
Re: No GRUB with brand-new GPU Felix Miata <mrmazda@earthlink.net> - 2020-12-29 18:10 +0100
Re: No GRUB with brand-new GPU The Wanderer <wanderer@fastmail.fm> - 2020-12-29 18:20 +0100
Re: No GRUB with brand-new GPU Felix Miata <mrmazda@earthlink.net> - 2020-12-29 18:40 +0100
Re: No GRUB with brand-new GPU Michael Stone <mstone@debian.org> - 2020-12-29 19:20 +0100
Re: No GRUB with brand-new GPU Felix Miata <mrmazda@earthlink.net> - 2020-12-30 04:10 +0100
Page 1 of 4 [1] 2 3 4 Next page →
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2020-12-26 23:30 +0100 |
| Subject | No GRUB with brand-new GPU |
| Message-ID | <Bqqew-xP-53@gated-at.bofh.it> |
[Multipart message — attachments visible in raw view] — view raw
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) until after adjusting some combination of installed driver- and firmware-related packages, module-blacklist settings, boot-time options, initrd state, GRUB configuration, and possibly other (again, e.g., X) config files. I'm generally fine with wrangling that, and based on my pre-swap research, was expecting to be able to get up and running with the new GPU today. What I got, instead, was not even that far. 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 through to the monitor on a basic level. However, as soon as the machine tries to hand over control to the bootloader, I get a hard freeze; the screen goes black (albeit I think still with backlight), the keyboard light toggle keys stop responding, and the GRUB menu never appears. Waiting a long time doesn't change anything; even after roughly half an hour of waiting, pressing the Power button once (no press-and-hold) shuts the system off immediately, which indicates that the system hasn't progressed much (if at all) past early boot. Thus far, Google has not been helpful. I find plenty about black screens after GRUB, but very little about before GRUB and after POST, and what little I find is from other distros - some Ubuntu (earlier versions, mostly 2010-era), some Arch, some RHEL - which don't necessarily handle either graphics drivers or GRUB in a way that will let their directions reliably translate to Debian. Any suggestions for what to try? I'm back up now with the old GPU, since researching this on my smartphone was going nowhere. I've dug into /etc/grub* and /boot/ looking for anything which seemed related, with no promising hits yet. Barring other discoveries, my current next step is to dig up a suitably recent Debian-based live-boot environment, boot to that, and see what it does. If it gives me usable graphics, I want to see what it's doing at bootloader time, and what parts I might be able to transpose into my primary install. However, given that live-boot setups don't always handle the early parts of boot the same way as hard-drive installs do, I'm not positive this will be fruitful. Also, given how relatively new this card is, I'm not sure I'll be able to find a suitable environment which does work with it to the level I need. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
[toc] | [next] | [standalone]
| From | Georgi Naplatanov <gosho@oles.biz> |
|---|---|
| Date | 2020-12-26 23:40 +0100 |
| Message-ID | <Bqqoa-BP-21@gated-at.bofh.it> |
| In reply to | #230005 |
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 expecting to get no graphics support (e.g., X, et cetera) until > after adjusting some combination of installed driver- and > firmware-related packages, module-blacklist settings, boot-time options, > initrd state, GRUB configuration, and possibly other (again, e.g., X) > config files. I'm generally fine with wrangling that, and based on my > pre-swap research, was expecting to be able to get up and running with > the new GPU today. > > What I got, instead, was not even that far. > > 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 through to the monitor on a basic level. > > However, as soon as the machine tries to hand over control to the > bootloader, I get a hard freeze; the screen goes black (albeit I think > still with backlight), the keyboard light toggle keys stop responding, > and the GRUB menu never appears. Waiting a long time doesn't change > anything; even after roughly half an hour of waiting, pressing the Power > button once (no press-and-hold) shuts the system off immediately, which > indicates that the system hasn't progressed much (if at all) past early > boot. > > Thus far, Google has not been helpful. I find plenty about black screens > after GRUB, but very little about before GRUB and after POST, and what > little I find is from other distros - some Ubuntu (earlier versions, > mostly 2010-era), some Arch, some RHEL - which don't necessarily handle > either graphics drivers or GRUB in a way that will let their directions > reliably translate to Debian. > > > Any suggestions for what to try? > > I'm back up now with the old GPU, since researching this on my > smartphone was going nowhere. I've dug into /etc/grub* and /boot/ > looking for anything which seemed related, with no promising hits yet. > > Barring other discoveries, my current next step is to dig up a suitably > recent Debian-based live-boot environment, boot to that, and see what it > does. If it gives me usable graphics, I want to see what it's doing at > bootloader time, and what parts I might be able to transpose into my > primary install. > > However, given that live-boot setups don't always handle the early parts > of boot the same way as hard-drive installs do, I'm not positive this > will be fruitful. Also, given how relatively new this card is, I'm not > sure I'll be able to find a suitable environment which does work with it > to the level I need. > Hi, I'm not a hardware expert but I found the following on Internet: - the interface for this card is PCI-Express 4.0 and I guess that your old computer doesn't support that - BIOS Support - Dual UEFI - I'm not sure what this means but is it possible this card not to be supported by non-UEFI systems ? Kind regards Georgi
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2020-12-26 23:50 +0100 |
| Message-ID | <BqqxP-Fx-3@gated-at.bofh.it> |
| In reply to | #230006 |
[Multipart message — attachments visible in raw view] — view raw
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 today swapped it in and attempted to boot with it. >> 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 through to the monitor on a basic level. >> >> However, as soon as the machine tries to hand over control to the >> bootloader, I get a hard freeze; the screen goes black (albeit I think >> still with backlight), the keyboard light toggle keys stop responding, >> and the GRUB menu never appears. Waiting a long time doesn't change >> anything; even after roughly half an hour of waiting, pressing the Power >> button once (no press-and-hold) shuts the system off immediately, which >> indicates that the system hasn't progressed much (if at all) past early >> boot. > Hi, > > I'm not a hardware expert but I found the following on Internet: > > - the interface for this card is PCI-Express 4.0 and I guess that your > old computer doesn't support that > > - BIOS Support - Dual UEFI - I'm not sure what this means but is it > possible this card not to be supported by non-UEFI systems ? I'd consider these plausible enough to pursue, except for the fact that (as noted above) I do get display output just fine during POST and in the BIOS. If the slot interface weren't compatible, I'd expect to not get any video output from the system at all. "Dual UEFI" I don't remember seeing in regard to this device; I'm not sure what it'd mean for a GPU. It's normally something I expect to see for a motherboard, where it would mean that the device supports having two different UEFIs in place at once, so you can flash a new one and still have the old one to fall back to if the new one fails. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
[toc] | [prev] | [next] | [standalone]
| From | Linux-Fan <Ma_Sys.ma@web.de> |
|---|---|
| Date | 2020-12-27 01:00 +0100 |
| Message-ID | <BqrDz-1ig-5@gated-at.bofh.it> |
| In reply to | #230006 |
[Multipart message — attachments visible in raw view] — view raw
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 to boot with it. [...] > > 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 through to the monitor on a basic level. Curious, what machine does not do UEFI yet but still benefits from large GPUs such as the RX 5700? [...] > > Any suggestions for what to try? [...] > I'm not a hardware expert but I found the following on Internet: > > - the interface for this card is PCI-Express 4.0 and I guess that your > old computer doesn't support that PCIe 4.0 is backwards-compatible (down to at least PCIe 3.0, possibly further). > - BIOS Support - Dual UEFI - I'm not sure what this means but is it > possible this card not to be supported by non-UEFI systems ? (Unsure on this) [...] I have a RadeonPro W5500 which is also too new, to be supported on Debian stable out of the box. What I did to get it running for basic 2D graphics (enough for me most of the time) was to install the following packages from debian-backports: * linux-image-5.8.0-0.bpo.2-amd64 * firmware-amd-graphics Additionally, I tried to enable amdgpu in xorg.conf, although I am not sure whether that is actually needed: $ cat /etc/X11/xorg.conf Section "Device" Identifier "AMD" Driver "amdgpu" EndSection This system is using UEFI to boot and I do not recall having the same issue (black screen) even before, though. Here are some other suggestions: As you mentioned GRUB not loading correctly, could there perhaps be an explicit graphics resolution configuration entry? I do not have any special configuration enabled there: $ grep -E '(GFXMODE|TERMINAL)' /etc/default/grub #GRUB_TERMINAL=console #GRUB_GFXMODE=640x480 Apart from a live system, it could already be helpful to boot a Debian installer to see if it can load a Linux if GRUB is not invovled. If that works (i.e. presents language selection screen), checking with a live system seems to be a reasonable next step. If you need the 3D accelleration performance (why buy an RX 5700 if not?), I'd suggest to setup a Debian testing environment for that. I managed to get some (fast enough for me) 3D accelleration working by creating a Debian sid chroot (testing did not have some dependencies I needed) and I can use it by logging in through TTY2 -> chroot -> startx. BUT: Please note that this setup is brittle -- dual-boot or testing-only configurations can be expected to run _more stable_ in this scenario :) HTH Linux-Fan öö
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2020-12-27 01:20 +0100 |
| Message-ID | <BqrWV-1DX-1@gated-at.bofh.it> |
| In reply to | #230011 |
[Multipart message — attachments visible in raw view] — view raw
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 (Radeon RX 570 0 >> > XT), and today swapped it in and attempted to boot with it. >> > 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 through to the monitor on a basic level. > > 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 of price vs. performance, with then-outsize specs in other regards, including what was at the time the top-end non-server CPU in the world. It's fallen well behind that standard, but is still far from the bottleneck in my system. The motivation for the GPU upgrade is that the card I have seems to be literally the last model made that doesn't support the required baseline for a game I've seen recommended. Based on the most recent Linux-including reviews as of the time I made the choice, the 5700 seems to be the current best option in terms of price vs. (performance / future-proofing). >> > Any suggestions for what to try? > I have a RadeonPro W5500 which is also too new, to be supported on Debian > stable out of the box. What I did to get it running for basic 2D > graphics (enough for me most of the time) was to install the following > packages from debian-backports: > > * linux-image-5.8.0-0.bpo.2-amd64 > * firmware-amd-graphics > > Additionally, I tried to enable amdgpu in xorg.conf, although I am not sure > whether that is actually needed: > > $ cat /etc/X11/xorg.conf > Section "Device" > Identifier "AMD" > Driver "amdgpu" > EndSection > > This system is using UEFI to boot and I do not recall having the same issue > (black screen) even before, though. All of those are part of what I expected to have to wrangle post-boot in order to get things working. (I'm running Debian testing, for what that's worth, so the kernel and so forth should already be new enough.) > Here are some other suggestions: > > As you mentioned GRUB not loading correctly, could there perhaps be an > explicit graphics resolution configuration entry? I do not have any special > configuration enabled there: > > $ grep -E '(GFXMODE|TERMINAL)' /etc/default/grub > #GRUB_TERMINAL=console > #GRUB_GFXMODE=640x480 Doesn't seem so; the output I get from that command is identical. > Apart from a live system, it could already be helpful to boot a Debian > installer to see if it can load a Linux if GRUB is not invovled. If that > works (i.e. presents language selection screen), checking with a live system > seems to be a reasonable next step. By my terminology, a Debian installer *is* a (special case of a) live-boot environment. Which is not to say it would necessarily have been my choice to test this, but it might. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
[toc] | [prev] | [next] | [standalone]
| From | Linux-Fan <Ma_Sys.ma@web.de> |
|---|---|
| Date | 2020-12-27 01:50 +0100 |
| Message-ID | <BqspX-1Nx-1@gated-at.bofh.it> |
| In reply to | #230012 |
[Multipart message — attachments visible in raw view] — view raw
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 recent model of GPU (Radeon RX 5700 > >> > XT), and today swapped it in and attempted to boot with it. > > >> > 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 through to the monitor on a basic level. > > > > 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 of > price vs. performance, with then-outsize specs in other regards, > including what was at the time the top-end non-server CPU in the world. > It's fallen well behind that standard, but is still far from the > bottleneck in my system. > > The motivation for the GPU upgrade is that the card I have seems to be > literally the last model made that doesn't support the required baseline > for a game I've seen recommended. Based on the most recent > Linux-including reviews as of the time I made the choice, the 5700 seems > to be the current best option in terms of price vs. (performance / > future-proofing). OK, that makes sense. I just wanted to ask because I was once in a similar situation. I had upgraded my venerable HP Z400 (Xeon W3550 -- not the fastet at the time) by adding a Radeon RX 570 to replace the previous Nvidia GTX 570 card and had... zero performance improvement in gaming because without me noticing this in other application contexts/earlier, the CPU had become the bottleneck :( > >> > Any suggestions for what to try? [...] > All of those are part of what I expected to have to wrangle post-boot in > order to get things working. (I'm running Debian testing, for what > that's worth, so the kernel and so forth should already be new enough.) [...] I am out of ideas on this... > By my terminology, a Debian installer *is* a (special case of a) > live-boot environment. Which is not to say it would necessarily have > been my choice to test this, but it might. [...] I just wanted to point the installer out, because it might be more easily available (already existent on a medium?) and hence the easier test to do. Unlike many other live systems, its terminal-based UI may help rule out X11 problems (although as noted, they are obviously not the issue at hand...) HTH Linux-Fan öö
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2020-12-27 02:00 +0100 |
| Message-ID | <BqszE-1Qw-5@gated-at.bofh.it> |
| In reply to | #230014 |
[Multipart message — attachments visible in raw view] — view raw
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 of price vs. performance, with then-outsize specs in other >> regards, including what was at the time the top-end non-server CPU >> in the world. It's fallen well behind that standard, but is still >> far from the bottleneck in my system. >> >> The motivation for the GPU upgrade is that the card I have seems to >> be literally the last model made that doesn't support the required >> baseline for a game I've seen recommended. Based on the most >> recent Linux-including reviews as of the time I made the choice, >> the 5700 seems to be the current best option in terms of price vs. >> (performance / future-proofing). > > OK, that makes sense. I just wanted to ask because I was once in a > similar situation. I had upgraded my venerable HP Z400 (Xeon W3550 -- > not the fastet at the time) by adding a Radeon RX 570 to replace the > previous Nvidia GTX 570 card and had... zero performance improvement > in gaming because without me noticing this in other application > contexts/earlier, the CPU had become the bottleneck :( Reasonable. In my case, I have a Core i7 990x Extreme, which cost me $1050 brand-new; it may turn out to be the bottleneck with the new GPU, but the resulting performance should still be better than what I've got, and at least the game should actually be willing to *launch*. Thanks for the input, regardless of whether it winds up helping. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2020-12-27 00:30 +0100 |
| Message-ID | <Bqray-18P-15@gated-at.bofh.it> |
| In reply to | #230005 |
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, if splash=silent is included, either remove it, or switch to splash=verbose. If the switch itself doesn't help, then try graphical after selecting some specific mode you know your display supports. I use video=1440x900 on cmdline most of the time for the vttys even when the display's native is 1920x1080, 1920x1200 or 2560x1440. -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2020-12-27 00:50 +0100 |
| Message-ID | <BqrtT-1fj-9@gated-at.bofh.it> |
| In reply to | #230009 |
[Multipart message — attachments visible in raw view] — view raw
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 I don't see any way to do that in the /etc/default/grub I have. The closest thing I see is # Uncomment to disable graphical terminal (grub-pc only) #GRUB_TERMINAL=console but that says it's for grub-pc only, i.e. the "legacy" version of grub, whereas I'm running grub2. A bit of Googling suggests that # 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 also supports a value of 'text' rather than a FOOxBAR resolution, but I don't see that documented anywhere yet. I don't expect such a change to be particularly risky, but I imagine if I do somehow fail to boot after making it (e.g. if I specify a setting that isn't actually supported), the solution would involve a live-boot environment and possibly chrooting into the installed system. > While in /etc/default/grub, if splash=silent is included, either > remove it, or switch to splash=verbose. It isn't. From the little I've read up on regarding this in the meantime, I'd expect this splash setting to be only regarding the post-GRUB-menu boot process, which is beyond the point I've reached. For what it's worth, I've long since intentionally disabled all "quiet" boot settings I'm aware of. > If the switch itself doesn't help, then try graphical after selecting > some specific mode you know your display supports. I use > video=1440x900 on cmdline most of the time for the vttys even when > the display's native is 1920x1080, 1920x1200 or 2560x1440. I'm not even getting to the GRUB command line; the hang is happening before GRUB displays anything at all. I may try specifying a resolution such as this to GRUB_GFXMODE, but I'm not entirely certain that's relevant to the behavior I'm seeing, although it would be plausible for it to be so. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2020-12-27 01:40 +0100 |
| Message-ID | <Bqsgh-1K9-7@gated-at.bofh.it> |
| In reply to | #230010 |
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
>> booting.
> That's a good suggestion, except I don't see any way to do that in the
> /etc/default/grub I have.
> The closest thing I see is
> # Uncomment to disable graphical terminal (grub-pc only)
> #GRUB_TERMINAL=console
> but that says it's for grub-pc only, i.e. the "legacy" version of grub,
> whereas I'm running grub2.
I know it says grub-pc only, but all mine are uncommented. And, all mine are on
UEFI installations. All my legacy BIOS installations boot from a custom partition
with Grub Legacy, which is used to boot every installation on the disk. It may be
that what it really means is: not arm*, not sparc, not mips, not ppc....
> A bit of Googling suggests that
> # 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
Mine all are GRUB_GFXMODE="auto", but I have no AMD anything newer than about 6
years old.
> also supports a value of 'text' rather than a FOOxBAR resolution, but I
> don't see that documented anywhere yet.
I think what you can do is create /etc/grub.d/05_do-text containing:
cat <<EOF
set textmode=true
terminal_output console
EOF
It may be sufficient with only the first of the two. Textmode can be made optional
via hotkey:
cat <<EOF
hiddenentry 'Text mode' --hotkey 't' {
set textmode=true
terminal_output console
}
EOF
--
Evolution as taught in public schools, like religion,
is based on faith, not on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
[toc] | [prev] | [next] | [standalone]
| From | Sven Joachim <svenjoac@gmx.de> |
|---|---|
| Date | 2020-12-27 09:00 +0100 |
| Message-ID | <Bqz87-60R-17@gated-at.bofh.it> |
| In reply to | #230010 |
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 and try
>> booting.
>
> That's a good suggestion, except I don't see any way to do that in the
> /etc/default/grub I have.
>
> The closest thing I see is
>
> # Uncomment to disable graphical terminal (grub-pc only)
> #GRUB_TERMINAL=console
>
> but that says it's for grub-pc only, i.e. the "legacy" version of grub,
> whereas I'm running grub2.
No, grub-pc is not the legacy version of grub, it is grub2 for legacy
computers without EFI. The version of grub2 for modern UEFI systems is
grub-efi-amd64 which uses the framebuffer set up by the system's
firmware (hence, no traditional text mode).
Cheers,
Sven
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2020-12-27 13:20 +0100 |
| Message-ID | <BqDbH-eX-3@gated-at.bofh.it> |
| In reply to | #230021 |
[Multipart message — attachments visible in raw view] — view raw
On 2020-12-27 at 02:51, Sven Joachim wrote: > 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 and try booting. >> >> That's a good suggestion, except I don't see any way to do that in >> the /etc/default/grub I have. >> >> The closest thing I see is >> >> # Uncomment to disable graphical terminal (grub-pc only) >> #GRUB_TERMINAL=console >> >> but that says it's for grub-pc only, i.e. the "legacy" version of >> grub, whereas I'm running grub2. > > No, grub-pc is not the legacy version of grub, it is grub2 for > legacy computers without EFI. The version of grub2 for modern UEFI > systems is grub-efi-amd64 which uses the framebuffer set up by the > system's firmware (hence, no traditional text mode). Ah, thanks for that correction; that does ring a bell now that you mention it. That would explain why this would be effective. I've made that change in this file; as soon as I reach a point in my operations where shutting down again is reasonable, I'll test to confirm that I can boot that way with the old GPU (and what behavior difference there may be with that change), and assuming it works will swap GPUs and see what I get. I also want to make sure I have an up-to-date rescue environment on external media, just in case I need to revert this change in order to boot my current system again. Unlikely, but better to be safe than sorry. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2020-12-27 16:30 +0100 |
| Message-ID | <BqG9z-1XY-5@gated-at.bofh.it> |
| In reply to | #230026 |
[Multipart message — attachments visible in raw view] — view raw
On 2020-12-27 at 07:10, The Wanderer wrote: > On 2020-12-27 at 02:51, Sven Joachim wrote: > >> On 2020-12-26 18:44 -0500, The Wanderer wrote: >>> That's a good suggestion, except I don't see any way to do that >>> in the /etc/default/grub I have. >>> >>> The closest thing I see is >>> >>> # Uncomment to disable graphical terminal (grub-pc only) >>> #GRUB_TERMINAL=console >>> >>> but that says it's for grub-pc only, i.e. the "legacy" version >>> of grub, whereas I'm running grub2. >> >> No, grub-pc is not the legacy version of grub, it is grub2 for >> legacy computers without EFI. The version of grub2 for modern >> UEFI systems is grub-efi-amd64 which uses the framebuffer set up by >> the system's firmware (hence, no traditional text mode). > > Ah, thanks for that correction; that does ring a bell now that you > mention it. > > That would explain why this would be effective. I've made that change > in this file; as soon as I reach a point in my operations where > shutting down again is reasonable, I'll test to confirm that I can > boot that way with the old GPU (and what behavior difference there > may be with that change), and assuming it works will swap GPUs and > see what I get. No joy. It works fine with the old GPU (better, actually, in that the GRUB menu doesn't take several seconds to draw; the lower boot-menu resolution is no hardship), but if anything the behavior with the new GPU is *worse*; I think I got the keyboard freeze even earlier on my first try with the new configuration, although it seems to have gone back to happening at the handover on subsequent attempts, I then went into the BIOS to check it over again, and found that an option for "BIOS EHCI handoff" was set to enabled, with the apparent meaning that the BIOS would take care of handing over USB EHCI control to the booted system rather than relying on the OS to handle that. On the presumption that modern Linux should be able to handle this itself, I disabled that setting; my USB devices are working fine now with the old GPU, but on the new it left me with no apparent change. That may be worth paying more attention to: this isn't just a black-screen hang, it's a more full-system hang. The keyboard lights stay in whatever state they were in immediately prior to the handover, and nothing responds to the keyboard at all. I did also confirm that the BIOS version is 1402, which is the version number of the final BIOS released for this motherboard back in 2012. If the BIOS needing updates to work with this GPU is the problem, then I'm SOL. Still, again, if that were the problem I'd expect there to be no display output during POST and in the BIOS... I need to get that live-boot medium ready and do those tests. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
[toc] | [prev] | [next] | [standalone]
| From | Anssi Saari <as@sci.fi> |
|---|---|
| Date | 2020-12-27 22:40 +0100 |
| Message-ID | <BqLVD-5Hj-1@gated-at.bofh.it> |
| In reply to | #230027 |
The Wanderer <wanderer@fastmail.fm> writes: > I need to get that live-boot medium ready and do those tests. That seems like a good thing to do. Another thing you could do is post your grub.cfg. It seems a little odd you haven't. Also from previous discussion I think it's worth mentioning that Grub doesn't actually read /etc/default/grub, update-grub reads it to generate /boot/grub/grub.cfg. So only editing /etc/default/grub doesn't change Grub config in any way. If you're up for it, you could setup a serial terminal and send Grub output to serial and/or console. That way you might be able to boot and wouldn't have to switch video cards to try different configurations. But if you only have that one computer then I guess not.
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2020-12-27 23:10 +0100 |
| Message-ID | <BqMoF-68y-7@gated-at.bofh.it> |
| In reply to | #230035 |
[Multipart message — attachments visible in raw view] — view raw
On 2020-12-27 at 16:36, Anssi Saari wrote: > The Wanderer <wanderer@fastmail.fm> writes: > >> I need to get that live-boot medium ready and do those tests. > > That seems like a good thing to do. I have it ready now, but haven't shut down for another swap, in part because I've been napping. I may do it tonight, or more likely, tomorrow. > Another thing you could do is post your grub.cfg. It seems a little > odd you haven't. It mainly just hadn't occurred to me, in part (though only in part) because I thought I recalled that the boot-configuration files for GRUB2 weren't the same as from legacy GRUB (and might even be stored in multiple files) and had a mental association of that file with legacy GRUB, so didn't trust it to necessarily be the correct / full config. Now that it's been suggested, I have a bit of concern about posting a file containing filesystem (and other related?) UUIDs; that's probably excessive paranoia (last time I needed to post a file containing complex IDs like that some of them were encryption-key hashes), but I've still chosen to sed them out into generic form before attaching the result. That's the only difference between the attachment and the original. I don't expect there to be any useful / relevant information there, but one never knows. It occurs to me that it might be worthwhile to note down some get-information commands from the GRUB documentation, and stop at the GRUB menu next time I'm booting with the old / current GPU to see whether I can extract anything that might be helpful. > Also from previous discussion I think it's worth mentioning that Grub > doesn't actually read /etc/default/grub, update-grub reads it to > generate /boot/grub/grub.cfg. So only editing /etc/default/grub > doesn't change Grub config in any way. Yes, I know that much. After applying the change, I ran update-grub to re-generate the config files appropriately. > If you're up for it, you could setup a serial terminal and send Grub > output to serial and/or console. That way you might be able to boot > and wouldn't have to switch video cards to try different > configurations. But if you only have that one computer then I guess > not. We have at least a dozen computers in the household, if you count servers and laptops, and AFAIK a plurality of them are Debian-based. What we don't have is A: any experience with working with serial console, or B: (that I know of) any cables that might work to connect two computers that way. I have the impression that things have by now developed to the point where a physical serial-port cable (of the classic type of serial port and cable, whose connectors can be visually confused with a VGA port in some cases) is no longer necessary, which is good, since if we ever had such a thing it was at least back in the days of PS/2 keyboards and mice and might have been back in the days before our home computers had internal hard drives. I imagine USB would be the replacement (just based on the name), and I'm also aware of the existence (kernel-side) of netconsole, but how to use either for this I don't know. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2020-12-27 23:30 +0100 |
| Message-ID | <BqMI1-6fP-1@gated-at.bofh.it> |
| In reply to | #230036 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, Dec 27, 2020 at 05:08:27PM -0500, The Wanderer wrote: [...] > I have the impression that things have by now developed to the point > where a physical serial-port cable (of the classic type of serial port > and cable, whose connectors can be visually confused with a VGA port in > some cases) is no longer necessary, which is good, since if we ever had > such a thing it was at least back in the days of PS/2 keyboards and mice > and might have been back in the days before our home computers had > internal hard drives. "Modern" computers tend to lack serial ports (sometimes a pity, but well...) Still I doubt it would be any help. You made a credible case that there is a hard lockdown at the handover from the BIOS to GRUB. You'd have to be very lucky for GRUB to utter a last sigh over serial before that. My impression is that the video card reacts allergically to some modeset attempt by GRUB and this causes a pretty low level lockup. Cheers - t
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2020-12-27 23:40 +0100 |
| Message-ID | <BqMRH-6jm-1@gated-at.bofh.it> |
| In reply to | #230038 |
[Multipart message — attachments visible in raw view] — view raw
On 2020-12-27 at 17:23, tomas@tuxteam.de wrote: > On Sun, Dec 27, 2020 at 05:08:27PM -0500, The Wanderer wrote: > > [...] > >> I have the impression that things have by now developed to the >> point where a physical serial-port cable (of the classic type of >> serial port and cable, whose connectors can be visually confused >> with a VGA port in some cases) is no longer necessary, which is >> good, since if we ever had such a thing it was at least back in the >> days of PS/2 keyboards and mice and might have been back in the >> days before our home computers had internal hard drives. > > "Modern" computers tend to lack serial ports (sometimes a pity, but > well...) > > Still I doubt it would be any help. You made a credible case that > there is a hard lockdown at the handover from the BIOS to GRUB. You'd > have to be very lucky for GRUB to utter a last sigh over serial > before that. > > My impression is that the video card reacts allergically to some > modeset attempt by GRUB and this causes a pretty low level lockup. I've had similar thoughts, but if that were the case, I'd expect that telling GRUB to use "console" output would avoid the problem, by having it not do any modesetting. My most recent attempt was with terminal_input and terminal_output set to "console", and the problem persisted. I do see various modules listed in the grub.cfg load_video function, and it's not impossible that the process of trying to use one or more of those includes some action which triggers this behavior. I haven't found a place to configure that, though - or I hadn't until now; it's in /etc/grub.d/00_header, and can be overridden to a single module by defining GRUB_VIDEO_BACKEND (presumably, in /etc/default/grub). I might pursue that if the live-boot environment doesn't give fruitful results. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
[toc] | [prev] | [next] | [standalone]
| From | Andrei POPESCU <andreimpopescu@gmail.com> |
|---|---|
| Date | 2020-12-28 09:20 +0100 |
| Message-ID | <BqVUZ-3W5-7@gated-at.bofh.it> |
| In reply to | #230039 |
[Multipart message — attachments visible in raw view] — view raw
On Du, 27 dec 20, 17:31:37, The Wanderer wrote: > > I do see various modules listed in the grub.cfg load_video function, and > it's not impossible that the process of trying to use one or more of > those includes some action which triggers this behavior. I haven't found > a place to configure that, though - or I hadn't until now; it's in > /etc/grub.d/00_header, and can be overridden to a single module by > defining GRUB_VIDEO_BACKEND (presumably, in /etc/default/grub). For testing purposes you could just edit grub.cfg, even if your changes will be overridden on the next 'update-grub'. At least you'll know if it's a path worth pursuing. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
[toc] | [prev] | [next] | [standalone]
| From | Anssi Saari <as@sci.fi> |
|---|---|
| Date | 2020-12-28 13:50 +0100 |
| Message-ID | <Br08h-6HP-7@gated-at.bofh.it> |
| In reply to | #230036 |
The Wanderer <wanderer@fastmail.fm> writes: > On 2020-12-27 at 16:36, Anssi Saari wrote: > >> The Wanderer <wanderer@fastmail.fm> writes: >> >>> I need to get that live-boot medium ready and do those tests. >> >> That seems like a good thing to do. > > I have it ready now, but haven't shut down for another swap, in part > because I've been napping. I may do it tonight, or more likely, tomorrow. > >> Another thing you could do is post your grub.cfg. It seems a little >> odd you haven't. > > It mainly just hadn't occurred to me, in part (though only in part) > because I thought I recalled that the boot-configuration files for GRUB2 > weren't the same as from legacy GRUB (and might even be stored in > multiple files) and had a mental association of that file with legacy > GRUB, so didn't trust it to necessarily be the correct / full config. Well, as I recall from the past, old Grub used /boot/grub/menu.lst. I still have one of those around dated Aug 14 2016. Not sure that's an accurate date but I can't remember my bootloader history, other than I stuck with LILO for a very long time. Anyways, I don't see much anything in the grub.cfg. Maybe the video options but it seems to be pretty much the default and that doesn't seem to cause issues very often, at least I couldn't find any Grub crashes with specifically AMD cards or any hardware. One thing came to my mind, do you have the appropriate aux power connectors available and connected? Looks like the RX 5700 XT is quite power hungry at 225 W max vs. 151 W with your old card. Different connectors too (6 pin + 8 pin instead of 2x 6 pin). And these cards can be quite picky about having appropriate power connected. > I have the impression that things have by now developed to the point > where a physical serial-port cable (of the classic type of serial port > and cable, whose connectors can be visually confused with a VGA port in > some cases) is no longer necessary, which is good, since if we ever had > such a thing it was at least back in the days of PS/2 keyboards and mice > and might have been back in the days before our home computers had > internal hard drives. Not quite that long ago. > I imagine USB would be the replacement (just based on the name), and I'm > also aware of the existence (kernel-side) of netconsole, but how to use > either for this I don't know. I've never tried it but as I understand it, Grub has some support for USB-serial adapters. After all, Grub has to support USB keyboards which means the basic building blocks of USB support have to be there. Adding support for USB-serial isn't that hard after that. But yes, this was a long shot anyways.
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2020-12-28 14:00 +0100 |
| Message-ID | <Br0hX-6LY-3@gated-at.bofh.it> |
| In reply to | #230050 |
[Multipart message — attachments visible in raw view] — view raw
On 2020-12-28 at 07:47, Anssi Saari wrote: > One thing came to my mind, do you have the appropriate aux power > connectors available and connected? Looks like the RX 5700 XT is > quite power hungry at 225 W max vs. 151 W with your old card. > Different connectors too (6 pin + 8 pin instead of 2x 6 pin). And > these cards can be quite picky about having appropriate power > connected. Yes - I noted the different power-connector requirements when I first installed the card, and I've had them in place on every swap-in since. If the card weren't getting its proper power, I'd expect anything from no video output at all to a warning light to a motherboard beep, none of which is happening. My PSU is overpowered for the system it's in, so I'm reasonably sure it's capable of handling the added load for the upgraded GPU without issues. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
[toc] | [prev] | [next] | [standalone]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | linux.debian.user
csiph-web