From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4306 invoked by alias); 10 Apr 2006 16:41:38 -0000 Received: (qmail 4297 invoked by uid 22791); 10 Apr 2006 16:41:37 -0000 X-Spam-Check-By: sourceware.org Received: from mail.toptech.com (HELO toptech.com) (207.13.72.10) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Apr 2006 16:41:34 +0000 DKIM-Signature: a=rsa-sha1; c=simple; d=toptech.com; s=MDaemon; t=1144687291; x=1145896891; q=dns; h=DomainKey-Signature: Received:Reply-To:From:To:Subject:Date:Organization:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To:Thread-Index: Message-ID; b=LeOp/xNBTOBJrG0GgOwNzih6j/RIM0uKKcLe+zDRjfRMzCW/iCB 1x8u7ZlSrMdW2S4lV3dZ0+JuD8ijfXz+acffolXtfGBi8R4X9+t0gMkOhGZv6A9h m3rSO3jH0IjbwlvNO9L4n9eBQOgsWEBpA2IU0DzT749mskG2RAeQ5pg8= Received: from jporthousexp2 by toptech.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.0) with ESMTP id 43-md50000000025.msg for ; Mon, 10 Apr 2006 12:41:29 -0400 Reply-To: From: "Joe Porthouse" To: Date: Mon, 10 Apr 2006 16:41:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: X-HashCash: 1:20:060410:ecos-discuss@sources.redhat.com::DpgT9E6IUz5+d9ZP:0000000000000000000000000000004Ua0 X-Spam-Processed: mail.toptech.com, Mon, 10 Apr 2006 12:41:30 -0400 (not processed: message from valid local sender) X-MDRemoteIP: 172.16.65.179 X-Return-Path: jporthouse@toptech.com X-MDaemon-Deliver-To: ecos-discuss@sources.redhat.com Message-ID: X-MDAV-Processed: mail.toptech.com, Mon, 10 Apr 2006 12:41:31 -0400 X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: RE: [ECOS] Re: DSR stops running after heavy interrupts. Spurious Interrupt! X-SW-Source: 2006-04/txt/msg00122.txt.bz2 Nick, Thanks for you reply. Your right. Not calling the interrupt_end() routine would cause the lock not to be released. After your comment I started looking closer at my modification. My original modification of: /hal/arm/arch/current/src/vectors.S file at line 951. cmp v1,#CYGNUM_HAL_INTERRUPT_NONE <-- from this cmp r0,#CYGNUM_HAL_INTERRUPT_NONE <-- to this v1 originally contained the interrupt vector. But I mistakenly believed this was the check of the return value from the ISR. I modified it to look at r0, the return value from the isr. The return value from the isr will be 0-3 (really 1 or 3). The CYGNUM_HAL_INTERRUPT_NONE is -1! (for some reason I thought it was +1 looking at the assembly listing) Bottom line, my modification made sure that interrupt_end() would always be called, even when v1 == CYGNUM_HAL_INTERRUPT_NONE (spurious interrupt). I just did a quick test with the original code and verified that when a spurious interrupt occurs, the interrupt_end() routine is not called and the lock is not released and my problem occurs. Calling the interrupt_end() routine with a spurious interrupt did not seem to break anything. Was there a reason why interrupt_end() should not be called on spurious interrupts? Now to figure out why I am getting a spurious interrupt with the simple UART code listed below? What should I look for in attempting to eliminate spurious interrupts? Can they be eliminated? What modifications to eCos source or my project is in order for dealing with spurious interrupts correctly? #define CYGNUM_HAL_INTERRUPT_22 22 #define CYGNUM_HAL_INTERRUPT_21 21 #define CYGNUM_HAL_INTERRUPT_20 20 #define CYG_HAL_PRI_HIGH 0 static cyg_interrupt btuart_interrupt_new_object; static cyg_handle_t btuart_interrupt_handle; static cyg_vector_t btuart_interrupt_vector = CYGNUM_HAL_INTERRUPT_21; static cyg_priority_t btuart_interrupt_priority = CYG_HAL_PRI_HIGH; unsigned int isr_rx_count = 0; cyg_uint32 btuart_interrupt_isr( cyg_vector_t vector, cyg_addrword_t data) { unsigned int iir, lsr, rbr; iir = PXA255_BTIIR; // check if RX FIFO interrupt if((iir & PXA255_IIR_IID_INT_ID_MASK) == PXA255_IIR_IID_RX_FIFO_INT_PENDING) { lsr = PXA255_BTLSR; while(lsr & PXA255_LSR_DR_DATA_READY) { rbr = PXA255_BTRBR; isr_rx_count++; lsr = PXA255_BTLSR; } } cyg_interrupt_acknowledge(vector); return(CYG_ISR_HANDLED); } void serial_port_start(void) { // GPIO and UART inits here... cyg_interrupt_create( btuart_interrupt_vector, btuart_interrupt_priority, 0, &btuart_interrupt_isr, 0, &btuart_interrupt_handle, &btuart_interrupt_new_object); cyg_interrupt_attach(btuart_interrupt_handle); cyg_interrupt_unmask(btuart_interrupt_vector); // UART interupt enabled here... } Joe Porthouse Toptech Systems, Inc. -----Original Message----- From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Nick Garnett Sent: Monday, April 10, 2006 5:36 AM To: Sergei Organov Cc: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] Re: DSR stops running after heavy interrupts. Bug found? Sergei Organov writes: > Andrew Lunn writes: > > [...] > > > However, from what you are saying it sounds like there needs to be > > another comparison afterwards. Something like: > > > > and r0,r0,#2 // CYG_ISR_CALL_DSR > > beq 17f > > No, bit checking of the ISR return value is performed inside the > interrupt_end() routine: > > if( isr_ret & Cyg_Interrupt::CALL_DSR && intr != NULL ) intr->post_dsr() Exactly. And there are other housekeeping things that go on in interrupt_end() which cannot be skipped. The most important of these is decrementing the scheduler lock. I don't really see how the original poster's problem is fixed by trying to skip interrupt_end(), I would only expect doing that to aggravate the problem. The scheduler lock is acquired early in interrupt processing -- before the ISR is called and we know whether there is a DSR to call. interrupt_end() decrements the scheduler lock and as a side-effect may cause any DSRs to be called. As Andrew has suggested, I think Joe's best way of working out what is happening is to switch on instrumentation and see if he can track down the extra increments of the scheduler lock. -- Nick Garnett eCos Kernel Architect http://www.ecoscentric.com The eCos and RedBoot experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss