Re: [Freeipmi-devel] [RFC][PATCH 0/1] Fix apparent bug w/ ACPI SPMI table parsing

[dann frazier]

Al,

  Thanks for the quick reply. Yeah, I have a larger patchset coming -
hopefully today, if testing goes well. I sent this out early as an RFC
because of reasons you mention - seems like it must've worked at some
point on some system, and I also didn't see any subsequent changes
that seemed likely to break it. There's also another fix in my series
that solves a problem where IPMI revision always seems to have
major/minor revs swapped - more clue that this probably just hasn't
been tested in a long time.

  -dann

On Mon, Jul 30, 2018 at 5:10 PM Albert Chu <address@hidden> wrote:
>
> Hey Dann,
>
> As I thought about it, I'm not sure how much the ACPI code has even
> been tested (atleast by me).  Almost every motherboard I can recall had
> info in DMI/SMBIOS.
>
> Digging into the code history, outside of cleanups & refactoring (which
> of course could have introduced issues, but I doubt those issues would
> have been at the level of what you found), this code was developed
> circa 2004-2005, with the last "real" change in 2006.
>
> So I'm willing to accept your change as is b/c A) it makes sense, B)
> you seem to have a system you can half-test against and C) I assume
> this code worked long ago on whatever system it was originally
> developed against, but who knows if that system even did it correctly.
>
> That said, you seem to be suggesting there are going to be some further
> patches down the line for acpi via sysfs.  If that code is coming down
> the pipeline, and this code is for it, I can wait for the entire patch
> series to come in and it can be added all at once.
>
> Al
>
> On Mon, 2018-07-30 at 15:30 -0600, dann frazier wrote:
> > hey.
> >   I'm working on a patch to add support to ipmi-locate code to parse
> > ACPI
> > SPMI tables via sysfs. This is to make ipmi-locate work on an ARM
> > system
> > we have that describes its BMC only in ACPI (not DMI). Being ARM,
> > trolling
> > /dev/mem isn't safe, (freeipmi ifdef's that out), so using the
> > kernel-exposed
> > tables, when available, is a better option.
> >
> > While doing this I ran across what seems like a bug, which the
> > following patch
> > should fix. I say "seems" and "should" because I don't have a system
> > where the
> > existing /dev/mem snooping code works - with, or without this bug fix
> > -
> > therefore, I cannot emperically demonstrate the bug. On the systems
> > I've
> > tested, which do include an SPMI table, ipmi-locate is unable to find
> > a valid
> > RSDT signature using the /dev/mem method. I'm not sure what I'm doing
> > wrong
> > there - I tried diabling CONFIG_STRICT_DEVMEM andsetting the
> > vm.mmap_min_addr
> > sysctl to 0 w/o luck.
> >
> > dann frazier (1):
> >   Don't try to separate the header from the ACPI table data
> >
> >  libfreeipmi/locate/ipmi-locate-acpi-spmi.c | 33 +++-----------------
> > --
> >  1 file changed, 4 insertions(+), 29 deletions(-)
> >
> --
> Albert Chu
> address@hidden
> Computer Scientist
> High Performance Systems Division
> Lawrence Livermore National Laboratory
>