Re: FreeBSD-8.0 802.11n support with ath/mwl

[Sam Leffler]

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: atheros broadcast/multicast corruption with multiple hostap's

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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.


Sam

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mai

Re: atheros broadcast/multicast corruption with multiple hostap's

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

Geoff Roberts wrote:
> Hi,
> 
> I had a working hostapd wireless access point configuration in FreeBSD 6.4. 
> The access point is being used by Windows XP workstations.
> 
> I was using WPA-EAP with freeradius authentication very successfully on the 
> 6.4 backend.
> 
> After making the changes for a new 8.0 RC2 (see below) system the XP clients 
> cannot seem to authenticate. The radius server does not even get contacted by 
> hostapd.
> 
> I can get WEP and WPA-PSK to work OK - just WPA-EAP fails to work in 8.0RC2.
> 
> I also have a dhcp server running to hand out dynamic addresses.
> 
> Please let me know if you have any suggestions as to how to debug the issue 
> further or where I may be going wrong.
> 
> 
> 
> hostapd.log is showing the following:
> 
> -> Startup
> Nov  8 23:06:26 freebsd hostapd: wlan0: IEEE 802.11 Fetching hardware 
> channel/rate support not supported.
> Nov  8 23:06:26 freebsd hostapd: wlan0: RADIUS Authentication server 
> xxx.xxx.xxx.xxx:1812
> -> When XP client tries to connect to AP
> Nov  8 23:08:43 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: 
> associated
> Nov  8 23:08:43 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: event 1 
> notification
> Nov  8 23:08:43 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.1X: 
> start authentication
> Nov  8 23:08:43 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: start 
> authentication
> Nov  8 23:08:43 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.1X: 
> unauthorizing port
> Nov  8 23:08:46 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.1X: 
> received EAPOL-Start from STA
> Nov  8 23:08:46 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: event 5 
> notification
> > Hangs here for a while
> Nov  9 00:32:23 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: 
> deassociated
> Nov  9 00:32:23 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: event 2 
> notification

Doesn't look like you're getting any debugging from hostapd so we cannot
see why it's giving up and dropping the station.

> 
> =
> 
> tcpdump -i wlan0:
> 
> 00:33:45.570161 xx:xx:xx:xx:xx:xx (oui Unknown) > Broadcast Null Supervisory, 
> Receiver not Ready, rcv seq 64, Flags [Poll], length 6
> 00:33:45.570174 xx:xx:xx:xx:xx:xx (oui Unknown) > Broadcast Null Supervisory, 
> Receiver not Ready, rcv seq 64, Flags [Poll], length 6
> 00:33:48.523053 EAPOL start (1) v1, len 0
> 
> 
> 
> ===
> dmesg:
> ath0:  mem 0xf900-0xf900 irq 16 at device 8.0 on pci1
> ath0: [ITHREAD]
> ath0: AR5212 mac 5.6 RF5111 phy 4.1
> ===
> 
> rc.conf
> 
> I have converted the 6.4 files from:
> 
> ifconfig_ath0="inet xxx.xxx.xxx.1 netmask xxx.xxx.xxx.192 mode 11g mediaopt 
> hostap"
> 
> to the newer 8.0 format:
> 
> wlans_ath0="wlan0"
> create_args_wlan0="wlanmode hostap mode 11g country Australia"
> ifconfig_wlan0="inet xxx.xxx.xxx.1 netmask xxx.xxx.xxx.192"
> ifconfig_wlan0_alias0="inet xxx.xxx.xxx.65 netmask xxx.xxx.xxx.192"
> ifconfig_wlan0_alias1="inet xxx.xxx.xxx.129 netmask xxx.xxx.xxx.192"
> ifconfig_wlan0_alias2="inet xxx.xxx.xxx.193 netmask xxx.xxx.xxx.192"
> 
> NOTE, I found the order of items in create_args_wlan0 important.

Yes, you cannot change the country code once the interface is marked UP
and that happens implicitly when you set the ip address on an ifnet.

> 
> 
> 
> I also adjusted the 6.4 hostapd.conf. Changes in 8.0RC2 are shown with ->
> =
> interface=ath0 -> wlan0
> driver=bsd
>  -> country_code=Australia

Not used by hostapd on freebsd (pretty sure).

> logger_syslog=-1
> logger_syslog_level=0
> logger_stdout=-1
> logger_stdout_level=0
> debug=4
> dump_file=/tmp/hostapd.dump
> ctrl_interface=/var/run/hostapd
> ctrl_interface_group=wheel
> ssid=netname
> macaddr_acl=0
> ieee8021x=1
> own_ip_addr=127.0.0.1
> auth_server_addr=xxx.xxx.xxx.xxx
> auth_server_port=1812
> auth_server_shared_secret=secretpw
> wpa=1
> wpa_key_mgmt=WPA-EAP
> wpa_pairwise=CCMP TKIP
> ===
> 
> Extra debugging output from wlandebug: 
> 
> Nov  9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] recv probe req
> Nov  9 00:44:07 freebsd kernel: wlan0: send probe resp on channel 1 to 
> xx:xx:xx:xx:xx:xx
> Nov  9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] recv probe req
> Nov  9 00:44:07 freebsd kernel: wlan0: send probe resp on channel 1 to 
> xx:xx:xx:xx:xx:xx
> Nov  9 00:44:07 freebsd kernel: wlan0: received auth from xx:xx:xx:xx:xx:xx 
> rssi 24
> Nov  9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] recv auth frame 
> with algorithm 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, 

Re: ral(4) on 8-RC1

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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)

[Sam Leffler]

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

[Sam Leffler]

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]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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)?

[Sam Leffler]

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: CFT: ath hal src switchover

[Sam Leffler]

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]

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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]

[Sam Leffler]

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]

[Sam Leffler]

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?

[Sam Leffler]

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/ ?)

[Sam Leffler]

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/ ?

[Sam Leffler]

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

[Sam Leffler]

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
suppose.

A workarou

Re: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7

[Sam Leffler]

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 without the PCM

Re: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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: hifn(4) causing system lockup

[Sam Leffler]

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: interrupt storms with AR5414 on 6.3 RELEASE

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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: weird problems on 7.0-BETA3

[Sam Leffler]

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

[Sam Leffler]

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?

[Sam Leffler]

Don Lewis wrote:

On 21 Nov, Chris wrote:
  

On 07/11/2007, Pyun YongHyeon <[EMAIL PROTECTED]> wrote:


On Wed, Nov 07, 2007 at 02:28:00PM +0200, Oleg Lomaka wrote:
 > Hello,
 >
 > Pyun YongHyeon wrote:
 > >On Thu, Nov 01, 2007 at 10:59:48AM +0200, Oleg Lomaka wrote:
 > > > Hello,
 > > >
 > > > Pyun YongHyeon wrote:
 > > > >On Tue, Oct 30, 2007 at 04:01:04PM +0200, Oleg Lomaka wrote:
 > > > >
 > > > >[...]
 > > > >
 > > > > > I had RxFIFO overrun again :(
 > > > > > from dmest:
 > > > > > msk0: Rx FIFO overrun!
 > > > >
 > > > >[...]
 > > > >
 > > > >Please try attached patch again. Sorry for the trouble.
 > > > >After applying the patch show me verbosed dmesg output related with
 > > > >msk(4)/PHY driver.
 > > > >
 > > > >Thanks for testing.
 > > > >
 > > > pcib1:  irq 16 at device 28.0 on pci0
 > > > pcib1:   domain0
 > > > pcib1:   secondary bus 2
 > > > pcib1:   subordinate bus   2
 > > > pcib1:   I/O decode0x2000-0x2fff
 > > > pcib1:   memory decode 0xd010-0xd01f
 > > > pcib1:   no prefetched decode
 > > > pci2:  on pcib1
 > > > pci2: domain=0, physical bus=2
 > > > found-> vendor=0x11ab, dev=0x4352, revid=0x14
 > > >domain=0, bus=2, slot=0, func=0
 > > >class=02-00-00, hdrtype=0x00, mfdev=0
 > > >cmdreg=0x0007, statreg=0x4010, cachelnsz=16 (dwords)
 > > >lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
 > > >intpin=a, irq=11
 > > >powerspec 2  supports D0 D1 D2 D3  current D0
 > > >MSI supports 2 messages, 64 bit
 > > >map[10]: type Memory, range 64, base 0xd010, size 14, enabled
 > > > pcib1: requested memory range 0xd010-0xd0103fff: good
 > > >map[18]: type I/O Port, range 32, base 0x2000, size  8, enabled
 > > > pcib1: requested I/O range 0x2000-0x20ff: in range
 > > > pcib1: slot 0 INTA routed to irq 16
 > > > mskc0:  port 0x2000-0x20ff mem
 > > > 0xd010-0xd0103fff irq 16 at device 0.0 on pci2
 > > > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd010
 > > > mskc0: MSI count : 2
 > > > mskc0: RAM buffer size : 4KB
 > > > mskc0: Port 0 : Rx Queue 2KB(0x:0x07ff)
 > > > mskc0: Port 0 : Tx Queue 2KB(0x0800:0x0fff)
 > > > msk0:  on mskc0
 > > > msk0: bpf attached
 > > > msk0: Ethernet address: 00:1b:24:0e:bc:26
 > > > miibus0:  on msk0
 > > > e1000phy0:  PHY 0 on miibus0
 > > > e1000phy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 > > > ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49
 > > > mskc0: [MPSAFE]
 > > > mskc0: [FILTER]
 > > >
 > >
 > >So far all looks good to me. If you encounter watchdog timeouts
 > >or Rx FIFO overruns let me know.
 > >
 > >
 >
 > Got it again:
 > msk0: Rx FIFO overrun!
 > I believe this is happening under heavy CPU usage. Now i have firefox
 > compiling and watched pictures on remote windows box using rdesktop. And
 > after few minutes got network freeze.

If it only happens under heavy system loads it's probably normal. If
system is too busy to serve other jobs the msk(4) may not recevie
more packets because its receive buffer was full. Probably msk(4)
should just count the overrun errors without printing the message
such that it would save more CPU cycles.
Btw, did you also see watchdog timeout errors?

 > But it looks i didn't get any packet lost :). Take a look at ping
 > statistics... funny...

I guess something is wrong here. Latency is unacceptable. However
I have no idea why ICMP echo reponse takes so long time. Are you
using any power saving mechanism(powerd, cpufreq etc)?

 > tdevil% ping 10.1.1.254
 > PING 10.1.1.254 (10.1.1.254): 56 data bytes
 > 64 bytes from 10.1.1.254: icmp_seq=0 ttl=64 time=35926.404 ms
 > 64 bytes from 10.1.1.254: icmp_seq=1 ttl=64 time=34925.694 ms
 > 64 bytes from 10.1.1.254: icmp_seq=2 ttl=64 time=33924.729 ms
 > 64 bytes from 10.1.1.254: icmp_seq=3 ttl=64 time=32923.814 ms
 > 64 bytes from 10.1.1.254: icmp_seq=4 ttl=64 time=31922.833 ms
 > 64 bytes from 10.1.1.254: icmp_seq=5 ttl=64 time=30921.878 ms
 > 64 bytes from 10.1.1.254: icmp_seq=6 ttl=64 time=29920.923 ms
 > 64 bytes from 10.1.1.254: icmp_seq=7 ttl=64 time=28919.960 ms
 > 64 bytes from 10.1.1.254: icmp_seq=8 ttl=64 time=27919.009 ms
 > 64 bytes from 10.1.1.254: icmp_seq=9 ttl=64 time=26918.042 ms
 > 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 ti

Re: ath support for mini-pci 802.11n card?

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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]"

Re: ath0 induced panic additional info

[Sam Leffler]

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: em0 watchdog timeout with nfs

[Sam Leffler]

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]"

Re: Atheros wireless card channel conflict - unable to reset hardware

[Sam Leffler]

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: sysinstall creates corrupt filesystems after repartitioning

[Sam Leffler]

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?

[Sam Leffler]

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: Panic: 6.2-STABLE/RELEASE, sysctl (on boot) -- ath related

[Sam Leffler]

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

[Sam Leffler]

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: Panic: 6.2-STABLE/RELEASE, sysctl (on boot) -- ath related

[Sam Leffler]

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]

[Sam Leffler]

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

[Sam Leffler]

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?]

[Sam Leffler]

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

