Re: GA-Z77X-UD3H with ITE IT8728F, modprobe it87 freezes system

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2012-07-11 18:10, Jean Delvare wrote:
On Wed, 11 Jul 2012 07:45:56 -0700, Guenter Roeck wrote:
On Wed, Jul 11, 2012 at 04:16:21PM +0200, Stevie Trujillo wrote:
[ ... ]
>
> > If that works, then please unload the driver and reload with write=2. > > This will log every register write right before it happens. So the last
> > message logged is likely to point to a register write which is
> > inappropriate for your device/board.
>
> I only see these lines:
> [  265.408976] it87: Found IT8728F chip at 0xa30, revision 1
> [  265.410655] it87: Beeping is supported
> [  265.411583] it87: Writing value 0x37 to register 0x0c
> [  265.423124] it87: Writing value 0x13 to register 0x00
>
Jean,

it87_write_value(data, IT87_REG_CONFIG,
                 (it87_read_value(data, IT87_REG_CONFIG) & 0x36)
			| (update_vbat ? 0x41 : 0x01));

Unless I am missing something, the above code enables interrupts by clearing bit 3. In combination with having bit 1 set, this means that SMI# interrupts will be enabled. Default value for the register, at least for IT8721F and
IT8718F, is 0x18.

The meaning of all bits in this register, and its default value, did
not change since the IT8705F, at least up to the IT8721F. I do not have
the datasheet for the IT8728F, do I cannot comment on that. Maybe
something changed for that chip, or - more likely - it is wired or
configured in an unusual way on Stevie's board.

A bit of archeology teaches us that the mysterious 0x36 mask comes from
this commit 8 years ago:

http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=30678638d86ea855f89fe5c799d146af7a75b64e

Before that the mask was 0xb7, which wasn't that different given that
bit 7 always reads back 0, and bit 0 is about be set anyway. I think
0x80 was removed to avoid an unlikely double-reset of the chip when the
module is loaded with reset=1.

The 0xb7 is from the very first version of the it87 driver by
Christophe Gauthron 11 years ago. I have no idea why bit 3 was
explicitly cleared back then.

Replacing the 0x36 mask above with 0x3e might possibly solve
the problem.

Indeed. I'm not too sure what to do about bit 5, BTW, it might be
self-clearing as bit 7.

Stevie, I have updated the driver at:
  http://khali.linux-fr.org/devel//misc/it87/

Please test it (make sure you don't get a cached version from your
browser - line 2390 should have mask 0x3e.)

Hello, sorry for destroying subject and threading last time!

The new version doesn't freeze the system.

I also took the libery of adding a printk showing the old value.
2388 .   /* Start monitoring */
2389 .   printk("IT87_REG_CONFIG oldvalue: %x\n",
2390 .   .   it87_read_value(data, IT87_REG_CONFIG));

[   75.539096] it87: Found IT8728F chip at 0xa30, revision 1
[   75.539114] it87: Beeping is supported
[   75.539280] it87: Writing value 0x37 to register 0x0c
[   75.549437] IT87_REG_CONFIG oldvalue: 1b
[   75.549448] it87: Writing value 0x1b to register 0x00

--
Stevie Trujillo

_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors


[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux