My Google Pixel C tablet is nearing the end of its life.

One of the facts which I did blog about was that, around April of 2017, I had purchased a Google Pixel C Tablet, which, in the meantime, had an O/S Upgrade to Android 8.1.0. That tablet is nearing the end of its life, and it’s barely 3 years old.

Firstly, it has not been receiving any system upgrades since 2019.

Secondly, as of a few months ago, it has started the behaviour of ‘spontaneously rebooting’ every few weeks, even though all I’ve been doing with it was, to keep it idling.

Some people tend to dismiss this behaviour of certain Android devices, just spontaneously to reboot, as if it was insignificant. But to the contrary, I tend to look at this as a crash each time, just as if a PC running Windows had suddenly received a Blue Screen. It can be caused by several things, but in this case I’m afraid, it might be a hardware problem, especially, since I have not been installing much software on it, nor receiving System Upgrades, at least, in the recent months.

Therefore, I am looking for a replacement, Android, Tablet.

BTW, The dedicated keyboard that came with this tablet has continued to work, to this day. I guess that I was lucky, not to receive a keyboard with a degraded built-in battery.


 

(Update 5/13/2021, 20h30: )

As of yesterday morning, this tablet has finally bitten the dust. Suddenly, its welded-in battery can no longer hold a charge, after being fully charged, for more than a few hours, before going completely flat. What I find remarkable about this has been the fact that, at least under my care, the KB battery didn’t die before the tablet’s built-in battery did.

I wonder whether this early demise of the battery may have been due, to my often having left the tablet plugged in for very long hours, to get a full charge each time,?

 

Dirk

 

Continuing to Troubleshoot my Graphics Chip

The computer named ‘Phoenix’ has now been running for 6 days and 19 hours. It is approaching the point, where recently it used to crash. I have suspected that my GeForce 6150SE graphics chip might be the problem, and that more specifically, this might have happened, because the graphics chip is only supposed to take 128MB of shared RAM according to the BIOS, but according to which it has been allocated 256MB, by the Linux software. It is an outdated graphics chip, which I have written about here.

Under Linux we have numerous tools that give us information about our machines, including the ‘KInfoCenter’ here:

phoenix_ram_2

I have already written that I cannot take the 70MB of shared RAM as an exact figure, of how much VRAM the chip is taking, which is actually system memory in this case, because there could be other processes using shared memory in some way. Yet, this is still an approximate estimate, and, since the amount being indicated is 70MB, the total amount of shared memory taken by my graphics chip, cannot be greater than 71MB.

This basically rules out one hypothesis for what might have been happening. Under normal use, the chip will not need more than 128MB.

Now, the fact that I have installed a new case fan, may or may not protect me from future crashes, since my other main hypothesis was, ‘Something could have been overheating on the motherboard.’

(Edit 02/14/2017 : )

And this is what my shared memory looked like today, 8 days and 23 hours after the latest reboot:

phoenix_ram_3

( 59+ MB – Stable )

Dirk

 

I question the amount of VRAM on Phoenix.

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:

phoenix_ram_1

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.

Continue reading I question the amount of VRAM on Phoenix.

NoMachine NX

When people connect to their VPN, this could simply allow them to access shared files. But alternatively, this could also mean that they wish to create a virtual session, on the remote desktop of one of their servers. The latter exists under the terms VNC, RDP, XRDP, and several others.

On my main Linux server named ‘Phoenix’, I have the XRDP service installed, which is the Linux equivalent of RDP. But one main drawback of this method, of remotely accessing a desktop, is the fact that XRDP does not allow file-sharing, specifically in the version of this protocol that runs out-of-the-box from the package manager. I have read that certain custom-compiled versions support this, but do recall that this service is a mess to custom-compile, and to set up in such a way that it runs reliably. So I stick to the packaged version for now, and do not obtain file-sharing.

There exists a closed-source application named NoMachine NX, which we could use to bridge this gap. But while their paid software subscriptions are very expensive (from my perspective), their Free software version has some big disadvantages.

First of all, even their Free version can be run in client or in server mode. I think that this is terrific. But in server mode – which affords access to the local machine desktop from elsewhere – there is no built-in support for SSH protocol. There is only the unencrypted NX protocol, for which their service listens.

Secondly, not every computer is strong enough to run NoMachine NX in server mode. On the computer ‘Phoenix’ I have a fragile X-server, and this service has actually crashed my X-server. Not only that, but allowing this service to run on reboot, consistently prevents my X-server from starting. It gets its hooks into the session so early on boot, that the X-server crashes, before the user is even asked for a graphical log-in.

On the plus side, there are ways of solving both problems.

Continue reading NoMachine NX