A Bluetooth Based Baggage Finder – Part 1

This is a new post about an idea I have for a new device. I believe this solves an interesting problem. I am going to start a series of posts documenting my progress as I develop the device based on this idea.

Idea

Recently, during my travels, I spent a lot of (unpleasant!!) time at the airports. More specifically, I spent a lot of time jostling with the crowds at the baggage carousal. I thought that there should be a better way to do this. What if the baggage was able to “announce” itself to you? You could stand away from the crowds and go pick up the bags when they “announce” themselves to you? So, having these questions in mind, I set out to attack this problem.

The easiest way to do this is to have a ad hoc sensor network. Everybody these days has a bluetooth based cellphones. So, I now have one end of this sensor network. All I need is another node in the bag and the problem solves itself.

I decided to do some research on this issue to see if anybody else had already attempted this issue. Sure enough there is a solution:Bag Claim is exactly the solution. Alas, it uses a regular bluetooth speaker as the second node. While this is a cool thought, my focus was to build a neat bluetooth device to act as the second node.

So now I have to have some sort of bluetooth device in the bag. This is the core idea.

The device in the bag should have these requirements:

1. It should be very cheap
2. The customer should not have to charge/recharge the device. It should run by itself for months or even years. Even then, it should be simple for the customer to charge them.
3. It should pass through obvious regulatory hurdles (this is tricky).

So, my next step is to find the proper bluetooth radio for the device. Fortunately, at the time of this writing, the Bluetooth Ultra Low Power (ULP) spec is out. These ULP devices are meant to run with minimal power requirements. They should be able to run for months, if not years. The first such devices have started to come out. After some search, I found out the Nordic Semiconductor device nRF24L01+. I now have the bluetooth radio sorted out. So, the basic parts of my device would be:

1. nRF24L01+
2. 8 bit MCU capable of executing 8051 instruction set.
3. Others (includes circuit components like oscillators, regulators etc).

The next task now is to get the price of building this device. If I determine that that it would be cheap to build and sell such a device, I will go ahead with the design. Watch out for it in the coming weeks.

Zend framework: Working with Gdata

In this post, I will talk about working with the open source zend framework and Google Health API . The zend framework offers an elegant method to access health data and post notices. I will talk about using the ClientLogin method first. ClientLogin method is recommended for desktop applications by Google. This post is based on the zend framework documentation and Google health API documentation.

The zend packages are available from Fedora repositories.

Authentication

