bge(4) one packet wedge

[Gleb Smirnoff]

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

In the Linux driver for the not tag capable controllers there is a following
comment and code:

        /* In INTx mode, it is possible for the interrupt to arrive at
         * the CPU before the status block posted prior to the interrupt.
         * Reading the PCI State register will confirm whether the
         * interrupt is ours and will flush the status block.
         */
        if ((sblk->status & SD_STATUS_UPDATED) ||
            !(tr32(TG3PCI_PCISTATE) & PCISTATE_INT_NOT_ACTIVE)) {

So, I tried to add  (void)pci_read_config(sc->bge_dev, BGE_PCI_PCISTATE, 4)
to the bge_intr(). Unfortunately, this didn't help.

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE