Another possible reason, why my Google Pixel C might have started crashing.

One of the facts which I posted about recently was, that My Google Pixel C Tablet had started crashing, roughly every one or two months. Because I haven’t really installed any new software on it, and because the most recent System Update took place sometime in mid-2019, I had assumed that the recent malfunctions could be due to some sort of hardware problem.

The fact that this tablet, which I only bought in 2017, was starting to become unstable, was partially also, why I have recently acquired a Samsung Galaxy Tab S6 tablet, as an eventual replacement.

But, there is in fact another possible explanation, for the crashes of the Pixel C. Until 2019, that tablet had received System Updates roughly once every month. It might just be that, due to many memory leaks, that tablet really needs to be rebooted once per month, and if nothing else, System Updates also resulted in soft reboots. The failure to perform any soft reboots, may be what’s leading to hard reboots. Only, hard reboots are dangerous, because too many of them can lead to file system corruption.

In that regard, I’m hoping that the new Tab S6, which has Android 10 installed, will offer a possible preventive measure, in the fact that it can be scheduled in advance, to reboot automatically, let’s say once per week. If that feature works out as expected, then the tablet in question may indeed last longer than the Pixel C did.

Really, I think it strange, that an Android tablet would crash – or hard-boot – because it was not soft-booted for more than a month. After all, my phones, also being Android devices, have usually been able to run for more than 2 months, without requiring any reboots, and when those finally do receive a soft-boot, it’s part of their System Update.

Dirk

 

My Galaxy Tab S has just Succumbed to File System Corruption.

One fact which had remained a reality in my life, was that I still owned a Samsung Galaxy Tab S, First Generation (Android Tablet). This mere fact was actually what prompted me to acquire a Pixel C Tablet some time ago, since we must eventually plan for the failure of old technologies.

At the same time I’ve mentioned the subject often, that when a computer is interrupted from running, so that it needs to reboot, but without having been given proper shutdown instructions, or without otherwise having carried out an orderly shutdown, this is known as a Hard Boot, and it can lead to File System Corruption. Actually, every Hard Boot is a File-System Event, which the drivers for the mass-storage device try to resolve to the best of their ability.

The way in which the mass-storage drivers typically repair FS corruption, is just to delete whatever file-fragments, whose meta-data is inconsistent, until the File System is consistent again. In some cases, critical files can end up just missing.

Well it just happened to me today, that my Samsung Tab S underwent a Hard Boot, and that unlike the previous times, this time it led to severe File System Corruption. This has left my Tab S in a state where it cannot be used anymore, and since other Computer Experts do not know about the existence of File System Corruption, I see no way to make that old tablet operational again.

That old tablet, sadly, must now go into my Tablet Graveyard. It has served me well until this morning, but is essentially a lost cause now, just as my Toshiba Thrive was, years ago. May the tablet be remembered for good deeds.

Dirk

 

Why a Hard-Boot is often Overkill.

In order to understand this posting, the reader first needs to understand something, about how the (volatile) memory in a computer is organized. Through the use of virtual addresses, it gets organized into user-space and kernel-space. User-space includes programs that run with elevated privileges, but also the GUI-programs that display widgets and the like on the screen. Kernel-space is reserved for the kernel of the O/S, as well as for kernel-modules, that act as device drivers in practice.

But in addition to that, modern architectures also have I/O chips – which the kernel modules would be responsible for – that run “firmware”. These more-complex I/O chips will often perform complex tasks, such as the encryption built-in to Bluetooth, without requiring that these tasks run on the CPU, or in RAM. In order to do that, I/O chips capable of doing so need a smaller program of instructions, that actually run on the I/O chip. This program is typically no longer than 1-2 KB.

(Edit 06/09/2017 :

I suppose the fact should also be acknowledged, that in order for the firmware actually to do anything, the I/O chip should also have a somewhat larger region of memory – call it a Buffer – which stores data and not code. In the case of an intelligent Bluetooth chip, that buffer would logically store whatever encryption keys are currently being applied to data, which is being streamed to and from the chip… )

