I was creating tables like this on every node:

CREATE TABLE x (
id             SERIAL PRIMARY KEY,
content   VARCHAR(255) DEFAULT NULL
);

but decided after half of having those nodes I already configured to rename the table from ‘x‘ to ‘y‘ using the ‘ALTER TABLE‘ command

ALTER TABLE x RENAME TO y;

and continued creating the schemas on the remaining nodes with the following command:

CREATE TABLE y (
id             SERIAL PRIMARY KEY,
content   VARCHAR(255) DEFAULT NULL
);

After finally having provided the schema to all nodes I started the replication daemons and got thrown errors from half of the nodes that replication doesn’t work properly since the schema doesn’t match the one on the master replication server:

CESTERROR  remoteWorkerThread_1: “select “_db”.setAddTable_int(1, 3, ‘”public”.”y”‘, ‘x_pkey’, ‘Table public.y with primary key’); ” PGRES_FATAL_ERROR ERROR:  Slony-I: setAddTable_int(): table “public”.”y” has no index x_pkey

All of the non-working nodes were those, I first created the table x on and later renamed it to y, instead of just directly creating table y like I did on the others.

Looking at the global table definitions – including the automatically co-created sequence – you can see that the table did get renamed, but the sequence didn’t:

Table y directly created:

postgres=# \d
List of relations
Schema |      Name      |   Type   |  Owner
——–+—————-+———-+———-
public | y              | table    | postgres
public | y_id_seq       | sequence | postgres
(4 rows)

Table x created and altered to be named y:

postgres=# \d
List of relations
Schema |      Name      |   Type   |  Owner
——–+—————-+———-+———-
public | y              | table    | postgres
public | x_id_seq       | sequence | postgres
(4 rows)

That normally doesn’t cause any trouble, since the reference of table y (formerly x) to the sequence x_id_seq is still valid. However since replication requires the very exact same schema on every node this actually is causing trouble. However that’s not the error mentioned in the error message above, which is referring to the primary key.

Diff’ing the actual schemas shows up more differences:

                                  Table “public.y”
Column  |          Type          |                   Modifiers
———+————————+————————————————
- id      | integer                | not null default nextval(‘x_id_seq‘::regclass)
+ id      | integer                | not null default nextval(‘y_id_seq‘::regclass)
content | character varying(255) | default NULL::character varying
Indexes:
-    “x_pkey” PRIMARY KEY, btree (id)
+    “y_pkey” PRIMARY KEY, btree (id)

The reference to the sequence and and name of the reference to the value of the primary key were NOT updated by altering the table name to match again. This separation of table-name and references might be a feature, however I find it hard to imagine a use-case where it makes sense using the sequence and/or primary key of another table. UPDATE: I just got told that it indeed might make sense sharing one sequence among several tables.

Also sequence and primary key were created inside / co-created by the ‘CREATE TABLE‘ statement, so at least I’d find it more consistent if both would be always reference by this table, by means of the table they got originally created with.

Looking for information, hints or documentation about this behaviour wasn’t fruitful as well.

So personally I’d really like to really see those reference updated – by changing the tables name - automatically.  I’d like to see at least a NOTICE that primary key and sequence are still haveing the name of / are referring to it’s old values and need to be updated / re-created to match again.

Conclusion: Make sure – when altering table names in Postgres – references to primary key and sequence are getting updated as well – manually! Primary key and sequence are NOT tied together with the table they got created with!

In our case Qt accesses framebuffer as well as the LinuxInput devices directly – there is no further layer (DirectFB, Xorg, Wayland, etc.) in between.

In this quite common scenario I noticed that Qt is treating the LinuxInput devices in a quite counterintuitive way which may lead into severe security problems.
The embedded device we are using in this particular project has a keyboard which to the userland is exposed as LinuxInput device.

Everything worked quite well, however our Qt application crashed once due to a programming error (our fault) and I was shown the underlying UNIX console which reflected every single keystroke I did inside the Qt application – all typing input within the Qt application also got passed to other applications / underlying shells!

An exposed root shell to the active TTY – possibly hidden by the GUI – is therewith also capturing all input. Since almost all linux (embedded) distributions are exposing login prompts / shells to all TTYs by default, this scenario is far from being unlikely.

My expected behavior would have been: the Qt application is opening the LinuxInput devices exclusively, so that only the Qt application receives data from the input devices.

