Date: Tue, 22 Oct 2013 18:18:25 -0700 From: Adrian Chadd <adrian@freebsd.org> To: claudiu vasadi <claudiu.vasadi@gmail.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, "freebsd-wireless@freebsd.org" <freebsd-wireless@freebsd.org> Subject: Re: 9.2-STABLE r255918 with GENERIC and iwn - core dump Message-ID: <CAJ-Vmommb%2BtNy5EbvDyxk6sAGRFVardQ9Sebjtyi0aR9%2BV0umA@mail.gmail.com> In-Reply-To: <CAM-i3ijHDVG5XQ0LjfWHT%2BcyECja7VQRR9wXV71wEOeHr4eVDw@mail.gmail.com> References: <CAM-i3iiem_3-tv90k0NWeJjocx77RhT%2BCeZPHZRHZS3_AsgZkQ@mail.gmail.com> <CAJ-VmomY16hJSJgj5jAq9ywxCsY67AmmesPSSgsb1OekTGikww@mail.gmail.com> <CAM-i3ijHDVG5XQ0LjfWHT%2BcyECja7VQRR9wXV71wEOeHr4eVDw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Grr, it's slightly more complicated than that. That whole timer mess is actually used for two things: * if the management transmit succeeds - it acts as a short-interval (a few seconds) timer to ensure that the probe request ends up providing some response that transitions to auth; otherwise it aborts and transitions back to the SCAN state; * if the management transmit fails - it immediately transitions back to SCAN. So, the "correct" fix involves correctly locking things and turning that timer into a "if I fail to transition into a run state, then just go back to scanning" timeout. It sucks and it's going to take an evening of deep thought to figure out the correct solution to. Thanks for reminding me about this mess! -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmommb%2BtNy5EbvDyxk6sAGRFVardQ9Sebjtyi0aR9%2BV0umA>