heci: a new driver for review and testing

[Andriy Gapon]

Some time ago I posted some ideas about HECI/MEI driver for FreeBSD:
http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006

I actually got around to implementing it (in initial/basic form):
http://people.freebsd.org/~avg/heci.tgz

Other drivers are:
[Linux] http://www.openamt.org/
[OpenSolaris]
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/intel/io/heci/

An example of what functionality this driver could provide:
http://article.gmane.org/gmane.linux.drivers.sensors/20398
This actually was my primary motivation for looking into this driver.

Your hardware may be supported by this driver if pciconf -lv has something like
the following:
none0@pci0:0:3:0:       class=0x078000 card=0x50448086 chip=0x29c48086 rev=0x02
hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '(Bearlake) HECI Controller'
    class      = simple comms

Here's how successful attachment of this driver looks on my system:
heci0: <Intel 82G33/G31/P35/P31 Express HECI/MEI Controller> mem
0xe0426100-0xe042610f irq 16 at device 3.0 on pci0
heci0: using MSI
heci0: [ITHREAD]
heci0: found ME client at address 0x03:
heci0:  status = 0x00
heci0:  protocol_name(guid) = A12FF5CA-FACB-4CB4-A958-19A23B2E6881
heci0: found ME client at address 0x07:
heci0:  status = 0x00
heci0:  protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB
heci0: found ME client at address 0x20:
heci0:  status = 0x00
heci0:  protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327
heci0: found ME client at address 0x21:
heci0:  status = 0x00
heci0:  protocol_name(guid) = 6B5205B9-8185-4519-B889-D98724B58607

The driver has many functional and programming shortcomings, but I still would
like to ask for its review and testing.
Please read the following warnings and notices:
1. right now the driver is provided only as a module.
2. the driver recognizes only PCI ID of 0x29c48086, which is what I tested it
with; please see hecireg.h for a list of potentially supported IDs and add your ID
to heci_probe().
3. heciio.h does not get installed into /usr/include, so for time being you need
to take an extra step to make it available to code that wishes to communicate to heci.
4. this driver has far less capabilities than Linux and OpenSolaris drivers, so
don't expect every OpenAMT program to work with it (but it does reliably work for
me for the QST thing).

Now more details about the code:
1. the code contains some style violations like overly long lines, probably
others; but I still would like to hear your comments on its style.
2. there are some bad design decisions like using the same mutex+condvar pair for
signaling different events (reception of data from ME, emptying of user buffer);
but I still would like to hear your comments about improving the design.
3. only a single connection is allowed for a host client
4. only a single connection is allowed to a ME client (if the client can support
more).
5. quite an arbitrary timeout is used in all places where we wait for simething to
happen.
6. no power management supported.
7. only messages of size less than 512 bytes are supported.
8. only complete messages are supported, multi-part messages are not.
9. userland is expected to read or write the whole message in one go.
10. poll/select functionality is not tested.
11. non-blocking reads/writes are not supported.
12. some (probably important) properties and statuses of ME clients are not
interpreted.
13. no specific support for watchdog and PTHI, only simple HECI/MEI communications.
14. probably many more...

I think that ultimately, if complete feature support is needed, it would be easier
to port the driver from either OpenSolaris or Linux than to add all the features
to the presented driver. This is because documentation/description for many
features is severely lacking in public access. I guess that Intel developers that
worked on the OpenAMT driver had much more detailed specifications to work with.
But reverse-engineering some parts of OpenAMT code is very hard.
You can see for yourself, if not for the hacker who decompiled a Windows DLL,
there would be no way of obtaining even GUID of QST client from public sources.

Thank you very much in advance for any feedback, comments, ideas!

P.S.
BTW, can/may I drop "alternatively GPL" wording from License block of the files I
borrowed from Intel? I.e. can a dual BSD+GPL licensed file be turned into BSD-only?
Some additional info. The files contain only some data structure/constants
definitions. I guess those are not copyrightable at all? I added a bunch of
comments to those file describing the constants and structs.


--
Andriy Gapon
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Robert Noland]

On Wed, 2009-10-14 at 20:12 +0300, Andriy Gapon wrote:
> Some time ago I posted some ideas about HECI/MEI driver for FreeBSD:
> http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006
>
> I actually got around to implementing it (in initial/basic form):
> http://people.freebsd.org/~avg/heci.tgz

Your getting a WITNESS warning from malloc() while holding a lock at
like 941 of heci.c

                mec = (struct me_client *)malloc(sizeof(*mec), M_HECI,
                    M_NOWAIT | M_ZERO);

fixes it.  It also locked up the machine when I tried to kldunload, but
haven't identified a root cause of that.

robert.

> Other drivers are:
> [Linux] http://www.openamt.org/
> [OpenSolaris]
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/intel/io/heci/
>
> An example of what functionality this driver could provide:
> http://article.gmane.org/gmane.linux.drivers.sensors/20398
> This actually was my primary motivation for looking into this driver.
>
> Your hardware may be supported by this driver if pciconf -lv has something like
> the following:
> none0@pci0:0:3:0:       class=0x078000 card=0x50448086 chip=0x29c48086 rev=0x02
> hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = '(Bearlake) HECI Controller'
>     class      = simple comms
>
> Here's how successful attachment of this driver looks on my system:
> heci0: <Intel 82G33/G31/P35/P31 Express HECI/MEI Controller> mem
> 0xe0426100-0xe042610f irq 16 at device 3.0 on pci0
> heci0: using MSI
> heci0: [ITHREAD]
> heci0: found ME client at address 0x03:
> heci0:  status = 0x00
> heci0:  protocol_name(guid) = A12FF5CA-FACB-4CB4-A958-19A23B2E6881
> heci0: found ME client at address 0x07:
> heci0:  status = 0x00
> heci0:  protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB
> heci0: found ME client at address 0x20:
> heci0:  status = 0x00
> heci0:  protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327
> heci0: found ME client at address 0x21:
> heci0:  status = 0x00
> heci0:  protocol_name(guid) = 6B5205B9-8185-4519-B889-D98724B58607
>
> The driver has many functional and programming shortcomings, but I still would
> like to ask for its review and testing.
> Please read the following warnings and notices:
> 1. right now the driver is provided only as a module.
> 2. the driver recognizes only PCI ID of 0x29c48086, which is what I tested it
> with; please see hecireg.h for a list of potentially supported IDs and add your ID
> to heci_probe().
> 3. heciio.h does not get installed into /usr/include, so for time being you need
> to take an extra step to make it available to code that wishes to communicate to heci.
> 4. this driver has far less capabilities than Linux and OpenSolaris drivers, so
> don't expect every OpenAMT program to work with it (but it does reliably work for
> me for the QST thing).
>
> Now more details about the code:
> 1. the code contains some style violations like overly long lines, probably
> others; but I still would like to hear your comments on its style.
> 2. there are some bad design decisions like using the same mutex+condvar pair for
> signaling different events (reception of data from ME, emptying of user buffer);
> but I still would like to hear your comments about improving the design.
> 3. only a single connection is allowed for a host client
> 4. only a single connection is allowed to a ME client (if the client can support
> more).
> 5. quite an arbitrary timeout is used in all places where we wait for simething to
> happen.
> 6. no power management supported.
> 7. only messages of size less than 512 bytes are supported.
> 8. only complete messages are supported, multi-part messages are not.
> 9. userland is expected to read or write the whole message in one go.
> 10. poll/select functionality is not tested.
> 11. non-blocking reads/writes are not supported.
> 12. some (probably important) properties and statuses of ME clients are not
> interpreted.
> 13. no specific support for watchdog and PTHI, only simple HECI/MEI communications.
> 14. probably many more...
>
> I think that ultimately, if complete feature support is needed, it would be easier
> to port the driver from either OpenSolaris or Linux than to add all the features
> to the presented driver. This is because documentation/description for many
> features is severely lacking in public access. I guess that Intel developers that
> worked on the OpenAMT driver had much more detailed specifications to work with.
> But reverse-engineering some parts of OpenAMT code is very hard.
> You can see for yourself, if not for the hacker who decompiled a Windows DLL,
> there would be no way of obtaining even GUID of QST client from public sources.
>
> Thank you very much in advance for any feedback, comments, ideas!
>
> P.S.
> BTW, can/may I drop "alternatively GPL" wording from License block of the files I
> borrowed from Intel? I.e. can a dual BSD+GPL licensed file be turned into BSD-only?
> Some additional info. The files contain only some data structure/constants
> definitions. I guess those are not copyrightable at all? I added a bunch of
> comments to those file describing the constants and structs.
>

--
Robert Noland <rnoland@...>
FreeBSD

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Robert Noland]

On Wed, 2009-10-14 at 20:12 +0300, Andriy Gapon wrote:

