[lm-sensors] Gigabyte GA-Z77N-ITX Motherboard it87 sensors module (SuperIO chip ITE 8728)

[lm-sensors] Gigabyte GA-Z77N-ITX Motherboard it87 sensors module (SuperIO chip ITE 8728)

[luke.leighton]

ok.  it took a hell of a long time to find the right information to
get this motherboard to be recognised, so i thought i'd do a quick
report with the appropriate keywords for other people to be able to
find it.   i'm using linux kernel 3.2.0 which is considered reasonably
stable, hence the reason why it was not detected.

the phrase that people are looking for - if they notice it when
running sensors-detect, is:

     "Found unknown chip with ID 0x8728"

with that, it's possible to find this:

     http://www.spinics.net/lists/lm-sensors/msg30897.html

which leads to the correct information which is to add the following
to a file named e.g. /etc/modprobe.d/it87.conf:

    options it87 force_id=0x8720

also by downloading the source code for sensors-detect 3.3 i was able
to ascertain that the SuperIO chip with ID 0x8728 has already been
added, but i had sensors-detect version 3.1 so  modified
/usr/sbin/sensors-detect (version 3.1) around line 1819 to add this:

        }, {
                name => "ITE IT8726F Super IO Sensors",
                driver => "it87",
                devid => 0x8726,
                logdev => 0x04,
                features => FEAT_IN | FEAT_FAN | FEAT_TEMP,
        }, {
                name => "ITE IT8728F Super IO Sensors",
                driver => "it87",
                devid => 0x8728,
                logdev => 0x04,
                features => FEAT_IN | FEAT_FAN | FEAT_TEMP,
        }
);

this was rather unnecessary but may be useful to some: after running,
all it did was add it87 to /etc/modules which i could have done anyway
[but ONLY works with that modprobe.d addition.

also what may be of assistance to some people: the previous answer did
not exactly specify what the line is for modprobe, it assumes
knowledge of how to use modprobe.  the command you are looking for is:

    modprobe it87 force_id=0x8720

also, the following page http://www.lm-sensors.org/wiki/Devices was
also quite terse and not immediately very helpful.  if the advice
about force_id had been on the wiki page, i would have saved about 2
hours of searching.  however, *after* discovering the above, the
information reporting that 0x8728 works with kernel versions 3.3 or
the stand-alone sensors kernel modules became clear [i have 3.2.0].
also, H77N is missing from the wiki page entry, it shows support for
H67 and a couple of others, but H77N i can definitely confirm is
working [with the force_id]

so this is more a sort-of interim thing for people who are using
stable 3.2.0 kernels for the forseeable future, especially debian
users, with this amazing low-cost high-featured motherboard.

l.

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

Re: [lm-sensors] Gigabyte GA-Z77N-ITX Motherboard it87 sensors module (SuperIO chip ITE 8728)

[Jean Delvare]

Hi Luke,

On Mon, 29 Apr 2013 12:34:45 +0100, luke.leighton wrote:
> ok.  it took a hell of a long time to find the right information to
> get this motherboard to be recognised, so i thought i'd do a quick
> report with the appropriate keywords for other people to be able to
> find it.   i'm using linux kernel 3.2.0 which is considered reasonably
> stable, hence the reason why it was not detected.
> 
> the phrase that people are looking for - if they notice it when
> running sensors-detect, is:
> 
>      "Found unknown chip with ID 0x8728"
> 
> with that, it's possible to find this:
> 
>      http://www.spinics.net/lists/lm-sensors/msg30897.html
> 
> which leads to the correct information which is to add the following
> to a file named e.g. /etc/modprobe.d/it87.conf:
> 
>     options it87 force_id=0x8720
> 
> also by downloading the source code for sensors-detect 3.3 i was able
> to ascertain that the SuperIO chip with ID 0x8728 has already been
> added, but i had sensors-detect version 3.1 so  modified
> /usr/sbin/sensors-detect (version 3.1) around line 1819 to add this:
> 
>         }, {
>                 name => "ITE IT8726F Super IO Sensors",
>                 driver => "it87",
>                 devid => 0x8726,
>                 logdev => 0x04,
>                 features => FEAT_IN | FEAT_FAN | FEAT_TEMP,
>         }, {
>                 name => "ITE IT8728F Super IO Sensors",
>                 driver => "it87",
>                 devid => 0x8728,
>                 logdev => 0x04,
>                 features => FEAT_IN | FEAT_FAN | FEAT_TEMP,
>         }
> );
> 
> this was rather unnecessary but may be useful to some: after running,
> all it did was add it87 to /etc/modules which i could have done anyway
> [but ONLY works with that modprobe.d addition.
> 
> also what may be of assistance to some people: the previous answer did
> not exactly specify what the line is for modprobe, it assumes
> knowledge of how to use modprobe.  the command you are looking for is:
> 
>     modprobe it87 force_id=0x8720

Thanks for sharing your findings. Obviously I already knew about it
all, but your post might help others in similar situations.

> also, the following page http://www.lm-sensors.org/wiki/Devices was
> also quite terse and not immediately very helpful.  if the advice
> about force_id had been on the wiki page, i would have saved about 2
> hours of searching.

Good point. However I'm not sure where I would add the information and
in what form. The force_id parameter isn't it87-specific, it is
supported by 11 different hwmon drivers, covering something 20 or 30
different devices. In general it is also better if users can build a
standalone driver because this gives them the right device name
matching the configuration file for their board (if one exists.)

That being said, I agree that not all users can build the standalone
driver. Also the cases where passing the force_id parameter works
perfectly are rather rare. So I decided to add a note about force_id in
the IT8728F entry only. Thanks for the suggestion.

> however, *after* discovering the above, the
> information reporting that 0x8728 works with kernel versions 3.3 or
> the stand-alone sensors kernel modules became clear [i have 3.2.0].
> also, H77N is missing from the wiki page entry, it shows support for
> H67 and a couple of others, but H77N i can definitely confirm is
> working [with the force_id]

The wiki has been clarified by Guenter meanwhile.

> so this is more a sort-of interim thing for people who are using
> stable 3.2.0 kernels for the forseeable future, especially debian
> users, with this amazing low-cost high-featured motherboard.

-- 
Jean Delvare

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

Re: [lm-sensors] Gigabyte GA-Z77N-ITX Motherboard it87 sensors module (SuperIO chip ITE 8728)

[luke.leighton]

On Tue, May 7, 2013 at 8:03 AM, Jean Delvare <khali@linux-fr.org> wrote:

>>     modprobe it87 force_id=0x8720
>
> Thanks for sharing your findings. Obviously I already knew about it
> all, but your post might help others in similar situations.

 with the right keywords, aaanything is possible :)

>> also, the following page http://www.lm-sensors.org/wiki/Devices was
>> also quite terse and not immediately very helpful.  if the advice
>> about force_id had been on the wiki page, i would have saved about 2
>> hours of searching.
>
> Good point. However I'm not sure where I would add the information and
> in what form. The force_id parameter isn't it87-specific, it is
> supported by 11 different hwmon drivers, covering something 20 or 30
> different devices. In general it is also better if users can build a
> standalone driver because this gives them the right device name
> matching the configuration file for their board (if one exists.)

 in debian this is generally discouraged.  in the work environment in
which i find myself it is a *definite* no.  we have enough to deal
with in the fact that this is only available for 3.2.0 rather than
2.6.32.  we will need to do at least 2 to 3 months of testing before
3.2.0 can be *considered* to be put into production.

 and we would need to either create a debian package for the
stand-alone driver or compile ... no, we would not be able to compile
on the box because that would mean that the 800 machines in the field
would need to have gcc installed, that would mean 100% CPU for short
durations which would disrupt the customer, so no, definitely a debian
package, and that's a lot of work.

 basically it is often completely impractical to use the standalone
driver, or quite a lot of work.


> That being said, I agree that not all users can build the standalone
> driver.

 ... or it's a significant burden to do so, as well as requiring
months of testing before going live.

> Also the cases where passing the force_id parameter works
> perfectly are rather rare. So I decided to add a note about force_id in
> the IT8728F entry only.

 that works.  that works very well.  H77N could do with being added to
the list of gigabyte motherboards in that entry, it only lists 67 so
far.

 l.

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

Re: [lm-sensors] Gigabyte GA-Z77N-ITX Motherboard it87 sensors module (SuperIO chip ITE 8728)

[Guenter Roeck]

On Tue, May 07, 2013 at 08:38:04AM +0100, luke.leighton wrote:
> On Tue, May 7, 2013 at 8:03 AM, Jean Delvare <khali@linux-fr.org> wrote:
> 
> >>     modprobe it87 force_id=0x8720
> >
> > Thanks for sharing your findings. Obviously I already knew about it
> > all, but your post might help others in similar situations.
> 
>  with the right keywords, aaanything is possible :)
> 
> >> also, the following page http://www.lm-sensors.org/wiki/Devices was
> >> also quite terse and not immediately very helpful.  if the advice
> >> about force_id had been on the wiki page, i would have saved about 2
> >> hours of searching.
> >
> > Good point. However I'm not sure where I would add the information and
> > in what form. The force_id parameter isn't it87-specific, it is
> > supported by 11 different hwmon drivers, covering something 20 or 30
> > different devices. In general it is also better if users can build a
> > standalone driver because this gives them the right device name
> > matching the configuration file for their board (if one exists.)
> 
>  in debian this is generally discouraged.  in the work environment in
> which i find myself it is a *definite* no.  we have enough to deal
> with in the fact that this is only available for 3.2.0 rather than
> 2.6.32.  we will need to do at least 2 to 3 months of testing before
> 3.2.0 can be *considered* to be put into production.
> 
And we are up to 3.9 already, and 2.6.32 was already dropped from the longterm
supported kernel list. You are really running old kernels - by the time you
start running 3.2, it may be getting close to EOL.

>  and we would need to either create a debian package for the
> stand-alone driver or compile ... no, we would not be able to compile
> on the box because that would mean that the 800 machines in the field
> would need to have gcc installed, that would mean 100% CPU for short
> durations which would disrupt the customer, so no, definitely a debian
> package, and that's a lot of work.
> 
>  basically it is often completely impractical to use the standalone
> driver, or quite a lot of work.
> 
> 
> > That being said, I agree that not all users can build the standalone
> > driver.
> 
>  ... or it's a significant burden to do so, as well as requiring
> months of testing before going live.
> 
I think Jean referred more to individual users and did not really have
distributions or large scale deployments in mind.

> > Also the cases where passing the force_id parameter works
> > perfectly are rather rare. So I decided to add a note about force_id in
> > the IT8728F entry only.
> 
>  that works.  that works very well.  H77N could do with being added to
> the list of gigabyte motherboards in that entry, it only lists 67 so
> far.
> 
Might be better to remove all of them. The driver is, after all, for a SuperIO
chipset, not for specific Intel boards, and the chip is used quite widely
on many boards nowadays.

Thanks,
Guenter

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

Re: [lm-sensors] Gigabyte GA-Z77N-ITX Motherboard it87 sensors module (SuperIO chip ITE 8728)

[luke.leighton]

On Tue, May 7, 2013 at 2:43 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> On Tue, May 07, 2013 at 08:38:04AM +0100, luke.leighton wrote:
>> On Tue, May 7, 2013 at 8:03 AM, Jean Delvare <khali@linux-fr.org> wrote:
>>
>> >>     modprobe it87 force_id=0x8720
>> >
>> > Thanks for sharing your findings. Obviously I already knew about it
>> > all, but your post might help others in similar situations.
>>
>>  with the right keywords, aaanything is possible :)
>>
>> >> also, the following page http://www.lm-sensors.org/wiki/Devices was
>> >> also quite terse and not immediately very helpful.  if the advice
>> >> about force_id had been on the wiki page, i would have saved about 2
>> >> hours of searching.
>> >
>> > Good point. However I'm not sure where I would add the information and
>> > in what form. The force_id parameter isn't it87-specific, it is
>> > supported by 11 different hwmon drivers, covering something 20 or 30
>> > different devices. In general it is also better if users can build a
>> > standalone driver because this gives them the right device name
>> > matching the configuration file for their board (if one exists.)
>>
>>  in debian this is generally discouraged.  in the work environment in
>> which i find myself it is a *definite* no.  we have enough to deal
>> with in the fact that this is only available for 3.2.0 rather than
>> 2.6.32.  we will need to do at least 2 to 3 months of testing before
>> 3.2.0 can be *considered* to be put into production.
>>
> And we are up to 3.9 already, and 2.6.32 was already dropped from the longterm
> supported kernel list. You are really running old kernels - by the time you
> start running 3.2, it may be getting close to EOL.

 doesn't matter: it's what debian/stable (or ubuntu) are using.
that's what's important here.  live stable production systems cannot
use stuff that's not been fully tested.  i once worked for an
organisation that was still using python 2.1... in 2007!

