* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
@ 2007-10-01 17:44 ` Juerg Haefliger
2007-10-01 19:22 ` Juergen Bausa
` (28 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Juerg Haefliger @ 2007-10-01 17:44 UTC (permalink / raw)
To: lm-sensors
Hi Juergen,
On 9/25/07, Juergen Bausa <Juergen.Bausa@web.de> wrote:
> What does this mean (taken from /var/log/messages)?
>
> Sep 23 12:11:22 lisa kernel: dme1737 0-002e: Write to register 0x30 failed! Please report to the driver maintainer.
What exactly is unclear about the message? The write fails (for
whatever reason). I should probably print out the return value as
well...
More interestingly is the register address. 0x30 is the current PWM
duty-cycle. It only gets written during driver initialization or if
userland does manual PWM control.
> I get this sometimes (every some hours). I use the dme1737.ko without on my asus system
> (Pundit P1-AH2) with Athlon BE-2350.
What apps are you running that touch the driver? Are you doing manual
PWM control?
...juerg
>
> Juergen
> _______________________________________________________________________
> Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate
> kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc\x022220
>
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
2007-10-01 17:44 ` Juerg Haefliger
@ 2007-10-01 19:22 ` Juergen Bausa
2007-10-01 21:39 ` Juerg Haefliger
` (27 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Juergen Bausa @ 2007-10-01 19:22 UTC (permalink / raw)
To: lm-sensors
Hi Juerg,
> Von: "Juerg Haefliger" <juergh@gmail.com>
>
> On 9/25/07, Juergen Bausa <Juergen.Bausa@web.de> wrote:
> > What does this mean (taken from /var/log/messages)?
> >
> > Sep 23 12:11:22 lisa kernel: dme1737 0-002e: Write to register 0x30 failed! Please report to the driver maintainer.
>
> What exactly is unclear about the message? The write fails (for
> whatever reason). I should probably print out the return value as
> well...
> More interestingly is the register address. 0x30 is the current PWM
> duty-cycle. It only gets written during driver initialization or if
> userland does manual PWM control.
>
> > I get this sometimes (every some hours). I use the dme1737.ko without on my asus system
> > (Pundit P1-AH2) with Athlon BE-2350.
>
> What apps are you running that touch the driver? Are you doing manual
> PWM control?
>
I use the script fancontrol from lm-sensors, that controls the cpu-fan by pwm. It works
fine. Maybe it somtimes fails in setting the fan speed, but can set in the next cycle.
I newer got error messages from fancontrol.
Juergen
_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc\x100071&distributionid\00000000066
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
2007-10-01 17:44 ` Juerg Haefliger
2007-10-01 19:22 ` Juergen Bausa
@ 2007-10-01 21:39 ` Juerg Haefliger
2007-10-01 21:50 ` Jean Delvare
` (26 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Juerg Haefliger @ 2007-10-01 21:39 UTC (permalink / raw)
To: lm-sensors
Hi Juergen,
On 10/1/07, Juergen Bausa <Juergen.Bausa@web.de> wrote:
> Hi Juerg,
>
> > Von: "Juerg Haefliger" <juergh@gmail.com>
> >
> > On 9/25/07, Juergen Bausa <Juergen.Bausa@web.de> wrote:
> > > What does this mean (taken from /var/log/messages)?
> > >
> > > Sep 23 12:11:22 lisa kernel: dme1737 0-002e: Write to register 0x30 failed! Please report to the driver maintainer.
> >
> > What exactly is unclear about the message? The write fails (for
> > whatever reason). I should probably print out the return value as
> > well...
> > More interestingly is the register address. 0x30 is the current PWM
> > duty-cycle. It only gets written during driver initialization or if
> > userland does manual PWM control.
> >
> > > I get this sometimes (every some hours). I use the dme1737.ko without on my asus system
> > > (Pundit P1-AH2) with Athlon BE-2350.
> >
> > What apps are you running that touch the driver? Are you doing manual
> > PWM control?
> >
>
> I use the script fancontrol from lm-sensors, that controls the cpu-fan by pwm. It works
> fine. Maybe it somtimes fails in setting the fan speed, but can set in the next cycle.
> I newer got error messages from fancontrol.
Aha, that explains it. Can you apply the attached patch and reload the
driver? Could you also please post the output of 'lsmod'?
...juerg
--- dme1737.c.orig 2007-10-01 14:34:13.508278000 -0700
+++ dme1737.c 2007-10-01 14:35:14.041684000 -0700
@@ -493,8 +493,8 @@ static u8 dme1737_read(struct i2c_client
if (val < 0) {
dev_warn(&client->dev, "Read from register "
- "0x%02x failed! Please report to the driver "
- "maintainer.\n", reg);
+ "0x%02x failed (%d)! Please report to the "
+ "driver maintainer.\n", reg, val);
}
} else { /* ISA device */
outb(reg, client->addr);
@@ -513,8 +513,8 @@ static s32 dme1737_write(struct i2c_clie
if (res < 0) {
dev_warn(&client->dev, "Write to register "
- "0x%02x failed! Please report to the driver "
- "maintainer.\n", reg);
+ "0x%02x failed (%d)! Please report to the "
+ "driver maintainer.\n", reg, res);
}
} else { /* ISA device */
outb(reg, client->addr);
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (2 preceding siblings ...)
2007-10-01 21:39 ` Juerg Haefliger
@ 2007-10-01 21:50 ` Jean Delvare
2007-10-08 18:31 ` Juergen Bausa
` (25 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Jean Delvare @ 2007-10-01 21:50 UTC (permalink / raw)
To: lm-sensors
Hi Juerg,
On Mon, 1 Oct 2007 14:39:44 -0700, Juerg Haefliger wrote:
> Aha, that explains it. Can you apply the attached patch and reload the
> driver? Could you also please post the output of 'lsmod'?
>
> ...juerg
>
> --- dme1737.c.orig 2007-10-01 14:34:13.508278000 -0700
> +++ dme1737.c 2007-10-01 14:35:14.041684000 -0700
> @@ -493,8 +493,8 @@ static u8 dme1737_read(struct i2c_client
>
> if (val < 0) {
> dev_warn(&client->dev, "Read from register "
> - "0x%02x failed! Please report to the driver "
> - "maintainer.\n", reg);
> + "0x%02x failed (%d)! Please report to the "
> + "driver maintainer.\n", reg, val);
> }
> } else { /* ISA device */
> outb(reg, client->addr);
> @@ -513,8 +513,8 @@ static s32 dme1737_write(struct i2c_clie
>
> if (res < 0) {
> dev_warn(&client->dev, "Write to register "
> - "0x%02x failed! Please report to the driver "
> - "maintainer.\n", reg);
> + "0x%02x failed (%d)! Please report to the "
> + "driver maintainer.\n", reg, res);
> }
> } else { /* ISA device */
> outb(reg, client->addr);
Unfortunately, most SMBus master drivers return "-1" on error rather
than a sensible error code, so this probably won't help you much. You
would have to fix the underlying bus driver too - this needs to be done
someday anyway.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (3 preceding siblings ...)
2007-10-01 21:50 ` Jean Delvare
@ 2007-10-08 18:31 ` Juergen Bausa
2007-10-09 7:03 ` Jean Delvare
` (24 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Juergen Bausa @ 2007-10-08 18:31 UTC (permalink / raw)
To: lm-sensors
Hi Juerg,
> Von: "Juerg Haefliger" <juergh@gmail.com>
>
> On 10/1/07, Juergen Bausa <Juergen.Bausa@web.de> wrote:
> > Hi Juerg,
> >
> > > Von: "Juerg Haefliger" <juergh@gmail.com>
> > >
> > > On 9/25/07, Juergen Bausa <Juergen.Bausa@web.de> wrote:
> > > > What does this mean (taken from /var/log/messages)?
> > > >
> > > > Sep 23 12:11:22 lisa kernel: dme1737 0-002e: Write to register 0x30 failed! Please report to the driver maintainer.
> > >
> > > > I get this sometimes (every some hours). I use the dme1737.ko without on my asus system
> > > > (Pundit P1-AH2) with Athlon BE-2350.
> > >
> > > What apps are you running that touch the driver? Are you doing manual
> > > PWM control?
> > >
> >
> > I use the script fancontrol from lm-sensors, that controls the cpu-fan by pwm. It works
> > fine. Maybe it somtimes fails in setting the fan speed, but can set in the next cycle.
> > I newer got error messages from fancontrol.
>
> Aha, that explains it. Can you apply the attached patch and reload the
> driver? Could you also please post the output of 'lsmod'?
>
not much information:
/var/log/messages.0:Oct 4 00:17:43 lisa kernel: dme1737 0-002e: Write to register 0x30 failed (-1)! Please report to the driver maintainer.
And here comes lsmod:jba@lisa:~$ lsmod
Module Size Used by
nvidia 4550548 22
agpgart 30216 1 nvidia
nfs 203980 0
cpufreq_userspace 4768 1
nfsd 199856 10
exportfs 6080 1 nfsd
lockd 55240 3 nfs,nfsd
nfs_acl 3904 2 nfs,nfsd
sunrpc 139772 13 nfs,nfsd,lockd,nfs_acl
ppdev 8964 0
lp 11300 0
button 6928 0
ac 5508 0
battery 9924 0
ipv6 228320 12
nls_iso8859_1 4544 1
ntfs 195988 1
dm_snapshot 15904 0
dm_mirror 19600 0
dm_mod 50776 2 dm_snapshot,dm_mirror
dme1737 28884 0
hwmon_vid 3072 1 dme1737
powernow_k8 13696 1
freq_table 4832 1 powernow_k8
kqemu 107908 0
sbp2 21320 0
loop 15496 0
snd_hda_intel 17620 1
snd_hda_codec 138816 1 snd_hda_intel
snd_pcm_oss 39200 0
snd_mixer_oss 15552 1 snd_pcm_oss
snd_pcm 68996 3 snd_hda_intel,snd_hda_codec,snd_pcm_oss
snd_seq_dummy 4164 0
snd_seq_oss 29120 0
snd_seq_midi 8544 0
snd_rawmidi 23200 1 snd_seq_midi
snd_seq_midi_event 7488 2 snd_seq_oss,snd_seq_midi
snd_seq 46224 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
snd_timer 21316 2 snd_pcm,snd_seq
snd_seq_device 8140 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq
parport_pc 32612 1
snd 47524 12 snd_hda_intel,snd_hda_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
parport 33672 3 ppdev,lp,parport_pc
usblp 13120 0
soundcore 9568 1 snd
i2c_nforce2 7232 0
k8temp 5952 0
rtc 12788 0
snd_page_alloc 9928 2 snd_hda_intel,snd_pcm
i2c_core 20096 3 nvidia,dme1737,i2c_nforce2
psmouse 35336 0
serio_raw 6980 0
pcspkr 3392 0
tsdev 7808 0
eth1394 18756 0
evdev 9408 1
ext3 120584 3
jbd 52968 1 ext3
mbcache 8644 1 ext3
ide_cd 36576 0
cdrom 33056 1 ide_cd
sd_mod 19456 6
usbhid 37856 0
usb_storage 72832 0
sata_nv 11332 5
ohci1394 31344 0
ieee1394 88376 3 sbp2,eth1394,ohci1394
forcedeth 38788 0
amd74xx 13340 0 [permanent]
ehci_hcd 28488 0
libata 90772 1 sata_nv
scsi_mod 124872 4 sbp2,sd_mod,usb_storage,libata
ohci_hcd 18564 0
generic 5188 0 [permanent]
ide_core 110984 4 ide_cd,usb_storage,amd74xx,generic
usbcore 113412 6 usblp,usbhid,usb_storage,ehci_hcd,ohci_hcd
thermal 13896 0
processor 29128 2 powernow_k8,thermal
fan 5124 0
Juergen
_________________________________________________________________________
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten!
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc\x021114
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (4 preceding siblings ...)
2007-10-08 18:31 ` Juergen Bausa
@ 2007-10-09 7:03 ` Jean Delvare
2007-10-09 16:08 ` Juerg Haefliger
` (23 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Jean Delvare @ 2007-10-09 7:03 UTC (permalink / raw)
To: lm-sensors
On Mon, 08 Oct 2007 20:31:55 +0200, Juergen Bausa wrote:
> > Aha, that explains it. Can you apply the attached patch and reload the
> > driver? Could you also please post the output of 'lsmod'?
>
> not much information:
> /var/log/messages.0:Oct 4 00:17:43 lisa kernel: dme1737 0-002e: Write to register 0x30 failed (-1)! Please report to the driver maintainer.
As I expected...
> i2c_nforce2 7232 0
Juerg, you could patch i2c-nforce2 to return more useful error codes.
Such a patch could go upstream. Alternatively, building the i2c-nforce2
driver with CONFIG_I2C_DEBUG_BUS=y may provide some hints.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (5 preceding siblings ...)
2007-10-09 7:03 ` Jean Delvare
@ 2007-10-09 16:08 ` Juerg Haefliger
2007-10-09 19:41 ` Juergen Bausa
` (22 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Juerg Haefliger @ 2007-10-09 16:08 UTC (permalink / raw)
To: lm-sensors
Jean, Juergen,
On 10/9/07, Jean Delvare <khali@linux-fr.org> wrote:
> On Mon, 08 Oct 2007 20:31:55 +0200, Juergen Bausa wrote:
> > > Aha, that explains it. Can you apply the attached patch and reload the
> > > driver? Could you also please post the output of 'lsmod'?
> >
> > not much information:
> > /var/log/messages.0:Oct 4 00:17:43 lisa kernel: dme1737 0-002e: Write to register 0x30 failed (-1)! Please report to the driver maintainer.
>
> As I expected...
>
> > i2c_nforce2 7232 0
Yes, I looked at the driver and it indeed only returns -1 on error.
> Juerg, you could patch i2c-nforce2 to return more useful error codes.
> Such a patch could go upstream. Alternatively, building the i2c-nforce2
> driver with CONFIG_I2C_DEBUG_BUS=y may provide some hints.
I was thinking of doing that. First I have to try to recreate the
problem on my machine.
Juergen: Do you feel like recompiling i2c_nforce2 with debugging enabled?
...juerg
> --
> Jean Delvare
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (6 preceding siblings ...)
2007-10-09 16:08 ` Juerg Haefliger
@ 2007-10-09 19:41 ` Juergen Bausa
2007-10-10 17:12 ` Juerg Haefliger
` (21 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Juergen Bausa @ 2007-10-09 19:41 UTC (permalink / raw)
To: lm-sensors
> -----Ursprüngliche Nachricht-----
> Von: "Juerg Haefliger" <juergh@gmail.com>
>
> > Juerg, you could patch i2c-nforce2 to return more useful error codes.
> > Such a patch could go upstream. Alternatively, building the i2c-nforce2
> > driver with CONFIG_I2C_DEBUG_BUS=y may provide some hints.
>
> I was thinking of doing that. First I have to try to recreate the
> problem on my machine.
>
> Juergen: Do you feel like recompiling i2c_nforce2 with debugging enabled?
>
This would require compiling a single module and exchanging it against the default
debian module? Then ist no problem. Is it ok to use the debian sources (2.6.18-5-k7)?
And how to turn on debugging?
Juergen
_______________________________________________________________________
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc\x022220
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (7 preceding siblings ...)
2007-10-09 19:41 ` Juergen Bausa
@ 2007-10-10 17:12 ` Juerg Haefliger
2007-10-11 7:45 ` Jean Delvare
` (20 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Juerg Haefliger @ 2007-10-10 17:12 UTC (permalink / raw)
To: lm-sensors
Hu Juergen,
On 10/9/07, Juergen Bausa <Juergen.Bausa@web.de> wrote:
>
> > -----Ursprüngliche Nachricht-----
> > Von: "Juerg Haefliger" <juergh@gmail.com>
> >
> > > Juerg, you could patch i2c-nforce2 to return more useful error codes.
> > > Such a patch could go upstream. Alternatively, building the i2c-nforce2
> > > driver with CONFIG_I2C_DEBUG_BUS=y may provide some hints.
> >
> > I was thinking of doing that. First I have to try to recreate the
> > problem on my machine.
> >
> > Juergen: Do you feel like recompiling i2c_nforce2 with debugging enabled?
> >
>
> This would require compiling a single module and exchanging it against the default
> debian module? Then ist no problem. Is it ok to use the debian sources (2.6.18-5-k7)?
I believe so.
> And how to turn on debugging?
I don't know if there's an easier way but I usually do it the following way:
1) copy the i2c-nforce2.c file from the kernel source to a temp dir.
2) add a Makefile to the temp dir with the following content:
obj-m := i2c-nforce2.o
EXTRA_CFLAGS += -DDEBUG
all:
make -C /lib/modules/`uname -r`/build M=`pwd` modules
3) compile the module by running make
4) reload the new module. You have to remove the dme1737 module before
unloading the i2c-nforce2 module.
...juerg
> Juergen
> _______________________________________________________________________
> Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate
> kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc\x022220
>
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (8 preceding siblings ...)
2007-10-10 17:12 ` Juerg Haefliger
@ 2007-10-11 7:45 ` Jean Delvare
2007-10-17 18:56 ` Juergen Bausa
` (19 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Jean Delvare @ 2007-10-11 7:45 UTC (permalink / raw)
To: lm-sensors
Hi Juerg,
On Wed, 10 Oct 2007 10:12:05 -0700, Juerg Haefliger wrote:
> I don't know if there's an easier way but I usually do it the following way:
> 1) copy the i2c-nforce2.c file from the kernel source to a temp dir.
> 2) add a Makefile to the temp dir with the following content:
>
> obj-m := i2c-nforce2.o
> EXTRA_CFLAGS += -DDEBUG
> all:
> make -C /lib/modules/`uname -r`/build M=`pwd` modules
>
> 3) compile the module by running make
> 4) reload the new module. You have to remove the dme1737 module before
> unloading the i2c-nforce2 module.
You don't actually have to remove the dme1737 module. The i2c subsystem
is designed is such a way that bus drivers and chip drivers can be
loaded in any order.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (9 preceding siblings ...)
2007-10-11 7:45 ` Jean Delvare
@ 2007-10-17 18:56 ` Juergen Bausa
2007-10-17 19:43 ` Juerg Haefliger
` (18 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Juergen Bausa @ 2007-10-17 18:56 UTC (permalink / raw)
To: lm-sensors
Jean, Juerg,
> -----Ursprüngliche Nachricht-----
> Von: "Juerg Haefliger" <juergh@gmail.com>
> Gesendet: 09.10.07 18:08:33
> An: "Jean Delvare" <khali@linux-fr.org>
> CC: lm-sensors@lm-sensors.org
> Betreff: Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
> > >
> > > not much information:
> > > /var/log/messages.0:Oct 4 00:17:43 lisa kernel: dme1737 0-002e: Write to register 0x30 failed (-1)! Please report to the driver maintainer.
> >
> > As I expected...
> >
> > > i2c_nforce2 7232 0
>
> Yes, I looked at the driver and it indeed only returns -1 on error.
>
> > Juerg, you could patch i2c-nforce2 to return more useful error codes.
> > Such a patch could go upstream. Alternatively, building the i2c-nforce2
> > driver with CONFIG_I2C_DEBUG_BUS=y may provide some hints.
>
> I was thinking of doing that. First I have to try to recreate the
> problem on my machine.
>
> Juergen: Do you feel like recompiling i2c_nforce2 with debugging enabled?
>
Here is what I found in /var/log:
/var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: nForce2 SMBus adapter at 0x4c00
/var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-1: nForce2 SMBus adapter at 0x4c40
/var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: Found a DME1737 chip at 0x2e (rev 0x8a)
/var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x10)
/var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x10)
/var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-1: SMBus Timeout! (0x10)
/var/log/debug:Oct 17 19:35:30 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x1a)
/var/log/messages:Oct 17 09:16:00 lisa kernel: dme1737 0-002e: Optional features: pwm3=yes, pwm5=no, pwm6=no, fan3=no, fan4=yes, fan5=no, fan6=no.
/var/log/messages:Oct 17 19:35:30 lisa kernel: dme1737 0-002e: Write to register 0x30 failed (-1)! Please report to the driver maintainer.
Juergen
_______________________________________________________________________
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc\x022220
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (10 preceding siblings ...)
2007-10-17 18:56 ` Juergen Bausa
@ 2007-10-17 19:43 ` Juerg Haefliger
2007-10-17 21:32 ` Jean Delvare
` (17 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Juerg Haefliger @ 2007-10-17 19:43 UTC (permalink / raw)
To: lm-sensors
Hi Juergen,
On 10/17/07, Juergen Bausa <Juergen.Bausa@web.de> wrote:
> Jean, Juerg,
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: "Juerg Haefliger" <juergh@gmail.com>
> > Gesendet: 09.10.07 18:08:33
> > An: "Jean Delvare" <khali@linux-fr.org>
> > CC: lm-sensors@lm-sensors.org
> > Betreff: Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
>
>
> > > >
> > > > not much information:
> > > > /var/log/messages.0:Oct 4 00:17:43 lisa kernel: dme1737 0-002e: Write to register 0x30 failed (-1)! Please report to the driver maintainer.
> > >
> > > As I expected...
> > >
> > > > i2c_nforce2 7232 0
> >
> > Yes, I looked at the driver and it indeed only returns -1 on error.
> >
> > > Juerg, you could patch i2c-nforce2 to return more useful error codes.
> > > Such a patch could go upstream. Alternatively, building the i2c-nforce2
> > > driver with CONFIG_I2C_DEBUG_BUS=y may provide some hints.
> >
> > I was thinking of doing that. First I have to try to recreate the
> > problem on my machine.
> >
> > Juergen: Do you feel like recompiling i2c_nforce2 with debugging enabled?
> >
>
> Here is what I found in /var/log:
>
> /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: nForce2 SMBus adapter at 0x4c00
> /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-1: nForce2 SMBus adapter at 0x4c40
> /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: Found a DME1737 chip at 0x2e (rev 0x8a)
>
> /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x10)
> /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x10)
> /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-1: SMBus Timeout! (0x10)
These are all errors that occur when the drivers (i2c and dme1737) get
loaded. The dme1737 is not printing any errors so they are not
transactions initiated by the dme1737. The 0x10 means "SMBus Device
Address Not Acknowledged" according to the ACPI spec. Not sure how
this can happen... Signal integrity problems on the board level? In
any case, these errors should probably be retried. Not sure at what
level though. Jean?
> /var/log/debug:Oct 17 19:35:30 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x1a)
>
> /var/log/messages:Oct 17 09:16:00 lisa kernel: dme1737 0-002e: Optional features: pwm3=yes, pwm5=no, pwm6=no, fan3=no, fan4=yes, fan5=no, fan6=no.
> /var/log/messages:Oct 17 19:35:30 lisa kernel: dme1737 0-002e: Write to register 0x30 failed (-1)! Please report to the driver maintainer.
Aha, this is an error as a result of a dme1737 initiated write. 0x1a
means "SMBus Busy". So the dme1737 driver is colliding with something
else in the system that tries to talk to a chip on the same bus. That
should definitely get retried. I can certainly do that at the dme1737
level but I don't think that's the right place. Jean?
...juerg
> Juergen
> _______________________________________________________________________
> Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate
> kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc\x022220
>
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (11 preceding siblings ...)
2007-10-17 19:43 ` Juerg Haefliger
@ 2007-10-17 21:32 ` Jean Delvare
2007-10-18 4:53 ` Juerg Haefliger
` (16 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Jean Delvare @ 2007-10-17 21:32 UTC (permalink / raw)
To: lm-sensors
Hi Juerg,
On Wed, 17 Oct 2007 12:43:16 -0700, Juerg Haefliger wrote:
> On 10/17/07, Juergen Bausa <Juergen.Bausa@web.de> wrote:
> > Here is what I found in /var/log:
> >
> > /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: nForce2 SMBus adapter at 0x4c00
> > /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-1: nForce2 SMBus adapter at 0x4c40
> > /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: Found a DME1737 chip at 0x2e (rev 0x8a)
> >
> > /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x10)
> > /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x10)
> > /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-1: SMBus Timeout! (0x10)
>
> These are all errors that occur when the drivers (i2c and dme1737) get
> loaded. The dme1737 is not printing any errors so they are not
> transactions initiated by the dme1737. The 0x10 means "SMBus Device
> Address Not Acknowledged" according to the ACPI spec. Not sure how
> this can happen... Signal integrity problems on the board level? In
> any case, these errors should probably be retried. Not sure at what
> level though. Jean?
These are not errors at all, it's only i2c-core probing at work. The
dme1737 driver specifies three possible addresses (0x2c, 0x2d, 0x2e),
the probes at 0x2c and 0x2d on bus 0 fail, these are the first two
"SMBus Timeout!" messages above. Then the probe at 0x2e succeeds. Then
i2c-core goes on with bus 1. There should have been 3 failing probes
there, but surprisingly, there's only one "SMBus Timeout!" for bus 1. I
can't explain it.
Juergen, can you please attach the output of:
modprobe i2c-dev
i2cdetect -y 0
i2cdetect -y 1
Either way these 3 log messages can safely be ignored.
> > /var/log/debug:Oct 17 19:35:30 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x1a)
> >
> > /var/log/messages:Oct 17 09:16:00 lisa kernel: dme1737 0-002e: Optional features: pwm3=yes, pwm5=no, pwm6=no, fan3=no, fan4=yes, fan5=no, fan6=no.
> > /var/log/messages:Oct 17 19:35:30 lisa kernel: dme1737 0-002e: Write to register 0x30 failed (-1)! Please report to the driver maintainer.
>
> Aha, this is an error as a result of a dme1737 initiated write. 0x1a
> means "SMBus Busy". So the dme1737 driver is colliding with something
> else in the system that tries to talk to a chip on the same bus.
This can only happen on a multi-master I2C bus, which is rather rare on
consumer PCs. Juergen, do you have detailed technical documentation
about your system? It would be interesting to find out what chip the
other master is talking to. If it's the DME1737 chip, this could lead
to problems.
> That
> should definitely get retried. I can certainly do that at the dme1737
> level but I don't think that's the right place. Jean?
Assuming that "busy" means that the nForce chip did not even attempt to
send the message (or lost arbitration, which is equivalent), this
specific error could be handled in i2c-nforce2, by retrying. The
problem is that you have to decide how many times you retry, and how
much time you wait between retries (there doesn't seem to be a way to
test if the SMBus is busy before trying, right?)
We have "timeout" and "retries" fields in struct i2c_adapter, which
could be used for this. The meaning of "retries" is a bit different
though, it's supposed to be the number of nacks the bus driver accepts
when attempting to contact a chip before giving up. This doesn't appear
to be very useful though so I wouldn't mind recycling this field for
the more interesting usage you need. Most bus drivers don't set nor use
"timeout".
As a first aid solution, you could simply hardcode the timeout and
retry values, just to confirm that it solves Juergen's problem. Then
we can see how to make it cleaner. Error handling is an area where the
i2c subsystem needs to be improved.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (12 preceding siblings ...)
2007-10-17 21:32 ` Jean Delvare
@ 2007-10-18 4:53 ` Juerg Haefliger
2007-10-19 15:07 ` Jean Delvare
` (15 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Juerg Haefliger @ 2007-10-18 4:53 UTC (permalink / raw)
To: lm-sensors
[-- Attachment #1: Type: text/plain, Size: 5270 bytes --]
Hi Jean, Juergen,
On 10/17/07, Jean Delvare <khali@linux-fr.org> wrote:
> Hi Juerg,
>
> On Wed, 17 Oct 2007 12:43:16 -0700, Juerg Haefliger wrote:
> > On 10/17/07, Juergen Bausa <Juergen.Bausa@web.de> wrote:
> > > Here is what I found in /var/log:
> > >
> > > /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: nForce2 SMBus adapter at 0x4c00
> > > /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-1: nForce2 SMBus adapter at 0x4c40
> > > /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: Found a DME1737 chip at 0x2e (rev 0x8a)
> > >
> > > /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x10)
> > > /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x10)
> > > /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-1: SMBus Timeout! (0x10)
> >
> > These are all errors that occur when the drivers (i2c and dme1737) get
> > loaded. The dme1737 is not printing any errors so they are not
> > transactions initiated by the dme1737. The 0x10 means "SMBus Device
> > Address Not Acknowledged" according to the ACPI spec. Not sure how
> > this can happen... Signal integrity problems on the board level? In
> > any case, these errors should probably be retried. Not sure at what
> > level though. Jean?
>
> These are not errors at all, it's only i2c-core probing at work. The
> dme1737 driver specifies three possible addresses (0x2c, 0x2d, 0x2e),
> the probes at 0x2c and 0x2d on bus 0 fail, these are the first two
> "SMBus Timeout!" messages above. Then the probe at 0x2e succeeds. Then
> i2c-core goes on with bus 1. There should have been 3 failing probes
> there, but surprisingly, there's only one "SMBus Timeout!" for bus 1. I
> can't explain it.
>
> Juergen, can you please attach the output of:
>
> modprobe i2c-dev
> i2cdetect -y 0
> i2cdetect -y 1
Ah, Jean, you're certainly right! On my machine, I get the following
when loading the driver:
Oct 17 21:38:09 localhost kernel: i2c-adapter i2c-0: SMBus Timeout! (0x10)
Oct 17 21:38:09 localhost kernel: i2c-adapter i2c-0: SMBus Timeout! (0x10)
Oct 17 21:38:09 localhost kernel: dme1737 0-002e: Found a DME1737 chip
at 0x2e (rev 0x8a).
Oct 17 21:38:09 localhost kernel: dme1737 0-002e: Optional features:
pwm3=yes, pwm5=no, pwm6=no, fan3=no, fan4=yes, fan5=no, fan6=no.
Oct 17 21:38:09 localhost kernel: i2c-adapter i2c-0: nForce2 SMBus
adapter at 0x4c00
Oct 17 21:38:09 localhost kernel: i2c-adapter i2c-1: SMBus Timeout! (0x10)
Oct 17 21:38:09 localhost last message repeated 2 times
Oct 17 21:38:09 localhost kernel: i2c-adapter i2c-1: nForce2 SMBus
adapter at 0x4c40
> Either way these 3 log messages can safely be ignored.
>
> > > /var/log/debug:Oct 17 19:35:30 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x1a)
> > >
> > > /var/log/messages:Oct 17 09:16:00 lisa kernel: dme1737 0-002e: Optional features: pwm3=yes, pwm5=no, pwm6=no, fan3=no, fan4=yes, fan5=no, fan6=no.
> > > /var/log/messages:Oct 17 19:35:30 lisa kernel: dme1737 0-002e: Write to register 0x30 failed (-1)! Please report to the driver maintainer.
> >
> > Aha, this is an error as a result of a dme1737 initiated write. 0x1a
> > means "SMBus Busy". So the dme1737 driver is colliding with something
> > else in the system that tries to talk to a chip on the same bus.
>
> This can only happen on a multi-master I2C bus, which is rather rare on
> consumer PCs. Juergen, do you have detailed technical documentation
> about your system? It would be interesting to find out what chip the
> other master is talking to. If it's the DME1737 chip, this could lead
> to problems.
Hmm... What about ACPI? Couldn't it interfere with the dme1737 module
by going after the same resources.
> > That
> > should definitely get retried. I can certainly do that at the dme1737
> > level but I don't think that's the right place. Jean?
>
> Assuming that "busy" means that the nForce chip did not even attempt to
> send the message (or lost arbitration, which is equivalent), this
> specific error could be handled in i2c-nforce2, by retrying. The
> problem is that you have to decide how many times you retry, and how
> much time you wait between retries (there doesn't seem to be a way to
> test if the SMBus is busy before trying, right?)
The i2c-nforce2 driver already spins for 10 msecs before deciding to
give up. I'd just retry once after that and see what happens.
Juergen: Can you apply the attached patch and give it a whirl?
...juerg
> We have "timeout" and "retries" fields in struct i2c_adapter, which
> could be used for this. The meaning of "retries" is a bit different
> though, it's supposed to be the number of nacks the bus driver accepts
> when attempting to contact a chip before giving up. This doesn't appear
> to be very useful though so I wouldn't mind recycling this field for
> the more interesting usage you need. Most bus drivers don't set nor use
> "timeout".
>
> As a first aid solution, you could simply hardcode the timeout and
> retry values, just to confirm that it solves Juergen's problem. Then
> we can see how to make it cleaner. Error handling is an area where the
> i2c subsystem needs to be improved.
>
> --
> Jean Delvare
>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: i2c-nforce2-retry-if-busy.patch --]
[-- Type: text/x-patch; name=i2c-nforce2-retry-if-busy.patch, Size: 1063 bytes --]
Index: linux-2.6.23/drivers/i2c/busses/i2c-nforce2.c
===================================================================
--- linux-2.6.23.orig/drivers/i2c/busses/i2c-nforce2.c 2007-10-17 21:30:23.000000000 -0700
+++ linux-2.6.23/drivers/i2c/busses/i2c-nforce2.c 2007-10-17 21:54:23.000000000 -0700
@@ -168,18 +168,22 @@
}
outb_p((addr & 0x7f) << 1, NVIDIA_SMB_ADDR);
- outb_p(protocol, NVIDIA_SMB_PRTCL);
- temp = inb_p(NVIDIA_SMB_STS);
+ i = 1;
+ do {
+ outb_p(protocol, NVIDIA_SMB_PRTCL);
- if (~temp & NVIDIA_SMB_STS_DONE) {
- udelay(500);
temp = inb_p(NVIDIA_SMB_STS);
- }
- if (~temp & NVIDIA_SMB_STS_DONE) {
- msleep(10);
- temp = inb_p(NVIDIA_SMB_STS);
- }
+
+ if (~temp & NVIDIA_SMB_STS_DONE) {
+ udelay(500);
+ temp = inb_p(NVIDIA_SMB_STS);
+ }
+ if (~temp & NVIDIA_SMB_STS_DONE) {
+ msleep(10);
+ temp = inb_p(NVIDIA_SMB_STS);
+ }
+ } while (i-- && (temp & NVIDIA_SMB_STS_STATUS) == 0x1a);
if ((~temp & NVIDIA_SMB_STS_DONE) || (temp & NVIDIA_SMB_STS_STATUS)) {
dev_dbg(&adap->dev, "SMBus Timeout! (0x%02x)\n", temp);
[-- Attachment #3: Type: text/plain, Size: 153 bytes --]
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (13 preceding siblings ...)
2007-10-18 4:53 ` Juerg Haefliger
@ 2007-10-19 15:07 ` Jean Delvare
2007-10-20 19:28 ` Juergen Bausa
` (14 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Jean Delvare @ 2007-10-19 15:07 UTC (permalink / raw)
To: lm-sensors
Hi Juerg,
On Wed, 17 Oct 2007 21:53:42 -0700, Juerg Haefliger wrote:
> On 10/17/07, Jean Delvare <khali@linux-fr.org> wrote:
> > On Wed, 17 Oct 2007 12:43:16 -0700, Juerg Haefliger wrote:
> > > Aha, this is an error as a result of a dme1737 initiated write. 0x1a
> > > means "SMBus Busy". So the dme1737 driver is colliding with something
> > > else in the system that tries to talk to a chip on the same bus.
> >
> > This can only happen on a multi-master I2C bus, which is rather rare on
> > consumer PCs. Juergen, do you have detailed technical documentation
> > about your system? It would be interesting to find out what chip the
> > other master is talking to. If it's the DME1737 chip, this could lead
> > to problems.
>
> Hmm... What about ACPI? Couldn't it interfere with the dme1737 module
> by going after the same resources.
It could, but I just can't think of a valid reason why ACPI wouldn't
use the nForce2 SMBus controller itself.
Are you certain that the "busy" error code means that the *bus* is
busy? Doesn't it rather mean that the *nForce SMBus controller* itself
is busy (i.e. the previous command is still being processed)? The latter
would indeed suggest that ACPI is running SMBus transactions in our
back, which would be a problem. At least, if the SMBus controller lets
us know, we'll avoid corruption, but bad things can still happen.
Juergen, if you load the "thermal" driver and look
in /proc/acpi/thermal_zone, do you see a temperature reported, with the
same value as one of the DME1737 temperature channels?
If you unload the "thermal" driver, do the dme1737 write errors go away?
> > Assuming that "busy" means that the nForce chip did not even attempt to
> > send the message (or lost arbitration, which is equivalent), this
> > specific error could be handled in i2c-nforce2, by retrying. The
> > problem is that you have to decide how many times you retry, and how
> > much time you wait between retries (there doesn't seem to be a way to
> > test if the SMBus is busy before trying, right?)
>
> The i2c-nforce2 driver already spins for 10 msecs before deciding to
> give up. I'd just retry once after that and see what happens.
Depends on what kernel Juergen is running. Oleg Ryjkov has submitted
interesting patches that clean up this part of the i2c-nforce2 driver:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;hA53549734cbdba24e9cf5eb200b70b7b1572e15
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h‘9584c4a37c7228e7778bcb60f79e7a08472fa8
These are already in Linus' tree for 2.6.24.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (14 preceding siblings ...)
2007-10-19 15:07 ` Jean Delvare
@ 2007-10-20 19:28 ` Juergen Bausa
2007-10-20 19:39 ` Juergen Bausa
` (13 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Juergen Bausa @ 2007-10-20 19:28 UTC (permalink / raw)
To: lm-sensors
> Von: Jean Delvare <khali@linux-fr.org>
> Gesendet: 17.10.07 23:32:28
>
> On Wed, 17 Oct 2007 12:43:16 -0700, Juerg Haefliger wrote:
> > On 10/17/07, Juergen Bausa <Juergen.Bausa@web.de> wrote:
> > > Here is what I found in /var/log:
> > >
> > > /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: nForce2 SMBus adapter at 0x4c00
> > > /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-1: nForce2 SMBus adapter at 0x4c40
> > > /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: Found a DME1737 chip at 0x2e (rev 0x8a)
> > >
> > > /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x10)
> > > /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x10)
> > > /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-1: SMBus Timeout! (0x10)
> >
> > These are all errors that occur when the drivers (i2c and dme1737) get
> > loaded. The dme1737 is not printing any errors so they are not
> > transactions initiated by the dme1737. The 0x10 means "SMBus Device
> > Address Not Acknowledged" according to the ACPI spec. Not sure how
> > this can happen... Signal integrity problems on the board level? In
> > any case, these errors should probably be retried. Not sure at what
> > level though. Jean?
>
> These are not errors at all, it's only i2c-core probing at work. The
> dme1737 driver specifies three possible addresses (0x2c, 0x2d, 0x2e),
> the probes at 0x2c and 0x2d on bus 0 fail, these are the first two
> "SMBus Timeout!" messages above. Then the probe at 0x2e succeeds. Then
> i2c-core goes on with bus 1. There should have been 3 failing probes
> there, but surprisingly, there's only one "SMBus Timeout!" for bus 1. I
> can't explain it.
I greped the mesages. Maybe, there was a 'message repeated xx times' in the log, that wasnt displayed.
>
> Juergen, can you please attach the output of:
>
> modprobe i2c-dev
> i2cdetect -y 0
> i2cdetect -y 1
lisa:/home/jba# modprobe i2c-dev
lisa:/home/jba# i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- 08 -- -- -- -- 0d -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU --
30: 30 31 -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
lisa:/home/jba# i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
lisa:/home/jba#
>
> Either way these 3 log messages can safely be ignored.
>
> > > /var/log/debug:Oct 17 19:35:30 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x1a)
> > >
> > > /var/log/messages:Oct 17 09:16:00 lisa kernel: dme1737 0-002e: Optional features: pwm3=yes, pwm5=no, pwm6=no, fan3=no, fan4=yes, fan5=no, fan6=no.
> > > /var/log/messages:Oct 17 19:35:30 lisa kernel: dme1737 0-002e: Write to register 0x30 failed (-1)! Please report to the driver maintainer.
> >
> > Aha, this is an error as a result of a dme1737 initiated write. 0x1a
> > means "SMBus Busy". So the dme1737 driver is colliding with something
> > else in the system that tries to talk to a chip on the same bus.
>
> This can only happen on a multi-master I2C bus, which is rather rare on
> consumer PCs. Juergen, do you have detailed technical documentation
> about your system? It would be interesting to find out what chip the
> other master is talking to. If it's the DME1737 chip, this could lead
> to problems.
No. I dont have detailes information. Its an asus barebone.
Asus borads have a feature called 'ASUS Q-Fan Technology'. Its a BIOS-based controller for the
FAN/CPU-temperature. This is turned on in the bios. However, when booting linux, the script
'fancontrol' is started and then controls cpu-temperature. Maybe the Q-fan still tries to access
the fan and this is the reason for the collision?
>
> > That
> > should definitely get retried. I can certainly do that at the dme1737
> > level but I don't think that's the right place. Jean?
>
> Assuming that "busy" means that the nForce chip did not even attempt to
> send the message (or lost arbitration, which is equivalent), this
> specific error could be handled in i2c-nforce2, by retrying. The
> problem is that you have to decide how many times you retry, and how
> much time you wait between retries (there doesn't seem to be a way to
> test if the SMBus is busy before trying, right?)
>
> We have "timeout" and "retries" fields in struct i2c_adapter, which
> could be used for this. The meaning of "retries" is a bit different
> though, it's supposed to be the number of nacks the bus driver accepts
> when attempting to contact a chip before giving up. This doesn't appear
> to be very useful though so I wouldn't mind recycling this field for
> the more interesting usage you need. Most bus drivers don't set nor use
> "timeout".
>
> As a first aid solution, you could simply hardcode the timeout and
> retry values, just to confirm that it solves Juergen's problem. Then
> we can see how to make it cleaner. Error handling is an area where the
> i2c subsystem needs to be improved.
>
Just to make it clear: The messages are no real problem. fancontrol is working very fine.
Maybe its not successful in setting fan speed sometimes (once a day). But it just sets thge
fan speed in the next iteration 5 seconds later. Thats no problem.
However, I am also interested in the solution of this.
Juergen
__________________________________________________________________________
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!
Mehr Infos unter http://produkte.web.de/club/?mc\x021131
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (15 preceding siblings ...)
2007-10-20 19:28 ` Juergen Bausa
@ 2007-10-20 19:39 ` Juergen Bausa
2007-10-21 18:40 ` Mark M. Hoffman
` (12 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Juergen Bausa @ 2007-10-20 19:39 UTC (permalink / raw)
To: lm-sensors
> -----Ursprüngliche Nachricht-----
> Von: Jean Delvare <khali@linux-fr.org>
> On Wed, 17 Oct 2007 21:53:42 -0700, Juerg Haefliger wrote:
> > On 10/17/07, Jean Delvare <khali@linux-fr.org> wrote:
> > > On Wed, 17 Oct 2007 12:43:16 -0700, Juerg Haefliger wrote:
> > > > Aha, this is an error as a result of a dme1737 initiated write. 0x1a
> > > > means "SMBus Busy". So the dme1737 driver is colliding with something
> > > > else in the system that tries to talk to a chip on the same bus.
> > >
> > > This can only happen on a multi-master I2C bus, which is rather rare on
> > > consumer PCs. Juergen, do you have detailed technical documentation
> > > about your system? It would be interesting to find out what chip the
> > > other master is talking to. If it's the DME1737 chip, this could lead
> > > to problems.
> >
> > Hmm... What about ACPI? Couldn't it interfere with the dme1737 module
> > by going after the same resources.
>
> It could, but I just can't think of a valid reason why ACPI wouldn't
> use the nForce2 SMBus controller itself.
>
> Are you certain that the "busy" error code means that the *bus* is
> busy? Doesn't it rather mean that the *nForce SMBus controller* itself
> is busy (i.e. the previous command is still being processed)? The latter
> would indeed suggest that ACPI is running SMBus transactions in our
> back, which would be a problem. At least, if the SMBus controller lets
> us know, we'll avoid corruption, but bad things can still happen.
>
> Juergen, if you load the "thermal" driver and look
> in /proc/acpi/thermal_zone, do you see a temperature reported, with the
> same value as one of the DME1737 temperature channels?
>
Yes, I see a temperature, but its not the same.
lisa:/home/jba# cat /proc/acpi/thermal_zone/THRM/temperature
temperature: 40 C
lisa:/home/jba# sensors
k8temp-pci-00c3
Adapter: PCI adapter
Core0 Temp:
+44°C
Core0 Temp:
+46°C
Core1 Temp:
+52°C
Core1 Temp:
+49°C
dme1737-i2c-0-2e
Adapter: SMBus nForce2 adapter at 4c00
V5stby: +0.00 V (min = +0.00 V, max = +6.64 V) ALARM
Vccp: +1.09 V (min = +0.00 V, max = +2.99 V)
V3.3: +3.27 V (min = +0.00 V, max = +4.38 V)
V5: +4.93 V (min = +0.00 V, max = +6.64 V)
V12: +11.78 V (min = +0.00 V, max = +15.94 V)
V3.3stby: +3.28 V (min = +0.00 V, max = +4.38 V)
Vbat: +2.98 V (min = +0.00 V, max = +4.38 V)
Int Temp: +32°C (low = -127°C, high = +127°C)
CPU Temp: +30°C (low = -127°C, high = +127°C)
CPU_Fan: 0 RPM (min = 0 RPM)
ERROR: Can't get fan3 data!
ERROR: Can't get fan5 data!
ERROR: Can't get fan6 data!
CPU_PWM: 0 (enable = 1, freq = 25000 Hz)
ERROR: Can't get pwm5 data!
ERROR: Can't get pwm6 data!
cpu0_vid: +1.550 V (VRM Version 2.4)
lisa:/home/jba#
> If you unload the "thermal" driver, do the dme1737 write errors go away?
I will try this. I am not sure, but dont think thermal was loaded.
>
> > > Assuming that "busy" means that the nForce chip did not even attempt to
> > > send the message (or lost arbitration, which is equivalent), this
> > > specific error could be handled in i2c-nforce2, by retrying. The
> > > problem is that you have to decide how many times you retry, and how
> > > much time you wait between retries (there doesn't seem to be a way to
> > > test if the SMBus is busy before trying, right?)
> >
> > The i2c-nforce2 driver already spins for 10 msecs before deciding to
> > give up. I'd just retry once after that and see what happens.
>
> Depends on what kernel Juergen is running. Oleg Ryjkov has submitted
lisa:/home/jba# uname -r
2.6.18-5-k7
Its a stock debian etch kernel.
> interesting patches that clean up this part of the i2c-nforce2 driver:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;hA53549734cbdba24e9cf5eb200b70b7b1572e15
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;hÔ9584c4a37c7228e7778bcb60f79e7a08472fa8
> These are already in Linus' tree for 2.6.24.
>
Juergen
_______________________________________________________________________
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc\x022220
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (16 preceding siblings ...)
2007-10-20 19:39 ` Juergen Bausa
@ 2007-10-21 18:40 ` Mark M. Hoffman
2007-10-21 19:14 ` Jean Delvare
` (11 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Mark M. Hoffman @ 2007-10-21 18:40 UTC (permalink / raw)
To: lm-sensors
Hi:
> > Von: Jean Delvare <khali@linux-fr.org>
> > Gesendet: 17.10.07 23:32:28
> >
> > This can only happen on a multi-master I2C bus, which is rather rare on
> > consumer PCs. Juergen, do you have detailed technical documentation
> > about your system? It would be interesting to find out what chip the
> > other master is talking to. If it's the DME1737 chip, this could lead
> > to problems.
* Juergen Bausa <Juergen.Bausa@web.de> [2007-10-20 21:28:02 +0200]:
> No. I dont have detailes information. Its an asus barebone.
>
> Asus borads have a feature called 'ASUS Q-Fan Technology'. Its a BIOS-based controller for the
> FAN/CPU-temperature. This is turned on in the bios. However, when booting linux, the script
> 'fancontrol' is started and then controls cpu-temperature. Maybe the Q-fan still tries to access
> the fan and this is the reason for the collision?
Unlikely. I have several Asus boards... in all cases, "Q-fan" is merely their
rebranding of whatever automatic fan control is supported by the sensor chip.
I.e. the BIOS may allow you to set up some automatic fan control of the sensor
chip, but after initialization the BIOS has nothing more to do with it.
Of course it's *possible* that your board is different than all of mine and
that there is active BIOS control. But again, *unlikely*.
Regards,
--
Mark M. Hoffman
mhoffman@lightlink.com
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (17 preceding siblings ...)
2007-10-21 18:40 ` Mark M. Hoffman
@ 2007-10-21 19:14 ` Jean Delvare
2007-10-21 19:37 ` Jean Delvare
` (10 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Jean Delvare @ 2007-10-21 19:14 UTC (permalink / raw)
To: lm-sensors
Hi Juergen,
On Sat, 20 Oct 2007 21:28:02 +0200, Juergen Bausa wrote:
>
> > Von: Jean Delvare <khali@linux-fr.org>
> > Gesendet: 17.10.07 23:32:28
> >
> > On Wed, 17 Oct 2007 12:43:16 -0700, Juerg Haefliger wrote:
> > > On 10/17/07, Juergen Bausa <Juergen.Bausa@web.de> wrote:
> > > > Here is what I found in /var/log:
> > > >
> > > > /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: nForce2 SMBus adapter at 0x4c00
> > > > /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-1: nForce2 SMBus adapter at 0x4c40
> > > > /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: Found a DME1737 chip at 0x2e (rev 0x8a)
> > > >
> > > > /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x10)
> > > > /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x10)
> > > > /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-1: SMBus Timeout! (0x10)
> > >
> > > These are all errors that occur when the drivers (i2c and dme1737) get
> > > loaded. The dme1737 is not printing any errors so they are not
> > > transactions initiated by the dme1737. The 0x10 means "SMBus Device
> > > Address Not Acknowledged" according to the ACPI spec. Not sure how
> > > this can happen... Signal integrity problems on the board level? In
> > > any case, these errors should probably be retried. Not sure at what
> > > level though. Jean?
> >
> > These are not errors at all, it's only i2c-core probing at work. The
> > dme1737 driver specifies three possible addresses (0x2c, 0x2d, 0x2e),
> > the probes at 0x2c and 0x2d on bus 0 fail, these are the first two
> > "SMBus Timeout!" messages above. Then the probe at 0x2e succeeds. Then
> > i2c-core goes on with bus 1. There should have been 3 failing probes
> > there, but surprisingly, there's only one "SMBus Timeout!" for bus 1. I
> > can't explain it.
>
> I greped the mesages. Maybe, there was a 'message repeated xx times' in
> the log, that wasnt displayed.
Ah, OK, that explains it.
> lisa:/home/jba# i2cdetect -y 0
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: -- -- -- -- -- 08 -- -- -- -- 0d -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU --
> 30: 30 31 -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
Aha. The "0d" is suspicious, I've never seen any chip using this
address. I really wonder what it is. The rest is standard.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (18 preceding siblings ...)
2007-10-21 19:14 ` Jean Delvare
@ 2007-10-21 19:37 ` Jean Delvare
2007-10-22 16:02 ` Juerg Haefliger
` (9 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Jean Delvare @ 2007-10-21 19:37 UTC (permalink / raw)
To: lm-sensors
Juergen,
On Sat, 20 Oct 2007 21:39:32 +0200, Juergen Bausa wrote:
> > Von: Jean Delvare <khali@linux-fr.org>
> > Juergen, if you load the "thermal" driver and look
> > in /proc/acpi/thermal_zone, do you see a temperature reported, with the
> > same value as one of the DME1737 temperature channels?
>
> Yes, I see a temperature, but its not the same.
>
> lisa:/home/jba# cat /proc/acpi/thermal_zone/THRM/temperature
> temperature: 40 C
> lisa:/home/jba# sensors
> k8temp-pci-00c3
> Adapter: PCI adapter
> Core0 Temp:
> +44°C
> Core0 Temp:
> +46°C
> Core1 Temp:
> +52°C
> Core1 Temp:
> +49°C
>
> dme1737-i2c-0-2e
> Adapter: SMBus nForce2 adapter at 4c00
> V5stby: +0.00 V (min = +0.00 V, max = +6.64 V) ALARM
> Vccp: +1.09 V (min = +0.00 V, max = +2.99 V)
> V3.3: +3.27 V (min = +0.00 V, max = +4.38 V)
> V5: +4.93 V (min = +0.00 V, max = +6.64 V)
> V12: +11.78 V (min = +0.00 V, max = +15.94 V)
> V3.3stby: +3.28 V (min = +0.00 V, max = +4.38 V)
> Vbat: +2.98 V (min = +0.00 V, max = +4.38 V)
> Int Temp: +32°C (low = -127°C, high = +127°C)
> CPU Temp: +30°C (low = -127°C, high = +127°C)
> CPU_Fan: 0 RPM (min = 0 RPM)
> ERROR: Can't get fan3 data!
> ERROR: Can't get fan5 data!
> ERROR: Can't get fan6 data!
> CPU_PWM: 0 (enable = 1, freq = 25000 Hz)
> ERROR: Can't get pwm5 data!
> ERROR: Can't get pwm6 data!
> cpu0_vid: +1.550 V (VRM Version 2.4)
>
> lisa:/home/jba#
OK. It doesn't mean that ACPI doesn't get the temperatures from the
DME1737 chip though, it could be adding some arbitrary offset. Can you
please send me your DSDT table in private? I'll take a look.
I also have an experimental (but safe) patch detecting possible
conflicts between ACPI and hwmon drivers. Do you want to test it?
> > If you unload the "thermal" driver, do the dme1737 write errors go away?
>
> I will try this. I am not sure, but dont think thermal was loaded.
Many distributions load it by default, which makes sense for laptops,
but way less for desktops IMHO.
> (...)
> lisa:/home/jba# uname -r
> 2.6.18-5-k7
>
> Its a stock debian etch kernel.
Except for the dme1737 driver, of course ;)
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (19 preceding siblings ...)
2007-10-21 19:37 ` Jean Delvare
@ 2007-10-22 16:02 ` Juerg Haefliger
2007-10-22 16:05 ` Juerg Haefliger
` (8 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Juerg Haefliger @ 2007-10-22 16:02 UTC (permalink / raw)
To: lm-sensors
Hi Jean,
On 10/19/07, Jean Delvare <khali@linux-fr.org> wrote:
> Hi Juerg,
>
> On Wed, 17 Oct 2007 21:53:42 -0700, Juerg Haefliger wrote:
> > On 10/17/07, Jean Delvare <khali@linux-fr.org> wrote:
> > > On Wed, 17 Oct 2007 12:43:16 -0700, Juerg Haefliger wrote:
> > > > Aha, this is an error as a result of a dme1737 initiated write. 0x1a
> > > > means "SMBus Busy". So the dme1737 driver is colliding with something
> > > > else in the system that tries to talk to a chip on the same bus.
> > >
> > > This can only happen on a multi-master I2C bus, which is rather rare on
> > > consumer PCs. Juergen, do you have detailed technical documentation
> > > about your system? It would be interesting to find out what chip the
> > > other master is talking to. If it's the DME1737 chip, this could lead
> > > to problems.
> >
> > Hmm... What about ACPI? Couldn't it interfere with the dme1737 module
> > by going after the same resources.
>
> It could, but I just can't think of a valid reason why ACPI wouldn't
> use the nForce2 SMBus controller itself.
>
> Are you certain that the "busy" error code means that the *bus* is
> busy? Doesn't it rather mean that the *nForce SMBus controller* itself
> is busy (i.e. the previous command is still being processed)? The latter
> would indeed suggest that ACPI is running SMBus transactions in our
> back, which would be a problem. At least, if the SMBus controller lets
> us know, we'll avoid corruption, but bad things can still happen.
From the ACPI spec:
Indicates that the transaction failed because the SMBus host
reports that the SMBus is presently busy with some other
transaction. For example, the Smart Battery might be
sending charging information to the Smart Battery Charger.
> Juergen, if you load the "thermal" driver and look
> in /proc/acpi/thermal_zone, do you see a temperature reported, with the
> same value as one of the DME1737 temperature channels?
>
> If you unload the "thermal" driver, do the dme1737 write errors go away?
>
> > > Assuming that "busy" means that the nForce chip did not even attempt to
> > > send the message (or lost arbitration, which is equivalent), this
> > > specific error could be handled in i2c-nforce2, by retrying. The
> > > problem is that you have to decide how many times you retry, and how
> > > much time you wait between retries (there doesn't seem to be a way to
> > > test if the SMBus is busy before trying, right?)
> >
> > The i2c-nforce2 driver already spins for 10 msecs before deciding to
> > give up. I'd just retry once after that and see what happens.
>
> Depends on what kernel Juergen is running. Oleg Ryjkov has submitted
> interesting patches that clean up this part of the i2c-nforce2 driver:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;hA53549734cbdba24e9cf5eb200b70b7b1572e15
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;hÔ9584c4a37c7228e7778bcb60f79e7a08472fa8
> These are already in Linus' tree for 2.6.24.
Hmm... These patches add abort functionality in case the controller is
locked. I don't think this is our problem here. In Juergen's case, any
subsequent transaction after one that fails succeeds so it's a
transient problem and not a hard lock.
...juerg
> --
> Jean Delvare
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (20 preceding siblings ...)
2007-10-22 16:02 ` Juerg Haefliger
@ 2007-10-22 16:05 ` Juerg Haefliger
2007-10-23 12:08 ` Jean Delvare
` (7 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Juerg Haefliger @ 2007-10-22 16:05 UTC (permalink / raw)
To: lm-sensors
Hi Juergen,
On 10/20/07, Juergen Bausa <Juergen.Bausa@web.de> wrote:
>
> > Von: Jean Delvare <khali@linux-fr.org>
> > Gesendet: 17.10.07 23:32:28
> >
> > On Wed, 17 Oct 2007 12:43:16 -0700, Juerg Haefliger wrote:
> > > On 10/17/07, Juergen Bausa <Juergen.Bausa@web.de> wrote:
> > > > Here is what I found in /var/log:
> > > >
> > > > /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: nForce2 SMBus adapter at 0x4c00
> > > > /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-1: nForce2 SMBus adapter at 0x4c40
> > > > /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: Found a DME1737 chip at 0x2e (rev 0x8a)
> > > >
> > > > /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x10)
> > > > /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x10)
> > > > /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-1: SMBus Timeout! (0x10)
> > >
> > > These are all errors that occur when the drivers (i2c and dme1737) get
> > > loaded. The dme1737 is not printing any errors so they are not
> > > transactions initiated by the dme1737. The 0x10 means "SMBus Device
> > > Address Not Acknowledged" according to the ACPI spec. Not sure how
> > > this can happen... Signal integrity problems on the board level? In
> > > any case, these errors should probably be retried. Not sure at what
> > > level though. Jean?
> >
> > These are not errors at all, it's only i2c-core probing at work. The
> > dme1737 driver specifies three possible addresses (0x2c, 0x2d, 0x2e),
> > the probes at 0x2c and 0x2d on bus 0 fail, these are the first two
> > "SMBus Timeout!" messages above. Then the probe at 0x2e succeeds. Then
> > i2c-core goes on with bus 1. There should have been 3 failing probes
> > there, but surprisingly, there's only one "SMBus Timeout!" for bus 1. I
> > can't explain it.
>
> I greped the mesages. Maybe, there was a 'message repeated xx times' in the log, that wasnt displayed.
>
> >
> > Juergen, can you please attach the output of:
> >
> > modprobe i2c-dev
> > i2cdetect -y 0
> > i2cdetect -y 1
>
> lisa:/home/jba# modprobe i2c-dev
> lisa:/home/jba# i2cdetect -y 0
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: -- -- -- -- -- 08 -- -- -- -- 0d -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU --
> 30: 30 31 -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
> lisa:/home/jba# i2cdetect -y 1
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: -- -- -- -- -- 08 -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
> lisa:/home/jba#
>
>
> >
> > Either way these 3 log messages can safely be ignored.
> >
> > > > /var/log/debug:Oct 17 19:35:30 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x1a)
> > > >
> > > > /var/log/messages:Oct 17 09:16:00 lisa kernel: dme1737 0-002e: Optional features: pwm3=yes, pwm5=no, pwm6=no, fan3=no, fan4=yes, fan5=no, fan6=no.
> > > > /var/log/messages:Oct 17 19:35:30 lisa kernel: dme1737 0-002e: Write to register 0x30 failed (-1)! Please report to the driver maintainer.
> > >
> > > Aha, this is an error as a result of a dme1737 initiated write. 0x1a
> > > means "SMBus Busy". So the dme1737 driver is colliding with something
> > > else in the system that tries to talk to a chip on the same bus.
> >
> > This can only happen on a multi-master I2C bus, which is rather rare on
> > consumer PCs. Juergen, do you have detailed technical documentation
> > about your system? It would be interesting to find out what chip the
> > other master is talking to. If it's the DME1737 chip, this could lead
> > to problems.
>
> No. I dont have detailes information. Its an asus barebone.
>
> Asus borads have a feature called 'ASUS Q-Fan Technology'. Its a BIOS-based controller for the
> FAN/CPU-temperature. This is turned on in the bios. However, when booting linux, the script
> 'fancontrol' is started and then controls cpu-temperature. Maybe the Q-fan still tries to access
> the fan and this is the reason for the collision?
I don't think so. It's just a setting that tells the BIOS to setup the
dme1737 for automatic fan control. After that it won't touch the
dme1737 again. I have a barebone with the same feature.
...juerg
> >
> > > That
> > > should definitely get retried. I can certainly do that at the dme1737
> > > level but I don't think that's the right place. Jean?
> >
> > Assuming that "busy" means that the nForce chip did not even attempt to
> > send the message (or lost arbitration, which is equivalent), this
> > specific error could be handled in i2c-nforce2, by retrying. The
> > problem is that you have to decide how many times you retry, and how
> > much time you wait between retries (there doesn't seem to be a way to
> > test if the SMBus is busy before trying, right?)
> >
> > We have "timeout" and "retries" fields in struct i2c_adapter, which
> > could be used for this. The meaning of "retries" is a bit different
> > though, it's supposed to be the number of nacks the bus driver accepts
> > when attempting to contact a chip before giving up. This doesn't appear
> > to be very useful though so I wouldn't mind recycling this field for
> > the more interesting usage you need. Most bus drivers don't set nor use
> > "timeout".
> >
> > As a first aid solution, you could simply hardcode the timeout and
> > retry values, just to confirm that it solves Juergen's problem. Then
> > we can see how to make it cleaner. Error handling is an area where the
> > i2c subsystem needs to be improved.
> >
>
> Just to make it clear: The messages are no real problem. fancontrol is working very fine.
> Maybe its not successful in setting fan speed sometimes (once a day). But it just sets thge
> fan speed in the next iteration 5 seconds later. Thats no problem.
>
> However, I am also interested in the solution of this.
>
> Juergen
>
> __________________________________________________________________________
> Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!
> Mehr Infos unter http://produkte.web.de/club/?mc\x021131
>
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (21 preceding siblings ...)
2007-10-22 16:05 ` Juerg Haefliger
@ 2007-10-23 12:08 ` Jean Delvare
2007-10-23 12:22 ` Jean Delvare
` (6 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Jean Delvare @ 2007-10-23 12:08 UTC (permalink / raw)
To: lm-sensors
Hi Juerg,
On Mon, 22 Oct 2007 09:02:37 -0700, Juerg Haefliger wrote:
> From the ACPI spec:
> Indicates that the transaction failed because the SMBus host
> reports that the SMBus is presently busy with some other
> transaction. For example, the Smart Battery might be
> sending charging information to the Smart Battery Charger.
Hmm, OK, that's really "bus busy" then. It may be related to this chip
at address 0x0d. Can't say more without detailed hardware
specifications of the system.
> > Depends on what kernel Juergen is running. Oleg Ryjkov has submitted
> > interesting patches that clean up this part of the i2c-nforce2 driver:
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;hA53549734cbdba24e9cf5eb200b70b7b1572e15
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;hÔ9584c4a37c7228e7778bcb60f79e7a08472fa8
> > These are already in Linus' tree for 2.6.24.
>
> Hmm... These patches add abort functionality in case the controller is
> locked. I don't think this is our problem here. In Juergen's case, any
> subsequent transaction after one that fails succeeds so it's a
> transient problem and not a hard lock.
The second patch if completely unrelated, agreed. But the first patch
changes how the driver polls for transaction status. While it is not
related to Juergen's problem, the timing change involved could affect
the code you want to add to retry the transaction when the bus is busy.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (22 preceding siblings ...)
2007-10-23 12:08 ` Jean Delvare
@ 2007-10-23 12:22 ` Jean Delvare
2007-10-23 20:44 ` Juergen Bausa
` (5 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Jean Delvare @ 2007-10-23 12:22 UTC (permalink / raw)
To: lm-sensors
On Sun, 21 Oct 2007 21:37:26 +0200, Jean Delvare wrote:
> Juergen,
>
> On Sat, 20 Oct 2007 21:39:32 +0200, Juergen Bausa wrote:
> > > Von: Jean Delvare <khali@linux-fr.org>
> > > Juergen, if you load the "thermal" driver and look
> > > in /proc/acpi/thermal_zone, do you see a temperature reported, with the
> > > same value as one of the DME1737 temperature channels?
> >
> > Yes, I see a temperature, but its not the same.
> >
> > lisa:/home/jba# cat /proc/acpi/thermal_zone/THRM/temperature
> > temperature: 40 C
> > lisa:/home/jba# sensors
> > k8temp-pci-00c3
> > Adapter: PCI adapter
> > Core0 Temp:
> > +44°C
> > Core0 Temp:
> > +46°C
> > Core1 Temp:
> > +52°C
> > Core1 Temp:
> > +49°C
> >
> > dme1737-i2c-0-2e
> > Adapter: SMBus nForce2 adapter at 4c00
> > V5stby: +0.00 V (min = +0.00 V, max = +6.64 V) ALARM
> > Vccp: +1.09 V (min = +0.00 V, max = +2.99 V)
> > V3.3: +3.27 V (min = +0.00 V, max = +4.38 V)
> > V5: +4.93 V (min = +0.00 V, max = +6.64 V)
> > V12: +11.78 V (min = +0.00 V, max = +15.94 V)
> > V3.3stby: +3.28 V (min = +0.00 V, max = +4.38 V)
> > Vbat: +2.98 V (min = +0.00 V, max = +4.38 V)
> > Int Temp: +32°C (low = -127°C, high = +127°C)
> > CPU Temp: +30°C (low = -127°C, high = +127°C)
> > CPU_Fan: 0 RPM (min = 0 RPM)
> > ERROR: Can't get fan3 data!
> > ERROR: Can't get fan5 data!
> > ERROR: Can't get fan6 data!
> > CPU_PWM: 0 (enable = 1, freq = 25000 Hz)
> > ERROR: Can't get pwm5 data!
> > ERROR: Can't get pwm6 data!
> > cpu0_vid: +1.550 V (VRM Version 2.4)
> >
> > lisa:/home/jba#
>
> OK. It doesn't mean that ACPI doesn't get the temperatures from the
> DME1737 chip though, it could be adding some arbitrary offset. Can you
> please send me your DSDT table in private? I'll take a look.
OK, I've taken a look at the DSDT and it includes references to
hardware monitoring features all around the place:
Device (ASOC)
{
Name (_HID, "ATK0110")
Name (_UID, 0x01010110)
Name (MBIF, Package (0x08)
{
0x01,
"M2N8L",
0x01010101,
0x01010101,
0xC0010002,
0x01,
0x00,
0x00
})
Name (VBUF, Package (0x05)
{
0x04,
VCRE,
V333,
V500,
V120
})
Name (VCRE, Package (0x05)
{
0x06020000,
"Vcore Voltage",
0x05AA,
0x06D6,
0x01
})
Name (V333, Package (0x05)
{
0x06020001,
" +3.3 Voltage",
0x0BB8,
0x0E10,
0x01
})
Name (V500, Package (0x05)
{
0x06020002,
" +5.0 Voltage",
0x1194,
0x157C,
0x01
})
Name (V120, Package (0x05)
{
0x06020003,
"+12.0 Voltage",
0x2BC0,
0x3390,
0x01
})
Name (TBUF, Package (0x03)
{
0x02,
CPUT,
MBTP
})
Name (CPUT, Package (0x05)
{
0x06030000,
"CPU Temperature",
0x0384,
0x04E2,
0x00010001
})
Name (MBTP, Package (0x05)
{
0x06030001,
"MB Temperature",
0x02BC,
0x04E2,
0x00010001
})
Name (FBUF, Package (0x06)
{
0x03,
CPUF,
CHAF,
PWRF,
CHPF,
CH2F
})
Name (CPUF, Package (0x05)
{
0x06040000,
"CPU FAN Speed",
0x00,
0x0708,
0x00010001
})
Name (CHAF, Package (0x05)
{
0x06040001,
"CHASSIS FAN Speed",
0x00,
0x0708,
0x01
})
Name (PWRF, Package (0x05)
{
0x06040002,
"POWER FAN Speed",
0x00,
0x0708,
0x00
})
Name (CHPF, Package (0x05)
{
0x06040005,
"CHIPSET FAN Speed",
0x00,
0x0708,
0x00
})
Name (CH2F, Package (0x05)
{
0x06040006,
"CHASSIS2 FAN Speed",
0x00,
0x0708,
0x00
})
Name (QFAN, Package (0x05)
{
0x04060003,
"CPU Q-Fan Control",
0x00,
0x01,
0x01
})
Name (QFRO, Package (0x05)
{
0x04050004,
"CPU Q-Fan Ratio",
0x3C,
0x5A,
0x00
})
Name (QFTP, Package (0x05)
{
0x04030005,
"Temperature Range",
0x02,
0x50,
0x00010001
})
Name (QCFN, Package (0x05)
{
0x04060006,
"Chassis Q-Fan Control",
0x00,
0x01,
0x00
})
Name (QFCR, Package (0x05)
{
0x04050007,
"Chassis Q-Fan Ratio",
0x38,
0x64,
0x00
})
etc etc. This appears to be the half-standard ATK0110 implementation
for which a driver was posted to the lm-sensors list a few months ago.
Maybe for this motherboard you should use this driver rather than the
dme1737 driver. Adding Rudolf in Cc, I think he knows more about this
driver's status.
The DSDT also includes references to the nforce2's SMBus:
Device (SMB0)
{
Name (_ADR, 0x000A0001)
OperationRegion (SMCF, PCI_Config, 0x48, 0x10)
Field (SMCF, DWordAcc, NoLock, Preserve)
{
SMPM, 4,
SMT1, 28,
SMT2, 32
}
OperationRegion (SMCA, PCI_Config, 0x20, 0x08)
Field (SMCA, DWordAcc, NoLock, Preserve)
{
SB1, 32,
SB2, 32
}
OperationRegion (PDEV, PCI_Config, 0xE8, 0x04)
Scope (\)
{
Field (\_SB.PCI0.SMB0.PDEV, AnyAcc, NoLock, Preserve)
{
, 12,
ACIE, 1
}
}
Method (SMBB, 0, NotSerialized)
{
If (PCIA)
{
And (SB1, 0xFFFE, Local0)
}
Else
{
Store (0x4C00, Local0)
}
Return (Local0)
}
}
So at the very least I'd say it's not safe to use the i2c-nforce2 and
dme1737 drivers when the fan and thermal ACPI drivers are in use. But
it may even not be safe when these ACPI drivers aren't loaded, I don't
know.
That being said, I can't guarantee that the I/O errors you've seen are
related to this. There may _also_ be a second master on the SMBus
talking to whatever chip is at address 0x0d. So adding a retry
mechanism to i2c-nforce2 may still be a good idea.
> I also have an experimental (but safe) patch detecting possible
> conflicts between ACPI and hwmon drivers. Do you want to test it?
Hopefully the patch in question will also detect the conflict.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (23 preceding siblings ...)
2007-10-23 12:22 ` Jean Delvare
@ 2007-10-23 20:44 ` Juergen Bausa
2007-10-23 21:54 ` Rudolf Marek
` (4 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Juergen Bausa @ 2007-10-23 20:44 UTC (permalink / raw)
To: lm-sensors
Juer, Jean,
> -----Ursprüngliche Nachricht-----
> Von: "Juerg Haefliger" <juergh@gmail.com>
> Gesendet: 18.10.07 06:53:47
> An: "Jean Delvare" <khali@linux-fr.org>
> CC: lm-sensors@lm-sensors.org
> Betreff: Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
>
> > > That
> > > should definitely get retried. I can certainly do that at the dme1737
> > > level but I don't think that's the right place. Jean?
> >
> > Assuming that "busy" means that the nForce chip did not even attempt to
> > send the message (or lost arbitration, which is equivalent), this
> > specific error could be handled in i2c-nforce2, by retrying. The
> > problem is that you have to decide how many times you retry, and how
> > much time you wait between retries (there doesn't seem to be a way to
> > test if the SMBus is busy before trying, right?)
>
> The i2c-nforce2 driver already spins for 10 msecs before deciding to
> give up. I'd just retry once after that and see what happens.
>
> Juergen: Can you apply the attached patch and give it a whirl?
>
Since i applied the patch I got no more errors.
Juergen
______________________________________________________________________
XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club!
Jetzt testen! http://produkte.web.de/club/?mc\x021130
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (24 preceding siblings ...)
2007-10-23 20:44 ` Juergen Bausa
@ 2007-10-23 21:54 ` Rudolf Marek
2007-10-24 8:48 ` Jean Delvare
` (3 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Rudolf Marek @ 2007-10-23 21:54 UTC (permalink / raw)
To: lm-sensors
> etc etc. This appears to be the half-standard ATK0110 implementation
> for which a driver was posted to the lm-sensors list a few months ago.
> Maybe for this motherboard you should use this driver rather than the
> dme1737 driver. Adding Rudolf in Cc, I think he knows more about this
> driver's status.
Hmm dont know more it seems. Perhaps contact original author? Those ACPI
routines are not called unless the TMP method for thermal stuff is called. So If
there will be no readings from the acpi thermal sysfs/proc file the method will
not run (in theory if the code is write like here)
> The DSDT also includes references to the nforce2's SMBus:
>
> Device (SMB0)
> {
> Name (_ADR, 0x000A0001)
> OperationRegion (SMCF, PCI_Config, 0x48, 0x10)
> Field (SMCF, DWordAcc, NoLock, Preserve)
> {
> SMPM, 4,
> SMT1, 28,
> SMT2, 32
> }
>
> OperationRegion (SMCA, PCI_Config, 0x20, 0x08)
> Field (SMCA, DWordAcc, NoLock, Preserve)
> {
> SB1, 32,
> SB2, 32
> }
>
> OperationRegion (PDEV, PCI_Config, 0xE8, 0x04)
> Scope (\)
> {
> Field (\_SB.PCI0.SMB0.PDEV, AnyAcc, NoLock, Preserve)
> {
> , 12,
> ACIE, 1
> }
> }
>
> Method (SMBB, 0, NotSerialized)
> {
> If (PCIA)
> {
> And (SB1, 0xFFFE, Local0)
> }
> Else
> {
> Store (0x4C00, Local0)
> }
>
> Return (Local0)
> }
> }
>
> So at the very least I'd say it's not safe to use the i2c-nforce2 and
> dme1737 drivers when the fan and thermal ACPI drivers are in use. But
> it may even not be safe when these ACPI drivers aren't loaded, I don't
> know.
It depends what methods are called. Imho if you remove the "thermal" support
from the ACPI it should be ok. If someone gives me the table, I can take a look.
Rudolf
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (25 preceding siblings ...)
2007-10-23 21:54 ` Rudolf Marek
@ 2007-10-24 8:48 ` Jean Delvare
2007-10-29 21:23 ` Rudolf Marek
` (2 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Jean Delvare @ 2007-10-24 8:48 UTC (permalink / raw)
To: lm-sensors
On Tue, 23 Oct 2007 23:54:24 +0200, Rudolf Marek wrote:
> > etc etc. This appears to be the half-standard ATK0110 implementation
> > for which a driver was posted to the lm-sensors list a few months ago.
> > Maybe for this motherboard you should use this driver rather than the
> > dme1737 driver. Adding Rudolf in Cc, I think he knows more about this
> > driver's status.
>
> Hmm dont know more it seems. Perhaps contact original author? Those ACPI
> routines are not called unless the TMP method for thermal stuff is called. So If
> there will be no readings from the acpi thermal sysfs/proc file the method will
> not run (in theory if the code is write like here)
Even if the ACPI thermal driver is set to automatic polling mode?
> > The DSDT also includes references to the nforce2's SMBus:
> >
> > Device (SMB0)
> > {
> > Name (_ADR, 0x000A0001)
> > OperationRegion (SMCF, PCI_Config, 0x48, 0x10)
> > Field (SMCF, DWordAcc, NoLock, Preserve)
> > {
> > SMPM, 4,
> > SMT1, 28,
> > SMT2, 32
> > }
> >
> > OperationRegion (SMCA, PCI_Config, 0x20, 0x08)
> > Field (SMCA, DWordAcc, NoLock, Preserve)
> > {
> > SB1, 32,
> > SB2, 32
> > }
> >
> > OperationRegion (PDEV, PCI_Config, 0xE8, 0x04)
> > Scope (\)
> > {
> > Field (\_SB.PCI0.SMB0.PDEV, AnyAcc, NoLock, Preserve)
> > {
> > , 12,
> > ACIE, 1
> > }
> > }
> >
> > Method (SMBB, 0, NotSerialized)
> > {
> > If (PCIA)
> > {
> > And (SB1, 0xFFFE, Local0)
> > }
> > Else
> > {
> > Store (0x4C00, Local0)
> > }
> >
> > Return (Local0)
> > }
> > }
> >
> > So at the very least I'd say it's not safe to use the i2c-nforce2 and
> > dme1737 drivers when the fan and thermal ACPI drivers are in use. But
> > it may even not be safe when these ACPI drivers aren't loaded, I don't
> > know.
>
> It depends what methods are called. Imho if you remove the "thermal" support
> from the ACPI it should be ok. If someone gives me the table, I can take a look.
I'll send it to you in private.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (26 preceding siblings ...)
2007-10-24 8:48 ` Jean Delvare
@ 2007-10-29 21:23 ` Rudolf Marek
2007-10-30 2:52 ` Juerg Haefliger
2007-10-31 2:40 ` Juerg Haefliger
29 siblings, 0 replies; 31+ messages in thread
From: Rudolf Marek @ 2007-10-29 21:23 UTC (permalink / raw)
To: lm-sensors
> It depends what methods are called. Imho if you remove the "thermal" support
> from the ACPI it should be ok. If someone gives me the table, I can take a look.
Also standard ACPI fan support driver should not be loaded.
Rudolf
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (27 preceding siblings ...)
2007-10-29 21:23 ` Rudolf Marek
@ 2007-10-30 2:52 ` Juerg Haefliger
2007-10-31 2:40 ` Juerg Haefliger
29 siblings, 0 replies; 31+ messages in thread
From: Juerg Haefliger @ 2007-10-30 2:52 UTC (permalink / raw)
To: lm-sensors
Hi Rudolf,
On 10/29/07, Rudolf Marek <r.marek@assembler.cz> wrote:
> > It depends what methods are called. Imho if you remove the "thermal" support
> > from the ACPI it should be ok. If someone gives me the table, I can take a look.
>
> Also standard ACPI fan support driver should not be loaded.
Just got my hands on a W8000 machine yesterday. The Compaq Evo W8000
is blacklisted in the kernel and acpi=ht (hyperthreading only) is
forced during boot. So ACPI is pretty much disabled by default.
...juerg
> Rudolf
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [lm-sensors] dme1737 0-002e: Write to register 0x30 failed!
2007-09-25 19:08 [lm-sensors] dme1737 0-002e: Write to register 0x30 failed! Juergen Bausa
` (28 preceding siblings ...)
2007-10-30 2:52 ` Juerg Haefliger
@ 2007-10-31 2:40 ` Juerg Haefliger
29 siblings, 0 replies; 31+ messages in thread
From: Juerg Haefliger @ 2007-10-31 2:40 UTC (permalink / raw)
To: lm-sensors
> Hi Rudolf,
>
> On 10/29/07, Rudolf Marek <r.marek@assembler.cz> wrote:
> > > It depends what methods are called. Imho if you remove the "thermal" support
> > > from the ACPI it should be ok. If someone gives me the table, I can take a look.
> >
> > Also standard ACPI fan support driver should not be loaded.
>
> Just got my hands on a W8000 machine yesterday. The Compaq Evo W8000
> is blacklisted in the kernel and acpi=ht (hyperthreading only) is
> forced during boot. So ACPI is pretty much disabled by default.
Argh, wrong thread. Sorry for the noise.
...juerg
> ...juerg
>
>
>
> > Rudolf
> >
> > _______________________________________________
> > lm-sensors mailing list
> > lm-sensors@lm-sensors.org
> > http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
> >
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 31+ messages in thread