[lm-sensors] Sensors-detect with DMI detection

[lm-sensors] Sensors-detect with DMI detection

[Ivo Manca]

Hey all,

We are three Computer Science students from the TH Rijswijk in the
Netherlands. Hans de Goede, our project supervisor, suggested it would be a
good idea to work on the LM sensors detection script. After hearing his
idea, we decided this could be a good idea and started to write a project
plan.

Mainly, it means that the sensor-detect script will be extended with
detection through DMI. It does not mean that the probing will be removed.

The project plan can be found at 
http://souchi.nl/prive/ProjectPlanDMIv1.1.pdf
Here you can find all information about our goal. We hope you think the 
extension
will be useful and wanted. Suggestions and feedback are always welcome.

Ivo Manca, Project Leader
Jasper Alias
Gijs van der Weg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20070222/64937185/attachment.html 

[lm-sensors] Sensors-detect with DMI detection

[Jean Delvare]

Hi Ivo,

On Thu, 22 Feb 2007 15:40:18 +0100, Ivo Manca wrote:
> We are three Computer Science students from the TH Rijswijk in the
> Netherlands. Hans de Goede, our project supervisor, suggested it would be a
> good idea to work on the LM sensors detection script. After hearing his
> idea, we decided this could be a good idea and started to write a project
> plan.
> 
> Mainly, it means that the sensor-detect script will be extended with
> detection through DMI. It does not mean that the probing will be removed.
> 
> The project plan can be found at 
> http://souchi.nl/prive/ProjectPlanDMIv1.1.pdf
> Here you can find all information about our goal. We hope you think the 
> extension
> will be useful and wanted. Suggestions and feedback are always welcome.

This sounds like a good plan, however I'd like to make sure that you do
not duplicate efforts that have been going on in this area:

1* Back in November 2006, I proposed a patch to sensors-detect to print
the DMI data at the beginning of sensors-detect:
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-November/018245.html
There was zero feedback so I did not apply it, however it might be a
good base for what you want to implement now.

2* Back in September 2006, Ivan Barrera proposed something named
"sconfig" which looked very similar to your own proposal:
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-September/017623.html
Unfortunately, nobody paid attention to this, despite the fact that
everybody seems to agree that such a tool is highly needed. So maybe
you want to look at whan Ivan did and/or take contact with him.

-- 
Jean Delvare

[lm-sensors] Sensors-detect with DMI detection

[Hans de Goede]

Jean Delvare wrote:
> Hi Ivo,
> 
> 
> This sounds like a good plan, however I'd like to make sure that you do
> not duplicate efforts that have been going on in this area:
> 
> 
> 2* Back in September 2006, Ivan Barrera proposed something named
> "sconfig" which looked very similar to your own proposal:
> http://lists.lm-sensors.org/pipermail/lm-sensors/2006-September/017623.html
> Unfortunately, nobody paid attention to this, despite the fact that
> everybody seems to agree that such a tool is highly needed. So maybe
> you want to look at whan Ivan did and/or take contact with him.
> 

Actually I did pay attention, as Ivan was doing this for a Google Summer of 
Code project, which was initiated by my from under the Fedora project umbrella.

Since I was Ivan's mentor that project I did closely follow his work, but 
unfortunately his results where not all that I had hoped for. Hence this new 
attempt, with lessons learned from the Ivan story. I've already given my 
students a link to the website where Ivan's stuff is hosted and told them to 
take a look at the things done and source code created by Ivan as a start.

Regards,

Hans

[lm-sensors] Sensors-detect with DMI detection

[Jean Delvare]

Hi Ivo,

On Thu, 22 Feb 2007 15:40:18 +0100, Ivo Manca wrote:
> The project plan can be found at 
> http://souchi.nl/prive/ProjectPlanDMIv1.1.pdf
> Here you can find all information about our goal. We hope you think the 
> extension
> will be useful and wanted. Suggestions and feedback are always welcome.

I've read the "Background Information" and "Objectives" parts, overall
it looks good, except that a proofread of the document would be very
welcome.

My comments:

* The primary objective mentions an "internal database". I'm not sure
what "internal" is supposed to mean here. Do you plan to embed a big
array of known motherboards inside the sensors-detect script itself?

* I'm very much in favor of command line parameters being added to
sensors-detect so that for example a non-interactive mode can be
supported. I wanted to do that myself for some time but could never
find the time to actually do it. Another useful mode would be a "quiet"
mode, which would hide all the details and present the probing summary.
It would still be interactive in that it should not overwrite the
configuration file without the user's consent, so it would be somewhat
intermediate between the current mode and a fully automated mode.

BTW, I think you really mean "first objective" and "second objective",
not primary and secondary.

-- 
Jean Delvare

[lm-sensors] Sensors-detect with DMI detection

[Ivo Manca]

Hey Jean,

First of all, sorry for my late response.

> I've read the "Background Information" and "Objectives" parts, overall
> it looks good, except that a proofread of the document would be very
> welcome.

We've tried to fix most of the errors and typo's in the document before 
sending in to the mailing list. However, English is not our main language 
and because of our school's short time limit there still may be some errors. 
Thanks for noticing it, we will check the document again and post an updated 
version as soon as possible.

> My comments:
>
> * The primary objective mentions an "internal database". I'm not sure
> what "internal" is supposed to mean here. Do you plan to embed a big
> array of known motherboards inside the sensors-detect script itself?

In this case, internal means that the database is stored on the user's 
computer. The reason we mentioned this is because we first considered an 
option which makes the script connect to the corresponding website. This 
however does not seem to be a very welcome "feature".

The actual place were the database will be stored is not yet decided.