After some research and asking around I got pointed to the EVIOCGRAB IOCTL implemented in the LinuxInput subsystem.

As stated in $(LINUX_KERNEL)/include/input/linux.h:

@grab: input handle that currently has the device grabbed (via
EVIOCGRAB ioctl). When a handle grabs a device it becomes sole
recipient for all input events coming from the device

This means: When opening LinuxInput devices they’re not grabbed, they’re not opened exclusively by default.

Okay, I got it

So let’s just find the magic option / command which tells Qt to set up an EVIOCGRAB with an appropriate argument on the going-to-be-used LinuxInput device. Since I didn’t find any documentation I grep’ed through the Qt source:

> ~/src/qt.git$ git grep EVIOCGRAB
> ~/src/qt.git$

nothing… so I took a closer look into how Qt implemented support for LinuxInput devices (src/gui/embedded/qkbdlinuxinput_qws.cpp) – still nothing…

So I implemented support for telling Qt to open LinuxInput devices exclusively by optionally passing an ‘grab’-argument to the LinuxInput drivers inside Qt.

And here it is – a patch which adds support for passing another parameter named ‘grab’ to the LinuxInput device driver of Qt – to specify whether the device should be opened exclusively (grabbed) or not.

https://dev.openwrt.org/browser/packages/Xorg/lib/qt4/patches/500-allow-device-grabbing.patch?rev=26780

Conclusion: Take care when using Qt and its LinuxInput drivers – all input might be received and used by other applications as well – including shells running on TTYs.

UPDATE: The patch finally git committed and went upstream. Grabbing can now be configured since Qt version 4.8 (http://www.qt.gitorious.org/qt/qt/commit/947aaa79b05adec527c7500e36766c7ff19f118d/diffs)

In Linux the use of buses is tried to get as abstracted as possible – the idea is that the actual boards (or call it whatever you like as devices, platforms etc) define and expose the capability of buses and its properties.

In our case the rfm12 kernel module requires the availability of an SPI bus – it doesn’t matter how it is implemented (native SPI bus, SPI over GPIOs or any other way of implementation). The client module – the kernel module implementing an driver for the actual rfm12 hardware – simply doesn’t care and doesn’t need to know about that.

That’s the reason why the actual rfm12 code doesn’t contain any GPIO <-> rfm12 hardware mappings – the rfm12 code is just using an existing and otherwise exposed SPI bus.

The actual wiring / mapping and setup of the SPI bus is done within the platform / board / device code, which is located below arch/${ARCH}/${BOARD} – a common place for code like that is arch/${ARCH}/${BOARD}/setup.c.

This project however seemed to have raised some interest and I got asked quite a few times about the board specific changes I made – so here they are now:
the kernel patches which provide SPI buses on both boards, including GPIO mappings.

Since both targets I used the rfm12 module and driver on are running OpenWrt, I created both patches against the Linux vanilla tree having OpenWrt specific kernel patches already applied.

Changes however are small and clear, so they should be easy to understand and adapt.

The wiring I used to get the rfm12 module working on the NanoNote working by the way is the following:

GPIO | PIN on SD port | PIN on module | purpose / description
=====|================|===============|=================================
108  | D12 (1)        | MISO / SDO    | SPI: master input slave output
109  | D13 (2)        | nIRQ          | interrupt
104  | D08 (3)        | (unused)      | (unused)
X    | VDD (4)        | VDD           | power
105  | D09 (5)        | MOSI / SDI    | SPI: master output slave input
X    | VSS (6)        | GND (1+2)     | ground
106  | D10 (7)        | SCK           | SPI: clock
107  | D11 (8)        | nSEL          | SPI: chip select


There needs to be a resistor (10-100kOhm) between pin FSK (if used) of
the rfm12 module and VDD as pullup – however when just using ASK it isn’t needed anyway.

However while working on a certain project we recently experienced quite some issues debugging applications involving threads.

Debugging the application on my local workstation worked quite fine, however on OpenWrt-targets – ARM as well as MIPS – it behaved rather strange: stack corruptions, missing traces, weird signals got issued…

After quite some time of debugging the debug issue, we found out the issue is caused by a stripped version of libpthread.so.

Stripped – not in the sense of a more lightweight but compatible version of the pthread library – but stripped by the utility “strip”, which purges all debug- and “other unneeded” symbols out of binaries to reduce their size, which usually is applied on all binaries by the OpenWrt framework automatically.

Usually binaries stripped by “strip” are still fully-fledged binaries, still usable with GDB (however without debugging symbols available of course). Applying strip on libpthread.so* however, it seems to strip out also stuff needed by GDB following and tracing threads. Without these symbols / meta-information not needed for running the actual application, but for tracking its threads, GDB results in mentioned issues above.

One might ask why someone is debugging binaries without debug symbols compiled in – reasons are obvious:

• there’s not enough storage available
• there’s not enough RAM available
• using gdbserver and having the binaries with debug symbols compiled in on another machine communicating with gdbserver

To check whether an object got stripped or not is quite easy using the “file” util:

$ file build_dir/target-arm_v5te_uClibc-0.9.30.1_eabi/root-foo/lib/libpthread-0.9.30.1.so
build_dir/target-arm_v5te_uClibc-0.9.30.1_eabi/root-foo/lib/libpthread-0.9.30.1.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), stripped

