You're seeing CRC and framing errors and general input errors. If this happened while setting up the port this could be caused by people still fiddling with the fiber.
If this happens during normal operation most of the time it indicates a low light level or some other error with the fiber(s) or optics.
You can check the light levels with
show interfaces transceiver
Beware that this might report incorrect readings for 3rd party optics. You would then have to look up the power budget / limits of the optic to see if you're in range with the specifications.
As Mike suggested, try cleaning all the fiber terminations. If that doesn't help try replacing the optics.
At the moment the errors are too small to be noticed but that can change very quickly. Better fix it now than being woken at 3am because there is suddenly more loss on the line.
Also for interface (error) counters it sometimes pays off to use the Cisco output interpreter to analyse what you're seeing:
https://www.cisco.com/pcgi-bin/Support/OutputInterpreter/home.pl
Take the analysis with a grain of salt, sometimes they're missing the point but it can help in getting a quick view about what's wrong.
UPDATE:
When using a XENPAK/SFP+ Adapter and DAC cables the problem could be with either of them. Try replacing the Adapter(s) and/or cables. As DAC has no optics in it (it's copper), the interface transceiver
command will not show anything useful.
Also the cable length and possible electromagnetic interferences could cause problems with DAC. If everything fails try switching to optics and optical cabling and see if that helps.
I usually check the Cisco Gigabit Ethernet Transceiver Modules Compatibility Matrix and the 10-Gigabit Ethernet Transceiver Modules Compatibility Matrix. However, none of them contains any reference to SG500X
Anyway: regarding the switch, SFP-H10GB-CUxM is listed in the datasheet of the 500 Series as an option for 10G connectivity, so you should have no problem to attach it to the switch. Regarding the NIC, its specification states it supports standard SFF-8431 and according to 10-Gigabit Ethernet Transceiver Modules Compatibility Matrix the SFP-H10GB-CUxM does also support SFF-8431 (as you can see next), so they should be able to work toghether.
Regulatory and Standards Compliance
Standards:
• GR-20-CORE: Generic Requirements for Optical Fiber and Optical Fiber
Cable
• GR-326-CORE: Generic Requirements for Single-Mode Optical Connectors
and Jumper Assemblies
• GR-1435-CORE: Generic Requirements for Multifiber Optical Connectors
• IEEE 802.3: 10-Gigabit Ethernet
• ITU-T G.709: Interfaces for the Optical Transport Network
• ITU-T G.975: GFEC
• ITU-T G.975.1: EFEC
• SFP+ MSA SFF-8431 (Optical Modules, Active Optical Cables, and
Passive Twinax cables)
• SFP+ MSA SFF-8461 (Active Twinax cables)
Best Answer
You'll find discussion of this elsewhere - see 'Why would I choose Copper over SFP+ for 10GbE?' - but broadly speaking SFP+ DA is, ignoring distance:
10GBase-T on the other hand is:
I've been watching the field for a while, and it doesn't seem like there's consensus on the "best" option yet - networking, server and adapter vendors seem to be hedging their bets.
For what it's worth, we went with SFP+ DA in a top-of-rack configuration, largely due to the ability to mix copper/fibre on the same device. Whether this is applicable for your environment will depend on the number of ports and nature of the network you're building.
One final point: if you do some reading on this, finding objective, unbiased opinion is hard - a lot of the commentary and claims are by people with vested financial interest in encouraging one or other option. As an example, compare and contrast:
Further Reading:
Face off: 10GBase-T and SFP+ Direct Attach
Benefits of Deploying SFP+ Fiber vs. 10GBase-T