[lm-sensors] GA-Z77X-UD3H with ITE IT8728F, modprobe it87 freezes system

[lm-sensors] GA-Z77X-UD3H with ITE IT8728F, modprobe it87 freezes system

[Stevie Trujillo]

Hello,

I have a Gigabyte GA-Z77X-UD3H motherboard with a 3570k CPU and 32GiB ram.
  * ISA bus, address 0xa30
    Chip `ITE IT8728F Super IO Sensors' (confidence: 9)

I run Gentoo with linux-3.4.4, if I do "modprobe it87" the system freezes.
I was told GA-Z77X-D3H (not UD3H) works in Debian Squeeze with 3.2
kernel from Debian backports.
I installed Squeeze, for me it freezes there too:

# modprobe it87
it87: Found IT8728F chip at 0xa30, revision 1
it87: Beeping is supported
* here it froze*

How can I fix/debug this?

Thank you!
Stevie Trujillo

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

Re: [lm-sensors] GA-Z77X-UD3H with ITE IT8728F, modprobe it87 freezes system

[Jean Delvare]

Hi Stevie,

On Tue, 10 Jul 2012 16:24:55 +0200, Stevie Trujillo wrote:
> I have a Gigabyte GA-Z77X-UD3H motherboard with a 3570k CPU and 32GiB ram.
>   * ISA bus, address 0xa30
>     Chip `ITE IT8728F Super IO Sensors' (confidence: 9)
> 
> I run Gentoo with linux-3.4.4, if I do "modprobe it87" the system freezes.
> I was told GA-Z77X-D3H (not UD3H) works in Debian Squeeze with 3.2
> kernel from Debian backports.
> I installed Squeeze, for me it freezes there too:
> 
> # modprobe it87
> it87: Found IT8728F chip at 0xa30, revision 1
> it87: Beeping is supported
> * here it froze*

Very odd. I think this is the first report of that kind. You are not
booting with acpi_enforce_resources=lax or =no, are you?

> How can I fix/debug this?

I have no immediate idea. Please check in /proc/ioports if you see
anything suspicious at address 0xa30. 

I have added a module parameter to the it87 driver. The updated driver
is here:
  http://khali.linux-fr.org/devel/misc/it87/
Build instructions are at:
  http://khali.linux-fr.org/devel/misc/INSTALL

You can load this it87 driver with write=0 to disable all register
writes. This will tell us if at least the driver works when not writing
to registers (I expect so.)

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.

-- 
Jean Delvare

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

Re: [lm-sensors] GA-Z77X-UD3H with ITE IT8728F, modprobe it87 freezes system

[Jean Delvare]

Hi Guenter, Stevie,

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;h0678638d86ea855f89fe5c799d146af7a75b64e

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

-- 
Jean Delvare

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

Re: [lm-sensors] GA-Z77X-UD3H with ITE IT8728F, modprobe it87 freezes system

[Stevie Trujillo]

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;h0678638d86ea855f89fe5c799d146af7a75b64e
>
> 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@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] GA-Z77X-UD3H with ITE IT8728F, modprobe it87 freezes system

[Guenter Roeck]

On Wed, Jul 11, 2012 at 06:10:43PM +0200, Jean Delvare wrote:
> Hi Guenter, Stevie,
> 
> 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.
> 
I suspect the latter. The meanings did not change for IT8782F and IT8783E/F
either, so there is no reason to believe that IT8728F would be different.

> 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;h0678638d86ea855f89fe5c799d146af7a75b64e
> 
> 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.
> 
Oversight, maybe, or the bit name was confusing.

It doesn't make much sense to enable SMI interrupts while keeping global
interrupts disabled. We may just have been lucky to never hit this problem.

> > 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.
> 
I'd keep it as-is. Not worth trying to solve a problem which may not exist.

Guenter

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

Re: [lm-sensors] GA-Z77X-UD3H with ITE IT8728F, modprobe it87 freezes system

[Jean Delvare]

On Wed, 11 Jul 2012 11:31:24 -0700, Guenter Roeck wrote:
> On Wed, Jul 11, 2012 at 06:10:43PM +0200, Jean Delvare wrote:
> > 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.
>
> Oversight, maybe, or the bit name was confusing.
> 
> It doesn't make much sense to enable SMI interrupts while keeping global
> interrupts disabled. We may just have been lucky to never hit this problem.

I think so, yes.

> > > 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.
>
> I'd keep it as-is. Not worth trying to solve a problem which may not exist.

Agreed. I'll push the fix to Linus ASAP.

Thanks Stevie for the quick test report!

-- 
Jean Delvare

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