On Sunday 06 June 2010 22:07:00 Nick Kossifidis wrote:
We read-and-clear RXDP on hw_nic_reset (actually we do that for any
pending register writes -we need to ensure that all pending register
writes are complete by doing a DMA register read, docs suggest RXDP
and that's what we are doing on
Hi!
Here is the patch to disable ath5k leds support on build stage.
However if the leds support was enabled do not force selection of 802.11 leds
layer.
Depency on LEDS_CLASS is kept.
Suggestion given by Pavel Roskin and Bob Copeland applied.
Changes from the previos version of the patch:
-
On Wed, Jun 9, 2010 at 3:40 AM, Bruno Randolf b...@einfach.org wrote:
hey, i guess something like this must be happening...
i think we have to avoid tasklets being run concurrently to a reset.
so does this patch help?
Heh, I made a similar patch this morning before I saw this. I think
the
Hi, Bob.
For instance I don't use 802.11 leds layer and trigger leds from
userspace according to my purposes.
-- Dima
On Wed, Jun 9, 2010 at 4:58 PM, Bob Copeland m...@bobcopeland.com wrote:
On Wed, Jun 9, 2010 at 3:31 AM, Dmytro Milinevskyy
milinevs...@gmail.com wrote:
However if the leds
I wrote some code to test my hunch. I was under the mistaken impression
that
each receive tasklet starts looking at receive buffers from the point where
the
hardware last copied data. That's not the case, as Bob mentioned in one of
his
emails. All receive tasklets start traversing the receive
I don't know anything about work queues, but I did read some documentation
about tasklets. Relevant info: tasklets always run on the CPU that
schedules
them, multiple tasklets can run at the same time on different CPUs. You
folks
probably know this already
bob
On Wed, Jun 9, 2010 at 3:07
The wireshark experiment I ran earlier is worth considering again.
Wireshark
saw block 110413 sent, but the receive tasklet saw a stale block, 107223.
In the data file, block 110413 appears where block 110412 should be in
addition
to appearing in its proper spot. The receive tasklet saw data for
On Wednesday 09 June 2010 22:42:27 Bob Copeland wrote:
On Wed, Jun 9, 2010 at 3:40 AM, Bruno Randolf b...@einfach.org wrote:
hey, i guess something like this must be happening...
i think we have to avoid tasklets being run concurrently to a reset.
so does this patch help?
Heh, I made
2010/6/10 Bruno Randolf b...@einfach.org:
On Wednesday 09 June 2010 22:42:27 Bob Copeland wrote:
On Wed, Jun 9, 2010 at 3:40 AM, Bruno Randolf b...@einfach.org wrote:
hey, i guess something like this must be happening...
i think we have to avoid tasklets being run concurrently to a reset.
On Thu, Jun 10, 2010 at 10:21:44AM +0900, Bruno Randolf wrote:
hi bob!
sounds like a good plan... do you have time to do that?
Yeah, I started on this already, will probably have it in a day or two.
could we improve background scanning? right now it will make us loose
packets...
One
On Thursday 10 June 2010 12:51:07 Bob Copeland wrote:
On Thu, Jun 10, 2010 at 10:21:44AM +0900, Bruno Randolf wrote:
hi bob!
sounds like a good plan... do you have time to do that?
Yeah, I started on this already, will probably have it in a day or two.
great!
could we improve
11 matches
Mail list logo