> * I'm very much in favor of command line parameters being added to
> sensors-detect so that for example a non-interactive mode can be
> supported. I wanted to do that myself for some time but could never
> find the time to actually do it. Another useful mode would be a "quiet"
> mode, which would hide all the details and present the probing summary.
> It would still be interactive in that it should not overwrite the
> configuration file without the user's consent, so it would be somewhat
> intermediate between the current mode and a fully automated mode.

It seems that this did not end up in the final version of the project plan 
but this was also our view.
The command line switches we were thinking of adding, include:
* An automatic (or: non-interactive) mode, which will only use the DMI 
information to detect the sensors.
* A mode which first uses the DMI information and then asks whether or not 
the user wants to probe afterwards.
* A probing-only mode. For various reasons it might be welcome to keep this 
mode, for example: if for some reason the DMI information is bogus.

This automatic mode could also be very useful for newly installed 
configurations. In this case the user will already have a configured 
sensors.conf and is able to use the software "out-of-the-box". However, this 
is just a thought.

We've already figured out that the default option of sensors-detect should 
not overwrite an existing configuration file without asking first. It might 
give some frustration to the users..

> BTW, I think you really mean "first objective" and "second objective",
> not primary and secondary.

We meant: "Most important" and "Less important". I thought primary and 
secondary was a correct translation for this. They both still need to (and 
will) be completed though.

Ivo Manca 

[lm-sensors] Sensors-detect with DMI detection

[Jean Delvare]

Hi Ivo,

On Tue, 27 Feb 2007 11:59:03 +0100, Ivo Manca wrote:
> Hey Jean,
> 
> First of all, sorry for my late response.

Late response? You replied within 2 hours, it took me four days ;)

> > My comments:
> >
> > * The primary objective mentions an "internal database". I'm not sure
> > what "internal" is supposed to mean here. Do you plan to embed a big
> > array of known motherboards inside the sensors-detect script itself?
> 
> In this case, internal means that the database is stored on the user's 
> computer. The reason we mentioned this is because we first considered an 

In this case the correct term would be "local", not "internal".

> option which makes the script connect to the corresponding website. This 
> however does not seem to be a very welcome "feature".

I think it is. There's nothing wrong with fetching data file updates
from the net. New motherboard models are released so frequently that
it's very likely that the user won't find his model in the local
database (provided by his distribution, so including a 6 to 9-month old
version of lm_sensors.) A remote repository makes sense IMHO.

But of course having a local cache can be good too. Not everyone has a
permanent access to Internet, and our server might be temporarily
unresponsive or be moved to a different location.

So both options are really open. It's up to you. Either option will be
better than what we currently have anyway :)

> 
> The actual place were the database will be stored is not yet decided.
> 
> > * I'm very much in favor of command line parameters being added to
> > sensors-detect so that for example a non-interactive mode can be
> > supported. I wanted to do that myself for some time but could never
> > find the time to actually do it. Another useful mode would be a "quiet"
> > mode, which would hide all the details and present the probing summary.
> > It would still be interactive in that it should not overwrite the
> > configuration file without the user's consent, so it would be somewhat
> > intermediate between the current mode and a fully automated mode.
> 
> It seems that this did not end up in the final version of the project plan 
> but this was also our view.
> The command line switches we were thinking of adding, include:
> * An automatic (or: non-interactive) mode, which will only use the DMI 
> information to detect the sensors.
> * A mode which first uses the DMI information and then asks whether or not 
> the user wants to probe afterwards.
> * A probing-only mode. For various reasons it might be welcome to keep this 
> mode, for example: if for some reason the DMI information is bogus.

I'm not sure it makes sense to have command line switches for the
interactive mode itself. You can simply propose the user to check the
DMI table (default Y), then propose to probe the hardware (default N if
the system was found in the database.)

The command line options would be most valuable for the non-interactive
mode: one option to only use the DMI database, one option to only use
probing, one option to try DMI first then fallback to probing.

> This automatic mode could also be very useful for newly installed 
> configurations. In this case the user will already have a configured 
> sensors.conf and is able to use the software "out-of-the-box". However, this 
> is just a thought.

Agreed.

> We've already figured out that the default option of sensors-detect should 
> not overwrite an existing configuration file without asking first. It might 
> give some frustration to the users..

True. That being said, in non-interactive mode, it might make sense to
backup the old config file and write the new one (by default or with an
option.)

> > BTW, I think you really mean "first objective" and "second objective",
> > not primary and secondary.
> 
> We meant: "Most important" and "Less important". I thought primary and 
> secondary was a correct translation for this. They both still need to (and 
> will) be completed though.

If you meant "most important" and "less important" then "primary" and
"secondary" are correct. But my understanding is that the first
objective is a required prerequisite to implement the second one, too.

-- 
Jean Delvare

[lm-sensors] Sensors-detect with DMI detection

[Ivo Manca]

Hey Jean

> Late response? You replied within 2 hours, it took me four days ;)
True; this response was quite fast. I was actually thinking about the first 
post of yours and my first response in general ;)

> In this case the correct term would be "local", not "internal".
How obvious; you're right.

> I think it is. There's nothing wrong with fetching data file updates
> from the net. New motherboard models are released so frequently that
> it's very likely that the user won't find his model in the local
> database (provided by his distribution, so including a 6 to 9-month old
> version of lm_sensors.) A remote repository makes sense IMHO.
>
> But of course having a local cache can be good too. Not everyone has a
> permanent access to Internet, and our server might be temporarily
> unresponsive or be moved to a different location.
>
> So both options are really open. It's up to you. Either option will be
> better than what we currently have anyway :)
The local cache is something we wanted to use no matter what. It can be very 
annoying if software doesn't work, simply because you don't have an internet 
connection at that moment. But, the cache can get out-dated.

I agree that it should be able to update this cache but I'm not sure yet 
how. Should the sensors_detect script try and find a new data file every 
time it's executed with DMI support, or should it get a parameter for either 
enabling or disabling this feature? That's something we've got to give a 
thought.

