[lm-sensors] Compaq Evo w6000

[lm-sensors] Compaq Evo w6000

[Catalin]

An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060512/e49b6e5e/attachment.html

[lm-sensors] compaq evo w6000

[Catalin Arseni]

 Hi,

I have a Compaq Evo W6000 with dual Xeon 1.7Ghz

My problem is somehow related to ticket 913.
Sensors-detect doesn't find any smbus-pci-device
and of course lspci the same.It looks  hidden.

lspci output:

0000:00:00.0 Host bridge: Intel Corp. 82860 860 (Wombat) Chipset Host Bridge
(MCH) (rev 04)
0000:00:01.0 PCI bridge: Intel Corp. 82850 850 (Tehama) Chipset AGP Bridge
(rev 04)
0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 04)
0000:00:1f.0 ISA bridge: Intel Corp. 82801BA ISA Bridge (LPC) (rev 04)
0000:00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 04)
0000:00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #1) (rev 04)
0000:00:1f.4 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #2) (rev 04)
0000:01:00.0 VGA compatible controller: nVidia Corporation NV10GL [Quadro]
(rev 10)
0000:02:06.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev
09)
0000:02:08.0 Ethernet controller: Intel Corp. 82801BA/BAM/CA/CAM Ethernet
Controller (rev 03)
0000:02:0d.0 SCSI storage controller: Adaptec AIC-7892P U160/m (rev 02)

Regarding to ticket913 I cannot use p4b_smbus module to activate  the smbus
because my kernel version is  2.6.15.4. Ok, I found out that I have  to
find  a patch for this kernel for  /drivers/pci/quirks.c to activate the
smbus.
I didn't find it, and it is also not very easy for me to write it.
I could find thou in  quirks.c suport for some Compaqs and I know that
I only have to change some parameters to match my computer.
For example:

}
        } else if (unlikely(dev->subsystem_vendor = PCI_VENDOR_ID_COMPAQ))
{
                if (dev->device = PCI_DEVICE_ID_INTEL_82855PM_HB)
                        switch(dev->subsystem_device) {
                        case 0x0058: /* Compaq Evo N620c */
                                asus_hides_smbus = 1;
                        }

I need (i supose :)) 3 values - PCI_DEVICE_ID_INTEL_????? (the chipset is
i860, but I don't know if this
                                                   is the right value that I
have to add after INTEL_....

                                                - case 0x?????
                                                - and probably the name
between /*???????*/

Also the last kernel 2.6.16.16 didn't add any configuration in the
quirks.cfor compaq evo w6000.

Can anybody help me to solve this problem? Maybe some unix commands that can
give me the right
values?

Best Regards

Catalin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060514/0c35f54e/attachment.html

[lm-sensors] compaq evo w6000

[Rudolf Marek]

Hi,

> 
> 0000:00:00.0 Host bridge: Intel Corp. 82860 860 (Wombat) Chipset Host 
> Bridge (MCH) (rev 04)
> 0000:00:01.0 PCI bridge: Intel Corp. 82850 850 (Tehama) Chipset AGP 
> Bridge (rev 04)
> 0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 04)
> 0000:00:1f.0 ISA bridge: Intel Corp. 82801BA ISA Bridge (LPC) (rev 04)
> 0000:00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 04)
> 0000:00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #1) (rev 04)
> 0000:00:1f.4 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #2) (rev 04)
> 0000:01:00.0 VGA compatible controller: nVidia Corporation NV10GL 
> [Quadro] (rev 10)
> 0000:02:06.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] 
> (rev 09)
> 0000:02:08.0 Ethernet controller: Intel Corp. 82801BA/BAM/CA/CAM 
> Ethernet Controller (rev 03)
> 0000:02:0d.0 SCSI storage controller: Adaptec AIC-7892P U160/m (rev 02)
> 


> Can anybody help me to solve this problem? Maybe some unix commands that 
> can give me the right
> values?

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.

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

Hope it helps.

Good night,
Rudolf

[lm-sensors] compaq evo w6000

[mlo]

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\x16]

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úst >TAbort- <TAbort- <MAbort+ >SERR+ <PERR+
        Latency: 0
        Region 0: Memory at e8000000 (32-bit, prefetchable) [sizedM]
        Capabilities: [a0] AGP version 2.0
                Status: RQ2 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úst >TAbort- <TAbort- <MAbort+ >SERR+ <PERR+
        Latency: 0
        Region 0: Memory at e8000000 (32-bit, prefetchable) [sizedM]
        Capabilities: [a0] AGP version 2.0
                Status: RQ2 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\x16]

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

[lm-sensors] compaq evo w6000

[Rudolf Marek]

mlo wrote:
> 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.

Good.

>> 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\x16]

Good2

> 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úst >TAbort- <TAbort- <MAbort+ >SERR+ <PERR+
>         Latency: 0
>         Region 0: Memory at e8000000 (32-bit, prefetchable) [sizedM]
>         Capabilities: [a0] AGP version 2.0
>                 Status: RQ2 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úst >TAbort- <TAbort- <MAbort+ >SERR+ <PERR+
>         Latency: 0
>         Region 0: Memory at e8000000 (32-bit, prefetchable) [sizedM]
>         Capabilities: [a0] AGP version 2.0
>                 Status: RQ2 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\x16]
> 
> 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) ?

Well only compaq people knows it...

> 
> 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 ?)

DMI is the answer
> 
> 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)

Hmm this will work only for the listed IDs
> 
> 
> 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.

Well I think we do not want to activate the SMBUs on notebooks because it may
interfere with the ACPI or SMBIOS code. - Two diffrent "drivers" talking to same
device is no-good. So I would suggest to leave it as it is unless there are
strong reasons why the SMBus has to be un-hidden.

Regards
Rudolf