Lines Matching refs:empty

28 There are three primary states that a descriptor can be in: "empty",
29 "full" and "not-in-use".  An "empty" or "ready" descriptor is ready
32 descriptor is neither empty or full; it is simply not ready. It may
37 buffers. These are all marked "empty", ready to receive data. This
40 buffers, processing them, and re-marking them empty.
48 and everything in front of it should be "empty".  If the hardware
49 discovers that the current descr is not empty, it will signal an
59 The OS will then note that the current tail is "empty", and halt
67 then mark the descr as "empty", ready to receive data. Thus, when there
69 be "not-in-use", and everything behind it should be "empty". If no
72 "empty", and it will halt processing.
75 all be pointing at the same descr, which should be "empty". All of the
76 other descrs in the ring should be "empty" as well.
103 to "empty". The actual value printed is RXCOMST_A.
108     "empty" == SPIDER_NET_DESCR_CARDOWNED == 0xa
116 As long as the OS can empty out the RX buffers at a rate faster than
118 the OS fails to empty the RX ring fast enough, the hardware GDACTDPA
119 pointer will catch up to the head, notice the not-empty condition,
128 When the OS finally has a chance to run, it will empty out the RX ring.
134 which, from the OS point of view, is empty; the OS will be waiting for
139 empty.
157 marked xa... which is "empty". Thus, from the OS point of view, there
159 that everything in front of the "empty" descr must surely also be empty,
161 become non-empty, which, in this case, will never happen.
166 "full", while descr 254 and 255 are empty. (The "Last 1 descrs" is
173 of the RX chain seems to show it is empty, then it is probable that
193 in the ring. The hardware can empty the ring about four times per jiffy,
201 interrupts, as the hardware can empty the queue faster than the kernel