Authentication is the first step in working with Gdata. The ClientLogin method uses standard username and password for authentication. We will be using the developers sandbox (https://www.google.com/h9) for our testing. The authentication code could be:


function authenticate()
{
$user = "user@gmail.com";
$pass = "passwd";
$h9service = Zend_Gdata_Health :: H9_SANDBOX_SERVICE_NAME;
$client = Zend_Gdata_ClientLogin :: getHttpClient($user, $pass, $h9service);
return $client;
}


This code creates a http client using the ClientLogin mechanism for the H9 sandbox service and returns the client. This should be your first step.

Health Service

The next step is to create a Google health service client from the http client. This could be the code:


$client = authenticate();
$useH9 = true;
$healthService = new Zend_Gdata_Health($client, "MyService", $useH9);


In this code block we call the authenticate() function to get the http client and create a health service client.

Profile List Feeds

ClientLogin Mechanism requires that we extract the profile ID for subsequent queries. It provides profile list feed from which we extract the profile we want.

The register feed is:

https://www.google.com/health/feeds/register/ui/profileID

The profile feed is:

https://www.google.com/health/feeds/profile/ui/profileID

Since one user can have more than one profile ID in Google Health, we need to extract the profile ID we need. For ClientLogin mechanism, we need to set the profile ID for the health service client. In the following code, we extract the profile from profile list feed and set the first profile ID for the health service:


$feed = $healthService->getHealthProfileListFeed();
$entries = $feed->getEntries();
$profileID = $feed->entry[0]->getProfileID;
$healthService->setProfileID->($profileID)


In the code above, we use the profile list feed to enlist all the profiles for a particular user. This feed is available only under ClientLogin authentication mechanism.

Feeds and Queries

Now that we have the profile ID, we can get all the CCR entries from the feed. To do so, we construct a query and use that query to get all the feed entries


$query = new Zend_Gdata_Health_Query("https://www.google.com/h9/feeds/profile/ui/$profileID");
$profileFeed = $healthService->getHealthProfileFeed($query);
foreach ($profileFeed->getEntries() as $entry) {
$ccr = $entry->getCcr();
echo '<p>' . $ccr->getXML() . '</p>';
$count++;
}


In the code above, we just print the CCR entries in XML format. If you want to print text of, say medication, you could use this code:


$query = new Zend_Gdata_Health_Query(SCOPE . "profile/ui/$profileID");
$query->setDigest("true");
$profileFeed = $healthService->getHealthProfileFeed($query);
$entries = $profileFeed->getEntries();
foreach ($entries as $entry) {
$medications = $entry->getCcr()->getMedications();
foreach($medications as $med) {
$xpath = new DOMXpath($med->ownerDocument);
$elements = $xpath->query("//ccr:Medications/ccr:Medication/ccr:Product/ccr:ProductName/ccr:Text");
foreach ($elements as $element) {
echo $element->nodeValue . '<br>';
}
}
}


In the code, above we use setDigest to get the entire feed as one entry. Hence it will loop only once here. We then use DOMXpath object to query the CCR text. We could get text of other categories this way.

Sending Notices

You can send notices to the profile which can be as simple as a text message or can optionally include a CCR element. I will just point out that it is very simple to send these. It is just one call.


$subject = "This is my subject";
$body = " This is the message ";

$healthService->sendHealthNotice($subject, $body);


Its as simple as that.

This concludes this post. In the next post, I will talk about other methods of authentication. This post should hopefully help anyone to get started on the Gdata API immediately.

Bluez tools and programming – Part II

In this post I will continue exploration of bluez tools and programming. Please check back my last post for part I.

hcitool

Let us explore the information extracted by hcitool. The format of the command is

$ hcitool [options] [command]

$hcitool dev

This will output the local devices in the format [hciX] [BD Address]

hcitool inq

This will inquire remote bluetooth devices and output information of the device. On my machine the output was

[BD Address] [Clock offset] [class]

This will scan the remote device. As opposed to inquiry, this will just output the bluetooth address and the user friendly name of the remote device.

hcitool name [BD address]

Given the address of the remote device, this command outputs the user friendly name.

$ hcitool info [BD address]

This will output the information of the remote device given its address. On my machine, it gave me this:

Requesting information …
BD Address: 00:20:E0:CC:29:7B
OUI Company: Actiontec Electronics, Inc. (00-20-E0)
Device Name: Blue1-0
LMP Version: 1.1 (0x1) LMP Subversion: 0x322
Manufacturer: Cambridge Silicon Radio (10)
Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00

As you can see, it outputs information needed for making a connection.

hcitool cc [BD address]

This creates a ACL connection to the bluetooth device whose address is given. You can specify the role of the local device as master or slave using -m option. Please note that this connection is not meant to stay endless. They will be disconnected. You should use other methods for persistent connections (I will talk about them later).

hcitool dc [BD address]

This will disconnect from the connected bluetooth device.

hcitool con

This displays the list of connections. The output might look like this:

Connections:
< ACL 00:20:E0:CC:29:7B handle 0 state 2 lm MASTER

This tells us that the host is connected to a device with address 00:20:E0:CC:29:7B. It is a ACL link and it is the master in the connection.

hcitool sr

This enables switching of roles of the host device. If it is master, you can switch it to slave.

hcitool rssi [BD address]

This displays the connection signal strength. The output might look like this (it says 1 for my connection).

RSSI return value: 1

hcitool lq [BD address]

This displays the link quality of the current connection. The output might look like this.

Link quality: 255

hcitool tpl [BD address]

This displays the transmit power level of the current connection. The output might look like this (it shows 0 for my connection).

Current transmit power level: 0

hcitool afh [BD address]

This displays the AFH map in hexadecimal. The output might look like this.

AFH map: 0xffffffffffffffffff7f

hcitool lp [BD address]

This displays the link policies of the current connection.

hcitool lst [BD address]

This displays the link supervision timeout settings. The output might look like this.

Link supervision timeout: 32000 slots (20000.00 msec)

hcitool clkoff [BD address]

This displays the clock offset setting of the remote device. The output might look like this.

Clock offset: 0x5206

hcitool clock [BD address]

This displays the clock of the remote device.

hcitool key [BD address]

This changes the link key (the pin) between the two devices.

This completes the most useful options for the command. There might be others that you might want to see. But the most important thing about hcitool is to know the various connection parameters.

In the next post, I will look into the BlueZ API. This will give us the capability to program these devices.

Bluez tools and programming – Part I

In this post, I will talk about the bluez userspace tools. I am using Fedora 11 for this exploration but it is applicable irrespective of the distro.

The bluetooth specification is very useful if you need to learn everything you need to learn! I have used the specification to extract and present some information here. The official page has all the information.

The userspace tools in bluez that are useful for the programmer are: hciconfig, hcitool and hcidump. I will attempt to describe the information extracted by hciconfig in this post.

hciconfig

To start using this tool, simply type the command:

$ hciconfig

This will output basic information about all the bluetooth devices.

or

$ hciconfig -a

This will output “all” the information (hence the option “a”) about the bluetooth devices

To know the usage for hciconfig, use option “h”

$ hciconfig -h

Let us examine the output of the command and understand the contents.

This would be a sample output for hciconfig -a

hci0: Type: USB
BD Address: 00:10:60:B2:9F:42 ACL MTU: 377:10 SCO MTU: 64:8
UP RUNNING PSCAN
RX bytes:1647 acl:0 sco:0 events:49 errors:0
TX bytes:454 acl:0 sco:0 commands:50 errors:0
Features: 0xff 0xfe 0x0d 0x38 0x08 0x08 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy:
Link mode: SLAVE ACCEPT
Name: ‘Blue-0’
Class: 0x4a0104
Service Classes: Networking, Capturing, Telephony
Device Class: Computer, Desktop workstation
HCI Ver: 1.2 (0x2) HCI Rev: 0x0 LMP Ver: 1.2 (0x2) LMP Subver: 0x309
Manufacturer: Broadcom Corporation (15)

This output shows that one bluetooth device is attached. Let us explore the meaning of the output.

USB: This is a USB device connected to out host. Other kinds could be UART, for instance.

BD Address: 00:10:60:B2:9F:42: This is the 48 bit unique hardware address of the device, similar to the MAC or Ethernet address

ACL MTU: 377:10 SCO MTU: 64:8: They refer to the two kinds of bluetooth data links: Asynchronous Connectionless Link (ACL) and Synchronous Connection Link (SCO). MTU refers to Maximum Transmission Unit which is the maximum Service Data Unit (SDU) they device is capable of receiving. For this device 377 refers to the MTU for ACL packets and 10 refers to the number of ACL packets sent in a transmission. Similarly 64 refers to MTU for SCO and 8 refers to the number of SCO packets sent in a transmission.

RX bytes:1647 acl:0 sco:0 events:49 errors:0: This refers to the statistics of the received bytes. It shows that no ACL or SCO bytes were received.

TX bytes:454 acl:0 sco:0 commands:50 errors:0: This refers to the statistics of the transmitted bytes. As before, it shows that no ACL or SCO bytes were transmitted.

UP RUNNING PSCAN: These are the bluetooth link states. The official spec defines them as substates. These substates define the parameters to enable discovery and establish connections with other bluetooth devices. The important substates are: page, page scan, inquiry, inquiry scan (The standby and connected states are kind of self-explanatory).

Broadly, paging substates are used for establishing connections and inquiry substates are used for discovery of devices.

page state: A bluetooth device in this state is the master device that is sending paging messages for connection
page scan state: A bluetooth device in this state is the slave that is set to receive paging messages from a master
inquiry state: A bluetooth device in this state is attempting to discover other devices in the vicinity.
inquiry scan state: A bluetooth device in this state is discoverable to other devices in the vicinity.

From the output, we see that our bluetooth device is in page scan state as well as UP and RUNNING.

Features: 0xff 0xfe 0x0d 0x38 0x08 0x08 0x00 0x00: This is a long list of features supported by the device. These are transmitted as Link Manager Protocol (LMP) messages for the devices to know each others capability. Each feature is represented as a bit mask. 1 indicates that the feature is supported and 0 indicates that it is not supported. Some of the features are represented by more than one bit.

For instance, byte 0, which is 0xff indicates that all the features in this byte are supported: They are: 3-slot packets, 5-slot packets, encryption, slot offset, timing accuracy, role switch, hold mode, sniff mode. The official bluetooth spec has the list of all the features if you are interested.

Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3: This lists the baseband layer data packet types supported by this device. They are represented as 4 bit fields. Please check the official specification if you are interested in details of all the data packet types.

Link policy: This refers to the settings which determines the behavior of the bluetooth device when it receives a request from another device. The possible policies are DISABLED (which is the current setting), ROLE SWITCH, HOLD, SNIFF and PARK.

Link mode: SLAVE ACCEPT: The modes for the bluetooth linking protocol. The other modes could be MASTER for instance.

Name: ‘Blue-0’: The user friendly name of the device.

Class: 0x4a0104: This is an identifier for the device composed of 3 bytes. The man page for hcid.conf describes them in detail. If we proceed from MSB to LSB for this number,

0x4a (Represents the service classes of the device): Bits 2, 4 and 7 are set which indicate “Networking, Capturing, Telephony”.
0x01 (Represents major device class): Bit 1 is set which indicates “Computer”.
0x04 (Represents minor class): Bit 2 is set which indicates “Desktop workstation” of major device “Computer”.

Service Classes: Networking, Capturing, Telephony: This refers to the services that the current host configuration can offer. It can be anything related to services offered by the device like “Rendering”, “Positioning” etc.

Device Class: Computer, Desktop workstation: The major and minor device classes as discussed above.

HCI Ver: 1.2 (0x2) HCI Rev: 0x0 LMP Ver: 1.2 (0x2) LMP Subver: 0x309: This refers to the versions supported by this device.

Manufacturer: Broadcom Corporation (15): The manufacturer of the bluetooth device.

Changing parameters via hciconfig

You can change configuration parameters via hciconfig. To see all the command line options:

$ hciconfig -h

Usage:
hciconfig
hciconfig [-a] hciX [command]
Commands:
up Open and initialize HCI device
down Close HCI device
reset Reset HCI device
rstat Reset statistic counters
auth Enable Authentication
noauth Disable Authentication
encrypt Enable Encryption
noencrypt Disable Encryption
piscan Enable Page and Inquiry scan
noscan Disable scan
iscan Enable Inquiry scan
pscan Enable Page scan
ptype [type] Get/Set default packet type
lm [mode] Get/Set default link mode
lp [policy] Get/Set default link policy
name [name] Get/Set local name
class [class] Get/Set class of device
voice [voice] Get/Set voice setting
iac [iac] Get/Set inquiry access code
inqtpl [level] Get/Set inquiry transmit power level
inqmode [mode] Get/Set inquiry mode
inqdata [data] Get/Set inquiry data
inqtype [type] Get/Set inquiry scan type
inqparms [win:int] Get/Set inquiry scan window and interval
pageparms [win:int] Get/Set page scan window and interval
pageto [to] Get/Set page timeout
afhmode [mode] Get/Set AFH mode
sspmode [mode] Get/Set Simple Pairing Mode
aclmtu [mtu:pkt] Set ACL MTU and number of packets
scomtu [mtu:pkt] Set SCO MTU and number of packets
putkey [bdaddr] Store link key on the device
delkey [bdaddr] Delete link key from the device
oobdata Display local OOB data
commands Display supported commands
features Display device features
version Display version information
revision Display revision information

For instance, to make the device discoverable:

$ hciconfig hciX iscan (or piscan to enable both page and inquiry scan)

In the next post, I will talk about more command line tools and bluez API.

Subversion

If you want to maintain a code repository, subversion could satisfy your needs. Creating such a repository is fairly simple. The issues with subversion being not great with branches/tags are well documented. I won’t go into those details.
I will list the steps to create a repository fast and get working on checking in and checking out your code. All the information here is condensed from the Redbook .

1. Create the subversion repository

Say, you want to create a repository under the directory /home/svn/my_repos, this is the command to create the repository.

$ svnadmin create /home/svn/my_repos

That’s it.

2. Get the code base ready

Subversion redbook recommends that the code be in structured in 3 directories: trunk, branches, tags. Say your code has two files main.h, main.c.

Create a top level directory, say my_code

$ mkdir my_code

Create the subversion recommended branches

$ cd my_code
$ mkdir trunk
$ mkdir branches
$ mkdir tags

Copy all your sources to my_code/trunk. You now have your sources ready for importing into the repository.

3. Import the code to your repository

$ svn import my_code file:///home/svn/my_repos -m “Initial import of my_code”

You are done!

4. Check your work

To see the repository, the subversion command svnlook is your friend.

$ svnlook info /home/svn/my_repos

This will dump the last checked in message (in this case the initial message during import) along with the time details

$ svnlook tree /home/svn/my_repos

This will dump your source tree. It will look like this

/
trunk/
main.h
main.c
branches/
tags/

As always svnlook help will enlist other commands

5. Checking out and checking in code

To check your code to your local machine:

$ svn co file:///home/svn/my_repos

This will check out your code to local directory my_local_dir. I am assuming that your repository is on your local machine. This almost will never be the case if you are in a professional environment. You will most likely use tunneling over ssh. To access your code over the tunnel:

$ svn co svn+ssh://svn@hostname/home/svn/my_repos

Checking in your work is pretty simple:

$ svn ci

6. Branching and tagging

Branching and tagging are really copy operations in subversion. Basically it saves a snapshot. It is up to the user to create a branch. Say you want to create a branch from trunk and work on that branch:

$ svn copy /repos_path/trunk /repos_path/branches/branch_name

where branch_name is the name of the branch you want. That’s about it. You can do the usual check in and check out from this branch. Tagging is similar. You just copy to tags directory in the repository.

FreeBSD updates

I updated couple of FreeBSD machines to test out the latest sources. This is my notes on doing the updates “the right way”! This is based on the Handbook (which is a great reference BTW). These are the steps.

1. Install CVSup and portupgrade.

Installation of these programs can be done via the usual pkg_add mechanism or via ports. To add via pkg_add, do this:

$ pkg_add cvsup
$pkg_add portupgrade

That's it!

If you want to install via the ports directory:

$ cd /usr/ports/net/cvsup
$ make install && make clean

$ cd /usr/ports/ports-mgmt/portupgrade
$ make install && make clean

2. Edit the cvs-supfile

cvs-supfile is the input file for CVSup. You can find an example file in /usr/share/examples/cvsup/cvs-supfile. You will need to edit this file to let CVSup know which parts of the source needs to be updated. These were the edits I did on the file:

Change host to cvsup.FreeBSD.org.

Next, you need to edit the major portions of that file.

They are: Sources, Ports, Documentation, WWW, Projects, CVSROOT. I used “src-all” and “ports-all” and disabled the rest. It is really advisable to update all the sources. If you update parts of source tree, it might result in unpredictable behavior. Updating all the sources is well worth the time. I think updating ports is also well worth the time. Remember that updating ports just downloads all the info files (like Makefiles, patches etc) and not the actual sources (I will talk about actual install of updated ports in a while).

3. Update sources and ports

This step downloads all the latest sources and ports configuration files. Its straightforward. Use this command:

$ cvsup -g -L 2

This will take a while. So, go ahead, get some coffee.

After all the files are downloaded, you need to build world (compilers etc) and kernel.

4. Reboot to single user mode

It is recommended to build world and kernel in single user mode. This will obviously speed things up and won’t mess with the configuration files in /etc directory, for instance.
After rebooting in single user more, you need to manually mount all the UFS file systems. These are the steps:

$ fsck -p

This runs file system checks on all UFS systems to make sure they are consistent.

$ mount -u /

This remounts the root file system with read/write permissions.

$ mount -a -t ufs

This mounts all the UFS file systems on your machine.

$ swapon -a

This turns all the swap partitions on.

5. Build world

This step is very important. Before updating any ports, you need to rebuild world. This will rebuild the kernel, compilers, and other utilities (like files in /sbin/ /usr/sbin etc). Before you rebuild world you need to look at /usr/src/UPDATING file. This file will have notes on any issues with the latest kernel sources or compilers.
The most important part is to rebuild kernel with the latest compiler sources. So, you will have to first rebuild the compilers first! These are the steps:

$ cd /usr/src
$ make buildworld

This will build the compilers and place them in /usr/obj. This will take a while, obviously.

Now, you are ready to build and install the new kernel with the compilers from /usr/obj. It is very simple! This kernel, however uses the standard configuration file. If you have your own configuration file, you need to specify with KERNCONF option. Please also not that the standard configuration file will include options to enable debugging. Please turn it off if you don’t need them.

$ make kernel

Now, reboot the machine to single user mode. After the machine reboots, please mount all UFS partitions as in step 4. In the next step we will be installing world (meaning all utilities like compilers, editors etc).

6. Install world.

Installing world is straightforward.

$ cd /usr/src
$ make installworld

This will copy all the files from /usr/obj/. After this step, you can remove this directory.

$ cd /usr/obj
$ chflags -R noschg * (Recursively remove all the immutable flags)

The next step is to update files in /etc

7. Updating files in /etc

This step is needed to update various configuration files in /etc directory. You would use a Bourne script utility called mergemaster.sh. On my system, I didn’t make any changes to /etc directory. So, I just accepted the new changes.

$ mergemaster

Not that in this process you will be presented with diffs for all the /etc files that need to be updated. This can be a bit tedious, but you have to do it anyway. On my system, I accepted all the diffs for the new files.

You are done now. You can reboot to multi user mode now. Next, we update all the ports.

7. Update the ports database

Before you update the ports database, make sure you read /usr/ports/UPDATING. This file will usually enlist any issues in the current development branch.

In this step, you would update the ports database with the new ports that we downloaded during the CVSup stage. This creates a new /usr/ports/INDEX.db file

$ portsdb -Uu

Depending on the number of ports you have installed, it will take a while for this command to run. So, please be patient!

8. portversion

portversion is a tool which compares the installed ports with the updated database and outputs them with either “=” sign (meaning no updating needed) or “<" sign (meaning the port needs upgrade). To see the ports that need to be updated, use this command:

$ portversion -l “<"

9. Update the ports.

Finally! This step will update all the ports.

$ portupgrade -arR

This command recursively updates all the ports. This step will obviously take a while.

You are almost done now!

10. Sync with the packages database

It is a good idea to sync your ports database with the packages database. It is very simple.

$ pkgdb -F

This is an interactive command. It will ask if any obsolete packages need to be deleted. I didn’t have any obsolete packages on my machine. If you want this to be done automatically, use this command

$ pkgdb -fu

Now you are done!

Sound on ASUS M2A-VM HDMI MB with 64 bit Linux

If you don’t have sound on this MB with 64 bit Linux, upgrade your BIOS to latest (V 2301 at this time). It fixes the card detection issue.

radeon_gem_do_relocate message. Whats that?

My home machine runs F12 on a ASUS M2A-VM HDMI MB. With the changes to the radeon driver being continuously worked on, I get this message with my ATI X1950Pro card:

[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4
[drm:radeon_gem_do_relocate] *ERROR* radeon gem set domain -11 failed 0 4

I presume it is harmless and only for debug purposes on Fedora.

Update: Looks like a bug has been reported on bugzilla: Bug 499335