> I'm not sure it makes sense to have command line switches for the
> interactive mode itself. You can simply propose the user to check the
> DMI table (default Y), then propose to probe the hardware (default N if
> the system was found in the database.)
>
> The command line options would be most valuable for the non-interactive
> mode: one option to only use the DMI database, one option to only use
> probing, one option to try DMI first then fallback to probing.

That actually sums up every sensible option, doesn't it? ;). Right now, I 
can't find a reason not to do it that way.

> True. That being said, in non-interactive mode, it might make sense to
> backup the old config file and write the new one (by default or with an
> option.)
Agree.

> If you meant "most important" and "less important" then "primary" and
> "secondary" are correct. But my understanding is that the first
> objective is a required prerequisite to implement the second one, too.

It is.
However, we are not sure yet if we're going to completely implement the 
first objective first, before starting on the second. If we make a good 
design for both objectives we are able to script this webinterface in 
relatively little time. This can be a big advantage since we only got a 
fixed amount of weeks to finish this assignment for school ("if we fix 
things afterwards, they don't count for the project anymore"). After this 
website is "live" we can easily gather information from various users and 
configurations, which makes it easier to find (and fix) bugs in an early 
stage.

After the detection script seems to be more than capable of doing the job, 
we we can expand the webinterface to make it more user friendly, depending 
on progress being made.

I hope this clarifies it a bit. I'm not sure whether or not "Primary" and 
"Secondary" are the correct terms to use, but it seems to cause confusion so 
it obviously isn't. We should modify that chapter and add some explanation 
there ;)

Ivo 

[lm-sensors] Sensors-detect with DMI detection

[Rudolf Marek]

Hello Ivo,

Back in the 2004 (12.06.2004 15:04 ;) I collected some DMI strings from 
different machines, please check the attachment for some summary and bellow for 
the 2004 raw data.

Rudolf

         DMI type 1, 25 bytes.
         System Information
                 Manufacturer: ASUSTeK Computer INC.
                 Product Name: A7N8X2.0
--
         DMI type 2, 8 bytes.
         Base Board Information
                 Manufacturer: ASUSTeK Computer INC.
                 Product Name: A7N8X2.0
--
         DMI type 3, 13 bytes.
         Chassis Information
                 Manufacturer: Chassis Manufactture
                 Type: Desktop

         DMI type 1, 25 bytes.
         System Information
                 Manufacturer: IBM
                 Product Name: 2722CDG
--
         DMI type 2, 8 bytes.
         Base Board Information
                 Manufacturer: IBM
                 Product Name: 2722CDG
--
         DMI type 3, 17 bytes.
         Chassis Information
                 Manufacturer: IBM
                 Type: Notebook


ANd from my computer in prague.
        DMI type 1, 25 bytes.
        System Information Block
                Vendor: System Manufacturer
                Product: System Name
-- 
        DMI type 2, 8 bytes.
        Board Information Block
                Vendor: ASUSTeK Computer INC.
                Product: P4B533-E
-- 
        DMI type 3, 17 bytes.
        Chassis Information Block
                Vendor: Chassis Manufacture
                Chassis Type: Tower


triton:~# dmidecode|grep -A 3 'type [123],'
         DMI type 1, 25 bytes.
         System Information
                 Manufacturer: VIA Technologies, Inc.
                 Product Name: VT8366/A-8233
--
         DMI type 2, 8 bytes.
         Base Board Information
                 Manufacturer: <BAD INDEX>
                 Product Name: <BAD INDEX>
--
         DMI type 3, 17 bytes.
         Chassis Information
                 Manufacturer: <BAD INDEX>
                 Type: Desktop
--
         DMI type 3, 4 bytes.
         Chassis Information
Handle 0x001C
         DMI type 17, 27 bytes.
BListy:~# dmidecode|grep -A 3 'type [123],'
         DMI type 1, 25 bytes.
         System Information
                 Manufacturer: Intel Corporation
                 Product Name: SE7505VB2
--
         DMI type 2, 8 bytes.
         Base Board Information
                 Manufacturer: Intel Corporation
                 Product Name: SE7505VB2 Board
--
         DMI type 3, 17 bytes.
         Chassis Information
                 Manufacturer: No Enclosure
                 Type: Tower
jhr:~# dmidecode|grep -A 3 'type [123],'
         DMI type 1, 25 bytes.
         System Information
                 Manufacturer: VIA Technologies, Inc.
                 Product Name: VT82C692BX
--
         DMI type 2, 8 bytes.
         Base Board Information
                 Manufacturer:
                 Product Name: 693-596-ITE
--
         DMI type 3, 13 bytes.
         Chassis Information
                 Manufacturer:
                 Type: Unknown
Imladris:/home/joe# dmidecode|grep -A 3 'type [123],'
         DMI type 1, 25 bytes.
         System Information
                 Manufacturer: VIA Technologies, Inc.
                 Product Name: VT8363
--
         DMI type 2, 8 bytes.
         Base Board Information
                 Manufacturer:
                 Product Name: 8363-686B
--
         DMI type 3, 17 bytes.
         Chassis Information
                 Manufacturer:
                 Type: Desktop
ssh:~# dmidecode|grep -A 3 'type [123],'
         DMI type 1, 25 bytes.
         System Information
                 Manufacturer: To be Filled
                 Product Name: To be Filled
--
         DMI type 2, 8 bytes.
         Base Board Information
                 Manufacturer: Supermicro Inc.
                 Product Name: Intel 440BX/440GX
--
         DMI type 3, 13 bytes.
         Chassis Information
                 Manufacturer: To be Filled
                 Type: Desktop
Lothlorien:/home/joe# dmidecode|grep -A 3 'type [123],'
         DMI type 1, 25 bytes.
         System Information
                 Manufacturer: Acer
                 Product Name: TravelMate 220
--
         DMI type 2, 8 bytes.
         Base Board Information
                 Manufacturer: Acer
                 Product Name: Intel Almador-M
--
         DMI type 3, 13 bytes.
         Chassis Information
                 Manufacturer: Acer
                 Type: Notebook
jboss:~# dmidecode|grep -A 3 'type [123],'
         DMI type 1, 25 bytes.
         System Information
                 Manufacturer: IBM
                 Product Name: 6893520
--
         DMI type 2, 8 bytes.
         Base Board Information
                 Manufacturer: IBM
                 Product Name: 6893520
--
         DMI type 3, 13 bytes.
         Chassis Information
                 Manufacturer: IBM
                 Type: Desktop
Moria:~# dmidecode
# dmidecode 2.4
# No SMBIOS nor DMI entry point found, sorry.
Dylan:~# dmidecode|grep -A 3 'type [123],'
         DMI type 1, 8 bytes.
         System Information
                 Manufacturer:
                 Product Name:
--
         DMI type 2, 8 bytes.
         Base Board Information
                 Manufacturer:
                 Product Name: i430TX-8679
--
         DMI type 3, 9 bytes.
         Chassis Information
                 Manufacturer:
                 Type: Unknown
r3:~# dmidecode|grep -A 3 'type [123],'
         DMI type 1, 25 bytes.
         System Information
                 Manufacturer: Intel
                 Product Name:
--
         DMI type 2, 8 bytes.
         Base Board Information
                 Manufacturer: Intel
                 Product Name: SE7501WV2S
--
         DMI type 3, 17 bytes.
         Chassis Information
                 Manufacturer: Intel Corporation
                 Type: Rack Mount Chassis
gw:~# dmidecode|grep -A 3 'type [123],'
         DMI type 1, 25 bytes.
         System Information
                 Manufacturer:
                 Product Name:
--
         DMI type 2, 8 bytes.
         Base Board Information
                 Manufacturer: Intel Corporation
                 Product Name: D815EPE2U
--
         DMI type 3, 17 bytes.
         Chassis Information
                 Manufacturer:
                 Type: Unknown
Gondolin:~# dmidecode|grep -A 3 'type [123],'
         DMI type 1, 8 bytes.
         System Information
                 Manufacturer: System Manufacturer
                 Product Name: System Name
--
         DMI type 2, 8 bytes.
         Base Board Information
                 Manufacturer: ASUSTeK Computer INC.
                 Product Name: P2B
--
         DMI type 3, 9 bytes.
         Chassis Information
                 Manufacturer: Chassis Manufacture
                 Type: Unknown




root at service:~# dmidecode  |grep -A 3 "type [123],"     DMI type 1, 25
bytes.
         System Information
                 Manufacturer: System Manufacturer
                 Product Name: System Name
--
         DMI type 2, 8 bytes.
         Base Board Information
                 Manufacturer: ASUSTeK Computer INC.
                 Product Name: PU-DLS
--
         DMI type 3, 17 bytes.
         Chassis Information
                 Manufacturer: Chassis Manufacture
                 Type: Tower

         DMI type 1, 25 bytes.
         System Information

Manufacturer:
                 Product Name:
--
         DMI type 2, 8 bytes.
         Base Board Information
                 Manufacturer: Intel Corporation
                 Product Name: D815EPFV
--
         DMI type 3, 17 bytes.
         Chassis Information

Manufacturer:
                 Type: Unknown

nms1:~# dmidecode  |grep -A 3 "type [123],"
         DMI type 1, 25 bytes.
         System Information
                 Manufacturer:
                 Product Name:
--
         DMI type 2, 8 bytes.
         Base Board Information
                 Manufacturer: Gigabyte Technology Co. Ltd.
                 Product Name: i440BX-W977
--
         DMI type 3, 13 bytes.
         Chassis Information
                 Manufacturer:
                 Type: Unknown
(nms1.sh)
b0re:/home/wilder# dmidecode  |grep -A 3 "type [123],"
         DMI type 1, 25 bytes.
         System Information
                 Manufacturer: System Manufacturer
                 Product Name: System Name
--
         DMI type 2, 8 bytes.
         Base Board Information
                 Manufacturer: ASUSTeK Computer INC.
                 Product Name: P4S8X-X
--
         DMI type 3, 17 bytes.
         Chassis Information
                 Manufacturer: Chassis Manufacture
                 Type: Tower
(hysteria.cz)

and this only from one grep

[15:07] <@jammic> jedina informacia z toho grepu je
Product
         Name: i440BX-W83977
[15:07] <@jammic>                 Type: Desktop

fw:~# dmidecode  |grep -A 3 "type [123],"
         DMI type 1, 25 bytes.
         System Information
                 Manufacturer: Dell Computer Corp.
                 Product Name: PowerEdge 350
--
         DMI type 2, 8 bytes.
         Base Board Information
                 Manufacturer: Intel Corporation
                 Product Name: TR440BXA
--
         DMI type 3, 17 bytes.
         Chassis Information

Manufacturer:
                 Type: Unknown
(zakaznik c.1)
         DMI type 1, 25 bytes.
         System Information
                 Manufacturer: Dell Computer Corporation
                 Product Name: PowerEdge 2550
--
         DMI type 3, 13 bytes.
         Chassis Information
                 Manufacturer: Dell Computer Corporation
                 Type: Rack Mount Chassis
(zakaznik c.2)
         DMI type 1, 25 bytes.
         System Information
                 Manufacturer: Dell Computer Corporation
                 Product Name: PowerEdge 2650
--
         DMI type 2, 9 bytes.
         Base Board Information
                 Manufacturer: Dell Computer Corporation
                 Product Name: 0H3099
--
         DMI type 3, 17 bytes.
         Chassis Information
                 Manufacturer: Dell Computer Corporation
                 Type: Rack Mount Chassis
(zakaznik c.3)


         DMI type 1, 25 bytes.
         System Information
                 Manufacturer: Dell Computer Corporation
                 Product Name: PowerEdge 2550
--
         DMI type 3, 13 bytes.
         Chassis Information
                 Manufacturer: Dell Computer Corporation
                 Type: Rack Mount Chassis
(zakaznuik c.4)

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmi_strucs
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20070227/af51ee2b/attachment-0001.pl 

[lm-sensors] Sensors-detect with DMI detection

[Hans de Goede]

Rudolf Marek wrote:
> Hello Ivo,
> 
> Back in the 2004 (12.06.2004 15:04 ;) I collected some DMI strings from 
> different machines, please check the attachment for some summary and 
> bellow for the 2004 raw data.
> 
> Rudolf
> 

Interesting stuff. Ivo, Gijs and Jasper. It looks like we need only need 
to use the "Base Board" info from dmi, but also the "System info" as 
some boards seem to fill "System info" with sensible info while filling 
"Base Board" with less sensible info. I think this isn't hard todo, all 
these fields are defined in the BIOS, and thus motherboard specific, 
they should just all match, otherwise its a different motherboard.

(In case of changes because of BIOS updates we should be able to match 
multiple DMI-table-entries to one motherboard-table-entry. Where with 
table I mean database tables.

Regards,

Hans

[lm-sensors] Sensors-detect with DMI detection

[Jasper Alias]

An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20070228/159a643e/attachment.html 

[lm-sensors] Sensors-detect with DMI detection

[Jean Delvare]

Jasper, please don't send HTML-only e-mails to the lm-sensors list.

Jasper Alias wrote:
> Agreed we should be able to include both base info and
> system info into the system. Maybe we can check the values in
> those fields and then let the system decide with of the two
> contains the most sensible info and select that info field to
> be used.

It might be non-trivial to determine which fields contain relevant
information and which do not. If the fields are empty it's clear they
aren't relevant, but sometimes vendors put random crap in the fields
instead, such as "None" or "System Manufacturer" or "To Be Filled By
O.E.M.". Anyway, as Hans suggested, we don't really need to find out
which fields are most relevant. We can use all four fields as the key
to identify the motherboard, if parts of the key aren't meaningful it
doesn't really matter.

BTW, as the dmidecode maintainer, I have a lot of BIOS ROM images I use
for my regression tests. I can provide the system and board
manufacturer and product strings for all of them, to complement
Rudolf's list, if you are interested.

-- 
Jean Delvare

[lm-sensors] Sensors-detect with DMI detection

[Hans de Goede]

Jean Delvare wrote:
> Jasper, please don't send HTML-only e-mails to the lm-sensors list.
> 
> Jasper Alias wrote:
>> Agreed we should be able to include both base info and
>> system info into the system. Maybe we can check the values in
>> those fields and then let the system decide with of the two
>> contains the most sensible info and select that info field to
>> be used.
> 
> It might be non-trivial to determine which fields contain relevant
> information and which do not. If the fields are empty it's clear they
> aren't relevant, but sometimes vendors put random crap in the fields
> instead, such as "None" or "System Manufacturer" or "To Be Filled By
> O.E.M.". Anyway, as Hans suggested, we don't really need to find out
> which fields are most relevant. We can use all four fields as the key
> to identify the motherboard, if parts of the key aren't meaningful it
> doesn't really matter.
> 

Exactly, except when the whole key isn't relevant, iow all 4 Fields 
contain crap / are to generic to uniquely identify a motherboard.

That is why we need a queue on the website for new motherboard dmi-info 
+ lm-sensors-config submissions, and that queue needs to be checked 
manually, we cannot expect well meaning end-users to make the decission 
of the DMI info is unique enough. And on top of that a rating system 
where people can say, good config works for me too, or crappy config 
doesn't work.

Regards,

Hans

[lm-sensors] Sensors-detect with DMI detection

[Jean Delvare]

Hi Hans,

On Thu, 01 Mar 2007 09:13:36 +0100, Hans de Goede wrote:
> Jean Delvare wrote:
> > It might be non-trivial to determine which fields contain relevant
> > information and which do not. If the fields are empty it's clear they
> > aren't relevant, but sometimes vendors put random crap in the fields
> > instead, such as "None" or "System Manufacturer" or "To Be Filled By
> > O.E.M.". Anyway, as Hans suggested, we don't really need to find out
> > which fields are most relevant. We can use all four fields as the key
> > to identify the motherboard, if parts of the key aren't meaningful it
> > doesn't really matter.
> 
> Exactly, except when the whole key isn't relevant, iow all 4 Fields 
> contain crap / are to generic to uniquely identify a motherboard.

True, this kind of board exists :(

> That is why we need a queue on the website for new motherboard dmi-info 
> + lm-sensors-config submissions, and that queue needs to be checked 
> manually, we cannot expect well meaning end-users to make the decission 
> of the DMI info is unique enough. And on top of that a rating system 
> where people can say, good config works for me too, or crappy config 
> doesn't work.

Another approach is to let the submissions go through but in an
"unconfirmed" state. If two unconfirmed sumbissions have the same DMI
signature but list different drivers, we demote them to state "bogus"
or something similar.

Anyway, I don't really care about the exact implementation, it's up to
your students. Now that they are aware that the DMI data might not be
100% reliable, I'm certain they'll come up with a solution.

-- 
Jean Delvare

[lm-sensors] Sensors-detect with DMI detection

[Ivo Manca]

Hey Jean,

Just a few more questions from our side ;).

First of all, is it good idea to scan for sensors in the CPU's after our 
script successfully finds a match with the DMI information?
If we don't do this, the user might have a disadvantage using the new way of 
detection, since the DMI information will only used be for mainboard 
information.
However, we are not completely sure if the CPU detection is currently 
completely safe. Do you have any idea about that? Because if it isn't, it 
might not be a good idea to "just" let that also run.

Secondly, do you prefer using the local database (/cache, which contains the 
dmi-info versus configuration) as the default option, or to prefer it when 
the default option fetching the online database first?

Downloading the online database is a big pro, since faulty and new 
configurations can be fixed and updated.

Just wondering what you think about it.

You were also saying that you could provided quite some more DMI strings to 
complement the list Rudolf send earlier. Could you please do that? Would be 
nice to find out about strange exceptions in an early stage ;).

