> Hello there,
>
> today a somewhat unprecise report:
>
> When connecting to the local university's wireless APs, rather regularly
> presumably the kernel crashes.
>
> So, connecting to one of those the system hardlocks. No panic LED blinking, no mouse cursor moving,
> no magic sysreq key working. Poweroff is the only way to revive the machine. Until the upcoming
> lock-up.
>
> What might serve as a hint: using knemo and kwifimanager (with wpa_supplicant in the bg) it feels like it is
> freezing more frequently. Not running kwifimanager seems to reduce the frequency w/o however eliminating it
> completely. Sometimes iceweasel has been touched and then the crash occurred.
> Maybe some TX (or subsequent RX) provokes the crash? Some idea that also came up was that accessing iwlagn
> drivers isn't clean when it's happening from more that one place at the same time
> (->wpa_supplicant + kwifimanager)?
>
> This behaviour is currently only known to happen in this exact place/location. So one assumption is that it
> is somehow correlated to a particular type of access point, firmware respectively. Nonetheless, even
> if there's some fw sending kill packets, the kernel should not crash, obviously.
>
> The access points in range are of type:
>
> - one 0:1d:8b PIRELLI BROADBAND SOLUTIONS
> - couple of those 0:40:96 Cisco Systems, Inc.
> - one 0:1a:70 Cisco-Linksys
>
> This notebook has no serial port, so we haven't been able to get a glimpse on what is happening at that
> precise moment. xconsole or dmesg haven't been helpful as the system just freezes and that's it.
>
> Comments, ideas, fixes welcome...
>
> Cheers,
>
> Nils
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to
majordomo@vger.kernel.org
> More majordomo info at
http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at
http://www.tux.org/lkml/
>
