[OT} New desktop part 6.

The duff memory stick (if that's what this post implies), could prevent the system from starting, but there should have been a memory beep if that was the case. The manual has beep codes, but no POST code table that I saw in a quick skim.

The BIOS starts with CPU_register-only code, and does not have usage of the DRAM initially. It has to program the controller for the correct CAS on the memory controller end and on the DRAM end. There is a "special cycle" sent on the DRAM bus, that programs the DRAM for a certain CAS. So if the RAM runs at DDR5-4800 or whatever, and with a certain CAS at that speed, the clock needs to be set up for that (divider or synthesizer), and then the special cycle commissions the DRAM. The DRAM may also have impedance settings for bus termination purposes (some of that is programmable). The DRAM also has calibration cycles, which have been getting more fancy with each generation.

All these things happen without the machine crashing.

Now, if the memory fails tests after that, the BIOS can send the beep code to SPKR header and the case speaker.

If the BIOS started to use low memory (E801 reserved area), and, the memory was bad, then when the BIOS "steps in it", it could crash. There would be no beeps. However, on a motherboard with staging lights, one of the staging lights is on, and the white lettering next to the LED tells you where it crashed. It crashed during "MEM".

The motherboard in this case, I can't get a picture with sufficient detail, but as near as I can tell, there are no staging LEDs. "Staging" refers to the Drag Race track, where a "christmas tree" with lights on it, counts down the beginning of the race. And that's what the debug LEDs on some motherboards are indicating, the start of the race.

What the post is missing then, for starters, is

"WHAT PREVENTED THE POWER FROM COMING ON?"

Note that bad RAM does not stop PS_ON# from being asserted. The RAM could certainly have a dead short on it, it happens on ceramic bypass caps on "untested" products. Some DIMMs come out of the soldering machine and are put in bags, as a measure of stupidity. Quality products need at least a small initial test for rail shorts, even if no lengthy "MEMTEST" is run.

The story lacks convincing detail.

Sure, there are details about integrated graphics versus the RX6600 I didn't know you'd installed. If I'd known that, I would have told you to remove it. Debug benefits from onion skin and building from a debugged core. You remove as much extraneous crap as you can, making for the simplest of test cases when breathing life into your monster. If the

Some motherboards disable the internal graphics core, if a PCIe vid card is detected, on the assumption it is running things. But you can also go into the BIOS screen when everything is working, and switch off the internal graphics so the 256MB to 4096MB of RAM it "stole", can be released. The more RAM you have, the more it steals. If you had a single 4GB stick installed, then it would only grab a small chunk. Turning it off, returns the small chunk so an OS can use it.

it's possible SPKR was not connected. This could be why there "wasn't enough feedback coming from mobo".

Sometimes, the "pitch" of the computer case connectors do not match the connector. On one of my case wiring bits, I had to move a pin from slot 3 to slot 2, by lifting the plastic tab that allows backing out the pin. Then the connector would mate with the new mobo header. SPKR is a 1x4 connector, typically. Usually it becomes obvious during FP fitting, that something is wrong with the pitch on one of them.

I cannot tell from the graphics description, why we moved the cable. Whether the integrated had switched itself off, or, whatever. Normally, by starting by using the integrated, you have time to familiarize yourself with the (not documented in the manual) choices of

Integrated graphics Auto | Off

Auto implies the integrated graphics switches off when the RX6600 is present.

Paul

Nope, not with the power on beep and fans running.

Yep, and some fan running.

Its likely the standard AMS post code.

But he should have got a startup beep and atleast the cpu fan running.

But I can't see the original *.linux.mint posts so it isnt clear if he spelt out exactly what he meant by "won't start"

Is it clear that it didn't ?

Yep, tho I haven't seen the orignal posts.

But the cpu fan should have started.

I think in some motherboards you could set the primary boot video to be either the onboard video or via teh PCIe video card.

Mind you, I have personally come across situations where a PCIe graphics card would work in any PC that did not have the UHD630 onboard video.

As soon as the same graphics card was plugged into a mobo with UHD630 grpahics, it was not possible to have both working at the same time with the correct sets of drivers... You had one working with correct drivers and the other using somethign akin to safe mode drivers.....

In fact this machine I am writing this post on has UHD630 graphics on board that I can't use as there is a AMD Radeon R9 200 series GFX card with 3GB RAM.

I know the AMD card is very long in the tooth, I do plan to replace it when graphcis card prices get lower... :-)

The P.O.S.T gave 3 beeps when either both or just the duff stick was in.

But it could do that, because it powered up for you.

At one point, it was not powering up.

Then... something changed.

Paul

A long time ago, AGP had GART (Graphics Area Translation Table ?). "You could only have one of those" was the wisdom at the time. That may have been one of the reasons for having "Auto" behavior and having one GPU shut off.

When PCIe came along, some sort of scheme which was not GART was used as a replacement (it would be a scheme for texture transfer from system RAM, for games). There seemed to be no rules for that.

The machines really should allow multiple GPUs to be present in the machine, and have the machines still work. While there is a 256KB table in the 640KB ("Bill Gates") area, for shrinking config ROMs from the various boards, I don't know if that is still an issue or not.

Another issue, is there are two standards at work for config ROMs. The newest one is GOP and is part of UEFI or something. At one time, a few cards, you could buy the card with the legacy format in the EEPROM on the board, but you could download the GOP version from the manufacturer. Later, only GOP shipped in the card. Again, this may be intended to support more than one card, rather than being something that restricts card usage.

I believe the "UEFI" tick box here, indicates a GOP config ROM is on the video card (or supports the video silicon). If UEFI is not ticked, then it could be a legacy VESA config ROM. Just about all video cards in the old days were VESA compatible -- only a couple Matrox cards seemed to be busted (made incorrect images during BIOS POST or something).

Paul

You are right. The miracle worker claimed that either the eight-pin power cable to the graphics card or the motherboard was of the wrong type becsause it had PCIe stamped on it. As far as I could see all those with the same number of connections did too.

He seemed to be fiddling with one set that had a six-pin plus a two-pin and held them together before inserting them. Either way, he got it started.

Alan

The auxiliary EPS12V power to the motherboard and the PCIe power cables to the GPU are both 8 pin, but have different notches on them - you shouldn't be able to insert one in the other unless you force them in hard.

Sometimes the EPS12V comes in 4+4 and the PCIe in 6+2 format, which support devices which only take 4 pin or 6 pin connectors - the two halves latch together to make an 8 pin connector.

If you have a modular PSU, vendors often use similar connectors on the power supply end of such cables in some non-standard fashion - depending on what they used, I suppose it may be possible to get them the wrong way round (ie connecting the end that should go into the PSU into the motherboard, and so making a connection you shouldn't be able to).

Theo