Hi Sedat, On Fri, 20 Sep 2019 15:23:43 -0500, Bjorn Helgaas wrote: > [+cc Jean] Thanks Bjorn. > On Fri, Sep 20, 2019 at 03:04:39PM +0200, Sedat Dilek wrote: > > I wonder how I can teach dmidecode to give me the correct Manufacturer name. > > I don't know, but Jean (cc'd) probably does. > > You may be able to figure it out via the source or the spec, which you > can find here: https://www.nongnu.org/dmidecode/ > > > root@iniza:~# dmidecode --handle 0x0036 > > # dmidecode 3.2 > > Getting SMBIOS data from sysfs. > > SMBIOS 2.6 present. > > 63 structures occupying 2524 bytes. > > Table at 0x000E0840. > > > > Handle 0x0036, DMI type 17, 28 bytes > > Memory Device > > Array Handle: 0x0033 > > Error Information Handle: Not Provided > > Total Width: 64 bits > > Data Width: 64 bits > > Size: 4096 MB > > Form Factor: SODIMM > > Set: None > > Locator: ChannelB-DIMM0 > > Bank Locator: BANK 2 > > Type: DDR3 > > Type Detail: Synchronous > > Speed: 1333 MT/s > > Manufacturer: 859B > > Serial Number: E0FBCF01 > > Asset Tag: 9876543210 > > Part Number: CT51264BF160B.C16F > > Rank: Unknown > > > > I upgraded my local PCI-IDs via 'update-pciids' tool from pciutils > > Debian/buster AMD64 package. DIMMs are not PCI devices, so dmidecode doesn't care about pciutils-ids at all. > > I tried... > > > > root@iniza:~# diff /usr/share/misc/pci.ids /usr/share/misc/pci.ids.dileks > > 31390a31391 > > > 959B Crucial Technology Moot point but this number does not match the one above so it wouldn't work anyway. > > Under Windows-7 with the SIW tool I can see... > > > > Memory Information; > > Device Locator || Memory Type || Capacity || Manufacturer || Model > > Slot 1 || DDR3 [PC3-12800] || 4096 MBytes || Crucial Technology || > > CT51264BF160B.C16F You should ask them how they are doing that. Are you even sure they read the information from the DMI table? > > How can I handle this correctly in Linux? The manufacturer field is supposed to be encoded as a human-readable string. You BIOS decided to put some 16-bit ID there instead. You seem to think it is a PCI vendor ID but I have no reason to believe so (that number doesn't match anything at http://pci-ids.ucw.cz/read/PC/ ). If anything, it would most probably a JEDEC-106 manufacturer ID. But anyway, dmidecode just decodes the fields according to the specification. We try to avoid adding quirks for hardware which deviates from the spec, as much as possible. The problem is not in dmidecode, the problem is that your BIOS lazily copies the manufacturer ID to the field instead of decoding it to the actual manufacturer name. I've seen this before, you are not an isolated case. You may argue that the specification should have left the decoding to the OS to make BIOS code easier and smaller, and I would agree with that (especially as the JEDEC-106 list keeps growing with company names which I suspect don't even produce memory chips or modules), but other BIOS vendors manage to deal with it properly, so it's definitely possible. We could add JEDEC-106 ID decoding to dmidecode to workaround the issue, but first we would need a pci.ids-like package to provide the IDs independently from the tools. Not only dmidecode would benefit from that, decode-dimms could use it as well. -- Jean Delvare SUSE L3 Support
