Re: heci: a new driver for review and testing
on 27/01/2011 07:43 Lawrence Stewart said the following: > Hi Andriy, > > On 10/15/09 04:12, 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 > > An old thread I know, but I just noticed my desktop has AMT support and > was investigating if I could get access to the Serial Over Lan feature. > I stumbled across your HECI driver and thought I'd give it a spin. It > loads and attaches fine and unloads without issue as well. I tested with > device "HECI_DEV_ID_ICH9_82Q35" on a HP DC7800 minitower machine. I get > no output when I run your "heci-qst" program though. > > Few more details: > > heci0@pci0:0:3:0: class=0x078000 card=0x2819103c chip=0x29b48086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel(R) Management Engine Interface (HECI) (Q35-Chipset)' > class = simple comms > > lstewart@lstewart> uname -a > FreeBSD lstewart 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0 r217387M: Fri > Jan 14 15:52:16 EST 2011 > lstewart@lstewart:/usr/obj/usr/src/sys/DESKTOP amd64 It's quite possible that your AMT firmware doesn't have a QST module. Upon loading of heci driver it prints a list of discovered module guids. QST guid is 6B5205B9-8185-4519-B889-D98724B58607. But I have mostly gave up on development of this driver (although I keep using it). I think that it's better to port either OpenSolaris or Linux heci driver to FreeBSD. BTW, Intel has released QST SDK source code: http://software.intel.com/en-us/articles/Intel_Quiet_System_Technology_Software_Development_Kit/ -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: heci: a new driver for review and testing
Hi Andriy, On 10/15/09 04:12, 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 An old thread I know, but I just noticed my desktop has AMT support and was investigating if I could get access to the Serial Over Lan feature. I stumbled across your HECI driver and thought I'd give it a spin. It loads and attaches fine and unloads without issue as well. I tested with device "HECI_DEV_ID_ICH9_82Q35" on a HP DC7800 minitower machine. I get no output when I run your "heci-qst" program though. Few more details: heci0@pci0:0:3:0: class=0x078000 card=0x2819103c chip=0x29b48086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel(R) Management Engine Interface (HECI) (Q35-Chipset)' class = simple comms lstewart@lstewart> uname -a FreeBSD lstewart 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0 r217387M: Fri Jan 14 15:52:16 EST 2011 lstewart@lstewart:/usr/obj/usr/src/sys/DESKTOP amd64 Cheers, Lawrence ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: heci: a new driver for review and testing
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: heci: a new driver for review and testing
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: heci: a new driver for review and testing
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 0x808580d3 in calltrap () >> at /usr/src/sys/amd64/amd64/exception.S:224 >> #9 0x8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e) >> at /usr/src/sys/kern/kern_mutex.c:827 >> #10 0x812221c6 in heci_detach () >>from /usr/src/sys/modules/heci/heci.ko >> #11 0x805b44d4 in device_detach (dev=0xdeadc0dedeadc0de) >> at device_if.h:212 >> #12 0x805b4ac0 in driver_module_handler (mod=0xff0002d0f800, >> what=Variable "what" is not available. >> ) at /usr/src/sys/kern/subr_bus.c:1156 >> #13 0x80578fc5 in module_unload (mod=0xff0002d0f800) >> at /usr/src/sys/kern/kern_module.c:266 >> #14 0x8056fc0b in linker_file_unload (file=0xff0002c9c200, >> flags=0) at /usr/src/sys/kern/kern_linker.c:633 >> #15 0x805707c3 in kern_kldunload (td=0xff0002950380, >> 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: heci: a new driver for review and testing
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: > > he...@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: mem > 0xff90-0xff9f 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 0x808580d3 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:224 > #9 0x8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e) > at /usr/src/sys/kern/kern_mutex.c:827 > #10 0x812221c6 in heci_detach () >from /usr/src/sys/modules/heci/heci.ko > #11 0x805b44d4 in device_detach (dev=0xdeadc0dedeadc0de) > at device_if.h:212 > #12 0x805b4ac0 in driver_module_handler (mod=0xff0002d0f800, > what=Variable "what" is not available. > ) at /usr/src/sys/kern/subr_bus.c:1156 > #13 0x80578fc5 in module_unload (mod=0xff0002d0f800) > at /usr/src/sys/kern/kern_module.c:266 > #14 0x8056fc0b in linker_file_unload (file=0xff0002c9c200, > flags=0) at /usr/src/sys/kern/kern_linker.c:633 > #15 0x805707c3 in kern_kldunload (td=0xff0002950380, > 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: heci: a new driver for review and testing
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: he...@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: mem 0xff90-0xff9f 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 0x808580d3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #9 0x8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e) at /usr/src/sys/kern/kern_mutex.c:827 #10 0x812221c6 in heci_detach () from /usr/src/sys/modules/heci/heci.ko #11 0x805b44d4 in device_detach (dev=0xdeadc0dedeadc0de) at device_if.h:212 #12 0x805b4ac0 in driver_module_handler (mod=0xff0002d0f800, what=Variable "what" is not available. ) at /usr/src/sys/kern/subr_bus.c:1156 #13 0x80578fc5 in module_unload (mod=0xff0002d0f800) at /usr/src/sys/kern/kern_module.c:266 #14 0x8056fc0b in linker_file_unload (file=0xff0002c9c200, flags=0) at /usr/src/sys/kern/kern_linker.c:633 #15 0x805707c3 in kern_kldunload (td=0xff0002950380, 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: heci: a new driver for review and testing
On Wed, Oct 14, 2009 at 9:34 PM, Mike Meyer wrote:
> On Wed, 14 Oct 2009 19:46:20 -0300
> "Carlos A. M. dos Santos" wrote:
>
>> On Wed, Oct 14, 2009 at 2:12 PM, Andriy Gapon 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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: heci: a new driver for review and testing
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: 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 FreeBSD ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: heci: a new driver for review and testing
Andriy Gapon 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 - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: heci: a new driver for review and testing
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: heci: a new driver for review and testing
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: heci: a new driver for review and testing
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: > no...@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: 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 No
Re: heci: a new driver for review and testing
On Wed, Oct 14, 2009 at 2:12 PM, Andriy Gapon 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: heci: a new driver for review and testing
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: > no...@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: 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 con
heci: a new driver for review and testing
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: no...@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: 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