$ file staging_dir/target-arm_v5te_uClibc-0.9.30.1_eabi/root-foo/lib/libpthread-0.9.30.1.so
staging_dir/target-arm_v5te_uClibc-0.9.30.1_eabi/root-foo/lib/libpthread-0.9.30.1.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

Long story short: When debugging applications involving threads, always use a non-stripped version of libpthread.so, even if debug symbols are not needed!

The rfm12 433MHz module, produced by HopeRF,  is attached to the microSD port of the Ben NanoNote, which pins are exposed via an microSD card dummy adapter.

rfm12 module attached to a microSD dummy

The System-on-a-chip used inside the Ben NanoNote (ingenic JZ47XX) allows us to put the microSD pins into GPIO mode, so we can (as already done for the first device, the Netgear WGT634u router, I connected an rfm12-module to) create and export an SPI bus on top of them to be able communicating with the module.

That way there’s no need of opening the device and/or soldering anything anywhere – the module is attached directly to the microSD dummy which gets simply inserted into microSD slot of the NanoNote.

rfm12 module attached to NanoNote running ncurses UI for switching power sockets

I wrote a basic but fully working ncurses frontend using the rfm12 library listing configured devices waiting for getting switched.

There’s also a ready-to-use XMLRPC daemon available which exposes all configured devices and provides functions for controlling them, so UIs for controlling devices are not limited to run on the same system the rfm12 module is installed on.

ncurses UI for switching configured radio controlled power sockets on the Ben NanoNote

I’ve also written a little GUI in python using the qt4 toolkit, connecting to the master via XML-RPC:

switching radio controlled power via a GUI using pyqt4

Several other frontends are work-in-progress as e.g. a GUI for the Android platform, as well as one based on qt4/QML being able to run e.g. on phones running Meego/Maemo as operating system – both using the XML-RPC interface.

So all major parts of the project are mostly finished now and the API is more or less fix.

The the whole project now consists of (a rough overview):

1. the kernel module which communicates with the actual hardware (so the rfm12 module) and exposes a character device to userspace
2. the rfm12 library which
• connects to the kernel module
• contains the device type specific data and code to modulate signals which control the actual power sockets
• provides functions for reading / writing configuration files and controlling / switching devices
3. applications using the library and its functions for actual controlling of devices, which could be / already are:
• UI applications linked directly against librfm12 (an ncurses frontend (shown above) is available yet)
• daemons providing network interfaces (a daemon exporting functionality via XMLRPC is available yet , one doing the same but using JSON-RPC as underlying rpc method is going to be implemented soon)
4. UIs running on different machines, using these RPC services  (e.g. above pyqt4  frontend; android- and qml-frontends are work-in-progress)

Devices are getting configured via configuration files, describing the product type of the device, a name and the actual code which is used to identify devices of a certain product type group.

The config used by the applications shown on the photos / screenshots above just looks this:

[socket_A]

label = “one”

product = “P801B”

code = “1111110000″

[socket_B]

label = “two”

product = “2272″

code = “1111110000″

[socket_C]

label = “three”

product = “2272″

code = “1111101000″

One of the tasks I’m working on right now, is state sharing. While the list of configured devices and it’s states (on/off) is already shared among all XML-RPC clients (so having switched a unit in one client, others will fetch the changed state next time they poll/refresh), the state is not yet shared between several processes invoking the librfm12.

