Scott Lambert wrote: > Threading broken to avoid potential takover of ral0 thread. > > On Sat, Sep 26, 2009 at 02:33:26AM +0000, Brandon Gooch wrote: >> On Fri, Sep 25, 2009 at 11:29 PM, Scott Lambert <lamb...@lambertfam.org> >> wrote: >>> iwn does not function after resume so I've actually run ethernet cables >>> to where I use the laptop now. >> I have to unload the if_iwn module on suspend, and reload it on resume >> (via /etc/rc.[suspend|resume], of course). >> >> Have you tried that? > > I am glad to hear that it works for somebody. There is hope! I have: > > kldunload if_iwn > > in /etc/rc.suspend and: > > kldload if_iwn > > in /etc/rc.resume. > > On resume there are lots of > > iwn0: iwn_mem_lock: could not lock memory > > and > > iwn0: iwn_transfer_microcode: could not load boot firmware > iwn0: iwn_transfer_firmware: could not load boot firmware, error 60 > iwn0: iwn_init_locked: could not load firmware, error 60 > > I did just notice: > > iwn0: Reg Domain: \M^?\M^?\M^?\M^?iwn0: iwn_mem_lock: could not lock memory > > Maybe I should set the regulatory domain? But having just spent a few > minutes trying, it doesn't seem to be interested... > > lamb...@slambert:~> sudo ifconfig wlan0 regdomain FCC > ifconfig: SIOCS80211: Device busy
wlan0 is marked UP; you cannot set regulatory state unless the interface is down. > Exit 1 > lamb...@slambert:~> sudo ifconfig iwn0 regdomain FCC > ifconfig: unable to get regulatory domain info: Invalid argument iwn0 is the wrong interface to use; use wlan0 > Exit 1 > > Same result with the other regulatory domains. Maybe iwn just doesn't > support it? > > lamb...@slambert:~> sudo ifconfig wlan0 list regdomain > :regdomain 0 country US anywhere -ecm > > > > http://www.lambertfam.org/~lambert/laptop/TravelMate_5720-6911 > > has my rc.[suspend|resume] and dmesg.[boot|resume] showing the > issues. Other stuff in there that might be relevant too, if anyone is > interested. > Regarding regdomain stuff; AFAIK you cannot alter regulatory state of any intel wireless card; it will enforce whatever is in the EEPROM. Can't recall if the driver pushes EEPROM state up to net80211; if not then it should and it should also reject all requests to change regulatory until there's fw that supports it. Sam _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