> Some time ago I posted some ideas about HECI/MEI driver for FreeBSD:
> http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006
>
> I actually got around to implementing it (in initial/basic form):
> http://people.freebsd.org/~avg/heci.tgz
>
> Other drivers are:
> [Linux] http://www.openamt.org/
> [OpenSolaris]
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/intel/io/heci/
>
> An example of what functionality this driver could provide:
> http://article.gmane.org/gmane.linux.drivers.sensors/20398
> This actually was my primary motivation for looking into this driver.

Could you also post the client code in some form more readily accessible
than trying to cut/paste from the web page?

robert.

> Your hardware may be supported by this driver if pciconf -lv has something like
> the following:
> none0@pci0:0:3:0:       class=0x078000 card=0x50448086 chip=0x29c48086 rev=0x02
> hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = '(Bearlake) HECI Controller'
>     class      = simple comms
>
> Here's how successful attachment of this driver looks on my system:
> heci0: <Intel 82G33/G31/P35/P31 Express HECI/MEI Controller> mem
> 0xe0426100-0xe042610f irq 16 at device 3.0 on pci0
> heci0: using MSI
> heci0: [ITHREAD]
> heci0: found ME client at address 0x03:
> heci0:  status = 0x00
> heci0:  protocol_name(guid) = A12FF5CA-FACB-4CB4-A958-19A23B2E6881
> heci0: found ME client at address 0x07:
> heci0:  status = 0x00
> heci0:  protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB
> heci0: found ME client at address 0x20:
> heci0:  status = 0x00
> heci0:  protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327
> heci0: found ME client at address 0x21:
> heci0:  status = 0x00
> heci0:  protocol_name(guid) = 6B5205B9-8185-4519-B889-D98724B58607
>
> The driver has many functional and programming shortcomings, but I still would
> like to ask for its review and testing.
> Please read the following warnings and notices:
> 1. right now the driver is provided only as a module.
> 2. the driver recognizes only PCI ID of 0x29c48086, which is what I tested it
> with; please see hecireg.h for a list of potentially supported IDs and add your ID
> to heci_probe().
> 3. heciio.h does not get installed into /usr/include, so for time being you need
> to take an extra step to make it available to code that wishes to communicate to heci.
> 4. this driver has far less capabilities than Linux and OpenSolaris drivers, so
> don't expect every OpenAMT program to work with it (but it does reliably work for
> me for the QST thing).
>
> Now more details about the code:
> 1. the code contains some style violations like overly long lines, probably
> others; but I still would like to hear your comments on its style.
> 2. there are some bad design decisions like using the same mutex+condvar pair for
> signaling different events (reception of data from ME, emptying of user buffer);
> but I still would like to hear your comments about improving the design.
> 3. only a single connection is allowed for a host client
> 4. only a single connection is allowed to a ME client (if the client can support
> more).
> 5. quite an arbitrary timeout is used in all places where we wait for simething to
> happen.
> 6. no power management supported.
> 7. only messages of size less than 512 bytes are supported.
> 8. only complete messages are supported, multi-part messages are not.
> 9. userland is expected to read or write the whole message in one go.
> 10. poll/select functionality is not tested.
> 11. non-blocking reads/writes are not supported.
> 12. some (probably important) properties and statuses of ME clients are not
> interpreted.
> 13. no specific support for watchdog and PTHI, only simple HECI/MEI communications.
> 14. probably many more...
>
> I think that ultimately, if complete feature support is needed, it would be easier
> to port the driver from either OpenSolaris or Linux than to add all the features
> to the presented driver. This is because documentation/description for many
> features is severely lacking in public access. I guess that Intel developers that
> worked on the OpenAMT driver had much more detailed specifications to work with.
> But reverse-engineering some parts of OpenAMT code is very hard.
> You can see for yourself, if not for the hacker who decompiled a Windows DLL,
> there would be no way of obtaining even GUID of QST client from public sources.
>
> Thank you very much in advance for any feedback, comments, ideas!
>
> P.S.
> BTW, can/may I drop "alternatively GPL" wording from License block of the files I
> borrowed from Intel? I.e. can a dual BSD+GPL licensed file be turned into BSD-only?
> Some additional info. The files contain only some data structure/constants
> definitions. I guess those are not copyrightable at all? I added a bunch of
> comments to those file describing the constants and structs.
>

--
Robert Noland <rnoland@...>
FreeBSD

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Carlos A. M. dos Santos]

On Wed, Oct 14, 2009 at 2:12 PM, Andriy Gapon <avg@...> wrote:

> BTW, can/may I drop "alternatively GPL" wording from License block of the files I
> borrowed from Intel? I.e. can a dual BSD+GPL licensed file be turned into BSD-only?

