I am still contemplating, why the server-box I name ‘Phoenix’ was crashing, and my attention keeps coming back to the graphics chip. Before this computer was resurrected, it was running in 32-bit mode, as ‘Thunderbox’. At that time, it only had 2GB of RAM. But now it runs in 64-bit mode, with 4GB of RAM.
When I boot, the BIOS message still tells me that it has 128MB of shared memory, for the graphics chip. But strangely enough, the piece of text I pasted into this posting, reads that the graphics driver has set aside 256MB of VRAM, near the top of the 4GB of physical addresses. I did not know that the kernel can override a BIOS setting in this way, let us say just because processing has been switched to 64-bit mode.
One mishap which could naively go wrong, is that the legacy driver, unaware of the specifics of this motherboard, could be allocating 256MB of shared memory, but that physically, the hardware cannot share past the address ‘0xe7ffffff’. That is, the address ‘0xe8000000′ may have become forbidden territory for the graphics card. It is however uncommon, that the programmers of kernel-space modules, would make such a simple mistake.
This is a 64-bit system, which only accepts up to 4GB of RAM, thus only possessing 32-bit physical addresses, to go with its 64-bit virtual addresses.
According to this screen-shot:
I only have 3.74GB of RAM available to the system, instead of 4GB. The reason for this, is the fact that 256MB have in fact been reserved for the graphics chip. By itself this would seem to suggest, that the allocation has succeeded.
Also, the fact that 49.26MB of shared memory was momentarily being indicated, is not too telling, because several types of processes could be using shared memory for some purpose. This feature does not only exist, for user-space processes to make texture images available to the graphics card.
There was an action required on my part, to follow up on this subject. I needed to go into my BIOS settings, and verify whether I had an option there, to enable 256MB of graphics memory, instead of 128MB. If there had been such an option, it would have been so long ago, since I even had a visit to my BIOS settings, that I would not have remembered such a detail today.
But alas, the information displayed there does not give me such an option. It only has, grayed out, “128MB”. This means that I will not be able to resolve this issue through my own actions.
And, because I saw it necessary to go into my BIOS settings, I needed to reboot this computer, for which reason my Web-site and blog were offline again, but only for 10 minutes this time, from about 14h55 until 15h05.
I have an added observation on this note.
It can happen many times, that a client-application has created a drawing surface, which it sends as a shared memory segment to the X-server, so that it can be submitted for desktop-compositing, and so that it can be sent to the graphics chip as a texture image. And every time the application closes, it can fail to destruct these objects.
The ability of the X-server and / or kernel to clean up such wasted memory is much better – usually flawless – if there has been no hardware-level access violation.
However, if the VRAM accessed in hardware hits some unexpected limit, the ability of actual software to clean up such memory, becomes Nil.