Thanks in advance,

Ivo Manca
Gijs van der Weg
Jasper Alias


----- Original Message ----- 
From: "Jean Delvare" <khali at linux-fr.org>
To: "Hans de Goede" <j.w.r.degoede at hhs.nl>
Cc: <lm-sensors at lm-sensors.org>
Sent: Thursday 1 March 2007 9:54
Subject: Re: [lm-sensors] Sensors-detect with DMI detection


> Hi Hans,
>
> On Thu, 01 Mar 2007 09:13:36 +0100, Hans de Goede wrote:
>> Jean Delvare wrote:
>> > It might be non-trivial to determine which fields contain relevant
>> > information and which do not. If the fields are empty it's clear they
>> > aren't relevant, but sometimes vendors put random crap in the fields
>> > instead, such as "None" or "System Manufacturer" or "To Be Filled By
>> > O.E.M.". Anyway, as Hans suggested, we don't really need to find out
>> > which fields are most relevant. We can use all four fields as the key
>> > to identify the motherboard, if parts of the key aren't meaningful it
>> > doesn't really matter.
>>
>> Exactly, except when the whole key isn't relevant, iow all 4 Fields
>> contain crap / are to generic to uniquely identify a motherboard.
>
> True, this kind of board exists :(
>
>> That is why we need a queue on the website for new motherboard dmi-info
>> + lm-sensors-config submissions, and that queue needs to be checked
>> manually, we cannot expect well meaning end-users to make the decission
>> of the DMI info is unique enough. And on top of that a rating system
>> where people can say, good config works for me too, or crappy config
>> doesn't work.
>
> Another approach is to let the submissions go through but in an
> "unconfirmed" state. If two unconfirmed sumbissions have the same DMI
> signature but list different drivers, we demote them to state "bogus"
> or something similar.
>
> Anyway, I don't really care about the exact implementation, it's up to
> your students. Now that they are aware that the DMI data might not be
> 100% reliable, I'm certain they'll come up with a solution.
>
> -- 
> Jean Delvare
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors at lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors 

[lm-sensors] Sensors-detect with DMI detection

[Jean Delvare]

Hi Ivo,

On Fri, 16 Mar 2007 14:06:08 +0100, Ivo Manca wrote:
> First of all, is it good idea to scan for sensors in the CPU's after our 
> script successfully finds a match with the DMI information?
> If we don't do this, the user might have a disadvantage using the new way of 
> detection, since the DMI information will only used be for mainboard 
> information.
> However, we are not completely sure if the CPU detection is currently 
> completely safe. Do you have any idea about that? Because if it isn't, it 
> might not be a good idea to "just" let that also run.

This is a good point. DMI data is indeed mainly about the motherboard,
while sensors can be found in other parts of the computer: CPU as you
found yourself, but also graphics adapter, memory module or hard disk
drive (not yet supported by lm-sensors.) The DMI database you're
working on can obviously only cover the motherboard sensors.

The current detection of CPU-embedded sensors is totally safe. It's
not based on physical probing as is the case for SMBus or Super-I/O
hardware monitoring chips. Instead, it is based on the presence of a
given PCI device (for AMD) or on the CPU ID (for Intel.) So it's OK to
include that part of sensors-detect in conjunction with your DMI-based
identification for the motherboard sensors.

Note that PCI drivers can be automatically loaded, so we could even
stop handling them in sensors-detect. We leave them in for
completeness, but chances are that the driver will already be loaded
before the user runs sensors-detect (assuming the required driver is
available on the system, of course.)

> Secondly, do you prefer using the local database (/cache, which contains the 
> dmi-info versus configuration) as the default option, or to prefer it when 
> the default option fetching the online database first?
> 
> Downloading the online database is a big pro, since faulty and new 
> configurations can be fixed and updated.
> 
> Just wondering what you think about it.

Good point again. Using the local database first will lower the load on
our server significantly, and will be overall faster for the user.
Missing configurations that were added later to the online database are
not a problem, we obviously want to try the online database if the
local cache has no information. The case where the configuration file
was updated is admittedly more problematic. I wonder how frequently the
configurations will be updated in practice. It's hard to predict.

I'm not too sure, but I'd say use the online database first, and
fallback to the cache if network is not available OR if the user
doesn't want the script to connect (a command-line option would be
welcome.)

> You were also saying that you could provided quite some more DMI strings to 
> complement the list Rudolf send earlier. Could you please do that? Would be 
> nice to find out about strange exceptions in an early stage ;).

OK, I will extract the info and send it to you in private tomorrow.

-- 
Jean Delvare

[lm-sensors] Sensors-detect with DMI detection

[Ivo Manca]

Hey Jean,


> This is a good point. DMI data is indeed mainly about the motherboard,
> while sensors can be found in other parts of the computer: CPU as you
> found yourself, but also graphics adapter, memory module or hard disk
> drive (not yet supported by lm-sensors.) The DMI database you're
> working on can obviously only cover the motherboard sensors.

We were aware about these situaties. But since the harddisk and videocard 
sensors are found by probing, we'd rather not do anything with them. Because 
we figured out the CPU detection might be safe, we considered that option as 
well.

> The current detection of CPU-embedded sensors is totally safe. It's
> not based on physical probing as is the case for SMBus or Super-I/O
> hardware monitoring chips. Instead, it is based on the presence of a
> given PCI device (for AMD) or on the CPU ID (for Intel.) So it's OK to
> include that part of sensors-detect in conjunction with your DMI-based
> identification for the motherboard sensors.

That sounds good! Must be easy to call the cpu detection after the DMI 
probing has succeeded :).

> Note that PCI drivers can be automatically loaded, so we could even
> stop handling them in sensors-detect. We leave them in for
> completeness, but chances are that the driver will already be loaded
> before the user runs sensors-detect (assuming the required driver is
> available on the system, of course.)

Noted

> Good point again. Using the local database first will lower the load on
> our server significantly, and will be overall faster for the user.
> Missing configurations that were added later to the online database are
> not a problem, we obviously want to try the online database if the
> local cache has no information. The case where the configuration file
> was updated is admittedly more problematic. I wonder how frequently the
> configurations will be updated in practice. It's hard to predict.
>
> I'm not too sure, but I'd say use the online database first, and
> fallback to the cache if network is not available OR if the user
> doesn't want the script to connect (a command-line option would be
> welcome.)

Noted, and the user will ofcourse be noticed. A commandline option for 
dissabling it (or just _only_ updating the cache without doing anything 
else) will be added.

>> You were also saying that you could provided quite some more DMI strings 
>> to
>> complement the list Rudolf send earlier. Could you please do that? Would 
>> be
>> nice to find out about strange exceptions in an early stage ;).
>
> OK, I will extract the info and send it to you in private tomorrow.
>
> -- 
> Jean Delvare

I received them, thank you!

Ivo Manca 

[lm-sensors] Sensors-detect with DMI detection

[Ivo Manca]

Hi Jean,

Just a quick question (again ;)). Is it necesary for us to even think about 
supporting the 2.4 kernels?
I'm asking this, because if our addition doesn't get included before 
libsensors 3.x, it seems like we only get to work with 2.6, isn't it?

If that is so, we can drop a table in our database. This is because we want 
to add the kernel versions a configuration is working for. The easiest way 
to implement this, is to just modify the minimum kernel version for that 
configuration. If there's no support for 2.4, we can just add a field with 
the minimum working 2.6 kernel verson, like 2.6.10. Else, we must also 
register the minimum 2.4 version, either as a field, or with a 
table/relationship.

Just wondering :)

Ivo Manca
Jasper Alias
Gijs van der Weg

----- Original Message ----- 
From: "Jean Delvare" <khali at linux-fr.org>
To: "Ivo Manca" <pinkel at gmail.com>
Cc: "Hans de Goede" <j.w.r.degoede at hhs.nl>; <lm-sensors at lm-sensors.org>
Sent: Sunday 18 March 2007 21:29
Subject: Re: [lm-sensors] Sensors-detect with DMI detection


> Hi Ivo,
>
> On Fri, 16 Mar 2007 14:06:08 +0100, Ivo Manca wrote:
>> First of all, is it good idea to scan for sensors in the CPU's after our
>> script successfully finds a match with the DMI information?
>> If we don't do this, the user might have a disadvantage using the new way 
>> of
>> detection, since the DMI information will only used be for mainboard
>> information.
>> However, we are not completely sure if the CPU detection is currently
>> completely safe. Do you have any idea about that? Because if it isn't, it
>> might not be a good idea to "just" let that also run.
>
> This is a good point. DMI data is indeed mainly about the motherboard,
> while sensors can be found in other parts of the computer: CPU as you
> found yourself, but also graphics adapter, memory module or hard disk
> drive (not yet supported by lm-sensors.) The DMI database you're
> working on can obviously only cover the motherboard sensors.
>
> The current detection of CPU-embedded sensors is totally safe. It's
> not based on physical probing as is the case for SMBus or Super-I/O
> hardware monitoring chips. Instead, it is based on the presence of a
> given PCI device (for AMD) or on the CPU ID (for Intel.) So it's OK to
> include that part of sensors-detect in conjunction with your DMI-based
> identification for the motherboard sensors.
>
> Note that PCI drivers can be automatically loaded, so we could even
> stop handling them in sensors-detect. We leave them in for
> completeness, but chances are that the driver will already be loaded
> before the user runs sensors-detect (assuming the required driver is
> available on the system, of course.)
>
>> Secondly, do you prefer using the local database (/cache, which contains 
>> the
>> dmi-info versus configuration) as the default option, or to prefer it 
>> when
>> the default option fetching the online database first?
>>
>> Downloading the online database is a big pro, since faulty and new
>> configurations can be fixed and updated.
>>
>> Just wondering what you think about it.
>
> Good point again. Using the local database first will lower the load on
> our server significantly, and will be overall faster for the user.
> Missing configurations that were added later to the online database are
> not a problem, we obviously want to try the online database if the
> local cache has no information. The case where the configuration file
> was updated is admittedly more problematic. I wonder how frequently the
> configurations will be updated in practice. It's hard to predict.
>
> I'm not too sure, but I'd say use the online database first, and
> fallback to the cache if network is not available OR if the user
> doesn't want the script to connect (a command-line option would be
> welcome.)
>
>> You were also saying that you could provided quite some more DMI strings 
>> to
>> complement the list Rudolf send earlier. Could you please do that? Would 
>> be
>> nice to find out about strange exceptions in an early stage ;).
>
> OK, I will extract the info and send it to you in private tomorrow.
>
> -- 
> Jean Delvare 

[lm-sensors] Sensors-detect with DMI detection

[Jean Delvare]

Hi Ivo,

