From owner-freebsd-drivers@FreeBSD.ORG Sun Jan 15 04:14:52 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 98F9716A420 for ; Sun, 15 Jan 2006 04:14:52 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F74D43D49 for ; Sun, 15 Jan 2006 04:14:52 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id k0F4DCTA064421; Sat, 14 Jan 2006 21:13:16 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 14 Jan 2006 21:13:12 -0700 (MST) Message-Id: <20060114.211312.74693697.imp@bsdimp.com> To: sds@jazzie.com From: Warner Losh In-Reply-To: <43C98205.70002@jazzie.com> References: <43C98205.70002@jazzie.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 14 Jan 2006 21:13:17 -0700 (MST) Cc: freebsd-drivers@freebsd.org Subject: Re: if_ed_isa.c change to support pnp on compaq lte dock X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2006 04:14:52 -0000 > This is regarding 5.4-RELEASE-p9 running on a Compaq LTE (Pentium-based) > laptop connected to a docking station. A patch for if_ed_isa.c is > included below. The Compaq LTE docking station includes an > ne2000-compatible ethernet interface, and using device.hints that match > the port and irq configured in the bios works just fine when booting > from a powered-off state. OK. > The system has a plug-n-play bios that knows about this device: > PNP8160: adding irq mask 0x800 > PNP8160: adding io range 0x340-0x35f, size=0x20, align=0x20 > pnpbios: handle 21 device ID PNP8160 (6081d041) > But the ed driver in 5.4-RELEASE doesn't attach to it automatically. > I made the obvious change, adding the device id to the table: > > *** if_ed_isa.c 2006/01/13 19:23:23 1.1 > --- if_ed_isa.c 2006/01/13 19:25:18 > *************** > *** 59,64 **** > --- 59,65 ---- > { 0x0090252a, NULL }, /* JQE9000 */ > { 0x0020832e, NULL }, /* KTC2000 */ > { 0x4cf48906, NULL }, /* ATIf44c */ > + { 0x6081d041, NULL }, /* PNP8160 */ > { 0, NULL } > }; > > After removing the device.hints, the system now reports: > ed0: at port 0x340-0x35f irq 11 on isa0 > both on cold boots and warm restarts, and does not hang. Hurray! > > Was there a better way to accomplish this? If no, can the change to add > this device id get incorporated into future FreeBSD releases? Committed. This is the best way to add an ID. Warner From owner-freebsd-drivers@FreeBSD.ORG Wed Jan 18 18:21:31 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 42BE216A422 for ; Wed, 18 Jan 2006 18:21:31 +0000 (GMT) (envelope-from kimblydavis@yahoo.com) Received: from web30005.mail.mud.yahoo.com (web30005.mail.mud.yahoo.com [68.142.200.68]) by mx1.FreeBSD.org (Postfix) with SMTP id C858143D46 for ; Wed, 18 Jan 2006 18:21:30 +0000 (GMT) (envelope-from kimblydavis@yahoo.com) Received: (qmail 20357 invoked by uid 60001); 18 Jan 2006 18:21:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=N+IbVYDh02RN/k4ERs/pbzaRzdAKShbUWTc1TLsOD1Redo36TzoXpGKTHnFqGN4akjU1FCKNUBtblv8z4YYlJBETd2OoWlHmKPY2PhyL0xZajqyemT/w+sLIjopsnNHVoCRiinPxNIj97HIt7pEvML1t9F3wyPxgv6pP58NJAY0= ; Message-ID: <20060118182130.20355.qmail@web30005.mail.mud.yahoo.com> Date: Wed, 18 Jan 2006 10:21:30 -0800 (PST) From: Kimberly Davis To: freebsd-drivers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 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: Wed, 18 Jan 2006 18:21:31 -0000 I am having a very serious problem with a driver that I am writing. Specifically, my problem is related to driver to driver communication. I've tried to abstract the problem in my description below. I have a driver (let's call it Driver 1) in which I register the interrupt handler in this way: tsc->irqid = 0x0; tsc->irq_res = bus_alloc_resource(dev, SYS_RES_IRQ,&(tsc->irqid), 0, ~0, 1, RF_SHAREABLE | RF_ACTIVE); if(tsc->irq_res == NULL) print_osal("Failed to allocate irq resource\n"); else { error = bus_setup_intr(dev, tsc->irq_res, INTR_TYPE_MISC , driver_one_interrupt_handler, tsc, &(tsc->handler)); } My interrupt handler function is actually quite long, but there is nothing to be done about it. There is no really good way to make it shorter. Anyway, in Driver 2, I call a function (part of an API that I provide in driver 1) and it returns a value: status = driver_one_is_operation_complete(param, param); The driver_one_is_operation_complete function actually returns to Driver 2 a status variable that is set in the interrupt handler of driver 1. //global for status of an event. int g_status; void driver_one_interrupt_handler(void * arg) { g_status = 0; if(CERTAIN_CONDITION_OCCURRED) g_status = 1; } The problem is that I never, ever get the value from the function driver_one_is_operation_complete that I would expect. The value returned is always 0 and never 1. However, when I check this value in driver one's detach function, right before the end of execution, the value is 1. driver_one_detach() { print("g_status %x\n",g_status) blah, blah, blah } Clearly, the interrupt handler has executed and the value has been set to one. In driver two, I've tried waiting 2 or 3 seconds (with the system's delay function) before calling driver_one_is_operation_complete, but this doesn't help either. Is there something weird going on in the Driver to Driver communication? Thanks in advance for any help or clues you may be able to provide, KD From owner-freebsd-drivers@FreeBSD.ORG Thu Jan 19 12:48:03 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 1D5D816A41F for ; Thu, 19 Jan 2006 12:48:03 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 922B043D53 for ; Thu, 19 Jan 2006 12:48:01 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id 14F53BD073; Thu, 19 Jan 2006 13:47:56 +0100 (CET) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13002-07; Thu, 19 Jan 2006 13:47:52 +0100 (CET) Received: from firewall.demig (p508391F0.dip0.t-ipconnect.de [80.131.145.240]) by server.absolute-media.de (Postfix) with ESMTP id F08F4BD041; Thu, 19 Jan 2006 13:47:51 +0100 (CET) Received: from ws-ew-3 (ws-ew-3.demig.intra [192.168.1.72]) by firewall.demig (8.13.5/8.13.4) with SMTP id k0JCjoeq001991; Thu, 19 Jan 2006 13:45:50 +0100 (CET) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: "Kimberly Davis" , Date: Thu, 19 Jan 2006 13:45:51 +0100 Message-ID: <000001c61cf6$478ea0e0$4801a8c0@ws-ew-3.demig.intra> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <20060118182130.20355.qmail@web30005.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Cc: Subject: RE: Interrupt Handlers and Driver to Driver Communication X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2006 12:48:03 -0000 >From which context/function in your driver 2 do you check g_status? Does your debug output show, that this context really becomes active? Are your drivers in the same or different source files? Or are they being loaded as different klds? Have you tried if it makes any difference to declare g_status as volatile? Any interesting compiler warnings? (Just for not forgetting to ask: You didn't by accident declare g_status twice, once at global and once static at function scope?) > -----Original Message----- > From: owner-freebsd-drivers@freebsd.org > [mailto:owner-freebsd-drivers@freebsd.org]On Behalf Of Kimberly Davis > Sent: Wednesday, January 18, 2006 7:22 PM > To: freebsd-drivers@freebsd.org > Subject: Interrupt Handlers and Driver to Driver Communication > > > I am having a very serious problem with a driver that I am > writing. Specifically, my problem is related to driver to driver > communication. I've tried to abstract the problem in my description below. > > I have a driver (let's call it Driver 1) in which I register the > interrupt handler in this way: > > tsc->irqid = 0x0; > tsc->irq_res = bus_alloc_resource(dev, SYS_RES_IRQ,&(tsc->irqid), 0, ~0, > 1, RF_SHAREABLE | RF_ACTIVE); > if(tsc->irq_res == NULL) > print_osal("Failed to allocate irq resource\n"); > else > { > error = bus_setup_intr(dev, tsc->irq_res, INTR_TYPE_MISC , > driver_one_interrupt_handler, tsc, &(tsc->handler)); > } > > My interrupt handler function is actually quite long, but there > is nothing to be done about it. There is no really good way to > make it shorter. Anyway, in Driver 2, I call a function (part of > an API that I provide in driver 1) and it returns a value: > > status = driver_one_is_operation_complete(param, param); > > The driver_one_is_operation_complete function actually returns to > Driver 2 a status variable that is set in the interrupt handler > of driver 1. > > //global for status of an event. > int g_status; > void driver_one_interrupt_handler(void * arg) > { > g_status = 0; > > if(CERTAIN_CONDITION_OCCURRED) > g_status = 1; > } > > The problem is that I never, ever get the value from the > function driver_one_is_operation_complete that I would expect. > The value returned is always 0 and never 1. However, when I check > this value in driver one's detach function, right before the end > of execution, the value is 1. > > driver_one_detach() > { > > print("g_status %x\n",g_status) > blah, blah, blah > } > > Clearly, the interrupt handler has executed and the value has > been set to one. > > In driver two, I've tried waiting 2 or 3 seconds (with the > system's delay function) before calling > driver_one_is_operation_complete, but this doesn't help either. > Is there something weird going on in the Driver to Driver communication? > > Thanks in advance for any help or clues you may be able to provide, > KD > _______________________________________________ > freebsd-drivers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-drivers > To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org" > From owner-freebsd-drivers@FreeBSD.ORG Thu Jan 19 15:57:06 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 D464D16A434 for ; Thu, 19 Jan 2006 15:57:06 +0000 (GMT) (envelope-from kimblydavis@yahoo.com) Received: from web30004.mail.mud.yahoo.com (web30004.mail.mud.yahoo.com [68.142.200.67]) by mx1.FreeBSD.org (Postfix) with SMTP id 7012243D46 for ; Thu, 19 Jan 2006 15:57:06 +0000 (GMT) (envelope-from kimblydavis@yahoo.com) Received: (qmail 13715 invoked by uid 60001); 19 Jan 2006 15:57:05 -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=QYYPQXYgtuSYuBtLLpD3i2e7slnH+7n0blbVMiXQrgX8RS9TJfRuhRnMOAYFcNoDmy6n9iWk2dAMkc6N0ngWDlbF5DPltMZIWv6l3mB6Eg4YDjSxy0AO8jeFORnfLueJRhzr2yqk/KLKAiJmc0UKC7NqfrFJ4i73Xmi9rbMbLQ8= ; Message-ID: <20060119155705.13713.qmail@web30004.mail.mud.yahoo.com> Date: Thu, 19 Jan 2006 07:57:05 -0800 (PST) From: Kimberly Davis To: Norbert Koch , freebsd-drivers@freebsd.org In-Reply-To: <000001c61cf6$478ea0e0$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: Thu, 19 Jan 2006 15:57:07 -0000 Norbert, thanks for responding. I provide answers to your questions and a little more information below. In driver 2, I call the function driver_one_is_operation_complete, which is part of an API provided by driver 1. Yes, I have reason to believe that the context becomes active. In other words, I believe that the condition CERTAIN_CONDITION_OCCURRED does in fact become true at some point. Driver 1 is a dma driver, and I can actually see that the driver completes a transaction, which triggers an interrupt. When I check the status variable from within driver1 the status does equal 1, letting me know that the condition occurred. if(CERTAIN_CONDITION_OCCURRED) g_status = 1; My drivers are definitely in different source files, and they are being loaded with different invokations of kldload. For example: >kldload driver1.o >kldload driver2.o >kldunload driver2 >kldunload driver1 Driver2 is dependent on driver1. I use the MODULE_DEPEND macro to ensure this dependency. Driver1 is actually composed of two .c files. Here is the layout for driver1: dma.c: uint32_t g_status dma_client_api.c: extern uint32_t g_status The code for driver_one_is_operation_complete is in this file and there is a dma_api.h file which contains the function protype. Here is the file layout for driver2: client_driver.c In driver2's attach function, I call driver_one_is_operation_complete. I have tried a volatile delcaration, and it doesn't work. I have checked, checked, and re-checked to make certain that I haven't declared the status variable twice accidentally. Also, I should say that I have a uniprocessor system, and the processor is not multi-core, so none of the typical questions about hyper-threading, SMP syncing issues, or multi-core difficulties seem particularly relevant, although I won't rule some sort of phantom issue out. I am using FreeBSD 6.0. I've also tried making this variable a part of the softc structure. That does not help either. Obviously I am having some sort of module communication problem, but what? I can't seem to nail it down. Thanks, KD ----- Original Message ---- From: Norbert Koch To: Kimberly Davis ; freebsd-drivers@freebsd.org Sent: Thursday, January 19, 2006 5:45:51 AM Subject: RE: Interrupt Handlers and Driver to Driver Communication >From which context/function in your driver 2 do you check g_status? Does your debug output show, that this context really becomes active? Are your drivers in the same or different source files? Or are they being loaded as different klds? Have you tried if it makes any difference to declare g_status as volatile? Any interesting compiler warnings? (Just for not forgetting to ask: You didn't by accident declare g_status twice, once at global and once static at function scope?) > -----Original Message----- > From: owner-freebsd-drivers@freebsd.org > [mailto:owner-freebsd-drivers@freebsd.org]On Behalf Of Kimberly Davis > Sent: Wednesday, January 18, 2006 7:22 PM > To: freebsd-drivers@freebsd.org > Subject: Interrupt Handlers and Driver to Driver Communication > > > I am having a very serious problem with a driver that I am > writing. Specifically, my problem is related to driver to driver > communication. I've tried to abstract the problem in my description below. > > I have a driver (let's call it Driver 1) in which I register the > interrupt handler in this way: > > tsc->irqid = 0x0; > tsc->irq_res = bus_alloc_resource(dev, SYS_RES_IRQ,&(tsc->irqid), 0, ~0, > 1, RF_SHAREABLE | RF_ACTIVE); > if(tsc->irq_res == NULL) > print_osal("Failed to allocate irq resource\n"); > else > { > error = bus_setup_intr(dev, tsc->irq_res, INTR_TYPE_MISC , > driver_one_interrupt_handler, tsc, &(tsc->handler)); > } > > My interrupt handler function is actually quite long, but there > is nothing to be done about it. There is no really good way to > make it shorter. Anyway, in Driver 2, I call a function (part of > an API that I provide in driver 1) and it returns a value: > > status = driver_one_is_operation_complete(param, param); > > The driver_one_is_operation_complete function actually returns to > Driver 2 a status variable that is set in the interrupt handler > of driver 1. > > //global for status of an event. > int g_status; > void driver_one_interrupt_handler(void * arg) > { > g_status = 0; > > if(CERTAIN_CONDITION_OCCURRED) > g_status = 1; > } > > The problem is that I never, ever get the value from the > function driver_one_is_operation_complete that I would expect. > The value returned is always 0 and never 1. However, when I check > this value in driver one's detach function, right before the end > of execution, the value is 1. > > driver_one_detach() > { > > print("g_status %x\n",g_status) > blah, blah, blah > } > > Clearly, the interrupt handler has executed and the value has > been set to one. > > In driver two, I've tried waiting 2 or 3 seconds (with the > system's delay function) before calling > driver_one_is_operation_complete, but this doesn't help either. > Is there something weird going on in the Driver to Driver communication? > > Thanks in advance for any help or clues you may be able to provide, > KD > _______________________________________________ > freebsd-drivers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-drivers > To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org" > From owner-freebsd-drivers@FreeBSD.ORG Thu Jan 19 18:15:24 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 8EEC916A41F for ; Thu, 19 Jan 2006 18:15:24 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A21C43D72 for ; Thu, 19 Jan 2006 18:15:16 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 6468447 for multiple; Thu, 19 Jan 2006 13:16:17 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k0JIFCkB063983; Thu, 19 Jan 2006 13:15:14 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-drivers@freebsd.org, Kimberly Davis Date: Thu, 19 Jan 2006 13:00:06 -0500 User-Agent: KMail/1.9.1 References: <20060119155705.13713.qmail@web30004.mail.mud.yahoo.com> In-Reply-To: <20060119155705.13713.qmail@web30004.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601191300.07638.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1245/Wed Jan 18 11:57:44 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Norbert Koch Subject: Re: Interrupt Handlers and Driver to Driver Communication X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2006 18:15:24 -0000 On Thursday 19 January 2006 10:57, Kimberly Davis wrote: > Norbert, thanks for responding. > > I provide answers to your questions and a little more information below. > > In driver 2, I call the function driver_one_is_operation_complete, which is > part of an API provided by driver 1. > > Yes, I have reason to believe that the context becomes active. In other > words, I believe that the condition CERTAIN_CONDITION_OCCURRED does in fact > become true at some point. Driver 1 is a dma driver, and I can actually see > that the driver completes a transaction, which triggers an interrupt. When > I check the status variable from within driver1 the status does equal 1, > letting me know that the condition occurred. > > if(CERTAIN_CONDITION_OCCURRED) > g_status = 1; > > My drivers are definitely in different source files, and they are being loaded with different invokations of kldload. For example: > >kldload driver1.o > >kldload driver2.o > >kldunload driver2 > >kldunload driver1 > > Driver2 is dependent on driver1. I use the MODULE_DEPEND macro to ensure > this dependency. Driver1 is actually composed of two .c files. > > Here is the layout for driver1: > > dma.c: > uint32_t g_status > > dma_client_api.c: > extern uint32_t g_status > The code for driver_one_is_operation_complete is in this file and there is > a dma_api.h file which contains the function protype. > > Here is the file layout for driver2: > client_driver.c > In driver2's attach function, I call driver_one_is_operation_complete. > > I have tried a volatile delcaration, and it doesn't work. I have checked, > checked, and re-checked to make certain that I haven't declared the status > variable twice accidentally. > > Also, I should say that I have a uniprocessor system, and the processor is > not multi-core, so none of the typical questions about hyper-threading, SMP > syncing issues, or multi-core difficulties seem particularly relevant, > although I won't rule some sort of phantom issue out. I am using FreeBSD > 6.0. I've also tried making this variable a part of the softc structure. > That does not help either. > > Obviously I am having some sort of module communication problem, but what? > I can't seem to nail it down. Can you provide 'nm driver1.ko | grep g_status' and 'nm driver2.ko | grep g_status' output? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-drivers@FreeBSD.ORG Thu Jan 19 21:35:56 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 DBBE416A41F for ; Thu, 19 Jan 2006 21:35:56 +0000 (GMT) (envelope-from kimblydavis@yahoo.com) Received: from web30003.mail.mud.yahoo.com (web30003.mail.mud.yahoo.com [68.142.200.66]) by mx1.FreeBSD.org (Postfix) with SMTP id 4437F43D45 for ; Thu, 19 Jan 2006 21:35:56 +0000 (GMT) (envelope-from kimblydavis@yahoo.com) Received: (qmail 28901 invoked by uid 60001); 19 Jan 2006 21:35:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=DoFMcXh2rLFeRqTrNdthKwB2ir/KjtxPKjZqo2X44Rcqr5uXVXh5BVMuKxP6jewmTSAJx23lLDISN4/1k+mvf76WmYBvNEn2x3CrPbOe4Ubk9ym1jdurxAt/SiCUUFORgE0dZ3iVIgjUW6OHPOf7x71610zVDdQSzPaoA5IHTTc= ; Message-ID: <20060119213555.28899.qmail@web30003.mail.mud.yahoo.com> Date: Thu, 19 Jan 2006 13:35:55 -0800 (PST) From: Kimberly Davis To: John Baldwin , freebsd-drivers@freebsd.org In-Reply-To: <200601191300.07638.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Norbert Koch 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: Thu, 19 Jan 2006 21:35:57 -0000 Yes, certainly. 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. Thanks, KD ----- Original Message ---- From: John Baldwin To: freebsd-drivers@freebsd.org; Kimberly Davis Cc: Norbert Koch Sent: Thursday, January 19, 2006 11:00:06 AM Subject: Re: Interrupt Handlers and Driver to Driver Communication On Thursday 19 January 2006 10:57, Kimberly Davis wrote: > Norbert, thanks for responding. > > I provide answers to your questions and a little more information below. > > In driver 2, I call the function driver_one_is_operation_complete, which is > part of an API provided by driver 1. > > Yes, I have reason to believe that the context becomes active. In other > words, I believe that the condition CERTAIN_CONDITION_OCCURRED does in fact > become true at some point. Driver 1 is a dma driver, and I can actually see > that the driver completes a transaction, which triggers an interrupt. When > I check the status variable from within driver1 the status does equal 1, > letting me know that the condition occurred. > > if(CERTAIN_CONDITION_OCCURRED) > g_status = 1; > > My drivers are definitely in different source files, and they are being loaded with different invokations of kldload. For example: > >kldload driver1.o > >kldload driver2.o > >kldunload driver2 > >kldunload driver1 > > Driver2 is dependent on driver1. I use the MODULE_DEPEND macro to ensure > this dependency. Driver1 is actually composed of two .c files. > > Here is the layout for driver1: > > dma.c: > uint32_t g_status > > dma_client_api.c: > extern uint32_t g_status > The code for driver_one_is_operation_complete is in this file and there is > a dma_api.h file which contains the function protype. > > Here is the file layout for driver2: > client_driver.c > In driver2's attach function, I call driver_one_is_operation_complete. > > I have tried a volatile delcaration, and it doesn't work. I have checked, > checked, and re-checked to make certain that I haven't declared the status > variable twice accidentally. > > Also, I should say that I have a uniprocessor system, and the processor is > not multi-core, so none of the typical questions about hyper-threading, SMP > syncing issues, or multi-core difficulties seem particularly relevant, > although I won't rule some sort of phantom issue out. I am using FreeBSD > 6.0. I've also tried making this variable a part of the softc structure. > That does not help either. > > Obviously I am having some sort of module communication problem, but what? > I can't seem to nail it down. Can you provide 'nm driver1.ko | grep g_status' and 'nm driver2.ko | grep g_status' output? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-drivers@FreeBSD.ORG Fri Jan 20 07:28:03 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 EE39916A42C; Fri, 20 Jan 2006 07:28:03 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3485843D48; Fri, 20 Jan 2006 07:28:02 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id 2E3ECBCE2C; Fri, 20 Jan 2006 08:28:01 +0100 (CET) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16026-06; Fri, 20 Jan 2006 08:27:55 +0100 (CET) Received: from firewall.demig (p508391F0.dip0.t-ipconnect.de [80.131.145.240]) by server.absolute-media.de (Postfix) with ESMTP id 43DC2B92EE; Fri, 20 Jan 2006 08:27:55 +0100 (CET) Received: from ws-ew-3 (ws-ew-3.demig.intra [192.168.1.72]) by firewall.demig (8.13.5/8.13.4) with SMTP id k0K7OrfO015644; Fri, 20 Jan 2006 08:24:56 +0100 (CET) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: "Kimberly Davis" , "John Baldwin" , Date: Fri, 20 Jan 2006 08:24:55 +0100 Message-ID: <000101c61d92$9ca927c0$4801a8c0@ws-ew-3.demig.intra> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20060119213555.28899.qmail@web30003.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Cc: Subject: RE: Interrupt Handlers and Driver to Driver Communication X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list 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 07:28:04 -0000 > 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? 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?