We’ve been working with the two Atom D510 servers we intend to use as dedicated route reflectors and came across a small problem we though prudent to share. (Original post: Atom D510 Servers as Route Reflectors) It’s not a showstopper, rather it should be classified as “annoying”.
The Atom servers come with on board IPMI 2.0 capabilities. It’s great for the price – remote KVM, virtual media, sensors, and more. However, we’ve discovered that the sensors don’t seem to coexist well with the operating system (in our case, OpenBSD) polling them as well. Eventually the sensor values will go out of bounds high, low, disappear or return incorrect results and requires a power cycle to reset them. So, we ended up using config(8) to disable the iic* and wbsio* devices to prevent the kernel from accessing them.
Instead, if local sensor monitoring is needed then using ipmitool to talk to the on board IPMI IP address is an acceptable workaround, although not as clean cut. We suspect there is a contention issue between the on board IPMI plus the OS accessing the sensors that eventually leads to the issue we observed.
This does not affect the Atom 330 since it doesn’t have onboard IPMI. Furthermore, reading the 330’s sensors through the operating system reports additional data such as fan RPM (with our case fan mod) whereas this data was only presented via IPMI on the D510.