If Intel is the copyright owner then you can not change the license
without their permission.

--
My preferred quotation of Robert Louis Stevenson is "You cannot
make an omelette without breaking eggs". Not because I like the
omelettes, but because I like the sound of eggs being broken.
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Andriy Gapon]

on 15/10/2009 00:25 Robert Noland said the following:

> On Wed, 2009-10-14 at 20:12 +0300, Andriy Gapon wrote:
>> Some time ago I posted some ideas about HECI/MEI driver for FreeBSD:
>> http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006
>>
>> I actually got around to implementing it (in initial/basic form):
>> http://people.freebsd.org/~avg/heci.tgz
>
> Your getting a WITNESS warning from malloc() while holding a lock at
> like 941 of heci.c
>
>                 mec = (struct me_client *)malloc(sizeof(*mec), M_HECI,
>                     M_NOWAIT | M_ZERO);
>
> fixes it.

Shame on me!
I have to admit that tested/used this module only on stable/7 (amd64) and
without WITNESS/INVARIANTS.
Thank you for catching this.
I guess I should also add a check for malloc returning NULL.

> It also locked up the machine when I tried to kldunload, but
> haven't identified a root cause of that.

Haven't seen it here.
I will try to investigate.

--
Andriy Gapon
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Andriy Gapon]

on 15/10/2009 00:35 Robert Noland said the following:

> On Wed, 2009-10-14 at 20:12 +0300, Andriy Gapon wrote:
>> Some time ago I posted some ideas about HECI/MEI driver for FreeBSD:
>> http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006
>>
>> I actually got around to implementing it (in initial/basic form):
>> http://people.freebsd.org/~avg/heci.tgz
>>
>> Other drivers are:
>> [Linux] http://www.openamt.org/
>> [OpenSolaris]
>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/intel/io/heci/
>>
>> An example of what functionality this driver could provide:
>> http://article.gmane.org/gmane.linux.drivers.sensors/20398
>> This actually was my primary motivation for looking into this driver.
>
> Could you also post the client code in some form more readily accessible
> than trying to cut/paste from the web page?
>
> robert.

Sure:
http://people.freebsd.org/~avg/heci-qst.c
Sorry for not doing this from the very start.


--
Andriy Gapon
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Dag-Erling Smørgrav]

Andriy Gapon <avg@...> writes:
> BTW, can / may I drop "alternatively GPL" wording from License block
> of the files I borrowed from Intel?  I.e. can a dual BSD+GPL licensed
> file be turned into BSD-only?

No.  Why would you want to?

> Some additional info.  The files contain only some data structure /
> constants definitions.  I guess those are not copyrightable at all?

That's debatable.  It is probably safe to assume that they aren't *if*
they only describe the interface to another piece of software or to the
hardware, but if they represent internal data structures used by the
Linux driver, they are definitely copyrightable.

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Robert Noland]

On Thu, 2009-10-15 at 08:23 +0300, Andriy Gapon wrote:

> on 15/10/2009 00:25 Robert Noland said the following:
> > On Wed, 2009-10-14 at 20:12 +0300, Andriy Gapon wrote:
> >> Some time ago I posted some ideas about HECI/MEI driver for FreeBSD:
> >> http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006
> >>
> >> I actually got around to implementing it (in initial/basic form):
> >> http://people.freebsd.org/~avg/heci.tgz
> >
> > Your getting a WITNESS warning from malloc() while holding a lock at
> > like 941 of heci.c
> >
> >                 mec = (struct me_client *)malloc(sizeof(*mec), M_HECI,
> >                     M_NOWAIT | M_ZERO);
> >
> > fixes it.
>
> Shame on me!
> I have to admit that tested/used this module only on stable/7 (amd64) and
> without WITNESS/INVARIANTS.
> Thank you for catching this.
> I guess I should also add a check for malloc returning NULL.

Yes, with M_NOWAIT you should.

Here is the dmesg output.

heci0: <Intel 82G33/G31/P35/P31 Express HECI/MEI Controller> mem
0xd0526100-0xd052610f irq 16 at device 3.0 on pci0
heci0: using MSI
heci0: [ITHREAD]
heci0: found ME client at address 0x02:
heci0:  status = 0x00
heci0:  protocol_name(guid) = BB875E12-CB58-4D14-AE93-8566183C66C7
heci0: found ME client at address 0x03:
heci0:  status = 0x00
heci0:  protocol_name(guid) = A12FF5CA-FACB-4CB4-A958-19A23B2E6881
heci0: found ME client at address 0x06:
heci0:  status = 0x00
heci0:  protocol_name(guid) = 9B27FD6D-EF72-4967-BCC2-471A32679620
heci0: found ME client at address 0x07:
heci0:  status = 0x00
heci0:  protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB
heci0: found ME client at address 0x20:
heci0:  status = 0x00
heci0:  protocol_name(guid) = 23F27E9B-9D26-4FCE-9227-DE06446E5B06
heci0: found ME client at address 0x21:
heci0:  status = 0x00
heci0:  protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327
heci0: found ME client at address 0x22:
heci0:  status = 0x00
heci0:  protocol_name(guid) = 6B5205B9-8185-4519-B889-D98724B58607
heci0: found ME client at address 0x23:
heci0:  status = 0x00
heci0:  protocol_name(guid) = 9D9105BD-C8C6-41CA-AC28-84738E2CE9FD
heci0: found ME client at address 0x24:
heci0:  status = 0x00
heci0:  protocol_name(guid) = DC506909-7ADB-4A0D-B109-4E25E38C382C
heci0: found ME client at address 0x25:
heci0:  status = 0x00
heci0:  protocol_name(guid) = 6733A4DB-0476-4E7B-B3AF-BCFC29BEE7A7
heci0: found ME client at address 0x26:
heci0:  status = 0x00
heci0:  protocol_name(guid) = 12F80028-B4B7-4B2D-ACA8-46E0FF65814C
heci0: found ME client at address 0x27:
heci0:  status = 0x00
heci0:  protocol_name(guid) = 05B79A6F-4628-4D7F-899D-A91514CB32AB

robert.

> > It also locked up the machine when I tried to kldunload, but
> > haven't identified a root cause of that.
>
> Haven't seen it here.
> I will try to investigate.
>
--
Robert Noland <rnoland@...>
FreeBSD

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Carlos A. M. dos Santos]

On Wed, Oct 14, 2009 at 9:34 PM, Mike Meyer <mwm@...> wrote:

> On Wed, 14 Oct 2009 19:46:20 -0300
> "Carlos A. M. dos Santos" <unixmania@...> wrote:
>
>> On Wed, Oct 14, 2009 at 2:12 PM, Andriy Gapon <avg@...> wrote:
>>
>> > BTW, can/may I drop "alternatively GPL" wording from License block of the files I
>> > borrowed from Intel? I.e. can a dual BSD+GPL licensed file be turned into BSD-only?
>>
>> If Intel is the copyright owner then you can not change the license
>> without their permission.
>
> True. But he *has* their permission. They list the requirements for
> use and redistribution in the license block in question:
>
>  * Redistribution and use in source and binary forms, with or without
>  * modification, are permitted provided that the following conditions
>  * are met:
>  * 1. Redistributions of source code must retain the above copyright
>  *    notice, this list of conditions, and the following disclaimer,
>  *    without modification.
>  * 2. Redistributions in binary form must reproduce at minimum a disclaimer
>  *    substantially similar to the "NO WARRANTY" disclaimer below
>  *    ("Disclaimer") and any redistribution must be conditioned upon
>  *    including a substantially similar Disclaimer requirement for further
>  *    binary redistribution.
>  * 3. Neither the names of the above-listed copyright holders nor the names
>  *    of any contributors may be used to endorse or promote products derived
>  *    from this software without specific prior written permission.
>
> I don't see anything there about retaining the ability to choose an
> alternative license. The paragraph in question says that people can
> *choose* to distribute it under the GPLv2, not that it *is* being
> distributed under the GPLv2.

Conversely, I don't see anything there explicitly *allowing* somebody
to remove that paragraph so I'd keep it unless I had express clearance
from Intel. Making assumptions can be dangerous, especially when
dealing with large corporations. That's the main lesson I've learned
after several years dealing with such matters.

I don't want to make this discussion longer than necessary, so I stop here.

--
My preferred quotation of Robert Louis Stevenson is "You cannot
make an omelette without breaking eggs". Not because I like the
omelettes, but because I like the sound of eggs being broken.
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Gavin Atkinson-4]

On Wed, 14 Oct 2009, Andriy Gapon wrote:
> Some time ago I posted some ideas about HECI/MEI driver for FreeBSD:
> http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006
>
> I actually got around to implementing it (in initial/basic form):
> http://people.freebsd.org/~avg/heci.tgz

Nice!

I've got the following device in my laptop:

heci0@pci0:0:3:0:       class=0x078000 card=0x00011179 chip=0x2a448086 rev=0x07 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = 'Intel Management Engine Interface (Mobile 4 Series Chipset)'
     class      = simple comms

I've added this device to the code, and loaded it:

heci0: <Intel ICH9 (Cantiga) Express HECI/MEI Controller> mem 0xff9ffff0-0xff9fffff irq 16 at device 3.0 on pci0
heci0: using MSI
heci0: [ITHREAD]
heci0: found ME client at address 0x02:
heci0: status = 0x00
heci0: protocol_name(guid) = BB875E12-CB58-4D14-AE93-8566183C66C7
heci0: found ME client at address 0x06:
heci0: status = 0x00
heci0: protocol_name(guid) = 9B27FD6D-EF72-4967-BCC2-471A32679620
heci0: found ME client at address 0x07:
heci0: status = 0x00
heci0: protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB
heci0: found ME client at address 0x20:
heci0: status = 0x00
heci0: protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327
heci0: found ME client at address 0x21:
heci0: status = 0x00
heci0: protocol_name(guid) = 23F27E9B-9D26-4FCE-9227-DE06446E5B06
heci0: found ME client at address 0x22:
heci0: status = 0x00
heci0: protocol_name(guid) = 6733A4DB-0476-4E7B-B3AF-BCFC29BEE7A7
heci0: found ME client at address 0x23:
heci0: status = 0x00
heci0: protocol_name(guid) = 12F80028-B4B7-4B2D-ACA8-46E0FF65814C
heci0: found ME client at address 0x24:
heci0: status = 0x00
heci0: protocol_name(guid) = 05B79A6F-4628-4D7F-899D-A91514CB32AB

However, running the heci-qst.c program you supplied:

psi# ./heci-qst
ioctl HECI_CONNECT: No such file or directory

And output to the console:

heci0: could not find ME client with given guid: 6B5205B9-8185-4519-B889-D98724B58607

Other than seeing that it doesn't appear in the list above, I don't know
if this is expected or not...

Secondly, I get a panic on module unlaod.  I haven't spent any time
looking at this, if you haven't fixed it yet let me know and I'll look
into it further.
I'm not even sure how it's getting that far into the detach routine before
panicing, if dev really does = 0xdeadc0dedeadc0de

#8  0xffffffff808580d3 in calltrap ()
     at /usr/src/sys/amd64/amd64/exception.S:224
#9  0xffffffff8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e)
     at /usr/src/sys/kern/kern_mutex.c:827
#10 0xffffffff812221c6 in heci_detach ()
    from /usr/src/sys/modules/heci/heci.ko
#11 0xffffffff805b44d4 in device_detach (dev=0xdeadc0dedeadc0de)
     at device_if.h:212
#12 0xffffffff805b4ac0 in driver_module_handler (mod=0xffffff0002d0f800,
what=Variable "what" is not available.
) at /usr/src/sys/kern/subr_bus.c:1156
#13 0xffffffff80578fc5 in module_unload (mod=0xffffff0002d0f800)
     at /usr/src/sys/kern/kern_module.c:266
#14 0xffffffff8056fc0b in linker_file_unload (file=0xffffff0002c9c200,
     flags=0) at /usr/src/sys/kern/kern_linker.c:633
#15 0xffffffff805707c3 in kern_kldunload (td=0xffffff0002950380,
fileid=Variable "fileid" is not available.
)    at /usr/src/sys/kern/kern_linker.c:1092

Let me know if there's anything else I can test.

Thanks,

Gavin
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Andriy Gapon]

on 09/11/2009 22:34 Gavin Atkinson said the following:

> On Wed, 14 Oct 2009, Andriy Gapon wrote:
>> Some time ago I posted some ideas about HECI/MEI driver for FreeBSD:
>> http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006
>>
>> I actually got around to implementing it (in initial/basic form):
>> http://people.freebsd.org/~avg/heci.tgz
>
> Nice!
>
> I've got the following device in my laptop:
>
> heci0@pci0:0:3:0:       class=0x078000 card=0x00011179 chip=0x2a448086
> rev=0x07 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = 'Intel Management Engine Interface (Mobile 4 Series
> Chipset)'
>     class      = simple comms
>
> I've added this device to the code, and loaded it:
>
> heci0: <Intel ICH9 (Cantiga) Express HECI/MEI Controller> mem
> 0xff9ffff0-0xff9fffff irq 16 at device 3.0 on pci0

I will add this ID and name to the driver.

