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.