>>  and we would need to either create a debian package for the
>> stand-alone driver or compile ... no, we would not be able to compile
>> on the box because that would mean that the 800 machines in the field
>> would need to have gcc installed, that would mean 100% CPU for short
>> durations which would disrupt the customer, so no, definitely a debian
>> package, and that's a lot of work.
>>
>>  basically it is often completely impractical to use the standalone
>> driver, or quite a lot of work.
>>
>>
>> > That being said, I agree that not all users can build the standalone
>> > driver.
>>
>>  ... or it's a significant burden to do so, as well as requiring
>> months of testing before going live.
>>
> I think Jean referred more to individual users and did not really have
> distributions or large scale deployments in mind.

 indeed.  we're looking to buy 100 a month of these motherboards once
we have done the required 2-3 months of testing. as a free software
developer i don't mind discussing these things: many corporations
would not even remotely have permission to do so, so unfortunately you
would normally not get to hear about the ways in which the software
you've written is being deployed, large-scale.

>> > Also the cases where passing the force_id parameter works
>> > perfectly are rather rare. So I decided to add a note about force_id in
>> > the IT8728F entry only.
>>
>>  that works.  that works very well.  H77N could do with being added to
>> the list of gigabyte motherboards in that entry, it only lists 67 so
>> far.
>>
> Might be better to remove all of them. The driver is, after all, for a SuperIO
> chipset, not for specific Intel boards, and the chip is used quite widely
> on many boards nowadays.

 well... it kinda helps to identify it.  i did a search "H77N" - i did
*not* do a search by "SuperIO" or even "it87" - it was only after
spotting that text "unrecognised SuperIO chip" did i begin to track
things down.

 if i had had a page which had come up with "Gigabyte H77N" i would
have had a chance to find the information.

l.

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

Re: [lm-sensors] Gigabyte GA-Z77N-ITX Motherboard it87 sensors module (SuperIO chip ITE 8728)

[Guenter Roeck]

On Tue, May 07, 2013 at 03:17:05PM +0100, luke.leighton wrote:
> On Tue, May 7, 2013 at 2:43 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > On Tue, May 07, 2013 at 08:38:04AM +0100, luke.leighton wrote:
> >> On Tue, May 7, 2013 at 8:03 AM, Jean Delvare <khali@linux-fr.org> wrote:
> >>
> >> >>     modprobe it87 force_id=0x8720
> >> >
> >> > Thanks for sharing your findings. Obviously I already knew about it
> >> > all, but your post might help others in similar situations.
> >>
> >>  with the right keywords, aaanything is possible :)
> >>
> >> >> also, the following page http://www.lm-sensors.org/wiki/Devices was
> >> >> also quite terse and not immediately very helpful.  if the advice
> >> >> about force_id had been on the wiki page, i would have saved about 2
> >> >> hours of searching.
> >> >
> >> > Good point. However I'm not sure where I would add the information and
> >> > in what form. The force_id parameter isn't it87-specific, it is
> >> > supported by 11 different hwmon drivers, covering something 20 or 30
> >> > different devices. In general it is also better if users can build a
> >> > standalone driver because this gives them the right device name
> >> > matching the configuration file for their board (if one exists.)
> >>
> >>  in debian this is generally discouraged.  in the work environment in
> >> which i find myself it is a *definite* no.  we have enough to deal
> >> with in the fact that this is only available for 3.2.0 rather than
> >> 2.6.32.  we will need to do at least 2 to 3 months of testing before
> >> 3.2.0 can be *considered* to be put into production.
> >>
> > And we are up to 3.9 already, and 2.6.32 was already dropped from the longterm
> > supported kernel list. You are really running old kernels - by the time you
> > start running 3.2, it may be getting close to EOL.
> 
>  doesn't matter: it's what debian/stable (or ubuntu) are using.
> that's what's important here.  live stable production systems cannot
> use stuff that's not been fully tested.  i once worked for an
> organisation that was still using python 2.1... in 2007!
> 
> >>  and we would need to either create a debian package for the
> >> stand-alone driver or compile ... no, we would not be able to compile
> >> on the box because that would mean that the 800 machines in the field
> >> would need to have gcc installed, that would mean 100% CPU for short
> >> durations which would disrupt the customer, so no, definitely a debian
> >> package, and that's a lot of work.
> >>
> >>  basically it is often completely impractical to use the standalone
> >> driver, or quite a lot of work.
> >>
> >>
> >> > That being said, I agree that not all users can build the standalone
> >> > driver.
> >>
> >>  ... or it's a significant burden to do so, as well as requiring
> >> months of testing before going live.
> >>
> > I think Jean referred more to individual users and did not really have
> > distributions or large scale deployments in mind.
> 
>  indeed.  we're looking to buy 100 a month of these motherboards once
> we have done the required 2-3 months of testing. as a free software
> developer i don't mind discussing these things: many corporations
> would not even remotely have permission to do so, so unfortunately you
> would normally not get to hear about the ways in which the software
> you've written is being deployed, large-scale.
> 
> >> > Also the cases where passing the force_id parameter works
> >> > perfectly are rather rare. So I decided to add a note about force_id in
> >> > the IT8728F entry only.
> >>
> >>  that works.  that works very well.  H77N could do with being added to
> >> the list of gigabyte motherboards in that entry, it only lists 67 so
> >> far.
> >>
> > Might be better to remove all of them. The driver is, after all, for a SuperIO
> > chipset, not for specific Intel boards, and the chip is used quite widely
> > on many boards nowadays.
> 
>  well... it kinda helps to identify it.  i did a search "H77N" - i did
> *not* do a search by "SuperIO" or even "it87" - it was only after
> spotting that text "unrecognised SuperIO chip" did i begin to track
> things down.
> 
Maybe, but H77 vs. it87 is really completely unrelated. Other H77 boards
will support different SuperIO chips. Presumably you don't look up the
manufacturer of your car radio to find the correct tire size either ...

>  if i had had a page which had come up with "Gigabyte H77N" i would
> have had a chance to find the information.
> 
The information should really be in the Gigabyte manual. Now, turns out that
a Google search for "gigabyte h77n superio" returns the SuperIO chip as first
response. Not really sure how we could do better than that.

What may make sense is a note telling people to look for the SuperIO
chip on their board, not for any of the Intel chips. A database with
motherboards and matching SuperIO chips might make sense too, though
I am relatively sure that something like this already exists. If not,
you are of course welcome to create such a database and maintain it.

Thanks,
Guenter

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

Re: [lm-sensors] Gigabyte GA-Z77N-ITX Motherboard it87 sensors module (SuperIO chip ITE 8728)

[luke.leighton]

On Tue, May 7, 2013 at 4:07 PM, Guenter Roeck <linux@roeck-us.net> wrote:

>>  well... it kinda helps to identify it.  i did a search "H77N" - i did
>> *not* do a search by "SuperIO" or even "it87" - it was only after
>> spotting that text "unrecognised SuperIO chip" did i begin to track
>> things down.
>>
> Maybe, but H77 vs. it87 is really completely unrelated.

 ok i get it now.  H77N is not the designation of the motherboard, but
an intel chipset.  in which case i absolutely agree with you.

> The information should really be in the Gigabyte manual. Now, turns out that
> a Google search for "gigabyte h77n superio" returns the SuperIO chip as first
> response. Not really sure how we could do better than that.

 also based on this being only related to linux kernel 3.2.... wait....
http://www.h-online.com/open/news/item/Debian-7-0-will-use-3-2-kernel-1425560.html

 yep, linux 3.2 is definitely going to be around for a looong time [it
was only released in january!!]

 something to think about...

> What may make sense is a note telling people to look for the SuperIO
> chip on their board, not for any of the Intel chips. A database with
> motherboards and matching SuperIO chips might make sense too, though
> I am relatively sure that something like this already exists. If not,
> you are of course welcome to create such a database and maintain it.

 loovely :)  if i had a dozen boards i was investigating, i definitely would :)

> Thanks,
> Guenter

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

Re: [lm-sensors] Gigabyte GA-Z77N-ITX Motherboard it87 sensors module (SuperIO chip ITE 8728)

[Jean Delvare]

Hi Luke,

On Tue, 7 May 2013 16:24:38 +0100, luke.leighton wrote:
>  also based on this being only related to linux kernel 3.2.... wait....
> http://www.h-online.com/open/news/item/Debian-7-0-will-use-3-2-kernel-1425560.html
> 
>  yep, linux 3.2 is definitely going to be around for a looong time [it
> was only released in january!!]

Linux 2.6.1 was released in January as well ;)

-- 
Jean Delvare

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