[Sam Leffler]

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: ath0 timeout problem - again

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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 meaningful.
> 
> 
> ifconfig
> 
> ath0: flags=8943 mtu 1500
> ether 00:13:46:8b:f1:86
> media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b 
> status: associated
> ssid omegasul channel 1 (2412) bssid 00:13:46:8b:f1:86
> authmode OPEN privacy ON deftxkey 1
> wepkey 1:40-bit
> wepkey 2:40-bit
> wepke

Re: ath0 timeout problem - again

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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

[Sam Leffler]

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: FBSD 6.2-PRE: todays cvsupdate break kernel build

[Sam Leffler]

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

[Sam Leffler]

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)

[Sam Leffler]

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]"

Re: 6.2-PRERELEASE/amd64 boot kernel.gz failes

[Sam Leffler]

Danny Braniss wrote:
> originally posted to [EMAIL PROTECTED]:
> 
> Hi,
>   While trying to figure out why boot/pxeboot failes on some
> kernels/hosts, I think i've come up with one solid nogo,
> if the kernel is gzipped it always fails.
>   Can someone confirm this? or am i suffering from some
> local problem?

I believe I've seen this before when booting i386 kernels from soekris
boards.  I've taken to using pxeboot to load netboot and then use
netboot to load a kernel as the netboot drivers are way faster (for
soekris at least).  Hopping through netboot also lets you have a menu to
select one of several kernels to load.

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)

[Sam Leffler]

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]"

Re: ath0 weak connectivity

[Sam Leffler]

Sten Daniel Sørsdal wrote:
> Sam Leffler wrote:
>> I've lost context about your problem but it appears you're having
>> trouble associating with "trejago" sometimes.  The failed scan shows
>> that your rssi was only 6 when you were having problems which is a very
>> marginal signal so I'm not at all surprised you're having trouble.
>> You've got strong signal ap's on overlapping channels (5 and 7) which
>> are likely drowning the signal on your ap.  I don't see anything the
>> driver could do differently; this seems more an issue of your
>> environment being very busy.  I vaguely recall you were comparing the
>> operation of the freebsd to windows.  If so then perhaps the windows
>> driver was doing better because it switched to XR mode and operating in
>> XR mode you were able to punch through the noise to get to the ap.
>> freebsd does not support XR mode.
>>
>>  Sam
>>
> 
> Are there any plans to support this?

XR mode, no--at least not in sta mode.

> What about fastframes/bursting? 10Mhz, 5Mhz channels?

Bursting has been there forever.  Fast frames have been in p4 for nearly
2 years; no plans to commit to cvs.  Variable channel width is probably
something to deal with soon; it's been implemented in other code bases
but not in a way I'm happy with.

> WDS? Virtual AP? Is there any place where i can read about this?

I recently did another WDS implementation that's quite nice but depends
on VAP's.  The vap support, as I've said many times, won't come into cvs
until developers appear to take responsibility for legacy wireless
drivers (just too much work for me to do by myself).

> Apologies if any of these are already in the works.
> 

I'd hoped to see some movement on this stuff but w/o help much of the
work done over the past 2 years will continue to sit outside cvs.

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 weak connectivity

[Sam Leffler]

Dmitry Karasik wrote:
>   Hi Sam!
> 
>  Sam> I do not understand what "bad connectivity" means.  
> 
> I'm not a native speaker so I've apparently used a wrong term, I apologize
> for the confusion. Instead I should've probably said "low signal strength".
> 
>  Sam> If you provide
>  Sam> information like the mac+phy revs for the card, hal version, and
>  Sam> statistics from programs like athstats then it might be possible to
>  Sam> identify what's wrong.  Otherwise look at turning on debugging at the
>  Sam> net80211 layer with wlandebug.  Both athstats and wlandebug are found
>  Sam> in src/tools/tools (under net80211 and ath respectively).
> 
> Here it is:
> 
> dmesg:
> 
>  mem 0xa840-0xa840 irq 11 at device 2.0 on pci4
> ath0: [GIANT-LOCKED]
> ath0: Ethernet address: 00:14:a4:80:f6:74
> mac 5.9 phy 4.3 radio 3.6
> 
> sysctl -a | grep ath | grep hal:
> 
> hw.ath.hal.version: 0.9.16.16
> hw.ath.hal.dma_brt: 2
> hw.ath.hal.sw_brt: 10
> hw.ath.hal.swba_backoff: 0
> 
> Output after wlandebug +debug scan is too large to be quoted on the list,
> so please take a look here: http://www.karasik.eu.org/misc/ath0.html ,
> probably you can find anything suspicious?
> 

I've lost context about your problem but it appears you're having
trouble associating with "trejago" sometimes.  The failed scan shows
that your rssi was only 6 when you were having problems which is a very
marginal signal so I'm not at all surprised you're having trouble.
You've got strong signal ap's on overlapping channels (5 and 7) which
are likely drowning the signal on your ap.  I don't see anything the
driver could do differently; this seems more an issue of your
environment being very busy.  I vaguely recall you were comparing the
operation of the freebsd to windows.  If so then perhaps the windows
driver was doing better because it switched to XR mode and operating in
XR mode you were able to punch through the noise to get to the ap.
freebsd does not support XR mode.

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 weak connectivity

[Sam Leffler]

Radu Adrian Zdrinca wrote:
> I have had similar problems with the driver. The signal quality in
> Windows is higher. But there are other problems. For example, when I
> start Limewire I have to wait for about 3 minutes before it loads. I
> am sure this is a problem with ath interface.

How do you know the signal quality in Windows is higher?

I know nothing about Limewire and cannot say why you think problems with
it are related to ath.  Regardless, read my response to the original
poster; I can't offer advise w/o meaningful information.

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 weak connectivity

[Sam Leffler]

Dmitry Karasik wrote:
> Hi,
> 
> Has anyone experienced problems with ath0 giving bad connectivity on
> 6.1-STABLE? My wireless card reported as Atheros 5212 rapidly loses
> connectivity if I move it more than 2-3 meters away from the access
> point, but the same notebook connects well from under windows.
> 
> I tried both kernel with both old device ath_rate_sample and ath_rate_onoe,
> tried to play with AP's settings, changed transmit rate and beacon
> interval, nothing helps. One interesting thing though is that "ifconfig ath0
> scan" reports my station as configured to 119ms beacon interval, while
> it is set to 100ms actually.
> 
> Anything else I can try?
> 

