On Thu, Sep 24, 2015 at 9:29 AM, Newell Jensen <newell.jen...@gmail.com> wrote: > Adding in Dann Frazier to thread
Thanks Newell! > On Wed, Sep 23, 2015 at 1:50 PM, Albert Chu <ch...@llnl.gov> wrote: >> >> Hi Newell, >> >> Hmmm, I'm not sure if your patch is the right approach. While there may >> be a problem w/ /dev/mem on your system, it may not be something that >> exists on all systems. Or if it's a bug, it may be fixed in the future. >> So just removing the probes on arm64 may not be the best choice. While SMBIOS tables will certainly exist on ARM systems, they should be described properly by firmware (e.g. EFI) and exposed by the kernel at /sys/firmware/dmi/tables/. My understanding is that poking in /dev/mem for the table at legacy addresses on ARM will always be bad because IO memory is memory mapped. This has been a problem for every ARM server platform I've seen (that is, every one supported by Ubuntu). lshw had this same issue, and we resolved it by dropping the /dev/mem probing for ARM (and other platforms), while still retaining non-legacy SMBIOS access: http://www.ezix.org/project/ticket/628 >> Perhaps a better option would be to create a set of options in >> ipmi-locate to limit what probes to do? That way (if you're scripting >> this), you can avoid the probing of known problem areas? >> >> It probably wouldn't be hard to add a bunch of the options. Do you >> think that'd suffice? That would be sufficient for the specific use case Newell and I are working in the MAAS project - that is, we could pass different parameters depending on the architecture. However, it would still remain an issue for other users of ipmi-locate, who would need to know that a special argument needs to be passed if they are on ARM. -dann _______________________________________________ Freeipmi-devel mailing list Freeipmi-devel@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-devel