Issue is: Every process linked against librfm12 creates its own list of devices, including states – so every process has its own copy. Changes done in one process are not shared among others. This could be solved using IPC (System V shared memory, sockets every instance connects to, etc.).

That’s it – feedback and/or participation is highly appreciated!

Ben NanoNote having an rfm12 module attached via microSD-port and several types of radio controlled power sockets

Source Code is still available on github: https://github.com/mirko/rfm12-ASK-for-linux

Short story long:

These radio modules are capable of sending / receiving over the ISM frequency band, as e.g. 433 MHz or 868 MHz and just cost about 5 Euros.

RFM12 module

RFM12 module soldered onto eval board

The idea was to get the module working on several embedded boards running Linux, e.g. routers, microcomputers such as the NanoNote, etc. via a generic software interface.

The rfm12 module is controlled via the 4-wire protocol SPI which basically is based on toggling pins between the machine’s logic-levels (high/low) at an individual non-specified clock-speed (http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus).

Since most of mentioned boards do not own a native SPI bus, but several GPIO’s (most LED’s are connected via GPIO’s on such devices), SPI can be “emulated” by toggling these GPIO’s in a specific way (also called “bitbanging“).

That way there’s no need for any other electronic peripherals such as microcontrollers, semiconductors, resistors, etc. – the chip is directly connected with the board – everything is done in software.

Inspired by the project “ethersex” – a project programming and maintaining a software for Atmel AVR micro-controllers used for home- / building automation – and an approach of soldering the module onto a specific router, communicating via SPI over GPIO’s (however used code is rather old, unmaintained and board-specific)  – the idea came up to write a generic linux kernel module to support the module from within linux directly.

Based on the ideas realised with the ethersex project, I decided to aim my project on being able to switch remote controlled power sockets of which I own several (to each other incompatible) modules.

Because the rfm12 module is (only) capable of doing FM (modulating payload data on top of the frequency), but lot’s of devices are controlled via AM (most remote controlled power sockets included), we emulate AM by simply turning the module on and off in a specific sequence.

Since this operation is timing critical and needs to be atomic, we need to do basic stuff in the kernel space rather than from userspace.

The whole project is going to consist of 4 major parts:

• the rfm12 driver as kernel module which provides an API (accessible via a character device) to the userspace
• an userspace library which contains all the information and protocol (meta)data for such remote controllable devices, providing an (more or less) generic interface and configuration of devices
• an actual application using the library, so controlling the devices – maybe exporting the available functions via RPC (json, xml, etc.) to provide network access
• a remote usable UI (for mobile devices as phones (android/meego), web-related, qt/gtk…)

My testing device is an old Netgear WGT634U I had in spare which has a broadcom 47xx SoC working in and 4 unused GPIO’s available.

RFM12 module directly connected to a Netgear WGT634U router