ifconfig ath0 scan doesn't report your local configuration, it triggers
a scan and reports the scan results.  If your local station thinks the
beacon internal is 119ms when it's really 100ms then something is very
confused but it's unlikely to cause "bad connectivity" (unless you're
operating the station in power save mode which isn't currently possible).

I do not understand what "bad connectivity" means.  If you provide
information like the mac+phy revs for the card, hal version, and
statistics from programs like athstats then it might be possible to
identify what's wrong.  Otherwise look at turning on debugging at the
net80211 layer with wlandebug.  Both athstats and wlandebug are found in
src/tools/tools (under net80211 and ath respectively).

Sam
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Where is the maximum of hw.ath.txbuf and rxbuf ? (former: atheros driver under high load, panics and even more freezes)

[Sam Leffler]

Daniel Dvořák wrote:
> Hi Sam,
> 
> thank you for your answer. I think it is connected to this problem
somehow, but not fully.
> 
> I increased txbuf and rxbuf twice to 200 and 80, I saw some
> betterment
in less of "no buffers space ...", but latency went up to 2000 ms.
> 
> Now I ended at txbuf=800 and rxbuf=320 on both sides R1 and R2.
> 
> But still, there is the same problem:
> 
> It was tested after the rebooting R2 almost at once.
> 
> --- R1 ping statistics ---
> 1 packets transmitted, 8752 packets received, 12% packet loss
> round-trip min/avg/max/stddev = 1.324/920.480/6323.454/766.399 ms   
> up to 6k ms
> 
> R2# athstats -i ath0
> 11309 data frames received
> 11384 data frames transmit
> 12508 long on-chip tx retries
> 769 tx failed 'cuz too many retries
> 24M current transmit rate
> 2 tx management frames
> 6 tx frames discarded prior to association
> 31 tx stopped 'cuz no xmit buffer
> 38 tx frames with no ack marked
> 3 rx failed 'cuz of bad CRC
> 4464 rx failed 'cuz of PHY err
> 4464 OFDM timing
> 24 periodic calibrations
> 27 rssi of last ack
> 27 avg recv rssi
> -96 rx noise floor
> 1 switched default/rx antenna
> Antenna profile:
> [1] tx10614 rx11449
> 
> 
> Where is the maximum of txbuf and rxbuf ?

The max is derived from available memory.  The h/w has no upper bounds.

> 
> I would like to test it.
> 
> Thank you for your attention.
> 
> Daniel
>  
> 
>> -Original Message-
>> From: Sam Leffler [mailto:[EMAIL PROTECTED] 
>> Sent: Friday, September 08, 2006 6:30 AM
>> To: [EMAIL PROTECTED]
>> Cc: freebsd-stable@freebsd.org
>> Subject: Re: atheros driver under high load, panics and even 
>> more freezes
>>
>> Daniel Dvoøák wrote:
>>> Hi Sam and all,
>>>
>>> I am not sure if I understand your answer, but I try it.
>>>
>>> When I use start my test, athstats shows this:
>>>
>>> athstats -i ath0
>>>
>>> 19308912 data frames received
>>> 15723536 data frames transmit
>>> 6536 tx frames with an alternate rate
>>> 2188280 long on-chip tx retries
>>> 62583 tx failed 'cuz too many retries
>>> 348 tx linearized to cluster
>>> 24M current transmit rate
>>> 6 tx management frames
>>> 6 tx frames discarded prior to association
>>> 27129 tx stopped 'cuz no xmit buffer
>>> 23057 tx frames with no ack marked
>>> 1182 rx failed 'cuz of bad CRC
>>> 761604 rx failed 'cuz of PHY err
>>> 761604 OFDM timing
>>> 4829 periodic calibrations
>>> 28 rssi of last ack
>>> 27 avg recv rssi
>>> -96 rx noise floor
>>> 1 switched default/rx antenna
>>> Antenna profile:
>>> [1] tx 15660942 rx 19451935
>>> [2] tx2 rx0
>>>
>>> ...
>>>
>>>
>>> I use this ping command from R2:
>>> ping -i .002 -c 1 -s 1472 opposite side R1
>>>
>>> --- R1 ping statistics ---
>>> 1 packets transmitted, 1 packets received, 0% packet loss 
>>> round-trip min/avg/max/stddev = 1.316/1.442/49.391/1.757 ms
>>>
>>> You can see nice average latency about 1,4 ms and no one 
>> packet was lost.
>>> athstats almost wasn´t changed.
>>>
>>> 19309465 data frames received
>>> 15724079 data frames transmit
>>> 6536 tx frames with an alternate rate
>>> 2188281 long on-chip tx retries
>>> 62583 tx failed 'cuz too many retries
>>> 348 tx linearized to cluster
>>> 24M current transmit rate
>>> 6 tx management frames
>>> 6 tx frames discarded prior to association
>>> 27129 tx stopped 'cuz no xmit buffer
>>> 23075 tx frames with no ack marked
>>> 1182 rx failed 'cuz of bad CRC
>>> 761605 rx failed 'cuz of PHY err
>>> 761605 OFDM timing
>>> 4834 periodic calibrations
>>> 29 rssi of last ack
>>> 27 avg recv rssi
>>> -96 rx noise floor
>>> 1 switched default/rx antenna
>>> Antenna profile:
>>> [1] tx 15661485 rx 19452488
>>> [2] tx2 rx0
>>>
>>> For compare with flood ping at once:
>>>
>>> --- R1 ping statistics ---
>>> 1 packets transmitted, 1 packets received, 0% packet loss 
>>> round-trip min/avg/max/stddev = 1.319/1.516/5.594/0.120 ms
>>>
>>> Almost the same, yes max is even better.
>>>
>>>
>> --

Re: panic: integer divide fault on 6.1

[Sam Leffler]

Joao Barros wrote:
> On 9/9/06, Kris Kennaway <[EMAIL PROTECTED]> wrote:
>> On Sat, Sep 09, 2006 at 09:02:35PM +0100, Joao Barros wrote:
>> > On 9/9/06, Max Laier <[EMAIL PROTECTED]> wrote:
>> > >
>> > >Can you try to get a dump, trace, or at least figure out which
>> function
>> > >the IP is refering to?
>> > >
>> >
>> > Well, the problem only occurs when I boot from the disk and the
>> > installed kernel doesn't have debug support.
>> > Does 'set dumpdev=' work from the boot loader? I tried some
>> > combinations with no success.
>>
>> No.
>>
>> > I can try and install a 6-STABLE snapshot if there's no way of getting
>> > the info needed.
>>
>> You can either try to install a new kernel with DDB support, or follow
>> the "instruction pointer" method in the developers handbook chapter on
>> kernel debugging.
> 
> I copied a CURRENT kernel from a 200608 snapshot and the problem also
> occurs thus I'm adding [EMAIL PROTECTED]
> My current laptop doesn't have a serial port so I'm copying this by hand:
> 
> Fatal trap 18: integer divide fault while in kernel mode
> cpuid = 0; apic id = 00
> instruction pointer = 0x20:0xc08a1fb7
> stack pointer   = 0x28:0xc0c20b14
> frame pointer   = 0x28:0xc0c20b9c
> code segment= base 0x0, limit 0xf, type 0x1b
>   = DPL 0, pres 1, def32 1, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 0 (swapper)
> [thread pid 0 tid 0 ]
> Stopped at__qdivrem+0x3b: divl%ecx,%eax
> 
> db> bt
> Tracing pid 0 tid0 td 0xc0a0c818
> __qdivrem(37fdfa0,0,0,0,0,...) at __qdivrem+0x3b
> __udivdi3(37fdfa0,0,0,0) at __udivdi3+0x16
> ata_raid_promise_read_meta(c37a5000,c09f4a80,1,8086,c37a5000,...) at
> ata_raid_promise_read_meta+0x9b
> ata_raid_read_metadata(c37a5000,c37a5000,c0c20c70,c06b58a4,c37a5000,...)
> at ata_raid_metadata+0x2be
> ata_raid_subdisk_attach(c37a5000) at ata_raid_subdisk_attach+0x33
> device_attach(c37a5000,c37a5180,c37a5000,c36885c0,0,...) at
> device_attach+0x58
> device_probe_and_attach(c37a5200,c37a5200,c08ec9a9,0,c37a5180,...) at
> bus_generic_attach+0x16
> ad_attach(c37a5200) at ad_attach+0x2c8
> device_attach(c37a5200,c095f2d0,c37a5200,0,c368d800,...) at
> device_attach+0x58
> device_probe_and_attach(c37a5200) at device_probe_and_atach+0xe0
> bus_generic_attach(c3659080,c3659080,,0,c37a5200,...) at
> bus_generic_attach+0x16
> ata_identify(c3659080) at ata_identify+0x1c8
> ata_boot_attach(0xc0a11d80,0,c09212e7,47,...) at ata_boot_attach+0x3e
> run_interrupt_drive_config_hooks(0,c1ec00,c1e000,0,c0451065,...) at
> run_interrupt_drive_config_hooks+0x43
> mi_startup() at mi_startup+0x96
> begin() at begin+0x2c
> 
> This board has a Promise SATA raid controller and it is disabled in
> the BIOS. I even tried disabling it through a jumper but it still
> stops.
> 

In sys/dev/ata/ata-raid.h the PROMISE_LBA macro does an unchecked
calculation that apparently can divide by zero.  Soren would likely
understand the root cause of this problem but until then you can patch
the driver to workaround 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: atheros driver under high load, panics and even more freezes

[Sam Leffler]

Daniel Dvoøák wrote:
> Hi Sam and all,
> 
> I am not sure if I understand your answer, but I try it.
> 
> When I use start my test, athstats shows this:
> 
> athstats -i ath0
> 
> 19308912 data frames received
> 15723536 data frames transmit
> 6536 tx frames with an alternate rate
> 2188280 long on-chip tx retries
> 62583 tx failed 'cuz too many retries
> 348 tx linearized to cluster
> 24M current transmit rate
> 6 tx management frames
> 6 tx frames discarded prior to association
> 27129 tx stopped 'cuz no xmit buffer
> 23057 tx frames with no ack marked
> 1182 rx failed 'cuz of bad CRC
> 761604 rx failed 'cuz of PHY err
> 761604 OFDM timing
> 4829 periodic calibrations
> 28 rssi of last ack
> 27 avg recv rssi
> -96 rx noise floor
> 1 switched default/rx antenna
> Antenna profile:
> [1] tx 15660942 rx 19451935
> [2] tx2 rx0
> 
> ...
> 
> 
> I use this ping command from R2:
> ping -i .002 -c 1 -s 1472 opposite side R1
> 
> --- R1 ping statistics ---
> 1 packets transmitted, 1 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 1.316/1.442/49.391/1.757 ms
> 
> You can see nice average latency about 1,4 ms and no one packet was lost.
> 
> athstats almost wasn´t changed.
> 
> 19309465 data frames received
> 15724079 data frames transmit
> 6536 tx frames with an alternate rate
> 2188281 long on-chip tx retries
> 62583 tx failed 'cuz too many retries
> 348 tx linearized to cluster
> 24M current transmit rate
> 6 tx management frames
> 6 tx frames discarded prior to association
> 27129 tx stopped 'cuz no xmit buffer
> 23075 tx frames with no ack marked
> 1182 rx failed 'cuz of bad CRC
> 761605 rx failed 'cuz of PHY err
> 761605 OFDM timing
> 4834 periodic calibrations
> 29 rssi of last ack
> 27 avg recv rssi
> -96 rx noise floor
> 1 switched default/rx antenna
> Antenna profile:
> [1] tx 15661485 rx 19452488
> [2] tx2 rx0
> 
> For compare with flood ping at once:
> 
> --- R1 ping statistics ---
> 1 packets transmitted, 1 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 1.319/1.516/5.594/0.120 ms
> 
> Almost the same, yes max is even better.
> 
> 
> --
> 
> If I use interval 1/1000 s to send the echo request, the situation is
> rapidly changed.
> ping -i .001 -c 1 -s 1472 opposite side R1
> 
> --- R1 ping statistics ---
> 1 packets transmitted, 9681 packets received, 3% packet loss
> round-trip min/avg/max/stddev = 1.319/335.806/564.946/170.691 ms
> 
> R2# ifconfig -v ath0
> ath0: flags=8c43 mtu 1500
> -- ??? OACTIVE FLAG ? 
> inet6 fe80::20b:6bff:fe2a:c78e%ath0 prefixlen 64 scopeid 0x2
> inet 10.XX.YY.ZZ netmask 0xfffc broadcast 10.40.64.19
> ether 
> media: IEEE 802.11 Wireless Ethernet OFDM/24Mbps mode 11a
>  (OFDM/24Mbps)
> status: associated
> 
> 19350739 data frames received
> 15765446 data frames transmit
> 6536 tx frames with an alternate rate
> 2194842 long on-chip tx retries
> 62590 tx failed 'cuz too many retries
> 348 tx linearized to cluster
> 24M current transmit rate
> 6 tx management frames
> 6 tx frames discarded prior to association
> 29242 tx stopped 'cuz no xmit buffer
> 23155 tx frames with no ack marked
> 1182 rx failed 'cuz of bad CRC
> 764641 rx failed 'cuz of PHY err
> 764641 OFDM timing
> 4856 periodic calibrations
> 28 rssi of last ack
> 27 avg recv rssi
> -96 rx noise floor
> 1 switched default/rx antenna
> Antenna profile:
> [1] tx 15702845 rx 19493774
> [2] tx2 rx0
> 
> I observe flags of ath and when latency is going to high more and more,
> there is a new flag which I´ve never seen before, OACTIVE FLAG ?
> 
> R2# man ifconfig | grep "OACTIVE"
> 
> When ping ends oactive flag disappears.
> 
> When the same ping test is done from linux box to fbsd, nice latency 1,2ms
> and no "no buffer".
> 
> with -i 0.002 the throughput is about 0,5MB/s in and out of cource
> 
> with -i 0.001 until no buffer is about 0,85MB/s in and out.
> 
> when no buffer and octive appears, the throughput is about 0,1MB/s or
> 128KB/s if you like or 1Mbit/s.
> 
> I attached the progress of pinging ip address.

You ask why you're seeing OACTIVE when you lower the inter-packet wait
time to ping.  This is because you're flooding the tx queue of the ath
driver and using up all the tx buffers/descriptors.  When ath is handed
a frame to send and it has no resources available it will mark the
interface "active' (OACTIVE) and drop the packet.  You can also see this
in the athstats output ("tx stopped 'cuz no xmit buffer").  Linux
behaves differently because it blocks the user process when this happens
 until such time as there are resources to do the send.  This behaviour
likely also explains the variability in the ping times; I think the rx
processing may be deferred while the driver deals with the tx flood.

You can up the number o

Re: missed hostapd / ath MFC warning?

[Sam Leffler]

Volker wrote:
> Hi folks,
> 
> I've recently (september 3rd) csup'ed RELENG_6 and made a
> buildkernel && buildworld process.
> 
> After the reboot hostapd doesn't work as expected. Did I miss a MFC
> warning for ath / hostapd?
> 
> hostapd just says:
> bellona# hostapd -dd /etc/hostapd.conf
> Configuration file: /etc/hostapd.conf
> bsd_set_iface_flags: dev_up=0
> bsd_get_ssid: ssid="vtec"
> Using interface ath0 with hwaddr 00:09:5b:89:7d:1f and ssid 'vtec'
> bsd_set_ieee8021x: enabled=1
> bsd_configure_wpa: group key cipher=TKIP (1)
> bsd_configure_wpa: pairwise key ciphers=0x2
> bsd_configure_wpa: key management algorithms=0x2
> bsd_configure_wpa: rsn capabilities=0x0
> bsd_configure_wpa: enable WPA= 0x1
> bsd_set_iface_flags: dev_up=1
> bsd_set_privacy: enabled=1
> WPA: group state machine entering state GTK_INIT
> GMK - hexdump(len=32): 33 e9 d7 a0 86 d2 4f 23 5b a8 21 f7 ed ef cf
> 57 ae 2b 29 5e 8e 5e 91 a8 92 9b 0b dd fa 10 28 ac
> GTK - hexdump(len=32): 8e 9c 18 a4 59 ca 79 bc 04 01 9f e2 82 a5 5b
> 17 94 d7 fd e8 e2 7e 65 30 bf de 9b 5f 9b 72 b3 f5
> WPA: group state machine entering state SETKEYSDONE
> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1
> Flushing old station entries
> bsd_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=3
> Deauthenticate all stations
> 
> .and all looks fine.
> 
> ifconfig ath0 says:
> ath0: flags=8843 mtu 2290
> ether 00:09:5b:89:7d:1f
> media: IEEE 802.11 Wireless Ethernet autoselect
> status: no carrier
> ssid vtec channel 9
> authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP
> 3:128-bit
> txpowmax 30 bmiss 7 protmode CTS burst bintval 100
> 
> I just get a 'no carrier' and so no client system is able to see the
> AP. There's no configuration change just a recently csup'ed and
> rebuild system.
> 
> Is there something I've overseen?

ath0 is not set in hostap mode.

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 driver under high load, panics and even more freezes

[Sam Leffler]

Daniel Dvořák wrote:
> Ok, I will upgrade my boxes and I will do simple ping tests again.
> 
> Did you see my sysctl.conf file ?
> 
> I mean these options:
> 
> kern.ipc.maxsockbuf=2097152
> net.inet.ip.fastforwarding=1
> net.inet.tcp.sendspace=65536
> 
> Could be this connected with increasing latency up to 500ms ?

Seems unlikely but I have little to go on.  You can easily identify
whether the delays are in the OS or due to wireless issues by sniffing
traffic.  Tools like athstats are also important for diagnosing problems.

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 driver: countrycode and athdebug

[Sam Leffler]

Daniel Dvoøák wrote:
>> You can override the country code but the potential values 
>> depends on the regdomain.  I thought hw.ath.countrycode was 
>> r/w but it appears you can only set via the tunable api (kenv 
>> hw.ath.countrycode=XXX).  The dev.ath mib must be r/o since 
>> you cannot (yet) change this after attaching the device (the 
>> driver does not implement it).  Adding support to do this is 
>> not a big deal but hasn't been done; feel free to supply a patch.
>>
> 
> Ok, I tried to set via the tunable api kenv through loader, but this is the
> result:
> 
> # ifconfig ath0
> ifconfig: interface ath0 does not exist
> # ifconfig ath1
> ifconfig: interface ath1 does not exist
> 
> ath0:  mem 0x8000-0x8000 irq 12 at device 13.0 on pci0
> ath0: unable to collect channel list from hal; regdomain likely 96 country
> code
> 203
> device_attach: ath0 attach returned 22
> 
> ath1:  mem 0x800c-0x800c irq 9 at device 17.0 on pci0
> ath1: unable to collect channel list from hal; regdomain likely 96 country
> code
> 203
> device_attach: ath1 attach returned 22
> 
> ath0:  mem 0x8000-0x8000 irq 12 at device 13.0 on pci0
> ath0: unable to collect channel list from hal; regdomain likely 96 country
> code 203
> device_attach: ath0 attach returned 22
> 
> ath1:  mem 0x800c-0x800c irq 9 at device 17.0 on pci0
> ath1: unable to collect channel list from hal; regdomain likely 96 country
> code 203
> device_attach: ath1 attach returned 22
> 
> # sysctl hw.ath
> hw.ath.hal.version: 0.9.17.2
> hw.ath.hal.dma_brt: 2
> hw.ath.hal.sw_brt: 10
> hw.ath.hal.swba_backoff: 0
> hw.ath.dwell: 200
> hw.ath.calibrate: 30
> hw.ath.outdoor: 1
> hw.ath.xchanmode: 1
> hw.ath.countrycode: 203
> hw.ath.regdomain: 0 -- not setted to 96 
> hw.ath.rxbuf: 40
> hw.ath.txbuf: 100
> 
> So ? I don´t know. :)

