Ryzen PC Backup

I finally decided to perform a backup of my new Ryzen PC running Fedora 26. Normally I wouldn’t leave it too long between backups especially if I have made significant changes. My new PC presented me with a little bit of an issue, I couldn’t run my backup software.

I tend to use Clonezilla to take/restore system images. I’ve used it for years and it has been working well for me. That was until I tried to boot it on my Ryzen system. It was hanging with tpm_tis and tpm_crb errors.

The arch wiki states that “Support for TPM 2.0 is still incomplete (both on the kernel and in userspace), and no known work flow for TPM2 exists at the moment.”

It would appear that I had enabled the TPM option in the bios and I have TPM 2.0 hardware.

The Workaround
Clonezilla 2.5.2-20 (Debian – Kernel 4.11.11-1+b1)

  1. Disable TPM in the bios.
  2. Boot from a CD (non-uefi) and run Clonezilla in graphics safe mode.
  3. Having successfully booted Clonezilla, perform backup as normal.
  4. On completion of the backup re-enable the TPM hardware in the bios.

Fedora 25

This evening I arrived home from work and began to update my machines to the latest version of Fedora. I am pleased to say the update has gone smoothly. This has been the easiest update I think I have had in recent years.

Now the bad. Wayland has become the default display server replacing X11. It works, by which I mean I have a usable display. The bad is that it has broken my workflow. I have a few simple scripts that tweak my environment. These have always loaded when the display server starts. Ok, how do I do this with Wayland? I did some reading. The issue has been known about for 2 years, Bug 736660. The workaround for the moment is to logout and then log in with an X11 session. Logging into the X11 session everything works again and I can continue. Hopefully issues like this will get resolved quickly.

Fedora 24

This week I have been updating my machines to run Fedora 24. Two out of 3 updated without any issues and continue to run normally. One machine however has decided to cause me some issues.

My old Toshiba X200 laptop had followed the upgrade instructions to the point where it needed to reboot. So I rebooted the machine and left it to do its work. Returning some time later expecting it to have completed I was disappointed to see it stuck doing nothing. After some investigation it appeared I was getting an error to do with an Invalid PCI ROM Header, the value didn't match what was expected. I couldn't boot the machine without this occurring and left me scratching my head for a bit. There doesn't appear to be an obvious solution online. Others have reported similar issues but apart from seeing the error their machines have fully booted.

I decided to try adding a few flags to my kernel boot parameters. Finally I go one to work. Adding "pci=norom" seems to have done the trick and allowed the machine to continue to update. I won't know until the upgrade is complete if I will need to add this option back in permanently. But hopefully it won't be anything more than that.

The Rodent Battle – It’s not over yet

In my previous post at the end of July I had resorted to calling in the Rat Man to assist me in my struggle. When that failed to show results I detailed my nuclear option of removing all of my loft insulation and denying the rodents access.

The button was pushed. I have spent many hours removing all the insulation. It's not an easy or pleasant task but there is no place left to hide. The entry points were filled with steel wool held in place by more expanding foam. You do get some funny looks bulk buying expanding foam but it all got used.

All has been quiet in the loft for the past few weeks. All that is left to do is have a proper clean up of rodent droppings, repair of eaten network cable and re-insulating before winter.
Everything has been going to plan.

Until today. I was sat at the computer catching up on a few podcasts when I heard the noise. The noise that has kept me awake at night, the noise that caused the pressing of the nuclear button. The sound of the rodent scratching about. The precise location I am uncertain about. I suspect that it is not from the loft, unless it has been enjoying its diet of steel and foam. By my estimation the noise is from the cavity wall above the window. I am guessing that little Ratty not being able to ascend to loft level has decided to compromise by setting up home atop the lintel over the window.

How I proceed at this point is uncertain. I need to insulate the loft for winter provided it is still secure. But it appears that a peaceful nights sleeps is not going to be an option in the short term. A new plan of attack is required.

