From owner-freebsd-drivers@FreeBSD.ORG Fri Jan 20 16:24:28 2006 Return-Path: X-Original-To: freebsd-drivers@freebsd.org Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0B2616A420 for ; Fri, 20 Jan 2006 16:24:28 +0000 (GMT) (envelope-from kimblydavis@yahoo.com) Received: from web30006.mail.mud.yahoo.com (web30006.mail.mud.yahoo.com [68.142.200.69]) by mx1.FreeBSD.org (Postfix) with SMTP id 128EB43D49 for ; Fri, 20 Jan 2006 16:24:27 +0000 (GMT) (envelope-from kimblydavis@yahoo.com) Received: (qmail 62051 invoked by uid 60001); 20 Jan 2006 16:24:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=L+orgTFCMkXFpc5b08j6r9pUtIRA84ykSR1ltf3AxF7mMP3tPGEEQRV4EjxT5rpuZGbPP4XBEokK2cCy6xlierJacTcR+e0qnUAkjh5ETq2dsQv6CEW512t3e7ecfTi7UudHeDanWSH17rLT53NsSNQ4sYoyNyowEb/4/IEyW7I= ; Message-ID: <20060120162427.62049.qmail@web30006.mail.mud.yahoo.com> Date: Fri, 20 Jan 2006 08:24:27 -0800 (PST) From: Kimberly Davis To: Norbert Koch , John Baldwin , freebsd-drivers@freebsd.org In-Reply-To: <000101c61d92$9ca927c0$4801a8c0@ws-ew-3.demig.intra> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: Interrupt Handlers and Driver to Driver Communication X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kimberly Davis List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2006 16:24:28 -0000 Yes, tried all that... nm driver1.ko | grep driver_one_is_complete 00003274 T driver_one_is_complete nm driver2.ko | grep driver_one_is_complete U driver_one_is_complete Undefined makes sense because it's not defined in the driver2 code. It's merely being called. A more interesting development occurred yesterday when a colleague suggested that I write post codes to the LED on the board at different times in the driver so that we could tell how long it was lingering over certain executions and see where the driver was in its execution of the interrupt handler. What I found during that exercise was that the driver interrupt handler gets stuck, unable to complete the interrupt handler call until driver2's call of the function driver_one_is_complete has finished executing. In other words, driver2's activities are preventing driver1's activities from finishing. This explains the erronenous value that I keep getting with driver_one_is_complete. I don't understand this at all. Have you ever encountered this problem? KD ----- Original Message ---- From: Norbert Koch To: Kimberly Davis ; John Baldwin ; freebsd-drivers@freebsd.org Sent: Friday, January 20, 2006 12:24:55 AM Subject: RE: Interrupt Handlers and Driver to Driver Communication > The results of that test are as follows > > >nm driver1.ko | grep g_status > 00004239 B g_status > > It doesn't make sense to do that for the client_driver (driver2) > since the variable isn't defined there or even externed there. I > use the API from driver1 (driver_one_is_complete) to find out the > value of g_status. So, what about 'nm driver[12].ko | grep driver_one_is_complete' ? Does driver_one_is_complete() do a test-and-reset operation on g_status? Did you have a look at the assembly output of this function? What are your compiler (optimization) settings?