Your card has a regdomain in the eeprom that is 96.  I believe that's
the FCC regdomain.  With that regdomain you cannot specify any country
code except US.  The hw.ath mib tree mostly contains "default settings"
that are applied to instances of the ath driver as they are attached.
The hw.ath.regdomain is there in case I'm able to add the ability to
override the eeprom regdomain at some point the future (something high
on my todo list).  In the mean time it is well known how to deal with
this situation--take a look at the madwifi.org web pages.

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 driver under high load, panics and even more freezes

[Sam Leffler]

Daniel Dvoøák wrote:
> Hi all,
>  
> first of all, I´m sorry maybe for my bad English.
>  
> We have 2 routers which I maintain in our mesh wireless community network.
>  
> The Router 1 has 2 atheros adapters, ath0=wistron cm9, ath1=wistron cm10, of
> course some sisX, fxpX and so on.
> The Router 2 has 1 atheros adapter, ath1=wistron CM10.
>  
> My R1 panics and even more it freezes very often. Maybe the reason for
> panicing and freezing is the same and maybe not.
>  
> I started  (only after vmcore.5, so vmcore.6 is with this option)  to use
> "option SW_WATCHDOG" in both my custom kernels on the R1 and R2 recently in
> hope, it is some walkaround for freezing at least if not for panicing. 
>  
> This router was installed on the 1st of April 2006.
>  
> Statistics:
>  
> 9 panics with 8 kernel dumps, 1 missed
>  
> 10 freezes
>  
> I think that all panics some how connected to athX taskq process, page fault
> in kernel panic and sbflush_locked.

