On Sun, 5 May 2013 21:50:33 +0200 Rafał Miłecki <zajec5@xxxxxxxxx> wrote: > 2013/5/5 Michael Büsch <m@xxxxxxx>: > > On Sun, 5 May 2013 18:31:20 +0200 > > Rafał Miłecki <zajec5@xxxxxxxxx> wrote: > > > >> Still worth considering is my previous e-mail. Why writing (for > >> example) 1 to RXSTOPINDEX doesn't stop firmware from using slot 1? > > > > What makes you think this register does not work? > > Take a look at this: > > [ 327.224976] [DBG] old current:5 new current:6 > [ 327.224982] [DBG] reading slot 5 > [ 327.224997] [DBG] writing stop slot 6 > > In above ring->slot was 5, but IRQ was generated, and we read new > "current" using get_current_rxslot. It appeared to be 6. So we read > packet from slot 5 and then called > ops->set_current_rxslot(ring, 6); > AFAIU hardware shouldn't use slot 6, right? But take a look at what > happens next: > > [ 327.319582] [DBG] old current:6 new current:7 > [ 327.319590] [DBG] reading slot 6 > [ 327.319619] [DBG] writing stop slot 7 > > Hardware generated IRQ and we get_current_rxslot returned 7. It means > we're allowed to read slots up to 7 (excluding). It other words it > means firmware used slot 6... but 100ms earlier we forbid firmware to > use slot 6! I'd rather say that this is a race condition between your testing code and the firmware. -- Michael
Attachment:
signature.asc
Description: PGP signature
