Created attachment 24308 [details] dmidecode --dump output from HP dv6 laptop Recently bought HP dv6 series laptop. The DMI table is attached taken by "dmidecode --dump". In particular, the OEM string type as dumped by "dmidecode --dump" is: Handle 0x0008, DMI type 11, 5 bytes Header and Data: 0B 05 08 00 04 Strings: 24 48 50 24 00 "$HP$" 4C 4F 43 23 41 43 4A 00 "LOC#ACJ" 41 42 53 20 37 30 2F 37 31 20 37 39 20 37 41 20 37 42 20 37 43 00 "ABS 70/71 79 7A 7B 7C" 43 4E 42 31 20 30 31 31 30 30 30 30 30 31 34 31 32 31 30 30 30 30 00 "CNB1 01100000141210000" Cousin brother also has an HP laptop - don't know the model. Here is the output from his machine: Handle 0x000B, DMI type 11, 5 bytes Header and Data: 0B 05 0B 00 03 Strings: 24 48 50 24 00 "$HP$" 4C 4F 43 23 41 42 41 00 "LOC#ABA" 41 42 53 20 37 30 2F 37 31 20 37 39 20 37 41 20 37 42 20 37 43 00 "ABS 70/71 79 7A 7B 7C" Following lines have the sscanf() calls specifically checking for "HP_Mute_LED*" OEM strings: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=sound/pci/hda/patch_sigmatel.c;h=eeda7beeb57a2300fe38ed2e83b7b1d22dcfeea0;hb=HEAD#l4760 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=sound/pci/hda/patch_sigmatel.c;h=eeda7beeb57a2300fe38ed2e83b7b1d22dcfeea0;hb=HEAD#l4766 But, as can be seen from the dmidecode output, those strings do not appear on my laptop. So, is it that the smbios/dmi tables are broken or the alsa code is broken? What I wonder from looking at the code is - there is already a check for PCI_VENDOR_ID_HP, why need to again look for SMBIOS/DMI stuff?
(In reply to comment #0) > Created an attachment (id=24308) [details] > dmidecode --dump output from HP dv6 laptop > > Recently bought HP dv6 series laptop. > The DMI table is attached taken by "dmidecode --dump". > > In particular, the OEM string type as dumped by "dmidecode --dump" is: > Handle 0x0008, DMI type 11, 5 bytes > Header and Data: > 0B 05 08 00 04 > Strings: > 24 48 50 24 00 > "$HP$" > 4C 4F 43 23 41 43 4A 00 > "LOC#ACJ" > 41 42 53 20 37 30 2F 37 31 20 37 39 20 37 41 20 > 37 42 20 37 43 00 > "ABS 70/71 79 7A 7B 7C" > 43 4E 42 31 20 30 31 31 30 30 30 30 30 31 34 31 > 32 31 30 30 30 30 00 > "CNB1 01100000141210000" > > Cousin brother also has an HP laptop - don't know the model. His model is dv9500t - which is pretty old, IIRC. > Here is the output from his machine: > Handle 0x000B, DMI type 11, 5 bytes > Header and Data: > 0B 05 0B 00 03 > Strings: > 24 48 50 24 00 > "$HP$" > 4C 4F 43 23 41 42 41 00 > "LOC#ABA" > 41 42 53 20 37 30 2F 37 31 20 37 39 20 37 41 20 > 37 42 20 37 43 00 > "ABS 70/71 79 7A 7B 7C" > > > Following lines have the sscanf() calls specifically checking for > "HP_Mute_LED*" OEM strings: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=sound/pci/hda/patch_sigmatel.c;h=eeda7beeb57a2300fe38ed2e83b7b1d22dcfeea0;hb=HEAD#l4760 > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=sound/pci/hda/patch_sigmatel.c;h=eeda7beeb57a2300fe38ed2e83b7b1d22dcfeea0;hb=HEAD#l4766 > > But, as can be seen from the dmidecode output, those strings do not appear on > my laptop. So, is it that the smbios/dmi tables are broken or the alsa code > is > broken? > > What I wonder from looking at the code is - there is already a check for > PCI_VENDOR_ID_HP, why need to again look for SMBIOS/DMI stuff?
Fix committed in sound-2.6 git tree: http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commit;h=d38cce7046cfd0011f69d5dcf6a22525438154f6