bugdmidecode - Bugs: bug #16042, "Part Number" entry of...

 
 

bug #16042: "Part Number" entry of DMI Type17 is not displayed correctly.

Submitted by:  None
Submitted on:  Thu 09 Mar 2006 06:31:42 PM UTC  
 
Category: NoneSeverity: 1 - Wish
Item Group: NoneStatus: Wont Fix
Privacy: PublicAssigned to: Jean Delvare <khali>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun 18 Feb 2007 03:44:37 PM UTC, comment #2:

After some more thinking, it's now clear to me that Apple messed up when filling the Part Number field of the memory device entries. It really doesn't make any sense to encode this string the way they did. So I'm not going to include additional code in dmidecode to handle it. Instead, the Apple engineers need to fix the code which generates their DMI table.

My own point about the Manufacturer field is still open though. But I don't really want to include a growing look-up table for the JEDEC manufacturer ID inside dmidecode. Such a list would rather belong to an external, tool-independent text file, just as we have /usr/share/pci.ids and usb.ids.

Jean Delvare <khali>
Project AdministratorIn charge of this item.
Mon 08 May 2006 09:22:19 AM UTC, comment #1:

The SMBIOS specification says that the part number is stored as a string, and dmidecode properly displays that string. The SMBIOS specification doesn't mention any additional processing for that string.

Now, it indeed looks like your implementation uses Jedec hexadecimal codes for this string and the "Manufacturer" string, as read from the memory module SPD EEPROM. Other implementations have it differently though.

For the manufacturer, I have seen some Compaq systems with strings like this one: "JEDEC ID:C1 00 00 00 00 00 00 00". So it's a JEDEC manufacturer code, like your system has, but it's encoded differently. And I have seen some HP systems where the string would simply be "HP", so it's already decoded.

For the part number, I've only seen them set on some Compaq systems, and they were already decoded (e.g. "8LSDT1664AG-133E1" or "64D32300GU6C").

So, as you can see, the decoding of these strings, where needed, is manufacturer-specific. We may add some heuristics to dmidecode so that it tries to decode them, but it's not trivial. A look-up table would also be required for manufacturers. And it's definitely a feature request and not a bug.

Could you please provide a dump of your SMBIOS table?
dd if=/dev/mem of=/tmp/macintel bs=4k seek=130760 count=2
I'd like to add it to my non-regression test suite.

Jean Delvare <khali>
Project AdministratorIn charge of this item.
Thu 09 Mar 2006 06:31:42 PM UTC, original submission:

I tested current dmidecode with USE_EFI on my Intel iMac
# Although Intel Mac is IA-32, it uses EFI.
But "Part Number" entry of DMI Type17 is not displayed correctly.
I attached the output file. Please check the spec.

--
demo-n

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #1538:  dmidecode.txt added by None (11KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by khali (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 18 Feb 2007 03:44:37 PM UTCkhaliStatusConfirmed=>Wont Fix
      Open/ClosedOpen=>Closed
    Tue 23 May 2006 02:13:30 PM UTCkhaliSeverity2 - Minor=>1 - Wish
    Mon 08 May 2006 09:22:19 AM UTCkhaliSeverity3 - Normal=>2 - Minor
      StatusNone=>Confirmed
      Assigned toNone=>khali
    Thu 09 Mar 2006 06:31:42 PM UTCNoneAttached File-=>Added dmidecode.txt, #3483

    Back to the top


    Powered by Savane 3.1-cleanup1