Hi, Martin Husemann wrote:
> The message is bogus, it has nothing to do with autoconfiguration. Misleading.. I was wondering what autoconfiguration had to be done after everything was connected. > > "Fatal error" is a bit in the interrupt cause register of the intel > chipset. The driver can not do anything about it and resets the device > (simmilar to a "ifconfig iwi0 down). This is not a good error handling > strategy, as you have noticed - and it is also done very wrong in the > iwi_softintr handler. Not very good and it explains aslo why, if done quickly enough, ifconfig up restores network connectivity and even open connection. Clearly, if time passes, dhcp lease might expire, connections drop, etc. > The driver should clear the interrupt, schedule a reset and ignore all > other activity untill the reset has happened. Of course the reset should > include bringing up the device to full working state again. I wonder which interrupt here happens that requires a rest - these disconnects happen also with a quite idle system. I had no X11 running and just network up and telnet in sometimes. > > However, this is obviously not easy to test and debug, as you will have to > be in a setup where this happens often enough (like your's). Let's try.... I wonder if 10 increased the frequency of drops or today is an unlucky day! > If you have patience and would be able to help with this: compile your > kernel with "options IWI_DEBUG" and see if that enables enough login to > give us a hint about the cause. If that is not enough you would need to > raise iwi_debug to more than the default level of 4, but that would > spam your log with every received packet. I will! The system should be fast enough. I just found that syssrc.tgz doesn't provide builds.h and one needs whole src.tgz to get it.. a little stupid. And also share. Building now.... will report back once done / rebooted. > Please file a PR and lets collect data there. Done. kern/58232 Riccardo