Why?

>  
> I guess that panic comes when router transmits and receives datas at the
> maximum throughput for setted nominal media rate speed, exactly 24Mbps, more
> I do not use, because there are problems with quagga 
>  
> ospfd packets, it is known issue.
>  
> Today I did a small test with throughput.
>  
> Router 1 executed this command:
>  
> # ping -i 0.001 -c 10 -s 1472 ANY IP
>  
> As you see, it is not even flood ping, it is almost flood, but not flood.
>  
> Throughput was about 1,13-1,2 MB/s as bmon showed me. I notice there is not
> any qos and icmp.limit is so high net.inet.icmp.icmplim: 2147483647
> net.ineticmp.icmplim_output: 0.
> 
>  
> First 5 s latency was about 1,1-1,7 ms
> After it goes to 10-30, 50-70, 110-130, 270-300, up 300ms and packet loss
>  
>  some seconds 
>  
> panic

<...lots of stuff deleted...>

Sounds like a resource leak to me.  You've got crash dumps, look at
memory usage with vmstat and/or netstat.  Past that it sounds like
you're running 6.1 RELEASE which is now 6+ months old.  Many bugs have
been fixed including, I believe, some resource-related ones.  Please try
6-STABLE.

Sam

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Suspend freezes system on my Thinkpad X41

[Sam Leffler]

Jordan Sissel wrote:
> Subject says it all. Attempting FN+F4 (suspend) or acpiconf -s 3 or -s 4
> all
> cause the system to halt.
> 
> Specs:
> Thinkpad X41
> 6.1-RELEASE GENERIC
> Atheros 5212
> Broadcom BCM5751M
> SATA (ICH6 SATA150)
> 
> Freezes are non-recoverable. Even hardware functions (such as lcd dimming)
> cease. Seems like the system has half suspended, but the LCD is still on
> and
> displaying. Sleep light doesn't blink indicating sleepiness.
> 
> Any help on this would be greatly appreciated :)

"Atheros 5212" is too imprecise; please give mac+phy rev's from
dmesg|grep ath.  Otherwise, try taking ath out of your kernel config to
see if you can suspend+resume.  I've got an outstanding issue with ath
in how suspend+resume is handled--for cardbus cards at least (never seen
it with minipci).

Sam
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

CFT: ipw driver update

[Sam Leffler]

If you use ipw please try a new version at:

http://www.freebsd.org/~sam/ipw-20060710.tgz

This code should work with wpa_supplicant, recognize beacon miss (i.e.
roam), implement the rfkill radio switch, etc.  It should work on both
HEAD and RELENG_6.

There are still some rough edges as the ipw firmware has some quirks but
I believe it's an improvement over what's in the tree.  Beware of bugs;
it's only been lightly tested.

Note that you'll need the ipw firmware packaged as modules.  This is the
way things are in HEAD but not RELENG_6.  The ipw-firmware-kmod port
currently won't allow installation on a RELENG_6 system; you'll need to
defeat the check in the Makefile to install the necessary firmware.

If you hit issues please try to collect a debug log by setting

sysctl debug.ipw=1

(or higher if needed); msgs go to the console.

