This looks about right. Wikipedia tells me that E5530 is a Nehalem. I would have expected floating point to be better for that architecture than what you're seeing, but I know that on Sandybridge it's a major crapshoot. Given the almost exact 50% overshoot, I would suspect that what you're seeing is an artifact related to inappropriate counting of floating point load/store operations. The good news is that this number should still be roughly proportional to the "real" answer; the bad news is that there's probably little we can do to make it better. If you're truly curious, you could try devising a test to chain arithmetic operations together to increase FP operations without increasing loads and stores. See what happens to the count vs. theoretical.
One of the issues we're dealing with is that in PAPI 5.0 the error testing on zero.c is now more rigorous, thanks to input from Phil Roth. In 4.x you wouldn't have seen this warning at all. Thank him for us next time you see him
As far as the other tests are concerned, segmentation faults are never a good thing, but are probably PAPI issues, not problems with your installation. It would probably be worthwhile investigating those in a little more detail, particularly the all_native_events test.
cycle_ratio only works on newer kernels (>3.3, I think), so warnings there are expected.
The lack of support for PAPI_PROFIL_RANDOM is also expected.
I hope this helps.