[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Freeipmi-devel] Submitting patches

From: Newell Jensen
Subject: Re: [Freeipmi-devel] Submitting patches
Date: Thu, 24 Sep 2015 12:28:20 -0700


Here is my patch (which I have also attached):

Index: ipmi-locate/ipmi-locate.c
--- ipmi-locate/ipmi-locate.c (revision 10210)
+++ ipmi-locate/ipmi-locate.c (working copy)
@@ -537,9 +537,13 @@
       exit (EXIT_FAILURE);
+#ifndef __arm__
+#ifndef __aarch64__
   dmidecode_probe_display (ctx);
   smbios_probe_display (ctx);
   acpi_probe_display (ctx);
   pci_probe_display (ctx);
   if (cmd_args.defaults)
     defaults_display (ctx);

On Thu, Sep 24, 2015 at 10:08 AM, Dann Frazier <address@hidden> wrote:
Hi Al,
 There's no urgency for a formal release. We're past feature freeze
for 15.10, so we couldn't pull in a new upstream release anyway.
However, we can cherry pick it as a bug fix. Though, as Newell just
mentioned to me, we probably want to rework the patch so apply to
ARM32 as well.

On Thu, Sep 24, 2015 at 10:59 AM, Albert Chu <address@hidden> wrote:
> 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 <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:
>> >> 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
> address@hidden
> Computer Scientist
> High Performance Systems Division
> Lawrence Livermore National Laboratory

Attachment: ipmi-locate.diff
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]