Implemented yet is support for the most common radio controlled sockets sold – the ones which have a 2272/2262 IC built in (including these Chinese versions which get on fire – http://ec.europa.eu/consumers/dyna/rapex/create_rapex.cfm?rx_id=142 #25) and the ones using an P801B chip.

radio controlled power sockets: 2272, P801B, 2262

I also have a set of radio controlled dimmers which protocol I’m going to implement soon…

For now the source code is hosted on github: https://github.com/mirko/rfm12-ASK-for-linux – there’s no project site yet but will be created if the project is growing / interest is getting raised

UPDATE: In case you’re willing to participate, you’re more than welcome! Just drop me an email… There’s lot’s of stuff I’d like to see implemented, especially usable (G)UI’s… but for sure it’s not just about me: patches, feedback, enhancements and feature-requests (in a certain extent) are highly appreciated!

I’ve been in Tanah Lot – an area where a rather famous temple of the same denominator is located. It’s kind of an island during high tide but accessible when tide is low.

Because of it’s formation, location and a spring of freshwater inside, a priest declared it as an holy place in the 15th century.

Seriously, it’s an amazing place (however flooded by tourists and locals trying to sell stuff).

After Tanah Lot I got back to Sanur, wanted to stay there just a few days and then move to the so called Gili islands…

…however unfortunately I got ill, got the Dengue fever.

I don’t want to elaborate my almost last 10 days on Bali, however it was everything but nice and I do not wish anyone getting this bloody fever – seriously…

Closing statement:

It was great (apart from the fever I got)!

Seriously, Bali is no place where you’re going to struggle in any way… the Balinese economy is based on tourism, so you can get there almost every (western) stuff – it’s everything but a survival training (assumed you’re not getting ill).

Bali is a perfect mix of paradise-like beach and sea (have a look at the photos posted a few posts below) and cultural experiences (despite the tourism the Balinese people try hard to keep and practise their culture) like their huge amount of temples, sacrificial offerings several times a day, performances, etc.

There is lot’s of tourism, and partially too much of it for sure (for example Kuta and surroundings) – however the locals are really lovely and open-minded, it’s quite easy to socialise and get in touch with them…

Sharing some time of their everyday life is a definite recommendation if you’re not just there for beach, sea and sun but interested as well in their daily grind and culture.

They are more than pleased to show you around, quiet interested in western politics, habits, views, etc. – answering your questions in exchange for yours

To those Balinese / Indonesian I met there, reading this:

Thanks you so much for the great time !!

Did so now and tried to respond to them – sorry for the delay and thanks a lot for your input/contributions!

As most people reading my blog do know already anyway and I no longer feel ashamed of using it…

My twitter username: foobarbablub – respectively the twitter page: http://twitter.com/foobarblablub

Polluting the twitter cloud with statements / impressions I don’t think they’re worth a whole blog post… most tweets are not related to technical / computer stuff by the way – used language is mostly English…

Actually I wanted to go there by taxi, however in the morning I met three really nice local guys in my age, who offered to drive me there for free after I told them I’m going to go to Ubud today… (however) by motorcycle.

Considering the traffic conditions on Bali I really was not sure about whether taking this offer would be a good idea… however I agreed – no risk no fun… – it was an awesome experience!

So I collected all my stuff, threw it in my backpack and met with these guys – four people on two motorcycles, lurching through the traffic about 40 minutes from Sanur to Ubud having all my stuff on my back.
Watching the traffic from this point of view it seems much more and less scary at the same time. You’re now part of this chaos, praying the guy in front of you driving the motorcycle is doing everything right.
However it just works – what seems to be the worst chaos ever from the outside, from the inside everything seems to be smooth, everybody is seems to be relaxed, just trying to find out whether this gap is big enough to get through…

The accomodation is really simple, but quite nice – just a room with a bed in and a kind of open-air shower and WC. Tea and coffee the whole day and breakfast included for about 10USD / night.

Met a German couple on the plane going to do professional diving somewhere in the south of Bali for three weeks. They offered me to visit them there and taking a deep look into the water with professional diving equipment. From what they told it has to be really incredible and if any way possible, I’m going to take that offer whenever I’ll be in this area.

On the final flight from Singapore to Bali I met an English guy, who is living on Bali with his Balinese wife and daugther for quite some time now and offered me to stay with them in their place for a couple of days which offer I thankfully took, as I had no clue anyway what to do after dropping out of the airplane (I in case of doubt I would have aimed a hostel near the airport mentioned in my guide).
These three people (actually four, there is an attendant living with them who is treated as part of the family) are really lovely, doing everything to make my stay enjoyable – well, I got in touch with the guy just two hours ago on the plane!

Their place – they call it “simple” – is wonderful; the whole kind-of 2nd floor is mine, within an own (bed)room, bathroom and an area with chairs and table which is opened to the inside of the whole area which in fact is a little garden – if I want to just “relax” they said…

Just take a look by yourself:

When writing this text it’s about 4 ‘o clock local time – bloody jetlag… _right now_ I just did see Bali at night (arrived at 9 ‘o clock); I’m really curious about how this all looks by day.

I took a walk in the area nearby at about 11PM and have to admit – I don’t really feel comfortable just walking around alone… Overall people offering you every kind of services in a very aggressive way, trying to rip off tourists.
However walking around in this area, tired and a little bit agitated because of the long flight, just wanna have everybody shut-up, might not have been the appropriate preconditions facing the situation in an open-minded way.

UPDATE: That was really just the first impression… the people are nice and kind, seriously. Yes, they want to sell their stuff quite often and quite everywhere, however you get used to it… just saying no, starting ignoring them or taking with them about all the world and his wife or whatever elese 

So much for now – as there are lot of things I’d like to see/visit very close by the place I’m currently staying, I think I’ll keep staying here for a couple of days – trying to figure out where to go and what to do next.