On Wed, 22 Jul 2009 17:29:57 -0700, Sam Leffler <sam_at_errno.com> wrote: > Giorgos Keramidas wrote: >> When I run tcpdump on lagg0 (with em0 and iwn0 as laggports), tcpdump >> seems to work fine, but typing ^C kills the wireless interface too. > > This is a known issue; bpf is holding a mutex over calls to the driver > that may block (in this case the taskqueue_drain calls in > net80211). It's unlikely to be resolved for 8.0 (too risky). Ok, it's good to know it is a known issue :) >> Then typing ^C stops tcpdump but the log shows: >> >> Jul 22 17:59:29 kobe kernel: wlan0: promiscuous mode disabled >> Jul 22 17:59:29 kobe kernel: em0: promiscuous mode disabled >> Jul 22 17:59:29 kobe kernel: iwn0: error, INTR=82000000<SW_ERROR,RX_INTR> STATUS=0x40010000 >> Jul 22 17:59:29 kobe kernel: lagg0: promiscuous mode disabled >> Jul 22 17:59:30 kobe kernel: iwn0: iwn_transfer_firmware: timeout waiting for first alive notice, error 35 >> Jul 22 17:59:30 kobe kernel: iwn0: iwn_init_locked: could not load firmware, error 35 >> Jul 22 17:59:30 kobe kernel: wlan0: link state changed to DOWN >> Jul 22 17:59:30 kobe kernel: lagg0: link state changed to DOWN >> >> At this point wlan0 is without carrier, and stays that way until I >> unplumb wlan0 and lagg0 and re-create them. > Sounds like iwn isn't reacting well to the calls coming in from > lagg. wlandebug state should provide some insight. I've used > lagg+iwn+em on a t61p with no obvious issues but never tried to run > tcpdump on the lagg port. It's a Lenovo Thinkpad X61s I'm using for this, so I'll gather some wlandebug output and post more details. I think it's probably a problem with iwn because the other interface (em0) seems to be handling tcpdump runs better.Received on Thu Jul 23 2009 - 12:36:06 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:52 UTC