Re: Xorg nvidia-driver GT 650M cause system reboot on my MacBook Retina 9.1RC1
On Thu, Sep 20, 2012 at 9:47 AM, suken woo wrote: > 2012/9/20 suken woo > >> hi folks: >>xorg caused my macbook 10,1 reboot immediately while startup X with >> latested nvidia-driver >> and event not to generate Xorg.0.log file attached my verbose message. >> thanks for any ideas >> --wsk > > > could you reply with the output of pciconf -lv (eg drop to a shell from the installer) -- Sam Fourman Jr. ___ 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"
Re: Looking for Supermicro distributors
On Tue, Apr 6, 2010 at 10:36 PM, Jeremy Chadwick wrote: > Hi! > > First off, sorry for cross-posting, but in this case I need somewhat of > a broader audience. This is the first time I've ever asked for > something like this, so I'm a bit shy. If end-users have other ideas > on how I can go about this, I'm all ears. > > I'm looking for any Supermicro hardware distributors that linger on the > mailing lists here. I know I've talked at least two of you in the past, > so I'm certain you're out there, but I've lost your names/Email > addresses. As long as this thread is already started, I will jump on board. :) Our company too is looking for Supermicro distributors. feel free to email me off list. Sam Fourman Jr. Fourman Networks ___ 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"
Re: FreeBSD-8.0 802.11n support with ath/mwl
Jim Pingle wrote: On 2/28/2010 10:16 PM, Rui Paulo wrote: On 1 Mar 2010, at 03:05, Jim Pingle wrote: On 2/28/2010 9:41 PM, Rui Paulo wrote: On 1 Mar 2010, at 02:26, Jim Pingle wrote: Ah, I wasn't aware of wlandebug(8). However, it doesn't seem to operate on this mwl(4) card. It sets the value of the sysctl net.wlan.0.debug and that doesn't show up on my system. Another system with a ral(4) card does have that sysctl. Judging by the information in the wlandebug(8) man page it appears as though this may be a side effect of mwl doing much of the work in firmware. wlandebug takes an -i argument. I seem to recall you created your wlan interface named "mwl_wlan0", so you need to type wlandebug -i mwl_wlan0. I saw that, but that is hardcoded to expect wlan (wlan0, wlan1, etc) for an interface name. Having seen that, I recompiled wlandebug without the hardcoded interface name check and it didn't work either, but it did toss an error for the sysctl it was trying to tweak. The whole system was designed for the interfaces to start with "wlan" and be named "wlan". It does certainly seem to lean that way. Personally I prefer to keep the hardware name in there, but I wasn't aware that would cause other issues. Especially when VAPs come into play, I'd rather have, for example, mwl0_wlan1, mwl0_wlan2, ath0_wlan0, etc, so I can better tie what goes where. But that's more of a bikeshed of personal preference. :-) Not following the wlanX naming convention will cause confusion for things like rc config files (I believe). Definitely any tool I touched expects vap's to be named wlanX. sysctl net.wlan.X.%parent gives the parent ifnet of a vap; I've considered many times including this in the ifconfig status. Feel free to offer a patch that does this. That made me look deeper at the code and see it was really just setting the debug sysctl based on flags that wlandebug was aware of. Handy, but the same thing could be done by hand with sysctl and some bitwise math in a pinch, assuming the interface has the right oids. (Which mine doesn't, for some reason...) The purpose of wlandebug is to not do any math by hand. Indeed, You're 110% right on that. I was just trying to work around the other issues I was seeing to get to the root of the issue, which seems to be the missing sysctl oid. I need to run some more tests and straighten my antenna issues out, but I'll report what I find back to the list in a few days. mwl 11n support broke sometime near the last firmware update and I never fixed it. I know in particular there are issues with AMPDU and seq#'s but possible other things too. The fw is rather finicky in how state is managed and it's likely the host is not in sync causing problems w/ the ampdu support and rate control algorithm that both operate in the fw. You should be able to get >100 Mb/s througput on an HT40 channel but I think I was seeing more like 35-40. Turning off ampdu is usually helpful to stabilize operation. 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"
Re: [HEADSUP]: ports feature freeze now in effect
On Mon, Feb 15, 2010 at 4:11 PM, Steven Friedrich wrote: > On Monday 15 February 2010 12:19:01 pm Erwin Lansing wrote: >> In preparation for 7.3-RELEASE, the ports tree is now in feature freeze. >> >> Normal upgrade, new ports, and changes that only affect other branches >> are allowed without prior approval but with the extra >> Feature safe: yes tag in the commit message. Any commit that is >> sweeping, i.e. touches a large number of ports, infrastructural changes, >> commts to ports with unusually high number of dependent ports, and any >> other commit that requires the rebuilding of many packages is not allowed >> without prior explicit approval from portmgr after that date. >> >> When in doubt, please do not hesitate to contact portmgr. >> >> -erwin >> > I suspect this means we won't get KDE 4.4 for quite some time... > ___ I am not sure how close KDE 4.4 is but it would have been nice to get KDE in before the freeze Sam Fourman Jr. ___ 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"
Re: atheros broadcast/multicast corruption with multiple hostap's
Russell Yount wrote:
> On Sun, Jan 17, 2010 at 1:45 PM, Sam Leffler <mailto:s...@errno.com>> wrote:
>
> Russell Yount wrote:
>
>
>
> On Sat, Jan 16, 2010 at 3:21 PM, Sam Leffler <mailto:s...@errno.com> <mailto:s...@errno.com
> <mailto:s...@errno.com>>> wrote:
>
>Russell Yount wrote:
>
>It seems AP to client broadcasts/multicasts traffic is
>broken when using WPA2/802.11i with multiple hostapds in 8.0.
>
>Only the SSID associated with the last hostapd to be
> started has
>AP to client broadcasts/multicasts being delivered correctly.
>
>The AP and client are 8.0 freebsd systems althought I see
> same
>problems with windows XP as a client.
>
>The AP has 4 hostapds configured to use TLS with client
>certificates for
>authentication. (hostapd recompiled with
>HOSTAPD_CFLAGS=-DEAP_SERVER)
>The AP and client radio are shown as ath0: AR5212 mac 5.9
> RF5112
>phy 4.3
>in dmesg.
>
>Client authenticate using client certificates associate
> correctly
>to all 4 SSIDs. Unicast traffic flows correctly between
> clients
>and AP
>for all for 4 SSIDs. Client to AP broadcast/multicast
> traffic works
>on of 4 SSIDs. AP to client broadcast/multicast traffic
> only works
>on 1 of the SSIDs. I have documented this using ARP
> broadcasts,
>but normal IP broadcasts also observed to corrupted.
>
>When an ARP request is send through the AP to an
> associated client
>it seems to be trashed on any of the SSID except the one
> associated
>with the last hostapd to be started. Here is the output of
>client side
>tcpdump showing the problems.
>
>In the first client side tcpdump with the hostapd associated
>with the SSID
>being associaed with the last hostapd started and the traffic
>flowing
>normally.
>
>In the second client side tcpdump with the hostapd associated
>with the SSID
>being not the last hostapd started the ARP request is resent
>multiple times
>and appears corrupted.
>
>I would really like to find a fix for this.
>Any help would be greatly appreciated.
>
>
>This sounds like the crypto encap of the frame is clobbering the
>mbuf contents. You can verify this by setting up multiple
> vaps w/o
>WPA. If this is the problem look for the mbuf copy logic for
> mcast
>frames and make sure a deep copy is done.
>
> Sam
>
>The four VAPs broadcast traffic works find without WPA if I
> do not start hostapds on them
> I have been trying to discovery why broadcast traffic only
> works correctly on the VAP associated with the last hostapd to
> be started. I have move with VAP has the working broadcast
> traffic by restarting the hostapd
> associated with it.
> It would seem something in the WPA/802.1x layer initialization
> remembers which hostapd was started last and that affected the
> crypto encap.
> I keep looking but do not see any place in the code that could
> account for this.
> It seems the corrupt crypto encap also happens on broadcast
> between stations.
> Please correct me if I am wrong:
> but when using hostapd normally traffic is bridged withing the card.
> So if a station sends to the VAP a broadcast it is actaully
> sending a non- broadcast frame to the AP
> and the AP sends the frame to all the other stations.
>
>
> I told you waht the likely problem is. Look in the net80211 layer
> in the kernel for the problem.
>
>Sam
>
>
>
>
> I tried to find problems in mbuf corruption
> in ieee80211_output.c by placing
>
> m = m_unshare(m,M_NOWAIT);
> if (m == NULL) {
> IEEE80211_DPRINTF(vap, IEEE80211_MSG_OUTPUT,
> "%s: cannot get writable mbuf\n", __func__);
> return NULL;
> }
>
> at begining ieee80211_mbuf_adjust()
Re: atheros broadcast/multicast corruption with multiple hostap's
Russell Yount wrote:
On Sat, Jan 16, 2010 at 3:21 PM, Sam Leffler <mailto:s...@errno.com>> wrote:
Russell Yount wrote:
It seems AP to client broadcasts/multicasts traffic is
broken when using WPA2/802.11i with multiple hostapds in 8.0.
Only the SSID associated with the last hostapd to be started has
AP to client broadcasts/multicasts being delivered correctly.
The AP and client are 8.0 freebsd systems althought I see same
problems with windows XP as a client.
The AP has 4 hostapds configured to use TLS with client
certificates for
authentication. (hostapd recompiled with
HOSTAPD_CFLAGS=-DEAP_SERVER)
The AP and client radio are shown as ath0: AR5212 mac 5.9 RF5112
phy 4.3
in dmesg.
Client authenticate using client certificates associate correctly
to all 4 SSIDs. Unicast traffic flows correctly between clients
and AP
for all for 4 SSIDs. Client to AP broadcast/multicast traffic works
on of 4 SSIDs. AP to client broadcast/multicast traffic only works
on 1 of the SSIDs. I have documented this using ARP broadcasts,
but normal IP broadcasts also observed to corrupted.
When an ARP request is send through the AP to an associated client
it seems to be trashed on any of the SSID except the one associated
with the last hostapd to be started. Here is the output of
client side
tcpdump showing the problems.
In the first client side tcpdump with the hostapd associated
with the SSID
being associaed with the last hostapd started and the traffic
flowing
normally.
In the second client side tcpdump with the hostapd associated
with the SSID
being not the last hostapd started the ARP request is resent
multiple times
and appears corrupted.
I would really like to find a fix for this.
Any help would be greatly appreciated.
This sounds like the crypto encap of the frame is clobbering the
mbuf contents. You can verify this by setting up multiple vaps w/o
WPA. If this is the problem look for the mbuf copy logic for mcast
frames and make sure a deep copy is done.
Sam
The four VAPs broadcast traffic works find without WPA if I do not start
hostapds on them
I have been trying to discovery why broadcast traffic only works
correctly on the VAP associated with the last hostapd to be started. I
have move with VAP has the working broadcast traffic by restarting the
hostapd
associated with it.
It would seem something in the WPA/802.1x layer initialization remembers
which hostapd was started last and that affected the crypto encap.
I keep looking but do not see any place in the code that could account
for this.
It seems the corrupt crypto encap also happens on broadcast between
stations.
Please correct me if I am wrong:
but when using hostapd normally traffic is bridged withing the card.
So if a station sends to the VAP a broadcast it is actaully sending a
non- broadcast frame to the AP
and the AP sends the frame to all the other stations.
I told you waht the likely problem is. Look in the net80211 layer in
the kernel for the problem.
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"
Re: ath hostap problems
Nenhum_de_Nos wrote: On Tue, January 5, 2010 00:09, Nenhum_de_Nos wrote: hail, I have a Core 2 Duo 2.66 GHz as a wifi ap: Jan 4 22:31:08 xxx kernel: cpu_reset: Stopping other CPUs Jan 4 22:31:08 xxx kernel: Copyright (c) 1992-2010 The FreeBSD Project. Jan 4 22:31:08 xxx kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 4 22:31:08 xxx kernel: The Regents of the University of California. All rights reserved. Jan 4 22:31:08 xxx kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 4 22:31:08 xxx kernel: FreeBSD 8.0-STABLE #0: Sun Jan 3 00:25:30 BRT 2010 Jan 4 22:31:08 xxx kernel: r...@xxx.xxx:/usr/obj/usr/src/sys/xxx amd64 Jan 4 22:31:08 xxx kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jan 4 22:31:08 xxx kernel: CPU: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz (2669.34-MHz K8-class CPU) Jan 4 22:31:08 xxx kernel: Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 xxx# uname -a FreeBSD xxx.xxx 8.0-STABLE FreeBSD 8.0-STABLE #0: Sun Jan 3 00:25:30 BRT 2010 r...@xxx.xxx:/usr/obj/usr/src/sys/xxx amd64 cat /etc/hostapd.conf interface=wlan0 #bridge=bridge0 driver=bsd logger_syslog=-1 logger_syslog_level=2 logger_stdout=-1 logger_stdout_level=2 debug=0 dump_file=/tmp/hostapd.dump ctrl_interface=/var/run/hostapd ctrl_interface_group=0 ssid=apartnet2 #macaddr_acl=1 #accept_mac_file=/etc/hostapd/accept auth_algs=3 eapol_key_index_workaround=0 #eap_server=0 wpa=3 wpa_psk_file=/etc/hostapd/wpa_psk wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP #stakey=0 ieee8021x=0 hw_mode=g and just get these messages in logs: Jan 4 22:49:46 xxx kernel: ath0: stuck beacon; resetting (bmiss count 4) Jan 4 22:49:48 xxx last message repeated 4 times Jan 4 22:49:48 xxx postfix/local[1293]: fatal: open database /etc/aliases.db: No such file or directory Jan 4 22:49:48 xxx kernel: ath0: stuck beacon; resetting (bmiss count 4) Jan 4 22:50:03 xxx last message repeated 46 times Jan 4 22:50:03 xxx kernel: Jan 4 22:50:03 xxx kernel: ath0: stuck beacon; resetting (bmiss count 4) Jan 4 22:50:19 xxx last message repeated 51 times Jan 4 22:50:20 xxx kernel: Jan 4 22:50:20 xxx kernel: ath0: stuck beacon; resetting (bmiss count 4) Jan 4 22:50:33 xxx last message repeated 41 times Jan 4 22:50:33 xxx kernel: Jan 4 22:50:33 xxx kernel: ath0: stuck beacon; resetting (bmiss count 4) Jan 4 22:50:49 xxx last message repeated 50 times Jan 4 22:50:49 xxx postfix/local[1296]: fatal: open database /etc/aliases.db: No such file or directory Jan 4 22:50:49 xxx kernel: ath0: stuck beacon; resetting (bmiss count 4) Jan 4 22:51:20 xxx last message repeated 98 times Jan 4 22:51:50 xxx last message repeated 100 times Jan 4 22:51:50 xxx postfix/local[1297]: fatal: open database /etc/aliases.db: No such file or directory Jan 4 22:51:50 xxx kernel: ath0: stuck beacon; resetting (bmiss count 4) I can't even see the network in other computers. Some time ago I reported this problem in here, but using slower hardware. and Sam said that was it. That machine was running Linux before and is now being converted to FreeBSD 8. when in linux, I had some performance penalties but it works great for internet access. is there anything I can do to solve this ? the card is this: a...@pci0:5:0:0:class=0x02 card=0x3a131186 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = '802.11a/b/g Wireless Adapter (AR5212)' class = network subclass = ethernet the card doesn't support 802.11a though. I'm about to buy a rum based usb wlan, may be Hawking HWUG1 or TP-LINK TL-WN321G, to make another freebsd based ap for light internet access. is this supposed to happen as well ? thanks, matheus Using similar configuration file for hostapd, I did test another atheros based wlan card in same role: a...@pci0:1:0:0:class=0x02 card=0x3065168c chip=0x001c168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'HDAUDIOFUNC_01&VEN_1095&DEV_1392&SUBSYS_10280242&REV_1000 (USBVID_147E&PID_20165&B71A446&0&1)' class = network subclass = ethernet this is a pcie part, AFAIK, running on Asus F3T turion based notebook. Runs FreeBSD 8 as well: [math...@xxx/usr/home/matheus]$ uname -a FreeBSD xxx.xxx 8.0-STABLE FreeBSD 8.0-STABLE #5: Sun Jan 3 16:20:25 BRT 2010 r...@xxx.xxx:/usr/obj/usr/src/sys/xxx amd64 but this time I have no message as tha other box, and the AP works fine. matheus Are both machines SMP? Stuck beacons typically arise for two reasons: the channel is busy and the ap can't get on the air to send the frame, or the host/bus is overloaded and cannot meet the realtime requirements of posting the beacon frame in time to hit the beacon transmit schedule. I can't tell from the above info whether either might be possible.
Re: atheros broadcast/multicast corruption with multiple hostap's
Russell Yount wrote: It seems AP to client broadcasts/multicasts traffic is broken when using WPA2/802.11i with multiple hostapds in 8.0. Only the SSID associated with the last hostapd to be started has AP to client broadcasts/multicasts being delivered correctly. The AP and client are 8.0 freebsd systems althought I see same problems with windows XP as a client. The AP has 4 hostapds configured to use TLS with client certificates for authentication. (hostapd recompiled with HOSTAPD_CFLAGS=-DEAP_SERVER) The AP and client radio are shown as ath0: AR5212 mac 5.9 RF5112 phy 4.3 in dmesg. Client authenticate using client certificates associate correctly to all 4 SSIDs. Unicast traffic flows correctly between clients and AP for all for 4 SSIDs. Client to AP broadcast/multicast traffic works on of 4 SSIDs. AP to client broadcast/multicast traffic only works on 1 of the SSIDs. I have documented this using ARP broadcasts, but normal IP broadcasts also observed to corrupted. When an ARP request is send through the AP to an associated client it seems to be trashed on any of the SSID except the one associated with the last hostapd to be started. Here is the output of client side tcpdump showing the problems. In the first client side tcpdump with the hostapd associated with the SSID being associaed with the last hostapd started and the traffic flowing normally. In the second client side tcpdump with the hostapd associated with the SSID being not the last hostapd started the ARP request is resent multiple times and appears corrupted. I would really like to find a fix for this. Any help would be greatly appreciated. This sounds like the crypto encap of the frame is clobbering the mbuf contents. You can verify this by setting up multiple vaps w/o WPA. If this is the problem look for the mbuf copy logic for mcast frames and make sure a deep copy is done. 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"
Re: Problems with Atheros card and hostpd
Derek Kulinski wrote: Hello Sam, Sunday, December 27, 2009, 12:05:34 PM, you wrote: I didn't see anything in the thread to point a finger at freebsd but given the debug msg log shows "ath0" instead of "wlan0" I'm guessing whatever version was being used was pre-8.x. I think I was the only one in thread who used FreeBSD as an AP, also that was before 7.x when I made the log. So I'm not saying it's FreeBSD specific problem, I don't even think it's a BSD problem, but perhaps some kind of incompatibility and I was hoping for some workaround. AP mode power save was broken for a time in 7.x (IIRC the aging of frames on the PS q was incorrectly calculated causing them to be tossed prematurely)--but that was unrelated to WME/WMM. Unlikely. Try collecting a packet trace of a failure w/ wireshark or tcpdump from a 3rd sta and send it to me. Be sure to collect data at the 802.11 layer (e.g. -y IEEE802_11_RADIO). You might also learn something by enabling power save debug msgs on the ap w/ wlandebug. Well, I actually managed it to work. Since the phone was rooted I changed settings and disabled WME on the phone. I associated it and it worked. Now there's a weird thing that I don't really get. After I saw that phone was working with WME disabled, I went back and changed it to the way it originally was, I also restarted the phone. To my surprise the phone continued to work (with WME enabled), and I still don't understand why. Perhaps it stored some information necessary? I think I'll deassociate the phone and make it forget the AP and see if it works. Can't even guess w/o a packet trace and/or debug log. WME should be immaterial to FreeBSD unless crypto was involved in which case you might've hit a bug w/ h/w crypto+WME that's long since been fixed (certain ath parts require the MIC be handled in s/w when WME is used). The best thing to do wrt FreeBSD is run 8.0 or later for much better wireless support. 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"
Re: Problems with Atheros card and hostpd
Derek Kulinski wrote: > Hello Boris, > > I checked the handbook, UPDATING, and nothing mentioned this thing, > why? I would think I'm not the only one with this problem, or am I? > > Anyway it seems to work, I'm getting: > Starting hostapd. > Configuration file: /etc/hostapd.conf > wlan0: IEEE 802.11 Fetching hardware channel/rate support not supported. > Using interface wlan0 with hwaddr 00:11:95:e5:70:df and ssid 'mayumi-ap' > > Is it something I should worry about? No. hostapd collects channel/rate information for functionality that is linux-specific. On freebsd hostapd is used purely as an authenticator. > Also how to create wlan device by hand? "ifconfig ath0 wlandev wlan0" > doesn't seem to work. > > What initially was worrying me was this: >>> ath0: mem 0xf400-0xf400 irq 3 at device 11.0 on pci0 >>> ath0: [ITHREAD] >>> ath0: AR2413 mac 7.9 RF2413 phy 4.5 > > I thought that ath0 was using a different driver than it supposed to. > > There's one more question, though not related to this problem. > I have an android phone, and it doesn't seem to work with my FreeBSD > AP, while it works on others. After sniffing the traffic, it looks > like it is a power management issue: > https://supportforums.motorola.com/message/87903#87903 I didn't see anything in the thread to point a finger at freebsd but given the debug msg log shows "ath0" instead of "wlan0" I'm guessing whatever version was being used was pre-8.x. > > Someone traced the problem to WME/WMM in his case. I don't know if > that's the case for me yet, I tried to disable/enable wme on the AP > but it doesn't seem to do anything. Is it possible that I might fix it > by enabling some option? Unlikely. Try collecting a packet trace of a failure w/ wireshark or tcpdump from a 3rd sta and send it to me. Be sure to collect data at the 802.11 layer (e.g. -y IEEE802_11_RADIO). You might also learn something by enabling power save debug msgs on the ap w/ wlandebug. > > Anyway, thanks for everyone who helped me fix the initial issue. > > Derek > > > Wednesday, December 16, 2009, 4:28:49 AM, you wrote: > >> Multi-BSS support in 8.0 means that you first need to create a wlan >> pseudo-device, and run hostapd with that. The rc.conf lines look like this: > >> wlans_ath0="wlan0" >> create_args_wlan0="wlanmode hostap" >> ifconfig_wlan0="ssid networkname media autoselect up" > >> -Boris > >> Derek Kulinski wrote: >>> Hello, >>> >>> I just upgraded my access point (from 7.1 to 8.0) and can't make >>> hostapd work (looks like wide-dhcp relay also has a problem with ath0): >>> >>> [mayumi]:/root# hostapd -P /var/run/hostapd.pid -dd /etc/hostapd.conf >>> Configuration file: /etc/hostapd.conf >>> Line 2: DEPRECATED: 'debug' configuration variable is not used anymore >>> ctrl_interface_group=0 (from group name 'wheel') >>> pcap_open_live: >>> ifname='ath0' >>> bsd driver initialization failed. >>> ath0: Unable to setup interface. >>> rmdir[ctrl_interface]: No such file or directory >>> Exit 255 >>> >>> Output from dmesg: >>> ath0: mem 0xf400-0xf400 irq 3 at device 11.0 on pci0 >>> ath0: [ITHREAD] >>> ath0: AR2413 mac 7.9 RF2413 phy 4.5 >>> >>> The interface seems to exist, but seems it lost some of its >>> functionality: >>> [mayumi]:/root# ifconfig ath0 >>> ath0: flags=8843 metric 0 mtu 2290 >>> ether 00:11:95:e5:70:df >>> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) >>> status: no carrier >>> [mayumi]:/root# ifconfig ath0 list cap >>> ifconfig: Don't know how to list cap for ath0 >>> >>> What's going on? The card worked pretty well with 7.1. >>> >>> I tried to compile kernel just with "device ath_ar5212" >>> but I'm only getting this: >>> >>> ah.o(.text+0x212): In function `ath_hal_rfprobe': >>> /usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to >>> `__start_set_ah_rfs' >>> ah.o(.text+0x21f):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined >>> reference to `__stop_set_ah_rfs' >>> ah.o(.text+0x235):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined >>> reference to `__stop_set_ah_rfs' >>> >>> > > > ___ 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"
Re: Problems moving hostapd AP config from 6.4 to 8.0RC2
Geoff Roberts wrote: Hi Sam, On Mon, 9 Nov 2009 03:48:41 am Sam Leffler wrote: snip < So your station associated and hostapd saw it but nothing in your logs shows what hostapd did or did not do to complete the radius handshake. All we see is that hostapd dropped the station--presumably because it timed out trying to authenticated against the backend. Not sure what debug level you need for hostapd; I usually use the cmd line options. Thanks for responding - it was a great help. Your comment give me a clue as to where to begin looking. It appears some components required by hostapd weren't being built. I am building on an amd64 system. I had a look at the make file in /usr/src/usr.sbin/wpa/hostapd/Makefile and found that adding the following to /etc/src.conf fixed my problem: HOSTAPD_CFLAGS+=-DEAP_SERVER -DEAP_GTC -DEAP_AKA -DEAP_SIM -DEAP_GPSK HOSTAPD_CFLAGS+=-DEAP_PAX -DEAP_SAKE WITH_OPENSSL=YES I haven't had a chance to narrow down exactly which one made the difference, but I'm guessing it is the -DEAP_SERVER flag. The only tunable I could find in /usr/src/tools/build/options was WPA_SUPPLICANT_EAPOL, but this should only affect wpa_supplicant. Does anyone know if there is a tunable I am missing in my src.conf file, or should I be setting the HOSTAPD_CFLAGS directly as above. Setting HOSTAPD_CFLAGS directly is the intended mechanism. EAP_SERVER is the important one to define; past that you're just adding in some of the more esoteric mechanisms. I should probably enable it by default (it comes setup out of the box to do only WPA-PSK). 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"
Re: Problems moving hostapd AP config from 6.4 to 8.0RC2
thm 0 seq 1 > Nov 9 00:44:07 freebsd kernel: [xx:xx:xx:xx:xx:xx] send auth on channel 1 > Nov 9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] station > authenticated (open) > Nov 9 00:44:07 freebsd kernel: wlan0: received assoc_req from > xx:xx:xx:xx:xx:xx rssi 24 > Nov 9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] WPA ie: mc 1/0 uc > 3/0 key 1 caps 0x0 > Nov 9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] station associated > at aid 1: short preamble, short slot time, QoS > Nov 9 00:44:07 freebsd kernel: [xx:xx:xx:xx:xx:xx] send assoc_resp on > channel > 1 > Nov 9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] station > unauthorize > via MLME So your station associated and hostapd saw it but nothing in your logs shows what hostapd did or did not do to complete the radius handshake. All we see is that hostapd dropped the station--presumably because it timed out trying to authenticated against the backend. Not sure what debug level you need for hostapd; I usually use the cmd line options. 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"
Re: ral(4) on 8-RC1
Matt Dawson wrote: > On Saturday 03 Oct 2009 19:28:50 you wrote: >> ral probably does not populate it's initial channel list according to >> the device capabilities. I'm guessing it falls back on the system code >> to do that and it fills in only channels 1-11. This means future >> changes to regulatory cannot setup the channels you want--it's not >> allowed to add channels that are not listed in the "device >> capabilities". > > That makes sense. Given that my 2561 card has "ETSI" stamped on its label, > one would think it's the card's job to report to the driver what it > supports. If the driver doesn't request this, the safest bet is the lowest > common denominator that should be legal everywhere, 11 channels at FCC > spec. Got it. > > Just a quick question, if I may: Are the maxpower specs of regdomain.xml in > dBm? ETSI is max 20dBm ERP at 2.4GHz. Euro spec cards are only capable of > ~100mW anyway, most more like 60mW and your average foot of RG-174 will > knock nearly a dB off at 2.4GHz, so it hardly matters, but I'm curious. The > manpage doesn't specify what the fields mean. maxpower are expressed as dBm. > >> You can hack ral to setup a proper channel list at attach or you can >> make a private hack to net80211 to populate the channel list w/ those >> channels you want. Either is simple. > > Thank you. I'll probably try the local hack for now, but hacking ral (and > probably iwi now I finally have that working, which does exactly the same > thing) to do the right thing would be a better long-term solution. > > To the list: Does anyone have any idea why the iwi firmware modules build > by default on i386 and not on amd64? I know from experience that manually > building them on 7.1 amd64 didn't work, but it now works well on 8 except > for the messages about mcast/promisc update separation. I had problems w/ the iwi firmware on 64-bit so set the build to i386 only. The problems I had were relocation errors and noone could help; if those are gone then building the fw image for amd64 should be fine. Whether the driver works is another matter... 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"
Re: ral(4) on 8-RC1
Matt Dawson wrote: Odd little issue just cropped up on my lappie running 8.0-RC1 amd64. On 7.2 the ral(4) wireless NIC (2560 1st gen mini-PCI) gave me the Japanese regulatory domain allocations (2.412GHz to 2.477GHz, 14 channels) on 802.11g. I understand a lot has changed with 802.11 on 8, but I can now only ever get 2.412-2.462GHz channels 1 to 11. It's not a huge issue right now as my own AP is within that range, but I may run into problems using open access WiFi on the go sometime in the future, with being in the UK (ETSI) and all that. wlan0 is set up in rc.conf like this: wlans_ral0="wlan0" ifconfig_wlan0="country GB regdomain ETSI protmode off WPA DHCP" Taking the interface down and tweaking ifconfig's regdomain and related options makes no difference. I still only end up with 11 channels no matter what I try. Booting from 6.3 (DSBSD over PXE) lists, yet again, 14 channels when I use ifconfig ral0 list chans. Ifconfig lists the correct country and regdomain, so I'm stumped. I do get the "ral0: need multicast update callback" warning, but I'm led to believe that this is harmless. ral probably does not populate it's initial channel list according to the device capabilities. I'm guessing it falls back on the system code to do that and it fills in only channels 1-11. This means future changes to regulatory cannot setup the channels you want--it's not allowed to add channels that are not listed in the "device capabilities". r...@pci0:2:4:0: class=0x028000 card=0x614618e8 chip=0x02011814 rev=0x01 hdr=0x00 vendor='Ralink Technology, Corp' device='Ralink Chipset 802.11b/g WLAN card ( PCIVEN_1814&DEV_0201&SUBSYS_68331460&REV_013&)' class=network cap 01[40]=powerspec 2 supports D0 D3 current D0 Any ideas? Anything else I can do to check the card? Anything else I should have included? I also have a 2561 based Gigabyte GN-WI01GS (also ral) and an iwi(4) 2915 dual band card to test with (and no silly BIOS limitations to stop me, thank $DEITY), but I've had zero luck with iwi on amd64, hence the Ralink card. Last time I tried iwi, the default build (7.1 IIRC) didn't build the module or its firmware (I did have the license ack in loader.conf) and I had to faff about connecting the module to the build, which wasn't pleasant and didn't work anyway (no results from scan, no association with my AP despite working perfectly on i386 with the same config). You can hack ral to setup a proper channel list at attach or you can make a private hack to net80211 to populate the channel list w/ those channels you want. Either is simple. 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"
Re: 8-RC1: iwn0 suspend/resume issues
Scott Lambert wrote: > Threading broken to avoid potential takover of ral0 thread. > > On Sat, Sep 26, 2009 at 02:33:26AM +, Brandon Gooch wrote: >> On Fri, Sep 25, 2009 at 11:29 PM, Scott Lambert >> 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"
Re: SASL problems with spnego on 8.0-BETA4
Rick Macklem wrote: > > > On Fri, 18 Sep 2009, John Marshall wrote: > >> On Thu, 17 Sep 2009, 21:28 +0300, George Mamalakis wrote: >>> Dear all, >>> >>> I am trying to setup ldap with heimdal on my fbsd 8.0-BETA4 and when I >>> run ldapsearch to see if I can authenticate via GSSAPI I keep getting >>> the following error: >>> >>> [r...@ldap root]# ldapsearch -H "ldap://ldap.example.com/"; -b >>> "dc=example,dc=com" >>> SASL/GSSAPI authentication started >>> dlopen: /usr/lib/libgssapi_spnego.so.10: Undefined symbol >>> "GSS_C_NT_HOSTBASED_SERVICE" >>> ldap_sasl_interactive_bind_s: Local error (-2) >>> > I don't know if you guys feel like experimenting, but here's what little > I know about the heimdal/gssapi setup. > > When cyrus-sasl2 builds, it uses the little shell script > /usr/bin/krb5-config with the args. "--libs gssapi" to get the list of > libraries to link against. This doesn't return "-lgssapi_spnego" in the > list. (The list can be changed by editting line #96 of > /usr/bin/krb5-config.) > > Nothing seems to link against "-lgssapi_spnego", so it's a mystery to > me how it ends up using it? (Maybe others with knowledge on how FreeBSD > loads libraries can explain it. The library is listed in /etc/gss/mech.) > > GSS_C_NT_HOSTBASED_SERVICE is defined in the file gss_names.o in > "-lgssapi", which is at the beginning of the list of libraries returned > by "krb5-config --libs gssapi". > > I'm hoping that someone who understands how libraries get loaded can > solve the puzzle, but barring that, you could try added "-lgssapi_spnego" > to line #96 of /usr/bin/krb5-config in front of "-lgssapi" and see if that > gets things to load properly? > > Not much help, but I don't know how to test this stuff, rick FWIW I hit the same problem (I think) with cyrus imap and saslauthd. I am running HEAD and tried building w/ and w/o kerberos enabled but cyradm aborts on startup complaining about the missing symbol. I started digging because I couldn't get cyrus imap to authenticate users. Feels like one or more of these ports are busted. 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"
Re: net/iwi-firmware refuses to build on 7.2-STABLE
Andre Albsmeier wrote: > Today I wanted to build net/iwi-firmware on 7.2-STABLE and I got > > ===> iwi-firmware-2.4_8 is configured with iwicontrol(8) which you don't > need, use 'make rmconfig' and uncheck CONTROL. > > While the firmware itself is in the base system, iwicontrol(8) > is not. The port should be modified to cope with this but I > have no idea in what way. Some ideas: > > 1. Remove the build restrictions > 2. Just build iwicontrol on systems where the fw is not needed > 3. Make an extra port just to build iwicontrol > 4. ??? > > Any suggestions? Thanks, man iwi; the firmware is automatically loaded by the driver 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"
Re: malo wireless driver - is this capable of wpa2-personal (WPA2-PSK)
John wrote: Hello list, uname -prs FreeBSD 7.2-RELEASE-p1 amd64 Question as subject, really. Is the malo driver capable of WPA2 under FreeBSD? ? If so, how would it be set? I've tried various wireless options via ifconfig, can't seem to get it to work, so am wondering if it is capable of it. I know support for it appeared in HEAD on OpenBSD around the middle of April, and this driver is derived from that. thanks malo is derived from the mwl driver. it supports wpa. 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"
Re: kernel compile fails without AH_SUPPORT_AR5416
Bruce Simpson wrote: Sam Leffler wrote: ... the "ath_hal" device. Do not modify ah_desc.h like you've done. Add this to conf/options ATH_HAL opt_ah.h and use that to enable AH_SUPPORT_AR5416. To clarify the first comment: you've made it impossible to build code w/o the extended format descriptor; this is what I find unacceptable. Ah, of course, duh -- I forgot about the CaPiTalIzAtion of the device name gets pulled into config(5) with the 'device' keyword. Thanks for the reminder... This is a much cleaner fix for the issue than forcing the option to be set on always. It looks like HEAD has this issue too and this can go right in there. Are we happy with AH_SUPPORT_AR5416 being enabled in 7.x GENERIC? The 'out of box' config hasn't been broken by the change and this is identical to to the situation in HEAD as far as I can see. Not sure I understand your last question. If you fix the code so it's not dependent on "options AH_SUPPORT_AR5416" then you can just remove it from the GENERIC config files. Otherwise the intent was that "device ath_hal" would enable all available chip support so yes we want support for 5416 and later parts. In fact AH_SUPPORT_AR5416 is probably not needed at all; we can conditionalize the code according to the device config; e.g. #if defined(ATH_HAL) || defined(ATH_AR5416) || defined(ATH_AR9160) || defined(ATH_AR9280) or possibly consolidate this check in one spot and define something like AH_SUPPORT_AR5416 to enable the extended descriptor format support. Beware of driver code that depends on AH_SUPPORT_AR5416 (grep shows several uses). For now just fixing the immediate problem is sufficient; I'll get to cleaning this stuff up later (unless you care to deal with 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"
Re: kernel compile fails without AH_SUPPORT_AR5416
Sam Leffler wrote: Bruce Simpson wrote: Hi, Can you please try this patch? I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut. Sam Leffler wrote: Bruce Simpson wrote: Hi, Looks like I'm late to the party. I was responsible for committing these ath(4) changes to RELENG_7. I can't remember if I tested the kernel compile without the AH_SUPPORT_AR5416 option or not, I have been so incredibly busy. ... ru had a change to fix this but decided not to; can't say why. Otherwise there is a better way to fix this which I alluded to in previous mail--use the config-generated #define that is generated for the "ath_hal" device. Do not modify ah_desc.h like you've done. Add this to conf/options ATH_HAL opt_ah.h and use that to enable AH_SUPPORT_AR5416. Also changes must go in head first. To clarify the first comment: you've made it impossible to build code w/o the extended format descriptor; this is what I find unacceptable. 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"
Re: kernel compile fails without AH_SUPPORT_AR5416
Bruce Simpson wrote: Hi, Can you please try this patch? I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut. Sam Leffler wrote: Bruce Simpson wrote: Hi, Looks like I'm late to the party. I was responsible for committing these ath(4) changes to RELENG_7. I can't remember if I tested the kernel compile without the AH_SUPPORT_AR5416 option or not, I have been so incredibly busy. ... ru had a change to fix this but decided not to; can't say why. Otherwise there is a better way to fix this which I alluded to in previous mail--use the config-generated #define that is generated for the "ath_hal" device. Do not modify ah_desc.h like you've done. Add this to conf/options ATH_HAL opt_ah.h and use that to enable AH_SUPPORT_AR5416. Also changes must go in head first. 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"
Re: cbb related panic: resource_list_release: resource entry is not busy
Lars Engels wrote: On 7.2-RC2 when I remove an Atheros wireless pccard causes the following panic: Unread portion of the kernel message buffer: panic: resource_list_release: resource entry is not busy cpuid = 1 Uptime: 4m28s Physical memory: 2019 MB Dumping 138 MB: 123 107 91 75 59 43 (CTRL-C to abort) (CTRL-C to abort) 27 (CTRL-C to abort) (CTRL-C to abort) 11 (CTRL-C to abort) (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07e25a7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e2879 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc080b4b2 in resource_list_release (rl=0xc594a404, bus=0xc5667100, child=0xc5957e80, type=3, rid=16, res=0xc599fb00) at /usr/src/sys/kern/subr_bus.c:2797 #4 0xc080b647 in bus_generic_rl_release_resource (dev=0xc5667100, child=0xc5957e80, type=3, rid=16, r=0xc599fb00) at /usr/src/sys/kern/subr_bus.c:3365 #5 0xc080b157 in bus_release_resource (dev=0xc5957e80, type=3, rid=16, r=0xc599fb00) at bus_if.h:347 #6 0xc053bef2 in ath_pci_detach (dev=0xc5957e80) at /usr/src/sys/dev/ath/if_ath_pci.c:222 #7 0xc0809378 in device_detach (dev=0xc5957e80) at device_if.h:212 #8 0xc058de4d in cardbus_detach_card (cbdev=0xc5667100) at /usr/src/sys/dev/cardbus/cardbus.c:236 #9 0xc0695bdc in cbb_event_thread (arg=0xc559d800) at card_if.h:95 #10 0xc07bd059 in fork_exit (callout=0xc0695a30 , arg=0xc559d800, frame=0xe57bfd38) at /usr/src/sys/kern/kern_fork.c:810 #11 0xc0ac9270 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 Lars P.S.: Please keep me CC'ed. I am not subscribed to this list. known issue; there's a PR for it; unlikely to get fixed for 7.2 (imo) 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"
Re: kernel compile fails without AH_SUPPORT_AR5416
Bruce Simpson wrote: > Hi, > > Looks like I'm late to the party. I was responsible for committing these > ath(4) changes to RELENG_7. > I can't remember if I tested the kernel compile without the > AH_SUPPORT_AR5416 option or not, I have been so incredibly busy. > > Dennis Melentyev wrote: >> 2009/4/16 Maxim Sobolev : >> >>> Dennis Melentyev wrote: >>> >>>> Could be worth an entry in UPDATING and/or explicitly added to GENERIC. >>>> >>> My point is that if the option is mandatory for compiling ath(4) driver, >>> then there is no point in having this option in the first place. >>> >> >> Well, fair. >> +1 from me :). >> >> > > So is there a consensus that this seems to break the build for folk who > do not need this option? > If so I can see about committing the necessary changes to turn this > option on by default. I needed the option for what I was trying to do. > > Of course if someone already has a patch for that, that will help, as I > don't have a lot of free time at the moment but can certainly commit a > quick fix if someone already has one. ru had a change to fix this but decided not to; can't say why. Otherwise there is a better way to fix this which I alluded to in previous mail--use the config-generated #define that is generated for the "ath_hal" device. As I said I've not had time to look at that won't probably for several weeks. Either way this requirement has been listed in UPDATING ever since the ath hal source code was imported into the tree. 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"
Re: kernel compile fails without AH_SUPPORT_AR5416
Maxim Sobolev wrote: Dennis Melentyev wrote: Could be worth an entry in UPDATING and/or explicitly added to GENERIC. My point is that if the option is mandatory for compiling ath(4) driver, then there is no point in having this option in the first place. There is an entry in UPDATING and it is present in GENERIC (in HEAD, I didn't commit the changes to RELENG_7 so don't know). When the ath hal src code was imported the meaning of the ath_hal device changed because internal configuration done during binary builds was now exposed. Specifically, the need for AH_SUPPORT_5416 to enable support for the extended descriptor format used by the 11n parts. If you read ath_hal(4) this should be clear--if not please help improve the manual page. However, it so happens you can eliminate this option because config will generate a #define you can use instead to identify the configuration of "ath_hal" but this magic is undocumented and I didn't know about it until ru recently told me. I suggested he go ahead and fixup the code to use it but haven't seen anything. I don't have time right now. 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"
Re: ural driver stalls under FreeBSD7.1
Bengt Ahlgren wrote: Weongyo Jeong writes: On Thu, Feb 26, 2009 at 06:04:17PM -0800, Sam Leffler wrote: Bengt Ahlgren wrote: Weongyo Jeong writes: On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote: I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor. It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1 Typically, It works for a while until eventually it stalls data transfers completely. It always seems to do this after an unspecified amount of time. I know the hardware isn't at fault because the device works fine under Linux. Could you please check that `ifconfig -bgscan' disabling the background scan helps your symptom? The above sounds like the same problem as this: http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011376.html http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html The problem is in the background scanning logic in sys/net80211. I don't see how you come to this conclusion. ural is a totally different driver than ath and so far as I can recall you never found the cause for your problem w/ ath. Most of the usb wireless drivers do a haphazard job of synchronizing async tasks like bg scan with the foreground tx/rx processing. This can lead to firmware and/or usb issues. ath does not have these issues but I am aware of at least one problem w/ bg scanning in ath under RELENG_7 (that is not present in HEAD). I agree with sam because I saw some cases like stalls during background scanning that most of them I think it's caused by H/W miss-operation or miss-configuration by mistakes of driver. Looking into if_ural (1.69.6.1 - 7.1R version), it partly has the same calls to net80211 which causes problems for ath. At line 1477, it has the same test as ath has to check for bg scanning: if (ic->ic_flags & IEEE80211_F_SCAN) ieee80211_cancel_scan(ic); That means that ieee80211_cancel_scan won't be called in the window between when scan_next is run (which resets IEEE80211_F_SCAN), and ieee80211_bg_scan is called the next time (setting IEEE80211_F_SCAN again). This is the same problem as ath has. But I can't find that ural calls ieee80211_pwrsave to queue packets if a bgscan was running. It seems that it just merrily tries to send packets despite scanning is going on. Please note that even though ieee80211_cancel_scan IS called, that won't take effect until the next clock tick. So if the output routine just carries on with sending a packet, it will do so in the middle of the scan. This is something that should be fixed in net80211. So, I find that ural also suffers from the problem with the scanning logic in net80211. It appears RELENG_7's scanning code lacks the locking that's in HEAD to guard against the race you describe. 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"
Re: ural driver stalls under FreeBSD7.1
Bengt Ahlgren wrote: Weongyo Jeong writes: On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote: I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor. It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1 Typically, It works for a while until eventually it stalls data transfers completely. It always seems to do this after an unspecified amount of time. I know the hardware isn't at fault because the device works fine under Linux. Could you please check that `ifconfig -bgscan' disabling the background scan helps your symptom? The above sounds like the same problem as this: http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011376.html http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html The problem is in the background scanning logic in sys/net80211. I don't see how you come to this conclusion. ural is a totally different driver than ath and so far as I can recall you never found the cause for your problem w/ ath. Most of the usb wireless drivers do a haphazard job of synchronizing async tasks like bg scan with the foreground tx/rx processing. This can lead to firmware and/or usb issues. ath does not have these issues but I am aware of at least one problem w/ bg scanning in ath under RELENG_7 (that is not present in HEAD). 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"
Re: Recommended wireless card (or is there a chance to get either iwi or ath fixed)?
Chris Rees wrote: 2009/2/25 Paul B. Mahol : On 2/24/09, SDH Support wrote: I tried using my ath based D-Link DWL G650, which still seems to have some issues in regard to interrupt handling: I've been able to get /most/ wireless cards working with ndiswrapper. *BSD doesnt have ndiswrapper. -- Paul ___ 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" Yeah it does... [ch...@amnesiac]~% ndisgen == -- Windows(r) driver converter --- == This script is designed to guide you through the process of converting a Windows(r) binary driver module and .INF specification file into a FreeBSD ELF kernel module for use with the NDIS compatibility system. The following options are available: 1] Learn about the NDIS compatibility system 2] Convert individual firmware files 3] Convert driver 4] Exit Enter your selection here and press return: "ndiswrapper" refers to the linux version of the Bill Paul's project for freebsd. They are very different; though have the same goal. 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"
Re: Unhappy Xorg upgrade
I've just upgraded to the latest xorg on my amd64 box 7.1-STABLE FreeBSD 7.1-STABLE #0: Fri Jan 16 07:33:20 PST 2009 I have a radeon graphics card, drm0: on vgapci0 - had to add the option mentioned in UPDATING Section "ServerLayout" Option "AllowEmptyInput" "off" ... Things seem mostly running on my box, though there are many of these emacs Xlib: extension "Generic Event Extension" missing on display ":0.0". ... I now see that ssh into a remote host (solaris 10 sparc), running emacs there pops up a window, but then typing anything into the window kills it, with X protocol error: BadAlloc (insufficient resources for operation) on protocol request 149 (on the remote machine). xv works ok. This doesn't happen if the remote host is linux rh4... This didn't happen before the xorg upgrade. Seems to be some sort of incompatibility in X11. Any ideas? Sam Sirlin ___ 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"
Re: CFT: ath hal src switchover
Bengt Ahlgren wrote: Uwe Laverenz writes: Sam Leffler schrieb: those changes. To do this you must have an up to date RELENG_7 code base and then apply this patch: http://people.freebsd.org/~sam/ath_hal-releng7.patch Then rebuild your kernel. There should be no changes to user apps. I tested this on a Thinkpad R51 / RELENG_7 / Atheros 5212 and I see no problems with the patch. It builds and runs fine and doesn't seem to do anything harmful. :) I have a problem with this machine though (with or without your patch): the wireless connection seems to be stalled every few minutes. If I try to send some traffic over ath0 or make wpa_cli reconnect it comes back for another few minutes. The only cure for now seems to be "ifconfig ath0 -bgscan". That sounds like it can be the same symptoms as I described on the freebsd-mobile list earlier this week: http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html What clockrate do you run at? On my system (Thinkpad X40, Atheros 5212) the problem does not occur at kern.hz=1000, but it is present at kern.hz=100. Tomorrow evening I will investigate this further including testing if "ifconfig ath0 -bgscan" makes a difference for me. There are many many changes to the ath driver in head that are not in stable. If I can get confidence in the hal backport I can try to bring back some of those. But I need to do things in the proper order; I can't backmerge a bunch of stuff, find something is broken, and then have to bisect changes. So people need to help get the hal code in place first. 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"
Re: iwn driver on 7.1 [no vaps in RELENG_7]
Jan Henrik Sylvester wrote: Torfinn Ingolfsen wrote: On Sun, 18 Jan 2009 14:17:39 -0600 Brandon Gooch wrote: I have a working driver for the Intel 4965, aka iwn(4), loaded on my Lenovo X300 running FreeBSD 7.1-RELEASE (amd64). FWIW, I am using the latest perforce version of the iwn driver as documented here[1] on a ThinkPad T61 running FreeBSD 7.1-stable / i386 - no modifications necessary. It works great. I just use the p4fetch.rb script to get the driver. HTH References: 1) http://clearchain.com/wiki/iwn Since from that address, you are using the latest version of the benjsc perforce branch, you are probably using the same as I, since I took the initial version from the sam_vap branch (before vap got introduced). I do not know how far it is, but there is vap_releng7 in the sam perforce and projects/vap7 in svn on which Sam Leffler is actively working: http://lists.freebsd.org/pipermail/svn-src-projects/2009-January/thread.html I would like to have if_iwn working on a otherwise unmodified 7.1-RELEASE-pX and help to test it, but maybe waiting on sam to bring vap to 7 would be a better way to go. vaps will never be committed to RELENG_7 due to API/ABI constraints. However that svn branch is operational and being maintained as it's used by multiple people. I considered bringing back iwn (it's just copying the bits); will add it to my TODO list. OTOH iwn is now out of date and someone needs to update it. There's newer firmware that is supposed to fix many of the bugs I hit when I worked on the driver (and Intel refused to acknowledge) and obsd has added support for newer parts that people want. It'd be great if someone wanted to take over this driver. 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"
HEADS UP: build changes
r187106 syncs the Makefiles with HEAD so that RELENG_7 has the same set of build knobs. Let me know if you see any oddities that you can trace to this commit. 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"
CFT: ath hal src switchover
I've brought the hal source code back to RELENG_7 but not connected it to the build and/or driver. I want folks to test this before I commit those changes. To do this you must have an up to date RELENG_7 code base and then apply this patch: http://people.freebsd.org/~sam/ath_hal-releng7.patch Then rebuild your kernel. There should be no changes to user apps. Beware however that custom kernel configurations will need to change; instead of: device ath device ath_hal device ath_rate_sample (or similar) you need: device ath device ath_hal options AH_SUPPORT_AR5416 device ath_rate_sample If you want to configure a subset of the chip support implied by ath_hal then you may not need the options line. If you are using modules note that ath_hal and ath_rate_* modules no longer exist; they are now rolled into the ath module. If you use a rate control algorithm other than sample then you'll need to modify the ath module build or override by specifying ATH_RATE; e.g. cd sys/modules/ath make ATH_RATE=onoe The updated hal code adds support for several parts but otherwise makes no effort to address driver bugs. You should see no regressions relative to operation w/ the older hal. If you are running the 7.1 release you will need to import the hal code that is now in sys/dev/ath/ath_hal before following the above instructions. I have no idea if this will work for an earlier version of FreeBSD; if you're not running at least 7.1 my advise is to upgrade. Please report any issues to this mailing list. 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"
Re: [Fwd: Re: kern/123552: [ath] [panic] kernel panic during network activity on ath0]
Sean C. Farley wrote: On Fri, 21 Nov 2008, Sam Leffler wrote: Folks having problems with ath on releng7 should try the attached patch. It fixed the panic when SuperG was activated on the wireless router for me. Thank you! Guy Coleman gets any credit; I just recognized what the root cause was. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[Fwd: Re: kern/123552: [ath] [panic] kernel panic during network activity on ath0]
Folks having problems with ath on releng7 should try the attached patch.
Sam
Index: ieee80211_freebsd.h
===
RCS file: /usr/ncvs/src/sys/net80211/ieee80211_freebsd.h,v
retrieving revision 1.15.2.1
diff -u -r1.15.2.1 ieee80211_freebsd.h
--- ieee80211_freebsd.h 11 Nov 2007 17:44:35 - 1.15.2.1
+++ ieee80211_freebsd.h 21 Nov 2008 03:32:42 -
@@ -197,9 +197,10 @@
#defineM_LINK0 M_PROTO1/* WEP requested */
#defineM_PWR_SAV M_PROTO4/* bypass PS handling */
#defineM_MORE_DATA M_PROTO5/* more data frames to
follow */
-#defineM_FF0x2 /* fast frame */
-#defineM_TXCB 0x4 /* do tx complete
callback */
-#defineM_80211_TX
(0x6|M_PROTO1|M_WME_AC_MASK|M_PROTO4|M_PROTO5)
+#defineM_FFM_PROTO6/* fast frame */
+#defineM_TXCB M_PROTO7/* do tx complete
callback */
+#defineM_80211_TX \
+ (M_LINK0|M_WME_AC_MASK|M_PWR_SAV|M_MORE_DATA|M_FF|M_TXCB)
/* rx path usage */
#defineM_AMPDU M_PROTO1/* A-MPDU processing
done */
--- Begin Message ---
Here is the reason in net80211/ieee80211_freebsd.h:
/* tx path usage */
#define M_LINK0 M_PROTO1/* WEP requested */
#define M_PWR_SAV M_PROTO4/* bypass PS handling */
#define M_MORE_DATA M_PROTO5/* more data frames to
follow */
#define M_FF0x2 /* fast frame */
#define M_TXCB 0x4 /* do tx complete
callback */
#define M_80211_TX (0x6|M_PROTO1|M_WME_AC_MASK|M_PROTO4|M_PROTO5)
M_FF and M_TXCB overlay M_PROMISC and M_NOFREE. Please try reverting
your change and then set M_FF to M_PROTO6 and M_TXCB M_PROTO7.
Sam
Guy Coleman wrote:
The following reply was made to PR kern/123552; it has been noted by GNATS.
From: Guy Coleman <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Subject: Re: kern/123552: [ath] [panic] kernel panic during network activity
on ath0
Date: Thu, 20 Nov 2008 21:51:37 +
I've found that partially reverting revs 1.181.2.2 and 1.181.2.4 of
sys/net/bpf.c stops the panic from happening. I have no idea why.
--- bpf.c.bak 2008-11-09 19:46:55.0 +
+++ bpf.c 2008-11-16 22:37:10.0 +
@@ -85,6 +85,8 @@
#define PRINET 26 /* interruptible */
+#define M_SKIP_BPF M_SKIP_FIREWALL
+
/*
* bpf_iflist is a list of BPF interface structures, each
corresponding to a
* specific DLT. The same network interface might have several BPF
interface
@@ -653,7 +655,7 @@
mc->m_pkthdr.rcvif = ifp;
/* Set M_PROMISC for outgoing packets to be discarded. */
if (d->bd_direction == BPF_D_INOUT)
- m->m_flags |= M_PROMISC;
+ m->m_flags |= M_SKIP_BPF;
} else
mc = NULL;
@@ -1358,9 +1360,8 @@
int gottime;
struct timeval tv;
- /* Skip outgoing duplicate packets. */
- if ((m->m_flags & M_PROMISC) != 0 && m->m_pkthdr.rcvif == NULL) {
- m->m_flags &= ~M_PROMISC;
+ if (m->m_flags & M_SKIP_BPF) {
+ m->m_flags &= ~M_SKIP_BPF;
return;
}
@@ -1413,9 +1414,8 @@
int gottime;
struct timeval tv;
- /* Skip outgoing duplicate packets. */
- if ((m->m_flags & M_PROMISC) != 0 && m->m_pkthdr.rcvif == NULL) {
- m->m_flags &= ~M_PROMISC;
+ if (m->m_flags & M_SKIP_BPF) {
+ m->m_flags &= ~M_SKIP_BPF;
return;
}
--- End Message ---
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What is cryptosoft0?
Ulrich Spoerlein wrote: Hi, today I discovered the following dmesg line on my laptop: cryptosoft0: on motherboard and I've not seen this one before, so: what is cryptosoft and should I care? I could imagine it's a pseudo-device by crypto(9) so the API is the same whether crypto hardware is installed or not. Anyway, I think a manpage link/update would be in order: % man -k cryptosoft cryptosoft: nothing appropriate It is what you suggest; a device associated with s/w crypto support. It was created so crypto requests can be submitted specifically to it (instead of a h/w device). This is currently used only for testing but the intent was also to use it when doing load-balancing and similar work. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: busybox and small scripting languages on FreeBSD ? (was Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?)
Luigi Rizzo wrote: On Sat, Aug 02, 2008 at 11:39:20AM -0700, Sam Leffler wrote: ... I've been looking at nanobsd for a couple of applications and working to reduce the footprint of the images without hacking special rules. With ... If we're ever to consider building images for flash parts (not compact flash) then we'll need to do a lot of work to pare down the bloat--or replace current apps w/ special purpose replacements a la busybox (not something I find appealing). related to this thread -- does anyone have experience in trying to build busybox on FreeBSD ? My last experience w/ busybox was >1 year ago and I'm not sure I was using anything close to up to date, but...it was utterly linux-specific. Given what it does and what I saw in the code I'd be more inclined to write one from scratch. But having said that I'm not really sure it's worthwhile; I think I'd rather put effort into putting some of the existing tools on a diet (possibly under #ifdefs) and then use crunchgen. I'm pretty sure you'd come up with something higher quality and with a similar footprint. Also, what would you suggest as a small scripting language to be used in this kind of platform for implementing CGI scripts (and preferably able to use sockets/select) ? The various perl/python/php and friend are in the 10MB range once you pick up a little bit of libraries (sockets etc) and the tangle of modules they require; awk (which is present in busybox) is ok-ish for some things, but doing I/O and calling external programs with it is very unfriendly; javascript/spidermonkey is on the 500KB range but it doesn't have a library to play with sockets... Not sure about scripting languages but what's really needed is a lightweight http solution that supports ssl. This can go a long way before you get to php et. al. My last project of this sort used tinyhttp (I think, whichever one Jeff Pozkanzer did) and php. But we didn't try to fit in flash, we used compact flash parts. I think tinyhttpd+php is also what m0n0wall and pfsense use but haven't looked in a while. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?
M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> fbsd2 <[EMAIL PROTECTED]> writes: : Greetings list, : :Given recent EOL announcements, I'm trying to upgrade an ancient machine from 5.5 to 7. It has 80 Mb total in the root partition, /home/, /var/, /usr/, and /tmp/ on other partitions, and NFS mounts /usr/src, /usr/obj, and /usr/ports from a slightly newer/faster box. I've seen : : http://www.freebsd.org/releases/7.0R/relnotes.html and : http://marc.info/?l=freebsd-stable&m=121278826119286&w=2 : : which seem to suggest that even with INSTALL_NODEBUG during buildkernel, 7 might not fit in an 80 Mb /. Must I partition a new disk to give more space to /, or can I find more space by deleting /stand/, /modules/, and possibly /rescue/ to shoehorn a custom 7.x kernel in the available space? TIA Doesn't look like anybody has answered this question... 80MB is plenty, even for 7.x. However, you'll have to use nanobsd or tinybsd to get that small. You'll likely been unable to do a 'make installworld' to get this size. You'll have to create an image and push it over to this machine somehow. In the 3.x time frame, I had FreeBSD booting with the standard scripts in 13MB without compression. 4.x, 5.x and 6.x bloated these binaries to about 18MB (a few more were added). I haven't built a system based on 7.x with this system due to a change in employment, but expect that it wouldn't be much larger than 20MB for these same files. Some careful honing could reduce that a little, but maybe not a lot. Typical embedded systems that I shipped were on the order of 24MB without X11 and 32-60MB for those with an X11 server. What's this box used for? I've been looking at nanobsd for a couple of applications and working to reduce the footprint of the images without hacking special rules. With the existing set of WITHOUT knobs in the build system you get a 48M image. With my additional knobs I have this down to 24M. There are still numerous bits of junk that must be removed with special rules unless I go the complete route and add WITHOUT knobs for just about everything. I'd much prefer an opt-in configuration scheme but wasn't keen on what I see in existing packaging systems. Like you I have my own packaging system (works on HEAD and RELENG_[4567] though stuff <7 is probably rotted) but hope to move away from it. In the long run I doubt nanobsd will work for a true embedded application (with my private tools my current RELENG_7 firewall is 10M and includes bind+dhcpd). The other area that I hope to improve on in nanobsd is build time. At the moment you're required to build a bunch of stuff just to throw it away. This is unacceptable with our current build times being so long. My main motivation for improving nanobsd is to offer it as a way to package embedded cross-builds. I've got examples to cross-build images for the AVILA board (it's trivial and I'm sure can be done by other systems like tinybsd so long as they use the buildworld infrastructure). To get past the current 24M barrier I'll need to attack individual applications. For example bind is currently huge and ancillary tools like dig are almost as big! I haven't looked at why but for my current firewall I crunchgen bind and related tools into an image together w/ various other bits. If we're ever to consider building images for flash parts (not compact flash) then we'll need to do a lot of work to pare down the bloat--or replace current apps w/ special purpose replacements a la busybox (not something I find appealing). Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7
Alexandre "Sunny" Kovalenko wrote: On Sun, 2008-07-13 at 11:21 +0200, Martin wrote: Hi Sam, do you know if there is anything done about cbb(4)? I have many wireless adapters with ath(4), but only the one based on PCMCIA is making problems on FreeBSD. I cannot boot my notebook with the device inserted into the port, or it will render the system unusable (100% load on cbb(4)). And all I can see is the following: Jul 12 14:58:39 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:40 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 Jul 12 14:58:41 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 Jul 12 14:58:42 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:43 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:44 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 Jul 12 14:58:45 link kernel: ath0: ath_chan_set: unable to reset channel 5 (2432 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:45 link kernel: ath0: ath_chan_set: unable to reset channel 8 (2447 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:46 link kernel: ath0: ath_chan_set: unable to reset channel 9 (2452 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:47 link kernel: ath0: ath_chan_set: unable to reset channel 10 (2457 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:52 link kernel: ath0: device timeout Jul 12 14:58:52 link kernel: ath0: ath_reset: unable to reset hardware; hal status 3231908395 Jul 12 14:58:58 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 Jul 12 14:58:59 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:00 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:01 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:01 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 3289233408 Jul 12 14:59:02 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:03 link kernel: ath0: ath_chan_set: unable to reset channel 5 (2432 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:04 link kernel: ath0: ath_chan_set: unable to reset channel 8 (2447 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:05 link kernel: ath0: ath_chan_set: unable to reset channel 9 (2452 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:06 link kernel: ath0: ath_chan_set: unable to reset channel 10 (2457 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:10 link kernel: ath0: device timeout Jul 12 14:59:10 link kernel: ath0: ath_reset: unable to reset hardware; hal status 3231908395 Jul 12 14:59:11 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 Jul 12 14:59:12 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:13 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 Jul 12 14:59:14 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:15 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:16 link kernel: ath0: unable to reset hardware; hal status 3868687084 Jul 12 14:59:16 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:17 link kernel: ath0: ath_chan_set: unable to reset channel 11 (2462 Mhz, flags 0x480 hal flags 0xc0), hal status 3828804624 Jul 12 14:59:22 link kernel: ath0: unable to reset hardware; hal status 3868539700 Jul 12 14:59:32 link kernel: ath0: unable to reset hardware; hal status 3868539700 Jul 12 14:59:42 link kernel: ath0: unable to reset hardware; hal status 3868539700 Jul 12 15:00:22 link last message repeated 4 times Jul 12 15:00:32 link kernel: ath0: unable to reset hardware; hal status 3868539700 Jul 12 15:00:42 link kernel: ath0: unable to reset hardware; hal status 3868539700 Jul 12 15:00:52 link kernel: ath0: unable to reset hardware; hal status 3868539700 wpa_supplicant is trying to access the card and switching channels, I s
Re: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7
Martin wrote: Hi Sam, do you know if there is anything done about cbb(4)? I have many wireless adapters with ath(4), but only the one based on PCMCIA is making problems on FreeBSD. I cannot boot my notebook with the device inserted into the port, or it will render the system unusable (100% load on cbb(4)). And all I can see is the following: Jul 12 14:58:39 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:40 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 Jul 12 14:58:41 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 Jul 12 14:58:42 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:43 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:44 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 Jul 12 14:58:45 link kernel: ath0: ath_chan_set: unable to reset channel 5 (2432 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:45 link kernel: ath0: ath_chan_set: unable to reset channel 8 (2447 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:46 link kernel: ath0: ath_chan_set: unable to reset channel 9 (2452 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:47 link kernel: ath0: ath_chan_set: unable to reset channel 10 (2457 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:52 link kernel: ath0: device timeout Jul 12 14:58:52 link kernel: ath0: ath_reset: unable to reset hardware; hal status 3231908395 Jul 12 14:58:58 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 Jul 12 14:58:59 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:00 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:01 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:01 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 3289233408 Jul 12 14:59:02 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:03 link kernel: ath0: ath_chan_set: unable to reset channel 5 (2432 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:04 link kernel: ath0: ath_chan_set: unable to reset channel 8 (2447 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:05 link kernel: ath0: ath_chan_set: unable to reset channel 9 (2452 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:06 link kernel: ath0: ath_chan_set: unable to reset channel 10 (2457 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:10 link kernel: ath0: device timeout Jul 12 14:59:10 link kernel: ath0: ath_reset: unable to reset hardware; hal status 3231908395 Jul 12 14:59:11 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 Jul 12 14:59:12 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:13 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 Jul 12 14:59:14 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:15 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:16 link kernel: ath0: unable to reset hardware; hal status 3868687084 Jul 12 14:59:16 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:17 link kernel: ath0: ath_chan_set: unable to reset channel 11 (2462 Mhz, flags 0x480 hal flags 0xc0), hal status 3828804624 Jul 12 14:59:22 link kernel: ath0: unable to reset hardware; hal status 3868539700 Jul 12 14:59:32 link kernel: ath0: unable to reset hardware; hal status 3868539700 Jul 12 14:59:42 link kernel: ath0: unable to reset hardware; hal status 3868539700 Jul 12 15:00:22 link last message repeated 4 times Jul 12 15:00:32 link kernel: ath0: unable to reset hardware; hal status 3868539700 Jul 12 15:00:42 link kernel: ath0: unable to reset hardware; hal status 3868539700 Jul 12 15:00:52 link kernel: ath0: unable to reset hardware; hal status 3868539700 wpa_supplicant is trying to access the card and switching channels, I suppose. A workaround that I'm using all the time is: 1) boot the notebook withou
Re: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7
Alexandre "Sunny" Kovalenko wrote:
On Sat, 2008-07-12 at 09:57 -0700, Sam Leffler wrote:
Alexandre "Sunny" Kovalenko wrote:
On Fri, 2008-07-11 at 20:29 -0700, Sam Leffler wrote:
Alexandre "Sunny" Kovalenko wrote:
On Fri, 2008-05-16 at 12:23 -0400, Sam Leffler wrote:
Alexandre "Sunny" Kovalenko wrote:
On Mon, 2008-05-12 at 19:33 -0700, Sam Leffler wrote:
Alexandre "Sunny" Kovalenko wrote:
I seem to be able to lock my machine by going into wpa_cli and asking it
to 'reassoc'. The reason for question mark after "hard" is that debug
information (caused by wlandebug and athdebug) is being printed on the
console. The only way to get machine's attention is to hold power button
for 8 seconds.
So this is just livelock due to console debug msgs.
I am not sure, I have parsed this well enough, so I will try to clarify:
machine becomes unresponsive *without* any debugging turned on, to an
extent that pressing the power button twice *does not* generate ACPI
console message (something to the tune of "going into S5 already --
gimme a break"). If I turn ath debugging on, I do see those messages,
and only them, scrolling on the console.
Guess I misunderstood you.
I have finally got enough time and equipment to investigate this
further. Here are some conclusions:
-- at this point (RELENG_7 as of July 9th around 15:30 EST) it is indeed
a livelock.
-- all system does, is executing ath_intr (if_ath.c) in the tight loop
with the same status -- 0x1000 AKA HAL_INT_MIB. In order to eliminate
possibility that I have caused livelock with the debug messages, I have
put conditional panic() into ath_intr, as soon as sc->sc_stats.ast_mib
reaches 10,000. Without any kind of the debug messages, it will be
triggered within 40-60 seconds after starting of wpa_supplicant.
-- I suspect that comment below, might not hold true on my equipment
if (status & HAL_INT_MIB) {
sc->sc_stats.ast_mib++;
/*
* Disable interrupts until we service the MIB
* interrupt; otherwise it will continue to fire.
*/
ath_hal_intrset(ah, 0);
/*
* Let the hal handle the event. We assume it will <
* clear whatever condition caused the interrupt. <
*/
ath_hal_mibevent(ah, &sc->sc_halstats);
ath_hal_intrset(ah, sc->sc_imask);
}
My hardware is:
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413,
RF5413)
ath0: mem 0xedf0-0xedf0 irq 17 at device 0.0 on
pci3
ath0: [ITHREAD]
ath0: using obsoleted if_watchdog interface
ath0: Ethernet address: 00:16:cf:26:2f:3f
ath0: mac 10.3 phy 6.1 radio 10.2
My wpa_supplicant.conf is:
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
eapol_version=2
network={
ssid="XXX"
scan_ssid=1
priority=1
proto=WPA
pairwise=TKIP
group=TKIP
key_mgmt=WPA-PSK
psk="xx"
}
Access point is Netgear WNDR3300-1B with 11N and 11G SSID set up to
different values. Only 11G SSID is configured in wpa_supplicant.conf. In
the test setup, AP is with 10' (3m) from the laptop.
AP is successfully used by handful of Windows clients (including this
same laptop) and iBook G4.
Neither wpa_supplicant with '-d -d' nor wlandebug 0x show
anything but normal scan.
athdebug 0x loops with ath_intr: status 0x1000 until I power
down my laptop.
I would appreciate any suggestion on what I can investigate further --
at this point I have comfortable console setup and should be able to
field requests for further information much better.
Are you running powerd?
I do. And I just tried disabling it, and I could not reproduce the
problem any more. Is there any way to reconcile if_ath with powerd?
Don't know. There appear to be two issues. When the MIB interrupts
arrive the kernel may service them w/ the cpu at a reduced clock
frequency. Since powered is currently the only mechanism for increasing
the frequency and it runs in user space it can take a while to bump the
clock rate leading to livelock (because the logic to reduce the _cause_
of the MIB interrupt takes a long time to run). John Baldwin suggested
raising the clock frequency when handling interrupts in the kernel but
nothing has been done to make that happen.
Separately there is a question as to why the MIB interrupts are
happening at all. This is possibly due to misprogramming of the
baseband h/w in the ath card. Unfortunately I've been trying to get
Atheros to help understand/resolve this question for a very long time
(as their code also exhibits this behaviour) but they've been
unre
Re: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7
Alexandre "Sunny" Kovalenko wrote:
On Fri, 2008-07-11 at 20:29 -0700, Sam Leffler wrote:
Alexandre "Sunny" Kovalenko wrote:
On Fri, 2008-05-16 at 12:23 -0400, Sam Leffler wrote:
Alexandre "Sunny" Kovalenko wrote:
On Mon, 2008-05-12 at 19:33 -0700, Sam Leffler wrote:
Alexandre "Sunny" Kovalenko wrote:
I seem to be able to lock my machine by going into wpa_cli and asking it
to 'reassoc'. The reason for question mark after "hard" is that debug
information (caused by wlandebug and athdebug) is being printed on the
console. The only way to get machine's attention is to hold power button
for 8 seconds.
So this is just livelock due to console debug msgs.
I am not sure, I have parsed this well enough, so I will try to clarify:
machine becomes unresponsive *without* any debugging turned on, to an
extent that pressing the power button twice *does not* generate ACPI
console message (something to the tune of "going into S5 already --
gimme a break"). If I turn ath debugging on, I do see those messages,
and only them, scrolling on the console.
Guess I misunderstood you.
I have finally got enough time and equipment to investigate this
further. Here are some conclusions:
-- at this point (RELENG_7 as of July 9th around 15:30 EST) it is indeed
a livelock.
-- all system does, is executing ath_intr (if_ath.c) in the tight loop
with the same status -- 0x1000 AKA HAL_INT_MIB. In order to eliminate
possibility that I have caused livelock with the debug messages, I have
put conditional panic() into ath_intr, as soon as sc->sc_stats.ast_mib
reaches 10,000. Without any kind of the debug messages, it will be
triggered within 40-60 seconds after starting of wpa_supplicant.
-- I suspect that comment below, might not hold true on my equipment
if (status & HAL_INT_MIB) {
sc->sc_stats.ast_mib++;
/*
* Disable interrupts until we service the MIB
* interrupt; otherwise it will continue to fire.
*/
ath_hal_intrset(ah, 0);
/*
* Let the hal handle the event. We assume it will <
* clear whatever condition caused the interrupt. <
*/
ath_hal_mibevent(ah, &sc->sc_halstats);
ath_hal_intrset(ah, sc->sc_imask);
}
My hardware is:
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413,
RF5413)
ath0: mem 0xedf0-0xedf0 irq 17 at device 0.0 on
pci3
ath0: [ITHREAD]
ath0: using obsoleted if_watchdog interface
ath0: Ethernet address: 00:16:cf:26:2f:3f
ath0: mac 10.3 phy 6.1 radio 10.2
My wpa_supplicant.conf is:
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
eapol_version=2
network={
ssid="XXX"
scan_ssid=1
priority=1
proto=WPA
pairwise=TKIP
group=TKIP
key_mgmt=WPA-PSK
psk="xx"
}
Access point is Netgear WNDR3300-1B with 11N and 11G SSID set up to
different values. Only 11G SSID is configured in wpa_supplicant.conf. In
the test setup, AP is with 10' (3m) from the laptop.
AP is successfully used by handful of Windows clients (including this
same laptop) and iBook G4.
Neither wpa_supplicant with '-d -d' nor wlandebug 0x show
anything but normal scan.
athdebug 0x loops with ath_intr: status 0x1000 until I power
down my laptop.
I would appreciate any suggestion on what I can investigate further --
at this point I have comfortable console setup and should be able to
field requests for further information much better.
Are you running powerd?
I do. And I just tried disabling it, and I could not reproduce the
problem any more. Is there any way to reconcile if_ath with powerd?
Don't know. There appear to be two issues. When the MIB interrupts
arrive the kernel may service them w/ the cpu at a reduced clock
frequency. Since powered is currently the only mechanism for increasing
the frequency and it runs in user space it can take a while to bump the
clock rate leading to livelock (because the logic to reduce the _cause_
of the MIB interrupt takes a long time to run). John Baldwin suggested
raising the clock frequency when handling interrupts in the kernel but
nothing has been done to make that happen.
Separately there is a question as to why the MIB interrupts are
happening at all. This is possibly due to misprogramming of the
baseband h/w in the ath card. Unfortunately I've been trying to get
Atheros to help understand/resolve this question for a very long time
(as their code also exhibits this behaviour) but they've been
unresponsive. I have some experimental code to address this in new hal
versions (such as 0.10.5.6 available in http://www.freebsd.org/~sam) but
apparently it does not entirely fix the problem.
Sam
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7
Alexandre "Sunny" Kovalenko wrote:
On Fri, 2008-05-16 at 12:23 -0400, Sam Leffler wrote:
Alexandre "Sunny" Kovalenko wrote:
On Mon, 2008-05-12 at 19:33 -0700, Sam Leffler wrote:
Alexandre "Sunny" Kovalenko wrote:
I seem to be able to lock my machine by going into wpa_cli and asking it
to 'reassoc'. The reason for question mark after "hard" is that debug
information (caused by wlandebug and athdebug) is being printed on the
console. The only way to get machine's attention is to hold power button
for 8 seconds.
So this is just livelock due to console debug msgs.
I am not sure, I have parsed this well enough, so I will try to clarify:
machine becomes unresponsive *without* any debugging turned on, to an
extent that pressing the power button twice *does not* generate ACPI
console message (something to the tune of "going into S5 already --
gimme a break"). If I turn ath debugging on, I do see those messages,
and only them, scrolling on the console.
Guess I misunderstood you.
I have finally got enough time and equipment to investigate this
further. Here are some conclusions:
-- at this point (RELENG_7 as of July 9th around 15:30 EST) it is indeed
a livelock.
-- all system does, is executing ath_intr (if_ath.c) in the tight loop
with the same status -- 0x1000 AKA HAL_INT_MIB. In order to eliminate
possibility that I have caused livelock with the debug messages, I have
put conditional panic() into ath_intr, as soon as sc->sc_stats.ast_mib
reaches 10,000. Without any kind of the debug messages, it will be
triggered within 40-60 seconds after starting of wpa_supplicant.
-- I suspect that comment below, might not hold true on my equipment
if (status & HAL_INT_MIB) {
sc->sc_stats.ast_mib++;
/*
* Disable interrupts until we service the MIB
* interrupt; otherwise it will continue to fire.
*/
ath_hal_intrset(ah, 0);
/*
* Let the hal handle the event. We assume it will <
* clear whatever condition caused the interrupt. <
*/
ath_hal_mibevent(ah, &sc->sc_halstats);
ath_hal_intrset(ah, sc->sc_imask);
}
My hardware is:
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413,
RF5413)
ath0: mem 0xedf0-0xedf0 irq 17 at device 0.0 on
pci3
ath0: [ITHREAD]
ath0: using obsoleted if_watchdog interface
ath0: Ethernet address: 00:16:cf:26:2f:3f
ath0: mac 10.3 phy 6.1 radio 10.2
My wpa_supplicant.conf is:
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
eapol_version=2
network={
ssid="XXX"
scan_ssid=1
priority=1
proto=WPA
pairwise=TKIP
group=TKIP
key_mgmt=WPA-PSK
psk="xx"
}
Access point is Netgear WNDR3300-1B with 11N and 11G SSID set up to
different values. Only 11G SSID is configured in wpa_supplicant.conf. In
the test setup, AP is with 10' (3m) from the laptop.
AP is successfully used by handful of Windows clients (including this
same laptop) and iBook G4.
Neither wpa_supplicant with '-d -d' nor wlandebug 0x show
anything but normal scan.
athdebug 0x loops with ath_intr: status 0x1000 until I power
down my laptop.
I would appreciate any suggestion on what I can investigate further --
at this point I have comfortable console setup and should be able to
field requests for further information much better.
Are you running powerd?
Sam
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Atheros (ath) MSI wireless embedded chipset fails to attach on 7.0-STABLE
Alexander Sack wrote: Hello: I have installed FreeBSD-7.0-amd64 stable on my new AMD X2 Turon based notebook, a MSI-1710A (GX710Ax) which has a generic embedded controller. During boot up I notice that ATH complains with: ath_rate: version 1.2 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xfd7f-0xfd7f irq 16 at device 0.0 on pci2 ath0: Reserved 0x1 bytes for rid 0x10 type 3 at 0xfd7f ath0: [MPSAFE] ath0: [ITHREAD] ath0: unable to attach hardware; HAL status 13 device_attach: ath0 attach returned 6 HAL status 13 from the header file seems to indicate that the 7.0-STABLE driver doesn't support my hardware revision. Here is my pciconf -l output: [EMAIL PROTECTED]:0:0:0:class=0x06 card=0x42cd1462 chip=0x79101002 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:0:2:0:class=0x060400 card=0x42cd1462 chip=0x79131002 rev=0x00 hdr=0x01 [EMAIL PROTECTED]:0:4:0:class=0x060400 card=0x42cd1462 chip=0x79141002 rev=0x00 hdr=0x01 [EMAIL PROTECTED]:0:6:0:class=0x060400 card=0x42cd1462 chip=0x79161002 rev=0x00 hdr=0x01 [EMAIL PROTECTED]:0:7:0:class=0x060400 card=0x42cd1462 chip=0x79171002 rev=0x00 hdr=0x01 [EMAIL PROTECTED]:0:18:0: class=0x01018f card=0x42cd1462 chip=0x43801002 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:0:19:0: class=0x0c0310 card=0x42cd1462 chip=0x43871002 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:0:19:1: class=0x0c0310 card=0x42cd1462 chip=0x43881002 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:0:19:2: class=0x0c0310 card=0x42cd1462 chip=0x43891002 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:0:19:3: class=0x0c0310 card=0x42cd1462 chip=0x438a1002 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:0:19:4: class=0x0c0310 card=0x42cd1462 chip=0x438b1002 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:0:19:5: class=0x0c0320 card=0x42cd1462 chip=0x43861002 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:0:20:0: class=0x0c0500 card=0x42cd1462 chip=0x43851002 rev=0x14 hdr=0x00 [EMAIL PROTECTED]:0:20:1: class=0x01018a card=0x42cd1462 chip=0x438c1002 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:0:20:2: class=0x040300 card=0x42cd1462 chip=0x43831002 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:0:20:3: class=0x060100 card=0x42cd1462 chip=0x438d1002 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:0:20:4: class=0x060401 card=0x chip=0x43841002 rev=0x00 hdr=0x01 [EMAIL PROTECTED]:0:24:0: class=0x06 card=0x chip=0x11001022 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:0:24:1: class=0x06 card=0x chip=0x11011022 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:0:24:2: class=0x06 card=0x chip=0x11021022 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:0:24:3: class=0x06 card=0x chip=0x11031022 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:1:0:0:class=0x03 card=0x42cd1462 chip=0x95811002 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:1:0:1:class=0x040300 card=0xaa081462 chip=0xaa081002 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:2:0:0:class=0x02 card=0x10261a3b chip=0x001c168c rev=0x01 hdr=0x00 [EMAIL PROTECTED]:5:0:0:class=0x02 card=0x42cd1462 chip=0x816810ec rev=0x01 hdr=0x00 [EMAIL PROTECTED]:6:4:0:class=0x060700 card=0x42cd1462 chip=0x71341217 rev=0x21 hdr=0x02 [EMAIL PROTECTED]:6:4:2:class=0x080500 card=0x42cd1462 chip=0x71201217 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:6:4:3:class=0x068000 card=0x42cd1462 chip=0x71301217 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:6:4:4:class=0x0c0010 card=0x42cd1462 chip=0x00f71217 rev=0x02 hdr=0x00 ath0 is listed as rev=0x01 so I'm a little confused why I got HAL status 13. Does anyone know if this chipset is supported in 7.0-STABLE? If not, is it possible to try CURRENT on 7.0 which may fix it? I've attached my complete dmesg output. Again, any feedback would be much appreciated! Try the hal in http://www.freebsd.org/~sam. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7
Alexandre "Sunny" Kovalenko wrote:
On Mon, 2008-05-12 at 19:33 -0700, Sam Leffler wrote:
Alexandre "Sunny" Kovalenko wrote:
I seem to be able to lock my machine by going into wpa_cli and asking it
to 'reassoc'. The reason for question mark after "hard" is that debug
information (caused by wlandebug and athdebug) is being printed on the
console. The only way to get machine's attention is to hold power button
for 8 seconds.
So this is just livelock due to console debug msgs.
I am not sure, I have parsed this well enough, so I will try to clarify:
machine becomes unresponsive *without* any debugging turned on, to an
extent that pressing the power button twice *does not* generate ACPI
console message (something to the tune of "going into S5 already --
gimme a break"). If I turn ath debugging on, I do see those messages,
and only them, scrolling on the console.
Guess I misunderstood you.
Note: manual reassociation is just the handy way to reproduce the
problem -- I have had machine locking up on me the whole day long
completely on its own.
Below are, what I think, relevant pieces of information. If anything is
missing, please, chastise me appropriately and will do my best to
provide. I have rigged firewire console, but am unable to break into the
debugger locally or remotely.
I see no log msgs.
I am sorry -- mailman must have eaten it up -- I have posted them here
now:
http://members.verizon.net/~akovalenko/Misc/reassoc.log.gz
All I see in the log is normal scanning.
While I am on the subject, I would appreciate couple of the
troubleshooting suggestions:
* is there any way to get sysctl dev.ath.0.debug to appear, other then
defining ATH_DEBUG in something like /usr/src/sys/dev/ath/ah_osdep.h?
options ATH_DEBUG
That does not seem to work for if_ath built as the module, sorry for not
being clear in that respect.
If you are build a module then you must edit the Makefile to add the
option. Feel free to provide a patch to improve this situation.
* is there minimal, but still usable mask for athdebug and wlandebug? I
have started with 0x and kept trimming likely high-volume
settings until output slowed down to the reasonable pace.
Why do you want debug msgs from ath? The debug msgs from wlandebug
depend on what you're trying to debug.
Because neither wpa_supplicant (quoted below), nor wlandebug (in the URL
above) gave me the answer -- it looks like we are going into the scan
with the specific SSID in mind and never come back, so I went for the
next level. However, could you, please, clarify that I understood you
correctly -- you *do not* want to see mix of wlandebug and athdebug
messages in the report, and I should turn wlandebug off before turning
athdebug on, right?
wlandebug msgs are typically low duty and can be left enabled when you
add driver-level debug msgs. But I can't see from the log you sent what
is going on. Try reducing the noise by eliminating all the ath debug
msgs; maybe provide one log w/ only wlan msgs and one w/ wlan+ath.
I suggest that when debugging you start from the highest layer and move
downward. If you can't find what you need in a wpa_supplicant log then
turn on msgs in net80211 with wlandebug. If that doesn't tell you what
you need then move to the driver. Blindly turning everything on can
easily livelock your system.
That's what I did -- what I have posted is the end result of the walking
down that chain, and I assumed, possibly incorrectly, that you would
want result of all three to put things in context. I do apologize for
the misunderstanding.
For high volume msgs I often do something
like:
athdebug +intr; sleep 1; athdebug -intr
or
athdebug +intr; read x; athdebug -intr
so a carriage return will disable msgs.
Thank you for the suggestion.
* what facility does wpa_supplicant use, when forced to syslog by -s
switch?
trouble% cd /data/freebsd/head/contrib/wpa_supplicant/
trouble% grep openlog *.c
common.c: openlog("wpa_supplicant", LOG_PID | LOG_NDELAY, LOG_DAEMON);
Thank you, should have done this myself, sorry.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7
Alexandre "Sunny" Kovalenko wrote:
I seem to be able to lock my machine by going into wpa_cli and asking it
to 'reassoc'. The reason for question mark after "hard" is that debug
information (caused by wlandebug and athdebug) is being printed on the
console. The only way to get machine's attention is to hold power button
for 8 seconds.
So this is just livelock due to console debug msgs.
Note: manual reassociation is just the handy way to reproduce the
problem -- I have had machine locking up on me the whole day long
completely on its own.
Below are, what I think, relevant pieces of information. If anything is
missing, please, chastise me appropriately and will do my best to
provide. I have rigged firewire console, but am unable to break into the
debugger locally or remotely.
I see no log msgs.
While I am on the subject, I would appreciate couple of the
troubleshooting suggestions:
* is there any way to get sysctl dev.ath.0.debug to appear, other then
defining ATH_DEBUG in something like /usr/src/sys/dev/ath/ah_osdep.h?
options ATH_DEBUG
* is there minimal, but still usable mask for athdebug and wlandebug? I
have started with 0x and kept trimming likely high-volume
settings until output slowed down to the reasonable pace.
Why do you want debug msgs from ath? The debug msgs from wlandebug
depend on what you're trying to debug.
I suggest that when debugging you start from the highest layer and move
downward. If you can't find what you need in a wpa_supplicant log then
turn on msgs in net80211 with wlandebug. If that doesn't tell you what
you need then move to the driver. Blindly turning everything on can
easily livelock your system. For high volume msgs I often do something
like:
athdebug +intr; sleep 1; athdebug -intr
or
athdebug +intr; read x; athdebug -intr
so a carriage return will disable msgs.
* what facility does wpa_supplicant use, when forced to syslog by -s
switch?
trouble% cd /data/freebsd/head/contrib/wpa_supplicant/
trouble% grep openlog *.c
common.c: openlog("wpa_supplicant", LOG_PID | LOG_NDELAY, LOG_DAEMON);
===
* OS:
RELENG_7 cvsup'ed on May 11th @ 15:30EST, if_ath is loaded as the module
* HW:
[EMAIL PROTECTED]:3:0:0: class=0x02 card=0x058a1014 chip=0x1014168c rev=0x01
hdr=0x00
vendor = 'Atheros Communications Inc.'
device = 'AR5212 Atheros AR5212 802.11abg wireless'
class = network
subclass = ethernet
ath0: mem 0xedf0-0xedf0 irq 17 at device 0.0 on
pci3
ath0: [ITHREAD]
ath0: using obsoleted if_watchdog interface
ath0: Ethernet address: xx:xx:xx:xx:xx:xx
ath0: mac 10.3 phy 6.1 radio 10.2
* Debug settings:
net.wlan.0.debug:
0xdfff<11n,debug,crypto,input,xrate,elemid,node,assoc,auth,scan,output,state,power,dot1x,dot1xsm,radius,raddump,radkeys,wpa,acl,wme,superg,doth,inact,roam,rate>
dev.ath.0.debug:
0xffef8ff0
* Console output (somewhat trimmed) is attached -- last group of
messages keeps repeating until I power down the machine.
* Output of 'wpa_supplicant -Dbsd -iath0 -d -d -K
-c/etc/wpa_supplicant.conf' (hand transcribed) is:
Starting AP scan (specific SSID)
Scan SSID = hexdump_ascii (len = NN)
xx xx xx xx xx xx
* /etc/wpa_supplicant.conf is attached
* Setup: two stations with the identical SSID: Linksys WRT54Gv8 (running
dd-wrt micro) at about 50' and Zyxel P-330W at about 20'.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Some odd behaviour of vmstat and vmtotal...
Alfred Perlstein wrote: * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [080430 18:13] wrote: Howdy, In deploying 7.0 at work we were finding a persistent problem when running "vmstat 1" on systems. The problem shows up as a 10ms "pause" in processing, usually packet stamping and forwarding by a user level process. This is due to the fact that vmstat calls the vmtotal() routine which in turn does a whole lot of locking. The vmtotal call locks and walks the VM object list twice in a mark and sweep operation. So, the question is, "What is the right way to fix this?" I could remove the locking since the O_ACTIVE bit is not used by any other routine besides vmtotal, but I'm not too happy about that. The relevant code can be found in src/sys/vm/vm_meter.c in vmtotal(). Thoughts? Can you _really_ remove the locking? I don't think that would be safe if the list is being manipulated, but I haven't checked. Typically one uses a sentinal to get around such problems. Basically insert a dummy object that no one should touch other than you, then drop the lock periodically and insert it into the list, then resume. net80211 uses a scan generation # to walk it's node lists. No sentinel. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Crash with recent kernel on wireless
Da Rock wrote: On Sat, 2008-04-26 at 11:11 +0400, Vladimir Grebenschikov wrote: On Fri, 2008-04-25 at 18:00 +0200, Roland Smith wrote: On Fri, Apr 25, 2008 at 04:25:14PM +0400, Vladimir Grebenschikov wrote: Hi Recently I've upgraded 7-STABLE: Mar 11 -> Apr 24 Everything was fine until I've tried to configure wireless (ath driver, WPA) It crashes every time after interface becomes UP, (I've seen associated in ifconfig output before crash), but before dhcp finished to get IP. You should use the kernel image with the debugging symbols here. If you build and install a kernel, you get two kernel images on 7.x; 1) /boot/kernel/kernel (your regular kernel) 2) /boot/kernel/kernel.symbols (with the debug symbols) Hm, I've thought before, that it will show back-trace even without debug symbols. Anyway, gdb still complains about "linker_file" and "not as structure pointer" But shows stop point. Not much info here :( cat /var/crash/info.44 Dump header from device /dev/ad0s2b Architecture: i386 Architecture Version: 2 Dump Length: 190091264B (181 MB) Blocksize: 512 Dumptime: Sat Apr 26 10:50:05 2008 Hostname: vbook.fbsd.ru Magic: FreeBSD Kernel Dump Version String: FreeBSD 7.0-STABLE #3: Sat Apr 26 10:20:31 MSD 2008 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/VBOOK Panic String: page fault Dump Parity: 4236056142 Bounds: 44 Dump Status: good kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.44 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". No struct type named linker_file. No struct type named linker_file. No struct type named linker_file. No struct type named linker_file. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0542757 in boot (howto=260) at ../../../kern/kern_shutdown.c:418 #2 0xc0542a53 in panic (fmt=Variable "fmt" is not available.) at ../../../kern/kern_shutdown.c:572 #3 0xc06a8870 in trap_fatal () #4 0xc06a8c2a in trap_pfault () #5 0xc06a957e in trap () #6 0xc068e80b in calltrap () #7 0xc58b68d5 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Most of crashes even failed to save vmdump due to double faults. Looks like it is really related to wireless code. Effect happens only at my home WiFi network and does not happens at work (WPA-PSK vs PEAP) and always current process in nmbd (broadcasting ?). Crash happens with both 4BSD and ULE schedulers. My system have dual-core Intel x86 CPU (SMP kernel) FWIW I've had to install 6.3 because my new system crashed on 7- uses a ral driver for a linksys wmp54g card. I'm not sure about broadcasting, but it failed after only moments of up time. I'm also going to have to roll back to 6.3 on another machine of similar design (minus wifi nic)- crashes every so often. So far I haven't been able to get a dump because I don't see it happen and I can't find the logs yet. Machines use a gigabyte GA-945GCM-S2L mb with a celeron ~1.6G cpu and 1gig RAM, seagate 80gb sata hdd. Main diff is case- 1x desktop (250W), 1x tower (400W). _____ We can't fix problems w/o information. Should you or someone else get something to work with please file a PR. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bin/117065: install packages without dependencies
[EMAIL PROTECTED] wrote: Synopsis: install packages without dependencies State-Changed-From-To: open->patched State-Changed-By: krion State-Changed-When: Sat Nov 10 09:40:52 UTC 2007 State-Changed-Why: MFC after 14 days. http://www.freebsd.org/cgi/query-pr.cgi?pr=117065 Hello, Please note that, MFC is missing. /Vladimir Ermakov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hifn(4) causing system lockup
Vivek Khera wrote: On Mar 17, 2008, at 4:05 PM, Sascha Klauder wrote: I've recently upgraded my 6.2-STABLE workstation to RELENG_7, and I'm now experiencing system lockups that seem to be caused by the hifn(4) driver. I've got a Soekris vpn1401 card to help with GELI disk en- cryption. Reading from a GELI volume is causing the system to freeze completely, which does not happen if software crypto is used (i.e. hifn.ko not loaded). I can't enter kernel debugger (ctrl+alt+esc doesn't work anymore) and my (remote) kgdb-fu isn't up to par anyway. I've had the exact same kind of issue with the vpn1401 PCI card in a Dell box for my firewall running pfSense (at the tie it was based on FreeBSD 6.1 I believe). It would lock up the firewall within 2 hours to 4 days of uptime. Once we removed the card, no lockups. Soekris never responded to my questions about such behavior. In contrast, their mini-PCI cards I have installed on some WRAP boards never lockup using the same software. I blame the card. Hifn contributed driver changes that purportedly corrected some issues that might be related. Unfortunately I've had no time to integrate them (it was provided as a single (huge) patch w/o any explanation). I called several times for someone to take it over but noone's stepped up. If you want to work through it contact me offline. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: recovering from the 6.3 xorg mess
On Mon, 17 Mar 2008 21:23:09 -0800 (AKDT) peter stern <[EMAIL PROTECTED]> wrote: > On Mon, 17 Mar 2008, Kevin Oberman wrote: > >> Date: Mon, 17 Mar 2008 07:36:23 +0100 > >> From: Kurt Jaeger <[EMAIL PROTECTED]> > >> Sender: [EMAIL PROTECTED] > >> Hi! > >>> I'd appreciate suggestions on how to get a working xorg from the mess 6.3 > >>> shipped with. I've been using FreeBSD since 2.2 and have never had much > >>> trouble with it until the 6 branch was released. My hardware is pretty > >>> generic Intel brand D865 motherboard, matrox g550 video. I don't customize > >>> the kernel. I do clean installs not upgrades. > >> > >> Basically, the problem is with the matrox board. ... > > > > I have run the Matrox G550 under both 6 and 7. I had some problems, but > > not too many. I do need to use xrandr to set up the proper resolution, > > though. > > > > #!/bin/sh > > # Set 1280x1024 mode on second display > > xrandr --addmode VGA2 1280x1024 > > # Set 1024x768 mode on second port (Why? Why not.) > > xrandr --addmode VGA2 1024x768 > > # Set the second port to use 1280x1024 > > xrandr --output VGA2 --mode 1280x1024 ... Not unique to matrox. Some time before 6.3 there was an X update that broke various things. I also noticed I couldn't set resolution in xorg.conf or via keystrokes. xrandr seems the only way for most wm (kde can do it). I thought perhaps it was a 64bit problem since I'm using amd64, and some other keystrokes don't work (normally don't notice but was trying to find some way to set resolution). I've also noticed after xscreensaver can put X in a sleep mode where it just ignores anything (not a crash, but need to remote in to shut down X at least). Is resolution setting only through xrandr perhaps a deliberate (but undocumented) design change in xorg (feature)? Or just a temporary bug? I don't have a matrox: drm0: port 0xa000-0xa0ff mem 0xe000-0xe7ff,0xfd80-0xfd80 irq 16 at device 0.0 on pci1 info: [drm] AGP at 0xf000 128MB info: [drm] Initialized radeon 1.25.0 20060524 -- sam sirlin <[EMAIL PROTECTED]> ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: interrupt storms with AR5414 on 6.3 RELEASE
huub wrote: I have a problem running the Atheros AR5414 wireless mini-pci-card (Compex model WLM54AGP23) with FreeBSD 6.3-RELEASE (GENERIC i 386) on a Soekris 4521. I get lots of messages: "interrupt storm detected on "irq10:"; throttling interrupt source" and "ath0: device timeout" And after sometime the interface stops functioning. Anybody any suggestion? Thanks, Huub Information on system follows: # dmesg: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) . ath0: mem 0xa000-0xa000 irq 10 at device 16.0 on pci0 ath0: Ethernet address: 00:80:48:54:c0:92 ath0: mac 10.5 phy 6.1 radio 6.3 # ifconfig ath0: flags=8843 mtu 1500 inet6 fe80::280:48ff:fe54:c092%ath0 prefixlen 64 scopeid 0x1 inet 172.16.0.214 netmask 0xfffc broadcast 172.16.0.215 ether 00:80:48:54:c0:92 media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: associated ssid ap-omni.renv0.wleiden.net channel 1 bssid 00:02:6f:06:d6:14 authmode OPEN privacy OFF txpowmax 46 protmode CTS bintval 100 # wicontrol -i ath0 NIC serial number: [ ] Station name: [ CNodeHuub.wLeiden.NET ] SSID for IBSS creation: [ ap-omni.renv0.wleiden.net ] Current netname (SSID): [ ap-omni.renv0.wleiden.net ] Desired netname (SSID): [ ap-omni.renv0.wleiden.net ] Current BSSID: [ 00:02:6f:06:d6:14 ] Channel list: [ ffe 0 1110 1 0 0 0 0 2220 22 ] IBSS channel: [ 1 ] Current channel:[ 1 ] Comms quality/signal/noise: [ 0 24 0 ] Promiscuous mode: [ Off ] Intersil-Prism2 based card: [ 1 ] Port type (1=BSS, 3=ad-hoc):[ 1 ] MAC address:[ 00:80:48:54:c0:92 ] TX rate (selection):[ 0 ] TX rate (actual speed): [ 2 ] RTS/CTS handshake threshold:[ 2346 ] Create IBSS:[ Off ] Access point density: [ 1 ] Power Mgmt (1=on, 0=off): [ 0 ] Max sleep time: [ 100 ] WEP encryption: [ Off ] TX encryption key: [ 0 ] Encryption keys:[ ][ ][ ][ ] Some people have reported problems like this when powerd is in use. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Expresscard Wireless
Michael Lankton wrote: I bought a laptop with no PCMCIA slot, just expresscard. Instead of using a usb dongle for wireless, I would like to use an expresscard if possible. Ubiquiti makes one that uses atheros chip. Has anyone successfully used an expresscard wifi card in FreeBSD? Any info? It's just another form factor; it'll work fine. For newer Atheros cards you're likely to need the hal at http://www.freebsd.org/~sam. I've not tried the Ubiquiti expresscard so don't know what part is in it. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New KTR trace for mouse freezing/stuttering in 7.0-RC1
John Baldwin wrote: On Thursday 24 January 2008 06:22:57 am Sam Leffler wrote: Joe Peterson wrote: In an attempt to track down this mouse freezing/stuttering (i.e. "jerky mouse movement) behavior in FreeBSD 7.0-RC1, I have come up with a reliable way to cause it to happen, and I have created a longer trace showing the results. Note that I am using the ULE scheduler. In general, it becomes easier to see the effect if there is CPU activity. I have noticed it during kernel compiles, while at the same time loading web pages in firefox that contain images (and moving the mouse while this is happening). But a more controlled way to see it is to run something that uses some CPU and then generating lots of X events. In my case, I start "xtrs" (TRS-80 emulator) in Model IV mode, which happens to poll for input, using the CPU. Then I move the mouse back and forth quickly between windows in "focus under mouse" mode (in my case, a KDE focus mode), which causes many focus events quickly. In about 15 or 20 seconds, the mouse reliably starts to show erratic movement, not moving smoothly. I really hope this can shed more light on what might be going on. Here is the trace: http://www.skyrush.com/downloads/ktr_ule_4.out This is an interesting trace. It appears that something is blocking threads in the runq from running for 2 seconds! I don't see what it is from the trace data. It sort of looks like the last thing that ran is the swi4 which is likely a callout (need to check the log file contents to be certain). If the callback function does something it wouldn't necessarily be visible in the schedgraph plot. If you could stick a dmesg from booting out in the same spot it might be worthwhile. Also if you rebuild the kernel the kernel with DIAGNOSTIC then softclock() will complain about callouts that take longer than 2ms to run. This might generate too much noise in which case you can adjust the threshold by editing the code in sys/kern/kern_timeout.c. Hmm, when I look at that graph using schedgraphy from HEAD it just looks like xtrs is using up all the CPU. I didn't see the 2 second window where nothing was running. Sigh, you are correct. I backrev'd the machine where I ran schedgraph to RELENG_7 and didn't notice the old version mis-parses the ktr file. The graph is totally different w/ schedgraph from HEAD. Sorry Joe for misleading you. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New KTR trace for mouse freezing/stuttering in 7.0-RC1
Joe Peterson wrote: In an attempt to track down this mouse freezing/stuttering (i.e. "jerky mouse movement) behavior in FreeBSD 7.0-RC1, I have come up with a reliable way to cause it to happen, and I have created a longer trace showing the results. Note that I am using the ULE scheduler. In general, it becomes easier to see the effect if there is CPU activity. I have noticed it during kernel compiles, while at the same time loading web pages in firefox that contain images (and moving the mouse while this is happening). But a more controlled way to see it is to run something that uses some CPU and then generating lots of X events. In my case, I start "xtrs" (TRS-80 emulator) in Model IV mode, which happens to poll for input, using the CPU. Then I move the mouse back and forth quickly between windows in "focus under mouse" mode (in my case, a KDE focus mode), which causes many focus events quickly. In about 15 or 20 seconds, the mouse reliably starts to show erratic movement, not moving smoothly. I really hope this can shed more light on what might be going on. Here is the trace: http://www.skyrush.com/downloads/ktr_ule_4.out This is an interesting trace. It appears that something is blocking threads in the runq from running for 2 seconds! I don't see what it is from the trace data. It sort of looks like the last thing that ran is the swi4 which is likely a callout (need to check the log file contents to be certain). If the callback function does something it wouldn't necessarily be visible in the schedgraph plot. If you could stick a dmesg from booting out in the same spot it might be worthwhile. Also if you rebuild the kernel the kernel with DIAGNOSTIC then softclock() will complain about callouts that take longer than 2ms to run. This might generate too much noise in which case you can adjust the threshold by editing the code in sys/kern/kern_timeout.c. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What current Dell Systems are supported/work
Richard, I just bought one of these 2450 servers on ebay the other day, it was pretty cheap and still a good server for DNS here is a link http://search.ebay.com/_W0QQsassZlesmilde when I received the server it shipped with PC-BSD installed, I am going to put RELENG_7 on it, but if you read the site there is a link to a dmesg hope this helps Sam Fourman Jr. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: weird problems on 7.0-BETA3
Teemu Korhonen wrote: I'm getting usb-input device freezes and sometimes kernel panics that are somehow related to network traffic after upgrading from 6.2-RELEASE to 7.0-BETA3. One reproducible freeze comes when I try to update the server list in quake3 (linux version and native). Usb-mouse freezes as does usb-keyboard. Ps/2-keyboard works. The list doesn't update so I think the network freezes too. Message "nfe0: watchdog timeout (missed Tx interrupts) -- recovering" is generated in the log. After exiting quake3 the devices come back. Similar behavior occurs sometimes when watching streaming videos except that the error message is produced more frequently and usually it results in a kernel panic with a string "ohci_add_done: addr 0x0236cf30 not found". Sounds like the ithread scheduling issue I fixed; you can try updating to RELENG_7 or wait for a new build. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cryptodev and ssh on RELENG_7
Norikatsu Shigemura wrote: On Tue, 27 Nov 2007 07:37:49 -0500 Mike Tancsa <[EMAIL PROTECTED]> wrote: I have a HiFN crypto card and can remember that it was used for ssh connections with 3des encryption (on 6.1 afair). But with RELENG_7 it isn't used at all (no interrupts) if I 'ssh -v -c 3des-cbc [EMAIL PROTECTED]' Any ideas what is wrong? dmesg: hifn0 mem 0x8000-0x8fff,0x8004-0x80041fff,0x8008-0x80087fff irq 12 at device 13.0 on pci0 hifn0: [ITHREAD] hifn0: Hifn 7955, rev 0, 32KB dram, pll=0x801 crw-rw-rw- 1 root wheel - 0, 41 Nov 27 08:13:41 2007 /dev/crypto Hi, Are you sure you have device crypto and device cryptodev in the kernel? Also, there is a program in /usr/src/tools/tools/crypto called hifnstats. It will show some usuage stats. e.g. This issue is one of a gcc42 issue. But gcc42 is not wrong. OpenSSL has a using __FreeBSD_version issue. So to fix this issue, you should apply following patch. --- crypto/openssl/crypto/engine/eng_cryptodev.c.orig 2006-07-30 04:10:18.0 +0900 +++ crypto/openssl/crypto/engine/eng_cryptodev.c2007-11-08 01:55:35.0 +0900 @@ -32,7 +32,7 @@ #include #if (defined(__unix__) || defined(unix)) && !defined(USG) && \ - (defined(OpenBSD) || defined(__FreeBSD_version)) + (defined(OpenBSD) || defined(__FreeBSD__)) #include # if (OpenBSD >= 200112) || ((__FreeBSD_version >= 470101 && __FreeBSD_version < 50) || __FreeBSD_version >= 500041) # define HAVE_CRYPTODEV It appears openssl has been busted in it's handling of /dev/crypto since the engine code was roto-tilled. Attached is an updated version of your patch that forces /dev/crypto to be installed as the default engine for all ciphers it supports. I'm not sure this is the right change but it definitely makes ssh start using it (I note however that openssl speed does not use cryptodev unless explicity forced w/ cmd args). It would be a good idea to get someone familiar with openssl to review this before committing. Sam Index: eng_cryptodev.c === RCS file: /usr/ncvs/src/crypto/openssl/crypto/engine/eng_cryptodev.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 eng_cryptodev.c --- eng_cryptodev.c 29 Jul 2006 19:10:18 - 1.1.1.1 +++ eng_cryptodev.c 29 Nov 2007 23:22:03 - @@ -32,7 +32,7 @@ #include #if (defined(__unix__) || defined(unix)) && !defined(USG) && \ - (defined(OpenBSD) || defined(__FreeBSD_version)) + (defined(OpenBSD) || defined(__FreeBSD__)) #include # if (OpenBSD >= 200112) || ((__FreeBSD_version >= 470101 && __FreeBSD_version < 50) || __FreeBSD_version >= 500041) # define HAVE_CRYPTODEV @@ -1126,6 +1126,7 @@ } ENGINE_add(engine); + ENGINE_set_default_ciphers(engine); ENGINE_free(engine); ERR_clear_error(); } ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: any hope for nfe/msk?
; 64 bytes from 10.1.1.254: icmp_seq=10 ttl=64 time=25917.078 ms > 64 bytes from 10.1.1.254: icmp_seq=11 ttl=64 time=24916.115 ms > 64 bytes from 10.1.1.254: icmp_seq=12 ttl=64 time=23915.144 ms > 64 bytes from 10.1.1.254: icmp_seq=13 ttl=64 time=22914.192 ms > 64 bytes from 10.1.1.254: icmp_seq=14 ttl=64 time=21913.214 ms > 64 bytes from 10.1.1.254: icmp_seq=15 ttl=64 time=20912.278 ms > 64 bytes from 10.1.1.254: icmp_seq=16 ttl=64 time=19911.330 ms > 64 bytes from 10.1.1.254: icmp_seq=17 ttl=64 time=18910.375 ms > 64 bytes from 10.1.1.254: icmp_seq=18 ttl=64 time=17909.419 ms > 64 bytes from 10.1.1.254: icmp_seq=19 ttl=64 time=16853.821 ms > 64 bytes from 10.1.1.254: icmp_seq=20 ttl=64 time=15854.710 ms > 64 bytes from 10.1.1.254: icmp_seq=21 ttl=64 time=14701.312 ms > 64 bytes from 10.1.1.254: icmp_seq=22 ttl=64 time=13701.003 ms > 64 bytes from 10.1.1.254: icmp_seq=23 ttl=64 time=12700.052 ms > 64 bytes from 10.1.1.254: icmp_seq=24 ttl=64 time=11699.098 ms > 64 bytes from 10.1.1.254: icmp_seq=25 ttl=64 time=10698.148 ms > 64 bytes from 10.1.1.254: icmp_seq=36 ttl=64 time=0.463 ms > 64 bytes from 10.1.1.254: icmp_seq=37 ttl=64 time=0.379 ms > -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" I started having problems on nfe driver now I was using on 6.2 stable and I had polling enabled, the entire system was lagging and even when idle. I have no upgraded the box in question to 7.0 beta 3 and keeping the nfe driver on. irq22: nfe0 ehci01652548 20 It hasnt had heavy load since the upgrade yet. ehci0: I have no local access so cannot disable usb in the bios, if I do a new kernel disabling ehci in the kernel config will this stop the interrupt sharing and allow me to use nfe reasonably without polling as I think polling itself has been causing me problems (i use nfs). Is nfe still getting development as these are existing problems that are known but there has been no update to the below page for a while now so I am curious if its dead in the water now. http://www.f.csce.kyushu-u.ac.jp/~shigeaki/software/freebsd-nfe.html Chris I've also seen wierd problems on a machine that shares an interrupt between nfe and ehci. I'm hoping that this recent commit to -CURRENT fixes the problem. I'm planning on trying it on my 7.0-BETA machine in the next day or so. scottl 2007-11-21 04:03:51 UTC FreeBSD src repository Modified files: sys/amd64/amd64 intr_machdep.c sys/i386/i386intr_machdep.c sys/ia64/ia64interrupt.c sys/powerpc/powerpc intr_machdep.c sys/sparc64/sparc64 intr_machdep.c Log: Extend critical section coverage in the low-level interrupt handlers to include the ithread scheduling step. Without this, a preemption might occur in between the interrupt getting masked and the ithread getting scheduled. Since the interrupt handler runs in the context of curthread, the scheudler might see it as having a such a low priority on a busy system that it doesn't get to run for a _long_ time, leaving the interrupt stranded in a disabled state. The only way that the preemption can happen is by a fast/filter handler triggering a schduling event earlier in the handler, so this problem can only happen for cases where an interrupt is being shared by both a fast/filter handler and an ithread handler. Unfortunately, it seems to be common for this sharing to happen with network and USB devices, for example. This fixes many of the mysterious TCP session timeouts and NIC watchdogs that were being reported. Many thanks to Sam Lefler for getting to the bottom of this problem. nfe+ohci was the combo I had that prompted me to fix this. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath support for mini-pci 802.11n card?
Michael Butler wrote: Has anyone tried the present ath driver with the mini-pc card described as .. "Netegriti 802.11n 802.11g 802.11b 802.11a Turbo Mini PCI Wireless Card" and advertised at http://discountechnology.com/Netegriti-802-11n-802-11g-802-11b-802-11a-Turbo-Mini-PCI-Wireless-Card It appears to be based on the Atheros AR5416, AR5133 chipsets but I can't work out from the sources if this combo is supported :- All 5416/5418-based cards will work in legacy mode w/ the hal found at http://www.freebsd.org/~sam. But since you can't (yet) use 11n there's not much reason to want an 11n card instead of a legacy card--especially given the cost. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-BETA2 buildworld fails: WITHOUT_WPA_SUPPLICANT_EAPOL
Frederic Chardon wrote: -- Message transféré -- From: Eugene Grosbein <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Sat, 10 Nov 2007 11:20:24 +0700 Subject: 7.0-BETA2 buildworld fails: WITHOUT_WPA_SUPPLICANT_EAPOL Hi! Yesterday I've upgraded 7.0-BETA1 to 7.0-BETA2 with standard source upgrade procedure. Then I've tried to build world again using same sources but this time with some parts turned off via src.conf and found that make -j2 buildworld fails. This is my /etc/src.conf: WITHOUT_ATM= WITHOUT_AUDIT= WITHOUT_AUTHPF= WITHOUT_ZFS= WITHOUT_CDDL= WITHOUT_FORTRAN= WITHOUT_GCOV= WITHOUT_HTML= WITHOUT_I4B= WITHOUT_INET6= WITHOUT_IPFILTER= WITHOUT_IPX= WITHOUT_KERBEROS= WITHOUT_NIS= WITHOUT_PF= WITHOUT_PROFILE= WITHOUT_WPA_SUPPLICANT_EAPOL= Hello I had exactly the same problem this morning, simply comment #WITHOUT_WPA_SUPPLICANT_EAPOL= in your make.conf and it should work. Or update; I just fixed the Makefile. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em watchdog problem
Jack Vogel wrote: This morning I had an idea about what the source of the watchdog problem is. Also, we have repro'd at least one type of watchdog inhouse. One question, is this problem only happening for those running STABLE with the 6.6.6 merged driver? We found the problem does not seem to happen on 7.0. Right now my suspicion is that the FAST irq handling is again causing a problem. I am experimenting with variations to the code today to be sure whats going on, and hopefully fixing it. I see it on HEAD and releng7. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wpa_supplicant features and compile options
Greg Rivers wrote: I connect to certain wireless networks that require the EAP_GTC and EAP_OTP features in wpa_supplicant. These features are not compiled into wpa_supplicant by default. Using the patch below works great, but it's inconvenient having to remember to apply it after every cvsup. Is there a better way to accomplish this? If not, might a change such as this be committed to enable GTC and OTP by default? Thanks for reminding me about these config options. I typically add EAP options slowly based on feedback because I'm leery of pulling in heaps of code that's rarely used. Also all the code is present in contrib so you just need to tweak the compile knobs. I'll see if I can make it so you can do it from src.conf. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: none of wpa_passphrase
Eitarou Kamo wrote:
Pietro Cerutti wrote:
Eitarou Kamo wrote:
Hi,
I used wpa _supplicant and was aware none of wpa _passphrase.
My machine is 6.2 REREASE. Does anyone have it or way to making it?
These kind of generic questions are better suited for
freebsd-questions@, i doubt.
Anyway, from man 8 wpa_passphrase:
The wpa_passphrase utility is a small program for generating a 256-bit
pre-shared WPA key from an ASCII passphrase and a given SSID. The output
is formatted for inclusion in wpa_supplicant.conf(5).
Example:
I have an access point with ssid MySSID and passphrase MyS3cr3t:
wpa_passphrase MySSID
# reading passphrase from stdin
MyS3cr3t
network={
ssid="MySSID"
#psk="MyS3cr3t"
psk=c0964594a3000e7605ef17097f7d939a44e516f05b99806fd862db5934c2e4d4
}
The output is ready to be included in your wpa_supplicant.conf file
(better removing the commented line where the password is in clear text).
nf
My question is not the usage of it but itself I can't use
wpa_supplicant because
none of it. Is there it anywhere? Haven't it been dealt with stable yet?
wpa_supplicant includes the functionality of wpa_passphrase. You only
want it if you want to precompute the PSK from a passphrase.
As to building it you have the code; just setup a Makefile in
usr.sbin/wpa. HEAD and RELENG_6 include support so try grabbing it from
there.
Sam
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Just saying hi.
Hi everyone, just thought I'd say hello, new to the list. Hope I can help with some problems; and if I have any, I hope you guys can help me. :D -- Sam Stein Computer Technician/Programmer b1tt3r ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 induced panic additional info
Steve Kargl wrote: > By increasing the kernel message buffer, I was able to > get the previous "Unread portion" im my last email. > > Unread portion of the kernel message buffer: > lock order reversal: (sleepable after non-sleepable) > 1st 0xc34caec0 ath0 (ath0) @ /usr/src/sys/dev/ath/if_ath.c:5210 > 2nd 0xc32cbe24 user map (user map) @ /usr/src/sys/vm/vm_map.c:3074 > KDB: stack backtrace: > kdb_backtrace(0,,c07c3e08,c07c5500,c078596c,...) at kdb_backtrace+0x29 > witness_checkorder(c32cbe24,9,c075587c,c02) at witness_checkorder+0x578 > _sx_xlock(c32cbe24,c075587c,c02) at _sx_xlock+0x50 > _vm_map_lock_read(c32cbde0,c075587c,c02,2000246,c3722068,...) at > _vm_map_lock_read+0x37 > vm_map_lookup(d9753a6c,805e000,2,d9753a70,d9753a60,d9753a64,d9753a47,d9753a48) > at vm_map_lookup+0x28 > vm_fault(c32cbde0,805e000,2,8,c34ee180,...) at vm_fault+0x65 > trap_pfault(d9753b34,0,805e000) at trap_pfault+0xce > trap(c07b0008,28,c0730028,805e000,c334f400,...) at trap+0x319 > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc06e8056, esp = 0xd9753b74, ebp = 0xd9753bac --- > generic_copyout(c34c8c00,c3726400,c34cab30,c0286938,0,...) at > generic_copyout+0x36 > ieee80211_ioctl(c34ca230,c0286938,c3726400) at ieee80211_ioctl+0xc1 > ath_ioctl(c34c8c00,c0286938,c3726400) at ath_ioctl+0x190 > ifhwioctl(c0286938,c34c8c00,c3726400,c34ee180) at ifhwioctl+0xa40 > ifioctl(c355e000,c0286938,c3726400,c34ee180,0,...) at ifioctl+0xc3 > soo_ioctl(c3516ab0,c0286938,c3726400,c3748480,c34ee180) at soo_ioctl+0x2db > ioctl(c34ee180,d9753d04) at ioctl+0x396 > syscall(3b,3b,3b,805d028,0,...) at syscall+0x22f > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28149787, esp = 0xbfbfe2fc, > ebp = 0xbfbfe328 --- > KDB: enter: witness_checkorder > panic: from debugger > KDB: stack backtrace: > Uptime: 1m1s > Dumping 511 MB (2 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 511MB (130786 pages) 495 479 463 447 431 415 399 383 367 351 335 > 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 > > #0 doadump () at pcpu.h:165 > 165 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) quit > mobile:root[157] exit > exit > > Script done on Thu Apr 26 16:38:51 2007 Age old issue: the driver calls into the net80211 layer holding it's softc lock but net80211 calls copyout and if that faults copying data to user mode then you'll blow up. I've proposed a solution but noone's responded so it remains. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GELI versus GBDE?
I've been working on a ruby script to manage some geli file systems and have had some good experience using "-k -" to make it read from standard in. It's mixed with popen calls instead of a more bash-y version, but it works. :) I have not tried running it w/o a terminal allocated, but I suspect that won't make much of a difference. (If the script wasn't in such sorry shape at the moment I would copy it along, but I don't think anyone wants to see it now. ;) ) Sam Lumeta - Securing the Network in the Face of Change www.lumeta.com Nikolay Mirin wrote: Anyway, the other reasons that GBDE suck are: 1) Lots of annoying ENOMEM messages, since the memory allocation calls gbde makes are somewhat specific as I understand. One can ignore those messages. 2) GELI provides a onetime key feature, which makes it incredibly convenient for swap and /tmp encryption. 3) The secret key in GELI can be split between the keyfile and the passphrase. The only inconvenience I had with GELI is that if one wants to read a passphrase in a script once and then open a bunch of volumes, than one has to use "expect" to feed the passphrase to geli. It requires the terminal input and won't accept the stdin. GBDE does not have such issue. P.S. One can actually have both in kernel. Christian Brueffer said the following on 16.04.2007 11:21: On Sun, Apr 15, 2007 at 08:56:07AM -0500, Nikolay Mirin wrote: Definitely GELI. GBDE will become obsolete very soon as some other things like vinum and such. It was there just as a test of concept as I understand. Many those different disk subsystems are incompatible in fact, the case of GBDE and Vinum is mentioned as an example in the handbook. Read more about GEOM, as this system will unite all possible disk techniqies. Also, GELI takes advantage of crypto-hardware, but I believe that one gets a benefit out of it only if the main CPU is very slow. There are currently no plans to remove GBDE. The problems with Vinum you mention stemmed from the fact, that the original Vinum was not GEOM aware, thus, GELI couldn't have been used with it as well. gvinum has been in existance for some time now and it's fully compatible to both GBDE and GELI. - Christian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0 watchdog timeout with nfs
LI Xin wrote: > Hi, Jack, > > Jack Vogel wrote: >>> [EMAIL PROTECTED]:14:0: class=0x02 card=0x002e8086 chip=0x100e8086 >>> rev=0x02 >>> hdr=0x00 > [...] >> The driver in 6.2 RELEASE fixed all known problems with >> watchdogs, other than REAL issues with the network/hardware. >> Have you tried installing that? > > A friend of mine has reported similar problem, with different em(4) > hardware. The server runs lighttpd on ufs, and the watchdog timeout > occurs no matter whether there is heavy traffic. > > Here is some pciconf -l output which can be interesting. > > [EMAIL PROTECTED] /usr/local/etc]# pciconf -l|grep em > [EMAIL PROTECTED]:0:0: class=0x02 card=0x30a38086 chip=0x108b8086 > rev=0x03 > hdr=0x00 > [EMAIL PROTECTED]:5:0: class=0x02 card=0x30a18086 chip=0x10768086 > rev=0x05 > hdr=0x00 > > Should more debugging aid / information is needed to narrow down the > issue please let us know, thanks! I've reported similar problems multiple times w/o any response. My nic is onboard (no msi involved, no polling used): [EMAIL PROTECTED]:1:0: class=0x02 card=0x80f71043 chip=0x10198086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82547EI Gigabit Ethernet Controller (LOM)' class = network subclass = ethernet trouble% ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=9b ether 00:11:2f:9e:c0:e5 inet 10.0.0.248 netmask 0xff00 broadcast 10.0.0.255 media: Ethernet autoselect (1000baseTX ) status: active When I boot I also see massive #'s of link state transitions while dhclient fetches a lease. I've swapped cables, switch ports, etc. I can believe it might be a h/w failure but was hoping I could isolate the issue to be certain (don't like discarding the onboard nic). This is a very current HEAD and has been a problem for several months (all against HEAD). Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Just a test
I'm trying to get my mail stuff all working correctly... this is just a test. -- Sam Stein Computer Technician/Programmer Steintech ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Atheros wireless card channel conflict - unable to reset hardware
Lyle Scott wrote: > I just replaced my Dell E1505's Intel 3945ABG wireless card with an > Atheros AR5006EX card that I purchased from a person in Hong Kong and I > live in the USA. The card works great under Windows but when ath0 starts > up in FreeBSD, it gets the following errors which renders the card > useless until I restart and choose a particular channel specified with > ifconfig in /etc/rc.conf that is not channel 8 or 12. I have read > another post somewhat similar to mine, but I have not had any luck > resolving it. Any help is very much appreciated. I am on FreeBSD > 6.2 ... this is also with a Linksys WRT54GX2 V2 wireless G router. > > /var/log/messages (over and over again) > # Mar 16 23:41:02 laptop kernel: ath0: unable to reset hardware; hal > status 12 > # Mar 16 23:41:12 laptop kernel: ath0: unable to reset hardware; hal > status 0 > > # dmesg > laptop kernel: ath0: mem 0xefcf-0xefcf irq 16 at > device 0.0 on pci11 > laptop kernel: ath0: Ethernet address: 00:11:f5:c2:2b:05 > laptop kernel: ath0: mac 10.3 phy 6.1 radio 10.2 > > # ifconfig ath0 list channels > Channel 1 : 2412* Mhz 11g Channel 16 : 5080 Mhz 11a > Channel 2 : 2417* Mhz 11g Channel 36 : 5180 Mhz 11a > Channel 3 : 2422* Mhz 11g Channel 40 : 5200 Mhz 11a > Channel 4 : 2427* Mhz 11g Channel 44 : 5220 Mhz 11a > Channel 5 : 2432* Mhz 11g Channel 48 : 5240 Mhz 11a > Channel 6 : 2437* Mhz 11g Channel 52 : 5260* Mhz 11a > Channel 7 : 2442* Mhz 11g Channel 56 : 5280* Mhz 11a > Channel 8 : 2447* Mhz 11a 11g Channel 60 : 5300* Mhz 11a > Channel 9 : 2452* Mhz 11g Channel 64 : 5320* Mhz 11a > Channel 10 : 2457* Mhz 11g Channel 135 : 4920 Mhz 11a > Channel 11 : 2462* Mhz 11g Channel 136 : 4940 Mhz 11a > Channel 12 : 2467* Mhz 11a 11g Channel 137 : 4960 Mhz 11a > Channel 13 : 2472* Mhz 11g Channel 138 : 4980 Mhz 11a > Channel 14 : 2484* Mhz 11b > > # sysctl dev.ath.0 > dev.ath.0.%desc: Atheros 5424 > dev.ath.0.%driver: ath > dev.ath.0.%location: slot=0 function=0 handle=\_SB_.PCI0.RP01.PXS1 > dev.ath.0.%pnpinfo: vendor=0x168c device=0x001c subvendor=0x10cf > subdevice=0x139c class=0x02 > dev.ath.0.%parent: pci11 > dev.ath.0.smoothing_rate: 95 > dev.ath.0.sample_rate: 10 > dev.ath.0.countrycode: 0 > dev.ath.0.regdomain: 247 247 is Japan UNI-1 even + UNI-2 + 4.9GHz > dev.ath.0.slottime: 9 > dev.ath.0.acktimeout: 48 > dev.ath.0.ctstimeout: 48 > dev.ath.0.softled: 0 > dev.ath.0.ledpin: 0 > dev.ath.0.ledon: 0 > dev.ath.0.ledidle: 2700 > dev.ath.0.txantenna: 0 > dev.ath.0.rxantenna: 2 > dev.ath.0.diversity: 1 > dev.ath.0.txintrperiod: 5 > dev.ath.0.diag: 0 > dev.ath.0.tpscale: 0 > dev.ath.0.tpc: 0 > dev.ath.0.tpack: 63 > dev.ath.0.tpcts: 63 > dev.ath.0.rfsilent: 1 > dev.ath.0.rfkill: 1 > dev.ath.0.monpass: 24 You are running a version of the os that maps the 4.9GHz channels according to the IEEE Public Safety Band (PSB) spec. Unfortunately that results in overlaps between 5GHz and 2GHz channels and the existing net80211 code doesn't handle that well. You don't indicate what version of the os you are running but if you use HEAD or RELENG_6 you'll find that I hacked the freq<->IEEE mapping to avoid this overlap. Alternatively you can search for how to zap the regdomain setting in your EEPROM to something that doesn't cause this overlap. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems installing JDK 1.5
We've seen JVM lockups during high contention Threading operations with the jdk15 port. The same code succeeded when running under diablo-jdk. I have precious little information on the details of the failure we saw so I'm hesitant to toss the jdk15 port squarely under the bus without more poking at the issue, but time just isn't on my side lately. :) Perhaps this will jog the memories of others who can elaborate. Juergen Nickelsen wrote: Stefan Walter <[EMAIL PROTECTED]> writes: It might be easier for you to just use the java/diablo-jdk15 port, which installs precompiled binaries. Although I have, with the much appreciated help from people here, successfully installed the jdk15 port in between, I thought about diablo-jdk15, too. Would there be any difference between both ports in terms of compatibility, features, and performance from the viewpoint of the Java developer and user? -- Sam Baskinger Software Engineer Lumeta - Securing the Network in the Face of Change www.lumeta.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP doesn't work without ACPI?
The 1950s that I have (IIRC as I installed them a few months ago) hang at about the same location when ACPI is enabled. I'll see if I can't pull one down and recreate the behavior. I should note that I'm running something after 6.2-RELEASE. Again, I'll try to recreate and get some data from the machines. Sam Scott Long wrote: I've had no problem getting FreeBSD 6 to boot on Dell 1950 and 2950 machines. Where does it hang for you, and what changes have you made to your kernel config? Scott Sam Baskinger wrote: Adding a datapoint: Dell 1950s exhibit similar behaviour but have 2 cores in a single physical CPU. Hope this helps the discussion along. Sam Baskinger Software Engineer Lumeta - Securing the Network in the Face of Change Ivan Voras wrote: Continuing my problems with the IBM blade: Booting with ACPI module enabled (btw. live boot CD with sysinstall doesn't load ACPI, but the installed system does?) hangs the system somewhere after first USB bus is found (booting verbose doesn't show any new lines before or after this step). It appears to be a real hang instead of a timeout because I left it 30 minutes and it didn't continue. Booting without ACPI on the other hand doesn't find all the CPU's :( Here's sysctl output: sysctl -a | grep smp kern.timecounter.smp_tsc: 0 kern.smp.forward_roundrobin_enabled: 1 kern.smp.forward_signal_enabled: 1 kern.smp.cpus: 1 kern.smp.disabled: 0 kern.smp.active: 0 kern.smp.maxcpus: 16 Here's the mptable -dmesg output: === MPTable --- MP Floating Pointer Structure: location: EBDA physical address: 0x0009d140 signature:'_MP_' length: 16 bytes version: 1.4 checksum: 0xfe mode: Virtual Wire --- MP Config Table Header: physical address: 0x0009e9b0 signature:'PCMP' base table length:388 version: 1.4 checksum: 0x77 OEM ID: 'IBM ENSW' Product ID: 'LEWIS SMP ' OEM table pointer:0x OEM table size: 0 entry count: 37 local APIC address: 0xfee0 extended table length:408 extended table checksum: 159 --- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 0 0x10BSP, usable 15 1 2 0x0301 2 0x10AP, usable 15 1 2 0x0301 1 0x10AP, usable 15 1 2 0x0301 3 0x10AP, usable 15 1 2 0x0301 -- Bus:Bus ID Type 0 PCI 1 PCI 2 PCI 3 PCI 4 PCI 5 PCI 6 PCI 7 PCI 8 PCI 9 ISA -- I/O APICs: APIC ID Version State Address 14 0x11usable 0xfec0 13 0x11usable 0xfec02000 -- I/O Ints: TypePolarityTrigger Bus ID IRQAPIC ID PIN# INT conformsconforms9 1 141 INT conformsconforms9 0 142 INT conformsconforms9 4 144 INT conformsconforms9 6 146 INT active-hiedge9 8 148 INT conformsconforms911 14 11 INT conformsconforms912 14 12 INT conformsconforms913 14 13 INT conformsconforms914 14 14 INT conformsconforms915 14 15 INT conformsconforms0 3:A 143 INT conformsconforms0 3:A 143 INT conformsconforms0 3:A 143 INT conformsconforms0 5:A 130 INT conformsconforms2 4:A 131 INT conformsc
Re: SMP doesn't work without ACPI?
Adding a datapoint: Dell 1950s exhibit similar behaviour but have 2 cores in a single physical CPU. Hope this helps the discussion along. Sam Baskinger Software Engineer Lumeta - Securing the Network in the Face of Change Ivan Voras wrote: Continuing my problems with the IBM blade: Booting with ACPI module enabled (btw. live boot CD with sysinstall doesn't load ACPI, but the installed system does?) hangs the system somewhere after first USB bus is found (booting verbose doesn't show any new lines before or after this step). It appears to be a real hang instead of a timeout because I left it 30 minutes and it didn't continue. Booting without ACPI on the other hand doesn't find all the CPU's :( Here's sysctl output: sysctl -a | grep smp kern.timecounter.smp_tsc: 0 kern.smp.forward_roundrobin_enabled: 1 kern.smp.forward_signal_enabled: 1 kern.smp.cpus: 1 kern.smp.disabled: 0 kern.smp.active: 0 kern.smp.maxcpus: 16 Here's the mptable -dmesg output: === MPTable --- MP Floating Pointer Structure: location: EBDA physical address: 0x0009d140 signature:'_MP_' length: 16 bytes version: 1.4 checksum: 0xfe mode: Virtual Wire --- MP Config Table Header: physical address: 0x0009e9b0 signature:'PCMP' base table length:388 version: 1.4 checksum: 0x77 OEM ID: 'IBM ENSW' Product ID: 'LEWIS SMP ' OEM table pointer:0x OEM table size: 0 entry count: 37 local APIC address: 0xfee0 extended table length:408 extended table checksum: 159 --- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 0 0x10BSP, usable 15 1 2 0x0301 2 0x10AP, usable 15 1 2 0x0301 1 0x10AP, usable 15 1 2 0x0301 3 0x10AP, usable 15 1 2 0x0301 -- Bus:Bus ID Type 0 PCI 1 PCI 2 PCI 3 PCI 4 PCI 5 PCI 6 PCI 7 PCI 8 PCI 9 ISA -- I/O APICs: APIC ID Version State Address 14 0x11usable 0xfec0 13 0x11usable 0xfec02000 -- I/O Ints: TypePolarityTrigger Bus ID IRQAPIC ID PIN# INT conformsconforms9 1 141 INT conformsconforms9 0 142 INT conformsconforms9 4 144 INT conformsconforms9 6 146 INT active-hiedge9 8 148 INT conformsconforms911 14 11 INT conformsconforms912 14 12 INT conformsconforms913 14 13 INT conformsconforms914 14 14 INT conformsconforms915 14 15 INT conformsconforms0 3:A 143 INT conformsconforms0 3:A 143 INT conformsconforms0 3:A 143 INT conformsconforms0 5:A 130 INT conformsconforms2 4:A 131 INT conformsconforms2 5:A 132 INT conformsconforms3 4:A 133 INT conformsconforms3 5:A 134 INT conformsconforms3 5:B 135 -- Local Ints: TypePolarityTrigger Bus ID IRQAPIC ID PIN# NMI conformsconforms9 02551 ExtINT conformsconforms9 02550 ---
Re: sysinstall creates corrupt filesystems after repartitioning
Steven Hartland wrote: > I've been repartitioning some of our machines here and > found that using the following method sysinstall creates > corrupt filesystems. > > 1. Boot a machine using an nfs mounted /usr > 2. Run: sysctl kern.geom.debugflags=16 to enable writing > to the disk mbr > 3. run sysinstall, Customise -> Label > 4. Delete the /usr partition e.g. /dev/da0s1f > 5. Create two partitions from the space left as ufs with > mount points /usr and /data > 6. Write the changes. > > Now two strange things happen: > 1. /usr ends up mounted twice once from nfs and once > from the new ufs. This requires umount -f /dev/da0s1f to > correct but doesnt always work properly requiring a reboot > to restore system functionality. > 2. The FS on both partitions is totally corrupt even fsck > cant repair them, even after a reboot. > > So the question is why would sysinstall create two corrupt > FS's with this procedure? > > Fixing is trivial just rerun the newfs commands and all > is good but its really odd that they should be corrupt > in the first place and caught me out big time when I first > did this as I had restored a full dump back onto /usr > and rebooted only for it to blow up horribly as the fs > was so badly corrupted. There's a debug flag you can turn on somewhere in the sysinstall menus. It may help diagnose what sysinstall is doing wrong by checking the log msgs. I find sysinstall is best diagnosed inside qemu or vmware so you destructively operate on disk images w/o hosing a real system. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixit cd for AMD64 on 6.2-RELEASE problem?
Steven Hartland wrote: > I'm currently trying to use the Fixit cd on AMD64 ( 6.2 ) > and it appears it has issues. When trying to fsck a > disk it reports: > fsck: exec fsck_4.2bsd for in /sbin:/usr/sbin: No such file or > directory > > When looking on the mounted volumes for fsck_4.2bsd its > located under: > /dist/rescue/fsck_4.2bsd > /dist/sbin/fsck_4.2bsd > > Surely /dist/sbin and /dist/usr/sbin should be in the PATH > by default? > > Also it seems that fsck uses a hardcoded search path so > setting PATH is not good enough, I had to create a symlink > it into /sbin. With fsck being one of the common things > people do with fixit would be nice if it just worked. > > P.S. Not sure if this is limited to AMD64, I suspect not > but thats what I was working on. Sometime back I needed the fixit CD and hit various problems like this (generated a 1/2 dozen items on my TODO list not all of which have been crossed off yet). This stuff gets precious little testing and could use a champion to help improve it. Seems like a chore most anyone could help with... Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems installing JDK 1.5
Juergen Nickelsen wrote: On Feb 27 2007, Chris Timmons wrote: Don't forget that the linux JDK will want you to have linprocfs mounted. I recently had a similar build experience of jdk-1.5.0p4 which cleared up fine after I remembered about linprocfs. linprocfs /compat/linux/proc linprocfs rw 0 0 Hm. I cannot imagine how this could lead to the problems I saw, but another thing to try. Thanks! Linux systems store tons of need-to-know data in the /proc file system. If you've ever installed a chrooted Linux environment you must 'mount -o bind' the /proc file system from the running system to the chroot for many OS functions to work correctly. I suspect that Java was looking for some process information in linprocfs and since it wasn't mounted, it blew up. :) Hope this clears up the "why" question. :) Sam Baskinger Lumeta - Securing the Network in the Face of Change www.lumeta.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems installing JDK 1.5
I'm assuming that you installed linux compatibility and then the linux-jdk 1.4? I failed to do that and saw a very similar error a while back. :) Sam Baskinger Lumeta - Securing the Network in the Face of Change www.lumeta.com Juergen Nickelsen wrote: Hello, on a more or less newly installed machine with 5.5-STABLE (updated recently) I tried to install JDK 1.5 via /usr/ports/. After retrieving all necessary files, the build failed quite mysteriously, even more so as I had succeeded with another machine fine last year. In the build protocol the problems seem to begin like this: Java HotSpot(TM) Client VM warning: Can't detect initial thread stack location /usr/ports/java/jdk15/work/control/build/bsd-i586/gensrc/sun/nio/cs/StandardChar\ sets.java:226: expected and then a series of other errors in the Java code; as if it is compiled using the wrong compiler version. It looks weird to me, as I think I fetched the correct files and did everything as carefully as last year. Is this a known problem? Does anyone know a way around it? Is the port currently broken, perhaps? Details can be found in <http://www.schlabun.org/screenlog.2>; and I'll gladly provide more details if necessary. Regards, Juergen. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic: 6.2-STABLE/RELEASE, sysctl (on boot) -- ath related
Hugo Silva wrote: > Hi, > > > While upgrading a fileserver / home wireless access point to > 6.2-RELEASE, it wouldn't come back after the regular > build/installworld/mergemaster procedures. > > I attached a keyboard and monitor to the server and noticed it was > panicking on boot, current process being sysctl: > > > Feb 13 18:27:51 hyperblast kernel: Fatal trap 12: page fault while in > kernel mode > Feb 13 18:27:51 hyperblast kernel: fault virtual address= 0x0 > Feb 13 18:27:51 hyperblast kernel: fault code = supervisor > read, page not present > Feb 13 18:27:51 hyperblast kernel: instruction pointer = 0x20:0xc06fb2a6 > Feb 13 18:27:51 hyperblast kernel: stack pointer= > 0x28:0xd9734ad8 > Feb 13 18:27:51 hyperblast kernel: frame pointer= > 0x28:0xc3383000 > Feb 13 18:27:51 hyperblast kernel: code segment = base 0x0, > limit 0xf, type 0x1b > Feb 13 18:27:51 hyperblast kernel: = DPL 0, pres 1, def32 1, gran 1 > Feb 13 18:27:51 hyperblast kernel: processor eflags = interrupt > enabled, resume, IOPL = 0 > Feb 13 18:27:51 hyperblast kernel: current process = 186 > (sysctl) > Feb 13 18:27:51 hyperblast kernel: trap number = 12 > Feb 13 18:27:51 hyperblast kernel: panic: page fault > Feb 13 18:27:51 hyperblast kernel: Uptime: 3s > Feb 13 18:27:51 hyperblast kernel: Cannot dump. No dump device defined. > Feb 13 18:27:51 hyperblast kernel: Automatic reboot in 15 seconds - > press a key on the console to abort > Feb 13 18:27:51 hyperblast kernel: --> Press a key on the console to > reboot, > Feb 13 18:27:51 hyperblast kernel: --> or switch off the system now. > Feb 13 18:27:51 hyperblast kernel: Rebooting... > > > The last line seen before the panic is sysctl adjusting values > (according to sysctl.conf): > > # tail /etc/sysctl.conf > > dev.ath.0.tpscale=1 > dev.ath.0.diversity=0 > > > Now, there are two interesting things to note: > > a) If I uncomment these lines with the system running and reload > (/etc/rc.d/sysctl reload), there's no panic. > > b) It used to work just fine on 6.0-RELEASE-p5. > > > It is not a big deal, but just something that perhaps should be fixed. > > For the records, I tried -RELEASE and -STABLE. Currently running -STABLE > (as of 2007-02-12 @ about 2AM GMT) Fixed in HEAD; will MFC in a week or so. Thanks for pointing this out. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath(4) irq and taskq cpu usage
Eric van Gyzen wrote: > The irq and taskq for my ath(4) card often use excessive amounts of CPU > time, even when my network is idle. They are often above 10% and 15%, > respectively; occasionally, they are as high as 27% and 44%. > > The system is an AMD Athlon64 2800+ running FreeBSD 6.2-RELEASE i386 > with a custom kernel including the wlan_* stuff, ath, ath_hal, and > ath_rate_sample. It is a station using WPA2-PSK with AES-CCMP. The > access point is also a FreeBSD machine with an ath(4) card. > > During periods of high CPU usage, the > > rx failed 'cuz of PHY err > OFDM timing > > fields of the athstats output are increasing rather quickly. For > example, while CPU usage was 25% and 46%, the OFDM timing field was > increasing by 43,000 per second. > > Can anyone explain this? Is it a sign of failing hardware? It means you're seeing lots of noise in the environment. The numbers you cite are way too high (43K/sec is crazy) and the %cpu times see too high for your processor but that's hard to evaluate. You don't indicate what your h/w is (mac+phy) revs but presumably it's old enough that PHY errors are not counted in h/w but instead sent to the host as little packets that must be processed. If you actually use the radio you'll see the error counts go down because the radio will be busy doing useful work. High phy error rates can also be caused by things like faulty antenna connections and/or radio overload (i.e. sta and ap being too close and/or using high power radios). I can add a knob to the driver to turn off this stuff but then you will likely see degraded performance as the PHY errors are used to tune the baseband when there is noise and/or when the case temperature changes (this can significantly affect radio operation). Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Diskless PXEboot crashes at kernel loading.
Hi all, I can't emphasise enough how useful running a TCPDUMP on the server in question is to find out what subtle thing it is that I missed. Generally speaking a quick-crash like that is a file not being found like the modules directory or something silly like that. If you dump the NFS traffic you will probably see the client asking for a file handle for file X and getting denied by the server. If you're not familiar w/ TCPDUMP, here are some handy commands: # Avoid SSH and dump everything to the screen... tcpdump -s 1500 -X udp # Write it to a file so you can open it in ethereal later... tcpdump -s 1500 -X -w nfs.dump udp # Read in the dump file and read it through less, should you not want to us # ethereal after the last step. :) tcpdump -X -r nfs.dump |less Note that if you have a slow or missing DNS entry, give these calls a -n to just get the data and not worry about the ND entries. Hope this helps! PXE boots are never kind. :) Sam Baskinger Software Engineer Lumeta - Securing the Network in the Face of Change Lumeta Corporation > > > And the crash happens. > > Note that the crash occurs for whatever option > > 1 to 6 I choose from the FreeBSD boot menu. > > > Does someone understand the crash messages? > > Not that I understand those messages but some time ago I've had a > similar case. It took me some hours to realise that I try to load > amd64 kernel to i386 diskless station... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic: 6.2-STABLE/RELEASE, sysctl (on boot) -- ath related
Hugo Silva wrote: > Hi, > > > While upgrading a fileserver / home wireless access point to > 6.2-RELEASE, it wouldn't come back after the regular > build/installworld/mergemaster procedures. > > I attached a keyboard and monitor to the server and noticed it was > panicking on boot, current process being sysctl: > > > Feb 13 18:27:51 hyperblast kernel: Fatal trap 12: page fault while in > kernel mode > Feb 13 18:27:51 hyperblast kernel: fault virtual address= 0x0 > Feb 13 18:27:51 hyperblast kernel: fault code = supervisor > read, page not present > Feb 13 18:27:51 hyperblast kernel: instruction pointer = 0x20:0xc06fb2a6 > Feb 13 18:27:51 hyperblast kernel: stack pointer= > 0x28:0xd9734ad8 > Feb 13 18:27:51 hyperblast kernel: frame pointer= > 0x28:0xc3383000 > Feb 13 18:27:51 hyperblast kernel: code segment = base 0x0, > limit 0xf, type 0x1b > Feb 13 18:27:51 hyperblast kernel: = DPL 0, pres 1, def32 1, gran 1 > Feb 13 18:27:51 hyperblast kernel: processor eflags = interrupt > enabled, resume, IOPL = 0 > Feb 13 18:27:51 hyperblast kernel: current process = 186 > (sysctl) > Feb 13 18:27:51 hyperblast kernel: trap number = 12 > Feb 13 18:27:51 hyperblast kernel: panic: page fault > Feb 13 18:27:51 hyperblast kernel: Uptime: 3s > Feb 13 18:27:51 hyperblast kernel: Cannot dump. No dump device defined. > Feb 13 18:27:51 hyperblast kernel: Automatic reboot in 15 seconds - > press a key on the console to abort > Feb 13 18:27:51 hyperblast kernel: --> Press a key on the console to > reboot, > Feb 13 18:27:51 hyperblast kernel: --> or switch off the system now. > Feb 13 18:27:51 hyperblast kernel: Rebooting... > > > The last line seen before the panic is sysctl adjusting values > (according to sysctl.conf): > > # tail /etc/sysctl.conf > > dev.ath.0.tpscale=1 > dev.ath.0.diversity=0 > > > Now, there are two interesting things to note: > > a) If I uncomment these lines with the system running and reload > (/etc/rc.d/sysctl reload), there's no panic. > > b) It used to work just fine on 6.0-RELEASE-p5. > > > It is not a big deal, but just something that perhaps should be fixed. > > For the records, I tried -RELEASE and -STABLE. Currently running -STABLE > (as of 2007-02-12 @ about 2AM GMT) I think I see the issue; not sure how it worked in previous versions. Thanks for the report. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias" [ath and ifconfig parameter order]
Freddie Cash wrote: > On Monday 12 February 2007 11:06 am, John Hay wrote: >> Also with the atheros driver I had problems in the past with some >> parameters that did not like to be on a single commandline. > > At least with the ath(4) driver, it all comes down to the order the > options are written on the commandline. Some options reset the device, > wiping out previous options, so you have to make sure those are set > first. Took me awhile to figure that out, but it is mentioned in the man > page. So can someone actually provide an example? I'm not aware of any interactions within the os. There might be some corner cases in ifconfig due to the way it processes cmdn line parameters. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0: ath_reset: unable to reset hardware; hal status 3
Kai Lockwood wrote: > Hello, > > I am having the same type of trouble with a Dynex card. I mearly > receive 'ath0: Device timeout' on the main console screen. "device timeout" and being unable to reset the h/w are totally different issues. > >> I take it you tried ifconfig'ing the interface down and up? > I have. The card does not appear to reset itself. While the card is up, it > just rotates across the chanels. If it's scanning then it resets. If it does not reset you will get a console msg saying it could not reset the chip. > >> The output of athstats at the point where things are wedged might be >> useful. > # /usr/local/bin/athstats > 84874 data frames received > 53228 data frames transmit > 2228 tx frames with an alternate rate > 15357 long on-chip tx retries > 560 tx failed 'cuz too many retries > 98877 mib overflow interrupts > 11M current transmit rate > 860 watchdog timeouts > 85 beacon miss interrupts > 612 tx management frames > 1602 tx frames discarded prior to association > 496 tx frames with no ack marked > 21148 rx failed 'cuz of bad CRC > 361 rx failed 'cuz of PHY err > 96 OFDM restart > 265 CCK restart > 13422 periodic calibrations > 10 rssi of last ack > -95 rx noise floor > 18 phantom beacon misses > 1 rx failed 'cuz frame too large > 1 switched default/rx antenna > Antenna profile: > [1] tx51420 rx 1829072 > [2] tx 403 rx 116 You have not indicated what h/w you have, what os version you're runing, or how your card is setup. The original poster I believe was operating in ap mode and you do not appear to be. Your athstats output indicates a very noise environment and/or a very long-running system (e.g. 98877 mib overflow interrupts for ~1.8 million packets tx/rx). Further an rssi of 10 indicates very low signal to the ap (it's barely on the fringe of operational use). > # >> Also verify if only tx is wedged (e.g. athstats 1 will show you >> if you're receiving frames). >input output altrate shortlong xretry crcerr crypt phyerr rssi > rate >84874532282228 0 15357560 21148 0 3610 11M >00 0 0 0 0 0 0 00 11M >00 0 0 0 0 0 0 00 11M >00 0 0 0 0 0 0 00 11M >00 0 0 0 0 0 0 00 11M >00 0 0 0 0 0 0 00 11M >00 0 0 0 0 0 0 00 11M >00 0 0 0 0 0 0 00 11M >00 0 0 0 0 0 0 00 11M >00 0 0 0 0 0 0 00 11M >00 0 0 0 0 0 0 00 11M >00 0 0 0 0 0 0 00 11M >00 0 0 0 0 0 0 00 11M >00 0 0 0 0 0 0 00 11M >00 0 0 0 0 0 0 00 11M >00 0 0 0 0 0 0 00 11M >00 0 0 0 0 0 0 00 11M >00 0 0 0 0 0 0 00 11M >00 0 0 0 0 0 0 00 11M >00 0 0 0 0 0 0 00 11M >00 0 0 0 0 0 0 00 11M > > The above snippet repeats verbatium regardless of traffic. rssi of 0 makes no sense. I don't trust your stats now. > >> Best suggestion I can make is to use a >> different model card. > > I can't. Is there someway to look into this issue deeper? I do not understand why you "can't" but whatever. FWIW I have a laptop that very recently started exhibiting "device timeouts" while operating in sta mode (using wpa). This means I'll eventually be able to look at that specific issue which in the past I've not been able to recreate. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath buildkernel problem with recent RELENG_6 [Was: Re: buildkernel (zlib module) broken?]
Kris Kennaway wrote: > On Mon, Jan 29, 2007 at 01:02:32AM +0100, Harald Schmalzbauer wrote: >> Am Sonntag, 28. Januar 2007 23:17 schrieb Kris Kennaway: >>> On Sun, Jan 28, 2007 at 10:12:26PM +0100, Harald Schmalzbauer wrote: Hello, I don't understand this error: ===> zlib (all) >> [...] 1 error *** Error code 2 Any hints? >>> Rerun make without -j and discover the real error which was some >>> distance back in the interleaved output from your parallel make >>> command. >> Ahh, ok, sorry, it's my first SMP system so I'm not used to this parallel >> build stuff... >> >> ath seems to be the problem: > > No, your kernel config is the problem ;) You apparently chopped out > too much when cutting it down from GENERIC. > >> /FlashBSD/src/sys/dev/ath/if_ath.c:417: undefined reference to >> `ieee80211_wme_acnames' > > "Undefined reference" almost always means "operator provided an > incomplete kernel config file". man ath shows: > To compile this driver into the kernel, place the following lines in your > kernel configuration file: > >device ath >device ath_hal >device ath_rate_sample >device wlan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0: ath_reset: unable to reset hardware; hal status 3
Henrik Brix Andersen wrote: > Hi all, > > I have noticed a problem when using ath(4) as an 802.11g access point > with hostapd(8) and WPA2-PSK CCMP. > > The following problem seems to only occur when a Microsoft Windows XP > STA connects to the AP in 802.11g mode, my FreeeBSD STAs doesn't seem > to trigger this: > > Jan 28 11:21:07 osgiliath kernel: ath0: stuck beacon; resetting (bmiss count > 4) > Jan 28 11:21:07 osgiliath kernel: ath0: ath_reset: unable to reset hardware; > hal status 3 > Jan 28 11:21:25 osgiliath kernel: ath0: device timeout > Jan 28 11:21:25 osgiliath kernel: ath0: stuck beacon; resetting (bmiss count > 4) > Jan 28 11:21:25 osgiliath kernel: ath0: ath_reset: unable to reset hardware; > hal status 3 > Jan 28 11:21:37 osgiliath kernel: ath0: device timeout > Jan 28 11:21:38 osgiliath kernel: ath0: stuck beacon; resetting (bmiss count > 4) > Jan 28 11:21:38 osgiliath kernel: ath0: ath_reset: unable to reset hardware; > hal status 3 > Jan 28 11:21:46 osgiliath kernel: ath0: device timeout > > This is FreeBSD RELENG_6 (nanoBSD) as of yesterday with the new > ath_hal(4) running on a Soekris net4801-50: > > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > ath0: mem 0xa001-0xa001 irq 11 at device 14.0 on pci0 > ath0: Ethernet address: 00:05:4e:42:e8:7c > ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 > > The same problem occured with version 0.9.17.2 of ath_hal(4). > > I have increased the RX/TX buffers in ath(4) as shown in this snippet > from my kernel configuration: > > deviceath > deviceath_hal > deviceath_rate_sample > > options ATH_RXBUF=80 > options ATH_TXBUF=200 > > The only way I can get the AP running again after the above messages > to syslog is to reboot it. The problem doesn't seem to occur in > 802.11b mode nor in 802.11g mode with only FreeBSD STAs. > > Any help in debugging this will be appreciated. I take it you tried ifconfig'ing the interface down and up? The output of athstats at the point where things are wedged might be useful. Also verify if only tx is wedged (e.g. athstats 1 will show you if you're receiving frames). The fact that the card cannot be reset seems to imply the mac is somehow locked up. I vaguely recall some h/w issues like this on older cards (and you are using a rather old card) but nothing that wasn't handled by doing a reset operation. Best suggestion I can make is to use a different model card. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Shutdown problem "Stray IRQ9"
Date: Fri, 5 Jan 2007 08:09:09 -0800 From: Jeremy Chadwick <[EMAIL PROTECTED]> On Fri, Jan 05, 2007 at 07:17:12AM -0800, vincent delft wrote: > As new to FreeBSD I'm looking for info to solve my > shutdown problem. > > When I shutdown the system (shutdown -h now), the > messages displayed are: ... I think shutdown -h should just hang (always has on my amd64 machine). I think you want to do shutdown -p which should (and does for me) turn off power. Sam Sirlin Email: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 timeout problem - again
JoaoBR wrote: > On Saturday 30 December 2006 18:37, Sam Leffler wrote: >> JoaoBR wrote: >>> 572 cabq frames transmitted >>> 11 cabq xmit overflowed beacon interval >>> >>> >>> media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b >> So one other thing came to mind. If your ap is operating in 11b and you >> have many multicast frames q'd up for power save stations then they can >> effectively saturate the network if they are being trasnmitted at a low >> tx rate (which they would be). This can effectively DOS your wireless >> network because the frames are burst immediately following the beacon. > > > hum, let's see ... > > this is an ISP environment > as unlikely the AP goes to sleep while rx/tx the client station either Don't know where this comment came from. Noone ever suggested the machine operating as an ap goes to sleep. > > we block incoming traffic, we sell internet access so there will no access to > the station which might match the case you brought up, the station request > access to a site and get reply, when the station "sleeps" (if) then there is > no considerable tx to it > > >> The driver limits the burst interval so it does not overflow into the >> next beacon but it's allowed to fill all available time to the next >> beacon frame (something I've considered changing for just the reason I >> described). This has always been an issue. You might try rate limiting >> these frames or just hack the driver to violate the spec and not buffer >> them for tx after the beacon (to see if your problem goes away). > > ok I understand, this certainly is another point we have problems with but we > did exactly what you mentioned. > > The tx buffer on the AP, once getting used is never released even if never > getting to fill it up to the configured limit - this I consider so far a > problem but not related to the problem we discuss Sorry I do not understand this but you say it is not related. > > > but let me ask, certainly the same problem could come up when for instance > the > client has a bad signal (bad caox or connector, antena misplaced or local > interference) and the AP can not tx to this station in this exact moment when > his signal drops right? Sorry, again I do not understand your point. I guess you're asking how do people deal with radio sources jamming the frequency, there's nothing you can do if someone doesn't honor the 802.11 protocols. > > > >> Further, if you have a machine with a crappy pci bus (such as !4801 >> soekris boards) it's entirely possible that you are hoarding the bus >> with these long transmits s.t. other problems are occurring. I do not >> recommend building ap products out of such equipment. (No disrespect to >> the 4501, et al they just had substandard pci bus operation.) >> > > ok, like said before we use PCs and the MBs we use are pretty reliable > because > on POPs where this special case of traffic do not appear we have them up for > months even with higher traffic as I mentioned before. > > > thank you for your availability to help. > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 timeout problem - again
JoaoBR wrote: > On Saturday 30 December 2006 18:29, Sam Leffler wrote: >> See my previous reply to you. Lamont is directing you to look for >> stations in your network operating with power save enabled. >> > > even if there are stations with powersaving on we can do anything against it > > this is an ISP environment where people connect with compatible hardware, I > do > not agree that power management enabled on some of them could bring the > network down Sorry I don't understand your comment. Noone has ever said having power save enabled in client sta's should be permitted to cause an ap to stop proper operation. > > > >>> But I saw histories about this and even if powersaving issue "was the >>> issue in that case(really?)" I think this is wierd in any way because if >>> ONE station with powersaving on could set the AP in DoS ... man ... if >>> really true this is kind of lame excuse or kind of driver weakness which >>> both would be inacceptable, and, if it does NOT wake up if in sleep state >>> ... no further comment, but a driver weakness right? >> Power save operation is a required part of 802.11. If there's a problem >> in supporting it then it should be fixed but I'm aware of several ap >> products shipping with freebsd that do not exhibit this problem so it >> may be related to your configuration. ath parts offload much processing >> to the host and creating a production quality ap based on them involves >> certain tuning and configuration that must be done according to the >> complete system. > > I know and as far as our knowledge goes (in fact there are no secrets to > disable powersaving) we do not have this problem and like I said before in > the former msg that I believe the problem is related to a certain kind of > traffic > > >> If you are saying you should not have to reboot a system because the >> device locks up then sure. But I've no idea if that was what was >> required. I'm aware of only one ath-related issue that can lockup a >> system--that's when a part is set into deep sleep and the host then >> accesses a register outside the pci clock domain w/o first waking up the >> part. This has only been reported with cardbus cards which means you >> can just eject the card to unfreeze the bus. But this sounds unrelated >> to the problem you are seeing. >> > > ok, but again our Ap is not in any power save mode, we monitor CPU, fan, temp > and traffic and to complete the powersaving issue, it is unlikely that the > freeBSD goes to sleep when I get considerable traffic through this box and > especially the ath card I guess you still don't understand what 802.11 power save operation means. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 timeout problem - again
JoaoBR wrote:
> On Saturday 30 December 2006 18:20, Sam Leffler wrote:
>
> thank you for answering, lots of good points and I will try to answer any of
> them
>
>
>>> I really do not know what this event means (ether type 5e4), for my
>>> understandings it is vague in the source, so I am lost here
>> Seems pretty clear: it's the type field extracted from the ethernet
>> header of the oversized packet. A quick check of sys/net/ethernet.h
>> shows no such ETHERTYPE defined. So something in your network is
>> transmitting packets that either being rx'd incorrectly or, more likely,
>> corrupted in transit.
>>
>
> good so far, point here is that we can not limit that someone tx this kind of
> packets but should find a way that this traffic do not DoS the AP.
>
> ipfw accepts 0x5e4 but at the end it does not get this packages
> changing mtu on any interface does not change a thing
>
>
> when we track the oversized packages they we found they are coming from nat
> servers where wingate and similar softwares are running, when we cut them out
> the mentioned traffic stopps and the AP does not interrupt service anymore
So the packet is real and it's being dropped at the 802.3 layer as it
should. If the printf is the problem remove it or rate limit it. I
think it should be rate-limited or just stuck under a debug flag but
I'll leave that to someone else. Alternatively we can enforce the mtu
in the ath driver and drop it there.
>
>
>>> {
>>> I get continously:
>>>
>>> kernel: ath0: link state changed to DOWN
>>> kernel: ath0: link state changed to UP
>>>
>>> when WL client but it recovers when the AP comes back to normal
>>> so wl-cli mode is not the issue
>>> }
>> Sorry this is hard to understand. You are saying that when you see
>> packets discarded on the ap the client stations lose their association
>> to the ap? You've said nothing about your environment but I'd guess
>> you've got some heavy interference like a microwave oven operating.
>>
>
>
> we use Freebsd releng_6 running Dlink 520 or 530 cards (ATH) in hostap mode
> as
> access point
>
> in order to check better what is happening we set up some freebsd clients
> releng_6 as well
>
> when this oversized packages are appearing first we see ath up/down events on
> the client, on windows machines the signal drops and comes back as well, so I
> guess it is the same
>
> if this oversize packages "are persistence" after a while the AP goes down
> and
> does not come back
>
> we do see other 11b/g APs out there and measured the spectrum but there is no
> meaningfull interference, also, in this specific case, here we do have
> channel 1,6 and 11 and all Aps are 2km away from each other.
>
>
>
>
>
>>> ath stats:
>>>
>>> 70777 data frames received
>>> 71551 data frames transmit
>>> 420 tx frames with an alternate rate
>>> 10821 long on-chip tx retries
>>> 260 tx failed 'cuz too many retries
>>> 11M current transmit rate
>>> 10489 tx management frames
>>> 1 tx frames discarded prior to association
>>> 786 tx frames with no ack marked
>>> 80516 tx frames with short preamble
>>> 54395 rx failed 'cuz of bad CRC
>>> 146438 rx failed 'cuz of PHY err
>>> 145013 CCK timing
>>> 1425 CCK restart
>>> 5295 beacons transmitted
>>> 19 periodic calibrations
>>> 42 rssi of last ack
>>> 31 avg recv rssi
>>> -98 rx noise floor
>>> 572 cabq frames transmitted
>>> 11 cabq xmit overflowed beacon interval
>> This should not happen. You have stations in power save mode in your
>> bss and the transmission of queued multicast frames overflowed the
>> interval following the beacon frame. This should be handled (I
>> explicitly tested it) but you might want to observe if this occurs when
>> you have problems.
>>
>
> this ath stats are from exactly the moment when the card in apmode stopped
>
>
>>> 1525 switched default/rx antenna
>>> Antenna profile:
>>> [1] tx41285 rx4
>> This makes no sense; you rx'd 4 frames total? That's inconsistent with
>> the "data frames received" counter and makes me question whether these
>> numbers are meaningful.
>>
>
> same answer as above, I like to remember we are in an outdoor environment
> with
> pigtail, coax and 18dBi Omni or 90 degree panel
Not sure how this statement bears any relationship to my quest
Re: ath0 timeout problem - again
JoaoBR wrote: > On Thursday 28 December 2006 21:52, you wrote: >> check this message: >> >> http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031216.html >> >> run "/usr/src/tools/tools/net80211/wlandebug/wlandebug -i ath0 power" and >> see if one of the hosts on your wlan has powersaving turned on. >> >> "stops forever" was not one of my symptoms though, so your issue may be >> different... >> > > > thank's for your answer > powersaving is not the issue here because it's off See my previous reply to you. Lamont is directing you to look for stations in your network operating with power save enabled. > > But I saw histories about this and even if powersaving issue "was the issue > in > that case(really?)" I think this is wierd in any way because if ONE station > with powersaving on could set the AP in DoS ... man ... if really true this > is kind of lame excuse or kind of driver weakness which both would be > inacceptable, and, if it does NOT wake up if in sleep state ... no further > comment, but a driver weakness right? Power save operation is a required part of 802.11. If there's a problem in supporting it then it should be fixed but I'm aware of several ap products shipping with freebsd that do not exhibit this problem so it may be related to your configuration. ath parts offload much processing to the host and creating a production quality ap based on them involves certain tuning and configuration that must be done according to the complete system. > > wether powersaving is on or not on the station/client is a local setting to > this station and must not influence any remote computer in any way, imagine, > you turn on your powersavings and the complete internet goes down on your > request hihihihi :) > > but then, like my case, on the AP or better ath in ap mode, even IF > powersaving is ON it might stop working for any related reason but firstable > NOT WHILE TX/RX and secondable if idle it must return soon THIS computer > wants to transmit any kind of traffic again > > last but not least powersaving might shut the power down but must return > when > necessary - if not - there is a driver problem. If you are saying you should not have to reboot a system because the device locks up then sure. But I've no idea if that was what was required. I'm aware of only one ath-related issue that can lockup a system--that's when a part is set into deep sleep and the host then accesses a register outside the pci clock domain w/o first waking up the part. This has only been reported with cardbus cards which means you can just eject the card to unfreeze the bus. But this sounds unrelated to the problem you are seeing. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 timeout problem - again
JoaoBR wrote:
> I need some help here, this is not a single case, I get this on a several
> machines, this is releng_6 , recent, but old problem getting ugly
>
>
> first I get this kind of events in messages, independent if it is client mode
> or hostap or adhoc
>
> Dec 28 16:50:53 ap1-cds kernel: ath0: discard oversize frame (ether type 5e4
> flags 3 len 1522 > max 1514)
> Dec 28 16:51:01 ap1-cds kernel: ath0: discard oversize frame (ether type 5e4
> flags 3 len 1522 > max 1514)
> Dec 28 16:58:16 ap1-cds kernel: ath0: device timeout
> ... timeout event repeats
>
> I really do not know what this event means (ether type 5e4), for my
> understandings it is vague in the source, so I am lost here
Seems pretty clear: it's the type field extracted from the ethernet
header of the oversized packet. A quick check of sys/net/ethernet.h
shows no such ETHERTYPE defined. So something in your network is
transmitting packets that either being rx'd incorrectly or, more likely,
corrupted in transit.
>
> {
> I get continously:
>
> kernel: ath0: link state changed to DOWN
> kernel: ath0: link state changed to UP
>
> when WL client but it recovers when the AP comes back to normal
> so wl-cli mode is not the issue
> }
Sorry this is hard to understand. You are saying that when you see
packets discarded on the ap the client stations lose their association
to the ap? You've said nothing about your environment but I'd guess
you've got some heavy interference like a microwave oven operating.
>
>
> but when the machine is running hostap the link state up/down events do not
> come up but transmission is interrupted, or better, goes slow and stops
> then - and stops forever until cold reboot, no chance to get this card back,
> not even unload ath and reload the driver (that was a try but I use it
> compiled into the kernel)
> this is not related to any WEP settings or any rate, this problem is coming
> up
> with either rate-sample or rate_onoe
>
>
> this is not related to the "tx stopped" problem (OACTIVE) and it is not
> related to any [TX|RX]BUF value (whatever it is set to)
>
> this problem is not a single case and not hardware related, here I mean MB,
> CPU, memory but is related in a certain way to the ath drv - same machine,
> but wi0 (prism card) and it does NOT happen this way
>
>
> I am with this problem since 6.0 and would be glad if somebody could convince
> Mr. Sam L. to attend this since it is a serious issue - any FreeBSD releng_6
> has this problem but releng_5 does not
Well "Mr. Sam L" has other things to do that are more important to him.
If you want help I can try to provide it but this is not exactly a
problem one can diagnose from afar. I suggest you sniff traffic from a
separate station and try to identify what is going on in the network
when you this event occur. It would also help to do the obvious things
like swap ath cards. You've also said nothing about your environment
such as the mac+phy revs for the card and the computer this is operating in.
>
> depending on the amount of traffic I get this any hour ( when 2-3Mbit/s or
> more) or several times a day (when 1-2Mbit/s)
>
> it get worse when I have more then one ath card installed
Sounds like you've got radio/antenna issues that manifest themselves as
noise that drives the radio's into silence. Diagnosing something like
that may requires tools like a spectrum analyzer.
>
>
> ath stats:
>
> 70777 data frames received
> 71551 data frames transmit
> 420 tx frames with an alternate rate
> 10821 long on-chip tx retries
> 260 tx failed 'cuz too many retries
> 11M current transmit rate
> 10489 tx management frames
> 1 tx frames discarded prior to association
> 786 tx frames with no ack marked
> 80516 tx frames with short preamble
> 54395 rx failed 'cuz of bad CRC
> 146438 rx failed 'cuz of PHY err
> 145013 CCK timing
> 1425 CCK restart
> 5295 beacons transmitted
> 19 periodic calibrations
> 42 rssi of last ack
> 31 avg recv rssi
> -98 rx noise floor
> 572 cabq frames transmitted
> 11 cabq xmit overflowed beacon interval
This should not happen. You have stations in power save mode in your
bss and the transmission of queued multicast frames overflowed the
interval following the beacon frame. This should be handled (I
explicitly tested it) but you might want to observe if this occurs when
you have problems.
> 1525 switched default/rx antenna
> Antenna profile:
> [1] tx41285 rx4
This makes no sense; you rx'd 4 frames total? That's inconsistent with
the "data frames received" counter and makes me question whether these
numbers are meani
Re: ath0 timeout problem - again
JoaoBR wrote: > 572 cabq frames transmitted > 11 cabq xmit overflowed beacon interval > > media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b So one other thing came to mind. If your ap is operating in 11b and you have many multicast frames q'd up for power save stations then they can effectively saturate the network if they are being trasnmitted at a low tx rate (which they would be). This can effectively DOS your wireless network because the frames are burst immediately following the beacon. The driver limits the burst interval so it does not overflow into the next beacon but it's allowed to fill all available time to the next beacon frame (something I've considered changing for just the reason I described). This has always been an issue. You might try rate limiting these frames or just hack the driver to violate the spec and not buffer them for tx after the beacon (to see if your problem goes away). Further, if you have a machine with a crappy pci bus (such as !4801 soekris boards) it's entirely possible that you are hoarding the bus with these long transmits s.t. other problems are occurring. I do not recommend building ap products out of such equipment. (No disrespect to the 4501, et al they just had substandard pci bus operation.) Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 issue
Lamont Granquist wrote: > > and ath_intr() is getting called all the time but status & HAL_INT_TX > isn't true so the task isn't getting enqueued. this is a 5 second stutter: > > Nov 28 21:39:48 warez kernel: ath_tx_proc_q0123: 1 > Nov 28 21:39:48 warez kernel: ath_intr: status 0x101 > Nov 28 21:39:48 warez kernel: ath_intr: status 0x109 > Nov 28 21:39:48 warez kernel: ath_intr: status 0x101 > Nov 28 21:39:48 warez kernel: ath_intr: status 0x109 > Nov 28 21:39:48 warez kernel: ath_intr: status 0x101 <...stuff truncated...> Using timestamps from syslog isn't going to give you any useful information since the data may be delayed getting to syslogd. Is there some reason you are not just sniffing the air? Assuming packets are being deferred because the medium is busy you might see a reason. Otherwise it appears (though it's impossible to tell from what you've shown so far) that the packets are handed to the h/w in a timely fashion. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 issue
Lamont Granquist wrote: > > > On Wed, 15 Nov 2006, Sam Leffler wrote: >> Snapshots are rarely useful; try running athstats 1 and correlate what >> you see with pauses. Another possible reason for deferred operation is >> something else in the system blocking the taskq threads; that's a bit >> trickier to diagnose. > > I threw in some printf()'s in the beginning of ath_start() and > ath_tx_proc_q0123() and see this: > > Nov 28 20:27:41 warez kernel: ath_tx_proc_q0123: 1 > Nov 28 20:27:41 warez kernel: ath_start > Nov 28 20:27:41 warez kernel: ath_start > Nov 28 20:27:41 warez kernel: ath_tx_proc_q0123: 1 > Nov 28 20:27:41 warez kernel: ath_start > Nov 28 20:27:45 warez last message repeated 13 times > Nov 28 20:27:45 warez kernel: ath_tx_proc_q0123: 1 > Nov 28 20:27:45 warez kernel: ath_start > Nov 28 20:27:45 warez kernel: ath_tx_proc_q0123: 1 > Nov 28 20:27:45 warez kernel: ath_start > Nov 28 20:27:45 warez kernel: ath_start > > this was during a time where i was pinging across this interface so that > every second it should have been transmitting at least one packet. the > 4 second stutter there where ath_tx_proc_q0123 wasn't being called > correllates with actual stutters in packet transmission. > > if i understand this, that's the taskq associated with transmission? > > TASK_INIT(&sc->sc_txtask, 0, ath_tx_proc_q0123, sc); > > No, that's the task q that reaps completed tx descriptors. You can't infer anything about when packets were transmitted from this. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 issue
Lamont Granquist wrote: > > > On Sun, 12 Nov 2006, Sam Leffler wrote: >> If tx stops in ap mode you need to figure out whether the h/w tx q is >> stalled or something else "above" is blocking outbound traffic. The >> usual things to check are: >> >> 1. are there resources in the driver to send a packet (e.g. buffers on >> the queue); if the tx q is full then the OACTIVE bit will be marked on >> the interface and visible with ifconfig > > during one of the period where tx was blocking i got ifconfigs that > looked like: > > ath0: flags=8843 mtu 1500 > inet 192.168.70.1 netmask 0xff00 broadcast 192.168.70.255 > ether 00:09:5b:c8:78:9c > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: associated > ssid lamontnet channel 1 bssid 00:09:5b:c8:78:9c > authmode OPEN privacy OFF txpowmax 30 bmiss 7 protmode CTS burst > dtimperiod 1 bintval 100 > > ath0: flags=8843 mtu 1500 > inet 192.168.70.1 netmask 0xff00 broadcast 192.168.70.255 > ether 00:09:5b:c8:78:9c > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: associated > ssid lamontnet channel 1 bssid 00:09:5b:c8:78:9c > authmode OPEN privacy OFF txpowmax 30 bmiss 7 protmode CTS burst > dtimperiod 1 bintval 100 > >> 2. if packets are queued to the h/w and not going out then you need to >> identify whether a higher priority frame is blocking them; this is >> harder but can occur when something like a beacon frame fails to go out >> or if there is cabq traffic q'd up behind the beacon frame that doesn't >> make it out >> 3. if none of the above is blocking traffic then h/w may consider the >> media busy; this can happen if your ap is operating in a busy >> environment and things like protection are being used heavily, or if you >> have an overlapping BSS that is operating in 11b > > i'm not certain how to go about collecting that information, but this is > a very lightly used wireless network with only the freebsd box and the > windows machine participating and the traffic is limited to the ssh > sessions that i setup and the usual windoze and dhcp chatter... > >> Often problems such as this are most easily understood by sniffing >> traffic from another station and looking for traffic patterns coincident >> with the event on the ap. > > i've only got the two wireless points right now, so i can't get a third > machine up to sniff... > >> More useful information can be found in the >> statistics collected by the driver (use athstats). > > here's a before and after of athstats which brackets one of these events: > > warez# ./athstats > 2243 data frames received > 2925 data frames transmit > 50 tx frames with an alternate rate > 947 long on-chip tx retries > 115 tx failed 'cuz too many retries > 2M current transmit rate > 982 tx management frames > 6 tx frames discarded prior to association > 242 tx frames with no ack marked > 2828 tx frames with short preamble > 2439 rx failed 'cuz of bad CRC > 28137 rx failed 'cuz of PHY err > 19620 OFDM timing > 8517 CCK timing > 150622 beacons transmitted > 534 periodic calibrations > 16 rssi of last ack > 19 avg recv rssi > -96 rx noise floor > 1 cabq frames transmitted > 33 switched default/rx antenna > Antenna profile: > [1] tx 1862 rx 6345 > [2] tx 1927 rx 6371 > warez# ./athstats > 2252 data frames received > 2937 data frames transmit > 50 tx frames with an alternate rate > 947 long on-chip tx retries > 115 tx failed 'cuz too many retries > 2M current transmit rate > 982 tx management frames > 6 tx frames discarded prior to association > 242 tx frames with no ack marked > 2840 tx frames with short preamble > 2440 rx failed 'cuz of bad CRC > 28145 rx failed 'cuz of PHY err > 19623 OFDM timing > 8522 CCK timing > 150659 beacons transmitted > 535 periodic calibrations > 22 rssi of last ack > 22 avg recv rssi > -96 rx noise floor > 1 cabq frames transmitted > 33 switched default/rx antenna > Antenna profile: > [1] tx 1874 rx 6371 > [2] tx 1927 rx 6371 > > Snapshots are rarely useful; try running athstats 1 and correlate what you see with pauses. Another possible reason for deferred operation is something else in the system blocking the taskq threads; that's a bit trickier to diagnose. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 issue
Lamont Granquist wrote: > > i did the same thing with running: > > while(1) > echo foo > sleep 1 > end > > in a window ssh'd into the machine with the ath0 driver, but with the > kernel recompiled with ATH_DEBUG and sysctl dev.ath.0.debug=0x > -- there should be packets sent every second while doing this. Not usually a good idea to enable so much debugging. The console printfs will alter operation. > > i saw the same behavior where tx packets would tend to spool up and > buffer. here's the output of one second where a bunch of spooled up > packets were sent alont with the previous second and following second > and with a note on how long it had been before any ath*tx* routine had > been called. hopefully this is useful for debugging -- i've got copious > amounts of debugging logs, so let me know if i've guessed wrongly about > what is relevant... > > this is the previous debugging notice for ath*tx* which i believe > indicates nothing > sent out on the interface since 11:17:36: If tx stops in ap mode you need to figure out whether the h/w tx q is stalled or something else "above" is blocking outbound traffic. The usual things to check are: 1. are there resources in the driver to send a packet (e.g. buffers on the queue); if the tx q is full then the OACTIVE bit will be marked on the interface and visible with ifconfig 2. if packets are queued to the h/w and not going out then you need to identify whether a higher priority frame is blocking them; this is harder but can occur when something like a beacon frame fails to go out or if there is cabq traffic q'd up behind the beacon frame that doesn't make it out 3. if none of the above is blocking traffic then h/w may consider the media busy; this can happen if your ap is operating in a busy environment and things like protection are being used heavily, or if you have an overlapping BSS that is operating in 11b Often problems such as this are most easily understood by sniffing traffic from another station and looking for traffic patterns coincident with the event on the ap. More useful information can be found in the statistics collected by the driver (use athstats). Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposed 6.2 em RELEASE patch
Without introduced this new patch, can I still use sysctl to maximise its performance like FAST_INTR? S On 11/9/06, Jack Vogel <[EMAIL PROTECTED]> wrote: This patch is an evolution of the last one I sent out. It has a couple of minor corrections, like a bad forward decl in the header. The last patch has had quite a bit of testing and all reports have been positive. The only complaint was from Gleb who says he needs to keep his beloved infinite for loop in the interrupt handler, well I have a better one for you Gleb, keep reading. I have also been doing some extreme stress testing using SmartBits, and discovered the driver as it stands is really not able to take extreme receive side pounding, Scott pointed out that this is why the FAST_INTR work was done :) There were some people that had stability issues with that work, but there were also many that did not. I actually merged the FAST code onto my last patch, and ran the SB stress and found it really was able to gracefully handle that load, way to go Scott :) I've pondered this situation, and this patch I'm including here today is the result. Here's what it does: If you drop it in place, compile it, and go... you will get the code that has been tested for a week, it uses the older style interrupts, it has the watchdog and other SMP fixes so its been proven. BUT, I've added the FAST_INTR changes back into the code, so if you go into your Makefile and add -DEM_FAST_INTR you will then get the taskqueue stuff. So, Gleb, rather than replace the infinite for loop that no one thinks is a good idea, you can just define FAST_INTR again, and you should be good to go. I see this as the best thing for the 6.2 RELEASE, it lets us keep moving forward, people that want max performance can define EM_FAST_INTR and help us wring out any problems, it also will mean that I will have our Intel test group start using this code. But for those that just want a stable driver the standard compile will still give them that. The patch I'm including is against BETA3. Let me know of your concerns or issues. Cheers, Jack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
Bill Moran wrote: [snip] >> The driver from HEAD (if_bce.c 1.17) is looking much better - thanks >> Scott! >> >> We couldn't trigger this bug using UDP NFS mounts. >> >> Neither could we trigger it with multiple simultaneous TCP connections. > > I'm seeing similar improvement. I've been testing the new version since > I came in this morning (About 2.5 hours so far), with no failures. [snip] Adding to the excitement, our band of attack squirrels haven't been able to bring down our 2950 yet with this one. We are using the if_bce.c from the HEAD w/ a small chunk about vlans commented out (for any wondering). We're trying outbound UDP_STREAM tests w/ netperf of big and small payloads to a machine on the same 100Mb switch. Nothing fancy, but what we could once crash in seconds now hangs tough till the end of the test. Sam -- Lumeta Corporation www.lumeta.com The world's most security conscious organizations rely on Lumeta to find and prioritize what's in IT, so they can manage and secure IT better. Lumeta Corporation 220 Davidson Ave, 4th Floor Somerset, NJ 08873 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD 6.2-PRE: todays cvsupdate break kernel build
O. Hartmann wrote: > Today's cvsupdate seems to break kernel build at this pint on FreeBSD > 6.2-PRE/AMD64: > > awk -f /usr/src/sys/modules/ata/atapicam/../../../conf/kmod_syms.awk > atapicam.ko export_syms | xargs -J% objcopy % atapicam.ko > objcopy --strip-debug atapicam.ko > ===> ath (all) > make: don't know how to make > /usr/src/sys/modules/ath/../../contrib/dev/ath/freebsd/ah_osdep.h. Stop > *** Error code 2 > > Stop in /usr/src/sys/modules. > *** Error code 1 Make sure you rebuild your dependencies; ah_osdep.[ch] moved from contrib/dev/ath to dev/ath. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 attach problems
Vulpes Velox wrote: > Any suggestions on this? The card in question one supplied by > Toshiba in their laptops. > > ath0: irq 17 at device 0.0 on pci3 > ath0: 0x1 bytes of rid 0x10 res 3 failed (0, 0x). > ath0: cannot map register space > device_attach: ath0 attach returned 6 > > > From lsci -v > > 03:00.0 Ethernet controller: Atheros Communications, Inc. Unknown > device 001c (rev 01) Subsystem: Askey Computer Corp. Unknown device > 7096 Flags: bus master, fast devsel, latency 0, IRQ 17 > Memory at (64-bit, non-prefetchable) > Capabilities: [40] Power Management version 2 > Capabilities: [50] Message Signalled Interrupts: 64bit- > Queue=0/0 Enable- Capabilities: [60] Express Legacy Endpoint IRQ 0 > Capabilities: [90] MSI-X: Enable- Mask- TabSize=1 This is likely an ACPI/ASL issue. I saw this on an hp nx6125 laptop when trying to use the express card slot. The BIOS did not identify how to map the resources associated with the bridge. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 802.11 RSSI value displayed from ifconfig(8)
Eduardo Meyer wrote: > Thank you Mr Leffler for this explanation. Honestly I did not know > about those tools. Very interesting, useful and some curious (say, > number of associations denied by wlan acl) information, which I > believe I will be able to produce some logs of it with audit support. > > But I did not find any "signal" information nor any value which looks > like dBm > > # athstats -i ath0 > 4 watchdog timeouts > 549821 tx management frames > 7 tx frames discarded prior to association > 1744404 tx stopped 'cuz no xmit buffer > 15 tx linearized to cluster > 97625 tx failed 'cuz too many retries > 9069518 long on-chip tx retries > 422577 tx frames with no ack marked > 62850632 tx frames with short preamble > 1700110 tx frames with an alternate rate > 24280171 rx failed 'cuz of bad CRC > 1 rx failed 'cuz frame too large > 62560031 rx failed 'cuz of PHY err >4211566 OFDM timing >101667 OFDM restart >58199442 CCK timing >47356 CCK restart > 31931664 beacons transmitted > 109058 periodic calibrations > rssi of last ack: 24 > 417831 switched default/rx antenna > Antenna profile: > [1] tx 31753038 rx 33886147 > [2] tx 31594701 rx 33711543 > > # wlanstats -i ath0 > 1509703 rx discard 'cuz dup > 335650 rx frame ssid mismatch > 2314 rx deauthentication > 377 rx disassociation > 4959 rx discard 'cuz acl policy > 1068 tx failed for no node > 3 active scans started > 142 nodes timed out inactivity > > Note that I am acting in hostap mode. Looks like you're not running HEAD or RELENG_6 or your system is not update recently. Sam > > On 9/27/06, Sam Leffler <[EMAIL PROTECTED]> wrote: >> Eduardo Meyer wrote: >> > Hello, I would like to convert RSSI to dBm (in fact I would love if >> > ifconfig cound display SNR in dBM), so I would like to know if this >> > formula is any right: >> > >> > /* Calculate the RSSI Value */ >> > V_RSSI = 3.0 * (RSSI_VAL/1024); >> > RSSI_dBM = (int8_t) ((-50.0 * V_RSSI) - 45.5); >> > >> > And if there are any other tools which can help me finding out signal >> > stenght, when I am acting as an access point. >> >> ifconfig reports rssi as whatever the driver provided. The intent is >> that it be a signed value relative to the current noise floor (both in >> dBm). If you look at the output of wlanstats >> (tools/tools/net80211/wlanstats) or, for ath devices, athstats >> (tools/tools/ath/athstats) you will see the default displays show >> "signal" which is rssi+noise-floor in dBm. The main issue(s) right now >> are that the net80211-driver api does not pass noise floor up so it can >> be reported to user apps and drivers reports rssi+nf in varying units. >> athstats doesn't have that issue since it queries the driver directly >> (hence it's display has a reasonable noise floor). >> >> It's on my todo list to push signal-related data up properly and fix >> ifconfig so it displays a proper signal strength in the normal status >> display. The issue of units is more difficult as converting data for >> some devices to dBm can be tricky. >> >> Sam >> > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
