Bug 207501 - DMIDecode tables advertizing bogus size
DMIDecode tables advertizing bogus size
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xen (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Xen Maintainance List
Brian Brock
:
Depends On:
Blocks: FC6Blocker
  Show dependency treegraph
 
Reported: 2006-09-21 09:23 EDT by Daniel Berrange
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-11 16:02:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
DMI Decode output (3.01 KB, text/plain)
2006-09-21 09:23 EDT, Daniel Berrange
no flags Details
Fix CPU table length calculation (568 bytes, patch)
2006-10-03 16:28 EDT, Daniel Berrange
no flags Details | Diff

  None (edit)
Description Daniel Berrange 2006-09-21 09:23:29 EDT
Description of problem:
Running on an Fedora Core 6 (rawhide) AMD x86_64 host system, with a RHEL-3 i386
guest. The guest's DMI decode tables contain bogus size information. Running
dmidecode reports:

  "Wrong DMI structures length: 439 bytes announced, structures occupy 363 bytes."

I've not checked whether the same happens in a x86_64 guest, or a later rhel

Version-Release number of selected component (if applicable):
Host running  xen-3.0.2-33
Guest running  redhat-release-3AS-13.8.3

How reproducible:
Always

Steps to Reproduce:
1. Create HVM guest
2. Run 'dmidecode' in guest
3.
  
Actual results:
Warnings about bogus size info

Expected results:
No warnings

Additional info:
Will attach the dmidecode output the ticket
Comment 1 Daniel Berrange 2006-09-21 09:23:29 EDT
Created attachment 136852 [details]
DMI Decode output
Comment 2 Daniel Berrange 2006-09-21 11:20:04 EDT
Ok, verified in a x86_64  HVM guest - still get the bogus dmidecode data size
reported, so doesn't seem to be related to the architecture mismatch.
Comment 3 Andrew D. Ball 2006-10-02 11:13:10 EDT
Please post the domU's configuration.
Comment 4 Daniel Berrange 2006-10-02 11:52:14 EDT
Here's an example config for x86_64 RHEL-3 guest.

name = "rhel3x86_64"
builder = "hvm"
memory = "500"
disk = [ 'file:/xen/rhel3x86_64.img,hda,w', ]
vif = [ 'mac=00:16:3e:05:eb:04, bridge=xenbr0', ]
uuid = "dbc4c892-4b67-bc7a-895a-a6b5f56ff061"
device_model = "/usr/lib64/xen/bin/qemu-dm"
kernel = "/usr/lib/xen/boot/hvmloader"
vnc=1
vncunused=1
apic=1
acpi=0
pae=1
vcpus=4
serial = "pty" # enable serial console
on_reboot   = 'restart'
on_crash    = 'restart'
Comment 5 Daniel Berrange 2006-10-02 16:18:33 EDT
Looks like it is fixed upstream in:

http://xenbits.xensource.com/xen-unstable.hg?cs=f426f6e646eb

Comment 6 Daniel Berrange 2006-10-03 16:28:09 EDT
Created attachment 137694 [details]
Fix CPU table length calculation

The upstream patch was not complete. This fixes a corrupt CPU table entry
Comment 7 Daniel Berrange 2007-01-11 16:02:08 EST
Fixed in Fedora a little while back now.

Note You need to log in before you can comment on or make changes to this bug.