On Wed, 22 Jul 2009 17:29:57 -0700, Sam Leffler <sam@errno.com> wrote:
quoted text
> 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 :)

quoted text
>> 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.

quoted text
> 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.

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"