[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Invalid length provided for SMBIOS data
I've checked in a simplification of the SMBIOS code as changeset 11686 in xen-unstable. Since this entirely removes the code that computes the table size 'ahead of time', it is very likely to fix this bug. We now *definitely* write the number of bytes that we actually emitted when constructing the tables. So unless the tables themselves are screwed, the length field must now surely be correct. -- Keir On 2/10/06 15:10, "Andrew D. Ball" <aball@xxxxxxxxxx> wrote: > This is seriously broken -- I'll write a patch as soon as I can, unless > somebody beats me to it :-) > > Peace. > Andrew > > On Wed, 2006-09-27 at 19:03 +0100, Daniel P. Berrange wrote: >> I was running some tests of HVM guests on Fedora Core 6, test3 and came >> across a potential issue with SMBIOS data. When running dmidecode in the >> guest VMs it reports that the actual SMBIOS data size, does not match >> the advertised size. eg >> >> "Wrong DMI structures length: 439 bytes announced, structures occupy 363 >> bytes." >> >> I've tried this in a variety of guest OS (RHEL-3 32-bit, RHEL-3 64-bit, >> RHEL-4 64-bit) all the same results. The host is running FC6 test3, but >> the bit of code responsible for constructing the SMBIOS tables is identical >> to that on the vanilla xen-unstable.hg repository. I'm not familiar >> enough with SMBIOS specs / code to determine where the mistake in the >> length calculation is though... >> >> Is anyone else seeing this length mismatch in HVM guests ? >> >> FYI, we're tracking this as >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207501 >> >> Regards, >> Dan. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |