Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Nov 2009 13:54:09 +0200
From:      Andriy Gapon <avg@icyb.net.ua>
To:        Gavin Atkinson <gavin@FreeBSD.org>
Cc:        freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org
Subject:   Re: heci: a new driver for review and testing
Message-ID:  <4AF95461.2030700@icyb.net.ua>
In-Reply-To: <20091109195045.Q13027@ury.york.ac.uk>
References:  <4AD6067E.2010503@icyb.net.ua> <20091109195045.Q13027@ury.york.ac.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4AF95461.2030700>