On Thu, 22 Mar 2007 11:09:14 +0100, Ivo Manca wrote:
> Just a quick question (again ;)). Is it necesary for us to even think about 
> supporting the 2.4 kernels?
> I'm asking this, because if our addition doesn't get included before 
> libsensors 3.x, it seems like we only get to work with 2.6, isn't it?

Side note: we are already at libsensors 3.x (unfortunately.) What you
refer to is lm-sensors 3.x, for which the libsensors version will be
4.x. Actually I think we should jump to lm-sensors 4.x directly to sync
the lib version with the package version again - but Mark seems to like
lm-sensors 3.x.

> If that is so, we can drop a table in our database. This is because we want 
> to add the kernel versions a configuration is working for. The easiest way 
> to implement this, is to just modify the minimum kernel version for that 
> configuration. If there's no support for 2.4, we can just add a field with 
> the minimum working 2.6 kernel verson, like 2.6.10. Else, we must also 
> register the minimum 2.4 version, either as a field, or with a 
> table/relationship.
> 
> Just wondering :)

We don't really care about 2.4 anymore. If you can support it for free,
alright. If it has a cost, just don't do it.

One thing which you will have to handle though are the syntax changes
to sensors.conf. Two things are going to happen in a (more or less)
near future:

* Mark Hoffman will add support for the "include" statement. Obviously,
the user will need libsensors 4.x if they download a configuration file
which uses such a statement. OTOH, I can't see any reason why an
include statement would be used in the configuration files for
motherboards, so maybe all you have to do is strip any include
statement before storing the configuration file in the database.

* Once the library discovers the device features autmatically,
sensors.conf will have to use the standard feature names, instead of
the custom ones. This means we'll have to fork sensors.conf.eg into an
old-style version and a new-style version. The configuration files
stored in your database will have the same problem - they will work
with either the old library, or the new one, but not both.

Note that it should be possible to translate old-style configuration
files to the new style automatically, using the same translation
rules which are used by libsensors today. A perl script would do. The
other way around is much more difficult, though, as you would need to
write an extensive reverse mapping table for every supported chip.

-- 
Jean Delvare

[lm-sensors] Sensors-detect with DMI detection

[Hans de Goede]

Jean Delvare wrote:
> Hi Ivo,
> 
> On Thu, 22 Mar 2007 11:09:14 +0100, Ivo Manca wrote:
>> Just a quick question (again ;)). Is it necesary for us to even think about 
>> supporting the 2.4 kernels?
>> I'm asking this, because if our addition doesn't get included before 
>> libsensors 3.x, it seems like we only get to work with 2.6, isn't it?
> 
> Side note: we are already at libsensors 3.x (unfortunately.) What you
> refer to is lm-sensors 3.x, for which the libsensors version will be
> 4.x. Actually I think we should jump to lm-sensors 4.x directly to sync
> the lib version with the package version again - but Mark seems to like
> lm-sensors 3.x.
> 
>> If that is so, we can drop a table in our database. This is because we want 
>> to add the kernel versions a configuration is working for. The easiest way 
>> to implement this, is to just modify the minimum kernel version for that 
>> configuration. If there's no support for 2.4, we can just add a field with 
>> the minimum working 2.6 kernel verson, like 2.6.10. Else, we must also 
>> register the minimum 2.4 version, either as a field, or with a 
>> table/relationship.
>>
>> Just wondering :)
> 
> We don't really care about 2.4 anymore. If you can support it for free,
> alright. If it has a cost, just don't do it.
> 
> One thing which you will have to handle though are the syntax changes
> to sensors.conf. Two things are going to happen in a (more or less)
> near future:
> 
> * Mark Hoffman will add support for the "include" statement. Obviously,
> the user will need libsensors 4.x if they download a configuration file
> which uses such a statement. OTOH, I can't see any reason why an
> include statement would be used in the configuration files for
> motherboards, so maybe all you have to do is strip any include
> statement before storing the configuration file in the database.
> 
> * Once the library discovers the device features autmatically,
> sensors.conf will have to use the standard feature names, instead of
> the custom ones. This means we'll have to fork sensors.conf.eg into an
> old-style version and a new-style version. The configuration files
> stored in your database will have the same problem - they will work
> with either the old library, or the new one, but not both.
> 
> Note that it should be possible to translate old-style configuration
> files to the new style automatically, using the same translation
> rules which are used by libsensors today. A perl script would do. The
> other way around is much more difficult, though, as you would need to
> write an extensive reverse mapping table for every supported chip.
> 

Wouldn't it be wise to target only 3.x / 4.x with the dmi-detect code, and thus 
assume dynamic chip support and the new syntax? I haven't been doing much 
lm-sensors related work myself lately, but I can make some time free to get the 
dyn chip support into the 3.0 branch asap, if that helps the dmi detect code to 
become future proof. I think only support 3.x / 4.x is easiest / best otherwise 
the code becomes convoluted with compatibility muck from the day it was written.

Regards,

Hans

[lm-sensors] Sensors-detect with DMI detection

[Jean Delvare]

Hi Hans,

On Fri, 23 Mar 2007 10:06:10 +0100, Hans de Goede wrote:
> Wouldn't it be wise to target only 3.x / 4.x with the dmi-detect code, and thus 
> assume dynamic chip support and the new syntax? I haven't been doing much 
> lm-sensors related work myself lately, but I can make some time free to get the 
> dyn chip support into the 3.0 branch asap, if that helps the dmi detect code to 
> become future proof. I think only support 3.x / 4.x is easiest / best otherwise 
> the code becomes convoluted with compatibility muck from the day it was written.

I tend to agree, yeah. The only problem is that I cannot give any
timeline for the dyn chip support, as I do not have the time to work on
it myself. But if you're going to do it, alright.

-- 
Jean Delvare