Hi Dann, Thanks for the additional info, I wasn't aware of it.
In that case, I think we can use the patch. What's the urgency on a new release w/ this patch? Al On Thu, 2015-09-24 at 10:28 -0600, Dann Frazier wrote: > 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 -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-devel mailing list Freeipmi-devel@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-devel
