Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Aug 2006 10:29:32 -0700
From:      "David Christensen" <davidch@broadcom.com>
To:        "Gleb Smirnoff" <glebius@FreeBSD.org>
Cc:        brad@openbsd.org, oleg@FreeBSD.org, net@FreeBSD.org
Subject:   RE: bge(4) one packet wedge
Message-ID:  <09BFF2FA5EAB4A45B6655E151BBDD90301D4325E@NT-IRVA-0750.brcm.ad.broadcom.com>
In-Reply-To: <20060824060922.GF76666@cell.sick.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
> D> This "lost interrupt" type of problem is addressed by the=20
> use of the
> D> status_tag=20
> D> field in the status block.  (Listed as bge_rsvd0 in the=20
> bge_status_block
> D> structure).=20
> D> Everytime the status block is updated a new tag value is=20
> written to the
> D> status block. =20
> D> When the ISR starts the driver should record the=20
> status_tag value.  At
> D> the end
> D> of the ISR, the driver should compare the current=20
> status_tag value is
> D> the status
> D> block with the value recorded on entry to the ISR.  If the=20
> values are
> D> the same
> D> then no additional status block updates have occurred so=20
> there shouldn't
> D> be
> D> any packets hanging around.  If the values are different=20
> then additional
> D> packets
> D> or completions are waiting around so the ISR should loop=20
> around again.
> D> At the=20
> D> end of the ISR the driver will write the status_tag value it last
> D> handled to a
> D> mailbox register, letting the hardware know the last=20
> status block update
> D> handled.
> D> If necessary the hardware will generate a new interrupt=20
> and start the
> D> process over
> D> again.
> D>=20
> D> This entire process should be included in the Linux=20
> driver, I don't see
> D> it being
> D> used in the bge driver (bge_intr()).
>=20
> True, this isn't done in FreeBSD driver. First I started to=20
> work on this,
> but just noticed that I am seeing this problem on 5700 chip, that is
> known not to support the status tag.
>=20
> What can be the problem for not updated status block in the 5700 case?

In general the problem isn't that the status block isn't being updated,
but that
the status update occurs AFTER the ISR has stopped looking at the status
block, but before the ISR has re-enabled interrupts, thus missing the
update.
That's why tagged status mode is an improvement, the ISR actively tells
the
hardware which status block update it last processed and forces the
hardware
to generate another interrupt if a status block update was missed by the
ISR.

Dave




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