bge(4) one packet wedge

[Oleg Bulyzhin]

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()).
> 
> Dave
> 

Could you please answer few questions?

1) I've found status tag is returned in status block even if bit 9 of Misc.
   Host Control Register is not set, is it ok?

2) Status tag is returned in bits 0-7 of status tag field of status block,
   as long as i know it should be returned in bits 31-24, is it ok?

3) If i try to return processed tag (at the end of ISR) in Mailbox 0 register:
   CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, status_tag << 24);
   it would lead to disabled interrupts.
   I've thought this should not happen cause in_isr bits (0-23) are cleared.

-- 
Oleg.