> heci0: using MSI
> heci0: [ITHREAD]
> heci0: found ME client at address 0x02:
> heci0:     status = 0x00
> heci0:     protocol_name(guid) = BB875E12-CB58-4D14-AE93-8566183C66C7
> heci0: found ME client at address 0x06:
> heci0:     status = 0x00
> heci0:     protocol_name(guid) = 9B27FD6D-EF72-4967-BCC2-471A32679620
> heci0: found ME client at address 0x07:
> heci0:     status = 0x00
> heci0:     protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB
> heci0: found ME client at address 0x20:
> heci0:     status = 0x00
> heci0:     protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327
> heci0: found ME client at address 0x21:
> heci0:     status = 0x00
> heci0:     protocol_name(guid) = 23F27E9B-9D26-4FCE-9227-DE06446E5B06
> heci0: found ME client at address 0x22:
> heci0:     status = 0x00
> heci0:     protocol_name(guid) = 6733A4DB-0476-4E7B-B3AF-BCFC29BEE7A7
> heci0: found ME client at address 0x23:
> heci0:     status = 0x00
> heci0:     protocol_name(guid) = 12F80028-B4B7-4B2D-ACA8-46E0FF65814C
> heci0: found ME client at address 0x24:
> heci0:     status = 0x00
> heci0:     protocol_name(guid) = 05B79A6F-4628-4D7F-899D-A91514CB32AB

Thanks a lot for testing!

> However, running the heci-qst.c program you supplied:
>
> psi# ./heci-qst
> ioctl HECI_CONNECT: No such file or directory
>
> And output to the console:
>
> heci0: could not find ME client with given guid:
> 6B5205B9-8185-4519-B889-D98724B58607
>
> Other than seeing that it doesn't appear in the list above, I don't know
> if this is expected or not...

Yes, this is expected if you don't have ME client with this GUID.
Perhaps, there is no QST firmware in the ME or it is disabled.  Also, I am not
sure but I think that it could be possible that you have a newer version of QST
and its GUID is different.  If you feel adventurous, you could try substituting
GUID value in heci-qst.c with values reported by the driver.  Perhaps it would
work, perhaps you'd get a crash or hang or just an ioctl error.

> Secondly, I get a panic on module unlaod.  I haven't spent any time
> looking at this, if you haven't fixed it yet let me know and I'll look
> into it further.

To my shame I still haven't got around to testing the driver with head tree and
diagnostics enabled.  I do not see any problems on stable/7 without diagnostics.
Robert Noland has reported that he had a lockup on module unload with head
sources.  I will investigate this.
BTW, 0xdeadc0dedeadc0de as arg to device_detach() looks really strange (if
debugger reports it correctly).  This looks like the memory was already freed.

> I'm not even sure how it's getting that far into the detach routine
> before panicing, if dev really does = 0xdeadc0dedeadc0de
>
> #8  0xffffffff808580d3 in calltrap ()
>     at /usr/src/sys/amd64/amd64/exception.S:224
> #9  0xffffffff8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e)
>     at /usr/src/sys/kern/kern_mutex.c:827
> #10 0xffffffff812221c6 in heci_detach ()
>    from /usr/src/sys/modules/heci/heci.ko
> #11 0xffffffff805b44d4 in device_detach (dev=0xdeadc0dedeadc0de)
>     at device_if.h:212
> #12 0xffffffff805b4ac0 in driver_module_handler (mod=0xffffff0002d0f800,
> what=Variable "what" is not available.
> ) at /usr/src/sys/kern/subr_bus.c:1156
> #13 0xffffffff80578fc5 in module_unload (mod=0xffffff0002d0f800)
>     at /usr/src/sys/kern/kern_module.c:266
> #14 0xffffffff8056fc0b in linker_file_unload (file=0xffffff0002c9c200,
>     flags=0) at /usr/src/sys/kern/kern_linker.c:633
> #15 0xffffffff805707c3 in kern_kldunload (td=0xffffff0002950380,
> fileid=Variable "fileid" is not available.
> )    at /usr/src/sys/kern/kern_linker.c:1092
>
> Let me know if there's anything else I can test.
>
> Thanks,

Nothing else I can think of right now.
Thanks again!

--
Andriy Gapon
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Andriy Gapon]

on 10/11/2009 13:54 Andriy Gapon said the following:

