Re: [Freeipmi-devel] Submitting patches

[Dann Frazier]

On Thu, Sep 24, 2015 at 9:29 AM, Newell Jensen <address@hidden> wrote:
> Adding in Dann Frazier to thread

Thanks Newell!

> On Wed, Sep 23, 2015 at 1:50 PM, Albert Chu <address@hidden> 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