Sam
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: "scan stuck" with if_iwi(4)

[Sam Leffler]

Sam Leffler wrote:
> Andrew Thompson wrote:
>> On Wed, Jul 26, 2006 at 01:28:12PM -0700, Sam Leffler wrote:
>>> Henrik Brix Andersen wrote:
>>>> Oh? Sounds interesting, where can I find these patches?
>>> The work has always been in perforce.freebsd.org; look in the sam_wifi
>>> branch.  The code will not hit head until folks show up to fix legacy
>>> drivers that use net80211.  I got stuck holding the bag when I committed
>>> the wpa support and it ain't going to happen again.
>>>
>> Do you have a list of drivers that are stalling this? 
> 
> The changes decouple scanning from the net80211 state machine so any
> driver that uses ieee80211_new_state is affected:
> 
> tubby% grep -l ieee80211_new_state */*.c
> ath/if_ath.c
> awi/awi.c
> ipw/if_ipw.c
> iwi/if_iwi.c
> ral/rt2560.c
> ral/rt2661.c
> usb/if_ural.c
> wi/if_wi.c
> 
> I know how to convert ath and ral.  iwi and ipw might not be too bad now
> that they've been changed to not abuse the state machine so much.  awi,
> ural, and wi will break.  ural might be ok after the new usb stack comes
> in but that's not clear.
> 
> So I guess I'd take responsibility for ath and ral and want help with
> all other drivers.

I forgot the other key item missing from the above list: ndis.  It
bypasses the net80211 api's lots of places and frobs things directly so
converting may be a big job--hard to say until someone tries 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: "scan stuck" with if_iwi(4)

[Sam Leffler]

Andrew Thompson wrote:
> On Wed, Jul 26, 2006 at 01:28:12PM -0700, Sam Leffler wrote:
>> Henrik Brix Andersen wrote:
>>> Oh? Sounds interesting, where can I find these patches?
>> The work has always been in perforce.freebsd.org; look in the sam_wifi
>> branch.  The code will not hit head until folks show up to fix legacy
>> drivers that use net80211.  I got stuck holding the bag when I committed
>> the wpa support and it ain't going to happen again.
>>
> 
> Do you have a list of drivers that are stalling this? 

The changes decouple scanning from the net80211 state machine so any
driver that uses ieee80211_new_state is affected:

tubby% grep -l ieee80211_new_state */*.c
ath/if_ath.c
awi/awi.c
ipw/if_ipw.c
iwi/if_iwi.c
ral/rt2560.c
ral/rt2661.c
usb/if_ural.c
wi/if_wi.c

I know how to convert ath and ral.  iwi and ipw might not be too bad now
that they've been changed to not abuse the state machine so much.  awi,
ural, and wi will break.  ural might be ok after the new usb stack comes
in but that's not clear.

So I guess I'd take responsibility for ath and ral and want help with
all other drivers.

Sam
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: "scan stuck" with if_iwi(4)

[Sam Leffler]

Henrik Brix Andersen wrote:
> On Wed, Jul 26, 2006 at 11:07:36AM -0700, Sam Leffler wrote:
>> Sure, it was for others.
> 
> Ah :)
> 
>> Which version are you looking at? The numbers in iwi are from the code
>> in linux-2.6.17; maybe it's been changed again in the code on
>> sourceforge?
> 
> I was looking in the ipw2200.h header file from ipw2200-1.1.2 - but
> the values are the same in version 1.1.1 of the driver, which is
> present in linux-2.6.17.
> 
> #define IPW_MB_ROAMING_THRESHOLD_DEFAULT8
> #define IPW_MB_DISASSOCIATE_THRESHOLD_DEFAULT   
> 3*IPW_MB_ROAMING_THRESHOLD_DEFAULT

If I recall the first is used to trigger a bg scan to look for a better
ap.  If that fails and the 2nd number is seen then the driver shuts
down.  So I guess this amounts to disconnecting from the current ap on
the 2nd number but I'm not sure how you can do the bg scan and still get
the firmware to keep counting up to the larger number (it resets it's
internal counter on channel change from what I recall).  But it's been a
while.  Regardless you've got a knob now so you can set it to whatever
you want.  You shouldn't be missing beacons in such large numbers; it's
a likely indicator of some other problem but since we don't know what
exactly a bmiss means it's hard to say (e.g. the firmware may report a
bmiss when the rssi of the received beacon frame is below a threshold in
which case there may be a problem with the threshold setting).

> 
>> The one thing the linux driver does differently is scan for a new ap
>> _before_ roaming which the current net80211 code cannot do.
>> Unfortunately the code to do that has been sitting outside the tree
>> for a long time and it's unclear if it'll ever come in...
> 
> Oh? Sounds interesting, where can I find these patches?

The work has always been in perforce.freebsd.org; look in the sam_wifi
branch.  The code will not hit head until folks show up to fix legacy
drivers that use net80211.  I got stuck holding the bag when I committed
the wpa support and it ain't going to happen again.

Sam
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: "scan stuck" with if_iwi(4)

[Sam Leffler]

Henrik Brix Andersen wrote:
> On Wed, Jul 26, 2006 at 09:10:03AM -0700, Sam Leffler wrote:
>> Thanks for your help but understand this is not necessarily a solution;
>> just the addition of a knob.
> 
> I know.

Sure, it was for others.

> 
>> The linux driver already used 7 consecutive beacon misses to trigger
>> roaming so I'm not sure why 10 is an improvement but given that
>> adding 300ms (typical) lag makes you happy I wasn't going to argue
>> :)
> 
> Actually, it seems the linux driver uses a threshold of 8 missed
> beacons for roaming and a threshold of 24 for disassociation.

Which version are you looking at?  The numbers in iwi are from the code
in linux-2.6.17; maybe it's been changed again in the code on
sourceforge?  The one thing the linux driver does differently is scan
for a new ap _before_ roaming which the current net80211 code cannot do.
 Unfortunately the code to do that has been sitting outside the tree for
a long time and it's unclear if it'll ever come in...

> 
> But you're correct - this only solves the issue of being disassociated
> every 3 minutes; it doesn't solve the problem behind "scan stuck", but
> this problem is not present here anymore since the station is not
> disassociated all the time.
> 
> I'll try to address the scan stuck problem when I find some more time.

Thank you.

Sam
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"