* Re: [rfkill PATCH] default install to $(PREFIX)/sbin
From: Johannes Berg @ 2009-09-29 21:02 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20090929210001.GG2678@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]
On Tue, 2009-09-29 at 17:00 -0400, John W. Linville wrote:
> On Tue, Sep 29, 2009 at 10:34:37PM +0200, Johannes Berg wrote:
> > On Tue, 2009-09-29 at 13:41 -0400, John W. Linville wrote:
> > > The rfkill utility isn't generally useful to normal users, so move it to
> > > /sbin with other system management executables.
> >
> > Seems to me that it's kinda useful, it should be possible for most users
> > to use the event and query interface if the /dev/rfkill permissions are
> > set up correctly.
>
> Sure, but (just like ip, ifconfig, or iwconfig) nothing stops people
> from using them in /sbin or /usr/sbin. It is just a convention for
> tools that are more for system management than for day-to-day use.
>
> Hopefully most people will stick with NM or whatever and may stay
> completely unaware of the rfkill utility. :-)
So are you going to send an iw patch too? :-)
FWIW I like tools in bin/ since the default paths on most systems for
users don't include sbin/.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [rfkill PATCH] default install to $(PREFIX)/sbin
From: John W. Linville @ 2009-09-29 21:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1254256477.30589.1.camel@johannes.local>
On Tue, Sep 29, 2009 at 10:34:37PM +0200, Johannes Berg wrote:
> On Tue, 2009-09-29 at 13:41 -0400, John W. Linville wrote:
> > The rfkill utility isn't generally useful to normal users, so move it to
> > /sbin with other system management executables.
>
> Seems to me that it's kinda useful, it should be possible for most users
> to use the event and query interface if the /dev/rfkill permissions are
> set up correctly.
Sure, but (just like ip, ifconfig, or iwconfig) nothing stops people
from using them in /sbin or /usr/sbin. It is just a convention for
tools that are more for system management than for day-to-day use.
Hopefully most people will stick with NM or whatever and may stay
completely unaware of the rfkill utility. :-)
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [rfkill PATCH] default install to $(PREFIX)/sbin
From: Johannes Berg @ 2009-09-29 20:34 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <1254246097-4490-1-git-send-email-linville@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 367 bytes --]
On Tue, 2009-09-29 at 13:41 -0400, John W. Linville wrote:
> The rfkill utility isn't generally useful to normal users, so move it to
> /sbin with other system management executables.
Seems to me that it's kinda useful, it should be possible for most users
to use the event and query interface if the /dev/rfkill permissions are
set up correctly.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: 2.6.32-rc2: wlan rt73 dead
From: Heinz Diehl @ 2009-09-29 20:04 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-kernel, linux-wireless
In-Reply-To: <20090929191948.GE2678@tuxdriver.com>
On 29.09.2009, John W. Linville wrote:
> Could you do a git bisect?
I have never used git in my whole life, but I'll read the documentation
and try.
^ permalink raw reply
* New cfg80211 warning on 2.6.32-rc<bleh>
From: Luis R. Rodriguez @ 2009-09-29 19:37 UTC (permalink / raw)
To: linux-wireless
I got this while running my tests by booting with mem=300M and CPU downscaled.
Luis
[ 2032.396393] phy4: Removed STA <ap-BSSID>
[ 2032.408522] phy4: Destroyed STA <ap-BSSID>
[ 2032.408542] wlan0: deauthenticating from <ap-BSSID> by local choice
(reason=3)
[ 2032.442906] phy4: device now idle
[ 2032.451837] ------------[ cut here ]------------
[ 2032.451876] WARNING: at net/wireless/core.c:613
wdev_cleanup_work+0xe9/0x110 [cfg80211]()
[ 2032.451883] Hardware name: 7660A14
[ 2032.451888] Modules linked in: ath5k(-) <bleh>
[ 2032.452072] Pid: 10, comm: events/1 Tainted: G W 2.6.32-rc2-wl #45
[ 2032.452080] Call Trace:
[ 2032.452098] [<ffffffff8105be78>] warn_slowpath_common+0x78/0xb0
[ 2032.452109] [<ffffffff8105bebf>] warn_slowpath_null+0xf/0x20
[ 2032.452127] [<ffffffffa00c25b9>] wdev_cleanup_work+0xe9/0x110 [cfg80211]
[ 2032.452144] [<ffffffffa00c24d0>] ? wdev_cleanup_work+0x0/0x110 [cfg80211]
[ 2032.452156] [<ffffffff81075c3e>] worker_thread+0x1fe/0x3b0
[ 2032.452165] [<ffffffff81075bed>] ? worker_thread+0x1ad/0x3b0
[ 2032.452176] [<ffffffff8107abf0>] ? autoremove_wake_function+0x0/0x40
[ 2032.452188] [<ffffffff81075a40>] ? worker_thread+0x0/0x3b0
[ 2032.452198] [<ffffffff8107a82e>] kthread+0x8e/0xa0
[ 2032.452209] [<ffffffff8101300a>] child_rip+0xa/0x20
[ 2032.452221] [<ffffffff81012990>] ? restore_args+0x0/0x30
[ 2032.452230] [<ffffffff8107a7a0>] ? kthread+0x0/0xa0
[ 2032.452239] [<ffffffff81013000>] ? child_rip+0x0/0x20
[ 2032.452245] ---[ end trace 7d678c5342bdcaab ]---
[ 2033.767265] ath5k 0000:03:00.0: PCI INT A disabled
^ permalink raw reply
* Re: mac80211: NOHZ: local_softirq_pending 08
From: John W. Linville @ 2009-09-29 19:29 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Michael Buesch, Kalle Valo, linux-wireless, netdev, Johannes Berg
In-Reply-To: <4AABCF28.6090505@hartkopp.net>
On Sat, Sep 12, 2009 at 06:41:12PM +0200, Oliver Hartkopp wrote:
> i cooked a patch that introduces netif_rx_ti() and fixes up the problems in
> mac80211 and the CAN subsystem.
Oliver,
Are you going to send this patch to Dave? If you want me to carry
it instead, please resend it with a proper changelog including a
Signed-off-by line. For that matter, Dave will most certainly want
that as well...
Thanks!
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: 2.6.32-rc2: wlan rt73 dead
From: John W. Linville @ 2009-09-29 19:19 UTC (permalink / raw)
To: Heinz Diehl; +Cc: linux-kernel, linux-wireless
In-Reply-To: <20090929191125.GA5640@fancy-poultry.org>
On Tue, Sep 29, 2009 at 09:11:25PM +0200, Heinz Diehl wrote:
> And that's it. Tha adapter is "off", and no connection is possible. It's
> strongly 2.6.32-rc2 related, no problems with any other kernel before.
Could you do a git bisect? Also, please Cc:
linux-wireless@vger.kernel.org for your response...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* SME warning on 2.6.32-rc<bleh>
From: Luis R. Rodriguez @ 2009-09-29 19:24 UTC (permalink / raw)
To: linux-wireless
I believe the problem comes from the assumption from cfg80211 that
previous deauthentications would have gone through before we run
__cfg80211_disconnected() and are using wext or nl80211
connec/disconnectt. Under certain conditions (clearly not known yet)
this is not true and we'll end up asking mac80211 to deauthenticate us
from a BSS we already deauthenticated to end end up with an -ENOLINK
on our mac80211 cfg80211 deauth ops. It seems this race was expected
all along on mac80211 ieee80211_mgd_deauth():
/*
* cfg80211 should catch this ... but it's racy since
* we can receive a deauth frame, process it, hand it
* to cfg80211 while that's in a locked section already
* trying to tell us that the user wants to disconnect.
*/
if (!bssid) {
mutex_unlock(&ifmgd->mtx);
return -ENOLINK;
}
So it seems we do need to address that race but I'm not yet sure how.
Here is a warning from the latest wireless-testing. Unfortunately I
cannot reproduce in a systematic way, I've tried even different boot
configuration (mem=300M) and CPU pegged at 800 MHz thinking the race
occurs when mac80211 takes its sweet time deathenticating but that
wasn't the case.
phy0: device now idle
phy0: Removed STA <your-AP-bssid>
phy0: Destroyed STA <your-AP-bssid>
wlan0: deauthenticating from <your-AP-bssid> by local choice (reason=3)
------------[ cut here ]------------
WARNING: at net/wireless/sme.c:620
__cfg80211_disconnected+0x209/0x260 [cfg80211]()
Hardware name: 7660A14
deauth failed: -67 (editorial note: -ENOLINK)
Modules linked in: <etc>
Pid: 1829, comm: wpa_supplicant Not tainted 2.6.32-rc2-wl #45
Call Trace:
[<ffffffff8105be78>] warn_slowpath_common+0x78/0xb0
[<ffffffff8105bf0c>] warn_slowpath_fmt+0x3c/0x40
[<ffffffffa00d5489>] __cfg80211_disconnected+0x209/0x260 [cfg80211]
[<ffffffffa00d31a8>] __cfg80211_send_deauth+0x228/0x2a0 [cfg80211]
[<ffffffffa00d3261>] cfg80211_send_deauth+0x41/0x80 [cfg80211]
[<ffffffffa01c1c1f>] ieee80211_send_deauth_disassoc+0x14f/0x170 [mac80211]
[<ffffffffa01c4945>] ieee80211_mgd_deauth+0xf5/0x120 [mac80211]
[<ffffffffa01c8fa9>] ieee80211_deauth+0x19/0x20 [mac80211]
[<ffffffffa00d1bae>] __cfg80211_mlme_deauth+0xee/0x130 [cfg80211]
[<ffffffffa00d59f9>] __cfg80211_disconnect+0x159/0x1d0 [cfg80211]
[<ffffffffa00d9245>] cfg80211_mgd_wext_siwfreq+0xd5/0x1b8 [cfg80211]
[<ffffffff81516b30>] ? ioctl_standard_call+0x0/0xd0
[<ffffffffa00d772d>] cfg80211_wext_siwfreq+0x4d/0xd0 [cfg80211]
[<ffffffff81516b8b>] ioctl_standard_call+0x5b/0xd0
[<ffffffff8144e040>] ? __dev_get_by_name+0xa0/0xc0
[<ffffffff815162b5>] wext_ioctl_dispatch+0x165/0x1d0
[<ffffffff81516700>] ? ioctl_private_call+0x0/0xa0
[<ffffffff81516451>] wext_handle_ioctl+0x41/0x90
[<ffffffff8144f316>] dev_ioctl+0x676/0x820
[<ffffffff8107abf0>] ? autoremove_wake_function+0x0/0x40
[<ffffffff8143aec5>] sock_ioctl+0x95/0x280
[<ffffffff811445bd>] vfs_ioctl+0x1d/0xa0
[<ffffffff8114475a>] do_vfs_ioctl+0x8a/0x5a0
[<ffffffff815336eb>] ? thread_return+0x4e/0x733
[<ffffffff81144cf1>] sys_ioctl+0x81/0xa0
[<ffffffff81011ec2>] system_call_fastpath+0x16/0x1b
---[ end trace 7d678c5342bdca98 ]---
^ permalink raw reply
* Re: cannot compile compate-wirless snapshots
From: John W. Linville @ 2009-09-29 18:52 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Hin-Tak Leung, Malte Gell, Hauke Mehrtens, linux-wireless
In-Reply-To: <69e28c910909291127x3be75be0r3ceef7367d05f9c3@mail.gmail.com>
On Tue, Sep 29, 2009 at 08:27:20PM +0200, Gábor Stefanik wrote:
> On Tue, Sep 29, 2009 at 11:00 AM, Hin-Tak Leung <hintak.leung@gmail.com> wrote:
> > The relevant config is probably /boot/config-`uname -r`, but, please
> > do *not* modify it.
> >
>
> It should be in /proc/config.gz. (/boot/config-* is an Ubuntuism.)
No -- it is at least that way in Fedora and RHEL as well.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH 2.6.32-rc2] ar9170: fix bug in iq-auto calibration value calculation
From: Christian Lamparter @ 2009-09-29 18:47 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, Andrew Morton, Joerg Albert, David S. Miller
This patch fixes a embarrassing bug which was introduced by:
"[PATCH] ar9170: implement frequency calibration for one-stage/openfw"
The phy_data variable initialization has to done outside the for-loop
scope. This is because the for-loop uses u32 phy_data variable more
like a 4-byte field. But in each run only a single byte is calculated.
Therefore phy_data content needs to stay the same for at least 3 more
iterations, before the complete set can be uploaded.
Reported-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
BTW: I found Andrew Morton original patch right here:
http://userweb.kernel.org/~akpm/mmotm/broken-out/
drivers-net-wireless-ath-ar9170-phyc-fix-uninitialised-variable.patch
---
diff --git a/drivers/net/wireless/ath/ar9170/phy.c b/drivers/net/wireless/ath/ar9170/phy.c
index b3e5cf3..dbd488d 100644
--- a/drivers/net/wireless/ath/ar9170/phy.c
+++ b/drivers/net/wireless/ath/ar9170/phy.c
@@ -1141,7 +1141,8 @@ static int ar9170_set_freq_cal_data(struct ar9170 *ar,
u8 vpds[2][AR5416_PD_GAIN_ICEPTS];
u8 pwrs[2][AR5416_PD_GAIN_ICEPTS];
int chain, idx, i;
- u8 f;
+ u32 phy_data = 0;
+ u8 f, tmp;
switch (channel->band) {
case IEEE80211_BAND_2GHZ:
@@ -1208,9 +1209,6 @@ static int ar9170_set_freq_cal_data(struct ar9170 *ar,
}
for (i = 0; i < 76; i++) {
- u32 phy_data;
- u8 tmp;
-
if (i < 25) {
tmp = ar9170_interpolate_val(i, &pwrs[0][0],
&vpds[0][0]);
^ permalink raw reply related
* RE: [PATCH] libertas: Add auto deep sleep support for SD8385/SD8686/SD8688
From: Bing Zhao @ 2009-09-29 18:36 UTC (permalink / raw)
To: Holger Schurig
Cc: Dan Williams, libertas-dev@lists.infradead.org,
linux-wireless@vger.kernel.org, Amitkumar Karwar
In-Reply-To: <200909290904.00971.hs4233@mail.mn-solutions.de>
Hi Holger,
> From: Holger Schurig [hs4233@mail.mn-solutions.de]
> Sent: Tuesday, September 29, 2009 12:04 AM
> To: Bing Zhao
> Cc: Dan Williams; libertas-dev@lists.infradead.org; linux-wireless@vger.kernel.org; Amitkumar Karwar
> Subject: Re: [PATCH] libertas: Add auto deep sleep support for SD8385/SD8686/SD8688
>
> Hi Bing !
>
> Please note that I just sent an experimental patch to enable
> cfg80211 for libertas.
>
> Once this is polished, you can immediately start using
> nl80211/cfg80211 to configure such things, there's no need to
> have the full thingy (e.g. wpa_supplicant via -Dnl80211 working
> with WEP/WPA/WPA2) working, those things are not interrelated.
Thanks for the info.
I will start to use nl80211/cfg80211 to configure my parameters as soon as your patch is in libertas driver.
Best regards,
Bing
>
>
> --
> http://www.holgerschurig.de
^ permalink raw reply
* [htd@fancy-poultry.org: 2.6.32-rc2: wlan rt73 dead]
From: John W. Linville @ 2009-09-29 18:24 UTC (permalink / raw)
To: linux-wireless; +Cc: ivdoorn
Better to send these to linux-wireless@vger.kernel.org...
----- Forwarded message from Heinz Diehl <htd@fancy-poultry.org> -----
> Date: Tue, 29 Sep 2009 19:06:15 +0200
> From: Heinz Diehl <htd@fancy-poultry.org>
> To: linux-kernel@vger.kernel.org
> Subject: 2.6.32-rc2: wlan rt73 dead
> User-Agent: Mutt/1.5.20+20090822 (GNU/Linux 2.6.31.1 x86_64)
>
> Hi,
>
> with 2.6.32-rc2, my wlan adapter no longer works. I'm using an RT73 based USB wlan
> stick, which has worked flawlessly with any kernel before this one. The
> wlan adapter is still recognized correctly by the kernel, but its 2 status
> lights (act, link) stay dark, and the adapter does not work at all.
> The adapter identifies as
> Bus 001 Device 002: ID 07d1:3c03 D-Link System DWL-G122 802.11g Adapter [ralink rt73].
>
> The logs doesn't show any error or something strange at all, and I'm
> somewhat puzzled on what's going on here.
>
> Configs are attached.
>
> Thanks,
> Heinz.
>
>
>
----- End forwarded message -----
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: cannot compile compate-wirless snapshots
From: Gábor Stefanik @ 2009-09-29 18:27 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Malte Gell, Hauke Mehrtens, linux-wireless
In-Reply-To: <3ace41890909290200h4dbefddah131851675dc06097@mail.gmail.com>
On Tue, Sep 29, 2009 at 11:00 AM, Hin-Tak Leung <hintak.leung@gmail.com> wrote:
> On Tue, Sep 29, 2009 at 9:50 AM, Malte Gell <malte.gell@gmx.de> wrote:
>>
>> Hauke Mehrtens <hauke@hauke-m.de> wrote
>>
>>
>>> Does this file exists in your installation?
>>> /lib/modules/`uname -r`/build/include/linux/tracepoint.h ?
>>
>> Yes, but, look:
>>
>> cd /usr/src/linux
>>
>> grep -i tracepoint .config
>>
>> # CONFIG_TRACEPOINTS is not set
>>
>> Do I need to set it to yes?
>>
>> Malte
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> No. You should not manually edit any kernel config file (the
> compat-wireless module should be built against a config matching your
> running kernel, not a massaged version of it) and what is in
> /usr/src/linux is irrelevant , because that is not your running
> kernel.
>
> The relevant config is probably /boot/config-`uname -r`, but, please
> do *not* modify it.
>
It should be in /proc/config.gz. (/boot/config-* is an Ubuntuism.)
> I already wrote - your best bet is simply deleting all the 'error
> redefintion' parts from net/compat-2.6.28.h, since your kernel tree is
> somewhere between 2.6.27 and 2.6.28 . (and also delete some part of
> net/compat-2.6.28.c when possible later linker error arises).
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: 2.6.32-rc0-git: oops in wireless, iwl3945 related?
From: reinette chatre @ 2009-09-29 18:14 UTC (permalink / raw)
To: Pavel Machek
Cc: linux-kernel@vger.kernel.org, Zhu, Yi,
linux-wireless@vger.kernel.org, johannes
In-Reply-To: <20090929171249.GB14405@elf.ucw.cz>
Hi Pavel,
On Tue, 2009-09-29 at 10:12 -0700, Pavel Machek wrote:
> wlan0: Selected IBSS BSSID 02:18:41:de:3f:02 based on configured SSID
> wlan0: Trigger new scan to find an IBSS to join
> wlan0: Trigger new scan to find an IBSS to join
> wlan0: Creating new IBSS network, BSSID f2:d3:80:82:ed:6a
> wlan0: Creating new IBSS network, BSSID 52:17:bf:45:d6:9d
> skb_over_panic: text:c07b4113 len:130 put:36 head:e4c3edf0
> data:e4c3edf0 tail:0xe4c3ee72 end:0xe4c3ee70 dev:<NULL>
Looks like the ibss code is trying to use more space in skb than it
allocated. It thus does not seem specific to iwl3945. I am not familiar
with that code, but it looks that the skb allocation in
ieee80211_ibss_join does not accommodate the ibss probe response that is
inserted in __ieee80211_sta_join_ibss. I hope that Johannes can guide us
here.
> ------------[ cut here ]------------
> kernel BUG at net/core/skbuff.c:127!
> invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
> last sysfs file:
> /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:01/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/status
> Modules linked in:
>
> Pid: 1353, comm: iwl3945 Not tainted (2.6.31 #72) 17097HU
> EIP: 0060:[<c06d7189>] EFLAGS: 00010286 CPU: 0
> EIP is at skb_put+0x89/0x90
> EAX: 00000079 EBX: e4c3ee72 ECX: c0230881 EDX: 01eef000
> ESI: 00000024 EDI: f5e20fc0 EBP: f5dcde04 ESP: f5dcddd8
> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> Process iwl3945 (pid: 1353, ti=f5dcc000 task=f72e4698
> task.ti=f5dcc000)
> Stack:
> c0a28c24 c07b4113 00000082 00000024 e4c3edf0 e4c3edf0 e4c3ee72
> e4c3ee70
> <0> c09ac8b9 0000009c 66666667 f5dcde74 c07b4113 00000037 00000007
> 00000282
> <0> 00000002 00000000 00000040 00000006 00000064 f5e1bbc0 f5e1be23
> c03e82b1
> Call Trace:
> [<c07b4113>] ? __ieee80211_sta_join_ibss+0x143/0x3d0
> [<c07b4113>] ? __ieee80211_sta_join_ibss+0x143/0x3d0
> [<c03e82b1>] ? extract_entropy+0x51/0xa0
> [<c07b4677>] ? ieee80211_sta_find_ibss+0x227/0x450
> [<c07fcdc2>] ? mutex_lock_nested+0x1c2/0x230
> [<c07b48b7>] ? ieee80211_ibss_notify_scan_completed+0x17/0x80
> [<c07b4909>] ? ieee80211_ibss_notify_scan_completed+0x69/0x80
> [<c07b1b85>] ? ieee80211_scan_completed+0xc5/0x450
> [<c0239e29>] ? del_timer_sync+0x59/0x70
> [<c0239dd0>] ? del_timer_sync+0x0/0x70
> [<c052a4df>] ? iwl_bg_scan_completed+0x3f/0x80
> [<c024089d>] ? worker_thread+0x16d/0x280
> [<c024083a>] ? worker_thread+0x10a/0x280
> [<c052a4a0>] ? iwl_bg_scan_completed+0x0/0x80
> [<c02449d0>] ? autoremove_wake_function+0x0/0x50
> [<c0240730>] ? worker_thread+0x0/0x280
> [<c02446dc>] ? kthread+0x7c/0x90
> [<c0244660>] ? kthread+0x0/0x90
> [<c020385f>] ? kernel_thread_helper+0x7/0x18
> Code: 44 24 14 8b 81 a0 00 00 00 89 74 24 0c 89 44 24 10 8b 41 50 c7
> 04 24 24 8c a2 c0 89 44 24 08 8b
> 45 04 89 44 24 04 e8 a7 40 12 00 <0f> 0b eb fe 8d 76 00 55 89 e5 57 56
> 53 83 ec 18 89 45 e4 89 55
> EIP: [<c06d7189>] skb_put+0x89/0x90 SS:ESP 0068:f5dcddd8
> ---[ end trace 5d5762000564cd5a ]---
Reinette
^ permalink raw reply
* [rfkill PATCH] default install to $(PREFIX)/sbin
From: John W. Linville @ 2009-09-29 17:41 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, John W. Linville
The rfkill utility isn't generally useful to normal users, so move it to
/sbin with other system management executables.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
Makefile | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index cda48c4..71a6082 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
MAKEFLAGS += --no-print-directory
PREFIX ?= /usr
-BINDIR ?= $(PREFIX)/bin
+SBINDIR ?= $(PREFIX)/sbin
MANDIR ?= $(PREFIX)/share/man
MKDIR ?= mkdir -p
@@ -48,8 +48,8 @@ check:
install: rfkill rfkill.1.gz
@$(NQ) ' INST rfkill'
- $(Q)$(MKDIR) $(DESTDIR)$(BINDIR)
- $(Q)$(INSTALL) -m 755 -t $(DESTDIR)$(BINDIR) rfkill
+ $(Q)$(MKDIR) $(DESTDIR)$(SBINDIR)
+ $(Q)$(INSTALL) -m 755 -t $(DESTDIR)$(SBINDIR) rfkill
@$(NQ) ' INST rfkill.1'
$(Q)$(MKDIR) $(DESTDIR)$(MANDIR)/man1/
$(Q)$(INSTALL) -m 644 -t $(DESTDIR)$(MANDIR)/man1/ rfkill.1.gz
--
1.6.2.5
^ permalink raw reply related
* 2.6.32-rc0-git: oops in wireless, iwl3945 related?
From: Pavel Machek @ 2009-09-29 17:12 UTC (permalink / raw)
To: linux-kernel, yi.zhu, reinette.chatre, linux-wireless
Happened while playing with wireless.
Kernel is:
Linux version 2.6.31 (pavel@amd) (gcc version 4.3.3 (Debian 4.3.3-10)
) #72 SMP Thu Sep 10 21:56:19 CEST 2009
KERNEL supported cpus:
(Could we get kernels between release and -rc1 mark themselves
somehow?)
Pavel
...
Registered led device: iwl-phy0::radio
Registered led device: iwl-phy0::assoc
Registered led device: iwl-phy0::RX
Registered led device: iwl-phy0::TX
wlan0: Selected IBSS BSSID 02:18:41:de:3f:02 based on configured SSID
wlan0: Trigger new scan to find an IBSS to join
wlan0: Trigger new scan to find an IBSS to join
wlan0: Creating new IBSS network, BSSID f2:d3:80:82:ed:6a
wlan0: Creating new IBSS network, BSSID 52:17:bf:45:d6:9d
skb_over_panic: text:c07b4113 len:130 put:36 head:e4c3edf0
data:e4c3edf0 tail:0xe4c3ee72 end:0xe4c3ee70 dev:<NULL>
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:127!
invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
last sysfs file:
/sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:01/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/status
Modules linked in:
Pid: 1353, comm: iwl3945 Not tainted (2.6.31 #72) 17097HU
EIP: 0060:[<c06d7189>] EFLAGS: 00010286 CPU: 0
EIP is at skb_put+0x89/0x90
EAX: 00000079 EBX: e4c3ee72 ECX: c0230881 EDX: 01eef000
ESI: 00000024 EDI: f5e20fc0 EBP: f5dcde04 ESP: f5dcddd8
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process iwl3945 (pid: 1353, ti=f5dcc000 task=f72e4698
task.ti=f5dcc000)
Stack:
c0a28c24 c07b4113 00000082 00000024 e4c3edf0 e4c3edf0 e4c3ee72
e4c3ee70
<0> c09ac8b9 0000009c 66666667 f5dcde74 c07b4113 00000037 00000007
00000282
<0> 00000002 00000000 00000040 00000006 00000064 f5e1bbc0 f5e1be23
c03e82b1
Call Trace:
[<c07b4113>] ? __ieee80211_sta_join_ibss+0x143/0x3d0
[<c07b4113>] ? __ieee80211_sta_join_ibss+0x143/0x3d0
[<c03e82b1>] ? extract_entropy+0x51/0xa0
[<c07b4677>] ? ieee80211_sta_find_ibss+0x227/0x450
[<c07fcdc2>] ? mutex_lock_nested+0x1c2/0x230
[<c07b48b7>] ? ieee80211_ibss_notify_scan_completed+0x17/0x80
[<c07b4909>] ? ieee80211_ibss_notify_scan_completed+0x69/0x80
[<c07b1b85>] ? ieee80211_scan_completed+0xc5/0x450
[<c0239e29>] ? del_timer_sync+0x59/0x70
[<c0239dd0>] ? del_timer_sync+0x0/0x70
[<c052a4df>] ? iwl_bg_scan_completed+0x3f/0x80
[<c024089d>] ? worker_thread+0x16d/0x280
[<c024083a>] ? worker_thread+0x10a/0x280
[<c052a4a0>] ? iwl_bg_scan_completed+0x0/0x80
[<c02449d0>] ? autoremove_wake_function+0x0/0x50
[<c0240730>] ? worker_thread+0x0/0x280
[<c02446dc>] ? kthread+0x7c/0x90
[<c0244660>] ? kthread+0x0/0x90
[<c020385f>] ? kernel_thread_helper+0x7/0x18
Code: 44 24 14 8b 81 a0 00 00 00 89 74 24 0c 89 44 24 10 8b 41 50 c7
04 24 24 8c a2 c0 89 44 24 08 8b
45 04 89 44 24 04 e8 a7 40 12 00 <0f> 0b eb fe 8d 76 00 55 89 e5 57 56
53 83 ec 18 89 45 e4 89 55
EIP: [<c06d7189>] skb_put+0x89/0x90 SS:ESP 0068:f5dcddd8
---[ end trace 5d5762000564cd5a ]---
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* RE: [rt2x00-users] [PATCH] rt2x00: Thrustmaster FunAccess WIFI USB and rt73usb
From: Genar Codina @ 2009-09-29 15:21 UTC (permalink / raw)
To: rt2x00 Users List, John Linville, linux-wireless@vger.kernel.org,
szalat
In-Reply-To: <200909291537.54334.IvDoorn@gmail.com>
Hello,
I have also tested the rt73usb which is included in the new 2.6.31 kernel (modinfo rt73usb gives the version "2.3.0"), in mode Master, using hostapd (version 0.6.9) and it works OK.
Regards,
-----Mensaje original-----
De: users-bounces@rt2x00.serialmonkey.com [mailto:users-bounces@rt2x00.serialmonkey.com] En nombre de Ivo van Doorn
Enviado el: martes, 29 de septiembre de 2009 15:38
Para: John Linville; linux-wireless@vger.kernel.org; szalat; users@rt2x00.serialmonkey.com
Asunto: [rt2x00-users] [PATCH] rt2x00: Thrustmaster FunAccess WIFI USB and rt73usb
From: Michal Szalata <szalat@gmail.com>
Thrustmaster FunAccess WIFI USB works with rt73usb with little
modification of rt73usb.c.
Tested with version 2.3.0 of driver.
Signed-off-by: Michal Szalata <szalat@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
index 1cbd9b4..b8f5ee3 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -2381,6 +2381,7 @@ static struct usb_device_id rt73usb_device_table[] = {
/* Huawei-3Com */
{ USB_DEVICE(0x1472, 0x0009), USB_DEVICE_DATA(&rt73usb_ops) },
/* Hercules */
+ { USB_DEVICE(0x06f8, 0xe002), USB_DEVICE_DATA(&rt73usb_ops) },
{ USB_DEVICE(0x06f8, 0xe010), USB_DEVICE_DATA(&rt73usb_ops) },
{ USB_DEVICE(0x06f8, 0xe020), USB_DEVICE_DATA(&rt73usb_ops) },
/* Linksys */
_______________________________________________
users mailing list
users@rt2x00.serialmonkey.com
http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
^ permalink raw reply related
* Re: scan_request->nr_ssids never 0 ?
From: Johannes Berg @ 2009-09-29 14:04 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless
In-Reply-To: <200909291518.46655.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 536 bytes --]
On Tue, 2009-09-29 at 15:18 +0200, Holger Schurig wrote:
> Even when I do an "iw xxx scan trigger", scan_request->nr_ssids
> is always 1 in my driver.
>
> Is this a bug or a feature?
# iw wlan0 scan trigger passive
> However, scan_request->ssids[0].ssid_len is 0.
>
> So to ask my firmware for an SSID scan, I need to do
>
> if (req->n_ssids && req->ssid[0].ssid_len)
>
> instead of simply
>
> if (req->n_ssids)
No. You need to ask it to probe for the wildcard SSID, which is 0 bytes
long.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] rt2x00: Thrustmaster FunAccess WIFI USB and rt73usb
From: Ivo van Doorn @ 2009-09-29 13:37 UTC (permalink / raw)
To: John Linville, linux-wireless@vger.kernel.org, szalat, users
From: Michal Szalata <szalat@gmail.com>
Thrustmaster FunAccess WIFI USB works with rt73usb with little
modification of rt73usb.c.
Tested with version 2.3.0 of driver.
Signed-off-by: Michal Szalata <szalat@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
index 1cbd9b4..b8f5ee3 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -2381,6 +2381,7 @@ static struct usb_device_id rt73usb_device_table[] = {
/* Huawei-3Com */
{ USB_DEVICE(0x1472, 0x0009), USB_DEVICE_DATA(&rt73usb_ops) },
/* Hercules */
+ { USB_DEVICE(0x06f8, 0xe002), USB_DEVICE_DATA(&rt73usb_ops) },
{ USB_DEVICE(0x06f8, 0xe010), USB_DEVICE_DATA(&rt73usb_ops) },
{ USB_DEVICE(0x06f8, 0xe020), USB_DEVICE_DATA(&rt73usb_ops) },
/* Linksys */
^ permalink raw reply related
* scan_request->nr_ssids never 0 ?
From: Holger Schurig @ 2009-09-29 13:18 UTC (permalink / raw)
To: linux-wireless
Even when I do an "iw xxx scan trigger", scan_request->nr_ssids
is always 1 in my driver.
Is this a bug or a feature?
However, scan_request->ssids[0].ssid_len is 0.
So to ask my firmware for an SSID scan, I need to do
if (req->n_ssids && req->ssid[0].ssid_len)
instead of simply
if (req->n_ssids)
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: compat-wireless tracepoint error Re: [Ndiswrapper-general] Need help to create driver for Netgear WN111v2
From: Malte Gell @ 2009-09-29 11:07 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: linux-wireless
In-Reply-To: <3ace41890909290328l14620ed6o4939488e268d76a3@mail.gmail.com>
"Hin-Tak Leung" <hintak.leung@gmail.com> wrote
> CONFIG_COMPAT_WIRELESS_28
>
Jep, changed to 27, but, did not compile......:
/home/malte_gell/download/src/wifi/compat-
wireless-2009-09-29/drivers/net/wireless/ath/ar9170/usb.c: In function
‘ar9170_usb_cancel_urbs’:
/home/malte_gell/download/src/wifi/compat-
wireless-2009-09-29/drivers/net/wireless/ath/ar9170/usb.c:380: error: implicit
declaration of function ‘usb_poison_anchored_urbs’
make[5]: *** [/home/malte_gell/download/src/wifi/compat-
wireless-2009-09-29/drivers/net/wireless/ath/ar9170/usb.o] Fehler 1
make[4]: *** [/home/malte_gell/download/src/wifi/compat-
wireless-2009-09-29/drivers/net/wireless/ath/ar9170] Fehler 2
make[3]: *** [/home/malte_gell/download/src/wifi/compat-
wireless-2009-09-29/drivers/net/wireless/ath] Fehler 2
make[2]: *** [/home/malte_gell/download/src/wifi/compat-
wireless-2009-09-29/drivers/net/wireless] Fehler 2
make[1]: *** [_module_/home/malte_gell/download/src/wifi/compat-
wireless-2009-09-29] Fehler 2
make[1]: Leaving directory `/usr/src/linux-2.6.27.29-0.1'
make: *** [modules] Fehler 2
^ permalink raw reply
* Re: Firmware versioning best practices
From: Holger Schurig @ 2009-09-29 11:01 UTC (permalink / raw)
To: Tomas Winkler; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <1ba2fa240909290345k776826a6jc692d9d8dfe7577@mail.gmail.com>
> > Don't put the version into the filename. This is not a common
> > practice for Linux / BSD / whatever systems. Usually you have
> > a "kmail" file, not a kmail3.5, kmail4.0 and kmail4.2 file.
>
> I think in this context libyyy.so.x.y.z is better analogy.
> firmware is not an executable What is the reasoning behind this
> common practice?
There's no version of the library in the file-name, but the
version of the API. So if the API changes, and might break users
of the API, you increase the filename.
But you won't have a libc-2.3.6.so file. Instead you have a
package "libc6_2.3.6.ds1-13etch9_i386.deb" which contains the
file libc.so.6.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: Firmware versioning best practices
From: Tomas Winkler @ 2009-09-29 10:45 UTC (permalink / raw)
To: Holger Schurig
Cc: Luis R. Rodriguez, linux-wireless, reinette chatre, Kalle Valo,
Johannes Berg, Christian Lamparter, Bob Copeland
In-Reply-To: <200909290859.25075.hs4233@mail.mn-solutions.de>
On Tue, Sep 29, 2009 at 8:59 AM, Holger Schurig
<hs4233@mail.mn-solutions.de> wrote:
>> Or shall we have the same firmware filename and simply query
>> the firmware for a map of capabilities? Any other ideas?
>
> Don't put the version into the filename. This is not a common
> practice for Linux / BSD / whatever systems. Usually you have
> a "kmail" file, not a kmail3.5, kmail4.0 and kmail4.2 file.
I think in this context libyyy.so.x.y.z is better analogy. firmware is
not an executable
What is the reasoning behind this common practice?
> Versions or capability maps can be stored inside the firmware and
> queried at load time. E.g. the libertas driver does it that way.
It's only check if it fits but cannot fall back to an older version.
.
>
> If you make your firmware redistributable (which I recommend),
> the version will also be stored in the package metadata, e.g.
> the rpm or deb file and the infrastructure for rpm/yum deb/apt.
>
> --
> http://www.holgerschurig.de
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Thanks
Tomas
^ permalink raw reply
* Re: compat-wireless tracepoint error Re: [Ndiswrapper-general] Need help to create driver for Netgear WN111v2
From: Hin-Tak Leung @ 2009-09-29 10:28 UTC (permalink / raw)
To: Malte Gell; +Cc: linux-wireless
In-Reply-To: <200909291145.35972.malte.gell@gmx.de>
On Tue, Sep 29, 2009 at 10:45 AM, Malte Gell <malte.gell@gmx.de> wrote:
>
> "Hin-Tak Leung" <hintak.leung@gmail.com> wrote
>
>> > So, no need to modify compat-2.6.28.c? Does it automatically happen?
>>
>> You may or may not see any errors at the linker stage (the LD part in
>> stage 2). If you get to that point without further error, then, well,
>> count yourself lucky and just give "make install ; make unload;
>> modprobe -v ar9170" a go.
>
> Ho ho ;-) I got a lot of warnings like this:
>
> include/linux/tracepoint.h:86:1: warning: this is the location of the
> previous definition
>
> But, it DID compile! Thanx a lot.
>
> To be sure I did a find . -name "*.ko" and got these modules:
>
> ./drivers/net/wireless/ath/ath.ko
> ./net/rfkill/rfkill_backport.ko
> ./net/wireless/cfg80211.ko
> ./net/mac80211/mac80211.ko
>
> I just wonder, where is ar9170usb !? I did ./scripts/driver-select ar9170
>
> Malte
>
Argh... try changing this line in config.mk
ifndef CONFIG_COMPAT_WIRELESS_28
to ...27.
apparently it is disabled below 2.6.28. but then, yours is somewhere between.
------------
commit 13e9384e59b2cadaef7468f1417b9a1327419c89
Author: Luis R. Rodriguez <lrodriguez@atheros.com>
Date: Tue Jul 21 14:43:15 2009 -0700
ar9170 works needs more compat work for 2.6.27
We leave it only enabled for >= 2.6.28,
usb_hcd_unlink_urb() is used within usb_poison_urb()
and although it is available on 2.6.27 its not exported
and cannot be re-implemented. If we figure out a way
to drop the urb from the hardware queue as usb_hcd_unlink_urb()
does then we can backport this.
Also I think we need to backport usb_kill_urb_queue().
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
------------
^ permalink raw reply
* Re: compat-wireless tracepoint error Re: [Ndiswrapper-general] Need help to create driver for Netgear WN111v2
From: Malte Gell @ 2009-09-29 9:45 UTC (permalink / raw)
To: Hin-Tak Leung, ndiswrapper-general; +Cc: linux-wireless
In-Reply-To: <3ace41890909290206g3019a9cbv29048837804f830@mail.gmail.com>
"Hin-Tak Leung" <hintak.leung@gmail.com> wrote
> > So, no need to modify compat-2.6.28.c? Does it automatically happen?
>
> You may or may not see any errors at the linker stage (the LD part in
> stage 2). If you get to that point without further error, then, well,
> count yourself lucky and just give "make install ; make unload;
> modprobe -v ar9170" a go.
Ho ho ;-) I got a lot of warnings like this:
include/linux/tracepoint.h:86:1: warning: this is the location of the
previous definition
But, it DID compile! Thanx a lot.
To be sure I did a find . -name "*.ko" and got these modules:
./drivers/net/wireless/ath/ath.ko
./net/rfkill/rfkill_backport.ko
./net/wireless/cfg80211.ko
./net/mac80211/mac80211.ko
I just wonder, where is ar9170usb !? I did ./scripts/driver-select ar9170
Malte
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox