Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Aug 2006 10:47:43 +0900
From:      Pyun YongHyeon <pyunyh@gmail.com>
To:        David Christensen <davidch@broadcom.com>
Cc:        brad@openbsd.org, Gleb Smirnoff <glebius@FreeBSD.org>, oleg@FreeBSD.org, net@FreeBSD.org
Subject:   Re: bge(4) one packet wedge
Message-ID:  <20060824014743.GF22634@cdnetworks.co.kr>
In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD90301D43002@NT-IRVA-0750.brcm.ad.broadcom.com>
References:  <20060823161649.GE76666@cell.sick.ru> <09BFF2FA5EAB4A45B6655E151BBDD90301D43002@NT-IRVA-0750.brcm.ad.broadcom.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 23, 2006 at 12:53:49PM -0700, David Christensen wrote:
 > This "lost interrupt" type of problem is addressed by the use of the
 > status_tag 
 > field in the status block.  (Listed as bge_rsvd0 in the bge_status_block
 > structure). 
 > Everytime the status block is updated a new tag value is written to the
 > status block.  
 > When the ISR starts the driver should record the status_tag value.  At
 > the end
 > of the ISR, the driver should compare the current status_tag value is
 > the status
 > block with the value recorded on entry to the ISR.  If the values are
 > the same
 > then no additional status block updates have occurred so there shouldn't
 > be
 > any packets hanging around.  If the values are different then additional
 > packets
 > or completions are waiting around so the ISR should loop around again.
 > At the 
 > end of the ISR the driver will write the status_tag value it last
 > handled to a
 > mailbox register, letting the hardware know the last status block update
 > handled.
 > If necessary the hardware will generate a new interrupt and start the
 > process over
 > again.
 > 
 > This entire process should be included in the Linux driver, I don't see
 > it being
 > used in the bge driver (bge_intr()).
 > 

Hi,

I have a question too.
How we know generated interrupt is ours?
It seems that status block could be updated before/after generation
of an interrupt. If the interrupt is shared with other devices
what is correct way to know the origion of the interrupt?

-- 
Regards,
Pyun YongHyeon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060824014743.GF22634>