On Thu, Oct 13, 2016 at 12:29 PM, David Pinkerton <dpinkert@redhat.com> wrote:
Good News.
I installed the fedora 24 version of python-dmidecode and was able to successfully add the host to my cluster...
Thanks you to everyone who looked at this. I owe you a beer or at least some reward points :-)
You owe us a rhel bug for dmidecode :-) Program received signal SIGSEGV, Segmentation fault. dmi_set_vendor (s=0x0) at src/dmioem.c:45 45 if(strcmp(s, "HP") == 0) s is a null, cannot work with strcmp (gdb) thread apply all bt full Thread 1 (Thread 0x7ffff7feb740 (LWP 6318)): #0 dmi_set_vendor (s=0x0) at src/dmioem.c:45 __s1 = 0x0 __result = <error reading variable __result (Cannot access memory at address 0x0)> #1 0x00007fffead5f66f in dmi_table (logp=logp@entry=0xaa70e0, type=type@entry=1, base=<optimized out>, len=<optimized out>, num=<optimized out>, ver=<optimized out>, devmem=devmem@entry=0x7fffead645e0 "/dev/mem", xmlnode=xmlnode@entry=0x6e5420) at src/dmidecode.c:4902 next = <optimized out> h = {type = 0 '\000', length = 252 '\374', handle = 13, data = 0xa4f4aa ""} It look like the code is trying to get the vendor name from type 0. The fact that this leads to sending null vendor string is a second bug. I believe dmidecode is missing this upstream patch: https://github.com/nirs/dmidecode/commit/6e3a3f3cd36f633a56437b42e40d6769ad8... Nir
On Thu, Oct 13, 2016 at 7:28 PM, Martin Polednik <mpolednik@redhat.com> wrote:
On 13/10/16 09:01 +0300, Dan Kenigsberg wrote:
On Thu, Oct 13, 2016 at 11:52:17AM +1100, David Pinkerton wrote:
Nir,
Looks like its crashing on the dmidecode system call.
I've attached the output from gbd as well as a dmidecode text dump, dmidecode binary dump and each keywords run individually.
From the keywords it look like my dmi info is corrupted. I have download a AMI dmi editor but this only allows access to limited fields. Do you know another tools to rewrite the dmi info?
I don't. But whatever is inside your dmi, dmidecode must not crash. Which version of python-dmidecode do you have installed? Would you open a bug against it?
This is really unfortunate - I've reproduced the issue with the attached dump and it's python-dmidecode that crashes. The issue is actually fixed upstream, but the version at least in RHEL does not contain the fix.
RHEL version: python-dmidecode-3.10.13-11.el7.x86_64
works with (actual upstream): python-dmidecode-3.12.2-1.el7.x86_64 (actually it's ~6 line change in dmioem.c)
VDSM output: # vdsClient 0 getVdsHardwareInfo systemFamily = 'To Be Filled By O.E.M.' systemManufacturer = 'Supermicro' systemProductName = 'H8DM8-2' systemSerialNumber = '1234567890' systemUUID = '00020003-0004-0005-0006-000700080009' systemVersion = '1234567890'
Although the upstream version of python-dmidecode is able to deal with improper DMI tables, I can't say what else will/will not behave correctly.
mpolednik
I believe that its maintainers would appriace a simple reproducer, that does not involve ovirt or Vdsm. See if you can simplify the code in
def __leafDict(d): ret = {} for k, v in d.iteritems(): if isinstance(v, dict): ret.update(__leafDict(v)) else: ret[k] = v return ret
def getAllDmidecodeInfo(): import dmidecode
myLeafDict = {} for k in ('system', 'bios', 'cache', 'processor', 'chassis', 'memory'): myLeafDict[k] = __leafDict(getattr(dmidecode, k)()) return myLeafDict _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
--
David Pinkerton Consultant Red Hat Asia Pacific Pty. Ltd. Level 11, Canberra House 40 Marcus Clarke Street Canberra 2600 ACT
Mobile: +61-488-904-232 Email: david.pinkerton@redhat.com Web: http://apac.redhat.com/
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users