So in practice, a situation which the user can run in to, is that by unpairing all his (external) Bluetooth devices, and then turning Bluetooth Off from the settings GUI, and next turning BT back On, he can Fail to Reset the Bluetooth system to its original state. The user only gets to see what the GUI is showing him – which is being controlled by programs running in user-space.

What the user may not realize, is that the way kernel-space is often organized, turning Bluetooth Off in user-space, will fail to unload the kernel-module itself, responsible for operating the Bluetooth Chip, that has firmware running on it, for the sake of argument.

The actual kernel-modules first load when the computer boots up, and the first thing they do, if they are of the sort that use firmware, is to load that firmware onto the I/O chip – and it’s often patches to the firmware that get loaded, because the default firmware is burned-in to the I/O chip.

Continue reading Why a Hard-Boot is often Overkill.

Pixel C Keyboard Pairing Problem – Solved.

I own a Google Pixel C Tablet, which I did order with its recommended, accompanying Bluetooth Keyboard. I’ve been using it with a lot of fun for months now. But yesterday evening, the problem finally happened to me, which I had been contemplating, which was, that I had spent such a long series of hours using them, into the night, that the keyboard actually went dead. I mean, the batteries of the KB could not live as long as my session would have, and pressing keyboard keys eventually had no more effect on the tablet, as the pressed keystrokes were no longer being received. So what I did was to close the tablet over the keyboard in the recommended way, to plug the two in to have them charge, and to leave them that way overnight.

Next morning, I wanted to find that not only the tablet charge was back at 100%, but that I could just step in and start using the keyboard again. But what I found, was that the tablet – with its battery at 100% – was still unresponsive to the keyboard. So my first conclusion was, that the state of the Bluetooth Pairing, was somehow corrupted on the software-level, between the tablet and the keyboard. So I followed ‘The usual, basic steps, to re-pair the two':

  1. Separate the tablet from the keyboard. The on-screen keyboard will become available.
  2. On the tablet, go into Settings -> Bluetooth, tell it to Forget all Bluetooth Pairings, and turn Bluetooth Off.
  3. Re-Attach the tablet to the keyboard, and watch the tablet ask me to turn Bluetooth On. Do so.
  4. Wait for the Tablet to show me the PIN-number, which I am to type into the keyboard, to make them pair.

The next problem was, that Step (4) above wouldn’t happen. So my next thought was, that one of two things could finally be wrong with my keyboard:

  • The charging system / KB battery could genuinely be defective (Unlikely, as they are virtually still new, and were working before).
  • The logical corruption in the Bluetooth Pairing State, between the tablet and keyboard, could be more-deeply corrupted than I thought, from the broken-off session the previous night, maybe even at the Firmware Level.

So now I proceeded with ‘A more-robust procedure, which amounts to resetting the keyboard, as there does not exist a more-proper, explicit way to reset that keyboard':

  1. Separate the tablet from the keyboard.
  2. On the tablet, go into Settings -> Bluetooth, and tell it to Forget all Pairings / and turn Bluetooth Off.
  3. Soft Boot the tablet.
  4. After the orderly reboot has finished, Go To Step (3) in the more-basic procedure above.

And what I found next, was that after I had allowed the tablet to turn Bluetooth back On, it did in fact greet me with the 6-digit PIN-number, and after I typed that into the keyboard, and after I had hit Enter on the KB, the keyboard worked fine again.

Yay!

Now, there exist people who claim, that they tried all the steps above, numerous times without success, but that “Suddenly, the keyboard started working again.” To the best of my understanding, what must really have been happening to those people, is that they did try all the above steps, but ‘Maybe not in the correct sequence?’

Dirk

(Edit : )

Even when there is no malfunction taking place, I never try to reboot my tablet, with the BT Keyboard connected.

My best guess for what goes wrong with this KB, would be that it keeps its local store of information, with its encryption key, as a volatile (RAM) chip, with no backup power-supply. It lacks a non-volatile chip to store that. Hence, when the battery goes fully flat, its encryption key is corrupted, and depending on the extent to which encryption is hardware-based these days, it can also leave a trace in the firmware of the tablet itself, that the tablet was paired with it. Hence the reboot needed.