Hello! We realize this is not a Linux support forum, but we wanted to bring this issue to the HSA development community's attention to see if anyone else has the same problem and/or to warn people about this potential pitfall.
Ubuntu 15.04 launched yesterday, which is important for HSA since it is the first Ubuntu version to feature kernel 3.19 as its supported mainline kernel. That's a significant step forward towards normalizing the HSA software stack. Unfortunately, there's a small problem that we encountered with Lubuntu 15.04 (presumably this problem plagues every Ubuntu-derivative) in a UEFI boot configuration (gpt partition).
We have two installations of Lubuntu 15.04 on the same machine (A10-7700k): one on an mbr partition, and one on a different drive on a gpt partition (we set up the second installation to mess around with Sumatra). We can successfully boot to both from the bootloader on the gpt drive. What is odd is that the kfd does not seem to initialize when we boot via UEFI to the gpt partition. There are the usual error messages when attempting to boot the mbr partition with IOMMU disabled, but no such error messages occur when booting to the gpt installation regardless of the IOMMU status. Nothing HSA-related will work on the gpt installation (not even vector_copy), while we can run things "just fine" with aparapi-lambda on the mbr partition. Since the kfd is part of the kernel in 3.19, that would seem to be the place to look for problems.
The only obvious difference in the kernel structure between the two installations is that the gpt installation has one extra kernel package: linux-signed-image-18.104.22.168-generic. That package is necessary for proper UEFI booting since it has Canonical's UEFI signing key. Sadly, it (or something related to it) may be preventing initialization of the kfd.
The obvious solution is to stick to mbr installs since we've gotten one working without complication. That's kind of a headache on newer hardware where UEFI prevails and everything else is a "legacy" option.