Category Archives: Linux

Fixing unhandled instruction bytes error Running Valgrind on AWS CodeBuild

October 18, 2019 joekiller

When running Valgrind against one of our C libraries we encountered some discrepancies in the build where locally all would pass but on AWS CodeBuild using the aws/codebuild/standard:2.0 image we would get errors like:

vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7D 0x48 0xEF 0xC0 0xC5 0xF9 0x2E 0x45

The full message was like:

==16128== Memcheck, a memory error detector
==16128== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==16128== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==16128== Command: /root/build/meh/test/.libs/state
==16128== 
[==========] Running 2 test(s).
[ RUN      ] test1
vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7D 0x48 0xEF 0xC0 0xC5 0xF9 0x2E 0x45
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==16128== valgrind: Unrecognised instruction at address 0x1173bd.
=...
==16128== Your program just tried to execute an instruction that Valgrind
==16128== did not recognise.  There are two possible reasons for this.
==16128== 1. Your program has a bug and erroneously jumped to a non-code
==16128==    location.  If you are running Memcheck and you just saw a
==16128==    warning about a bad jump, it's probably your program's fault.
==16128== 2. The instruction is legitimate but Valgrind doesn't handle it,
==16128==    i.e. it's Valgrind's fault.  If you think this is the case or
==16128==    you are not sure, please let us know and we'll try to fix it.
==16128== Either way, Valgrind will now raise a SIGILL signal which will
==16128== probably kill your program.

The error seems to indicate that the architecture doesn’t seem to match what the docker image had so going off of a Linux Headers Reinstall article we added the following and then the architecture packages were fine.

apt upgrade --fix-missing -y && apt autoremove -y && apt autoclean -y

Arch Linux, Linux, Tech Support

EDID Reading on Arch Linux

April 13, 2019 joekiller

There are several tools to read the Extended Display Identification Data, EDID, from systems but I found LinuxTV’s edid-decode the most thorough when debugging for a linux 5.0.x display boot flicking problem.

On arch I ran installed edid-decode-git and then ran a quick script:

for f in `find /sys/devices -name 'edid'`; do sudo cat $f| edid-decode;done

and I got something like:

EDID version: 1.4
Manufacturer: BOE Model 65a Serial Number 0
Made in week 1 of 2015
Digital display
6 bits per primary color channel
DisplayPort interface
Maximum image size: 34 cm x 19 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4, YCrCb 4:4:4
First detailed timing includes the native pixel format and preferred refresh rate
Display x,y Chromaticity:
  Red:   0.6416, 0.3437
  Green: 0.3183, 0.6103
  Blue:  0.1494, 0.0439
  White: 0.3125, 0.3281
Established timings supported:
Standard timings supported:
Detailed mode: Clock 139.770 MHz, 344 mm x 194 mm
               1920 1968 2000 2080 hborder 0
               1080 1083 1089 1120 vborder 0
               +hsync -vsync 
               VertFreq: 59 Hz, HorFreq: 67197 Hz
Detailed mode: Clock 111.820 MHz, 344 mm x 194 mm
               1920 1968 2000 2080 hborder 0
               1080 1083 1089 1120 vborder 0
               +hsync -vsync 
               VertFreq: 47 Hz, HorFreq: 53759 Hz
ASCII string: J125V
Manufacturer-specified data, tag 0
Checksum: 0xa9 (valid)

This helped when trying to diagnose: black screen on Dell XPS 15 with kernel 5.0 and Bug 109959 – REGRESSION: black screen with linux 5.0 when starting X

Linux, Tech Support

Linux Client VPN using Meraki Cloud Controller authentication

February 7, 2018 joekiller 1 Comment

If you want to VPN into your network using the Meraki Cloud Controller the Client VPN Instructions indicate that you may be out of luck when trying to use xl2tp.

Note: The xl2tp package does not send user credentials properly to the MX when using Meraki Cloud Controller authentication, and this causes the authentication request to fail. Active Directory or RADIUS authentication can be used instead for successful authentication.

It turns out that if you setup the IPSEC phase1 and phase2 algorithms then it’ll work.

It took some googling to bring it all around but combined with the Project network-manager-l2tp Github issue 34 of “IPSec options hard coded” and the Ubuntu question “L2tp IPSEC PSK VPN client on (x)ubuntu 16.04“, I found that setting IPSEC Phase1 Algorithms to 3des-sha1-modp1024 and Phase2 Algorithms to 3des-sha1 works.