> On Tuesday, August 12, 2014 8:18 PM, Guenter Roeck <linux@xxxxxxxxxxxx> wrote: > > On 08/12/2014 04:48 PM, Chris Kelly wrote: >>> On Tuesday, August 12, 2014 5:47 PM, Guenter Roeck > <linux@xxxxxxxxxxxx> wrote: >> >>>> On 08/12/2014 02:05 PM, Chris Kelly wrote: >>>> Here's the full detection listing: (There is a Nuvoton chip > detected >>> (NCT6776F) but apparently this board has more than 1 Nuvoton on it?) >>>> >>> >>> Please don't drop the list (they are interested in the answer as > well), >>> and don't top-post. >>> >>>> Do you want to scan for Super I/O sensors? (YES/no): >>>> Probing for Super-I/O at 0x2e/0x2f >>>> Trying family `National Semiconductor/ITE'... > No >>>> Trying family `SMSC'... > No >>>> Trying family `VIA/Winbond/Nuvoton/Fintek'... > Yes >>>> Found `Nuvoton NCT6776F Super IO Sensors' > Success! >>>> (address 0x290, driver `w83627ehf') >>> >>> there is only one chip. The NCT5573D is supposedly compatible with > NCT6776F, >>> and you hereby confirmed that. I updated the lm-sensors web page > accordingly. >>> >>> If your distribution includes the nct6775 driver, you might want to use > it >>> instead of the w83627ehf driver. >>> >>> Guenter >>> >> >> >> >> dmesg output containing nct or w83 references: >> >> [ 10.420876] w83627ehf: Found NCT6776F chip at 0x290 >> [ 2014.388479] nct6775: Found NCT6776D/F or compatible chip at 0x2e:0x290 >> [ 2014.388593] nct6775: probe of nct6775.656 failed with error -16 >> >> >> Anything to be concerned about in reference to the above “probe of > nct6775.656 failed with error -16” ? >> > Both drivers support the chip. You have to use one or the other, but not both. > If you try to load both, the second driver will fail to load with -EBUSY, > or -16. > >> >> As a test, I ran ‘sensors’ with just the w83627ehf and coretemp drivers > loaded and then with just the nct6775 and coretemp drivers loaded (verified each > time looking at lsmod) >> Both resulted in the same output. >> One odd thing I noticed though is that in both cases, I continue to see the > reference to the “nct6776-isa-0290” as the driver in the output. Is this being > pulled in by both drivers? >> > > Not sure what you mean with "pulled", but the chip is detected as > nct6776 > by both drivers. > >> coretemp-isa-0000 >> Adapter: ISA adapter >> Core 0: +36.0°C (high = +98.0°C, crit = +98.0°C) >> Core 1: +36.0°C (high = +98.0°C, crit = +98.0°C) >> Core 2: +36.0°C (high = +98.0°C, crit = +98.0°C) >> Core 3: +36.0°C (high = +98.0°C, crit = +98.0°C) >> >> nct6776-isa-0290 >> Adapter: ISA adapter >> Vcore: +0.74 V (min = +0.00 V, max = +1.74 V) >> in1: +0.18 V (min = +0.00 V, max = +0.00 V) ALARM >> AVCC: +3.33 V (min = +2.98 V, max = +3.63 V) >> +3.3V: +3.31 V (min = +2.98 V, max = +3.63 V) >> in4: +0.74 V (min = +0.00 V, max = +0.00 V) ALARM >> in5: +1.82 V (min = +0.00 V, max = +0.00 V) ALARM >> 3VSB: +3.46 V (min = +2.98 V, max = +3.63 V) >> Vbat: +3.34 V (min = +2.70 V, max = +3.63 V) >> fan1: 0 RPM (min = 0 RPM) ALARM >> fan2: 0 RPM (min = 0 RPM) ALARM >> SYSTIN: +56.0°C (high = +0.0°C, hyst = +0.0°C) ALARM sensor = > thermistor >> CPUTIN: +46.5°C (high = +80.0°C, hyst = +75.0°C) sensor = > thermistor >> AUXTIN: -13.0°C (high = +80.0°C, hyst = +75.0°C) sensor = > thermistor >> cpu0_vid: +0.000 V >> intrusion0: ALARM >> intrusion1: ALARM >> >> >> What initially got me looking into this though is the lack of fan speed RPM > readings. Both drivers are not giving me any data. >> Is there a way for me to look into this any farther on the system? >> > > Looking at information available elsewhere on the web, it appears that AsRock > for some reason chose to implement fan control not in the nct chip but by some > other means. If this is a server board, the information may be accessible > through IPMI. You might want to ask AsRock for further assistance; maybe > they can tell you more. > > Guenter > Guenter, Appreciate the responses! So everything looks good then, in regards to the drivers. The motherboard is in fact a server motherboard. I'll contact AsRock and ask about any potential ways of extracting the fan speed data. While being available in the IPMI interface would be helpful, it would be ideal if lm-sensors could access the data, but I understand that if AsRock did not make it available via the sensors, then there's nothing you can do about it, from lm-sensor's perspective. Thanks again, though! _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
