* Re: no eth0 on using libertas_tf + F11 on OLPC XO-1
From: Assim Deodia @ 2010-06-12 4:27 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: linux-wireless
In-Reply-To: <AANLkTimuFeal0x-j3wZ3MpP0lnLZfX8lO1R45nF74DCx@mail.gmail.com>
In my system eth0 is the wireless interface. There is no wlan0. and
after loading libertas_tf there is neither wlan0 nor eth0 interface.
I also tried renaming the eth0 to wlan0 in
/etc/udev/rules.d/70-persistent-net.rules and renaming
/etc/sysconfig/network-scripts/*-eth* to *-wlan*. Now i have wlan
interface which also disappears on loading libertas_tf.
2010/6/12 Gábor Stefanik <netrolller.3d@gmail.com>:
> On Fri, Jun 11, 2010 at 10:08 PM, Assim Deodia <assim.deodia@gmail.com> wrote:
>> Hi All,
>>
>> I am having some issues loading libertas_tf on XO-1 with kernel 2.6.31.
>>
>> 1) after unloading libertas and usb8xxx modules when i modprobe
>> libertas_tf module eth0 (wireless interface) disappears. and instead
>> wmaster0 appears. but iwconfig show wmaster0 does not have wireless
>> extensions. lsmod shows libertas_tf and libertas_tf_usb module loaded.
>> No error in system logs. no error by modprobe. but no wireless
>> interface. Do i have to pass any parameter while loading libertas_tf?
>> I have also tried installing all the firmware versions from
>> http://dev.laptop.org/pub/firmware/libertas/thinfirm/ just to be sure.
>> I have installed the kernel after build its RPM
>> (http://dev.laptop.org/~assim/kernel_rpms/) on XO itself.
>>
>> 2) I also tried blacklisting libertas and usb8xxx modules but still
>> they are loading at boot time. again no error in logs.
>>
>> I am stuck as i am not getting any error message at all.
>>
>> --
>> Assim Deodia
>> --
>> 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
>>
>
> With libertas_tf, it is completely normal to have no eth0 interface,
> as it is a mac80211 driver, and thus registers interfaces with the
> "wlan" prefix, rather than "eth". So, you should be seeing a "wlan0"
> interface.
>
> --
> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>
--
Assim Deodia
Software Developer
One97 Communications Ltd, Noida
P: + 91 120 4770770
M: + 91 9911804112
Let’s Get Talking!
^ permalink raw reply
* Re: [ath5k-devel] [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Dmytro Milinevskyy @ 2010-06-12 2:02 UTC (permalink / raw)
To: Johannes Berg
Cc: Bob Copeland, ath5k-devel, Kalle Valo, linux-wireless,
GeunSik Lim, Jiri Slaby, Greg Kroah-Hartman, John W. Linville,
Keng-Yu Lin, netdev, Jiri Kosina, Shahar Or, linux-kernel,
Luca Verdesca
In-Reply-To: <1276288163.3918.1.camel@jlt3.sipsolutions.net>
In this case no way to control LEDs. If you turn LEDs support you
can't tune them out, no?
I believe that user should be able to chose whether LEDs support is
needed or not. This is how done in intel wireless drivers. The driver
should be tolerant.
-- Dima
On Fri, Jun 11, 2010 at 11:29 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Fri, 2010-06-11 at 23:26 +0300, Dmytro Milinevskyy wrote:
>> Generic LED class is not disabled so it's possible to control leds in sysfs.
>
> But if you turn off ATH5K_LEDS??
>
> johannes
>
>
^ permalink raw reply
* Re: no eth0 on using libertas_tf + F11 on OLPC XO-1
From: Gábor Stefanik @ 2010-06-12 1:39 UTC (permalink / raw)
To: Assim Deodia; +Cc: linux-wireless
In-Reply-To: <AANLkTinPM1byJy-y8GChXbAdYQuCvgiQRISWfmBRKoJu@mail.gmail.com>
On Fri, Jun 11, 2010 at 10:08 PM, Assim Deodia <assim.deodia@gmail.com> wrote:
> Hi All,
>
> I am having some issues loading libertas_tf on XO-1 with kernel 2.6.31.
>
> 1) after unloading libertas and usb8xxx modules when i modprobe
> libertas_tf module eth0 (wireless interface) disappears. and instead
> wmaster0 appears. but iwconfig show wmaster0 does not have wireless
> extensions. lsmod shows libertas_tf and libertas_tf_usb module loaded.
> No error in system logs. no error by modprobe. but no wireless
> interface. Do i have to pass any parameter while loading libertas_tf?
> I have also tried installing all the firmware versions from
> http://dev.laptop.org/pub/firmware/libertas/thinfirm/ just to be sure.
> I have installed the kernel after build its RPM
> (http://dev.laptop.org/~assim/kernel_rpms/) on XO itself.
>
> 2) I also tried blacklisting libertas and usb8xxx modules but still
> they are loading at boot time. again no error in logs.
>
> I am stuck as i am not getting any error message at all.
>
> --
> Assim Deodia
> --
> 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
>
With libertas_tf, it is completely normal to have no eth0 interface,
as it is a mac80211 driver, and thus registers interfaces with the
"wlan" prefix, rather than "eth". So, you should be seeing a "wlan0"
interface.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [ath5k-devel] [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Johannes Berg @ 2010-06-11 20:29 UTC (permalink / raw)
To: Dmytro Milinevskyy
Cc: Bob Copeland, ath5k-devel, Kalle Valo, linux-wireless,
GeunSik Lim, Jiri Slaby, Greg Kroah-Hartman, John W. Linville,
Keng-Yu Lin, netdev, Jiri Kosina, Shahar Or, linux-kernel,
Luca Verdesca
In-Reply-To: <AANLkTim90VBfWjp2YPYeYN6ImjIyZzcJ_XnpT5cdgCt4@mail.gmail.com>
On Fri, 2010-06-11 at 23:26 +0300, Dmytro Milinevskyy wrote:
> Generic LED class is not disabled so it's possible to control leds in sysfs.
But if you turn off ATH5K_LEDS??
johannes
^ permalink raw reply
* Re: [ath5k-devel] [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Dmytro Milinevskyy @ 2010-06-11 20:26 UTC (permalink / raw)
To: Johannes Berg
Cc: Bob Copeland, ath5k-devel, Kalle Valo, linux-wireless,
GeunSik Lim, Jiri Slaby, Greg Kroah-Hartman, John W. Linville,
Keng-Yu Lin, netdev, Jiri Kosina, Shahar Or, linux-kernel,
Luca Verdesca
In-Reply-To: <1276286993.3918.0.camel@jlt3.sipsolutions.net>
Generic LED class is not disabled so it's possible to control leds in sysfs.
-- Dima
On Fri, Jun 11, 2010 at 11:09 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2010-06-09 at 17:43 +0300, Dmytro Milinevskyy wrote:
>> Hi, Bob.
>>
>> For instance I don't use 802.11 leds layer and trigger leds from
>> userspace according to my purposes.
>
> Without the LED stuff in sysfs, how do you do that?
>
> johannes
>
>
^ permalink raw reply
* Re: [ath5k-devel] [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Johannes Berg @ 2010-06-11 20:09 UTC (permalink / raw)
To: Dmytro Milinevskyy
Cc: Bob Copeland, ath5k-devel, Kalle Valo, linux-wireless,
GeunSik Lim, Jiri Slaby, Greg Kroah-Hartman, John W. Linville,
Keng-Yu Lin, netdev, Jiri Kosina, Shahar Or, linux-kernel,
Luca Verdesca
In-Reply-To: <AANLkTimXqdkQxv_Y1JaleTTWNsDIQHQaPn8HR7efOupb@mail.gmail.com>
On Wed, 2010-06-09 at 17:43 +0300, Dmytro Milinevskyy wrote:
> Hi, Bob.
>
> For instance I don't use 802.11 leds layer and trigger leds from
> userspace according to my purposes.
Without the LED stuff in sysfs, how do you do that?
johannes
^ permalink raw reply
* Re: no eth0 on using libertas_tf + F11 on OLPC XO-1
From: Assim Deodia @ 2010-06-11 20:08 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <AANLkTinpYdb9Q_AEdUc7gvEIcxZoCFyVaKMIi6c_Sf9n@mail.gmail.com>
Hi All,
I am having some issues loading libertas_tf on XO-1 with kernel 2.6.31.
1) after unloading libertas and usb8xxx modules when i modprobe
libertas_tf module eth0 (wireless interface) disappears. and instead
wmaster0 appears. but iwconfig show wmaster0 does not have wireless
extensions. lsmod shows libertas_tf and libertas_tf_usb module loaded.
No error in system logs. no error by modprobe. but no wireless
interface. Do i have to pass any parameter while loading libertas_tf?
I have also tried installing all the firmware versions from
http://dev.laptop.org/pub/firmware/libertas/thinfirm/ just to be sure.
I have installed the kernel after build its RPM
(http://dev.laptop.org/~assim/kernel_rpms/) on XO itself.
2) I also tried blacklisting libertas and usb8xxx modules but still
they are loading at boot time. again no error in logs.
I am stuck as i am not getting any error message at all.
--
Assim Deodia
^ permalink raw reply
* Re: [ath5k-devel] [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Dmytro Milinevskyy @ 2010-06-11 19:52 UTC (permalink / raw)
To: Bob Copeland
Cc: Kalle Valo, GeunSik Lim, Greg Kroah-Hartman, Jiri Slaby, netdev,
ath5k-devel, linux-wireless, John W. Linville, Keng-Yu Lin,
Jiri Kosina, Shahar Or, linux-kernel, Luca Verdesca
In-Reply-To: <AANLkTimUW58T19GOkRk3oCC9huLDQLgLj4W3RjiQ9n53@mail.gmail.com>
I didn't know. Thank you for noting that.
However I think it's better to give a chance to disable 802.11 leds.
-- Dima
On Fri, Jun 11, 2010 at 8:07 PM, Bob Copeland <me@bobcopeland.com> wrote:
> On Wed, Jun 9, 2010 at 10:43 AM, Dmytro Milinevskyy
> <milinevskyy@gmail.com> wrote:
>> Hi, Bob.
>>
>> For instance I don't use 802.11 leds layer and trigger leds from
>> userspace according to my purposes.
>
> FWIW you can disable mac80211 triggers from userspace as well.
> But, I guess hooking up null triggers will work too.
>
> --
> Bob Copeland %% www.bobcopeland.com
>
^ permalink raw reply
* [RFT] ath5k: add new PCI devices
From: Luis R. Rodriguez @ 2010-06-11 18:39 UTC (permalink / raw)
To: linux-wireless, ath5k-devel
Cc: wilson.tsao, mian.tuo, akira.iida, jinyong.ren, david.quan,
Luis R. Rodriguez
Found our PCI device list not up to date with respect
to the PCI device ID db for 0x168c for legacy (non-802.11)
devices:
https://pci-ids.ucw.cz/read/PC/168c/
There a few bogus ones there but I believe these are also
listed on our NDIS driver.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
[RFT] request to test, if any ath5k users have these devices.
Note: this e-mail is sent on a public mailing list. It is
appreciated if you do reply to all and keep the
public mailing list CC'd.
I just saw a patch to add 0xff19 internally but also spotted
the other ones on the PCI device ID db. Folks CC'd do you know if
these other are indeed ath5k device? Can you also confirm if
indeed 0xff19 is an AR5424 device?
Luis
drivers/net/wireless/ath/ath5k/base.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 9d37c1a..cd44e02 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -103,6 +103,9 @@ static DEFINE_PCI_DEVICE_TABLE(ath5k_pci_id_table) = {
{ PCI_VDEVICE(ATHEROS, 0x001b) }, /* 5413 Eagle */
{ PCI_VDEVICE(ATHEROS, 0x001c) }, /* PCI-E cards */
{ PCI_VDEVICE(ATHEROS, 0x001d) }, /* 2417 Nala */
+ { PCI_VDEVICE(ATHEROS, 0xff19) }, /* 5424 */
+ { PCI_VDEVICE(ATHEROS, 0xff1c) },
+ { PCI_VDEVICE(ATHEROS, 0xff1d) },
{ 0 }
};
MODULE_DEVICE_TABLE(pci, ath5k_pci_id_table);
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] wireless: orphan ipw2x00 drivers
From: David Miller @ 2010-06-11 18:38 UTC (permalink / raw)
To: reinette.chatre; +Cc: linville, yi.zhu, linux-wireless
In-Reply-To: <1276278467.25793.1296.camel@rchatre-DESK>
From: reinette chatre <reinette.chatre@intel.com>
Date: Fri, 11 Jun 2010 10:47:47 -0700
> On Wed, 2010-06-09 at 22:52 -0700, David Miller wrote:
>> If documentation can't be provided so that others can maintain this
>> driver (not just few specific people, because some day those folks
>> might tire of maintaining this too) that would be a serious crime.
>
> We are unable to release this documentation, but are looking into our
> options at this time. With groups disbanded this will take some time.
And people wonder why we push vendors so damn hard to release chip
documentation even when the vendor has an upstream friendly set of
developers maintaining the code at least at the beginning.
It's exactly because stuff like this can and does happen. And with
the plethora of devices with drivers in the tree now, expect the
number of times this happens to escalate in the future rather than
decrease.
We're powerless without those documents, and at the mercy of what
you guys end up deciding to do. That doesn't work.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2010-06-09
From: David Miller @ 2010-06-11 18:34 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20100609211251.GC2452@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 9 Jun 2010 17:12:51 -0400
> Dave,
>
> Here is the usual, frightening, monstrous post-window pull request...
> Along with the usual batch of driver updates, there are also some DMA
> state API conversions from FUJITA Tomonori, some cleanups from Julia
> Lawall and Joe Perches, some SSB changes from Larry Finger and Rafał
> Miłecki, and a number of mac80211 changes from Johannes Berg. All of it
> has had at least one cycle through linux-next and most of it has been
> there for several days. This also includes the same wireless-2.6 pull I
> sent you previously so as to resolve some merge conflicts.
>
> Please let me know if there are problems!
Pulled, thanks JOhn.
^ permalink raw reply
* compat-wireless based on 2.6.35-rc2 pushed out
From: Luis R. Rodriguez @ 2010-06-11 18:29 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth; +Cc: linux-kernel
Its on the stable page now:
http://wireless.kernel.org/en/users/Download/stable
tarball: http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.35/compat-wireless-2.6.35-rc2.tar.bz2
sha1sum: 6b2f040c965bffd4a659a7f4771832a9b7b568e5
ChangeLog: http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.35/ChangeLog-2.6.35-rc2-wireless
This actually has all the changes from Linus' tree as of today so it
actually has extra stuff on top of rc2, its more like an rc3. I
spotted these merged already:
$ git shortlog v2.6.35-rc2.. net/mac80211/ net/wireless/ drivers/net/
drivers/bluetooth/
Abhijeet Kolekar (1):
iwl3945: fix internal scan
Bob Copeland (1):
ath5k: retain promiscuous setting
Bruno Randolf (1):
ath5k: fix NULL pointer in antenna configuration
David S. Miller (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Denis Kirjanov (1):
8139too: fix buffer overrun in rtl8139_init_board
Emmanuel Grumbach (1):
iwlwifi: move sysfs_create_group to post request firmware
Grazvydas Ignotas (1):
wl1251: fix a memory leak in probe
Holger Schurig (1):
mac80211: fix function pointer check
Jason Dravet (1):
p54usb: Add device ID for Dell WLA3310 USB
Johannes Berg (3):
mac80211: process station blockack action frames from work
iwlwifi: add missing rcu_read_lock
mac80211: fix deauth before assoc
John W. Linville (1):
Revert "wireless: hostap, fix oops due to early probing interrupt"
Jussi Kivilinna (1):
asix: check packet size against mtu+ETH_HLEN instead of ETH_FRAME_LEN
Linus Torvalds (1):
Merge git://git.kernel.org/.../davem/net-2.6
Reinette Chatre (1):
iwl3945: enable stuck queue detection on 3945
Timo Teräs (1):
r8169: fix random mdio_write failures
Tobias Doerffel (1):
ath5k: depend on CONFIG_PM_SLEEP for suspend/resume functions
Luis
^ permalink raw reply
* Re: [PATCH] wireless: orphan ipw2x00 drivers
From: reinette chatre @ 2010-06-11 18:19 UTC (permalink / raw)
To: Joe Perches
Cc: David Miller, linville@tuxdriver.com, Zhu, Yi,
linux-wireless@vger.kernel.org
In-Reply-To: <1276279556.1637.79.camel@Joe-Laptop.home>
On Fri, 2010-06-11 at 11:05 -0700, Joe Perches wrote:
> On Fri, 2010-06-11 at 10:47 -0700, reinette chatre wrote:
> > This is why we changed the status to "Orphaned" since it really seem to
> > reflect our status at this time. We really do not know what else to do.
> >
> > I understand that there is a concern with low level bugs for which
> > hardware documentation may be needed. We surely will do our best to help
> > out when these situations arise.
>
> The S: line is just a guide.
>
> Maybe change it to something more descriptive like:
>
> S: Orphaned, might dig up moldy faxed copies of hardware docs
>
That would be ideal if we can have some custom text in this file. We
actually looked into this but found that the different status field
values are currently used strictly by all entries in MAINTAINERS. Not
knowing what parses these files we stuck with the current style.
Reinette
^ permalink raw reply
* Re: [PATCH] wireless: orphan ipw2x00 drivers
From: Joe Perches @ 2010-06-11 18:05 UTC (permalink / raw)
To: reinette chatre; +Cc: David Miller, linville, Zhu, Yi, linux-wireless
In-Reply-To: <1276278467.25793.1296.camel@rchatre-DESK>
On Fri, 2010-06-11 at 10:47 -0700, reinette chatre wrote:
> This is why we changed the status to "Orphaned" since it really seem to
> reflect our status at this time. We really do not know what else to do.
>
> I understand that there is a concern with low level bugs for which
> hardware documentation may be needed. We surely will do our best to help
> out when these situations arise.
The S: line is just a guide.
Maybe change it to something more descriptive like:
S: Orphaned, might dig up moldy faxed copies of hardware docs
^ permalink raw reply
* Re: [PATCH] wireless: orphan ipw2x00 drivers
From: reinette chatre @ 2010-06-11 17:47 UTC (permalink / raw)
To: David Miller
Cc: linville@tuxdriver.com, Zhu, Yi, linux-wireless@vger.kernel.org
In-Reply-To: <20100609.225243.179940910.davem@davemloft.net>
On Wed, 2010-06-09 at 22:52 -0700, David Miller wrote:
> From: "John W. Linville" <linville@tuxdriver.com>
> Date: Wed, 9 Jun 2010 21:45:47 -0400
>
> > On Thu, Jun 10, 2010 at 09:44:29AM +0800, Zhu Yi wrote:
> >> Signed-off-by: Zhu Yi <yi.zhu@intel.com>
> >> ---
> >> Please let us know if someone is interested in maintaining these drivers.
> >
> > Any chance of getting some hardware/firmware documentation?
>
> Indeed.
>
> I'm extremely disappointed that the only organization currently even
> capable of fixing low level bugs in these drivers no longer is willing
> to do so.
This is not the situation. We recently lost all expertise with these
drivers and are unable to maintain them respectfully anymore.
If we continue to have the MAINTAINERS file commit us to "Odd fixes" we
are still responsible for reviewing/acknowledging patches, answering
community questions related to the driver, and looking into at least
critical bugs. Unfortunately we now have no ability to do any of these
tasks and surely not any better that members from the community (some of
whom actually know these drivers better than any of the people left here
at Intel).
This is why we changed the status to "Orphaned" since it really seem to
reflect our status at this time. We really do not know what else to do.
I understand that there is a concern with low level bugs for which
hardware documentation may be needed. We surely will do our best to help
out when these situations arise.
> If documentation can't be provided so that others can maintain this
> driver (not just few specific people, because some day those folks
> might tire of maintaining this too) that would be a serious crime.
We are unable to release this documentation, but are looking into our
options at this time. With groups disbanded this will take some time.
Reinette
^ permalink raw reply
* [PATCH v2] mac80211: Use a separate CCMP PN receive counter for management frames
From: Jouni Malinen @ 2010-06-11 17:27 UTC (permalink / raw)
To: John W. Linville, Johannes Berg; +Cc: linux-wireless
In-Reply-To: <20100611024625.GB3985@jm.kir.nu>
When management frame protection (IEEE 802.11w) is used, we must use a
separate counter for tracking received CCMP packet number for the
management frames. The previously used NUM_RX_DATA_QUEUESth queue was
shared with data frames when QoS was not used and that can cause
problems in detecting replays incorrectly for robust management frames.
Add a new counter just for robust management frames to avoid this issue.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
---
net/mac80211/debugfs_key.c | 2 +-
net/mac80211/key.c | 2 +-
net/mac80211/key.h | 8 +++++++-
net/mac80211/rx.c | 9 +++++++--
net/mac80211/wpa.c | 8 ++++++--
5 files changed, 22 insertions(+), 7 deletions(-)
v2: Add a comment describing the use of CCMP receive counters per
request from Johannes.
--- wireless-testing.orig/net/mac80211/debugfs_key.c 2010-06-11 10:22:06.000000000 -0700
+++ wireless-testing/net/mac80211/debugfs_key.c 2010-06-11 10:22:42.000000000 -0700
@@ -143,7 +143,7 @@ static ssize_t key_rx_spec_read(struct f
len = p - buf;
break;
case ALG_CCMP:
- for (i = 0; i < NUM_RX_DATA_QUEUES; i++) {
+ for (i = 0; i < NUM_RX_DATA_QUEUES + 1; i++) {
rpn = key->u.ccmp.rx_pn[i];
p += scnprintf(p, sizeof(buf)+buf-p,
"%02x%02x%02x%02x%02x%02x\n",
--- wireless-testing.orig/net/mac80211/key.c 2010-06-11 10:22:06.000000000 -0700
+++ wireless-testing/net/mac80211/key.c 2010-06-11 10:22:42.000000000 -0700
@@ -273,7 +273,7 @@ struct ieee80211_key *ieee80211_key_allo
key->conf.iv_len = CCMP_HDR_LEN;
key->conf.icv_len = CCMP_MIC_LEN;
if (seq) {
- for (i = 0; i < NUM_RX_DATA_QUEUES; i++)
+ for (i = 0; i < NUM_RX_DATA_QUEUES + 1; i++)
for (j = 0; j < CCMP_PN_LEN; j++)
key->u.ccmp.rx_pn[i][j] =
seq[CCMP_PN_LEN - j - 1];
--- wireless-testing.orig/net/mac80211/key.h 2010-06-11 10:22:06.000000000 -0700
+++ wireless-testing/net/mac80211/key.h 2010-06-11 10:23:04.000000000 -0700
@@ -77,7 +77,13 @@ struct ieee80211_key {
} tkip;
struct {
u8 tx_pn[6];
- u8 rx_pn[NUM_RX_DATA_QUEUES][6];
+ /*
+ * Last received packet number. The first
+ * NUM_RX_DATA_QUEUES counters are used with Data
+ * frames and the last counter is used with Robust
+ * Management frames.
+ */
+ u8 rx_pn[NUM_RX_DATA_QUEUES + 1][6];
struct crypto_cipher *tfm;
u32 replays; /* dot11RSNAStatsCCMPReplays */
/* scratch buffers for virt_to_page() (crypto API) */
--- wireless-testing.orig/net/mac80211/rx.c 2010-06-11 10:22:06.000000000 -0700
+++ wireless-testing/net/mac80211/rx.c 2010-06-11 10:22:42.000000000 -0700
@@ -1268,11 +1268,13 @@ ieee80211_rx_h_defragment(struct ieee802
rx->queue, &(rx->skb));
if (rx->key && rx->key->conf.alg == ALG_CCMP &&
ieee80211_has_protected(fc)) {
+ int queue = ieee80211_is_mgmt(fc) ?
+ NUM_RX_DATA_QUEUES : rx->queue;
/* Store CCMP PN so that we can verify that the next
* fragment has a sequential PN value. */
entry->ccmp = 1;
memcpy(entry->last_pn,
- rx->key->u.ccmp.rx_pn[rx->queue],
+ rx->key->u.ccmp.rx_pn[queue],
CCMP_PN_LEN);
}
return RX_QUEUED;
@@ -1292,6 +1294,7 @@ ieee80211_rx_h_defragment(struct ieee802
if (entry->ccmp) {
int i;
u8 pn[CCMP_PN_LEN], *rpn;
+ int queue;
if (!rx->key || rx->key->conf.alg != ALG_CCMP)
return RX_DROP_UNUSABLE;
memcpy(pn, entry->last_pn, CCMP_PN_LEN);
@@ -1300,7 +1303,9 @@ ieee80211_rx_h_defragment(struct ieee802
if (pn[i])
break;
}
- rpn = rx->key->u.ccmp.rx_pn[rx->queue];
+ queue = ieee80211_is_mgmt(fc) ?
+ NUM_RX_DATA_QUEUES : rx->queue;
+ rpn = rx->key->u.ccmp.rx_pn[queue];
if (memcmp(pn, rpn, CCMP_PN_LEN))
return RX_DROP_UNUSABLE;
memcpy(entry->last_pn, pn, CCMP_PN_LEN);
--- wireless-testing.orig/net/mac80211/wpa.c 2010-06-11 10:22:06.000000000 -0700
+++ wireless-testing/net/mac80211/wpa.c 2010-06-11 10:22:42.000000000 -0700
@@ -436,6 +436,7 @@ ieee80211_crypto_ccmp_decrypt(struct iee
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
u8 pn[CCMP_PN_LEN];
int data_len;
+ int queue;
hdrlen = ieee80211_hdrlen(hdr->frame_control);
@@ -453,7 +454,10 @@ ieee80211_crypto_ccmp_decrypt(struct iee
ccmp_hdr2pn(pn, skb->data + hdrlen);
- if (memcmp(pn, key->u.ccmp.rx_pn[rx->queue], CCMP_PN_LEN) <= 0) {
+ queue = ieee80211_is_mgmt(hdr->frame_control) ?
+ NUM_RX_DATA_QUEUES : rx->queue;
+
+ if (memcmp(pn, key->u.ccmp.rx_pn[queue], CCMP_PN_LEN) <= 0) {
key->u.ccmp.replays++;
return RX_DROP_UNUSABLE;
}
@@ -470,7 +474,7 @@ ieee80211_crypto_ccmp_decrypt(struct iee
return RX_DROP_UNUSABLE;
}
- memcpy(key->u.ccmp.rx_pn[rx->queue], pn, CCMP_PN_LEN);
+ memcpy(key->u.ccmp.rx_pn[queue], pn, CCMP_PN_LEN);
/* Remove CCMP header and MIC */
skb_trim(skb, skb->len - CCMP_MIC_LEN);
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [ath5k-devel] [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Bob Copeland @ 2010-06-11 17:07 UTC (permalink / raw)
To: Dmytro Milinevskyy
Cc: Kalle Valo, GeunSik Lim, Greg Kroah-Hartman, Jiri Slaby, netdev,
ath5k-devel, linux-wireless, John W. Linville, Keng-Yu Lin,
Jiri Kosina, Shahar Or, linux-kernel, Luca Verdesca
In-Reply-To: <AANLkTimXqdkQxv_Y1JaleTTWNsDIQHQaPn8HR7efOupb@mail.gmail.com>
On Wed, Jun 9, 2010 at 10:43 AM, Dmytro Milinevskyy
<milinevskyy@gmail.com> wrote:
> Hi, Bob.
>
> For instance I don't use 802.11 leds layer and trigger leds from
> userspace according to my purposes.
FWIW you can disable mac80211 triggers from userspace as well.
But, I guess hooking up null triggers will work too.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: iwl3945 bug in 2.6.34
From: reinette chatre @ 2010-06-11 16:27 UTC (permalink / raw)
To: Satish Eerpini; +Cc: linux-kernel, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTillaEGISTjW4iqpsNsJbaE6ZW7pqYvAzoBrkI69@mail.gmail.com>
On Fri, 2010-06-11 at 04:39 -0700, Satish Eerpini wrote:
> The 2.6.34 vanilla kernel with the above patches applied crashed again
> today, I was amidst a conference on webex when this happened, still
> not able to figure out what is the kind of traffic that causes the
> driver to give up ... here is output from dmesg :
Instead of duplicate posts to the list and bugzilla, lets just continue
debugging this at https://bugzilla.kernel.org/show_bug.cgi?id=16084 - I
responded there to your message.
Thanks
Reinette
^ permalink raw reply
* Re: [ath5k-devel] [PATCH] ath5k: disable all tasklets while resetting
From: Bob Copeland @ 2010-06-11 14:38 UTC (permalink / raw)
To: Johannes Berg; +Cc: Bruno Randolf, ath5k-devel, linux-wireless, linville
In-Reply-To: <AANLkTilzHEhYgPyOnUtHk9HrOuSyyifwoI3hN6VUG1Xr@mail.gmail.com>
On Fri, Jun 11, 2010 at 10:21 AM, Bob Copeland <me@bobcopeland.com> wrote:
> On Fri, Jun 11, 2010 at 6:41 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>
>> I have no idea how long a reset can take, but this means that all these
>> tasklets will spin while your reset is running if they were scheduled.
>
> It looks to me like tasklet_action() will bail out when the tasklet has a
> positive t->count (which disable elevates) rather than spin. What did I
> miss?
As Johannes pointed out on irc, I missed that it re-raises the softirq. doh!
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [PATCH 3/4] pcmcia: dev_node removal bugfix
From: Dominik Brodowski @ 2010-06-11 14:44 UTC (permalink / raw)
To: linux-pcmcia; +Cc: Dominik Brodowski, netdev, linux-wireless
In-Reply-To: <20100611144359.GA9572@comet.dominikbrodowski.net>
Patch c7c2fa07 removed one line too much from smc91c92_cs.c.
Reported-by: Komuro <komurojun-mbn@nifty.com>
CC: netdev@vger.kernel.org
CC: linux-wireless@vger.kernel.org
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
---
drivers/net/pcmcia/smc91c92_cs.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/pcmcia/smc91c92_cs.c b/drivers/net/pcmcia/smc91c92_cs.c
index 7b6fe89..64e6a84 100644
--- a/drivers/net/pcmcia/smc91c92_cs.c
+++ b/drivers/net/pcmcia/smc91c92_cs.c
@@ -322,6 +322,7 @@ static int smc91c92_probe(struct pcmcia_device *link)
return -ENOMEM;
smc = netdev_priv(dev);
smc->p_dev = link;
+ link->priv = dev;
spin_lock_init(&smc->lock);
link->io.NumPorts1 = 16;
--
1.7.0.4
^ permalink raw reply related
* Re: [ath5k-devel] [PATCH] ath5k: disable all tasklets while resetting
From: Bob Copeland @ 2010-06-11 14:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: Bruno Randolf, ath5k-devel, linux-wireless, linville
In-Reply-To: <1276252913.3640.12.camel@jlt3.sipsolutions.net>
On Fri, Jun 11, 2010 at 6:41 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> I have no idea how long a reset can take, but this means that all these
> tasklets will spin while your reset is running if they were scheduled.
It looks to me like tasklet_action() will bail out when the tasklet has a
positive t->count (which disable elevates) rather than spin. What did I
miss?
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: iwl3945 bug in 2.6.34
From: Satish Eerpini @ 2010-06-11 11:39 UTC (permalink / raw)
To: reinette chatre; +Cc: linux-kernel, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTinfoyhEyFjxReR6Oza7r_AQhcyMlpaXYB4ZjjlU@mail.gmail.com>
The 2.6.34 vanilla kernel with the above patches applied crashed again
today, I was amidst a conference on webex when this happened, still
not able to figure out what is the kind of traffic that causes the
driver to give up ... here is output from dmesg :
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: Calling CRDA for country: IN
cfg80211: Regulatory domain changed to country: IN
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 20000 KHz), (N/A, 2000 mBm)
(5250000 KHz - 5330000 KHz @ 20000 KHz), (N/A, 2000 mBm)
(5735000 KHz - 5835000 KHz @ 20000 KHz), (N/A, 2000 mBm)
wlan0: authenticate with 00:1b:da:2a:a1:53 (try 1)
wlan0: authenticated
wlan0: associate with 00:1b:da:2a:a1:53 (try 1)
wlan0: RX AssocResp from 00:1b:da:2a:a1:53 (capab=0x411 status=0 aid=1)
wlan0: associated
usb 4-2: USB disconnect, address 4
iwl3945 0000:10:00.0: queue 2 stuck 3 time. Fw reload.
iwl3945 0000:10:00.0: On demand firmware reload
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: BSM uCode verification failed at addr
0x00003800+0 (of 900), is 0xffffffff, s/b 0xf802020
iwl3945 0000:10:00.0: Wait for START_ALIVE timeout after 2000ms.
No probe response from AP 00:1b:da:2a:a1:53 after 500ms, disconnecting.
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: Calling CRDA for country: IN
cfg80211: Regulatory domain changed to country: IN
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 20000 KHz), (N/A, 2000 mBm)
(5250000 KHz - 5330000 KHz @ 20000 KHz), (N/A, 2000 mBm)
(5735000 KHz - 5835000 KHz @ 20000 KHz), (N/A, 2000 mBm)
is there anything else that can be done ??
Cheers
Satish
On Fri, Jun 11, 2010 at 12:19 AM, Satish Eerpini <eerpini@gmail.com> wrote:
> I have applied the patches to the 2.6.34 kernel, my machine has been
> up for 20 hours now, there is nothing in the dmesg either, dmesg |
> grep wlan0 just gives this :
>
> ADDRCONF(NETDEV_UP): wlan0: link is not ready
> wlan0: deauthenticating from 00:1b:da:2a:a1:53 by local choice (reason=3)
> wlan0: authenticate with 00:1b:da:2a:a1:53 (try 1)
> wlan0: authenticated
> wlan0: associate with 00:1b:da:2a:a1:53 (try 1)
> wlan0: RX AssocResp from 00:1b:da:2a:a1:53 (capab=0x411 status=0 aid=1)
> wlan0: associated
> ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> wlan0: no IPv6 routers present
> wlan0: deauthenticating from 00:1b:da:2a:a1:53 by local choice (reason=3)
> ADDRCONF(NETDEV_UP): wlan0: link is not ready
> wlan0: deauthenticating from 00:1b:da:2a:a1:53 by local choice (reason=3)
> wlan0: authenticate with 00:1b:da:2a:a1:53 (try 1)
> wlan0: authenticated
> wlan0: associate with 00:1b:da:2a:a1:53 (try 1)
> wlan0: RX AssocResp from 00:1b:da:2a:a1:53 (capab=0x411 status=0 aid=1)
> wlan0: associated
> ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> wlan0: no IPv6 routers present
> wlan0: authenticate with 00:1b:da:2a:a1:53 (try 1)
> wlan0: authenticated
> wlan0: associate with 00:1b:da:2a:a1:53 (try 1)
> wlan0: RX AssocResp from 00:1b:da:2a:a1:53 (capab=0x411 status=0 aid=1)
> wlan0: associated
> wlan0: authenticate with 00:1b:da:2a:a1:53 (try 1)
> wlan0: authenticated
> wlan0: associate with 00:1b:da:2a:a1:53 (try 1)
> wlan0: RX AssocResp from 00:1b:da:2a:a1:53 (capab=0x411 status=0 aid=1)
> wlan0: associated
>
> so I think after applying the patches, things have been working fine.
>
> Cheers
> Satish
>
> --
> http://satisheerpini.net
>
--
http://satisheerpini.net
^ permalink raw reply
* Re: [PATCH] ath5k: disable all tasklets while resetting
From: Johannes Berg @ 2010-06-11 10:41 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linville, ath5k-devel, linux-wireless
In-Reply-To: <20100611101221.26538.46913.stgit@tt-desk>
On Fri, 2010-06-11 at 19:12 +0900, Bruno Randolf wrote:
> Make sure no tasklets can run concurrently to a reset.
>
> Signed-off-by: Bruno Randolf <br1@einfach.org>
> ---
> drivers/net/wireless/ath/ath5k/base.c | 12 ++++++++++++
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
> index 9d37c1a..585c517 100644
> --- a/drivers/net/wireless/ath/ath5k/base.c
> +++ b/drivers/net/wireless/ath/ath5k/base.c
> @@ -2908,6 +2908,12 @@ ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan)
>
> ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "resetting\n");
>
> + tasklet_disable(&sc->rxtq); /* ath5k_tasklet_rx */
> + tasklet_disable(&sc->txtq); /* ath5k_tasklet_tx */
> + tasklet_disable(&sc->calib); /* ath5k_tasklet_calibrate */
> + tasklet_disable(&sc->beacontq); /* ath5k_tasklet_beacon */
> + tasklet_disable(&sc->ani_tasklet); /* ath5k_tasklet_ani */
I have no idea how long a reset can take, but this means that all these
tasklets will spin while your reset is running if they were scheduled.
johannes
^ permalink raw reply
* [PATCH] ath5k: disable all tasklets while resetting
From: Bruno Randolf @ 2010-06-11 10:12 UTC (permalink / raw)
To: linville; +Cc: ath5k-devel, linux-wireless
Make sure no tasklets can run concurrently to a reset.
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
drivers/net/wireless/ath/ath5k/base.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 9d37c1a..585c517 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -2908,6 +2908,12 @@ ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan)
ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "resetting\n");
+ tasklet_disable(&sc->rxtq); /* ath5k_tasklet_rx */
+ tasklet_disable(&sc->txtq); /* ath5k_tasklet_tx */
+ tasklet_disable(&sc->calib); /* ath5k_tasklet_calibrate */
+ tasklet_disable(&sc->beacontq); /* ath5k_tasklet_beacon */
+ tasklet_disable(&sc->ani_tasklet); /* ath5k_tasklet_ani */
+
if (chan) {
ath5k_hw_set_imr(ah, 0);
ath5k_txq_cleanup(sc);
@@ -2948,6 +2954,12 @@ ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan)
ath5k_beacon_config(sc);
/* intrs are enabled by ath5k_beacon_config */
+ tasklet_enable(&sc->rxtq); /* ath5k_tasklet_rx */
+ tasklet_enable(&sc->txtq); /* ath5k_tasklet_tx */
+ tasklet_enable(&sc->calib); /* ath5k_tasklet_calibrate */
+ tasklet_enable(&sc->beacontq); /* ath5k_tasklet_beacon */
+ tasklet_enable(&sc->ani_tasklet); /* ath5k_tasklet_ani */
+
ieee80211_wake_queues(sc->hw);
return 0;
^ permalink raw reply related
* Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34
From: Jens Axboe @ 2010-06-11 9:07 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Rafael J. Wysocki, Carl Worth, Eric Anholt,
Venkatesh Pallipadi, Dave Airlie, Jesse Barnes, David H?rdeman,
Mauro Carvalho Chehab, Eric Dumazet, Linux Kernel Mailing List,
Maciej Rutecki, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <20100611085520.GA20218@elte.hu>
On 2010-06-11 10:55, Ingo Molnar wrote:
>
> * Jens Axboe <jaxboe@fusionio.com> wrote:
>
>> On 2010-06-11 10:32, Ingo Molnar wrote:
>>>
>>> * Jens Axboe <jaxboe@fusionio.com> wrote:
>>>
>>>> On 2010-06-09 03:53, Linus Torvalds wrote:
>>>>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16129
>>>>>> Subject : BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2
>>>>>> Submitter : Jan Kreuzer <kontrollator@gmx.de>
>>>>>> Date : 2010-06-05 06:15 (4 days old)
>>>>>
>>>>> This seems to have been introduced by
>>>>>
>>>>> commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
>>>>> Author: Ingo Molnar <mingo@elte.hu>
>>>>> Date: Sat Nov 8 17:05:38 2008 +0100
>>>>>
>>>>> sched: optimize sched_clock() a bit
>>>>>
>>>>> sched_clock() uses cycles_2_ns() needlessly - which is an irq-disabling
>>>>> variant of __cycles_2_ns().
>>>>>
>>>>> Most of the time sched_clock() is called with irqs disabled already.
>>>>> The few places that call it with irqs enabled need to be updated..
>>>>>
>>>>> Signed-off-by: Ingo Molnar <mingo@elte.hu>
>>>>>
>>>>> and this seems to be one of those calling cases that need to be updated..
>>>>>
>>>>> Ingo? The call trace is:
>>>>>
>>>>> BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2-8/337
>>>>> caller is native_sched_clock+0x3c/0x68
>>>>> Pid: 337, comm: jbd2/sda2-8 Not tainted 2.6.35-rc1jan+ #4
>>>>> Call Trace:
>>>>> [<ffffffff812362c5>] debug_smp_processor_id+0xc9/0xe4
>>>>> [<ffffffff8101059d>] native_sched_clock+0x3c/0x68
>>>>> [<ffffffff8101043d>] sched_clock+0x9/0xd
>>>>> [<ffffffff81212d7a>] blk_rq_init+0x97/0xa3
>>>>> [<ffffffff81214d71>] get_request+0x1c4/0x2d0
>>>>> [<ffffffff81214ea6>] get_request_wait+0x29/0x1a6
>>>>> [<ffffffff81215537>] __make_request+0x338/0x45b
>>>>> [<ffffffff812147c2>] generic_make_request+0x2bb/0x330
>>>>> [<ffffffff81214909>] submit_bio+0xd2/0xef
>>>>> [<ffffffff811413cb>] submit_bh+0xf4/0x116
>>>>> [<ffffffff81144853>] block_write_full_page_endio+0x89/0x96
>>>>> [<ffffffff81144875>] block_write_full_page+0x15/0x17
>>>>> [<ffffffff8119b00a>] ext4_writepage+0x356/0x36b
>>>>> [<ffffffff810e1f91>] __writepage+0x1a/0x39
>>>>> [<ffffffff810e32a6>] write_cache_pages+0x20d/0x346
>>>>> [<ffffffff810e3406>] generic_writepages+0x27/0x29
>>>>> [<ffffffff811ca279>] journal_submit_data_buffers+0x110/0x17d
>>>>> [<ffffffff811ca986>] jbd2_journal_commit_transaction+0x4cb/0x156d
>>>>> [<ffffffff811d0cba>] kjournald2+0x147/0x37a
>>>>>
>>>>> (from the bugzilla thing)
>>>>
>>>> This should be fixed by commit 28f4197e which was merged on friday.
>>>
>>> Hm, it's still not entirely fixed, as of 2.6.35-rc2-00131-g7908a9e. With some
>>> configs i get bad spinlock warnings during bootup:
>>>
>>> [ 28.968013] initcall net_olddevs_init+0x0/0x82 returned 0 after 93750 usecs
>>> [ 28.972003] calling b44_init+0x0/0x55 @ 1
>>> [ 28.976009] bus: 'pci': add driver b44
>>> [ 28.976374] sda:
>>> [ 28.978157] BUG: spinlock bad magic on CPU#1, async/0/117
>>> [ 28.980000] lock: 7e1c5bbc, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
>>> [ 28.980000] Pid: 117, comm: async/0 Not tainted 2.6.35-rc2-tip-01092-g010e7ef-dirty #8183
>>> [ 28.980000] Call Trace:
>>> [ 28.980000] [<41ba6d55>] ? printk+0x20/0x24
>>> [ 28.980000] [<4134b7b7>] spin_bug+0x7c/0x87
>>> [ 28.980000] [<4134b853>] do_raw_spin_lock+0x1e/0x123
>>> [ 28.980000] [<41ba92ca>] ? _raw_spin_lock_irqsave+0x12/0x20
>>> [ 28.980000] [<41ba92d2>] _raw_spin_lock_irqsave+0x1a/0x20
>>> [ 28.980000] [<4133476f>] blkiocg_update_io_add_stats+0x25/0xfb
>>> [ 28.980000] [<41335dae>] ? cfq_prio_tree_add+0xb1/0xc1
>>> [ 28.980000] [<41337bc7>] cfq_insert_request+0x8c/0x425
>>> [ 28.980000] [<41ba9271>] ? _raw_spin_unlock_irqrestore+0x17/0x23
>>> [ 28.980000] [<41ba9271>] ? _raw_spin_unlock_irqrestore+0x17/0x23
>>> [ 28.980000] [<41329225>] elv_insert+0x107/0x1a0
>>> [ 28.980000] [<41329354>] __elv_add_request+0x96/0x9d
>>> [ 28.980000] [<4132bb8c>] ? drive_stat_acct+0x9d/0xc6
>>> [ 28.980000] [<4132dd64>] __make_request+0x335/0x376
>>> [ 28.980000] [<4132c726>] generic_make_request+0x336/0x39d
>>> [ 28.980000] [<410ad422>] ? kmem_cache_alloc+0xa1/0x105
>>> [ 28.980000] [<41089285>] ? mempool_alloc_slab+0xe/0x10
>>> [ 28.980000] [<41089285>] ? mempool_alloc_slab+0xe/0x10
>>> [ 28.980000] [<41089285>] ? mempool_alloc_slab+0xe/0x10
>>> [ 28.980000] [<41089347>] ? mempool_alloc+0x57/0xe2
>>> [ 28.980000] [<4132c804>] submit_bio+0x77/0x8f
>>> [ 28.980000] [<410d2cbc>] ? bio_alloc_bioset+0x37/0x94
>>> [ 28.980000] [<410ceb90>] submit_bh+0xc3/0xe2
>>> [ 28.980000] [<410d1474>] block_read_full_page+0x249/0x259
>>> [ 28.980000] [<410d31fb>] ? blkdev_get_block+0x0/0xc6
>>> [ 28.980000] [<41087bfa>] ? add_to_page_cache_locked+0x94/0xb5
>>> [ 28.980000] [<410d3d92>] blkdev_readpage+0xf/0x11
>>> [ 28.980000] [<41088823>] do_read_cache_page+0x7d/0x11a
>>> [ 28.980000] [<410d3d83>] ? blkdev_readpage+0x0/0x11
>>> [ 28.980000] [<410888f4>] read_cache_page_async+0x16/0x1b
>>> [ 28.980000] [<41088904>] read_cache_page+0xb/0x12
>>> [ 28.980000] [<410e80e1>] read_dev_sector+0x2a/0x63
>>> [ 28.980000] [<410e92e8>] adfspart_check_ICS+0x2e/0x166
>>> [ 28.980000] [<41ba6d55>] ? printk+0x20/0x24
>>> [ 28.980000] [<410e8d23>] rescan_partitions+0x196/0x3e4
>>> [ 28.980000] [<41ba7dc7>] ? __mutex_unlock_slowpath+0x98/0x9f
>>> [ 28.980000] [<410e92ba>] ? adfspart_check_ICS+0x0/0x166
>>> [ 28.980000] [<410d4277>] __blkdev_get+0x1e7/0x292
>>> [ 28.980000] [<4133a201>] ? kobject_put+0x14/0x16
>>> [ 28.980000] [<410d432c>] blkdev_get+0xa/0xc
>>> [ 28.980000] [<410e81fb>] register_disk+0x94/0xe5
>>> [ 28.980000] [<413326c6>] ? blk_register_region+0x1b/0x20
>>> [ 28.980000] [<41332815>] add_disk+0x57/0x95
>>> [ 28.980000] [<41331fc6>] ? exact_match+0x0/0x8
>>> [ 28.980000] [<4133233f>] ? exact_lock+0x0/0x11
>>> [ 28.980000] [<41643848>] sd_probe_async+0x108/0x1be
>>> [ 28.980000] [<41048865>] async_thread+0xf5/0x1e6
>>> [ 28.980000] [<4102cbcb>] ? default_wake_function+0x0/0xd
>>> [ 28.980000] [<41048770>] ? async_thread+0x0/0x1e6
>>> [ 28.980000] [<410433df>] kthread+0x5f/0x64
>>> [ 28.980000] [<41043380>] ? kthread+0x0/0x64
>>> [ 28.980000] [<41002cc6>] kernel_thread_helper+0x6/0x10
>>> [ 29.264071] async/1 used greatest stack depth: 2336 bytes left
>>> [ 29.267020] bus: 'ssb': add driver b44
>>> [ 29.267072] initcall b44_init+0x0/0x55 returned 0 after 281250 usecs
>>> [ 29.267076] calling init_nic+0x0/0x16 @ 1
>>>
>>> Caused by the same blkiocg_update_io_add_stats() function. Bootlog and config
>>> attached. Reproducible on that sha1 and with that config.
>>
>> I think I see it, the internal CFQ blkg groups are not properly
>> initialized... Will send a patch shortly.
>
> Cool - can test it with a short turnaround, the bug is easy to reproduce.
Thanks, I need to ensure what the best way to solve it is. The problem
is that if you have BLK_CGROUP set but don't enable the CFQ cgroup
stuff, then you end up calling the real update functions but CFQ has not
initialized them.
--
Jens Axboe
^ 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