[Discuss] Does somebody here have available an older low-end Linux-compatible PCIe graphics card?
Cy.Schubert at cschubert.com
Sun May 27 12:42:25 PDT 2018
In message <nycvar.QRO.7.76.1805251013370.1745 at zreyva.zlyna.ubzr>,
"Alan W. Irw
> The reason I ask about the availability of older, low-end Linux
> graphics cards is I have having lock-up trouble (three lock ups
> yesterday) with the AMD RX 550 graphics card on my new computer. So I
> would be willing to pay a reasonable price to acquire a used
> Linux-compatible PCIe-based graphics card to see if that change
> stabilizes my new computer.
> The AMD RX 550 was released for sale last year and almost immediately
> got an excellent Linux review at Phoronix. So I assumed it would be
> OK for my new system since generally although that site is focussed on
> performance, they do go out of their way to mention any lock ups that
> occur during their extensive testing and apparently there were none.
> But in retrospect the Linux environment Phoronix was using was cutting
> edge a year ago, and Debian is fairly conservative about how quickly
> they propagate cutting-edge stuff to even the Debian Testing rolling
> release I am using at the moment. So I assume it will be a matter of
> several months or more before Debian Testing is fully ready to support
> this one-year old graphics card.
drivers/gpu/drm sources cards supported by the linux kernel. They say
GCN 4th gen is supported but you'll need to look for yourself to be
> By the way, when it is working the card fully justifies the write-up
> at Phoronix because I have never seen such good looking computer videos befor
> (e.g., the volcanic eruption videos you can currently see on The
> Weather Network). But despite those good-looking videos I am pretty
> sure it is the card that is the source of the lock ups that are
> occurring on the new computer because those always (so far at least)
> only occur in X (as opposed to the legacy console mode also supported
> by the card and which uses much less card functionality than X). All
> the lock ups require at least a system reset to regain control of the
> graphics. Sometimes before the reset the system is completely dead
> (cannot even ping to it). Other times, I can ssh into the new
> computer from my old one and shutdown before the required reset. But
> on one occasion after such a reset the computer could not even display
> to my monitor during the POST phase, and I had to power down for
> several minutes (as opposed to the extremely short power down you get
> with a system reset) before the POST phase would display to my
> monitor. So an obvious concern that crossed my mind after that
> last-chance total power down finally made the card work again, is
> whatever is wrong with the Debian testing support of the RX 550 might
> accidentally turn that graphics card into a brick..
> Of course, it is possible that some non-graphics hardware issue on my
> new system is the source of the lock ups. But some extensive file
> transfers (with the rsync --checksum option used for a second rsync to
> confirm all was well with the first rsync) indicate good overall (cpu,
> memory, and motherboard) reliability.
> Also, after the 3 lock ups yesterday, I have decided to test the new
> system for a while by continuing to do all my work on it but with the X
> display being done remotely using my old computer. So in this mode,
> the only strain on the RX 550 is whatever functionality it needs to
> display the login prompt in console mode after the latest boot. The
> longest the computer has been up while doing its own X display is 2
> days. So if I can keep the new computer up (while doing all my work
> on it other than X display) for a week or so, I think that will be
> pretty clear evidence that it is either the RX 550 hardware for this
> particular card (i.e., I was sold a card with a manufacturing defect)
> or more likely the kernel and X software for Debian testing that
> currently drives that card that is the issue.
Are you sure your system locked up? If any combination of caps-,
scroll-, and/or num-lock LEDs are flashing, the kernel has panicked.
Try to get a kernel crash dump and let your distro know. Without a
register dump and backtrace there is no way to know what causes your
issue -- and random guessing makes matters worse. You will need to
If it is a genuine lockup, it's likely a deadlock (or deadly embrace as
some people call it) with interrupts disabled. Those are harder to
debug. In that case, in addition to enabling kdump, enable the hot key
to break the system out of deadlock and take a dump. (Of course this
isn't 100% effective.)
Either way let the folks who supplied your distro know after you
capture a dump. There is no way to randomly guess and know for sure.
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX: <cy at FreeBSD.org> Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
More information about the Discuss