> >I used a similar but different strategy in an earlier version of my own >driver. I used channel 0 as cmd data and rx data, but channel 1 as tx >data. But it still led to occasional hangs. Usually you need to drive >the interface pretty hard to hit it. Run two ttcp streams and you might >see it. > >I highly recommend you consider either adding a delay (forgot how long >it needs to be -- I should probably check the errata), or just switching >to a single BAP path. The problem isn't just one of if you use one >path or the other simultaneously -- its if you use one path or the other >within a certain small window of time. Its an ugly ugly errata. > > Ok, I will test and try.
>>> >>> >>I develop&debug realtek wifi driver recently and encounter such a >>deadlock. >>since 'scan' is not invoked frequently, I use a spin >>wait--drv_usecwait(). >> >> > >That's a really, really bad idea. You're talking about spinning for a >whole second. _Everything_ on the machine stops while this is >happening. Even interrupts will be blocked. I strongly urge against >this approach. > > I know it is a low-efficiency solution. I will try to find an alternative later. Thanks, Brian
