Hi,
I stumbled upon an exchange of messages on this list concerning sensors
on a Compaq evo W6000 (dating back 15-May-2006) where Rudolf Marek gave
a procedure to activate a possibly existing but hidden SMBUS where
sensors could be attached. I have an evo W6000 and could run the
proposed procedure and here are the results.
> Quick howto:
> 1) lspci -n will tell you the IDs, you will need: pci Id of 0000:00:1f.0
>
> first part is 8086: which is intel, second part is the requested ID
>
> 2) quick hack the quirks.c
>
> change this:
> static int __initdata asus_hides_smbus = 0;
> to
> static int __initdata asus_hides_smbus = 1;
>
> Then recompile and run. you should now see the smbus. If not then take the pci
> ID from step 1 and change following line:
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_0,
> asus_hides_smbus_lpc );
>
> into
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0xNNNN, asus_hides_smbus_lpc );
>
> where NNNN is you ID number.
For the evo, NNNN is 0x2440 and is already in the quirk.c as PCI_DEVICE_ID_INTEL_82801BA_0
Therefore, the only thing to change in quirk.c was to set asus_hides_smbus=1 ...
and it worked, lspci now reports the SMBUS:
00:1f.3 SMBus: Intel Corporation 82801BA/BAM SMBus (rev 04)
Subsystem: Compaq Computer Corporation Evo W6000
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin B routed to IRQ 5
Region 4: I/O ports at fc00 [size=16]
and sensors-detect can configure 2 chips so that "sensors" report something like:
max1617-i2c-0-18
Adapter: SMBus I801 adapter at fc00
Board: +53??C (low = -55??C, high = +127??C)
CPU: +61??C (low = -55??C, high = +64??C)
adm1023-i2c-0-4c
Adapter: SMBus I801 adapter at fc00
Board: +35??C (low = -55??C, high = +127??C)
CPU: +37??C (low = -55??C, high = +62??C)
> If you are able to see the smbus device run sensors-detect and please report if
> you found some useful devices. If so, proper quirk needs to be developed. You
> should provide:
> lspci
> lspci -n
> lspci -v -v -v
> lspci -v -v -v -n
Then, I tried to adapt the quirk.c in the same way that it is done for the other
systems that suffer from the hidden SMBUS issue and understood that the operation is done in 2 steps:
1 - identify if the computer model suffers from the problem by comparing the hostbridge
subsystem_vendor and subsystem_device with those known to be problematic.
2 - if first test succeeds, then write some magic value in pci register when processing the
LPC device.
Having understood this, the change should be easy to do but ... the hostbridge of the evo W6000
does not report a subsystem vendor and device:
# lspci -v -v -v -n
00:00.0 Class 0600: 8086:2531 (rev 04)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR+ <PERR+
Latency: 0
Region 0: Memory at e8000000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP+ GART64- 64bit- FW- Rate=x4
...
# lspci -v -v -v
00:00.0 Host bridge: Intel Corporation 82860 860 (Wombat) Chipset Host Bridge (MCH) (rev 04)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR+ <PERR+
Latency: 0
Region 0: Memory at e8000000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP+ GART64- 64bit- FW- Rate=x4
And the LPC does not have subsystem ID either.
# lspci -v -v -v
00:1f.0 ISA bridge: Intel Corporation 82801BA ISA Bridge (LPC) (rev 04)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR+ <PERR-
Also there are no PCI device processed before the LPC that have subsystem info (otherwise they could be used instead of the HB)
After the LPC device, there are devices with subsystem information such as the IDE interface:
00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 (rev 04) (prog-if 80 [Master])
Subsystem: Compaq Computer Corporation Unknown device 0077
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Region 4: I/O ports at 2040 [size=16]
I wonder how this problem can be worked around:
I thought about several solutions but I wonder if they may work:
idea 1 - do the PCI magic when stumbling upon the IDE interface (it is the first device that reports subsystem IDs that probably correspond indirectly to the mainboard: 0077 )
=> could it work (playing with PCI after having configured the LPC and also what is the risk that 0077 is used in another system than evo W6000) ?
Idea 2 - detect the type of mainboard thanks to something else than the subsystem ID of the HB.
=> I'm not certain where this info could be obtained reliably nor how (BIOS ?)
Idea 3 - replace the first step of the detection by a boot parameter
(one would set "asus_hides_smbus=1" in the boot parameters if he has a hardware with hidden SMBUS that cannot be quirk'ed because it's HB does not report subsystem IDs such as evo W6000)
If someone could shed some light on the possible side effects of such solutions or give other tracks, it would be great.
If nothing safe can be found (that does not risk to make quirk.c bring problem on some systems that work today), I guess that people will have to modify the quirk.c to activate the SMBUS on such hardware.
Regards,
Michel
