Hi Robert, On Wed, Mar 09, 2011 at 07:25:43PM -0500, Robert Kaiser wrote: > Guenter Roeck schrieb: > > All I know is that there is a sequence of patches in linux-next adding several > > PCI IDs plus related code to the kernel which seem to be related to Sandy Bridge. > > Look for PCI IDs with "DH89XXCC". I am kind of vague here; I was told that the added > > PCI IDs match those of Sandy Bridge, but I have not seen the specification myself > > so I don't really know for sure. > > > > Do those changes address your problem ? No idea, but it might be worth a try. > > I'm looking forward to seeing if 2.6.39-rc does better, then, once the > merge window has closed and openSUSE's Kernel:HEAD has it. > > > Just downloading those with wget seems to be more straightforward than creating a git clone. > > OK, did that (needed to switch to the other KERNEL_BUILD line in the > Makefile, but fortunately I'm familiar enough with those Makefiles from > Mozilla work). > FYI, here's the sensors output and used kernel version on my Intel > DH67CL board: > > # sensors > coretemp-isa-0000 > Adapter: ISA adapter > Core 0: +52.0°C (high = +80.0°C, crit = +98.0°C) > > coretemp-isa-0001 > Adapter: ISA adapter > Core 1: +49.0°C (high = +80.0°C, crit = +98.0°C) > > coretemp-isa-0002 > Adapter: ISA adapter > Core 2: +54.0°C (high = +80.0°C, crit = +98.0°C) > > coretemp-isa-0003 > Adapter: ISA adapter > Core 3: +48.0°C (high = +80.0°C, crit = +98.0°C) > > nct6775-isa-0290 > Adapter: ISA adapter > Vcore: +1.15 V (min = +0.00 V, max = +1.74 V) > in1: +1.11 V (min = +0.00 V, max = +0.00 V) ALARM > AVCC: +3.31 V (min = +0.00 V, max = +0.00 V) ALARM > +3.3V: +3.31 V (min = +0.00 V, max = +0.00 V) ALARM > in4: +1.02 V (min = +0.00 V, max = +0.00 V) ALARM > in5: +1.05 V (min = +0.00 V, max = +0.00 V) ALARM > in6: +1.08 V (min = +0.00 V, max = +0.00 V) ALARM > 3VSB: +3.41 V (min = +0.00 V, max = +0.00 V) ALARM > Vbat: +3.38 V (min = +0.00 V, max = +0.00 V) ALARM > fan1: 0 RPM (min = 0 RPM, div = 64) > fan2: 1110 RPM (min = 0 RPM, div = 32) ALARM > fan3: 0 RPM (min = 0 RPM, div = 64) > fan4: 0 RPM (div = 64) > SYSTIN: +39.0°C (high = +0.0°C, hyst = +0.0°C) ALARM > sensor = diode > CPUTIN: +38.0°C (high = +80.0°C, hyst = +75.0°C) sensor > = diode > SMBUSMASTER 1: +54.0°C (high = +80.0°C, hyst = +75.0°C) sensor > = diode > PCH_CHIP_CPU_MAX_TEMP: +65.0°C > SMBUSMASTER 2: +0.0°C (high = +80.0°C, hyst = +75.0°C) > cpu0_vid: +2.050 V > > # uname -a > Linux robert.box.kairo.at 2.6.38-rc7-18-desktop #1 SMP PREEMPT > 2011-03-08 01:01:25 +0100 x86_64 x86_64 x86_64 GNU/Linux > > > I hope those values are somewhat reasonable for what you'd expect. > Thanks for your work on this! > Looks reasonable. There is one problem which I had wondered about - the ALARM which tends to show up for running fans. I finally tracked that down. Turns out the chip has a "maximum RPM" register. Apparently that register is not set, which causes the alarm. There is a sysfs attribute for maximum RPM - fanX_max. The w83627ehf driver does not support / use this attribute. Guess I'll have to add it .... that will have to be a separate patch. Thanks, Guenter _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
