* Re: udevd / ext4 issue mounting 2.6.35-rc5
From: Luis R. Rodriguez @ 2010-07-23 17:56 UTC (permalink / raw)
To: Daniel J Blueman, Luis R. Rodriguez
Cc: linux-ext4, Rafael J. Wysocki, Ubuntu Kernel Team, linux-kernel,
linux-wireless
In-Reply-To: <AANLkTikwQg6ZC-5tAzBExnNSx5J7Zgyc14sPXE7KqLW5@mail.gmail.com>
On Fri, Jul 23, 2010 at 9:49 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Thu, Jul 22, 2010 at 2:10 AM, Daniel J Blueman
> <daniel.blueman@gmail.com> wrote:
>> On 22 July 2010 02:06, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>>> On Wed, Jul 21, 2010 at 1:43 AM, Daniel J Blueman
>>> <daniel.blueman@gmail.com> wrote:
>>>> Hi Luis,
>>>>
>>>> On 21 July 2010 01:36, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>>>>> I have been reluctant to boot to 2.6.35-rc due to the large set of
>>>>> regression list and the amount of work I needed to actually get done
>>>>> on 2.6.35. Last I checked the regression list it was getting small so
>>>>> I gave it a spin today. No luck. I get some bootup error from udevd
>>>>> and ext2/ext3/ext4, something like this:
>>>>>
>>>>> EXT3-fs (sda1): error: couldn't mount because of unsupported optional
>>>>> features (240)
>>>>> EXT2-fs (sda1): error: couldn't mount because of unsupported optional
>>>>> features (240)
>>>>> EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
>>>>
>>>> This succeeded.
>>>
>>> Heh, OK :)
>>>
>>>>> VFS: Mounted root (ext4 filesystem) readonly on device 8:1
>>>>> Freeing unused kernel memory: 708k freed
>>>>> Write protecting the kernel read-only data: 102040k
>>>>> Freeing unused kernel memory: 764k freed
>>>>> Freeing unused kernel memory: 1796k freed
>>>>> udevd: failed to create queue file: No such file or directory
>>>>> udevd: error creating queue file
>>>>
>>>> It looks like you need to enable:
>>>>
>>>> CONFIG_DEVTMPFS
>>>> CONFIG_DEVTMPFS_MOUNT
>>>
>>> Thanks, it also turned out that when I upgraded from Ubuntu 9.10 to
>>> Ubuntu 10.04 it replaced my own /sbin/installkernel so this was likely
>>> another issue. My /sbin/installkernel changes allow for easy initramfs
>>> installation on Debian/Ubuntu but my patches have been ignored my the
>>> maintainer.
>>>
>>> --- installkernel-ubuntu-10.04 2010-07-21 18:03:34.607678010 -0700
>>> +++ installkernel 2010-01-29 13:17:10.000000000 -0800
>>> @@ -36,7 +36,8 @@
>>> # Create backups of older versions before installing
>>> updatever () {
>>> if [ -f "$dir/$1-$ver" ] ; then
>>> - mv "$dir/$1-$ver" "$dir/$1-$ver.old"
>>> + #mv "$dir/$1-$ver" "$dir/$1-$ver.old"
>>> + rm -f "$dir/$1-$ver" "$dir/$1-$ver.old"
>>> fi
>>>
>>> cat "$2" > "$dir/$1-$ver"
>>> @@ -75,5 +76,16 @@
>>> if [ -f "$config" ] ; then
>>> updatever config "$config"
>>> fi
>>> +
>>> +LSB_RED_ID=$(/usr/bin/lsb_release -i -s)
>>> +
>>> +case $LSB_RED_ID in
>>> +"Ubuntu")
>>> + update-initramfs -c -k $ver
>>> + update-grub
>>> + ;;
>>> +*)
>>> + ;;
>>> +esac
>>>
>>> exit 0
>>>
>>> But anyway I also now get another boot failure with:
>>>
>>> mount: mounting /dev on /root/dev failed: No such file or directory
>>> mount: mounting /sys on /root/sys failed: No such file or directory
>>
>> Hmm...the scripts in the initrd are not doing what is expected -
>> perhaps if you didn't use:
>> linux$ fakeroot make-kpkg --append-to-version -luis1 --initrd kernel-image
>
> I am not using that to build my kernels I just build my kernels with
>
> make
> sudo make modules_install install
>
>> ...or if there are eg initrd script modifications on the filesystem
>> when it cooked the initd.
>
> I haven't modified any initrd scripts.
>
>> You could just try eg:
>> http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-image-2.6.35-9-generic_2.6.35-9.14_amd64.deb
Fun, so that kernel actually works but the one I am building from
wireless-testing.git does not. The curious thing is it doesn't boot
even if I remove my 802.11 module... so something is fishy. This is
likely a config issue. After booting with the above kernel though I
generated a new one with
make localmodconfig
and then enabled my 802.11 modules. Still, no luck.. Going to reset my
tree, I had manually merged Linus' latest stuff in but I don't think
this should matter.
Luis
^ permalink raw reply
* Re: [PATCH 6/6] pcmcia: remove cs_types.h
From: David Miller @ 2010-07-23 18:48 UTC (permalink / raw)
To: linux
Cc: linux-pcmcia, netdev, linux-wireless, linux-ide, linux-usb,
laforge, linux-mtd, linux-bluetooth, alsa-devel, linux-serial
In-Reply-To: <1279874305-21191-6-git-send-email-linux@dominikbrodowski.net>
From: Dominik Brodowski <linux@dominikbrodowski.net>
Date: Fri, 23 Jul 2010 10:38:25 +0200
> Remove cs_types.h which is no longer needed: Most definitions aren't
> used at all, a few can be made away with, and two remaining definitions
> (typedefs, unfortunatley) may be moved to more specific places.
>
> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: Atheros 0cf3:b003
From: Luis R. Rodriguez @ 2010-07-23 19:03 UTC (permalink / raw)
To: Maximi89; +Cc: Stephen Chen, Sujith, linux-wireless
In-Reply-To: <AANLkTimfc3NY46aYqPM5Ys2i9vpm2_qr5-kgsvc3sdkx@mail.gmail.com>
2010/7/23 Maximi89 <maximi89@gmail.com>:
> Hola Luis, conoces ese ID?, Atheros 0cf3:b003
> Es efectivamente un AR9271?
No, cual tarjeta es esa? Las que tenemos son estos:
static struct usb_device_id ath9k_hif_usb_ids[] = {
{ USB_DEVICE(0x0cf3, 0x9271) }, /* Atheros */
{ USB_DEVICE(0x0cf3, 0x1006) }, /* Atheros */
{ USB_DEVICE(0x0cf3, 0x7010) }, /* Atheros */
{ USB_DEVICE(0x0cf3, 0x7015) }, /* Atheros */
{ USB_DEVICE(0x0846, 0x9030) }, /* Netgear N150 */
{ USB_DEVICE(0x0846, 0x9018) }, /* Netgear WNDA3200 */
{ USB_DEVICE(0x07D1, 0x3A10) }, /* Dlink Wireless 150 */
{ USB_DEVICE(0x13D3, 0x3327) }, /* Azurewave */
{ USB_DEVICE(0x13D3, 0x3328) }, /* Azurewave */
{ USB_DEVICE(0x04CA, 0x4605) }, /* Liteon */
{ USB_DEVICE(0x083A, 0xA704) }, /* SMC Networks */
{ },
};
Stephen, have you heard of 0cf3:b003 as an ar9271 or HB94 card?
Luis
^ permalink raw reply
* Compat-wireless release for 2010-07-23 is baked
From: Compat-wireless cronjob account @ 2010-07-23 19:03 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
8302dc6..b2124fd linux-2.6.35.y -> origin/linux-2.6.35.y
* [new tag] compat-wireless-v2.6.35-rc6 -> compat-wireless-v2.6.35-rc6
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
afdbfed..f435fa7 history -> origin/history
+ dd5c869...80e9579 master -> origin/master (forced update)
cd5b8f8..b37fa16 stable -> origin/stable
* [new tag] next-20100723 -> next-20100723
* [new tag] v2.6.35-rc6 -> v2.6.35-rc6
compat-wireless code metrics
493730 - Total upstream lines of code being pulled
1447 - backport code changes
1211 - backport code additions
236 - backport code deletions
5764 - backport from compat module
7211 - total backport code
1.4605 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet posted
39 - Crap deletions not yet posted
0.2467 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100723
compat-wireless release: compat-wireless-2010-07-13-4-g04898a5
^ permalink raw reply
* Re: [patch -next] ath5k: snprintf() returns largish values
From: Linus Torvalds @ 2010-07-23 19:21 UTC (permalink / raw)
To: Joe Perches
Cc: Dan Carpenter, Bruno Randolf, Luis R. Rodriguez, Nick Kossifidis,
Jiri Slaby, Bob Copeland, John W. Linville, linux-wireless,
ath5k-devel, kernel-janitors, LKML
In-Reply-To: <1279907297.24768.1678.camel@Joe-Laptop.home>
On Fri, Jul 23, 2010 at 10:48 AM, Joe Perches <joe@perches.com> wrote:
>
> There are also many repeated uses of snprintf in kernel sources
> that could similarly be a problem.
>
> bar += snprintf(foo + bar, ...)
> bar += snprintf(foo + bar, ...)
> or
> foo += snprintf(foo, ...)
> foo += snprintf(foo, ...)
As long as the number of bytes is updated correctly, this won't be a
security problem, although it can cause a (single) warning. The kernel
vsnprintf does
if (WARN_ON_ONCE((int) size < 0))
return 0;
so if somebody overflows a buffer with multiple snprintf calls, it
will all be ok as long as the buffer size thing is updated the natural
way (possibly using pointer arithmetic, eg "end - bar").
Linus
^ permalink raw reply
* regulatory hiccup
From: Andrew Lutomirski @ 2010-07-23 19:30 UTC (permalink / raw)
To: linux-wireless
This is 2.6.35-rc4, but this bug (?) might exist in other versions ,too.
Early in boot, all was well:
[ 5524.214376] cfg80211: Calling CRDA to update world regulatory domain
[ 5524.219025] cfg80211: Calling CRDA for country: US
[ 5524.238440] cfg80211: Regulatory domain changed to country: US
[ 5524.238443] (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 5524.238446] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[ 5524.238448] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
[ 5524.238451] (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 5524.238454] (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 5524.238456] (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 5524.238459] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
Then, after fiddling with an AP for a bit, I got:
[11747.264221] cfg80211: Calling CRDA for country: US
[11747.282664] cfg80211: Current regulatory domain updated by AP to: US
[11747.282672] (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[11747.282680] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1600 mBm)
[11747.282688] (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 1600 mBm)
(Note lots of missing channels after that.) iw phy phy0 info showed
all the channels above 5.33GHz disabled. I didn't see some other APs
that were there.
Later on I disconnected, CRDA got called again, and all was well.
The AP that I had just connected to when everything broke was an
EnGenuis ESR7750 (brand new), and maybe it sent something wrong, but
surely if it says US it shouldn't disable other APs on US bands that
CRDA says is OK.
^ permalink raw reply
* Re: regulatory hiccup
From: Andrew Lutomirski @ 2010-07-23 19:35 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <AANLkTimdDhHudW6_7Hwcf6UCumY_EgqGd7CLtmSgOzEz@mail.gmail.com>
On Fri, Jul 23, 2010 at 3:30 PM, Andrew Lutomirski <luto@mit.edu> wrote:
>
> Then, after fiddling with an AP for a bit, I got:
>
> [11747.264221] cfg80211: Calling CRDA for country: US
> [11747.282664] cfg80211: Current regulatory domain updated by AP to: US
> [11747.282672] (start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> [11747.282680] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1600 mBm)
> [11747.282688] (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 1600 mBm)
>
It's worse than that. I reconnected to the AP (it appeared to work
for a few seconds) and I saw:
Wiphy phy0
[...]
Band 2:
Capabilities: 0x872
HT20/HT40
Static SM Power Save
RX Greenfield
RX HT20 SGI
RX HT40 SGI
No RX STBC
Max AMSDU length: 3839 bytes
No DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 4 usec (0x05)
HT TX/RX MCS rate indexes supported: 0-23, 32
Frequencies:
* 5180 MHz [36] (15.0 dBm) (passive scanning, no IBSS)
* 5200 MHz [40] (15.0 dBm) (passive scanning, no IBSS)
* 5220 MHz [44] (15.0 dBm) (passive scanning, no IBSS)
* 5240 MHz [48] (15.0 dBm) (passive scanning, no IBSS)
* 5260 MHz [52] (15.0 dBm) (passive scanning, no IBSS, radar detection)
* 5280 MHz [56] (15.0 dBm) (passive scanning, no IBSS, radar detection)
* 5300 MHz [60] (15.0 dBm) (passive scanning, no IBSS, radar detection)
* 5320 MHz [64] (15.0 dBm) (passive scanning, no IBSS, radar detection)
* 5500 MHz [100] (disabled)
* 5520 MHz [104] (disabled)
* 5540 MHz [108] (disabled)
* 5560 MHz [112] (disabled)
* 5580 MHz [116] (disabled)
* 5600 MHz [120] (disabled)
* 5620 MHz [124] (disabled)
* 5640 MHz [128] (disabled)
* 5660 MHz [132] (disabled)
* 5680 MHz [136] (disabled)
* 5700 MHz [140] (disabled)
* 5745 MHz [149] (disabled)
* 5765 MHz [153] (disabled)
* 5785 MHz [157] (disabled)
* 5805 MHz [161] (disabled)
* 5825 MHz [165] (disabled)
Which is absurd, because:
Connected to 00:02:6f:6e:d7:6c (on wlan0)
SSID: FFTT5
freq: 5785 [!!!!!!!!!!!]
RX: 72058 bytes (310 packets)
TX: 2568 bytes (20 packets)
signal: -33 dBm
tx bitrate: 6.0 MBit/s
The connection died after a little while, presumably because the AP
was outside of its own allowed band.
^ permalink raw reply
* hex_to_bin() patch
From: David Miller @ 2010-07-23 19:52 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Just FYI I tossed it into net-next-2.6 since it was easy for me
to do so. This way you don't have to :)
Thanks.
^ permalink raw reply
* Re: regulatory hiccup
From: Andrew Lutomirski @ 2010-07-23 20:03 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <AANLkTinfMiS=+dqi=azF2exJbkrSLYT9nN0aor7gff-Q@mail.gmail.com>
On Fri, Jul 23, 2010 at 3:35 PM, Andrew Lutomirski <luto@mit.edu> wrote:
> On Fri, Jul 23, 2010 at 3:30 PM, Andrew Lutomirski <luto@mit.edu> wrote:
>>
>> Then, after fiddling with an AP for a bit, I got:
>>
>> [11747.264221] cfg80211: Calling CRDA for country: US
>> [11747.282664] cfg80211: Current regulatory domain updated by AP to: US
>> [11747.282672] (start_freq - end_freq @ bandwidth),
>> (max_antenna_gain, max_eirp)
>> [11747.282680] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1600 mBm)
>> [11747.282688] (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 1600 mBm)
>>
>
> It's worse than that. I reconnected to the AP (it appeared to work
> for a few seconds) and I saw:
>
> Wiphy phy0
> [...]
> Band 2:
> Capabilities: 0x872
> HT20/HT40
> Static SM Power Save
> RX Greenfield
> RX HT20 SGI
> RX HT40 SGI
> No RX STBC
> Max AMSDU length: 3839 bytes
> No DSSS/CCK HT40
> Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
> Minimum RX AMPDU time spacing: 4 usec (0x05)
> HT TX/RX MCS rate indexes supported: 0-23, 32
> Frequencies:
> * 5180 MHz [36] (15.0 dBm) (passive scanning, no IBSS)
> * 5200 MHz [40] (15.0 dBm) (passive scanning, no IBSS)
> * 5220 MHz [44] (15.0 dBm) (passive scanning, no IBSS)
> * 5240 MHz [48] (15.0 dBm) (passive scanning, no IBSS)
> * 5260 MHz [52] (15.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5280 MHz [56] (15.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5300 MHz [60] (15.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5320 MHz [64] (15.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5500 MHz [100] (disabled)
> * 5520 MHz [104] (disabled)
> * 5540 MHz [108] (disabled)
> * 5560 MHz [112] (disabled)
> * 5580 MHz [116] (disabled)
> * 5600 MHz [120] (disabled)
> * 5620 MHz [124] (disabled)
> * 5640 MHz [128] (disabled)
> * 5660 MHz [132] (disabled)
> * 5680 MHz [136] (disabled)
> * 5700 MHz [140] (disabled)
> * 5745 MHz [149] (disabled)
> * 5765 MHz [153] (disabled)
> * 5785 MHz [157] (disabled)
> * 5805 MHz [161] (disabled)
> * 5825 MHz [165] (disabled)
>
> Which is absurd, because:
>
> Connected to 00:02:6f:6e:d7:6c (on wlan0)
> SSID: FFTT5
> freq: 5785 [!!!!!!!!!!!]
> RX: 72058 bytes (310 packets)
> TX: 2568 bytes (20 packets)
> signal: -33 dBm
> tx bitrate: 6.0 MBit/s
>
> The connection died after a little while, presumably because the AP
> was outside of its own allowed band.
>
Here's the offending country IE:
Country Information: Country Code: US, Indoor Environment
Tag Number: 7 (Country Information)
Tag length: 6
Tag interpretation: Country Code: US, Indoor Environment
Start Channel: 36, Channels: 13, Max TX Power: 16 dBm
AFAICT net/wireless/reg.c ignores the last bit, and the other APs that
work correctly here don't send country IEs.
--Andy
^ permalink raw reply
* Re: 2.6.35-rc6: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-07-23 20:09 UTC (permalink / raw)
To: Larry Finger
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <4C49A577.3020306@lwfinger.net>
On Friday, July 23, 2010, Larry Finger wrote:
> On 07/23/2010 06:42 AM, Rafael J. Wysocki wrote:
> > This message contains a list of some regressions from 2.6.34,
> > for which there are no fixes in the mainline known to the tracking team.
> > If any of them have been fixed already, please let us know.
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16312
> > Subject : WARNING: at fs/fs-writeback.c:1127 __mark_inode_dirty
> > Submitter : Zdenek Kabelac<zdenek.kabelac@gmail.com>
> > Date : 2010-06-28 9:40 (26 days old)
> > Message-ID :<AANLkTin24fr5O4_q5Xbo9Y_NKkEmtcp6Hgmr9_4qXaFz@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127771804806465&w=2
>
> I still have this in 2.6.35-rc5.
Thanks for the update.
Rafael
^ permalink raw reply
* iwlwifi connection problems
From: Alex Romosan @ 2010-07-23 20:14 UTC (permalink / raw)
To: linux-wireless
since kernel 2.6.35-rc3 (i didn't try 1 or 2) i haven't been able to
connect to a hidden wireless access point using the iwlwifi driver. i
can connect to open ones though (the ones that broadcast their name).
2.6.34 worked without any problems. any ideas?
this is with the driver in the standard linux kernel (2.6.35-rc6 is the
latest one i tried).
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
^ permalink raw reply
* Re: iwlwifi connection problems
From: Guy, Wey-Yi @ 2010-07-23 20:38 UTC (permalink / raw)
To: Berg, Johannes, Alex Romosan; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <87tynqvtu6.fsf@sycorax.lbl.gov>
Hi Johannes,
On Fri, 2010-07-23 at 13:14 -0700, Alex Romosan wrote:
> since kernel 2.6.35-rc3 (i didn't try 1 or 2) i haven't been able to
> connect to a hidden wireless access point using the iwlwifi driver. i
> can connect to open ones though (the ones that broadcast their name).
> 2.6.34 worked without any problems. any ideas?
>
> this is with the driver in the standard linux kernel (2.6.35-rc6 is the
> latest one i tried).
Do you aware any changes?
Thanks
Wey
>
^ permalink raw reply
* pull request: wireless-next-2.6 2010-07-23
From: John W. Linville @ 2010-07-23 20:40 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
Dave,
Yet another batch intended for 2.6.36... Mostly the usual random lot
of stuff, mostly driver updates. This batch also includes a flurry
of Sparse-inspired patches from me -- it is hard to resist once the
"bug" bites! As usual, all of these have been cooking in linux-next
for at least several days.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit e955cead031177b083fbf18d04a03c06e330a439:
CAN: Add Flexcan CAN controller driver (2010-07-22 18:06:25 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Bob Copeland (2):
ath5k: move reset to mac80211 workqueue
ath5k: disable tasklets during reset
Bruno Randolf (1):
ath5k: clean up rxlink handling
Christian Lamparter (1):
mac80211: skip HT parsing if HW does not support HT
Dan Carpenter (1):
orinoco_usb: potential null dereference
David Gnedt (1):
mac80211: set carrier on for monitor interfaces on ieee80211_open
Felix Fietkau (3):
ath9k: another fix for the A-MPDU buffer leak
ath9k_hw: remove initvals for hardware which was never sold
mac80211: fix aggregation action frame handling with AP VLANs
Joe Perches (1):
drivers/net/wireless: Remove unnecessary casts of private_data
Johannes Berg (5):
cfg80211: don't get expired BSSes
mac80211: move QoS-enable to BSS info
mac80211: refuse shared key auth when WEP is unavailable
mac80211: fix IBSS lockdep complaint
mac80211: proper IBSS locking
John W. Linville (16):
libertas: convert new uses of __attribute__ ((packed)) to __packed
iwlwifi: convert new uses of __attribute__ ((packed)) to __packed
mac80211: improve error checking if WEP fails to init
wireless: only use alpha2 regulatory information from country IE
wireless: correct sparse warning in lib80211_crypt_tkip.c
wireless: correct sparse warning in wext-compat.c
wireless: correct sparse warning in generated regdb.c
wireless: mark cfg80211_is_all_idle as static
ath9k: correct sparse identified endian bug in ath_paprd_calibrate
ipw2100: mark ipw2100_pm_qos_req static
libipw: correct sparse warnings and mark some variables static
rt2x00: correct sparse warning in rt2x00debug.c
wireless: remove unnecessary reg_same_country_ie_hint
mwl8k: correct/silence sparse warnings
rtl8180: improve signal reporting for rtl8185 hardware
b43: silence most sparse warnings
Kulikov Vasiliy (1):
wireless: airo: delete netdev from list after it is freed
Larry Finger (1):
b43: silence phy_n sparse warnings
Luis R. Rodriguez (2):
ath9k_htc: make ath9k_htc_tx_aggr_oper() static
ath9k_hw: Fix AR9003 MPDU delimeter CRC check for middle subframes
Maxime Bizon (1):
cfg80211: fix race between sysfs and cfg80211
Pavel Roskin (1):
ath9k: remove unneeded calculation of minimal calibration power
Rajkumar Manoharan (1):
ath9k: fix panic while cleaning up virtaul wifis
Vivek Natarajan (1):
ath9k: Fix the LED behaviour in idle unassociated state.
Wey-Yi Guy (3):
iwlwifi: additional statistic debug counter
iwlwifi: more statistics counter for agn in debugfs
iwlwifi: "recover_from_tx_stall" function for 4965
drivers/net/wireless/airo.c | 24 +-
drivers/net/wireless/ath/ath5k/base.c | 65 +-
drivers/net/wireless/ath/ath5k/base.h | 4 +-
drivers/net/wireless/ath/ath5k/debug.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 66 -
drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 4141 ++++++----------------
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 31 +-
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 7 +-
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 4 -
drivers/net/wireless/ath/ath9k/eeprom_def.c | 7 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 18 +-
drivers/net/wireless/ath/ath9k/init.c | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 21 +-
drivers/net/wireless/ath/ath9k/xmit.c | 19 +-
drivers/net/wireless/b43/main.c | 2 +-
drivers/net/wireless/b43/phy_g.c | 2 +-
drivers/net/wireless/b43/phy_lp.c | 8 +-
drivers/net/wireless/b43/phy_n.c | 16 +-
drivers/net/wireless/b43/wa.c | 8 +-
drivers/net/wireless/ipw2x00/ipw2100.c | 2 +-
drivers/net/wireless/ipw2x00/libipw_module.c | 4 +-
drivers/net/wireless/ipw2x00/libipw_wx.c | 4 -
drivers/net/wireless/iwlwifi/iwl-4965.c | 1 +
drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c | 7 +
drivers/net/wireless/iwlwifi/iwl-commands.h | 7 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 18 +-
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 10 +-
drivers/net/wireless/libertas/cfg.c | 6 +-
drivers/net/wireless/libertas/debugfs.c | 4 +-
drivers/net/wireless/libertas/host.h | 6 +-
drivers/net/wireless/mwl8k.c | 22 +-
drivers/net/wireless/orinoco/orinoco_usb.c | 10 +-
drivers/net/wireless/rt2x00/rt2x00dump.h | 2 +-
drivers/net/wireless/rtl818x/rtl8180_dev.c | 11 +-
include/net/cfg80211.h | 4 +
include/net/mac80211.h | 11 +-
include/net/regulatory.h | 1 -
net/mac80211/cfg.c | 4 -
net/mac80211/ht.c | 2 +-
net/mac80211/ibss.c | 92 +-
net/mac80211/ieee80211_i.h | 7 +-
net/mac80211/iface.c | 6 +-
net/mac80211/mlme.c | 13 +-
net/mac80211/util.c | 7 +-
net/mac80211/wep.c | 5 +-
net/wireless/core.c | 14 +-
net/wireless/genregdb.awk | 1 +
net/wireless/lib80211_crypt_tkip.c | 2 +-
net/wireless/reg.c | 654 +----
net/wireless/scan.c | 5 +
net/wireless/sme.c | 2 +-
net/wireless/wext-compat.c | 1 +
52 files changed, 1405 insertions(+), 3987 deletions(-)
Omnibus patch available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2010-07-23.patch.bz2
--
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
* new stuff for 2.6.36 needs to be posted _now_
From: John W. Linville @ 2010-07-23 20:45 UTC (permalink / raw)
To: linux-wireless
You may have noticed that when Linus released 2.6.35-rc6, he
optimistically predicted that it will be the last -rc for 2.6.35.
So, the merge window is around the corner!
For those that need a reminder, the opening of the merge window is a
_deadline_ for new features. Once the merge window opens, only fixes
will be accepted for 2.6.36. In fact, any non-fix patches need to
already be in wireless-next-2.6 when the merge window opens if you want
them in 2.6.36. That means you need to get them posted _now_, so they
can be reviewed and I can find time to merge them before the deadline.
You have been warned...this means you!
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: pull request: wireless-next-2.6 2010-07-23
From: David Miller @ 2010-07-23 21:03 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20100723204029.GD2426@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 23 Jul 2010 16:40:29 -0400
> Yet another batch intended for 2.6.36... Mostly the usual random lot
> of stuff, mostly driver updates. This batch also includes a flurry
> of Sparse-inspired patches from me -- it is hard to resist once the
> "bug" bites! As usual, all of these have been cooking in linux-next
> for at least several days.
>
> Please let me know if there are problems!
Auto-merging drivers/net/wireless/iwlwifi/iwl-commands.h
CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-commands.h
I don't even have to look at the file to know that it's
another one of those __packed things.
I'll fix it up again, but I know you can sense how tiring
this has become for me.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2010-07-23
From: John W. Linville @ 2010-07-23 21:39 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev
In-Reply-To: <20100723.140320.116366019.davem@davemloft.net>
On Fri, Jul 23, 2010 at 02:03:20PM -0700, David Miller wrote:
> From: "John W. Linville" <linville@tuxdriver.com>
> Date: Fri, 23 Jul 2010 16:40:29 -0400
>
> > Yet another batch intended for 2.6.36... Mostly the usual random lot
> > of stuff, mostly driver updates. This batch also includes a flurry
> > of Sparse-inspired patches from me -- it is hard to resist once the
> > "bug" bites! As usual, all of these have been cooking in linux-next
> > for at least several days.
> >
> > Please let me know if there are problems!
>
> Auto-merging drivers/net/wireless/iwlwifi/iwl-commands.h
> CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-commands.h
>
> I don't even have to look at the file to know that it's
> another one of those __packed things.
>
> I'll fix it up again, but I know you can sense how tiring
> this has become for me.
I'm sorry, Dave! I should have done a for-davem branch. FWIW,
I intended to do a test merge but it must have slipped my fragile
mind. :-(
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: iwlagn and many firmware restarts with Fedora kernel
From: drago01 @ 2010-07-23 22:32 UTC (permalink / raw)
To: Guy, Wey-Yi; +Cc: Marcel Holtmann, linux-wireless@vger.kernel.org
In-Reply-To: <1279823849.32290.1.camel@wwguy-ubuntu>
On Thu, Jul 22, 2010 at 8:37 PM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
> Hi drago,
>
>
> On Wed, 2010-07-21 at 14:00 -0700, drago01 wrote:
>> On Wed, Jul 21, 2010 at 10:37 PM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
>> > Hi drago,
>> > On Wed, 2010-07-21 at 12:59 -0700, drago01 wrote:
>> >> On Tue, Jul 20, 2010 at 1:56 AM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
>> >> > Hi drago,
>> >> >
>> >> >
>> >> > Are you using 5350? here I attach a "RFC patch", could you give a try to
>> >> > see if it help?
>> >>
>> >> Not quite I am on 5300; your patch seem to only touch the 5350 code
>> >> ... should I try the same change for 5300?
>> >
>> > Yes, please
>>
>> Hi,
>>
>> As there is no such field in .34 I patched the .35 driver which seems
>> to be fine with the change ... I couldn't trigger it using the close
>> lid (no suspend) and wait a bit trick ... but I have not used it for
>> long enough to say for certain that its gone.
>>
>> But unfortunately the driver has a different issue it spams my log with tons of:
>>
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>>
> Yes, I aware of this, this is introduced by a recent patch
> commit d9763a384216336e180399b69461eae37f6c4f54
>
> I will work on a new patch to help address this.
OK, as for the other patch after a day in use I could not trigger the
problem so it does indeed fix it.
Thanks
^ permalink raw reply
* Re: [PATCH] zd1211rw: make CR_INTERRUPT cast explicit
From: Pavel Roskin @ 2010-07-23 22:55 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Daniel Drake, Ulrich Kunitz
In-Reply-To: <20100722190339.GD2616@tuxdriver.com>
On Thu, 2010-07-22 at 15:03 -0400, John W. Linville wrote:
> On Wed, Jul 21, 2010 at 12:36:58PM -0400, Pavel Roskin wrote:
> > I think __force should be used sparingly, especially outside headers. I
> > tried other ways to prevent the warning. I tried declaring int_num as
> > zd_addr_t, but sparse keeps complaining about the same comparison.
>
> Actually, it looks like it works w/o the "__force" as well.
> Any objection to a version like that?
Ideally, I would avoid any workarounds for sparse. The bug was
acknowledged by a sparse developer, so I expect it to be fixed.
http://www.spinics.net/lists/linux-sparse/msg02167.html
However, a version without __force would be more acceptable than a
version with __force.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: wl1271 firmware
From: Pazzo Da Legare @ 2010-07-23 23:19 UTC (permalink / raw)
To: Luciano Coelho
Cc: linux-wireless@vger.kernel.org, Levi, Shahar, Logan Gunthorpe
In-Reply-To: <1279816465.1630.9.camel@powerslave>
Dear Luciano,
Obviously you are right: I did a stupid error (I modified wrong
wl1271.h file, the one for and older compact-wireless...), sorry for
that.
I attached what I got. Note that I have a limited buffer for system
log so this is the last part only, I hope is enough.
http://pastebin.com/7nLJeXkb
Thank you again,
pz
2010/7/22 Luciano Coelho <luciano.coelho@nokia.com>:
> On Thu, 2010-07-22 at 17:41 +0200, ext Pazzo Da Legare wrote:
>> I enabled the DEBUG_LEVEL as you advice me but I have no additional
>> information....
>>
>> [ 186.230000] wl1271_sdio mmc0:0001:2: firmware: requesting
>> wl1271-fw.bin
>> [ 186.420000] wl1271_sdio mmc0:0001:2: firmware: requesting
>> wl1271-nvs.bin
>> [ 186.860000] wl1271: firmware booted (Rev 6.1.0.0.310)
>> [ 186.880000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> [ 187.380000] wl1271: ERROR ELP wakeup timeout!
>> [ 187.880000] wl1271: ERROR ELP wakeup timeout!
>
> There's something wrong. There should have been a lot more traces with
> the DEBUG_LEVEL I proposed. Please try again.
>
>
> --
> Cheers,
> Luca.
>
>
^ permalink raw reply
* Re: Wireless card on Debian squeeze
From: Pavel Roskin @ 2010-07-23 23:27 UTC (permalink / raw)
To: Nicholas Syrotiuk; +Cc: linux-wireless
In-Reply-To: <4C488BD9.8040809@manchester.ac.uk>
On Thu, 2010-07-22 at 19:20 +0100, Nicholas Syrotiuk wrote:
> Dear Linux Wireless users,
>
> I'm having some trouble installing the correct driver on my laptop. I'm
> slightly confused about the revision numbering of my wireless hardware;
> that is, I'm not sure if it's revision 2 or 3.
>
> My kernel is: 2.6.32-5
> Relevant output from lspci is:
> 02:03.0 Network controller [0280]: Broadcom Corporation BCM4306
> 802.11b/g Wireless LAN Controller [14e4:4320] (rev 02)
> Subsystem: Dell TrueMobile 1300 WLAN Mini-PCI Card [1028:0001]
> Flags: bus master, fast devsel, latency 32, IRQ 5
> Memory at fafee000 (32-bit, non-prefetchable) [size=8K]
> Kernel driver in use: b43-pci-bridge
> -----------------------------------------------
>
> It looks like I need the b43legacy driver, which comes in a separate
> Debian package called "firmware-b43legacy-installer." When I install
> this package, computer says: "Not supported card. Use b43 firmware."
>
> When I install b43 firmware, configure the interface and bring it up,
> computer says: "Firmware file b43legacy/ucode4.fw not found or load failed."
I believe the drivers should be trusted since there they access the
actual hardware. The above message is from b43legacy. It must have
found the card, so the card needs b43legacy.
That means that firmware-b43legacy-installer is wrong. I don't have
Debian handy, but I checked its source, and it should work for your
card.
That's the page:
http://packages.debian.org/sid/firmware-b43legacy-installer
And that's the source:
http://ftp.de.debian.org/debian/pool/contrib/b/b43-fwcutter/b43-fwcutter_013-2.debian.tar.gz
I ran your "lspci -n" output through the
firmware-b43legacy-installer.postinst script and it doesn't complain.
> So, I am slightly confounded. However, it has occurred to me that I may
> be getting the packages from the wrong source, which are currently:
>
> deb http://debian.man.ac.uk/debian squeeze main
> deb http://ftp.us.debian.org/debian squeeze main contrib
Make sure your apt-get knows about the latest packages, that is run
"apt-get update". Then try installing firmware-b43legacy-installer.
If it doesn't work, download the package from the above page and install
it with dpkg. Alternatively, you could generate the firmware manually,
as described at http://linuxwireless.org/en/users/Drivers/b43
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: ath9k - D-link DWA-552
From: Pavel Roskin @ 2010-07-24 2:02 UTC (permalink / raw)
To: Andy Pyles; +Cc: linux-wireless
In-Reply-To: <AANLkTil3u8uFbH7WyPuvqu0wee4KsojqPUsAH2kupZhJ@mail.gmail.com>
On Wed, 2010-07-21 at 14:58 -0400, Andy Pyles wrote:
> I have recently purchased two of these cards. ( the markings on the
> outside indicate they have are same hardware revision). I am noticing
> some strange behavior on one of them:
...
> $lspci -n output:
> 05:05.0 0200: 168c:ff1d (rev 01)
This looks like some experimental version that was not meant to be sold.
> Has anyone else seen this behavior with Card Two? I tried swapping to
> a different PCI slot, even to a different PC.
> Same symptom. I also tried modifying pci.c in ath9k driver to no effect.
If you add the PCI ID to the driver, something should change. The
driver would try to initialize the card. If it fails, you should get
some message in the kernel log, which can be seen by running dmesg.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: new stuff for 2.6.36 needs to be posted _now_
From: Marcel Holtmann @ 2010-07-24 2:23 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20100723204529.GE2426@tuxdriver.com>
Hi John,
> You may have noticed that when Linus released 2.6.35-rc6, he
> optimistically predicted that it will be the last -rc for 2.6.35.
> So, the merge window is around the corner!
>
> For those that need a reminder, the opening of the merge window is a
> _deadline_ for new features. Once the merge window opens, only fixes
> will be accepted for 2.6.36. In fact, any non-fix patches need to
> already be in wireless-next-2.6 when the merge window opens if you want
> them in 2.6.36. That means you need to get them posted _now_, so they
> can be reviewed and I can find time to merge them before the deadline.
you did see my pull request for bluetooth-next-2.6 tree? I have two
additional patches that should go in, but I wait until you pulled that
one first.
Regards
Marcel
^ permalink raw reply
* Re: ath9k - D-link DWA-552
From: Andy Pyles @ 2010-07-24 2:30 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless
In-Reply-To: <1279936945.27462.2.camel@mj>
Hi Pavel,
Incidentally this is the output after adding that id to pci.c:
[ 1211.423855] Backport based on linux-next.git next-20100720
[ 1211.437076] cfg80211: World regulatory domain updated:
[ 1211.437080] (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 1211.437084] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 1211.437087] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 1211.437089] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 1211.437092] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 1211.437095] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 1211.447705] ath9k 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 1211.447794] ath9k 0000:05:02.0: Failed to initialize device
[ 1211.447830] ath9k 0000:05:02.0: PCI INT A disabled
[ 1211.447859] ath9k: probe of 0000:05:02.0 failed with error -95
On Fri, Jul 23, 2010 at 10:02 PM, Pavel Roskin <proski@gnu.org> wrote:
> On Wed, 2010-07-21 at 14:58 -0400, Andy Pyles wrote:
>> I have recently purchased two of these cards. ( the markings on the
>> outside indicate they have are same hardware revision). I am noticing
>> some strange behavior on one of them:
> ...
>> $lspci -n output:
>> 05:05.0 0200: 168c:ff1d (rev 01)
>
> This looks like some experimental version that was not meant to be sold.
>
>> Has anyone else seen this behavior with Card Two? I tried swapping to
>> a different PCI slot, even to a different PC.
>> Same symptom. I also tried modifying pci.c in ath9k driver to no effect.
>
> If you add the PCI ID to the driver, something should change. The
> driver would try to initialize the card. If it fails, you should get
> some message in the kernel log, which can be seen by running dmesg.
>
> --
> Regards,
> Pavel Roskin
>
^ permalink raw reply
* RE: iwlagn and many firmware restarts with Fedora kernel
From: Guy, Wey-Yi W @ 2010-07-24 4:34 UTC (permalink / raw)
To: drago01; +Cc: Marcel Holtmann, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTi=qKLVEKKKopWdnxS41ny5S6zV6RSCptSE+a8Sf@mail.gmail.com>
Hi drago,
-----Original Message-----
From: drago01 [mailto:drago01@gmail.com]
Sent: Friday, July 23, 2010 3:32 PM
To: Guy, Wey-Yi W
Cc: Marcel Holtmann; linux-wireless@vger.kernel.org
Subject: Re: iwlagn and many firmware restarts with Fedora kernel
On Thu, Jul 22, 2010 at 8:37 PM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
> Hi drago,
>
>
> On Wed, 2010-07-21 at 14:00 -0700, drago01 wrote:
>> On Wed, Jul 21, 2010 at 10:37 PM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
>> > Hi drago,
>> > On Wed, 2010-07-21 at 12:59 -0700, drago01 wrote:
>> >> On Tue, Jul 20, 2010 at 1:56 AM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
>> >> > Hi drago,
>> >> >
>> >> >
>> >> > Are you using 5350? here I attach a "RFC patch", could you give a try to
>> >> > see if it help?
>> >>
>> >> Not quite I am on 5300; your patch seem to only touch the 5350 code
>> >> ... should I try the same change for 5300?
>> >
>> > Yes, please
>>
>> Hi,
>>
>> As there is no such field in .34 I patched the .35 driver which seems
>> to be fine with the change ... I couldn't trigger it using the close
>> lid (no suspend) and wait a bit trick ... but I have not used it for
>> long enough to say for certain that its gone.
>>
>> But unfortunately the driver has a different issue it spams my log with tons of:
>>
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>>
> Yes, I aware of this, this is introduced by a recent patch
> commit d9763a384216336e180399b69461eae37f6c4f54
>
> I will work on a new patch to help address this.
OK, as for the other patch after a day in use I could not trigger the
problem so it does indeed fix it.
Great, thank you very much for testing it. I will prepare the patch for upstream.
Btw, I also have patch to help the other problem you encounter.
Wey
^ permalink raw reply
* Re: [PATCH] mac80211: simplify key locking
From: Jouni Malinen @ 2010-07-24 5:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1275380359.3621.17.camel@jlt3.sipsolutions.net>
On Tue, Jun 01, 2010 at 10:19:19AM +0200, Johannes Berg wrote:
> net/mac80211/key.c
commit ad0e2b5a00dbec303e4682b403bb6703d11dcdb2
> void ieee80211_key_free(struct ieee80211_key *key)
> - if (!key->sdata) {
> - /* The key has not been linked yet, simply free it
> - * and don't Oops */
It looks like this function can still be called with key->sdata == NULL
in some cases and that does indeed result in an oops below:
> + local = key->sdata->local;
I've seen this issue pop up in FT testing and based on a quick code
review, at least ieee80211_add_key() calls ieee80211_key_free() in an
error case (sta not found) without having first called
ieee80211_key_link(). Which one is wrong - the caller or the freeing
function? Should we just restore the previous key->sdata == NULL handler
here?
I'd guess that the sta-not-found part is caused by FT trying to
configure PTK before association in the FT protocol roaming case
(wpa_supplicant tries to do this as soon as it knows the key because
that works with some drivers and is needed to avoid race condition with
encrypted frames; as a workaround, it will do this again after
association if the previous attempt failed).
--
Jouni Malinen PGP id EFC895FA
^ 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