From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 10 11:54:13 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A91A106566B; Tue, 10 Nov 2009 11:54:13 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9443A8FC22; Tue, 10 Nov 2009 11:54:11 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA11835; Tue, 10 Nov 2009 13:54:09 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4AF95461.2030700@icyb.net.ua> Date: Tue, 10 Nov 2009 13:54:09 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Gavin Atkinson References: <4AD6067E.2010503@icyb.net.ua> <20091109195045.Q13027@ury.york.ac.uk> In-Reply-To: <20091109195045.Q13027@ury.york.ac.uk> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: heci: a new driver for review and testing X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 11:54:13 -0000 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: 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