> On Nov 23 Roland Dreir sent a patch for interrupt handling, but it > doesn't apply on -current since the file rt2661.c changed slightly > a few weeks earlier (1.51, date: 2009/11/01).
two "e"s in "Dreier" :) > This patch just changes Roland's patch to update against rt2661.c > r1.51 from the OpenBSD repository instead of Roland's patch which > is against his private GIT repo. Sorry about that... I was testing on a 4.5 box, so even though I had the patch against -current, I sent the wrong (backported) one. > I've been running with this for just over a day, including some > time copying kernels and snaps both ways non-stop (after removing > the ifconfig down/up from crontab). It has locked up only twice in > 24 hrs, a definite improvement. Thanks for testing and keeping this patch alive. I would like to see this comitted since I have multiple reports of this improving stability for people, and also I think that it is pretty clearly correct on a theoretical level too. However I have not seen any response from damien@ unfortunately. In my setup (slow VIA mini-itx box used as an AP) I've not seen any lockups with the patch applied. Could you give a quick description of your setup? Are the lockups you see the same as before -- ie the interface stops with "OACTIVE" set, and recovers if you do if config up/down? (Is that the problem you were having before?) I sent another patch (http://www.mail-archive.com/t...@openbsd.org/msg01261.html) that helps my setup a little more (avoids the "interface stays up but no longer sends broadcasts or multicasts" problem I saw -- not sure why exactly but avoiding sending the adapter garbage descriptors seems like a good idea in any case). You could try with that too and see if it helps at all. I do still see another problem that I have not figured out yet, namely the ral interface on the AP stops sending for 20 or 30 seconds and then recovers by itself. If I run ping to the AP on a client box and leave something like "tcpdump -i ral0 -n icmp" running on the AP, then I see that requests continue to be received during the interruption, but no replies are sent. Also I can see that OACTIVE is not set during the interruption. But I don't know why this is happening yet. Is it possible that this is what you're hitting too? Thanks, Roland
