Re: Request for merge into 9.x
On Wednesday 12 December 2012 14:29:13 Paul Webster wrote: Hello I was recently reading about your work on the Ralink 2860, I run an EEEPC 1000 at the moment and have always wanted to run freebsd on it; however due to the wireless not being supported and a hatred for hanging usb dongles handing everywhere; I had to run linux. I am no driver developer, but I would love to give your driver a trial run on 9.1-RELEASE or -STABLE if easier, I am quite sure once everyone with an eeepc realizes we finally have a working wifi card; they will be most impressed :) as an aside, if you could leave me some simplish instructions on howto actually generate the kernel module in 9.0/9.1 -RELEASE I would happily report how well it works Which card do you have exactly (pciconf -lv)? Everything if done to ral(4) is in stable/9 and 9.1-release. So, if the card is affected by any of the changes it should be supported in 9.1-release. If not, it might just be a missing PCI ID. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Erratic USB mouse behaviour when wireless is down and USB hard disk connected
On Fri, Jul 13, 2012 at 2:04 PM, Erich Dollansky erichfreebsdl...@ovitrap.com wrote: Hi, I know that this is not a very helpful information. I have an Lenovo X220 running 10 from some 2 weeks ago. I just noticed that the USB mouse (a wireless Logitech Trackman) becomes unusable when the wireless (iwn) is not able to connect to the access point and a USB hard disk is plugged in. Even when no data are transferred the USB mouse is unusable. Which frequency is the mouse working on? something in the 2.4GHz region? I remember having lots of fun at $office with the mouse of colleague. It used channel 6 and the amount of traffic generating over wireless LAN had direct influence on the accuracy of his mouse activity ;) Anyways, if you have the chance to switch to another channel, give it a shot. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: jemalloc: out of swap space
On Wed, May 30, 2012 at 2:11 PM, HIROSHI OOTA n...@mad.dog.cx wrote: Hi all, my PCEngine's wrap(NanoBSD, i386, 128Mbytes mem, no swap) won't start, after updating to r234569. some of daemons was killed with the message 'out of swap space'. vmstat in single user mode as: --- r234568(works fine) # uname -a FreeBSD 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r234568: root@ i386 # vmstat procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad0 ad1 in sy cs us sy id 0 0 0 26572k 109M 12 0 0 0 7 0 0 0 402 7 78 0 1 99 --- r234569(does not work) # uname -a FreeBSD 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r234569: root@ i386 # vmstat procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad0 ad1 in sy cs us sy id 0 0 0 21320k 86M 185 0 1 0 76 0 0 0 406 9 97 0 2 98 Any ideas? I've been running into the same issue on my Alix boards, defining MALLOC_PRODUCTION in src.conf fixed it. Alternatively you can bump kmem size (cant remember the exact knob, basically what most ZFS tuning guides recommend), but this is less effective as mem usage is still way to high. HTH -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support
On Sat, May 12, 2012 at 8:44 AM, hopto artem20041...@yandex.ru wrote: does not work DWA-525 is not as an access point, not as a client May 12 01:57:23 bit-box kernel: ral0: Ralink Technology RT3060 mem 0xfe51-0xfe51 irq 16 at device 0.0 on pci6 May 12 01:58:52 bit-box kernel: ral0: unable to receive rt2860fw firmware image Yeah, as mentioned in the initial mail, you need the firmware from HEAD. Go to http://svnweb.freebsd.org/base/head/ and pull the content of sys/contrib/dev/ral and sys/modules/ralfw and rebuild the firmware module. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support
On Sat, May 12, 2012 at 4:40 PM, hopto artem20041...@yandex.ru wrote: on first problem: #ifconfig ral0 inet 192.168.0.1 netmask 0xfff0 ssid freebsdap channel 11 mediaopt hostap ifconfig: SIOCS80211: Invalid argument on second problem: If the set is not as klinet otobrazhayutsya available networks at all. Ate configured as an access point to the kind of okay (wlan0 status running)but customers do not see the network. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-wireless.html -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support
On Friday 11 May 2012 17:57:03 hopto wrote:
FreeBSD 9 amd64
cc1: warnings being treated as errors
/usr/src/sys/modules/ral/../../dev/ral/rt2860.c: In function
'rt2860_attach':
/usr/src/sys/modules/ral/../../dev/ral/rt2860.c:349: warning: assignment
from incompatible pointer type
*** Error code 1
Stop in /usr/src/sys/modules/ral.
what?
9.0? Try attached patch
Though, you are better of updating to stable/9, the patches should
apply/build cleanly there.
--
Bernhard
Index: sys/dev/ral/rt2860.c
===
--- sys/dev/ral/rt2860.c (revision 235233)
+++ sys/dev/ral/rt2860.c (working copy)
@@ -76,7 +76,7 @@
#endif
static struct ieee80211vap *rt2860_vap_create(struct ieee80211com *,
- const char [IFNAMSIZ], int, enum ieee80211_opmode,
+ const char [IFNAMSIZ], int, int,
int, const uint8_t [IEEE80211_ADDR_LEN],
const uint8_t [IEEE80211_ADDR_LEN]);
static void rt2860_vap_delete(struct ieee80211vap *);
@@ -428,7 +428,7 @@
static struct ieee80211vap *
rt2860_vap_create(struct ieee80211com *ic, const char name[IFNAMSIZ], int unit,
-enum ieee80211_opmode opmode, int flags,
+int opmode, int flags,
const uint8_t bssid[IEEE80211_ADDR_LEN],
const uint8_t mac[IEEE80211_ADDR_LEN])
{
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support
On Sat, May 5, 2012 at 12:51 PM, Bernhard Schmidt bschm...@freebsd.org wrote: Please apply attached patch (also here [1]) on top of the first one, it fixes channel switching for = 3070 (called the wrong function, doh..) as well as a bgscan issue. [1] http://techwires.net/~bschmidt/rt2860_1.diff And another update [1] on top of the other 2 patches. * fix TX DMA, a wrong dmat has been used * add some more PCI IDs * disable debugging output by default * disable bgscan until it's sorted out * a printf is now hidden behind bootverbose So far it looks quite good, no open issues at the moment, keep on testing! ;) If nothing new comes up within the next few days I intend to commit this by the end of the week or something. [1] http://techwires.net/~bschmidt/rt2860_2.diff -- Bernhard rt2860_2.diff Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support
On Saturday 05 May 2012 09:52:58 Sergey V. Dyatko wrote: On Thu, 3 May 2012 18:53:52 +0200 Bernhard Schmidt bschm...@freebsd.org wrote: Hi folks, As some of you might know there has been some work going on porting support for new Ralink chipsets from OpenBSD. Several different drivers where floating around but nothing seemed to be decent enough to be committed. ray@ and I had been working on cleaning up one of those to get it into a good enough shape, but abandoned this approach as it resulted in more work than starting from scratch. So, attached diff [1] is a from-scratch effort to port over support for the new chipsets. It doesn't contain fancy stuff like 802.11n support as of yet (this will be worked one once the legacy stuff is in HEAD), nonetheless it showed pretty decent performance during the basic sta/adhoc/hostap tests I've done. I'd appreciate testing and feedback ;) at 1st I would say 'Thank You' for all people who working on this :) patch, make, make install, kldload: http://tiger.ipfw.ru/files/rt2860_3090.txt this is FreeBSD 10.0-CURRENT, r234992M: Fri May 4 11:25:53 FET 2012 from time to time on messages: May 5 10:32:47 laptop kernel: ral0: device timeout May 5 10:37:49 laptop kernel: ral0: device timeout May 5 10:42:50 laptop kernel: ral0: device timeout That interval is fishy.. can you try do disable bgscan? ifconfig wlan0 -bgscan LED... is just glowing, rarely blinks. With patch from Alexander (ray@) it doesn't work [tiger@laptop]~%scp tiger:/storage/FreeBSD-8.2-RELEASE-amd64-dvd1.iso . FreeBSD-8.2-RELEASE-amd64-dvd1.iso 11% 271MB 1.9MB/s 18:19 ETA ^C Killed by signal 2. where 'tiger' is my desktop The diff requires HEAD due to the firmware being available only there, though, if there are enough requests, I might consider looking into getting it merged to 9. (Simply pulling sys/modules/ralfw/ and sys/contrib/dev/ral/ from HEAD might be enough I guess.) [1] http://techwires.net/~bschmidt/rt2860.diff -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support
On Saturday 05 May 2012 09:52:58 Sergey V. Dyatko wrote:
On Thu, 3 May 2012 18:53:52 +0200
Bernhard Schmidt bschm...@freebsd.org wrote:
Hi folks,
As some of you might know there has been some work going on porting
support for new Ralink chipsets from OpenBSD. Several different
drivers where floating around but nothing seemed to be decent enough
to be committed. ray@ and I had been working on cleaning up one of
those to get it into a good enough shape, but abandoned this approach
as it resulted in more work than starting from scratch.
So, attached diff [1] is a from-scratch effort to port over support
for the new chipsets. It doesn't contain fancy stuff like 802.11n
support as of yet (this will be worked one once the legacy stuff is
in HEAD), nonetheless it showed pretty decent performance during the
basic sta/adhoc/hostap tests I've done.
I'd appreciate testing and feedback ;)
at 1st I would say 'Thank You' for all people who working on this :)
patch, make, make install, kldload:
http://tiger.ipfw.ru/files/rt2860_3090.txt
this is FreeBSD 10.0-CURRENT, r234992M: Fri May 4 11:25:53 FET 2012
from time to time on messages:
May 5 10:32:47 laptop kernel: ral0: device timeout
May 5 10:37:49 laptop kernel: ral0: device timeout
May 5 10:42:50 laptop kernel: ral0: device timeout
LED... is just glowing, rarely blinks. With patch from Alexander (ray@)
it doesn't work
[tiger@laptop]~%scp tiger:/storage/FreeBSD-8.2-RELEASE-amd64-dvd1.iso .
FreeBSD-8.2-RELEASE-amd64-dvd1.iso 11%
271MB 1.9MB/s 18:19 ETA
^C
Killed by signal 2.
where 'tiger' is my desktop
Please apply attached patch (also here [1]) on top of the first one,
it fixes channel switching for = 3070 (called the wrong function,
doh..) as well as a bgscan issue.
[1] http://techwires.net/~bschmidt/rt2860_1.diff
--
Bernhard
Index: sys/dev/ral/rt2860.c
===
--- sys/dev/ral/rt2860.c (revision 234847)
+++ sys/dev/ral/rt2860.c (working copy)
@@ -1605,10 +1605,7 @@ rt2860_tx(struct rt2860_softc *sc, struct mbuf *m, struct ieee80211_node *ni)
ieee80211_radiotap_tx(vap, m);
}
- if (hdrlen 3)
- pad = 4 - (hdrlen 3);
- else
- pad = 0;
+ pad = (hdrlen + 3) ~3;
/* copy and trim 802.11 header */
memcpy(txwi + 1, wh, hdrlen);
@@ -1667,7 +1664,7 @@ rt2860_tx(struct rt2860_softc *sc, struct mbuf *m, struct ieee80211_node *ni)
/* first segment is TXWI + 802.11 header */
txd = ring-txd[ring-cur];
txd-sdp0 = htole32(data-paddr);
- txd-sdl0 = htole16(sizeof (struct rt2860_txwi) + hdrlen + pad);
+ txd-sdl0 = htole16(sizeof (struct rt2860_txwi) + pad);
txd-flags = qsel;
/* setup payload segments */
@@ -1776,7 +1773,7 @@ rt2860_tx_raw(struct rt2860_softc *sc, struct mbuf *m,
u_int hdrlen;
uint16_t dur;
uint8_t type, qsel, mcs, pid, tid, qid;
- int i, nsegs, ntxds, rate, ridx, error;
+ int i, nsegs, ntxds, pad, rate, ridx, error;
/* the data pool contains at least one element, pick the first */
data = SLIST_FIRST(sc-data_pool);
@@ -1860,6 +1857,8 @@ rt2860_tx_raw(struct rt2860_softc *sc, struct mbuf *m,
ieee80211_radiotap_tx(vap, m);
}
+ pad = (hdrlen + 3) ~3;
+
/* copy and trim 802.11 header */
memcpy(txwi + 1, wh, hdrlen);
m_adj(m, hdrlen);
@@ -1917,7 +1916,7 @@ rt2860_tx_raw(struct rt2860_softc *sc, struct mbuf *m,
/* first segment is TXWI + 802.11 header */
txd = ring-txd[ring-cur];
txd-sdp0 = htole32(data-paddr);
- txd-sdl0 = htole16(sizeof (struct rt2860_txwi) + hdrlen);
+ txd-sdl0 = htole16(sizeof (struct rt2860_txwi) + pad);
txd-flags = qsel;
/* setup payload segments */
@@ -2336,7 +2335,6 @@ rt2860_scan_start(struct ieee80211com *ic)
tmp ~(RT2860_BCN_TX_EN | RT2860_TSF_TIMER_EN |
RT2860_TBTT_TIMER_EN));
rt2860_set_gp_timer(sc, 0);
- rt2860_set_bssid(sc, ifp-if_broadcastaddr);
}
static void
@@ -2346,10 +2344,10 @@ rt2860_scan_end(struct ieee80211com *ic)
struct rt2860_softc *sc = ifp-if_softc;
struct ieee80211vap *vap = TAILQ_FIRST(ic-ic_vaps);
- rt2860_enable_tsf_sync(sc);
- /* XXX keep local copy */
- rt2860_set_bssid(sc, vap-iv_bss-ni_bssid);
- rt2860_set_gp_timer(sc, 500);
+ if (vap-iv_state == IEEE80211_S_RUN) {
+ rt2860_enable_tsf_sync(sc);
+ rt2860_set_gp_timer(sc, 500);
+ }
}
static void
@@ -2359,7 +2357,7 @@ rt2860_set_channel(struct ieee80211com *ic)
struct rt2860_softc *sc = ifp-if_softc;
RAL_LOCK(sc);
- rt2860_set_chan(sc, ieee80211_chan2ieee(ic, ic-ic_curchan));
+ rt2860_switch_chan(sc, ic-ic_curchan);
RAL_UNLOCK(sc);
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support
On Sat, May 5, 2012 at 2:27 PM, Sergey V. Dyatko sergey.dya...@gmail.com wrote: On Sat, 5 May 2012 12:51:10 +0200 Bernhard Schmidt bschm...@freebsd.org wrote: Please apply attached patch (also here [1]) on top of the first one, it fixes channel switching for = 3070 (called the wrong function, doh..) as well as a bgscan issue. [1] http://techwires.net/~bschmidt/rt2860_1.diff * patch applied without errors * build/install - ok kldload and after ~5 minutes: May 5 15:01:20 laptop kernel: ral0: device timeout May 5 15:06:12 laptop kernel: ral0: device timeout without bgscan I didn't see such messages ~30-40 min Ok great, so except bgscan you haven't seen any other issue yet? -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10.0-CURRENT could not be built: make: don't know how to make blacklist.c. Stop
On Sunday 29 April 2012 13:38:38 Lev Serebryakov wrote:
Hello, Current.
I'm trying to build fresh (several minutes ago) 10.0-CURRENT/i386 on
month-old 10.0-CURRENT/i386. And it fails in very beginning:
=== usr.sbin/wpa (depend)
=== usr.sbin/wpa/wpa_supplicant (depend)
make: don't know how to make blacklist.c. Stop
*** [depend] Error code 2
I've looked at usr.sbin/wpa/wpa_supplicant/Makefile and found here
only .PATH.c:${WPA_DISTDIR}/src/drivers, without
${WPA_SUPPLICANT_DISTDIR.
hostapd is same story.
Revisions in question seems to be r234756 and r234711.
Just noticed that myself a few minutes ago.. I'm about to commit
attached fix in few minutes. Wanna give it a quick shot?
Other then that, removing WITHOUT_EXAMPLES from src.conf helps
too, that's why I missed it.
--
Bernhard
Index: usr.sbin/wpa/wpa_supplicant/Makefile
===
--- usr.sbin/wpa/wpa_supplicant/Makefile (revision 234784)
+++ usr.sbin/wpa/wpa_supplicant/Makefile (working copy)
@@ -2,7 +2,8 @@
.include ${.CURDIR}/../Makefile.inc
-.PATH.c:${WPA_DISTDIR}/src/drivers
+.PATH.c:${WPA_SUPPLICANT_DISTDIR} \
+ ${WPA_DISTDIR}/src/drivers
PROG= wpa_supplicant
SRCS= aes-unwrap.c \
Index: usr.sbin/wpa/hostapd/Makefile
===
--- usr.sbin/wpa/hostapd/Makefile (revision 234784)
+++ usr.sbin/wpa/hostapd/Makefile (working copy)
@@ -2,7 +2,8 @@
.include ${.CURDIR}/../Makefile.inc
-.PATH.c:${WPA_DISTDIR}/src/drivers
+.PATH.c:${HOSTAPD_DISTDIR} \
+ ${WPA_DISTDIR}/src/drivers
PROG= hostapd
SRCS= accounting.c \
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10.0-CURRENT could not be built: make: don't know how to make blacklist.c. Stop
On Sunday 29 April 2012 14:33:26 Lev Serebryakov wrote: Hello, Bernhard. You wrote 29 апреля 2012 г., 16:14:14: BS Just noticed that myself a few minutes ago.. I'm about to commit BS attached fix in few minutes. Wanna give it a quick shot? Yep, it helps :) Committed, sorry for the breakage. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
On Wednesday 07 March 2012 16:38:44 Mitsuru IWASAKI wrote: So iwi_transmit and iwi_qflush would not be necessary. correct Today's version of patches at: http://people.freebsd.org/~iwasaki/iwi/iwi-20120307.diff This would be the final version I hope. I gave it a quick spin, works for me. You can add Tested/Reviewed by: bschmidt if you like. Thanks! -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
On Tuesday 06 March 2012 21:12:55 Adrian Chadd wrote: .. except that the default if_transmit handling breaks fragments. Sigh. So we're going to have to implement if_transmit for all net80211 drivers soon and fix fragment handling. Not saying that you are wrong, it is unrelated to the issue at hand though and I'm not even sure it can be fixed just by replacing if_transmit(). Anyways, a bug going unnoticed for 3 years or something isn't that high on my priority list. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
On Wednesday 07 March 2012 19:45:11 Adrian Chadd wrote: Hi, I'd rather you didn't commit iwi_update_mcast() unless you absolutely know that the NIC doesn't need to be notified of multicast group membership changes. If so, please commit that as a separate fix. Oh well, iwi(4) receives multicast frames just fine, they are discarded somewhere else though last time I've checked, another offtopic issue ;) I'll look at iwi later and give you feedback on that particular change. I did look into this once for ipw it was I guess, the firmware doesn't support filtering based on addresses so everything one could achieve here is enable/disable filtering of all multicast frames. Check iwi_configuration.enable_multicast_filtering, which is a bool actually not an uint8_t. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
On Tuesday 06 March 2012 18:30:46 Mitsuru IWASAKI wrote:
Thanks Bernhard and Adrian, I think the problem seems to be solved.
My patches set IEEE80211_NODE_ASSOCID bit only if ni-ni_associd
is set. Any suggestions on this part are welcome.
Are you sure the net80211 part is correct? It looks to me as if you
are just masking the real issue. The IEEE80211_NODE_ASSOCID flag is
ment to be used to verify that an associd has actually been set, not
doing so will break other things I guess. iwi(4) is a bit tricky in
that regard, as it sets the associd itself, check iwi_checkforqos().
I'd verify that function is actually called and if so if the parameters
are correct. I fumbled around there once, might have wrong WEP..
As you suggested, iwi_checkforqos() has problems, wrong asresp
frame parsing.
@@ -1357,8 +1365,8 @@
frm += 2;
wme = NULL;
- while (frm efrm) {
- IEEE80211_VERIFY_LENGTH(efrm - frm, frm[1], return);
+ while (efrm - frm 1) {
+ IEEE80211_VERIFY_LENGTH(efrm - frm, frm[1] + 2, return);
switch (*frm) {
case IEEE80211_ELEMID_VENDOR:
if (iswmeoui(frm))
Bacause of the condition `while (frm efrm)',
IEEE80211_VERIFY_LENGTH() was checking item length beyond the
ieee80211_frame region, and returned from iwi_checkforqos() without
setting flags, capinfo and associd!
I made above changes referring to net80211 code such as
ieee80211_sta.c.
Today's version of patches at:
http://people.freebsd.org/~iwasaki/iwi/iwi-20120306.diff
This one don't have changes on net80211 part at all.
Looks good to me, please get that into the tree.
What's the reason behing adding if_qflush()/if_transmit()?
In RELENG_7, data frame is transmitted by iwi_tx_start() like this.
ether_output
ether_output_frame
IFQ_HANDOFF/IFQ_HANDOFF_ADJ
if_start
iwi_start
iwi_tx_start
After 8.0-RELEASE, device specific if_transmit() is called via net80211 layer.
ether_output
ether_output_frame
if_transmit
IFQ_HANDOFF/IFQ_HANDOFF_ADJ
if_start
ieee80211_start
parent-if_transmit(ie. iwi_transmit())
There was not if_transmit method in iwi(4), so I add it.
On if_qflush(), CURRENT kernel complains that `transmit and qflush
must both either be set or both be NULL' from if.c.
I wrote iwi_qflush(), but actually never tested it...
Hmm, it still is the case for = 8 afaik, there is a default
if_transmit() which is used for all wireless drivers which seems to
work pretty well. That's why I'm wondering, iwi(4) would be the first
driver to have it's own if_transmit() function. I'm not aware of any
technical reason for adding one, or did I miss something? If not I'd
rather not have one added, for sake of consistency.
From: Adrian Chadd adr...@freebsd.org
Would you please open a PR with this particular issue and then attach
the patch to it?
I prefer committing changes on iwi(4) by myself, because grimreaper@
keep giving pressure to me `Your src commit bit is still idle.' for
long time :)
I just want to stop it.
;)
--
Bernhard
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
On Monday 05 March 2012 18:42:12 Mitsuru IWASAKI wrote:
Hi,
I've fixed iwi(4) so that Intel(R) PRO/Wireless 2915ABG work
in WEP mode, which seems to be broken since 8.0-RELEASE.
The patches against HEAD at:
http://people.freebsd.org/~iwasaki/iwi/iwi-20120305.diff
I'm not sure that changes on ieee80211 layer are right fixes,
but all of mbufs were discarded in ieee80211_start() in WEP mode.
void
ieee80211_start(struct ifnet *ifp)
{
[snip]
if (ni-ni_associd == 0
(ni-ni_flags IEEE80211_NODE_ASSOCID)) {
IEEE80211_DISCARD_MAC(vap,
IEEE80211_MSG_OUTPUT,
eh-ether_dhost, NULL,
sta not associated (type 0x%04x),
htons(eh-ether_type));
vap-iv_stats.is_tx_notassoc++;
ifp-if_oerrors++;
m_freem(m);
ieee80211_free_node(ni);
continue;
}
My patches set IEEE80211_NODE_ASSOCID bit only if ni-ni_associd
is set. Any suggestions on this part are welcome.
Are you sure the net80211 part is correct? It looks to me as if you
are just masking the real issue. The IEEE80211_NODE_ASSOCID flag is
ment to be used to verify that an associd has actually been set, not
doing so will break other things I guess. iwi(4) is a bit tricky in
that regard, as it sets the associd itself, check iwi_checkforqos().
I'd verify that function is actually called and if so if the parameters
are correct. I fumbled around there once, might have wrong WEP..
I'm going to commit the changes coming weekend.
What's the reason behing adding if_qflush()/if_transmit()?
--
Bernhard
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn panic with 9.0-BETA3-amd64
On Friday 07 October 2011 16:18:47 Niclas Zeising wrote: This might or might not be related, but, I'm having trouble with the iwn firmware crashing. I also have a clang built kernel (and userland) buildwith CPUTYPE=core2. My iwn device is iwn0: Intel(R) Wireless WiFi Link 4965 mem 0xe400-0xe4001fff irq 17 at device 0.0 on pci16 and the firmware gives the following output when it dies. iwn0: iwn_intr: fatal firmware error firmware error log: error type = NMI_INTERRUPT_WDG (0x0004) program counter = 0x046C source line = 0x00D0 This is a known issue with the 4965's firmware. I have yet to find a reliable solution for that.. As a workaround you can disable background scan with ifconfig wlan0 -bgscan The only way to restore the firmware is to reboot the computer. No need to reboot, killing the VAP and recreating it should get you going again. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BETA2 panic
On Tue, Sep 6, 2011 at 22:42, Joel Dahl j...@vnode.se wrote: On 05-09-2011 9:02, Bernhard Schmidt wrote: On Mon, Sep 5, 2011 at 08:24, Joel Dahl j...@vnode.se wrote: On 05-09-2011 5:09, Adrian Chadd wrote: On 5 September 2011 01:04, Joel Dahl j...@vnode.se wrote: Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg Hi, There weren't many commits between BETA1 and -HEAD in the wireless area; would you please do a binary search of the kernel revisions (no need to do full buildworlds) to find which commit broke it? Yes, I'll do that tonight. While doing so, can you enable at least some debugging? wlandebug +state or even better wlandebug 0x It smells like that something is poking the SW bmiss handler while not in RUN state and therefore you're hitting a KASSERT(). Question is if the bmiss timer isn't stopped/drained somewhere or if there is too excessive call. Exactly what in the wlandebug output are you looking for? I've posted a pic at http://www.vnode.se/sc/panic_20110906.jpg showing what it looks like right before the panic. This is with wlandebug 0x. Thanks, so, looks like it is scanning while the panic happens. At that point it should actually never ever care about beacon misses.. this is strange, really. Can you try to comment out the call to ieee80211_beacon_miss() on line 2936 in if_iwn.c? If the panic no longer happens the issue is somewhere in the conditions before that call. I've also installed kernels all the way back to revision 222980, but they all panic, which I think is somewhat odd. I think this is an issue related to iwn(4), which had its last commit prior to that. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel Centrino Advanced-N + WiMAX 6250 doesn't work
On Wed, Sep 7, 2011 at 09:39, Tz-Huan Huang tzh...@gmail.com wrote: On Wed, Sep 7, 2011 at 14:10, Tz-Huan Huang tzh...@gmail.com wrote: Hi, I have a lenovo X201s with a Intel Centrino Advanced-N + WiMAX 6250 bundled. The device seems recognized as iwn0 correctly but it just doesn't work. The command ifconfig wlan0 up scan return immediately and nothing showed. Is the device not supported, or do I miss something? Any suggestion is welcome, thanks. Here is some information: $ uname -a FreeBSD bud 9.0-BETA2 FreeBSD 9.0-BETA2 #2: Tue Sep 6 16:50:09 CST 2011 root@bud:/usr/obj/usr/src/sys/BUD amd64 dmesg -a: http://www.csie.ntu.edu.tw/~b90093/tmp/dmesg.txt rc.conf: http://www.csie.ntu.edu.tw/~b90093/tmp/rc.conf kldstat -v http://www.csie.ntu.edu.tw/~b90093/tmp/kldstat.txt When loading acpi_ibm, I got more error information: $ kldload acpi_ibm acpi_ibm0: IBM ThinkPad ACPI Extras on acpi0 $ ifconfig wlan0 up iwn0: iwn5000_send_calibration: could not send calibration result, error 22 iwn0: iwn_init_locked: could not initialize hardware, error 22 Can you do sysctl dev.iwn.0.debug=0x before doing ifconfig wlan0 up? I'm curious on which result it can't send to the firmware. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BETA2 panic
On Wed, Sep 7, 2011 at 12:53, Joel Dahl j...@vnode.se wrote: On 07-09-2011 10:59, Bernhard Schmidt wrote: On Tue, Sep 6, 2011 at 22:42, Joel Dahl j...@vnode.se wrote: On 05-09-2011 9:02, Bernhard Schmidt wrote: On Mon, Sep 5, 2011 at 08:24, Joel Dahl j...@vnode.se wrote: On 05-09-2011 5:09, Adrian Chadd wrote: On 5 September 2011 01:04, Joel Dahl j...@vnode.se wrote: Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg Hi, There weren't many commits between BETA1 and -HEAD in the wireless area; would you please do a binary search of the kernel revisions (no need to do full buildworlds) to find which commit broke it? Yes, I'll do that tonight. While doing so, can you enable at least some debugging? wlandebug +state or even better wlandebug 0x It smells like that something is poking the SW bmiss handler while not in RUN state and therefore you're hitting a KASSERT(). Question is if the bmiss timer isn't stopped/drained somewhere or if there is too excessive call. Exactly what in the wlandebug output are you looking for? I've posted a pic at http://www.vnode.se/sc/panic_20110906.jpg showing what it looks like right before the panic. This is with wlandebug 0x. Thanks, so, looks like it is scanning while the panic happens. At that point it should actually never ever care about beacon misses.. this is strange, really. Can you try to comment out the call to ieee80211_beacon_miss() on line 2936 in if_iwn.c? If the panic no longer happens the issue is somewhere in the conditions before that call. Hm, this is with bwn(4), not iwn(4). :) Uhm.. right, I'm sorry, missed that Still.. two options, remove IEEE80211_FEXT_SWBMISS or try with ifconfig wlan0 -bgscan -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel Centrino Advanced-N + WiMAX 6250 doesn't work
On Wed, Sep 7, 2011 at 12:10, Kevin Lo ke...@freebsd.org wrote: Tz-Huan Huang wrote: Hi, I have a lenovo X201s with a Intel Centrino Advanced-N + WiMAX 6250 bundled. The device seems recognized as iwn0 correctly but it just doesn't work. The command ifconfig wlan0 up scan return immediately and nothing showed. Is the device not supported, or do I miss something? Any suggestion is welcome, thanks. Here is some information: $ uname -a FreeBSD bud 9.0-BETA2 FreeBSD 9.0-BETA2 #2: Tue Sep 6 16:50:09 CST 2011 root@bud:/usr/obj/usr/src/sys/BUD amd64 dmesg -a: http://www.csie.ntu.edu.tw/~b90093/tmp/dmesg.txt rc.conf: http://www.csie.ntu.edu.tw/~b90093/tmp/rc.conf kldstat -v http://www.csie.ntu.edu.tw/~b90093/tmp/kldstat.txt Please try attached patch. It seems like OpenBSD added support for 6205, but I'm not sure if it works for 6250. Worth a try, but I don't think it will make a difference. I had that code once (it should even be visible on the svn history) but removed it because it isn't required, the 6005 series devices work very well without it (I'm using a 6230 (6000g2b) daily) without issues. What is import though is which calibration results are sent to the runtime firmware, I suspect there might be an issue in iwn5000_rx_calib_results() around IWN5000_PHY_CALIB_DC. I remember that someone reported the 6250 devices working once, it might be worth going over the last revisions (there where some calibration related changes) and figure out which one broke it. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel Centrino Advanced-N + WiMAX 6250 doesn't work
On Wed, Sep 7, 2011 at 15:11, Tz-Huan Huang tzh...@gmail.com wrote:
On Wed, Sep 7, 2011 at 20:34, Bernhard Schmidt bschm...@freebsd.org wrote:
On Wed, Sep 7, 2011 at 12:10, Kevin Lo ke...@freebsd.org wrote:
Please try attached patch. It seems like OpenBSD added support
for 6205, but I'm not sure if it works for 6250.
Okay, I am re-building the kernel now,
will report here if any news.
Worth a try, but I don't think it will make a difference. I had that
code once (it should even be visible on the svn history) but removed
it because it isn't required, the 6005 series devices work very well
without it (I'm using a 6230 (6000g2b) daily) without issues. What is
import though is which calibration results are sent to the runtime
firmware, I suspect there might be an issue in
iwn5000_rx_calib_results() around IWN5000_PHY_CALIB_DC.
I remember that someone reported the 6250 devices working once, it
might be worth going over the last revisions (there where some
calibration related changes) and figure out which one broke it.
Yes, this device works fine according to this post:
http://forums.freebsd.org/showthread.php?t=19839
I have scanned the source but it seems that the iwn sources changed a lot...
Yeah, thanks, I start to remember..
Seems like I broke 6250 support by adding support for 6005. Point is,
the DC calibration result generated by the init firmware is too large
(saving calibration result code=8 len=3964, compare with other
results..) to pass over to the runtime firmware, this is where it
chokes. The solution is to not bother about it at all and let the
runtime firmware do the calibration again, so no need to send
anything. Basically, Kevin's patch is correct, it should also just
remove handling of PHY_CALIB_DC in iwn5000_rx_calib_results(), ideally
for all = 6000 devices.
Can you try this in addition to Kevin's patch?
Index: if_iwn.c
===
--- if_iwn.c(revision 225188)
+++ if_iwn.c(working copy)
@@ -2502,9 +2502,7 @@ iwn5000_rx_calib_results(struct iwn_softc *sc, str
switch (calib-code) {
case IWN5000_PHY_CALIB_DC:
- if ((sc-sc_flags IWN_FLAG_INTERNAL_PA) == 0
- (sc-hw_type == IWN_HW_REV_TYPE_5150 ||
-sc-hw_type = IWN_HW_REV_TYPE_6000))
+ if (sc-hw_type == IWN_HW_REV_TYPE_5150)
idx = 0;
break;
case IWN5000_PHY_CALIB_LO:
Thanks
--
Bernhard
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BETA2 panic
On Mon, Sep 5, 2011 at 08:24, Joel Dahl j...@vnode.se wrote: On 05-09-2011 5:09, Adrian Chadd wrote: On 5 September 2011 01:04, Joel Dahl j...@vnode.se wrote: Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg Hi, There weren't many commits between BETA1 and -HEAD in the wireless area; would you please do a binary search of the kernel revisions (no need to do full buildworlds) to find which commit broke it? Yes, I'll do that tonight. While doing so, can you enable at least some debugging? wlandebug +state or even better wlandebug 0x It smells like that something is poking the SW bmiss handler while not in RUN state and therefore you're hitting a KASSERT(). Question is if the bmiss timer isn't stopped/drained somewhere or if there is too excessive call. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cardbus panic: end address is not aligned
On Monday, July 04, 2011 10:37:12 Doug Barton wrote: On 07/03/2011 03:05, Adrian Chadd wrote: The obvious question - can you bisect kernel versions to find out when it broke? Sorry, I thought the answer to that was obvious from my message. I have no idea how far back the breakage goes since I don't use the cards often. Try at least r222753, which worked for me [tm]. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic in ieee80211 tx mgmt timeout
On Wednesday, June 29, 2011 03:50:08 Adrian Chadd wrote: This is kinda strange; that symbol doesn't exist in the net80211 or ath source. What the heck? adrian On 28 June 2011 17:28, Stefan Esser st_es...@t-online.de wrote: Hi, is this a known issue? My -CURRENT system (r223560M, amd64, 8GB, Atheros WLAN) panics after minutes to hours of uptime with the following message: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 0 fault virtual address = 0xff807f502000 fault code = supervisor data read, page not present ... processor eflags= interrupt enabled, resume, IOPL = 0 current process = 11 (swi4: clock) [ thread pid 11 tid 112 ] Stopped at ieee80211_tx_mgmt_timeout+0x1: movq (%rdi),%rdi db bt Tracing pid 11 tid 100012 td 0xfe00032e ieee80211_tx_mgmt_timeout() at ieee80211_tx_mgmt_timeout+0x1 intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop() at ithread_loop+0x96 fork_exit() at fork_exit+0x11d fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8000288d00, rbp = 0 --- This panic message is manually transcribed, since the GPT-only partitioning prevents dumping of a kernel core. (Why, BTW?) I could add a swap partition on a MBR disk, if a core dump seems neccessary to diagnose the problem. I'm also willing to wait for that panic to occur again and to gather more debug output. Other information: The Atheros WLAN in this system is unused (not associated) but both ath0 and wlan0 were UP at the time of the panic. Initial testing shows the system to be stable with both wlan0 and ath0 set to down after boot. But still, the timeout should not panic the kernel, if WLAN is active but not fully configured (e.g. no SSID). Any ideas? It's name is ieee80211_tx_mgt_timeout used to track AUTH/ASSOC requests. Afaik there is even a similar PR about that. Adrian, you've got a AP set up to drop either a AUTH or ASSOC response frame? -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic in ieee80211 tx mgmt timeout
On Wednesday, June 29, 2011 10:03:02 Adrian Chadd wrote:
On 29 June 2011 14:03, Bernhard Schmidt bschm...@freebsd.org wrote:
It's name is ieee80211_tx_mgt_timeout used to track AUTH/ASSOC
requests. Afaik there is even a similar PR about that.
Adrian, you've got a AP set up to drop either a AUTH or ASSOC
response frame?
Tell me how and I'll set it up.
A panic at that point in the function indicates maybe ni is NULL?
or ni-vap is now NULL, maybe?
vap should never be NULL, so, I'd guess it's ni.
Hmm.. I'd guess there is some kind of racy behavior, if the driver is
telling us that it was able to send the AUTH req frame, net80211 sets
up the timeout callback. What happens if the AUTH resp as well as the
callback hit at the same time? It should be locked appropriately, but
is it?
This will drop the AUTH response:
Index: sys/net80211/ieee80211_hostap.c
===
--- sys/net80211/ieee80211_hostap.c (revision 223661)
+++ sys/net80211/ieee80211_hostap.c (working copy)
@@ -978,7 +978,7 @@ hostap_auth_open(struct ieee80211_node *ni, struct
%s, station authentication defered (radius acl));
ieee80211_notify_node_auth(ni);
} else {
- IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUBTYPE_AUTH, seq + 1);
+ //IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUBTYPE_AUTH, seq + 1);
IEEE80211_NOTE_MAC(vap,
IEEE80211_MSG_DEBUG | IEEE80211_MSG_AUTH, ni-ni_macaddr,
%s, station authenticated (open));
@@ -1158,7 +1158,7 @@ hostap_auth_shared(struct ieee80211_node *ni, stru
estatus = IEEE80211_STATUS_SEQUENCE;
goto bad;
}
- IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUBTYPE_AUTH, seq + 1);
+ //IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUBTYPE_AUTH, seq + 1);
return;
bad:
/*
--
Bernhard
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic in ieee80211 tx mgmt timeout
On Wednesday, June 29, 2011 10:53:41 Stefan Esser wrote: Am 29.06.2011 10:03, schrieb Adrian Chadd: On 29 June 2011 14:03, Bernhard Schmidt bschm...@freebsd.org wrote: It's name is ieee80211_tx_mgt_timeout used to track AUTH/ASSOC requests. Afaik there is even a similar PR about that. Sorry, I manually entered the panic message, since dumps were not working on my system at the time of that panic. Adrian, you've got a AP set up to drop either a AUTH or ASSOC response frame? I've got a number of AUTH - SCAN transition lost messages for wlan0, seconds to minutes apart: Jun 28 21:16:17 kernel: wlan0: ieee80211_new_state_locked: pending AUTH - SCAN transition lost Jun 28 21:34:46 kernel: wlan0: ieee80211_new_state_locked: pending AUTH - SCAN transition lost Jun 28 21:36:33 kernel: wlan0: ieee80211_new_state_locked: pending AUTH - SCAN transition lost Jun 28 21:45:14 kernel: wlan0: ieee80211_new_state_locked: pending AUTH - SCAN transition lost Jun 28 21:45:44 kernel: wlan0: ieee80211_new_state_locked: pending AUTH - SCAN transition lost The setup is easy to reproduce, my rc.conf contained: wlans_ath0=wlan0 ifconfig_ath0=down ifconfig_wlan0=down wpa_supplicant_enable=YES Strip the last 3 lines, don't ever fiddle around with ath0 directly. This configuration always starts wpa_supplicant. This system used to be connected via ath0, but recently was moved to a place where Ethernet is available. The panics started only after WLAN was not used anymore. I might disable wpa_supplicant, since it is not required in the current situation, but did not try whether that helps prevent the panic. Tell me how and I'll set it up. A panic at that point in the function indicates maybe ni is NULL? or ni-vap is now NULL, maybe? I recreated the panic, this time with kernel dumps correctly configured (thanks for the hint, Scott). The panic message is: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xff809c7a1000 fault code = supervisor read data, page not present instruction pointer = 0x20:0x805e1851 stack pointer = 0x28:0xff8000288ab0 frame pointer = 0x28:0xff8000288b60 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 11 (swi4: clock) Traceback: #10 0x805e1851 in ieee80211_tx_mgt_timeout (arg=0xff809c7a1000) at ../../../net80211/ieee80211_output.c:2487 This indicates, that an invalid argument is passed and assigned to *ni, which causes the page fault when dereferencing ni to obtain *va. The problem here seems to be wpa_supplicant. It can try to associate at any given point in time which results in the BSS ni being destroyed, though it might still be referenced somewhere (In this case the timeout stuff, or better said ath's TX queue). Not clearing the reference (or stopping whatever is using it) is the fault here. Now how to figure out who the caller is? Got the complete backtrace? -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn does not associates
On Friday, June 17, 2011 09:36:46 rm...@free.fr wrote: hi all, since a month the wireless card of the E6400 Dell does not associate with the access point. it used to work fine, before. the config is exactly the same: iwn5150fw + iwn + wpa_supplicant = tkip. starting wpa_supplicant associates a few seconds and reverts to no carrier. here is what i get: sysctl dev.iwn.0.debug=1 iwn_notif_intr: scanning channel 7 status 1 ifconfig wlan0 ... status: no carrier ssid MyDomain channel 7 (2442 MHz 11g) regdomain ETSI country FR authmode OPEN privacy OFF txpower 30 bmiss 10 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme bintval 0 thanks in advance for your help. Are you running the latest current? This is a 5350? Can you post your configuration (rc.conf)? If you have a 'ifconfig wlan0 channel 7' somewhere, drop it, I'm aware of an issue regarding fixed channels, but found no clean solution yet. You might also want to try 'ifconfig wlan0 -ht', it might be related to the recent introduction of 11n support for iwn(4). -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: How can I clone a mac address on wlan0?
On Tuesday, March 29, 2011 08:38:43 Doug Barton wrote: For a variety of boring reasons I need to clone a mac address on wlan0. The documented way to do this: ifconfig wlan0 create wlandev wpi0 wlanaddr 00:11:22:33:44:55:66 works in the sense that it sets up the interface with that mac, but then the wlan0 interface never associates. Doing everything the same but omitting the wlanaddr argument (which causes wlan0 to use the mac of the wpi0 device) works. This also doesn't work in 8.2-RELEASE, so either we've got a long-standing bug, or I'm doing something very wrong. The wpi0 card is an intel 3945abg, I also have a couple of ath cards I can try (although so far they haven't worked either). I doubt the wlanaddr option is what you are looking for. This option is only used (and valid) in multiple VAP setups. The BSSID is used to filter frames, everything not to the BSSID (or multicast/broadcast) gets dropped. With multiple VAPs you want to use different BSSIDs for each AP. There are two options to achieve that, using the bssid parameter which will generate a semi random MAC (based on the hardware's MAC address) or the wlanaddr parameter which allows a user to define the complete address. Whether the hardware does support setting multiple BSSID filters is another story, I doubt we have one in tree.. mostly the addresses are generated in such a way that for example either the first 4 or last 4 bits are changed and therefore a wildcard filter can be used. Now to the point, wpi(4) has no support at all for multiple VAPs.. therefore no one ever had a look at that. Anyways.. you might want to look into the link option, changing the wpi0's MAC will also change the one of wlan0. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFR]RT305xF support, w/o attachment
On Monday 21 March 2011 00:16:01 Aleksandr Rybalko wrote: On Mon, 21 Mar 2011 05:59:45 +0800 Adrian Chadd adr...@freebsd.org wrote: On 21 March 2011 04:28, Sergey V. Dyatko sergey.dya...@gmail.com wrote: Last patch from Aleksandr 'works fine for me', so... may be rt2860 should be replaced to 'rt' for example ? rt0: flags= blah-blah-blah IHMO looks more .nice(?) than rt28600: flags= Yup, that's a good idea. Aleksandr, can you please do that? Off-course I can, but seems better name will be rtw or rtn, because we already have if_rt (for RT3052 ether) which have iface name rt. I think rtn is best. Maybe someone have better? rtw is a name for a Realtek driver. I'd prefer if can keep this driver in sync with the OpenBSD one where it is clearly derived from. So, rt28xx and rt30xx support has to be an extension to ral(4). That shouldn't be to hard to do, just throw in the code into dev/ral/ and hook it to the pci/ops code. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFR]RT305xF support, w/o attachment
On Monday, March 21, 2011 10:29:11 Aleksandr Rybalko wrote: Hi, On Mon, 21 Mar 2011 07:04:22 +0100 Bernhard Schmidt bschm...@freebsd.org wrote: On Monday 21 March 2011 00:16:01 Aleksandr Rybalko wrote: On Mon, 21 Mar 2011 05:59:45 +0800 Adrian Chadd adr...@freebsd.org wrote: On 21 March 2011 04:28, Sergey V. Dyatko sergey.dya...@gmail.com wrote: Last patch from Aleksandr 'works fine for me', so... may be rt2860 should be replaced to 'rt' for example ? rt0: flags= blah-blah-blah IHMO looks more .nice(?) than rt28600: flags= Yup, that's a good idea. Aleksandr, can you please do that? Off-course I can, but seems better name will be rtw or rtn, because we already have if_rt (for RT3052 ether) which have iface name rt. I think rtn is best. Maybe someone have better? rtw is a name for a Realtek driver. Realtek driver called urtw, but I agree with you to avoid confusion. That rtw driver I'm speaking of is for older Realtek 8180/8185 PCI based chips. Granted, not in our tree, but it exists. urtw(4) is for 8187B/L USB chipsets. I'd prefer if can keep this driver in sync with the OpenBSD one where it is clearly derived from. So, rt28xx and rt30xx support has to be an extension to ral(4). That shouldn't be to hard to do, just throw in the code into dev/ral/ and hook it to the pci/ops code. This driver closer to USB run(4), but this use USB and difference still big. In future, not so closer, I will try to join run, ral and my rt2860. But there is too much work and I need to find time for it. Please don't. There is a reason the PCI and USB chipsets, even if derived from the same base chipset, have different drivers. The BUS specific implementation/restrictions are way too different/important. Trying to merge those will only make your head ache :) So for now, best name is rtn. If no objections, I send updated patch with new name. I still don't think this is the way to go. Adding a totally independent driver now and replacing (or merging) it later simple won't work. Also, it is quite annoying from user point of view. I urge you to have a closer look at ral(4) and it's way of handling RT2500 and RT2600 specific differences. In it's simplest form you can copy the OpenBSD code 1:1 without any functional changes, heck, it's the source of this driver anyway. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: urtw0: could not allocate USB transfers
On Thursday, March 03, 2011 12:26:20 Etienne Robillard wrote: On 03/03/11 02:45 AM, Hans Petter Selasky wrote: I forwarded this thread on -current. Please also find below a stack trace produced with option KDB_UNATTENDED for the rt28700 driver (if_rt28700). On another side note, I have not being able to load the runfw firmware module anymore after having updated the src tree for 8.2-STABLE ? $ sudo kldload /boot/kernel/runfw.ko kldload: can't load /boot/kernel/runfw.ko: Exec format error Here is your real error in dmesg: KLD runfw.ko: depends on firmware - not available or version mismatch linker_load_file: Unsupported file type You need to kldload firmware.ko or make sure 'device firmware' is in your kernel config. Hi, Many thanks. This explains the change of behavior attempting to kldload runfw.ko without the firmware assist module. :) However I find strange that run(4) requires such a firmware to be preloaded when the rt2870 driver doesn't require it! Cheers, Maybe that's due to a missing MODULE_DEPEND() line in the .c file of urtw0. --HPS Hi, Thanks for the input. I realize the urtw(4) and the pseudo rt2870 drivers may be missing a MODULE_DEPEND macro but this issue is not as annoying than the repeated page faults happening when the card is trying to reassociate itself with a router. urtw(4) has no firmware, run(4) has the appropriate depend line. The rt2870 driver is not in-tree, contact the maintainter. I also noticed the same (random) page faults with the run(4) driver as well but since I don't use a driver requiring a external firmware to be loaded, I would prefer fixing the errors in the generic wireless code happening unconditionally with run(4), rt2870, and possibly urtw(4). Plus, a external firmware seems not necessary for using at least the TEW-644UB wireless adapter! You should by now have noticed that you can't use a Realtek driver with a Ralink chipset, or the other way around. So please stop calling both broken in one mail. Also, again, the rt2870 driver isn't in-tree, contact the maintainer. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cardbus and kldunload issue
On Saturday 26 February 2011 19:36:14 Paul B. Mahol wrote: On Sat, Feb 26, 2011 at 4:25 PM, Bernhard Schmidt bschm...@freebsd.org wrote: Hi, while working on a wireless driver for a Cardbus card I stumbled over an issue which bugs me quite a bit. The device: % none3@pci0:22:0:0: class=0x028000 card=0x107f1043 chip=0x02011814 rev=0x01 hdr=0x00 Loading the module attaches nicely to the device: # kldload if_ral % ral0: Ralink Technology RT2560 mem 0xf480-0xf4801fff irq 16 at device 0.0 on cardbus0 % ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525 % ral0: [ITHREAD] # pciconf -l % ral0@pci0:22:0:0: class=0x028000 card=0x107f1043 chip=0x02011814 rev=0x01 hdr=0x00 Though, kldunload doesn't detach the device, it doesn't even call the module's detach function. # kldunload if_ral # pciconf -l % ral0@pci0:22:0:0: class=0x028000 card=0x107f1043 chip=0x02011814 rev=0x01 hdr=0x00 # kldstat % Id Refs AddressSize Name % 1 27 0x8010 e640a0 kernel # ifconfig ral0 % ral0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 2290 % ether 00:0e:a6:a6:1b:70 % media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) % status: no carrier And of course trying to use the device at that point will result in instant panics. Playing around a bit I've noticed that changing the bus name in: % DRIVER_MODULE(ral, pci, ral_pci_driver, ral_devclass, 0, 0); from pci to cardbus makes a big difference. On module unload the detach function is then called as expected. So, question is, are we doing some too strict checks on module unload while matching the bus? Or is this expected behavior and the drivers are supposed to indiciated that they support both pci and cardbus? I don't see the later anywhere in tree. There is MODULE_DEPEND(), if_ndis depends on pccard, pci and usb modules and use both MODULE_DEPEND() and DRIVER_MODULE() with them. If I'm not mistaken pccard depends on cardbus. I tried playing around with various MODULE_DEPEND() values, without any differences. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cardbus and kldunload issue
On Monday 28 February 2011 14:37:31 John Baldwin wrote:
On Saturday, February 26, 2011 10:25:41 am Bernhard Schmidt wrote:
Hi,
while working on a wireless driver for a Cardbus card I stumbled over
an issue which bugs me quite a bit.
The device:
% none3@pci0:22:0:0: class=0x028000 card=0x107f1043 chip=0x02011814
rev=0x01 hdr=0x00
Loading the module attaches nicely to the device:
# kldload if_ral
% ral0: Ralink Technology RT2560 mem 0xf480-0xf4801fff irq 16 at
device 0.0 on cardbus0
% ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525
% ral0: [ITHREAD]
# pciconf -l
% ral0@pci0:22:0:0: class=0x028000 card=0x107f1043 chip=0x02011814
rev=0x01 hdr=0x00
Though, kldunload doesn't detach the device, it doesn't even call the
module's detach function.
# kldunload if_ral
# pciconf -l
% ral0@pci0:22:0:0: class=0x028000 card=0x107f1043 chip=0x02011814
rev=0x01 hdr=0x00
# kldstat
% Id Refs AddressSize Name
% 1 27 0x8010 e640a0 kernel
# ifconfig ral0
% ral0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 2290
% ether 00:0e:a6:a6:1b:70
% media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
% status: no carrier
And of course trying to use the device at that point will result in
instant panics. Playing around a bit I've noticed that changing the bus
name in:
% DRIVER_MODULE(ral, pci, ral_pci_driver, ral_devclass, 0, 0);
from pci to cardbus makes a big difference. On module unload the detach
function is then called as expected. So, question is, are we doing some
too strict checks on module unload while matching the bus? Or is this
expected behavior and the drivers are supposed to indiciated that they
support both pci and cardbus? I don't see the later anywhere in tree.
This sounds like a bug in how the inheritance stuff in new-bus drivers works.
The DRIVER_MODULE() line for cardbus is implicit because the 'cardbus' driver
inherits from the generic 'pci' bus driver. That is how kldload works
correctly. It seems we need to do some extra plumbing for the kldunload
case.
The bug is that 189574 only patched the devclass add driver path, not the
delete driver path. Try this:
That fixes it, thanks! kldunload now successfully calls the driver's
detach method.
Index: subr_bus.c
===
--- subr_bus.c(revision 219096)
+++ subr_bus.c(working copy)
@@ -987,11 +987,13 @@ devclass_find(const char *classname)
* is called by devclass_add_driver to accomplish the recursive
* notification of all the children classes of dc, as well as dc.
* Each layer will have BUS_DRIVER_ADDED() called for all instances of
- * the devclass. We do a full search here of the devclass list at
- * each iteration level to save storing children-lists in the devclass
- * structure. If we ever move beyond a few dozen devices doing this,
- * we may need to reevaluate...
+ * the devclass.
*
+ * We do a full search here of the devclass list at each iteration
+ * level to save storing children-lists in the devclass structure. If
+ * we ever move beyond a few dozen devices doing this, we may need to
+ * reevaluate...
+ *
* @param dc the devclass to edit
* @param driver the driver that was just added
*/
@@ -1085,6 +1087,78 @@ devclass_add_driver(devclass_t dc, driver_t *drive
}
/**
+ * @brief Register that a device driver has been deleted from a devclass
+ *
+ * Register that a device driver has been removed from a devclass.
+ * This is called by devclass_delete_driver to accomplish the
+ * recursive notification of all the children classes of busclass, as
+ * well as busclass. Each layer will attempt to detach the driver
+ * from any devices that are children of the bus's devclass. The function
+ * will return an error if a device fails to detach.
+ *
+ * We do a full search here of the devclass list at each iteration
+ * level to save storing children-lists in the devclass structure. If
+ * we ever move beyond a few dozen devices doing this, we may need to
+ * reevaluate...
+ *
+ * @param busclass the devclass of the parent bus
+ * @param dc the devclass of the driver being deleted
+ * @param driver the driver being deleted
+ */
+static int
+devclass_driver_deleted(devclass_t busclass, devclass_t dc, driver_t *driver)
+{
+ devclass_t parent;
+ device_t dev;
+ int error, i;
+
+ /*
+ * Disassociate from any devices. We iterate through all the
+ * devices in the devclass of the driver and detach any which are
+ * using the driver and which have a parent in the devclass which
+ * we are deleting from.
+ *
+ * Note that since a driver can be in multiple devclasses, we
+ * should not detach devices which are not children of devices
cardbus and kldunload issue
Hi, while working on a wireless driver for a Cardbus card I stumbled over an issue which bugs me quite a bit. The device: % none3@pci0:22:0:0: class=0x028000 card=0x107f1043 chip=0x02011814 rev=0x01 hdr=0x00 Loading the module attaches nicely to the device: # kldload if_ral % ral0: Ralink Technology RT2560 mem 0xf480-0xf4801fff irq 16 at device 0.0 on cardbus0 % ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525 % ral0: [ITHREAD] # pciconf -l % ral0@pci0:22:0:0: class=0x028000 card=0x107f1043 chip=0x02011814 rev=0x01 hdr=0x00 Though, kldunload doesn't detach the device, it doesn't even call the module's detach function. # kldunload if_ral # pciconf -l % ral0@pci0:22:0:0: class=0x028000 card=0x107f1043 chip=0x02011814 rev=0x01 hdr=0x00 # kldstat % Id Refs AddressSize Name % 1 27 0x8010 e640a0 kernel # ifconfig ral0 % ral0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 2290 % ether 00:0e:a6:a6:1b:70 % media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) % status: no carrier And of course trying to use the device at that point will result in instant panics. Playing around a bit I've noticed that changing the bus name in: % DRIVER_MODULE(ral, pci, ral_pci_driver, ral_devclass, 0, 0); from pci to cardbus makes a big difference. On module unload the detach function is then called as expected. So, question is, are we doing some too strict checks on module unload while matching the bus? Or is this expected behavior and the drivers are supposed to indiciated that they support both pci and cardbus? I don't see the later anywhere in tree. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: console freeze after ifconfig wlan0 scan with wi(4) pccard device
On Sunday, January 09, 2011 23:22:28 Anton Shterenlikht wrote: On amd64 r217010 laptop (HP Compaq 6715s) I'm trying to use this wi(4) device: wi0: The Linksys Group, Inc. Instant Wireless Network PC Card at port 0x100-0x13f irq 20 function 0 config 1 on pccard0 I do # ifconfig wlan0 create wlandev wi0 # ifconfig -a bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTAT E ether 00:1a:4b:89:4b:4e inet 192.168.1.102 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL wi0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 00:06:25:10:56:3b media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier wlan0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:06:25:10:56:3b media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid channel 1 (2412 MHz 11b) country US authmode OPEN privacy OFF txpower 0 bmiss 7 scanvalid 60 bintval 0 But after # ifconfig wlan0 up scan I get console freeze requiring cold reboot. No panic, just a LOR: wi0: The Linksys Group, Inc. Instant Wireless Network PC Card at port 0x100-0x13f irq 20 function 0 config 1 on pccard0 wlan0: Ethernet address: 00:06:25:10:56:3b lock order reversal: 1st 0xff80012be018 wi0_com_lock (wi0_com_lock) @ /usr/src/sys/net80211/ieee80211_scan.c:806 2nd 0xfe0001b8d010 wi0 (network driver) @ /usr/src/sys/dev/wi/if_wi.c:1083 KDB: stack backtrace: [..] This is a known LOR, many wireless do have that. It happens right after a scan iteration if there is a network to connect to. In case it matters I've hw.cbb.start_memory=0xf480 in /boot/loader.conf, according to http://www.freebsd.org/cgi/query-pr.cgi?pr=115623 Do you by any change have another device you can test the pccard slot with? Also, you might want to try 'ifconfig wlan0 ssid somethingwhichdoesdefinitelynotexist up; ifconfig wlan0 list scan' instead of 'ifconfig wlan0 up scan'. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wlan/wpi are more broken than 3 weeks.
On Saturday 01 January 2011 19:47:21 you wrote: On Mon, Dec 27, 2010 at 02:05:25AM +0100, Bernhard Schmidt wrote: On Monday 27 December 2010 01:32:56 Steve Kargl wrote: On Sun, Dec 26, 2010 at 11:25:05PM +0100, Bernhard Schmidt wrote: [ .. ] If you can get debug output while the UPs/DOWNs happen, that would help a lot. Sorry about the delay. The laptop has been in Windows land for the last week. I finally have a log where the interface is going UP/DOWN and have wlandebug in effect. It's 220KB. You can find it at Thanks http://troutmask.apl.washington.edu/~kargl/wlan0.msg wlan0: AMRR decreasing rate 48 (txcnt=35 retrycnt=14) wlan0: recv deauthenticate (reason 2) wlan0: ieee80211_new_state_locked: RUN - AUTH (nrunning 0 nscanning 0) I've seen those before, though, I never figured out if there is a way to bypass that. What's happening here is that the AP detects that you've ben idle (as in not sending frames) for quite a while (the rate decrease does indicate that) and kicks you with a 'auth no longer valid' message. This seems to be a 'feature' of your AP and not an issue with the driver, at least I do not see any connection. As a workaround try to ping something behind the AP. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wlan/wpi are more broken than 3 weeks.
On Sunday 26 December 2010 22:39:58 Steve Kargl wrote: On Sun, Dec 26, 2010 at 04:43:48PM -0500, Etienne Robillard wrote: On 26/12/10 02:55 PM, Steve Kargl wrote: First reported here, http://lists.freebsd.org/pipermail/freebsd-current/2010-December/021664 .html I now see a never ending spew in /var/log/messages of laptop:kargl[232] tail /var/log/messages Dec 26 07:58:27 laptop kernel: wlan0: link state changed to DOWN Dec 26 07:58:27 laptop kernel: wlan0: link state changed to UP So, the good news appears to be that 3 weeks ago wlan/wpi could stay up for 7 to 9 minutes before cycling DOWN/UP. While the bad news is that today, the DOWN/UP cycle last for 4 to 5 minutes. have you compiled with IEEE_DEBUG ? Yes. How about providing the info I asked for last time? Now that you have build the necessary options into the kernel you should be able to run with wlandebug 0x enabled. I would also like knowing which wireless NIC you're using. Is this bug related to a USB wireless card ? I have similar issues (recurring) on Freebsd 8.1. my current understanding is that USB wireless on FreeSD is somewhat a itchy business.. It's a nic builtin into a Dell D530 laptop. laptop:kargl[202] dmesg | grep wpi wpi0: Intel(R) PRO/Wireless 3945ABG mem 0xfe8ff000-0xfe8f irqi 17 at device 0.0 on pci12 I just backed out revision 214894 to test whether this is the problematic commit. http://svn.freebsd.org/viewvc/base/head/sys/dev/wpi/if_wpi.c?view=log -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wlan/wpi are more broken than 3 weeks.
On Monday 27 December 2010 01:32:56 Steve Kargl wrote: On Sun, Dec 26, 2010 at 11:25:05PM +0100, Bernhard Schmidt wrote: How about providing the info I asked for last time? Now that you have build the necessary options into the kernel you should be able to run with wlandebug 0x enabled. Perhaps, I got busy with real life work, and perhaps, I forgot you asked for this info. In the end, /var/log/messages get stuff full of Dec 26 16:30:04 laptop kernel: wlan0: received beacon from 00:18:e7:d4:f2:1b rssi 37 Dec 26 16:30:04 laptop kernel: wlan0: received beacon from 00:18:e7:d4:f2:1b rssi 38 Dec 26 16:30:04 laptop kernel: wlan0: received beacon from 00:18:e7:d4:f2:1b rssi 40 Dec 26 16:30:04 laptop kernel: wlan0: received beacon from 00:18:e7:d4:f2:1b rssi 34 Dec 26 16:30:04 laptop kernel: wlan0: received beacon from 00:18:e7:d4:f2:1b rssi 38 Dec 26 16:30:04 laptop kernel: wlan0: received beacon from 00:18:e7:d4:f2:1b rssi 38 Dec 26 16:30:04 laptop kernel: wlan0: received beacon from 00:18:e7:d4:f2:1b rssi 41 Dec 26 16:30:04 laptop kernel: wlan0: received beacon from 00:18:e7:d4:f2:1b rssi 40 Dec 26 16:30:04 laptop kernel: wlan0: received beacon from 00:18:e7:d4:f2:1b rssi 32 Dec 26 16:30:05 laptop kernel: wlan0: received beacon from 00:18:e7:d4:f2:1b rssi 34 Dec 26 16:30:05 laptop kernel: wlan0: received beacon from 00:18:e7:d4:f2:1b rssi 41 Dec 26 16:30:05 laptop kernel: wlan0: received beacon from 00:18:e7:d4:f2:1b rssi 41 Dec 26 16:30:05 laptop kernel: wlan0: received beacon from 00:18:e7:d4:f2:1b rssi 40 Dec 26 16:30:05 laptop kernel: wlan0: received beacon from 00:18:e7:d4:f2:1b rssi 37 Dec 26 16:30:05 laptop kernel: wlan0: received beacon from 00:18:e7:d4:f2:1b rssi 40 Dec 26 16:30:05 laptop kernel: wlan0: received beacon from 00:18:e7:d4:f2:1b rssi 40 Dec 26 16:30:05 laptop kernel: wlan0: received beacon from 00:18:e7:d4:f2:1b rssi 32 Dec 26 16:30:05 laptop kernel: wlan0: received beacon from 00:18:e7:d4:f2:1b rssi 35 Dec 26 16:30:05 laptop kernel: wlan0: received beacon from 00:18:e7:d4:f2:1b rssi 40 because apparently this message isn't rate limited. So, perhaps, this is the problem? I don't think so, those messages are usually an indicator for a successful connection. AP sends those as a 'hello, i'm still here' kinda thing. You should be able to supress those with 'wlandebug 0x -dumppkts'. If you can get debug output while the UPs/DOWNs happen, that would help a lot. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wlan0 going UP/DOWN problem
On Sunday 05 December 2010 07:21:03 Steve Kargl wrote: It seems some recent change (as in the last 7-10 days) has caused an instability in wlan0. Just a small excerpt from /var/log/messages, Dec 4 18:54:16 laptop kernel: wlan0: link state changed to UP Dec 4 19:11:16 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:11:16 laptop kernel: wlan0: link state changed to UP Dec 4 19:19:46 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:19:46 laptop kernel: wlan0: link state changed to UP Dec 4 19:37:01 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:37:01 laptop kernel: wlan0: link state changed to UP Dec 4 19:45:31 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:45:31 laptop kernel: wlan0: link state changed to UP Dec 4 19:54:01 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:54:01 laptop kernel: wlan0: link state changed to UP Dec 4 20:11:16 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:11:16 laptop kernel: wlan0: link state changed to UP Dec 4 20:19:46 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:19:46 laptop kernel: wlan0: link state changed to UP Dec 4 20:36:46 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:36:46 laptop kernel: wlan0: link state changed to UP Dec 4 20:45:16 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:45:16 laptop kernel: wlan0: link state changed to UP Dec 4 20:53:46 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:53:46 laptop kernel: wlan0: link state changed to UP So, every 18 minutes the devices is going DOWN/UP. :-/ More details please. Which driver? How is that stuff configured? wpa_supplicant involved? Try running it with debug messages enabled. We need to figure out what entity is causing the device to go down/up, this can either be wpa_supplicant or net80211 (or a cronjob calling ifconfig down/up every 18 minutes ;). The appropriate debug options enabled (wlandebug 0x or wpa_supplicant with -dd) should reveal that. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wpa_supplicant gets points for trying, I suppose....
On Tuesday, November 02, 2010 22:55:18 David Wolfskill wrote: On Tue, Nov 02, 2010 at 06:30:10PM +0100, Bernhard Schmidt wrote: Thanks. I had quick look into that and I currently do not see an easy way to address that issue, as in tell wpa_supplicant about the device's state. This might change though once a newer wpa_supplicant has been imported. I'm not entirely surprised -- a quick look I took at sys/dev/iwn seemed to indicate to me that whiule iwn(4) could whine about the switch, it didn't have much in the way of ability to actually provide information about that status in some other way (e.g., a non-zero return from attempt to mess with the device). But I don't claim extensive expertise in that area. There is ieee80211_notify_radio(), granted iwn(4) misses the calls.. that function is supposed to notify upper layers about the radio state (0 = off, 1 = on). Anyways, once wpa_supplicant import/update is done, I'll probably have a look into that again. For now just add wpa_supplicant_flags=- to rc.conf. : :-} That, or decide to ignore the silly messages Noted, thanks. Peace, david -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wpa_supplicant gets points for trying, I suppose....
On Monday, November 01, 2010 23:32:49 Paul B Mahol wrote: On 11/1/10, David Wolfskill da...@catwhisker.org wrote: FreeBSD 9.0-CURRENT #31 r214621M Nov 1 15:09:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:10:10 d130 last message repeated 3 times Nov 1 15:10:50 d130 last message repeated 4 times ... Nov 1 15:11:00 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:11:10 d130 wpa_supplicant[569]: Failed to initiate AP scan. ... Nov 1 15:11:20 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:11:30 d130 wpa_supplicant[569]: Failed to initiate AP scan. ... Nov 1 15:11:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. ... Nov 1 15:11:50 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:12:10 d130 last message repeated 2 times Nov 1 15:14:10 d130 last message repeated 12 times I have the switch on this laptop in position to disable the wireless device (iwn(4)). Is there some way wpa_supplicant (or something) might be able to recognize that this is a pointless exercise? Well iwn could bring device down when radio is turned off and bring it up when radio is turned on ??? Well, that should actually be the case. I don't see how it might differ between stable/8 and head. Can you post the output of wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d while the RF kill button is in disabled state? I don't recall stable/8 doing this, though I could be wrong. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wpa_supplicant gets points for trying, I suppose....
On Tue, Nov 2, 2010 at 16:53, David Wolfskill da...@catwhisker.org wrote: On Tue, Nov 02, 2010 at 08:40:54AM +0100, Bernhard Schmidt wrote: I have the switch on this laptop in position to disable the wireless device (iwn(4)). Is there some way wpa_supplicant (or something) might be able to recognize that this is a pointless exercise? Well iwn could bring device down when radio is turned off and bring it up when radio is turned on ??? Well, that should actually be the case. I don't see how it might differ between stable/8 and head. Can you post the output of wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d while the RF kill button is in disabled state? I don't recall stable/8 doing this, though I could be wrong. Next time I booted stable/8, I checked /var/log/messages, and verified that wpa_supplicant is also persistent in that environment. So I did the above within script(1); I've attached a copy of the typescript file. This was done while running: FreeBSD 8.1-STABLE #20 r214672: Tue Nov 2 04:19:13 PDT 2010 Thanks. I had quick look into that and I currently do not see an easy way to address that issue, as in tell wpa_supplicant about the device's state. This might change though once a newer wpa_supplicant has been imported. For now just add wpa_supplicant_flags=- to rc.conf. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wpa_supplicant gets points for trying, I suppose....
On Tue, Nov 2, 2010 at 19:06, Garrett Cooper gcoo...@freebsd.org wrote: On Tue, Nov 2, 2010 at 10:30 AM, Bernhard Schmidt bschm...@freebsd.org wrote: On Tue, Nov 2, 2010 at 16:53, David Wolfskill da...@catwhisker.org wrote: On Tue, Nov 02, 2010 at 08:40:54AM +0100, Bernhard Schmidt wrote: I have the switch on this laptop in position to disable the wireless device (iwn(4)). Is there some way wpa_supplicant (or something) might be able to recognize that this is a pointless exercise? Well iwn could bring device down when radio is turned off and bring it up when radio is turned on ??? Well, that should actually be the case. I don't see how it might differ between stable/8 and head. Can you post the output of wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d while the RF kill button is in disabled state? I don't recall stable/8 doing this, though I could be wrong. Next time I booted stable/8, I checked /var/log/messages, and verified that wpa_supplicant is also persistent in that environment. So I did the above within script(1); I've attached a copy of the typescript file. This was done while running: FreeBSD 8.1-STABLE #20 r214672: Tue Nov 2 04:19:13 PDT 2010 Thanks. I had quick look into that and I currently do not see an easy way to address that issue, as in tell wpa_supplicant about the device's state. This might change though once a newer wpa_supplicant has been imported. For now just add wpa_supplicant_flags=- to rc.conf. Device states could and should be periodically polled via the SIOCGIFMEDIA ioctl, but currently isn't (even in the CURRENT version of wpa_supplicant). This seems like a worthy enhancement. Not necessarily, we have a event based facility for that, the functions are empty though because the consumer, wpa_supplicant, is not able to make any use of it. There were some changes in 0.7 for interface states but I'm not sure what exactly changed, it might be possible to use events for the 'rfkill on' case, the 'rfkill off' might still need polling.. Once Rui has imported the new wpa stuff, someone should implemented the proper calls :) -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wpa_supplicant and ssid
On Monday, October 18, 2010 18:55:34 you wrote: It seems that wpa_supplicant iterate through all scanned ssids and try to associate with each, and that cause two problem for me. 1) in my school, there are many AP, and connection is not stable, when disconnect, it take many time to try and fail to associate with those ssids until the one I want. You can add a 'priority' statement to each network block in wpa_supplicant.conf. 2) i can't associate with a non-discoverable ssid but probably it is my wireless driver's problem, i'm using bwn0 and currently I need to force it to use mode 11b or it is unusable. Tried different options for the scan_ssid parameter? or should I complain to upstream ? Before doing so, can you capture the output of 'wlandebug 0x' while trying to get a connection? -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: if_ath HAL refactoring
On Wednesday, September 22, 2010 06:04:49 PseudoCylon wrote: - Original Message From: Adrian Chadd adr...@freebsd.org To: PseudoCylon moonlightak...@yahoo.ca Cc: freebsd-current@freebsd.org Sent: Tue, September 21, 2010 7:04:37 AM Subject: Re: RFT: if_ath HAL refactoring On 21 September 2010 11:58, PseudoCylon moonlightak...@yahoo.ca wrote: Just in case anyone wonders, I've added 11n support to run(4) (USB NIC). http://gitorious.org/run/run/trees/11n_beta2 It still has some issues, * doesn't work well with atheros chips * HT + AP + bridge = Tx may stall (seems OK with nat) So, use it at your own discretion. Want to put together a patch? sure! Does it introduce issues in the non-11n case? No, only in 11n mode. What I have found so far is that Ralink's driver checks MAC address of other end and identify atheros chip by oui. Then, sets special prot mode for it. Does this ring a bell? Are your sure that this is based on the actual MAC addresses? Atheros drivers tend to announce additional capabilities in beacons and probe responses. Has node lock in ieee80211_node_timeout() cased dead lock in HT + AP + bridge? I'm not aware of any issues there, though, I'm not very familiar with HT use cases. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: problem with wpa_supplicant
On Friday, September 03, 2010 01:34:54 Davide Italiano wrote:
Hi. I've been recently upgraded to -CURRENT (9.0).
After
# make buildworld
# make buildkernel KERNCONF=MYKERNEL
# make install kernel KERNCONF=MYKERNEL
I have rebooted to single-user mode, as suggested in the documentation.
No more wireless connection. I've a intel 2200 bg wireless card,
running using the kernel built-in iwi module.
In particular, when I run wpa_supplicant -i wlan0 -c
/etc/wpa_supplicant.conf I get this:
CTRL-EVENT-SCAN-RESULTS
CTRL-EVENT-SCAN-RESULTS
CTRL-EVENT-SCAN-RESULTS
...
My wpa_supplicant.conf is:
ap_scan=1
fast_reauth=1
network={
ssid=MY_SSID
psk=MY_KEY
}
Also, my /boot/loader.conf contains
legal.intel_iwi.license_ack=1
if_iwi_load=YES
and my rc.conf
wlans_iwi0=wlan0
ifconfig_wlan0=WPA inet 192.168.1.110 netmask 0xff00
defaultrouter=192.168.1.1
Again, it worked w/ freebsd 8.1 (stable). Also, I've read in the
UPDATING file in /usr/src this:
Applications such as wpa_supplicant(8) may require a full world
build without using NO_CLEAN in order to get synchronized with the
new structure.
But, I've done a make buildworld before, isn't enough?
Thanks a lot
Did you also run make installworld?
--
Bernhard
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: recent ath changes related panic
On Fri, Aug 20, 2010 at 22:51, Chris Ruiz yr.retar...@gmail.com wrote: On Fri, Aug 20, 2010 at 1:56 AM, Bernhard Schmidt bschm...@techwires.net wrote: On Fri, Aug 20, 2010 at 08:31, Bernhard Schmidt bschm...@techwires.net wrote: On Fri, Aug 20, 2010 at 01:04, Chris Ruiz yr.retar...@gmail.com wrote: I run a PCI Atheros card in hostap mode on CURRENT. a...@pci0:6:0:0: class=0x02 card=0x5a001385 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = '802.11a/b/g Wireless Adapter (AR2312)' class = network subclass = ethernet Everything works fine with r211193 but with newer kernels I receive the same panic related to the ath0 tasq. I guess this also happens with post-r211314 kernels? Seems like I missed you wrap a few ieee80211_ratectl_node_init() s,you,to, of course. calls. Please try attached patch, it should fix it. Thanks! My system no longer panics at the login prompt. Committed, thanks. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: recent ath changes related panic
On Fri, Aug 20, 2010 at 08:31, Bernhard Schmidt bschm...@techwires.net wrote:
On Fri, Aug 20, 2010 at 01:04, Chris Ruiz yr.retar...@gmail.com wrote:
I run a PCI Atheros card in hostap mode on CURRENT.
a...@pci0:6:0:0: class=0x02 card=0x5a001385 chip=0x0013168c
rev=0x01 hdr=0x00
vendor = 'Atheros Communications Inc.'
device = '802.11a/b/g Wireless Adapter (AR2312)'
class = network
subclass = ethernet
Everything works fine with r211193 but with newer kernels I receive
the same panic related to the ath0 tasq.
I guess this also happens with post-r211314 kernels?
Seems like I missed you wrap a few ieee80211_ratectl_node_init()
calls. Please try attached patch, it should fix it.
--
Bernhard
Index: sys/net80211/ieee80211_node.c
===
--- sys/net80211/ieee80211_node.c (revision 211524)
+++ sys/net80211/ieee80211_node.c (working copy)
@@ -817,8 +817,7 @@ ieee80211_sta_join(struct ieee80211vap *vap, struc
if (ieee80211_iserp_rateset(ni-ni_rates))
ni-ni_flags |= IEEE80211_NODE_ERP;
ieee80211_node_setuptxparms(ni);
- if (vap-iv_caps IEEE80211_C_RATECTL)
- ieee80211_ratectl_node_init(ni);
+ ieee80211_ratectl_node_init(ni);
return ieee80211_sta_join1(ieee80211_ref_node(ni));
}
Index: sys/net80211/ieee80211_sta.c
===
--- sys/net80211/ieee80211_sta.c (revision 211524)
+++ sys/net80211/ieee80211_sta.c (working copy)
@@ -1597,8 +1597,7 @@ sta_recv_mgmt(struct ieee80211_node *ni, struct mb
IEEE80211_F_JOIN | IEEE80211_F_DOBRS);
ieee80211_setup_basic_htrates(ni, htinfo);
ieee80211_node_setuptxparms(ni);
- if (vap-iv_caps IEEE80211_C_RATECTL)
-ieee80211_ratectl_node_init(ni);
+ ieee80211_ratectl_node_init(ni);
} else {
#ifdef IEEE80211_SUPPORT_SUPERG
if (IEEE80211_ATH_CAP(vap, ni, IEEE80211_NODE_ATH))
Index: sys/net80211/ieee80211_ratectl.h
===
--- sys/net80211/ieee80211_ratectl.h (revision 211524)
+++ sys/net80211/ieee80211_ratectl.h (working copy)
@@ -77,7 +77,8 @@ ieee80211_ratectl_node_init(struct ieee80211_node
{
const struct ieee80211vap *vap = ni-ni_vap;
- vap-iv_rate-ir_node_init(ni);
+ if (vap-iv_caps IEEE80211_C_RATECTL)
+ vap-iv_rate-ir_node_init(ni);
}
static void __inline
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: recent ath changes related panic
On Fri, Aug 20, 2010 at 01:04, Chris Ruiz yr.retar...@gmail.com wrote: I run a PCI Atheros card in hostap mode on CURRENT. a...@pci0:6:0:0: class=0x02 card=0x5a001385 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = '802.11a/b/g Wireless Adapter (AR2312)' class = network subclass = ethernet Everything works fine with r211193 but with newer kernels I receive the same panic related to the ath0 tasq. I guess this also happens with post-r211314 kernels? the panic - http://tinypic.com/r/11t3g39/4 the backtrace - http://tinypic.com/r/nv4786/4 Sorry about the pics, I don't have access to serial or dcons. -- Chris Ruiz - http://twitter.com/chrisattack http://chrisattack.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic: Kernel page fault with ath0_com_lock held, r211295
On Sat, Aug 14, 2010 at 18:47, David Wolfskill da...@catwhisker.org wrote: On Sun, Aug 15, 2010 at 12:07:13AM +0800, Adrian Chadd wrote: You should be able to revert the ath changes reasonably easy. Would you mind doing that and see if that fixes or contributes to the problem? OK; I reverted by doing this: g1-46(9.0-C)[1] cd /usr/src g1-46(9.0-C)[2] svn merge -c -211295 file:///svn/freebsd/src/base/head --- Reverse-merging r211295 into 'sys': U sys/net80211/ieee80211_node.c U sys/net80211/ieee80211_sta.c g1-46(9.0-C)[3] I then re-built the kernel and rebooted (with the ath(4) card inserted): [..] I think that qualifies as working. Indeed, please try attached patch. -- Bernhard ratectl_node_init.diff Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic: Kernel page fault with ath0_com_lock held, r211295
On Sat, Aug 14, 2010 at 19:43, David Wolfskill da...@catwhisker.org wrote: On Sat, Aug 14, 2010 at 07:05:40PM +0200, Bernhard Schmidt wrote: ... OK; I reverted by doing this: g1-46(9.0-C)[1] cd /usr/src g1-46(9.0-C)[2] svn merge -c -211295 file:///svn/freebsd/src/base/head --- Reverse-merging r211295 into 'sys': U sys/net80211/ieee80211_node.c U sys/net80211/ieee80211_sta.c g1-46(9.0-C)[3] I then re-built the kernel and rebooted (with the ath(4) card inserted): [..] I think that qualifies as working. Indeed, please try attached patch. Patch applied cleanly; rebuilt kernel; rebooted OK: Thanks, I've committed a 'slightly' different version. Drivers which aren't using the ratectl framework should be unaffected by any changes regarding ratectl in the future. Sorry for the noise. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
