From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 9 21:05:19 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 A939D106566B; Mon, 9 Nov 2009 21:05:19 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id 5836B8FC08; Mon, 9 Nov 2009 21:05:18 +0000 (UTC) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id nA9KYBiL016294; Mon, 9 Nov 2009 20:34:11 GMT Received: from ury.york.ac.uk ([144.32.108.81]) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1N7awF-0007OB-NH; Mon, 09 Nov 2009 20:34:11 +0000 Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.14.3/8.14.3) with ESMTP id nA9KYBkC071706; Mon, 9 Nov 2009 20:34:11 GMT (envelope-from gavin@FreeBSD.org) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id nA9KYAxG071694; Mon, 9 Nov 2009 20:34:10 GMT (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Mon, 9 Nov 2009 20:34:09 +0000 (GMT) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Andriy Gapon In-Reply-To: <4AD6067E.2010503@icyb.net.ua> Message-ID: <20091109195045.Q13027@ury.york.ac.uk> References: <4AD6067E.2010503@icyb.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org 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: Mon, 09 Nov 2009 21:05:19 -0000 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 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