> on 09/11/2009 22:34 Gavin Atkinson said the following:
>> Secondly, I get a panic on module unlaod.  I haven't spent any time
>> looking at this, if you haven't fixed it yet let me know and I'll look
>> into it further.
>
> To my shame I still haven't got around to testing the driver with head tree and
> diagnostics enabled.  I do not see any problems on stable/7 without diagnostics.
> Robert Noland has reported that he had a lockup on module unload with head
> sources.  I will investigate this.
> BTW, 0xdeadc0dedeadc0de as arg to device_detach() looks really strange (if
> debugger reports it correctly).  This looks like the memory was already freed.

I think I've found one bug in the heci code that could cause this - SLIST element
was first freed and then removed from the list.
I've uploaded updated sources (that should include your PCI ID too), could you
please re-test?

>> I'm not even sure how it's getting that far into the detach routine
>> before panicing, if dev really does = 0xdeadc0dedeadc0de
>>
>> #8  0xffffffff808580d3 in calltrap ()
>>     at /usr/src/sys/amd64/amd64/exception.S:224
>> #9  0xffffffff8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e)
>>     at /usr/src/sys/kern/kern_mutex.c:827
>> #10 0xffffffff812221c6 in heci_detach ()
>>    from /usr/src/sys/modules/heci/heci.ko
>> #11 0xffffffff805b44d4 in device_detach (dev=0xdeadc0dedeadc0de)
>>     at device_if.h:212
>> #12 0xffffffff805b4ac0 in driver_module_handler (mod=0xffffff0002d0f800,
>> what=Variable "what" is not available.
>> ) at /usr/src/sys/kern/subr_bus.c:1156
>> #13 0xffffffff80578fc5 in module_unload (mod=0xffffff0002d0f800)
>>     at /usr/src/sys/kern/kern_module.c:266
>> #14 0xffffffff8056fc0b in linker_file_unload (file=0xffffff0002c9c200,
>>     flags=0) at /usr/src/sys/kern/kern_linker.c:633
>> #15 0xffffffff805707c3 in kern_kldunload (td=0xffffff0002950380,
>> fileid=Variable "fileid" is not available.
>> )    at /usr/src/sys/kern/kern_linker.c:1092
>>
>> Let me know if there's anything else I can test.
>>
>> Thanks,
>
> Nothing else I can think of right now.

OK, I came up with something :)
Could you please send me verbose version of driver attachment messages
(debug.bootverbose=1)?
Thank you!

BTW, Robert, you also promised me those :)

--
Andriy Gapon
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Gavin Atkinson-4]

On Tue, 10 Nov 2009, Andriy Gapon wrote:

> on 10/11/2009 13:54 Andriy Gapon said the following:
>> on 09/11/2009 22:34 Gavin Atkinson said the following:
>>> Secondly, I get a panic on module unlaod.  I haven't spent any time
>>> looking at this, if you haven't fixed it yet let me know and I'll look
>>> into it further.
>>
>> To my shame I still haven't got around to testing the driver with head tree and
>> diagnostics enabled.  I do not see any problems on stable/7 without diagnostics.
>> Robert Noland has reported that he had a lockup on module unload with head
>> sources.  I will investigate this.
>> BTW, 0xdeadc0dedeadc0de as arg to device_detach() looks really strange (if
>> debugger reports it correctly).  This looks like the memory was already freed.
>
> I think I've found one bug in the heci code that could cause this - SLIST element
> was first freed and then removed from the list.
> I've uploaded updated sources (that should include your PCI ID too), could you
> please re-test?

That seems to have fixed it, thanks!  It also fixes the malloc() calls
with locks held.

> Could you please send me verbose version of driver attachment messages
> (debug.bootverbose=1)?
> Thank you!

Sure!

http://people.freebsd.org/~gavin/heci-verbose.txt

Gavin
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Andriy Gapon]

on 10/11/2009 20:42 Gavin Atkinson said the following:

> On Tue, 10 Nov 2009, Andriy Gapon wrote:
>> on 10/11/2009 13:54 Andriy Gapon said the following:
>>> on 09/11/2009 22:34 Gavin Atkinson said the following:
>> I think I've found one bug in the heci code that could cause this -
>> SLIST element
>> was first freed and then removed from the list.
>> I've uploaded updated sources (that should include your PCI ID too),
>> could you
>> please re-test?
>
> That seems to have fixed it, thanks!  It also fixes the malloc() calls
> with locks held.
>
>> Could you please send me verbose version of driver attachment messages
>> (debug.bootverbose=1)?
>> Thank you!
>
> Sure!
>
> http://people.freebsd.org/~gavin/heci-verbose.txt

Thank you for the testing and data!

--
Andriy Gapon
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."