On Friday 23 April 2010 22:05:34 Bob Copeland wrote: > On Fri, Apr 23, 2010 at 09:14:04AM +0900, Bruno Randolf wrote: > > On Thursday 22 April 2010 17:42:39 Joerg Pommnitz wrote: > > > Bob, > > > I just tested a recent wireless-testing snapshot. Unfortunately the > > > problem still persists. > > > Please consider the following patch for inclusion. For me it makes the > > > difference between "freezes in minutes" and "works stable". I know it's > > > at best a workaround and at worst a bad hack, but until the real cure > > > has been found, this is what we should do, IMHO. > > > > sorry, i have to object! if this patch goes in, it will be less likely > > that anyone cares enough to find a real solution, so this is not good. > > I'm sympathetic to this viewpoint, but at least I don't have the > bandwidth right now to track it down until my semester ends here in > a few weeks. What do you propose Joerg do to further debug?
a few weeks isnt too long, imho... ;) i'm sorry i haven't been able to completely follow this thread. could you or joerg give us a short overview: what chipset and platform are we talking about? what has been tried, where do you think the bug lies? does it have anything to do with noise calibration or not? btw: the only time when i saw similar kinds of reset and register timeout errors was when there was a DMA bug on my platform. could it be anything like this? > What if as a compromise in the near term we do just the wakeup part (not > all of reset) in a loop of length 2 with a FIXME? that might be better... or even a WARN_ON... i think we need to review the whole reset code. bruno _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