Damn You ISR!

I am sat here on a Sunday evening trying to debug embedded C/C++. For the most part all has been going well and the code has been behaving as expected. I have however run into one of my least favourite problems, the interrupt service routine (ISR). I have a couple of ISR's and they are presenting an unexpected start-up condition. The flow of the main body of the code is fine. I just can't understand why I am getting the current output.

All these problems take me back to a traffic light program I wrote at University. That worked fine for most of the sequence only to be tripped up by an ISR along the way and ending up in a stuck state. Not what you want from a set of traffic lights, especially if you find yourself stuck in the queue behind the red light.
Luckily there wasn't a green light & green man situation with the pedestrians finding themselves in the role of Frogger.

Only one solution for this situation; single malt.

The Rodent Battle

This month I finally called in the Rat Man to rid me of the menace in the loft. He managed to attend 2 out of the 3 scheduled visits. Having time off work and his no show did not go down well. In any case the traps are being avoided but they do like the additional bait they are being provided with. So after 2 visits and not hearing any movement above me I was a little happier. This evening however, following yesterdays no show, I hear scurrying once again. So in summary I have had 3 afternoons off work for no improvement in the situation whatsoever.

I am getting very close to the nuclear option of stripping out all the loft insulation and permanently denying them access by any means necessary (even if it means taking the roof off). It nibbled though my network cable and I have a zero tolerance approach to network intrusion.

6/7

RatBag
A six pack of rats.

To battle the rodent menace I have 7 traps in my loft. Yesterday I went up to check them; 6 were full. Of the 6, 5 suffered a quick demise through a direct head strike. One unfortunate victim was caught by the tail and eventually passed away from probable starvation/dehydration after a struggle with its surroundings.

In an additional observation one of the head strike victims appeared to have had its hind leg eaten off.

SPI Bus Problem Solved

SPI_Protocol_Decode
SPI_Protocol_Decode

This image is the result of a week of pulling my hair out. It is a simple read of a register on a device connected to a micro controller over an SPI bus. The protocol was simple, the code driving it was simple, but until today it refused to work. I had checked the connections, the component values, changed some of the hardware but wasn't having much luck.

The time came to get it onto the oscilloscope. I treated myself to a Rigol DS1054Z a few months ago and it has proved its worth already. Having access to a 4 channel scope with protocol decoding has allowed me monitor the bus and find my fault. The scope revealed that the SPI MISO line was signalling the same as the SPI Clock. It turned out I had a tiny solder bridge between some header pins on a break out board, never would have thought to look there. After removing the solder bridge I now have a working SPI bus. Now time to do something with it.

Cooling Things Down

Summer is approaching and the weather is getting slowly warmer. This brings with it the annual problem of having a computer in the bedroom kicking out heat and making it too warm. Another issue that had been causing me some bother for a few years is the power settings on my graphics card, a Radeon HD6850, when running Linux. I use the open source radeon driver as keeps improving overtime and has enough of the performance of the closed source official driver for my needs. The one thing that has been lacking in my particular case has been the dynamic adjustment (radeon.dpm) of the card to keep it running cool. I have been forced to manually set the card to a low power state each time I reboot the machine. Failing to do this means the card boots up running full speed and quite happy to warm the place up. The downside is that I am always in the low power state and any tasks that might make use of a bit of extra power never get it unless its specifically enabled.

Today was time for a bit of research and a test. I had a Radeon 7850 in my other machine and decided to swap them over. It means that I have a weaker card for gaming on Windows but I don't play that many games and out of the two machines it is the one next due an upgrade. So has it made a difference? The simple answer is yes. I found that after rebooting the Linux machine with the HD7850 that it had automatically switched to using the dynamic adjustments and all was working well, one problem solved.

The heat output was the thing I really wanted to improve and I am pleased to also report a successful change (results below). I am happy with a slight decrease in temperatures along side the enabling dynamic adjustment. I continued to experiment and discovered that it can get even better. I have 2 24" Dell monitors and these can both kick out a bit of heat. Whilst I like a dual screen setup I often switch to just one (mainly to boot the Windows machine on the other). Driving just a single monitor I have noticed a further drop in temperatures (results below). This apparent temperature drop with a single monitor was not noticed when using the HD6850.

Test Conditions:
- Ambient Temperature: 22C
- System settled on normal desktop, no user activity.
- 2 connected displays @ 1920x1200

Before (HD6850 in Low Power Mode):
- GPU Temp: 65.0C
- CPU Temp: 41.4C

After (HD7850 radeon.dpm=1 balanced profile dual display):
- GPU Temp: 47.0C
- CPU Temp: 37.1C

After (HD7850 radeon.dpm=1 balanced profile single display):
- GPU Temp: 39.0C
- CPU Temp: 36.0C

An upgrade to some slightly newer, better driver supported hardware can result in a gpu temperature drop of around 18-26C (depending on setup). It might not make a huge improvement in room temperature alone, but it is a step in the right direction.

Tmux – Solving The Problem Of Window Names

I was lucky enough to get a book on using tmux for Christmas. Following through the examples I noticed that I was not getting the expected behaviour when attempting to set window names.

Commandline

1
$ tmux new-window -n console

What this should do is create a new tmux window and within it a window called "console". What I was getting was a tmux window containing a window named after my command prompt e.g. 'bob@computer ~'. This was bothering me so I set about researching the problem, unluckily for me its not one that is that common. By chance I located a post linking to a RedHat bug report https://bugzilla.redhat.com/show_bug.cgi?id=969429. The report outlines a problem regarding a change in terminal escape codes and highlighted an identical problem with screen as I am having with tmux. I checked the escape codes in my .bashrc file, nothing wrong there. Next stop was /etc/bashrc.

/etc/bashrc

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
  if [ -z "$PROMPT_COMMAND" ]; then
    case $TERM in
    xterm*|vte*)
      if [ -e /etc/sysconfig/bash-prompt-xterm ]; then
          PROMPT_COMMAND=/etc/sysconfig/bash-prompt-xterm
      elif [ "${VTE_VERSION:-0}" -ge 3405 ]; then
          PROMPT_COMMAND="__vte_prompt_command"
      else
          PROMPT_COMMAND='printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"'
      fi
      ;;
    screen*)
      if [ -e /etc/sysconfig/bash-prompt-screen ]; then
          PROMPT_COMMAND=/etc/sysconfig/bash-prompt-screen
      else
          PROMPT_COMMAND='printf "\033k%s@%s:%s\033\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"'
      fi
      ;;
    *)
      [ -e /etc/sysconfig/bash-prompt-default ] && PROMPT_COMMAND=/etc/sysconfig/bash-prompt-default
      ;;
    esac
  fi

/etc/bashrc contained the above code section. It comprises two different sections for different terminals, each has its own prompt with different escape codes. The but report highlighted that the problem lay with the 033k escape code where as 033]0 worked. I should only be using the problematic escape code if I am using a screen terminal. So which am I using?

Commandprompt

1
$ echo $TERM

The result from running the above command in my gnome-terminal was "xterm-256color". This was expected and what I assumed I was using. Running it from inside a tmux session I got "screen-256color". Tmux using a screen terminal is pointing back to the problematic escape code. Time to go back to the .tmux.conf and check my settings.

.tmux.conf

1
2
# Use 256 term colours
set -g default-terminal "screen-256color"

There is my problem line, I have set it to use the screen terminal, oops.

.tmux.conf - Correct

1
2
# Use 256 term colours
set -g default-terminal "xterm-256color"

By using the xterm-256color terminal I correct the problem with the escape code. Rerunning my initial tmux command tmux opens with a window named 'console'. Problem solved.