On Wed, Jul 08, 2009 at 02:58:11AM -0400, Jasin Colegrove wrote: > I haven't tried this yet, but I started up gitk and realized that the > last good commit was the one previous to the bad commit. They where > made 3 minutes apart in the ath5k dir. So I am assuming that the > "Disable BMISS interrupts was not actually at fault. It just doesn't > seem logical now that i look at it. Yeah, that commit is near some changes that might cause what you are seeing though, so maybe you made a wrong turn along the way? E.g. "ath5k: Update reset code" introduced a bug for RF 5413 chips, maybe others. Another possible change is the txpower rework. BTW, can you (re?)post the "Atheros AR5212 chip found (MAC xxx, PHY xxxx)?" > So I started another bisect of drivers/net/. Is this the main tree you > where talking about or do you think I need to go further into the main > tree? If so, how far? Also at least /net (you can add multiple paths to git bisect). If you can narrow it down to a small range then a bisect over the entire tree would eliminate any doubt, but in that case it's easier to make a bisect mistake. As you say, it does sound like a driver issue though. > stellar results. Once again, downgrading to kernel .29 fixes > everything without changing any of my other settings. I am still 110% > positive this is a kernel module/driver issue. It does make sense, no? Yeah, unfortunately I don't really have any good ideas, but I've seen a trickle of similar reports so it would be good to nail it down. Thanks for testing, it really helps a lot. -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
