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 <ch...@llnl.gov> 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 > 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
