Lines Matching refs:empty

26 There are three primary states that a descriptor can be in: "empty",
27 "full" and "not-in-use".  An "empty" or "ready" descriptor is ready
30 descriptor is neither empty or full; it is simply not ready. It may
35 buffers. These are all marked "empty", ready to receive data. This
38 buffers, processing them, and re-marking them empty.
46 and everything in front of it should be "empty".  If the hardware
47 discovers that the current descr is not empty, it will signal an
57 The OS will then note that the current tail is "empty", and halt
65 then mark the descr as "empty", ready to receive data. Thus, when there
67 be "not-in-use", and everything behind it should be "empty". If no
70 "empty", and it will halt processing.
73 all be pointing at the same descr, which should be "empty". All of the
74 other descrs in the ring should be "empty" as well.
101 to "empty". The actual value printed is RXCOMST_A.
106 "empty" == SPIDER_NET_DESCR_CARDOWNED == 0xa
114 As long as the OS can empty out the RX buffers at a rate faster than
116 the OS fails to empty the RX ring fast enough, the hardware GDACTDPA
117 pointer will catch up to the head, notice the not-empty condition,
126 When the OS finally has a chance to run, it will empty out the RX ring.
132 which, from the OS point of view, is empty; the OS will be waiting for
137 empty.
155 marked xa... which is "empty". Thus, from the OS point of view, there
157 that everything in front of the "empty" descr must surely also be empty,
159 become non-empty, which, in this case, will never happen.
164 "full", while descr 254 and 255 are empty. (The "Last 1 descrs" is
171 of the RX chain seems to show it is empty, then it is probable that
191 in the ring. The hardware can empty the ring about four times per jiffy,
199 interrupts, as the hardware can empty the queue faster than the kernel