* Re: Fwd: [Bug 300794] Installation of WiFi Cards w firmware fails
From: John W. Linville @ 2009-10-26 20:17 UTC (permalink / raw)
To: Dr. Axel Braun; +Cc: linux-wireless
In-Reply-To: <200910222246.30668.axel.braun@gmx.de>
On Thu, Oct 22, 2009 at 10:46:30PM +0200, Dr. Axel Braun wrote:
> Gents,
>
> for some reason there are uncertainties about the license of the p54 firmware
> for the prism chips, which stop the openSUSE project for the moment to ship
> the firmware.
>
> Can you clarify the license question?
>
> Thanks
> Axel
Whom are you asking?
I wish we had a clear statement from the appropriate copyright holder,
but I'm not even sure whom to ask at this point...
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: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211
From: Dan Williams @ 2009-10-26 20:16 UTC (permalink / raw)
To: Holger Schurig
Cc: Christoph Hellwig, Johannes Berg, linux-wireless, John Linville
In-Reply-To: <200910260904.12417.hs4233@mail.mn-solutions.de>
On Mon, 2009-10-26 at 09:04 +0100, Holger Schurig wrote:
> > How much does mesh actually get used? AFAICS it's a
> > OLPC-specific one off.
>
> A good question, I don't know no-one that uses mesh outside of
> OLPC.
Nobody uses the custom libertas mesh stuff outside OLPC. I tend to look
at it as just not being a dick, subject to the limitations of testing
ability. Obviously OLPC are the only ones who can do in-depth testing
of mesh-related changes since those of us outside OLPC only have a few
OLPCs/dongles to mesh together.
>
> > So unless OLPC people come up and fix it why do people even
> > bother with it?
>
> In some way the OLPC people won't be bothered, they don't
> follow linux-git or linux-wireless, they are stuck to some
> old kernel (2.6.25 AFAIK). So they don't even notice :-)
Actually untrue; the *shipping* products are still at 2.6.25, but there
are fairly recent kernel trees, especially for the G1.5 machines (which
admittedly don't have the mesh capability anyway, but they do use the
Libertas sd8686).
> However, they need MESH, so if I now rip MESH out completely
> just because I change some configuration API, that would
> bring more burden to them.
Yeah, I don't think it's normal practice in kernel drivers to just rip
something out that we know people are using, we at least put in a modest
amount of effort to not break it completely. At least basic sanity
testing of mesh start/stop, and if possible, meshing two machines
together with static IP and making sure they can ping each other. More
extensive testing needs to be done by the organization set up for that.
Dan
^ permalink raw reply
* Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211
From: Dan Williams @ 2009-10-26 20:12 UTC (permalink / raw)
To: Holger Schurig; +Cc: Johannes Berg, linux-wireless, John Linville
In-Reply-To: <200910260859.39002.hs4233@mail.mn-solutions.de>
On Mon, 2009-10-26 at 08:59 +0100, Holger Schurig wrote:
> > > Well if you want to push the mesh wext bits through to cfg80211
> > > (temporarily) you wouldn't even need to depend on WEXT. I'd prefer,
> > > however, to not do this, and just use the cfg80211 wext handlers in
> > > libertas and depend on WEXT for now.
> >
> > Yeah, I think it's best to handle the mesh WEXT ioctls separately for
> > now. There are really only 4 of them (get/set SSID, set channel, get
> > mode) that matter for mesh. The rest of the ioctls that the mesh
> > interface supports get redirected to the cfg80211 handlers because they
> > aren't specific to mesh.
>
> We can reduce this to 3, because get/set channel could
> simply go via cfg80211.
>
> I'm unsure if we still need an GIWRANGE for mesh, but probably not.
Hmm, probably not. I think everything is the same between the mesh
interface and STA here, but not sure.
In any case, the code for the mesh channel change was different than the
code for the STA channel change, we have to be a bit careful here. The
sequences were:
STA:
1) get current channel #
2) issue a MESH_STOP command with the old channel
3) change the channel
4) resend WEP keys to firmware if any
5) restart adhoc if adhoc is enabled
mesh:
1) if STA is active and in infrastructure, deauth from AP
2) if STA is active and in adhoc, issue ADHOC_STOP
3) issue MESH_START with new channel
There are a few holes in the current implementation since desired
behavior is somewhat undefined; for example, if you change the mesh
channel, should an active adhoc network on the STA interface *restart*
on the new channel, or should the adhoc network on the old channel just
be torn down? If you change the mesh channel and the STA interface is
associated to an AP, should the STA interface try to re-associate to
that SSID on the new channel, or should it just stop?
In the end, we decided to keep it simple and require userspace to know a
bit about what was going on, which is reasonable, and thus if userspace
makes the choice to change mesh channel, userspace would also be
responsible for figuring out what happens with the STA interface next.
Dan
>
> Dan, you once said that you converted the MESH firmware
> calls to new style commands. Do you have those around? Maybe
> I can re-work them if they don't apply anymore.
>
^ permalink raw reply
* Re: libertas sdio firmware
From: Dan Williams @ 2009-10-26 20:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: Andrey Yurovsky, linux-wireless
In-Reply-To: <1256541398.28230.2.camel@johannes.local>
On Mon, 2009-10-26 at 08:16 +0100, Johannes Berg wrote:
> Hi,
>
> Was just looking at the libertas driver and noticed that the SPI part
> loads firmware as such:
>
> snprintf(helper_fw, IF_SPI_FW_NAME_MAX, "libertas/gspi%d_hlp.bin", ...
> etc.
>
> while the SDIO part just uses
> ret = request_firmware(&fw, card->helper, &card->func->dev);
>
> which ends up requesting sd8686_helper.bin instead of
> libertas/sd8686_helper.bin, as far as I can tell. That means the
> linux-firmware git repo won't work out of the box, I think?
Correct. I stuffed all the firmware into the git repo that I could
find, but because I didn't quite get around to doing firmware name
fallbacks in the driver (so we don't break existing installs) the driver
hasn't been updated yet.
I'd like to do a couple fallbacks actually; something like a priority
ordering of [<old name>, libertas/sd8686_helper_v9.bin,
libertas/sd8686_helper_v8.bin] so that we can use either v8 and v9
firmware if we need to; not all the v9 functionality has been added yet.
v10 is out there too but I haven't seen it in the wild yet.
Dan
^ permalink raw reply
* Re: TL-WN721N
From: John W. Linville @ 2009-10-26 19:51 UTC (permalink / raw)
To: Azhar; +Cc: linux-wireless
In-Reply-To: <loom.20091018T103209-571@post.gmane.org>
On Sun, Oct 18, 2009 at 08:33:46AM +0000, Azhar wrote:
> John W. Linville <linville@...> writes:
>
> >
> > On Thu, Oct 15, 2009 at 02:20:52PM +0000, Azhar wrote:
> > > Hi all,
> > >
> > > I am looking for drivers of TL-WN721N (for linux)...i have been going through
> > > pages aand pages of documentation....but every other link seems to route
> > > here...i would really appreciate if you could guide me
> > >
> > > Thanks
> > >
> > > Azhar
> >
> > Is it PCI? USB? The output of lspci or lsusb would be helpful
> > to know. Of course, in most cases you distribution would have the
> > driver auto-loaded for you if it was supported at all...
> >
> > John
>
> ndiswrapper -l
>
> WARNING: All config files need .conf: /etc/modprobe.d/ndiswrapper, it will be
> ignored in a future release.
> WARNING: All config files need .conf: /etc/modprobe.d/blacklist, it will be
> ignored in a future release.
> netathur : driver installed
> device (0CF3:9271) present
>
>
> lsusb
>
> Bus 001 Device 003: ID 0cf3:9271 Atheros Communications, Inc.
I suspect you should try a wireless-testing kernel or a bleeding-edge
wireless-compat package.
Hth!
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-rc5-git3: Reported regressions 2.6.30 -> 2.6.31
From: John W. Linville @ 2009-10-26 19:48 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <G2WU8XrUVpF.A.lxF.Ref5KB@chimera>
Several wireless ones...
On Mon, Oct 26, 2009 at 08:26:08PM +0100, Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14417
> Subject : [Regression] Wireless driver iwlagn+iwlcore doesn't work after resume (needs reloading)
> Submitter : Eddy Petrișor <eddy.petrisor+linbug@gmail.com>
> Date : 2009-10-16 11:07 (11 days old)
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14402
> Subject : Atheros ath9k module is not working with 2.6.31.1 on an Acer Extensa 7630EZ
> Submitter : Bernhard <berndl81@gmx.at>
> Date : 2009-10-14 11:17 (13 days old)
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14400
> Subject : disable/enable wlan broken with ath5k
> Submitter : Daniel Bumke <danielbumke@gmail.com>
> Date : 2009-10-13 12:35 (14 days old)
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14267
> Subject : Disassociating atheros wlan
> Submitter : Kristoffer Ericson <kristoffer.ericson@gmail.com>
> Date : 2009-09-24 10:16 (33 days old)
> References : http://marc.info/?l=linux-kernel&m=125378723723384&w=4
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14248
> Subject : 2.6.31 wireless: WARNING: at net/wireless/ibss.c:34
> Submitter : Jurriaan <thunder8@xs4all.nl>
> Date : 2009-09-13 7:32 (44 days old)
> References : http://marc.info/?l=linux-kernel&m=125282721113553&w=4
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14181
> Subject : b43 causes panic at ifconfig down / shutdown
> Submitter : Jeremy Huddleston <jeremyhu@freedesktop.org>
> Date : 2009-09-15 18:34 (42 days old)
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14141
> Subject : order 2 page allocation failures in iwlagn
> Submitter : Frans Pop <elendil@planet.nl>
> Date : 2009-09-06 7:40 (51 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ff05b2b4eac2e63d345fc731ea151a060247f53
> References : http://marc.info/?l=linux-kernel&m=125222287419691&w=4
> http://lkml.org/lkml/2009/10/2/86
> http://lkml.org/lkml/2009/10/5/24
> http://lkml.indiana.edu/hypermail/linux/kernel/0910.1/01395.html
> Handled-By : Pekka Enberg <penberg@cs.helsinki.fi>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13943
> Subject : WARNING: at net/mac80211/mlme.c:2292 with ath5k
> Submitter : Fabio Comolli <fabio.comolli@gmail.com>
> Date : 2009-08-06 20:15 (82 days old)
> References : http://marc.info/?l=linux-kernel&m=124958978600600&w=4
--
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: Questions about cfg80211's cfg80211_connect_params->crypto settings
From: Dan Williams @ 2009-10-26 19:57 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless
In-Reply-To: <200910260947.48365.hs4233@mail.mn-solutions.de>
On Mon, 2009-10-26 at 09:47 +0100, Holger Schurig wrote:
> Hi,
>
> I'm a but confused about what fields in "struct
> cfg80211_connect_params" (now abbreviated as sme->)
> are relevant for me.
>
>
> sme->private
> ------------
> Right now, my lbs_cfg_connect() code just tests
> sme->crypto.cipher_group. It doesn't check or use sme->privacy.
>
> and sme-> crypto.wpa_versions like they are redundant. Is this
> correct?
>
> Empirical it migth be correct, because I can successfully connect
> to APs, but if "privacy" is redundant, should I prepare a patch
> to get rid of it?
>
> What is this? And how should my driver react to it's settings?
>
>
>
> sme->crypto.wpa_versions
> ------------------------
> Again I seems to be ok to ignore this variable and just check
> sme->crypto.cipher_group. In practice this seems to work, but is
> it correct?
>
> What is this, what is the intented use of it? May I prepare a
> patch to get rid of it?
Wouldn't this be used to force WPA2/RSN? THere are APs out there where
you can select WPA+CCMP and WPA2+TKIP, which wouldn't be apparent from
just cipher_group, right? If userspace really does want you to only
connect to a WPA2-capable AP and ignore WPA1+TKIP and WPA1+CCMP, then
this field is the only way to indicate that.
In libertas, this would all happen during the scan-before-connect when
we try to find the BSSID of the AP we want to associate with. The WEXT
stuff had a bunch of ugly checks to match up an AP in the scan list with
the parameters of the connect request, and that's where I'd expect this
to be used?
Dan
>
>
> sme->crypto.n_ciphers_pairwise, sme->crypto.ciphers_pairwise
> ------------------------------------------------------------
> The same for sme->crypto.n_ciphers_pairwise. It is always 0 zero
> for the WEP case and always 1 for the WPA/WPA2 case, so isn't it
> redundant either? lbs_cfg_connect() ignores this, maybe it's
> not needed at .connect() time anyway?
>
> But what is it really, what is the intended use?
>
>
>
> sme->crypto.n_akm_suites, sme->crypto.akm_suites
> ------------------------------------------------
> In cfg80211.h, the kdoc help text for sme->crypo.akm_suites is
> just "AKM suites" or "number of AKM suites", which keeps me as
> confused as before.
>
> What is this? And how should my driver react to it's settings?
>
>
^ permalink raw reply
* Re: 2.6.32-rc5-git3: Reported regressions from 2.6.31
From: Michael Buesch @ 2009-10-26 19:37 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Christian Casteyde, Johannes Berg
In-Reply-To: <200910262011.22950.mb@bu3sch.de>
On Monday 26 October 2009 20:11:20 Michael Buesch wrote:
> On Monday 26 October 2009 19:59:02 John W. Linville wrote:
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14277
> > > Subject : Caught 8-bit read from freed memory in b43 driver at association
> > > Submitter : Christian Casteyde <casteyde.christian@free.fr>
> > > Date : 2009-09-30 18:06 (27 days old)
>
> Does this still trigger with a recent kernel (and thus recent memory debugging).
> I'm still not convinced that this is a wireless bug.
>
Ok, it just turns out this actually is a driver bug.
Thanks to Johannes Berg for tracking it down.
I think it's caused by the DMA bouncebuffer stuff that does not copy the skb->cb
and does not adjust the "tx-info" pointer.
I wonder why this didn't blow up easlier, because this bug is there since mac80211
switched to using the CB.
Here's a completely untested patch.
---
drivers/net/wireless/b43/dma.c | 2 ++
1 file changed, 2 insertions(+)
--- wireless-testing.orig/drivers/net/wireless/b43/dma.c
+++ wireless-testing/drivers/net/wireless/b43/dma.c
@@ -1224,6 +1224,8 @@ static int dma_tx_fragment(struct b43_dm
}
memcpy(skb_put(bounce_skb, skb->len), skb->data, skb->len);
+ memcpy(bounce_skb->cb, skb->cb, sizeof(skb->cb));
+ info = IEEE80211_SKB_CB(bounce_skb);
dev_kfree_skb_any(skb);
skb = bounce_skb;
meta->skb = skb;
--
Greetings, Michael.
^ permalink raw reply
* 2.6.32-rc5-git3: Reported regressions 2.6.30 -> 2.6.31
From: Rafael J. Wysocki @ 2009-10-26 19:26 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions introduced between 2.6.30 and
2.6.31, for which there are no fixes in the mainline I know of. If any of them
have been fixed already, please let me know.
If you know of any other unresolved regressions introduced between 2.6.30
and 2.6.31, please let me know either and I'll add them to the list.
Also, please let me know if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2009-10-26 170 37 32
2009-10-12 161 45 35
2009-10-02 151 49 42
2009-09-06 123 34 27
2009-08-26 108 33 26
2009-08-20 102 32 29
2009-08-10 89 27 24
2009-08-02 76 36 28
2009-07-27 70 51 43
2009-07-07 35 25 21
2009-06-29 22 22 15
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14476
Subject : Unable to handle kernel paging request in nfs_write_mapping
Submitter : Stephan von Krawczynski <skraw@ithnet.com>
Date : 2009-10-14 9:53 (13 days old)
References : http://marc.info/?l=linux-kernel&m=125551421405656&w=4
Handled-By : Trond Myklebust <Trond.Myklebust@netapp.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14474
Subject : restorecond going crazy on 2.6.31.4 - inotify regression?
Submitter : Robert Hancock <hancockrwd@gmail.com>
Date : 2009-10-16 0:03 (11 days old)
References : http://marc.info/?l=linux-kernel&m=125565159520489&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14446
Subject : battery status info broken/useless in 2.6.32-rc3 - MSI PR200 (possibly others, too)
Submitter : Eddy Petrișor <eddy.petrisor+linbug@gmail.com>
Date : 2009-10-20 08:25 (7 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14417
Subject : [Regression] Wireless driver iwlagn+iwlcore doesn't work after resume (needs reloading)
Submitter : Eddy Petrișor <eddy.petrisor+linbug@gmail.com>
Date : 2009-10-16 11:07 (11 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14402
Subject : Atheros ath9k module is not working with 2.6.31.1 on an Acer Extensa 7630EZ
Submitter : Bernhard <berndl81@gmx.at>
Date : 2009-10-14 11:17 (13 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14400
Subject : disable/enable wlan broken with ath5k
Submitter : Daniel Bumke <danielbumke@gmail.com>
Date : 2009-10-13 12:35 (14 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14391
Subject : use after free of struct powernow_k8_data
Submitter : Michal Schmidt <mschmidt@redhat.com>
Date : 2009-09-24 14:51 (33 days old)
References : http://marc.info/?l=linux-kernel&m=125380383515615&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14388
Subject : keyboard under X with 2.6.31
Submitter : Frédéric L. W. Meunier <fredlwm@gmail.com>
Date : 2009-10-07 20:19 (20 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e043e42bdb66885b3ac10d27a01ccb9972e2b0a3
References : http://marc.info/?l=linux-kernel&m=125494753228217&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14385
Subject : DMAR regression in 2.6.31 leads to ext4 corruption?
Submitter : Andy Isaacson <adi@hexapodia.org>
Date : 2009-10-08 23:56 (19 days old)
References : http://marc.info/?l=linux-kernel&m=125504643703877&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14294
Subject : kernel BUG at drivers/ide/ide-disk.c:187
Submitter : Santiago Garcia Mantinan <manty@manty.net>
Date : 2009-09-30 11:05 (27 days old)
References : http://marc.info/?l=linux-kernel&m=125430926311466&w=4
Handled-By : David Miller <davem@davemloft.net>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14267
Subject : Disassociating atheros wlan
Submitter : Kristoffer Ericson <kristoffer.ericson@gmail.com>
Date : 2009-09-24 10:16 (33 days old)
References : http://marc.info/?l=linux-kernel&m=125378723723384&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14265
Subject : ifconfig: page allocation failure. order:5, mode:0x8020 w/ e100
Submitter : Karol Lewandowski <karol.k.lewandowski@gmail.com>
Date : 2009-09-15 12:05 (42 days old)
References : http://marc.info/?l=linux-kernel&m=125301636509517&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14257
Subject : Not able to boot on 32 bit System
Submitter : Rishikesh <risrajak@linux.vnet.ibm.com>
Date : 2009-09-21 15:25 (36 days old)
References : http://marc.info/?l=linux-kernel&m=125354604314412&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14256
Subject : kernel BUG at fs/ext3/super.c:435
Submitter : Mikael Pettersson <mikpe@it.uu.se>
Date : 2009-09-21 7:29 (36 days old)
References : http://marc.info/?l=linux-kernel&m=125351816109264&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14252
Subject : WARNING: at include/linux/skbuff.h:1382 w/ e1000
Submitter : Stephan von Krawczynski <skraw@ithnet.com>
Date : 2009-09-20 11:26 (37 days old)
References : http://marc.info/?l=linux-kernel&m=125344599006033&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14249
Subject : BUG: oops in gss_validate on 2.6.31
Submitter : Bastian Blank <bastian@waldi.eu.org>
Date : 2009-09-16 10:29 (41 days old)
References : http://marc.info/?l=linux-kernel&m=125309700417283&w=4
Handled-By : Trond Myklebust <trond.myklebust@fys.uio.no>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14248
Subject : 2.6.31 wireless: WARNING: at net/wireless/ibss.c:34
Submitter : Jurriaan <thunder8@xs4all.nl>
Date : 2009-09-13 7:32 (44 days old)
References : http://marc.info/?l=linux-kernel&m=125282721113553&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14204
Subject : MCE prevent booting on my computer(pentium iii @500Mhz)
Submitter : GNUtoo <GNUtoo@no-log.org>
Date : 2009-09-21 20:36 (36 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14181
Subject : b43 causes panic at ifconfig down / shutdown
Submitter : Jeremy Huddleston <jeremyhu@freedesktop.org>
Date : 2009-09-15 18:34 (42 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14157
Subject : end_request: I/O error, dev cciss/cXdX, sector 0
Submitter : <jiri.harcarik@gmail.com>
Date : 2009-09-11 07:42 (46 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14141
Subject : order 2 page allocation failures in iwlagn
Submitter : Frans Pop <elendil@planet.nl>
Date : 2009-09-06 7:40 (51 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ff05b2b4eac2e63d345fc731ea151a060247f53
References : http://marc.info/?l=linux-kernel&m=125222287419691&w=4
http://lkml.org/lkml/2009/10/2/86
http://lkml.org/lkml/2009/10/5/24
http://lkml.indiana.edu/hypermail/linux/kernel/0910.1/01395.html
Handled-By : Pekka Enberg <penberg@cs.helsinki.fi>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14114
Subject : Tuning a saa7134 based card is broken in kernel 2.6.31-rc7
Submitter : Tsvety Petrov <Tsvetoslav.Petrov@itron.com>
Date : 2009-09-03 21:06 (54 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14090
Subject : WARNING: at fs/notify/inotify/inotify_user.c:394
Submitter : Joerg Platte <bugzilla@jako.ping.de>
Date : 2009-08-30 15:21 (58 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14058
Subject : Oops in fsnotify
Submitter : Grant Wilson <grant.wilson@zen.co.uk>
Date : 2009-08-20 15:48 (68 days old)
References : http://marc.info/?l=linux-kernel&m=125078450923133&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13987
Subject : Received NMI interrupt at resume
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Date : 2009-08-15 07:55 (73 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f41f3f373dd72344c65d801d6381fe83ef3a2c54
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13943
Subject : WARNING: at net/mac80211/mlme.c:2292 with ath5k
Submitter : Fabio Comolli <fabio.comolli@gmail.com>
Date : 2009-08-06 20:15 (82 days old)
References : http://marc.info/?l=linux-kernel&m=124958978600600&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13941
Subject : x86 Geode issue
Submitter : Martin-Éric Racine <q-funk@iki.fi>
Date : 2009-08-03 12:58 (85 days old)
References : http://marc.info/?l=linux-kernel&m=124930434732481&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13906
Subject : Huawei E169 GPRS connection causes Ooops
Submitter : Clemens Eisserer <linuxhippy@gmail.com>
Date : 2009-08-04 09:02 (84 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13836
Subject : suspend script fails, related to stdout?
Submitter : Tomas M. <tmezzadra@gmail.com>
Date : 2009-07-17 21:24 (102 days old)
References : http://marc.info/?l=linux-kernel&m=124785853811667&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13809
Subject : oprofile: possible circular locking dependency detected
Submitter : Jerome Marchand <jmarchan@redhat.com>
Date : 2009-07-22 13:35 (97 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13733
Subject : 2.6.31-rc2: irq 16: nobody cared
Submitter : Niel Lambrechts <niel.lambrechts@gmail.com>
Date : 2009-07-06 18:32 (113 days old)
References : http://marc.info/?l=linux-kernel&m=124690524027166&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13645
Subject : NULL pointer dereference at (null) (level2_spare_pgt)
Submitter : poornima nayak <mpnayak@linux.vnet.ibm.com>
Date : 2009-06-17 17:56 (132 days old)
References : http://lkml.org/lkml/2009/6/17/194
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14340
Subject : speedstep-ich driver not working in 2.6.31
Submitter : <dave.mueller@gmx.ch>
Date : 2009-10-07 08:16 (20 days old)
Handled-By : Eric Pielbug <e.a.b.piel@tudelft.nl>
Rusty Russell <rusty@rustcorp.com.au>
Patch : http://patchwork.kernel.org/patch/54672/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14258
Subject : Memory leak in SCSI initialization
Submitter : Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date : 2009-09-22 4:18 (35 days old)
References : http://marc.info/?l=linux-kernel&m=125359311312243&w=4
Handled-By : Michael Ellerman <michael@ellerman.id.au>
James Bottomley <James.Bottomley@suse.de>
Patch : http://patchwork.kernel.org/patch/51412/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14253
Subject : Oops in driversbasefirmware_class
Submitter : Lars Ericsson <Lars_Ericsson@telia.com>
Date : 2009-09-16 20:44 (41 days old)
References : http://lkml.org/lkml/2009/9/16/461
Handled-By : Frederik Deweerdt <frederik.deweerdt@xprog.eu>
Patch : http://patchwork.kernel.org/patch/49914/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14137
Subject : usb console regressions
Submitter : Jason Wessel <jason.wessel@windriver.com>
Date : 2009-09-05 21:08 (52 days old)
References : http://marc.info/?l=linux-kernel&m=125218501310512&w=4
Handled-By : Jason Wessel <jason.wessel@windriver.com>
Patch : http://patchwork.kernel.org/patch/45953/
http://patchwork.kernel.org/patch/45952/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14017
Subject : _end symbol missing from Symbol.map
Submitter : Hannes Reinecke <hare@suse.de>
Date : 2009-08-13 6:45 (75 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=091e52c3551d3031343df24b573b770b4c6c72b6
References : http://marc.info/?l=linux-kernel&m=125014649102253&w=4
Handled-By : Hannes Reinecke <hare@suse.de>
Patch : http://marc.info/?l=linux-kernel&m=125014649102253&w=4
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.30 and 2.6.31, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=13615
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
^ permalink raw reply
* [PATCH] MAINTAINERS: rt2x00 list is moderated
From: Bartlomiej Zolnierkiewicz @ 2009-10-26 19:14 UTC (permalink / raw)
To: Andrew Morton; +Cc: users, linux-wireless, linux-kernel
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] MAINTAINERS: rt2x00 list is moderated
Cc: users@rt2x00.serialmonkey.com
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/MAINTAINERS
===================================================================
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4325,7 +4325,7 @@ F: drivers/video/aty/aty128fb.c
RALINK RT2X00 WIRELESS LAN DRIVER
P: rt2x00 project
L: linux-wireless@vger.kernel.org
-L: users@rt2x00.serialmonkey.com
+L: users@rt2x00.serialmonkey.com (moderated for non-subscribers)
W: http://rt2x00.serialmonkey.com/
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ivd/rt2x00.git
^ permalink raw reply
* Re: 2.6.32-rc5-git3: Reported regressions from 2.6.31
From: Michael Buesch @ 2009-10-26 19:11 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Christian Casteyde
In-Reply-To: <20091026185901.GH2792@tuxdriver.com>
On Monday 26 October 2009 19:59:02 John W. Linville wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14277
> > Subject : Caught 8-bit read from freed memory in b43 driver at association
> > Submitter : Christian Casteyde <casteyde.christian@free.fr>
> > Date : 2009-09-30 18:06 (27 days old)
Does this still trigger with a recent kernel (and thus recent memory debugging).
I'm still not convinced that this is a wireless bug.
--
Greetings, Michael.
^ permalink raw reply
* Re: 2.6.32-rc5-git3: Reported regressions from 2.6.31
From: John W. Linville @ 2009-10-26 18:59 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <Sj-rRjx6TwF.A.djE.vqe5KB@chimera>
Wireless ones...
On Mon, Oct 26, 2009 at 07:45:48PM +0100, Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14381
> Subject : iwlagn lost connection after s2ram (with warnings)
> Submitter : Carlos R. Mafra <crmafra2@gmail.com>
> Date : 2009-10-07 14:20 (20 days old)
> References : http://marc.info/?l=linux-kernel&m=125492569119947&w=4
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14372
> Subject : ath5k wireless not working after suspend-resume - eeepc
> Submitter : Fabio Comolli <fabio.comolli@gmail.com>
> Date : 2009-10-03 15:36 (24 days old)
> References : http://lkml.org/lkml/2009/10/3/91
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14352
> Subject : WARNING: at net/mac80211/scan.c:267
> Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
> Date : 2009-10-08 00:30 (19 days old)
> References : http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2089#c7
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14299
> Subject : oops in wireless, iwl3945 related?
> Submitter : Pavel Machek <pavel@ucw.cz>
> Date : 2009-09-29 17:12 (28 days old)
> References : http://marc.info/?l=linux-kernel&m=125424439725743&w=4
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14277
> Subject : Caught 8-bit read from freed memory in b43 driver at association
> Submitter : Christian Casteyde <casteyde.christian@free.fr>
> Date : 2009-09-30 18:06 (27 days old)
--
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
* 2.6.32-rc5-git3: Reported regressions from 2.6.31
From: Rafael J. Wysocki @ 2009-10-26 18:45 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Adrian Bunk, Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions from 2.6.31, for which there
are no fixes in the mainline I know of. If any of them have been fixed already,
please let me know.
If you know of any other unresolved regressions from 2.6.31, please let me know
either and I'll add them to the list. Also, please let me know if any of the
entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2009-10-26 66 42 37
2009-10-12 48 31 27
2009-10-02 22 15 9
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14485
Subject : System lockup running "cat /sys/kernel/debug/dri/0/i915_regs"
Submitter : Miles Lane <miles.lane@gmail.com>
Date : 2009-10-26 4:00 (1 days old)
References : http://marc.info/?l=linux-kernel&m=125652968117713&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14484
Subject : no video output after suspend
Submitter : Riccardo Magliocchetti <riccardo.magliocchetti@gmail.com>
Date : 2009-10-25 20:57 (2 days old)
References : http://marc.info/?l=linux-kernel&m=125650430123713&w=4
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14483
Subject : WARNING: at drivers/base/sys.c:353 __sysdev_resume+0x54/0xca()
Submitter : Justin Mattock <justinmattock@gmail.com>
Date : 2009-10-25 19:58 (2 days old)
References : http://marc.info/?l=linux-kernel&m=125650070420168&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14482
Subject : kernel BUG at fs/dcache.c:670 +lvm +md +ext3
Submitter : Alexander Clouter <alex@digriz.org.uk>
Date : 2009-10-23 10:30 (4 days old)
References : http://lkml.org/lkml/2009/10/23/50
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14481
Subject : umount blocked for more than 120 seconds after USB drive removal
Submitter : Robert Hancock <hancockrwd@gmail.com>
Date : 2009-10-21 5:26 (6 days old)
References : http://marc.info/?l=linux-kernel&m=125610280532245&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14479
Subject : nfs oops
Submitter : Egon Alter <egon.alter@gmx.net>
Date : 2009-10-19 16:03 (8 days old)
References : http://marc.info/?l=linux-kernel&m=125596822630410&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14477
Subject : possible circular locking dependency in ISDN PPP
Submitter : Tilman Schmidt <tilman@imap.cc>
Date : 2009-10-18 22:16 (9 days old)
References : http://marc.info/?l=linux-kernel&m=125590423416087&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14473
Subject : ATA related kernel warning after resume
Submitter : Tino Keitel <tino.keitel@tikei.de>
Date : 2009-10-14 6:55 (13 days old)
References : http://marc.info/?l=linux-kernel&m=125550466624678&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14472
Subject : EXT4 corruption
Submitter : Shawn Starr <shawn.starr@rogers.com>
Date : 2009-10-13 2:07 (14 days old)
References : http://marc.info/?l=linux-kernel&m=125539997508256&w=4
Handled-By : Theodore Tso <tytso@mit.edu>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14467
Subject : Linker errors on ia64 with NR_CPUS=4096
Submitter : Jeff Mahoney <jeffm@suse.com>
Date : 2009-10-18 22:28 (9 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=34d76c41554a05425613d16efebb3069c4c545f0
References : http://marc.info/?l=linux-kernel&m=125590493116720&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14466
Subject : EFI boot on x86 fails in .32
Submitter : Matthew Garrett <mjg59@srcf.ucam.org>
Date : 2009-10-20 0:34 (7 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7bd867dfb4e0357e06a3211ab2bd0e714110def3
References : http://marc.info/?l=linux-kernel&m=125599887314290&w=4
Handled-By : Feng Tang <feng.tang@intel.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14442
Subject : resume after hibernate: /dev/sdb drops and returns as /dev/sde
Submitter : Duncan <1i5t5.duncan@cox.net>
Date : 2009-10-20 01:52 (7 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14430
Subject : sync() hangs in bdi_sched_wait
Submitter : Petr Vandrovec <petr@vandrovec.name>
Date : 2009-10-17 19:14 (10 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14415
Subject : Reboot on kernel load
Submitter : Brian Beardall <brian@rapsure.net>
Date : 2009-10-15 23:57 (12 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14408
Subject : sysctl check failed
Submitter : Peter Teoh <htmldeveloper@gmail.com>
Date : 2009-10-14 22:59 (13 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14406
Subject : uvcvideo stopped work on Toshiba
Submitter : okias <d.okias@gmail.com>
Date : 2009-10-14 19:08 (13 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14390
Subject : "bind" a device to a driver doesn't not work anymore
Submitter : Éric Piel <Eric.Piel@tremplin-utc.net>
Date : 2009-10-11 0:04 (16 days old)
References : http://marc.info/?l=linux-kernel&m=125521979921241&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14389
Subject : Build system issue
Submitter : Peter Zijlstra <peterz@infradead.org>
Date : 2009-10-09 8:58 (18 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=575543347b5baed0ca927cb90ba8807396fe9cc9
References : http://marc.info/?l=linux-kernel&m=125507914909152&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14387
Subject : deadlock with fallocate
Submitter : Thomas Neumann <tneumann@users.sourceforge.net>
Date : 2009-10-07 3:00 (20 days old)
References : http://marc.info/?l=linux-kernel&m=125488495526471&w=4
Handled-By : Christoph Hellwig <hch@lst.de>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14384
Subject : tbench regression with 2.6.32-rc1
Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date : 2009-10-09 9:51 (18 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59abf02644c45f1591e1374ee7bb45dc757fcb88
References : http://marc.info/?l=linux-kernel&m=125508216713138&w=4
Handled-By : Peter Zijlstra <a.p.zijlstra@chello.nl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14383
Subject : hackbench regression with kernel 2.6.32-rc1
Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date : 2009-10-09 9:19 (18 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=29cd8bae396583a2ee9a3340db8c5102acf9f6fd
References : http://marc.info/?l=linux-kernel&m=125508007510274&w=4
Handled-By : Peter Zijlstra <a.p.zijlstra@chello.nl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14381
Subject : iwlagn lost connection after s2ram (with warnings)
Submitter : Carlos R. Mafra <crmafra2@gmail.com>
Date : 2009-10-07 14:20 (20 days old)
References : http://marc.info/?l=linux-kernel&m=125492569119947&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14378
Subject : Problems with net/core/skbuff.c
Submitter : Massimo Cetra <mcetra@navynet.it>
Date : 2009-10-08 14:51 (19 days old)
References : http://marc.info/?l=linux-kernel&m=125501488220358&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14376
Subject : Kernel NULL pointer dereference/ kvm subsystem
Submitter : Don Dupuis <dondster@gmail.com>
Date : 2009-10-06 14:38 (21 days old)
References : http://marc.info/?l=linux-kernel&m=125484025021737&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14373
Subject : Task blocked for more than 120 seconds
Submitter : Zeno Davatz <zdavatz@gmail.com>
Date : 2009-10-02 10:16 (25 days old)
References : http://marc.info/?l=linux-kernel&m=125447858618412&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14372
Subject : ath5k wireless not working after suspend-resume - eeepc
Submitter : Fabio Comolli <fabio.comolli@gmail.com>
Date : 2009-10-03 15:36 (24 days old)
References : http://lkml.org/lkml/2009/10/3/91
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14355
Subject : USB serial regression after 2.6.31.1 with Huawei E169 GSM modem
Submitter : Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date : 2009-10-10 03:07 (17 days old)
References : http://marc.info/?l=linux-kernel&m=125513456327542&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14354
Subject : Bad corruption with 2.6.32-rc1 and upwards
Submitter : Holger Freyther <zecke@selfish.org>
Date : 2009-10-09 15:42 (18 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14353
Subject : BUG: sleeping function called from invalid context at kernel/mutex.c:280
Submitter : Miles Lane <miles.lane@gmail.com>
Date : 2009-10-05 3:39 (22 days old)
References : http://marc.info/?l=linux-kernel&m=125471432208671&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14352
Subject : WARNING: at net/mac80211/scan.c:267
Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
Date : 2009-10-08 00:30 (19 days old)
References : http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2089#c7
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14334
Subject : pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
Submitter : Jose Marino <braket@hotmail.com>
Date : 2009-10-06 15:44 (21 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14331
Subject : Radeon XPRESS 200M: System hang with radeon DRI and Fedora 10 userspace unless DRI=off
Submitter : Alex Villacis Lasso <avillaci@ceibo.fiec.espol.edu.ec>
Date : 2009-10-06 00:29 (21 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14299
Subject : oops in wireless, iwl3945 related?
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2009-09-29 17:12 (28 days old)
References : http://marc.info/?l=linux-kernel&m=125424439725743&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14298
Subject : warning at manage.c:361 (set_irq_wake), matrix-keypad related?
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2009-09-30 20:07 (27 days old)
References : http://marc.info/?l=linux-kernel&m=125434130703538&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14297
Subject : console resume broken since ba15ab0e8d
Submitter : Sascha Hauer <s.hauer@pengutronix.de>
Date : 2009-09-30 15:11 (27 days old)
References : http://marc.info/?l=linux-kernel&m=125432349404060&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14296
Subject : spitz boots but suspend/resume is broken
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2009-09-30 12:06 (27 days old)
References : http://marc.info/?l=linux-kernel&m=125431244516449&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14277
Subject : Caught 8-bit read from freed memory in b43 driver at association
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Date : 2009-09-30 18:06 (27 days old)
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14480
Subject : 2 locks held by cat -- running "find /sys | head -c 4" --> system hang
Submitter : Miles Lane <miles.lane@gmail.com>
Date : 2009-10-20 16:11 (7 days old)
References : http://marc.info/?l=linux-kernel&m=125605511728088&w=4
Handled-By : Chris Wilson <chris@chris-wilson.co.uk>
Patch : http://patchwork.kernel.org/patch/54974/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14380
Subject : Video tearing/glitching with T400 laptops
Submitter : Theodore Ts'o <tytso@mit.edu>
Date : 2009-10-02 22:40 (25 days old)
References : http://marc.info/?l=linux-kernel&m=125452324520623&w=4
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
Patch : http://marc.info/?l=linux-kernel&m=125591495325000&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14379
Subject : ACPI Warning for _SB_.BAT0._BIF: Converted Buffer to expected String
Submitter : Justin Mattock <justinmattock@gmail.com>
Date : 2009-10-08 21:46 (19 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d9adc2e031bd22d5d9607a53a8d3b30e0b675f39
References : http://marc.info/?l=linux-kernel&m=125504031328941&w=4
Handled-By : Alexey Starikovskiy <astarikovskiy@suse.de>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=23347
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14375
Subject : Intel(R) I/OAT DMA Engine init failed
Submitter : Alexander Beregalov <a.beregalov@gmail.com>
Date : 2009-10-02 9:46 (25 days old)
References : http://marc.info/?l=linux-kernel&m=125447680016160&w=4
Handled-By : Dan Williams <dan.j.williams@intel.com>
Patch : http://patchwork.kernel.org/patch/51808/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14302
Subject : Kernel panic on i386 machine when booting with profile=2
Submitter : Shi, Alex <alex.shi@intel.com>
Date : 2009-10-01 3:23 (26 days old)
References : http://marc.info/?l=linux-kernel&m=125436749607199&w=4
Handled-By : Alex Shi <alex.shi@intel.com>
Patch : http://patchwork.kernel.org/patch/50813/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.31,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=14230
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
^ permalink raw reply
* Re: rtl8187: kernel oops when leds enabled
From: Larry Finger @ 2009-10-26 18:27 UTC (permalink / raw)
To: Richard Farina; +Cc: wireless
In-Reply-To: <4AE5CDCB.8090400@gmail.com>
Richard Farina wrote:
> Larry Finger wrote:
>> On 10/26/2009 10:17 AM, Richard Farina wrote:
>>
>>
>>> I'm honestly a little surprised that no one has bothered to reproduce
>>> this in the month since I reported it but maybe it is more unique to my
>>> setup than it seems.
>>>
>>
>> Your machine seems to be unique in that it happens most of the time.
>> It took more than 10 tries, but I finally got my copy of the
>> wireless-testing kernel to oops.
>>
>> I will be working on a patch.
>>
>>
> Excellent! Thanks for looking into it. I'll be as responsive as
> possible in testing any patches.
I finally got a full dump on my own machine. It is a kernel BUG from
"scheduling while atomic". That makes me think that the bug is not in
rtl8187, but that unplugging the RTL8187 module triggers a bug in the
kernel.
I'm currently building the latest git pull of Linus's tree to see if
the problem is still there. If so, I will post on LKML and make a
kernel bugzilla entry.
Larry
^ permalink raw reply
* Re: rtl8187: kernel oops when leds enabled
From: Hin-Tak Leung @ 2009-10-26 18:20 UTC (permalink / raw)
To: Richard Farina; +Cc: linux-wireless
In-Reply-To: <4AE5BD6C.2050303@gmail.com>
On Mon, Oct 26, 2009 at 3:17 PM, Richard Farina <sidhayn@gmail.com> wrote:
> I'm honestly a little surprised that no one has bothered to reproduce this
> in the month since I reported it but maybe it is more unique to my setup
> than it seems.
Yes, quite possibly. Mine is built-in and hooked up directly to the
laptop's motherboard (and cannot be unplugged!) so I am no use. Larry
is on it, I think. We appreciate the persistence...
Hin-Tak
^ permalink raw reply
* [RFC] ar9170: load firmware asynchronously
From: Johannes Berg @ 2009-10-26 17:43 UTC (permalink / raw)
To: linux-wireless; +Cc: Christian Lamparter, David Woodhouse, Dan Williams
This converts ar9170 to load firmware asynchronously
out of ->probe() and only register with mac80211 when
all firmware has been loaded successfully. If, on the
other hand, any firmware fails to load, it will now
unbind from the device.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
This ought to make it possible to build the driver
into the kernel and as long as your system boots
within 60 seconds it'll all just work.
This is how we need to load firmware for drivers that
require the firmware image to detect which features
to register to mac80211/cfg80211, but it's also useful
when no features depend on the firmware.
I've done ar9170 because I'm somewhat familiar with its
implementation. b43 should probably be converted to this
scheme since it actually has features that depend on the
firmware, and libertas_tf has the MAC addresss depending
on the firmware (well it needs the firmware to read it).
The only complication with this is that now the user is
mostly unaware they have a wireless device, they can only
find it via lsusb/lspci etc. if firmware loading fails,
or from kernel messages. And also manual binding in sysfs,
device re-plugging or module re-loading is required to
get the module to find the device after putting firmware
in place...
Still I think this is better than what we have now with
many drivers -- if firmware is missing you get network
interfaces etc. but cannot ever use them, and it's not
always entirely clear that is due to missing firmware.
drivers/net/wireless/ath/ar9170/ar9170.h | 1
drivers/net/wireless/ath/ar9170/main.c | 10 +
drivers/net/wireless/ath/ar9170/usb.c | 170 ++++++++++++++++++-------------
3 files changed, 111 insertions(+), 70 deletions(-)
--- wireless-testing.orig/drivers/net/wireless/ath/ar9170/usb.c 2009-10-26 16:45:12.000000000 +0100
+++ wireless-testing/drivers/net/wireless/ath/ar9170/usb.c 2009-10-26 18:29:17.000000000 +0100
@@ -578,43 +578,6 @@ static int ar9170_usb_upload(struct ar91
return 0;
}
-static int ar9170_usb_request_firmware(struct ar9170_usb *aru)
-{
- int err = 0;
-
- err = request_firmware(&aru->firmware, "ar9170.fw",
- &aru->udev->dev);
- if (!err) {
- aru->init_values = NULL;
- return 0;
- }
-
- if (aru->req_one_stage_fw) {
- dev_err(&aru->udev->dev, "ar9170.fw firmware file "
- "not found and is required for this device\n");
- return -EINVAL;
- }
-
- dev_err(&aru->udev->dev, "ar9170.fw firmware file "
- "not found, trying old firmware...\n");
-
- err = request_firmware(&aru->init_values, "ar9170-1.fw",
- &aru->udev->dev);
- if (err) {
- dev_err(&aru->udev->dev, "file with init values not found.\n");
- return err;
- }
-
- err = request_firmware(&aru->firmware, "ar9170-2.fw", &aru->udev->dev);
- if (err) {
- release_firmware(aru->init_values);
- dev_err(&aru->udev->dev, "firmware file not found.\n");
- return err;
- }
-
- return err;
-}
-
static int ar9170_usb_reset(struct ar9170_usb *aru)
{
int ret, lock = (aru->intf->condition != USB_INTERFACE_BINDING);
@@ -753,6 +716,103 @@ err_out:
return err;
}
+static void ar9170_usb_firmware_failed(struct ar9170_usb *aru)
+{
+ struct device *parent = aru->udev->dev.parent;
+
+ /* unbind anything failed */
+ if (parent)
+ down(&parent->sem);
+ device_release_driver(&aru->udev->dev);
+ if (parent)
+ up(&parent->sem);
+}
+
+static void ar9170_usb_firmware_finish(const struct firmware *fw, void *context)
+{
+ struct ar9170_usb *aru = context;
+ int err;
+
+ aru->firmware = fw;
+
+ if (!fw) {
+ dev_err(&aru->udev->dev, "firmware file not found.\n");
+ goto err_freefw;
+ }
+
+ err = ar9170_usb_init_device(aru);
+ if (err)
+ goto err_freefw;
+
+ err = ar9170_usb_open(&aru->common);
+ if (err)
+ goto err_unrx;
+
+ err = ar9170_register(&aru->common, &aru->udev->dev);
+
+ ar9170_usb_stop(&aru->common);
+ if (err)
+ goto err_unrx;
+
+ return;
+
+ err_unrx:
+ ar9170_usb_cancel_urbs(aru);
+
+ err_freefw:
+ ar9170_usb_firmware_failed(aru);
+}
+
+static void ar9170_usb_firmware_inits(const struct firmware *fw,
+ void *context)
+{
+ struct ar9170_usb *aru = context;
+ int err;
+
+ if (!fw) {
+ dev_err(&aru->udev->dev, "file with init values not found.\n");
+ ar9170_usb_firmware_failed(aru);
+ return;
+ }
+
+ aru->init_values = fw;
+
+ /* ok so we have the init values -- get code for two-stage */
+
+ err = request_firmware_nowait(THIS_MODULE, 1, "ar9170-2.fw",
+ &aru->udev->dev, GFP_KERNEL, aru,
+ ar9170_usb_firmware_finish);
+ if (err)
+ ar9170_usb_firmware_failed(aru);
+}
+
+static void ar9170_usb_firmware_step2(const struct firmware *fw, void *context)
+{
+ struct ar9170_usb *aru = context;
+ int err;
+
+ if (fw) {
+ ar9170_usb_firmware_finish(fw, context);
+ return;
+ }
+
+ if (aru->req_one_stage_fw) {
+ dev_err(&aru->udev->dev, "ar9170.fw firmware file "
+ "not found and is required for this device\n");
+ ar9170_usb_firmware_failed(aru);
+ return;
+ }
+
+ dev_err(&aru->udev->dev, "ar9170.fw firmware file "
+ "not found, trying old firmware...\n");
+
+ err = request_firmware_nowait(THIS_MODULE, 1, "ar9170-1.fw",
+ &aru->udev->dev, GFP_KERNEL, aru,
+ ar9170_usb_firmware_inits);
+ if (err)
+ ar9170_usb_firmware_failed(aru);
+}
+
static bool ar9170_requires_one_stage(const struct usb_device_id *id)
{
if (!id->driver_info)
@@ -810,33 +870,9 @@ static int ar9170_usb_probe(struct usb_i
if (err)
goto err_freehw;
- err = ar9170_usb_request_firmware(aru);
- if (err)
- goto err_freehw;
-
- err = ar9170_usb_init_device(aru);
- if (err)
- goto err_freefw;
-
- err = ar9170_usb_open(ar);
- if (err)
- goto err_unrx;
-
- err = ar9170_register(ar, &udev->dev);
-
- ar9170_usb_stop(ar);
- if (err)
- goto err_unrx;
-
- return 0;
-
-err_unrx:
- ar9170_usb_cancel_urbs(aru);
-
-err_freefw:
- release_firmware(aru->init_values);
- release_firmware(aru->firmware);
-
+ return request_firmware_nowait(THIS_MODULE, 1, "ar9170.fw",
+ &aru->udev->dev, GFP_KERNEL, aru,
+ ar9170_usb_firmware_step2);
err_freehw:
usb_set_intfdata(intf, NULL);
usb_put_dev(udev);
@@ -856,12 +892,12 @@ static void ar9170_usb_disconnect(struct
ar9170_unregister(&aru->common);
ar9170_usb_cancel_urbs(aru);
- release_firmware(aru->init_values);
- release_firmware(aru->firmware);
-
usb_put_dev(aru->udev);
usb_set_intfdata(intf, NULL);
ieee80211_free_hw(aru->common.hw);
+
+ release_firmware(aru->init_values);
+ release_firmware(aru->firmware);
}
#ifdef CONFIG_PM
--- wireless-testing.orig/drivers/net/wireless/ath/ar9170/ar9170.h 2009-10-26 18:00:40.000000000 +0100
+++ wireless-testing/drivers/net/wireless/ath/ar9170/ar9170.h 2009-10-26 18:04:01.000000000 +0100
@@ -160,6 +160,7 @@ struct ar9170 {
struct ath_common common;
struct mutex mutex;
enum ar9170_device_state state;
+ bool registered;
unsigned long bad_hw_nagger;
int (*open)(struct ar9170 *);
--- wireless-testing.orig/drivers/net/wireless/ath/ar9170/main.c 2009-10-26 18:04:05.000000000 +0100
+++ wireless-testing/drivers/net/wireless/ath/ar9170/main.c 2009-10-26 18:05:59.000000000 +0100
@@ -2722,7 +2722,8 @@ int ar9170_register(struct ar9170 *ar, s
dev_info(pdev, "Atheros AR9170 is registered as '%s'\n",
wiphy_name(ar->hw->wiphy));
- return err;
+ ar->registered = true;
+ return 0;
err_unreg:
ieee80211_unregister_hw(ar->hw);
@@ -2733,11 +2734,14 @@ err_out:
void ar9170_unregister(struct ar9170 *ar)
{
+ if (ar->registered) {
#ifdef CONFIG_AR9170_LEDS
- ar9170_unregister_leds(ar);
+ ar9170_unregister_leds(ar);
#endif /* CONFIG_AR9170_LEDS */
- kfree_skb(ar->rx_failover);
ieee80211_unregister_hw(ar->hw);
+ }
+
+ kfree_skb(ar->rx_failover);
mutex_destroy(&ar->mutex);
}
^ permalink raw reply
* Re: iwl3945, after a while stops working with "No space for Tx"
From: Fredi @ 2009-10-26 17:04 UTC (permalink / raw)
To: reinette chatre
Cc: YiZhu, Intel Linux Wireless, John W. Linville, TomasWinkler,
AbhijeetKolekar, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1256574352.21134.7591.camel@rc-desk>
Hi
first thanks for your reply,
--- On Mon, 26/10/09, reinette chatre <reinette.chatre@intel.com> wrote:
> From: reinette chatre <reinette.chatre@intel.com>
> Subject: Re: iwl3945, after a while stops working with "No space for Tx"
> To: "Frederik Nosi" <fredin77@yahoo.com>
> Cc: "Zhu, Yi" <yi.zhu@intel.com>, "Intel Linux Wireless" <ilw@linux.intel.com>, "John W. Linville" <linville@tuxdriver.com>, "Winkler, Tomas" <tomas.winkler@intel.com>, "Kolekar, Abhijeet" <abhijeet.kolekar@intel.com>, "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
> Date: Monday, 26 October, 2009, 5:25 PM
> On Sat, 2009-10-24 at 06:44 -0700,
> Frederik Nosi wrote:
> > Hi,
> > first sorry if somebody is not the right contact, got
> the adressess from ./scripts/get_maintainer.pl -f
> drivers/net/wireless/iwlwifi.
> > From some kernel versions now, after some time that im
> using this card it stops working and on messages i get this
> errors:
> >
> > Oct 24 14:38:24 kotys NetworkManager:
> <info> Activation (wlan0) Stage 5 of 5 (IP
> Configure Commit) complete.
> > [snip pulseaudio's stuppid log spam warning]
> > Oct 24 14:40:07 kotys kernel: iwl3945 0000:04:00.0:
> Error sending REPLY_TX_PWR_TABLE_CMD: time out after 500ms.
> > Oct 24 14:40:09 kotys pulseaudio[16469]: sap.c:
> sendmsg() failed: Invalid argument
> > Oct 24 14:40:10 kotys kernel: iwl3945 0000:04:00.0:
> Error sending REPLY_SCAN_CMD: time out after 500ms.
> > Oct 24 14:40:11 kotys kernel: iwl3945 0000:04:00.0:
> Error sending REPLY_TX_PWR_TABLE_CMD: time out after 500ms.
> > Oct 24 14:40:11 kotys kernel: iwl3945 0000:04:00.0:
> Error sending POWER_TABLE_CMD: time out after 500ms.
> > Oct 24 14:40:14 kotys kernel: iwl3945 0000:04:00.0:
> set power fail, ret = -110
> > Oct 24 14:40:14 kotys kernel: No probe response from
> AP 00:1c:df:82:63:c9 after 500ms, disconnecting.
> > Oct 24 14:40:14 kotys NetworkManager:
> <info> (wlan0): supplicant connection
> state: completed -> disconnected
> > Oct 24 14:40:14 kotys NetworkManager:
> <info> (wlan0): supplicant connection
> state: disconnected -> scanning
> > Oct 24 14:40:14 kotys pulseaudio[16469]: sap.c:
> sendmsg() failed: Invalid argument
> > Oct 24 14:40:14 kotys kernel: iwl3945 0000:04:00.0:
> Error sending REPLY_RXON: time out after 500ms.
> > Oct 24 14:40:14 kotys kernel: iwl3945 0000:04:00.0:
> Error setting new configuration (-110).
> > Oct 24 14:40:15 kotys kernel: iwl3945 0000:04:00.0:
> Error sending REPLY_SCAN_CMD: time out after 500ms.
> > Oct 24 14:40:15 kotys kernel: wlan0: direct probe to
> AP 00:1c:df:82:63:c9 (try 1)
> > Oct 24 14:40:15 kotys NetworkManager:
> <info> (wlan0): supplicant connection
> state: scanning -> associating
> > Oct 24 14:40:15 kotys kernel: wlan0: direct probe to
> AP 00:1c:df:82:63:c9 (try 2)
> > Oct 24 14:40:15 kotys kernel: wlan0: direct probe to
> AP 00:1c:df:82:63:c9 (try 3)
> > Oct 24 14:40:15 kotys kernel: iwl3945 0000:04:00.0:
> Error sending REPLY_RXON: time out after 500ms.
> > Oct 24 14:40:15 kotys kernel: iwl3945 0000:04:00.0:
> Error setting new configuration (-110).
> > Oct 24 14:40:15 kotys kernel: wlan0: direct probe to
> AP 00:1c:df:82:63:c9 timed out
> > Oct 24 14:40:16 kotys kernel: iwl3945 0000:04:00.0:
> Error sending REPLY_TX_PWR_TABLE_CMD: time out after 500ms.
> > Oct 24 14:40:16 kotys kernel: iwl3945 0000:04:00.0:
> Error sending REPLY_RXON: time out after 500ms.
> > Oct 24 14:40:16 kotys kernel: iwl3945 0000:04:00.0:
> Error setting new configuration (-110).
> >
> >
> > When this happens i am able to use the card only after
> reloading the related modules, iwl3945 ecc. But the problem
> happens again after some minutes that im connected.
> >
> > Kernel is 2.6.32-rc5 but his started happening around
> 2.6.31, not sure exactly what version as i update kernel
> often. Firmware is iwl3945-ucode-15.32.2.9.
> >
> > Every other info that you need just ask. I hope i dont
> have to bisect as this is the laptop i use for work too, but
> if it's needed i'll do.
> >
> > I'm not subscribed on any ML, so in case please cc
> me.
> >
>
> We currently have a bug open for this issue. Could you
> please add this
>
> information to
> http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1944
> ?
Done, noticed that there's a patch for this issue. Will try and tell the results. And noticed the link on how to report possible firmware problems, will follow that procedure and post the results of that too.
> Thank you
Thaks for pointing me on the right direction!
> Reinette
>
>
Frederik
^ permalink raw reply
* [PATCH v2 2/4] ath9k_hw: distinguish single-chip solutions on initial probe print
From: Luis R. Rodriguez @ 2009-10-26 16:44 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ath9k-devel, Luis R. Rodriguez
Devices with external radios have revisions which we can count on.
On single chip solutions these EEPROM values for these radio revision
also exist but are not meaningful as the radios are embedded onto the
same chip. Each single-chip device evolves together as one device.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
Changes hw_name to 60 bytes.
drivers/net/wireless/ath/ath9k/ahb.c | 11 ++++-------
drivers/net/wireless/ath/ath9k/hw.c | 27 +++++++++++++++++++++++----
drivers/net/wireless/ath/ath9k/hw.h | 3 +--
drivers/net/wireless/ath/ath9k/pci.c | 11 ++++-------
4 files changed, 32 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ahb.c b/drivers/net/wireless/ath/ath9k/ahb.c
index 41422c4..33da2e7 100644
--- a/drivers/net/wireless/ath/ath9k/ahb.c
+++ b/drivers/net/wireless/ath/ath9k/ahb.c
@@ -69,6 +69,7 @@ static int ath_ahb_probe(struct platform_device *pdev)
int irq;
int ret = 0;
struct ath_hw *ah;
+ char hw_name[60];
if (!pdev->dev.platform_data) {
dev_err(&pdev->dev, "no platform data specified\n");
@@ -133,15 +134,11 @@ static int ath_ahb_probe(struct platform_device *pdev)
}
ah = sc->sc_ah;
+ ath9k_hw_name(ah, hw_name);
printk(KERN_INFO
- "%s: Atheros AR%s MAC/BB Rev:%x, "
- "AR%s RF Rev:%x, mem=0x%lx, irq=%d\n",
+ "%s: %s mem=0x%lx, irq=%d\n",
wiphy_name(hw->wiphy),
- ath9k_hw_mac_bb_name(ah->hw_version.macVersion),
- ah->hw_version.macRev,
- ath9k_hw_rf_name((ah->hw_version.analog5GhzRev &
- AR_RADIO_SREV_MAJOR)),
- ah->hw_version.phyRev,
+ hw_name,
(unsigned long)mem, irq);
return 0;
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index cf543e3..f65b591 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -3959,7 +3959,7 @@ static struct {
/*
* Return the MAC/BB name. "????" is returned if the MAC/BB is unknown.
*/
-const char *ath9k_hw_mac_bb_name(u32 mac_bb_version)
+static const char *ath9k_hw_mac_bb_name(u32 mac_bb_version)
{
int i;
@@ -3971,13 +3971,12 @@ const char *ath9k_hw_mac_bb_name(u32 mac_bb_version)
return "????";
}
-EXPORT_SYMBOL(ath9k_hw_mac_bb_name);
/*
* Return the RF name. "????" is returned if the RF is unknown.
* Used for devices with external radios.
*/
-const char *ath9k_hw_rf_name(u16 rf_version)
+static const char *ath9k_hw_rf_name(u16 rf_version)
{
int i;
@@ -3989,4 +3988,24 @@ const char *ath9k_hw_rf_name(u16 rf_version)
return "????";
}
-EXPORT_SYMBOL(ath9k_hw_rf_name);
+
+void ath9k_hw_name(struct ath_hw *ah, char *hw_name)
+{
+ /* chipsets >= AR9280 are single-chip */
+ if (AR_SREV_9280_10_OR_LATER(ah)) {
+ sprintf(hw_name,
+ "Atheros single-chip AR%s Rev:%x",
+ ath9k_hw_mac_bb_name(ah->hw_version.macVersion),
+ ah->hw_version.macRev);
+ }
+ else {
+ sprintf(hw_name,
+ "Atheros AR%s MAC/BB Rev:%x AR%s RF Rev:%x: ",
+ ath9k_hw_mac_bb_name(ah->hw_version.macVersion),
+ ah->hw_version.macRev,
+ ath9k_hw_rf_name((ah->hw_version.analog5GhzRev &
+ AR_RADIO_SREV_MAJOR)),
+ ah->hw_version.phyRev);
+ }
+}
+EXPORT_SYMBOL(ath9k_hw_name);
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 100fcba..3ceb4c6 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -720,8 +720,7 @@ void ath_gen_timer_free(struct ath_hw *ah, struct ath_gen_timer *timer);
void ath_gen_timer_isr(struct ath_hw *hw);
u32 ath9k_hw_gettsf32(struct ath_hw *ah);
-const char *ath9k_hw_mac_bb_name(u32 mac_bb_version);
-const char *ath9k_hw_rf_name(u16 rf_version);
+void ath9k_hw_name(struct ath_hw *ah, char *hw_name);
#define ATH_PCIE_CAP_LINK_CTRL 0x70
#define ATH_PCIE_CAP_LINK_L0S 1
diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
index 76f3890..961a18b 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -114,6 +114,7 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
u32 val;
int ret = 0;
struct ath_hw *ah;
+ char hw_name[60];
if (pci_enable_device(pdev))
return -EIO;
@@ -218,15 +219,11 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
sc->irq = pdev->irq;
ah = sc->sc_ah;
+ ath9k_hw_name(ah, hw_name);
printk(KERN_INFO
- "%s: Atheros AR%s MAC/BB Rev:%x "
- "AR%s RF Rev:%x: mem=0x%lx, irq=%d\n",
+ "%s: %s mem=0x%lx, irq=%d\n",
wiphy_name(hw->wiphy),
- ath9k_hw_mac_bb_name(ah->hw_version.macVersion),
- ah->hw_version.macRev,
- ath9k_hw_rf_name((ah->hw_version.analog5GhzRev &
- AR_RADIO_SREV_MAJOR)),
- ah->hw_version.phyRev,
+ hw_name,
(unsigned long)mem, pdev->irq);
return 0;
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 2/4] ath9k_hw: distinguish single-chip solutions on initial probe print
From: Luis R. Rodriguez @ 2009-10-26 16:37 UTC (permalink / raw)
To: Michael Buesch; +Cc: Kalle Valo, linville, linux-wireless, ath9k-devel
In-Reply-To: <200910261729.38199.mb@bu3sch.de>
On Mon, Oct 26, 2009 at 9:29 AM, Michael Buesch <mb@bu3sch.de> wrote:
> On Monday 26 October 2009 17:21:40 Luis R. Rodriguez wrote:
>> >> --- a/drivers/net/wireless/ath/ath9k/pci.c
>> >> +++ b/drivers/net/wireless/ath/ath9k/pci.c
>> >> @@ -114,6 +114,7 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>> >> u32 val;
>> >> int ret = 0;
>> >> struct ath_hw *ah;
>> >> + char hw_name[1024];
>> >
>> > Ditto.
>>
>> We use this for debugfs, so I went with that as an upper limit, given
>> that we just use it a probe it seemed sane.
>
> I think it's completely insane, because you effectively use 25% of the available stack.
> Why is a hardware name 1024 chars (max) long anyway?
>
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> I would be pissed off after reading the first line already ;)
Heh alright, I'll go reduce this, thanks.
Luis
^ permalink raw reply
* Re: [RFC] libertas: minimal WEXT handler for MESH
From: Johannes Berg @ 2009-10-26 16:35 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless, Dan Williams
In-Reply-To: <200910261729.36583.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 411 bytes --]
On Mon, 2009-10-26 at 17:29 +0100, Holger Schurig wrote:
> For many handlers, I simply put NULL there, but I guess
> that I should do this:
>
> a) register mesh_dev with cfg80211 as well
> b) use the handlers from compat-wext.c instead
>
> Is this right? And I guess that I connot do b) without a)
>
> Or is it ok to do b) without a).
No, it's not, it'll most certainly segfault.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [RFC] libertas: minimal WEXT handler for MESH
From: Holger Schurig @ 2009-10-26 16:29 UTC (permalink / raw)
To: linux-wireless, Dan Williams, Johannes Berg
Here I moved some WEXT related for the mesh interface from wext.c
into the upcoming "mesh.c". Near the very end of this patch you
see the new iw_handler definition.
For many handlers, I simply put NULL there, but I guess
that I should do this:
a) register mesh_dev with cfg80211 as well
b) use the handlers from compat-wext.c instead
Is this right? And I guess that I connot do b) without a)
Or is it ok to do b) without a). Would then cfg80211 than always
calls into the priv->dev (for the station's struct net_device *).
I'm puzzled.
I guess that this patch --- as it is --- will leave you with a broken
mesh implementation. Or with a partially broken one, e.g. where you
can define mesh-SSID, but you cannot reduce the TX power. Not sure if
that is what we want ---- or in other words, not sure if the mesh-WEXT
handler really only needs 4 or so handler functions.
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
--- linux-wl.orig/drivers/net/wireless/libertas/wext.c
+++ linux-wl/drivers/net/wireless/libertas/wext.c
@@ -104,45 +104,6 @@
}
/**
- * @brief Find the channel frequency power info with specific channel
- *
- * @param priv A pointer to struct lbs_private structure
- * @param band it can be BAND_A, BAND_G or BAND_B
- * @param channel the channel for looking
- * @return A pointer to struct chan_freq_power structure or NULL if not find.
- */
-struct chan_freq_power *lbs_find_cfp_by_band_and_channel(
- struct lbs_private *priv,
- u8 band,
- u16 channel)
-{
- struct chan_freq_power *cfp = NULL;
- struct region_channel *rc;
- int i, j;
-
- for (j = 0; !cfp && (j < ARRAY_SIZE(priv->region_channel)); j++) {
- rc = &priv->region_channel[j];
-
- if (!rc->valid || !rc->CFP)
- continue;
- if (rc->band != band)
- continue;
- for (i = 0; i < rc->nrcfp; i++) {
- if (rc->CFP[i].channel == channel) {
- cfp = &rc->CFP[i];
- break;
- }
- }
- }
-
- if (!cfp && channel)
- lbs_deb_wext("lbs_find_cfp_by_band_and_channel: can't find "
- "cfp by band %d / channel %d\n", band, channel);
-
- return cfp;
-}
-
-/**
* @brief Find the channel frequency power info with specific frequency
*
* @param priv A pointer to struct lbs_private structure
@@ -213,7 +174,7 @@
return 0;
}
-static int lbs_get_freq(struct net_device *dev, struct iw_request_info *info,
+int lbs_get_freq(struct net_device *dev, struct iw_request_info *info,
struct iw_freq *fwrq, char *extra)
{
struct lbs_private *priv = dev->ml_priv;
@@ -422,18 +383,6 @@
return 0;
}
-static int mesh_wlan_get_mode(struct net_device *dev,
- struct iw_request_info *info, u32 * uwrq,
- char *extra)
-{
- lbs_deb_enter(LBS_DEB_WEXT);
-
- *uwrq = IW_MODE_REPEAT;
-
- lbs_deb_leave(LBS_DEB_WEXT);
- return 0;
-}
-
static int lbs_get_txpow(struct net_device *dev,
struct iw_request_info *info,
struct iw_param *vwrq, char *extra)
@@ -838,7 +787,7 @@
return 0;
}
-static struct iw_statistics *lbs_get_wireless_stats(struct net_device *dev)
+struct iw_statistics *lbs_get_wireless_stats(struct net_device *dev)
{
enum {
POOR = 30,
@@ -1010,58 +959,6 @@
return ret;
}
-static int lbs_mesh_set_freq(struct net_device *dev,
- struct iw_request_info *info,
- struct iw_freq *fwrq, char *extra)
-{
- struct lbs_private *priv = dev->ml_priv;
- struct chan_freq_power *cfp;
- int ret = -EINVAL;
-
- lbs_deb_enter(LBS_DEB_WEXT);
-
- /* If setting by frequency, convert to a channel */
- if (fwrq->e == 1) {
- long f = fwrq->m / 100000;
-
- cfp = find_cfp_by_band_and_freq(priv, 0, f);
- if (!cfp) {
- lbs_deb_wext("invalid freq %ld\n", f);
- goto out;
- }
-
- fwrq->e = 0;
- fwrq->m = (int) cfp->channel;
- }
-
- /* Setting by channel number */
- if (fwrq->m > 1000 || fwrq->e > 0) {
- goto out;
- }
-
- cfp = lbs_find_cfp_by_band_and_channel(priv, 0, fwrq->m);
- if (!cfp) {
- goto out;
- }
-
- if (fwrq->m != priv->channel) {
- lbs_deb_wext("mesh channel change forces eth disconnect\n");
- if (priv->mode == IW_MODE_INFRA)
- lbs_cmd_80211_deauthenticate(priv,
- priv->curbssparams.bssid,
- WLAN_REASON_DEAUTH_LEAVING);
- else if (priv->mode == IW_MODE_ADHOC)
- lbs_adhoc_stop(priv);
- }
- lbs_mesh_config(priv, CMD_ACT_MESH_CONFIG_START, fwrq->m);
- lbs_update_channel(priv);
- ret = 0;
-
-out:
- lbs_deb_leave_args(LBS_DEB_WEXT, "ret %d", ret);
- return ret;
-}
-
static int lbs_set_rate(struct net_device *dev, struct iw_request_info *info,
struct iw_param *vwrq, char *extra)
{
@@ -2110,60 +2007,6 @@
return ret;
}
-static int lbs_mesh_get_essid(struct net_device *dev,
- struct iw_request_info *info,
- struct iw_point *dwrq, char *extra)
-{
- struct lbs_private *priv = dev->ml_priv;
-
- lbs_deb_enter(LBS_DEB_WEXT);
-
- memcpy(extra, priv->mesh_ssid, priv->mesh_ssid_len);
-
- dwrq->length = priv->mesh_ssid_len;
-
- dwrq->flags = 1; /* active */
-
- lbs_deb_leave(LBS_DEB_WEXT);
- return 0;
-}
-
-static int lbs_mesh_set_essid(struct net_device *dev,
- struct iw_request_info *info,
- struct iw_point *dwrq, char *extra)
-{
- struct lbs_private *priv = dev->ml_priv;
- int ret = 0;
-
- lbs_deb_enter(LBS_DEB_WEXT);
-
- if (!priv->radio_on) {
- ret = -EINVAL;
- goto out;
- }
-
- /* Check the size of the string */
- if (dwrq->length > IEEE80211_MAX_SSID_LEN) {
- ret = -E2BIG;
- goto out;
- }
-
- if (!dwrq->flags || !dwrq->length) {
- ret = -EINVAL;
- goto out;
- } else {
- /* Specific SSID requested */
- memcpy(priv->mesh_ssid, extra, dwrq->length);
- priv->mesh_ssid_len = dwrq->length;
- }
-
- lbs_mesh_config(priv, CMD_ACT_MESH_CONFIG_START,
- priv->channel);
- out:
- lbs_deb_leave_args(LBS_DEB_WEXT, "ret %d", ret);
- return ret;
-}
-
/**
* @brief Connect to the AP or Ad-hoc Network with specific bssid
*
@@ -2270,71 +2113,8 @@
(iw_handler) NULL, /* SIOCSIWPMKSA */
};
-static const iw_handler mesh_wlan_handler[] = {
- (iw_handler) NULL, /* SIOCSIWCOMMIT */
- (iw_handler) lbs_get_name, /* SIOCGIWNAME */
- (iw_handler) NULL, /* SIOCSIWNWID */
- (iw_handler) NULL, /* SIOCGIWNWID */
- (iw_handler) lbs_mesh_set_freq, /* SIOCSIWFREQ */
- (iw_handler) lbs_get_freq, /* SIOCGIWFREQ */
- (iw_handler) NULL, /* SIOCSIWMODE */
- (iw_handler) mesh_wlan_get_mode, /* SIOCGIWMODE */
- (iw_handler) NULL, /* SIOCSIWSENS */
- (iw_handler) NULL, /* SIOCGIWSENS */
- (iw_handler) NULL, /* SIOCSIWRANGE */
- (iw_handler) lbs_get_range, /* SIOCGIWRANGE */
- (iw_handler) NULL, /* SIOCSIWPRIV */
- (iw_handler) NULL, /* SIOCGIWPRIV */
- (iw_handler) NULL, /* SIOCSIWSTATS */
- (iw_handler) NULL, /* SIOCGIWSTATS */
- iw_handler_set_spy, /* SIOCSIWSPY */
- iw_handler_get_spy, /* SIOCGIWSPY */
- iw_handler_set_thrspy, /* SIOCSIWTHRSPY */
- iw_handler_get_thrspy, /* SIOCGIWTHRSPY */
- (iw_handler) NULL, /* SIOCSIWAP */
- (iw_handler) NULL, /* SIOCGIWAP */
- (iw_handler) NULL, /* SIOCSIWMLME */
- (iw_handler) NULL, /* SIOCGIWAPLIST - deprecated */
- (iw_handler) lbs_set_scan, /* SIOCSIWSCAN */
- (iw_handler) lbs_get_scan, /* SIOCGIWSCAN */
- (iw_handler) lbs_mesh_set_essid,/* SIOCSIWESSID */
- (iw_handler) lbs_mesh_get_essid,/* SIOCGIWESSID */
- (iw_handler) NULL, /* SIOCSIWNICKN */
- (iw_handler) mesh_get_nick, /* SIOCGIWNICKN */
- (iw_handler) NULL, /* -- hole -- */
- (iw_handler) NULL, /* -- hole -- */
- (iw_handler) lbs_set_rate, /* SIOCSIWRATE */
- (iw_handler) lbs_get_rate, /* SIOCGIWRATE */
- (iw_handler) lbs_set_rts, /* SIOCSIWRTS */
- (iw_handler) lbs_get_rts, /* SIOCGIWRTS */
- (iw_handler) lbs_set_frag, /* SIOCSIWFRAG */
- (iw_handler) lbs_get_frag, /* SIOCGIWFRAG */
- (iw_handler) lbs_set_txpow, /* SIOCSIWTXPOW */
- (iw_handler) lbs_get_txpow, /* SIOCGIWTXPOW */
- (iw_handler) lbs_set_retry, /* SIOCSIWRETRY */
- (iw_handler) lbs_get_retry, /* SIOCGIWRETRY */
- (iw_handler) lbs_set_encode, /* SIOCSIWENCODE */
- (iw_handler) lbs_get_encode, /* SIOCGIWENCODE */
- (iw_handler) lbs_set_power, /* SIOCSIWPOWER */
- (iw_handler) lbs_get_power, /* SIOCGIWPOWER */
- (iw_handler) NULL, /* -- hole -- */
- (iw_handler) NULL, /* -- hole -- */
- (iw_handler) lbs_set_genie, /* SIOCSIWGENIE */
- (iw_handler) lbs_get_genie, /* SIOCGIWGENIE */
- (iw_handler) lbs_set_auth, /* SIOCSIWAUTH */
- (iw_handler) lbs_get_auth, /* SIOCGIWAUTH */
- (iw_handler) lbs_set_encodeext,/* SIOCSIWENCODEEXT */
- (iw_handler) lbs_get_encodeext,/* SIOCGIWENCODEEXT */
- (iw_handler) NULL, /* SIOCSIWPMKSA */
-};
struct iw_handler_def lbs_handler_def = {
.num_standard = ARRAY_SIZE(lbs_handler),
.standard = (iw_handler *) lbs_handler,
.get_wireless_stats = lbs_get_wireless_stats,
};
-
-struct iw_handler_def mesh_handler_def = {
- .num_standard = ARRAY_SIZE(mesh_wlan_handler),
- .standard = (iw_handler *) mesh_wlan_handler,
- .get_wireless_stats = lbs_get_wireless_stats,
-};
--- linux-wl.orig/drivers/net/wireless/libertas/wext.h
+++ linux-wl/drivers/net/wireless/libertas/wext.h
@@ -4,6 +4,14 @@
#ifndef _LBS_WEXT_H_
#define _LBS_WEXT_H_
+
+struct lbs_private;
+struct net_device;
+struct iw_request_info;
+struct iw_freq;
+struct iw_statistics;
+
+
void lbs_send_disconnect_notification(struct lbs_private *priv);
void lbs_send_mic_failureevent(struct lbs_private *priv, u32 event);
@@ -14,4 +22,9 @@
extern struct iw_handler_def lbs_handler_def;
+int lbs_get_freq(struct net_device *dev, struct iw_request_info *info,
+ struct iw_freq *fwrq, char *extra);
+struct iw_statistics *lbs_get_wireless_stats(struct net_device *dev);
+
+
#endif
--- linux-wl.orig/drivers/net/wireless/libertas/persistcfg.c
+++ linux-wl/drivers/net/wireless/libertas/persistcfg.c
@@ -9,6 +9,7 @@
#include "mesh.h"
#include "decl.h"
#include "cmd.h"
+#include "wext.h"
/***************************************************************************
@@ -1059,6 +1060,294 @@
/***************************************************************************
+ * WEXT related
+ */
+
+/**
+ * @brief Find the channel frequency power info with specific frequency
+ *
+ * @param priv A pointer to struct lbs_private structure
+ * @param band it can be BAND_A, BAND_G or BAND_B
+ * @param freq the frequency for looking
+ * @return A pointer to struct chan_freq_power structure or NULL if not find.
+ */
+static struct chan_freq_power *find_cfp_by_band_and_freq(
+ struct lbs_private *priv,
+ u8 band,
+ u32 freq)
+{
+ struct chan_freq_power *cfp = NULL;
+ struct region_channel *rc;
+ int i, j;
+
+ for (j = 0; !cfp && (j < ARRAY_SIZE(priv->region_channel)); j++) {
+ rc = &priv->region_channel[j];
+
+ if (!rc->valid || !rc->CFP)
+ continue;
+ if (rc->band != band)
+ continue;
+ for (i = 0; i < rc->nrcfp; i++) {
+ if (rc->CFP[i].freq == freq) {
+ cfp = &rc->CFP[i];
+ break;
+ }
+ }
+ }
+
+ if (!cfp && freq)
+ lbs_deb_wext("find_cfp_by_band_and_freql: can't find cfp by "
+ "band %d / freq %d\n", band, freq);
+
+ return cfp;
+}
+
+/**
+ * @brief Find the channel frequency power info with specific channel
+ *
+ * @param priv A pointer to struct lbs_private structure
+ * @param band it can be BAND_A, BAND_G or BAND_B
+ * @param channel the channel for looking
+ * @return A pointer to struct chan_freq_power structure or NULL if not find.
+ */
+struct chan_freq_power *lbs_find_cfp_by_band_and_channel(
+ struct lbs_private *priv,
+ u8 band,
+ u16 channel)
+{
+ struct chan_freq_power *cfp = NULL;
+ struct region_channel *rc;
+ int i, j;
+
+ for (j = 0; !cfp && (j < ARRAY_SIZE(priv->region_channel)); j++) {
+ rc = &priv->region_channel[j];
+
+ if (!rc->valid || !rc->CFP)
+ continue;
+ if (rc->band != band)
+ continue;
+ for (i = 0; i < rc->nrcfp; i++) {
+ if (rc->CFP[i].channel == channel) {
+ cfp = &rc->CFP[i];
+ break;
+ }
+ }
+ }
+
+ if (!cfp && channel)
+ lbs_deb_wext("lbs_find_cfp_by_band_and_channel: can't find "
+ "cfp by band %d / channel %d\n", band, channel);
+
+ return cfp;
+}
+
+static int lbs_mesh_set_freq(struct net_device *dev,
+ struct iw_request_info *info,
+ struct iw_freq *fwrq, char *extra)
+{
+ struct lbs_private *priv = dev->ml_priv;
+ struct chan_freq_power *cfp;
+ int ret = -EINVAL;
+
+ lbs_deb_enter(LBS_DEB_WEXT);
+
+ /* If setting by frequency, convert to a channel */
+ if (fwrq->e == 1) {
+ long f = fwrq->m / 100000;
+
+ cfp = find_cfp_by_band_and_freq(priv, 0, f);
+ if (!cfp) {
+ lbs_deb_wext("invalid freq %ld\n", f);
+ goto out;
+ }
+
+ fwrq->e = 0;
+ fwrq->m = (int) cfp->channel;
+ }
+
+ /* Setting by channel number */
+ if (fwrq->m > 1000 || fwrq->e > 0)
+ goto out;
+
+ cfp = lbs_find_cfp_by_band_and_channel(priv, 0, fwrq->m);
+ if (!cfp)
+ goto out;
+
+ if (fwrq->m != priv->channel) {
+ lbs_deb_wext("mesh channel change forces eth disconnect\n");
+ if (priv->mode == IW_MODE_INFRA)
+ lbs_cmd_80211_deauthenticate(priv,
+ priv->curbssparams.bssid,
+ WLAN_REASON_DEAUTH_LEAVING);
+ else if (priv->mode == IW_MODE_ADHOC)
+ lbs_adhoc_stop(priv);
+ }
+ lbs_mesh_config(priv, CMD_ACT_MESH_CONFIG_START, fwrq->m);
+ lbs_update_channel(priv);
+ ret = 0;
+
+out:
+ lbs_deb_leave_args(LBS_DEB_WEXT, "ret %d", ret);
+ return ret;
+}
+
+static int mesh_wlan_get_mode(struct net_device *dev,
+ struct iw_request_info *info, u32 * uwrq,
+ char *extra)
+{
+ lbs_deb_enter(LBS_DEB_WEXT);
+
+ *uwrq = IW_MODE_REPEAT;
+
+ lbs_deb_leave(LBS_DEB_WEXT);
+ return 0;
+}
+
+static int lbs_mesh_set_essid(struct net_device *dev,
+ struct iw_request_info *info,
+ struct iw_point *dwrq, char *extra)
+{
+ struct lbs_private *priv = dev->ml_priv;
+ int ret = 0;
+
+ lbs_deb_enter(LBS_DEB_WEXT);
+
+ if (!priv->radio_on) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ /* Check the size of the string */
+ if (dwrq->length > IEEE80211_MAX_SSID_LEN) {
+ ret = -E2BIG;
+ goto out;
+ }
+
+ if (!dwrq->flags || !dwrq->length) {
+ ret = -EINVAL;
+ goto out;
+ } else {
+ /* Specific SSID requested */
+ memcpy(priv->mesh_ssid, extra, dwrq->length);
+ priv->mesh_ssid_len = dwrq->length;
+ }
+
+ lbs_mesh_config(priv, CMD_ACT_MESH_CONFIG_START,
+ priv->channel);
+ out:
+ lbs_deb_leave_args(LBS_DEB_WEXT, "ret %d", ret);
+ return ret;
+}
+
+static int lbs_mesh_get_essid(struct net_device *dev,
+ struct iw_request_info *info,
+ struct iw_point *dwrq, char *extra)
+{
+ struct lbs_private *priv = dev->ml_priv;
+
+ lbs_deb_enter(LBS_DEB_WEXT);
+
+ memcpy(extra, priv->mesh_ssid, priv->mesh_ssid_len);
+
+ dwrq->length = priv->mesh_ssid_len;
+
+ dwrq->flags = 1; /* active */
+
+ lbs_deb_leave(LBS_DEB_WEXT);
+ return 0;
+}
+
+
+static int mesh_get_nick(struct net_device *dev, struct iw_request_info *info,
+ struct iw_point *dwrq, char *extra)
+{
+ struct lbs_private *priv = dev->ml_priv;
+
+ lbs_deb_enter(LBS_DEB_WEXT);
+
+ /* Use nickname to indicate that mesh is on */
+
+ if (priv->mesh_connect_status == LBS_CONNECTED) {
+ strncpy(extra, "Mesh", 12);
+ extra[12] = '\0';
+ dwrq->length = strlen(extra);
+ }
+
+ else {
+ extra[0] = '\0';
+ dwrq->length = 0;
+ }
+
+ lbs_deb_leave(LBS_DEB_WEXT);
+ return 0;
+}
+
+
+static const iw_handler mesh_wlan_handler[] = {
+ (iw_handler) NULL, /* SIOCSIWCOMMIT */
+ (iw_handler) NULL, /* SIOCGIWNAME, was lbs_get_name */
+ (iw_handler) NULL, /* SIOCSIWNWID */
+ (iw_handler) NULL, /* SIOCGIWNWID */
+ (iw_handler) lbs_mesh_set_freq, /* SIOCSIWFREQ */
+ (iw_handler) lbs_get_freq, /* SIOCGIWFREQ */
+ (iw_handler) NULL, /* SIOCSIWMODE */
+ (iw_handler) mesh_wlan_get_mode, /* SIOCGIWMODE */
+ (iw_handler) NULL, /* SIOCSIWSENS */
+ (iw_handler) NULL, /* SIOCGIWSENS */
+ (iw_handler) NULL, /* SIOCSIWRANGE */
+ (iw_handler) NULL, /* SIOCGIWRANGE, was lbs_get_range */
+ (iw_handler) NULL, /* SIOCSIWPRIV */
+ (iw_handler) NULL, /* SIOCGIWPRIV */
+ (iw_handler) NULL, /* SIOCSIWSTATS */
+ (iw_handler) NULL, /* SIOCGIWSTATS */
+ iw_handler_set_spy, /* SIOCSIWSPY */
+ iw_handler_get_spy, /* SIOCGIWSPY */
+ iw_handler_set_thrspy, /* SIOCSIWTHRSPY */
+ iw_handler_get_thrspy, /* SIOCGIWTHRSPY */
+ (iw_handler) NULL, /* SIOCSIWAP */
+ (iw_handler) NULL, /* SIOCGIWAP */
+ (iw_handler) NULL, /* SIOCSIWMLME */
+ (iw_handler) NULL, /* SIOCGIWAPLIST - deprecated */
+ (iw_handler) lbs_set_scan, /* SIOCSIWSCAN */
+ (iw_handler) lbs_get_scan, /* SIOCGIWSCAN */
+ (iw_handler) lbs_mesh_set_essid,/* SIOCSIWESSID */
+ (iw_handler) lbs_mesh_get_essid,/* SIOCGIWESSID */
+ (iw_handler) NULL, /* SIOCSIWNICKN */
+ (iw_handler) mesh_get_nick, /* SIOCGIWNICKN */
+ (iw_handler) NULL, /* -- hole -- */
+ (iw_handler) NULL, /* -- hole -- */
+ (iw_handler) NULL, /* SIOCSIWRATE, was lbs_set_rate */
+ (iw_handler) NULL, /* SIOCGIWRATE, was lbs_get_rate */
+ (iw_handler) NULL, /* SIOCSIWRTS, was lbs_set_rts */
+ (iw_handler) NULL, /* SIOCGIWRTS, was lbs_get_rts */
+ (iw_handler) NULL, /* SIOCSIWFRAG, was lbs_set_frag */
+ (iw_handler) NULL, /* SIOCGIWFRAG, was lbs_get_frag */
+ (iw_handler) NULL, /* SIOCSIWTXPOW, was lbs_set_txpow */
+ (iw_handler) NULL, /* SIOCGIWTXPOW, was lbs_get_txpow */
+ (iw_handler) NULL, /* SIOCSIWRETRY, was lbs_set_retry */
+ (iw_handler) NULL, /* SIOCGIWRETRY, was lbs_get_retry */
+ (iw_handler) NULL, /* SIOCSIWENCODE, was lbs_set_encode */
+ (iw_handler) NULL, /* SIOCGIWENCODE, was lbs_get_encode */
+ (iw_handler) NULL, /* SIOCSIWPOWER, was lbs_set_power */
+ (iw_handler) NULL, /* SIOCGIWPOWER, was lbs_get_power */
+ (iw_handler) NULL, /* -- hole -- */
+ (iw_handler) NULL, /* -- hole -- */
+ (iw_handler) NULL, /* SIOCSIWGENIE, was lbs_set_genie */
+ (iw_handler) NULL, /* SIOCGIWGENIE, lbs_get_genie */
+ (iw_handler) NULL, /* SIOCSIWAUTH, lbs_set_auth */
+ (iw_handler) NULL, /* SIOCGIWAUTH, lbs_get_auth */
+ (iw_handler) NULL, /* SIOCSIWENCODEEXT, was lbs_set_encodeext */
+ (iw_handler) NULL, /* SIOCGIWENCODEEXT, was lbs_get_encodeext */
+ (iw_handler) NULL, /* SIOCSIWPMKSA */
+};
+struct iw_handler_def mesh_handler_def = {
+ .num_standard = ARRAY_SIZE(mesh_wlan_handler),
+ .standard = (iw_handler *) mesh_wlan_handler,
+ .get_wireless_stats = lbs_get_wireless_stats,
+};
+
+
+/***************************************************************************
* Ethtool related
*/
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH 2/4] ath9k_hw: distinguish single-chip solutions on initial probe print
From: Michael Buesch @ 2009-10-26 16:29 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Kalle Valo, linville, linux-wireless, ath9k-devel
In-Reply-To: <43e72e890910260921h91c4cb5u5a2fc81e73377055@mail.gmail.com>
On Monday 26 October 2009 17:21:40 Luis R. Rodriguez wrote:
> >> --- a/drivers/net/wireless/ath/ath9k/pci.c
> >> +++ b/drivers/net/wireless/ath/ath9k/pci.c
> >> @@ -114,6 +114,7 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> >> u32 val;
> >> int ret = 0;
> >> struct ath_hw *ah;
> >> + char hw_name[1024];
> >
> > Ditto.
>
> We use this for debugfs, so I went with that as an upper limit, given
> that we just use it a probe it seemed sane.
I think it's completely insane, because you effectively use 25% of the available stack.
Why is a hardware name 1024 chars (max) long anyway?
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I would be pissed off after reading the first line already ;)
--
Greetings, Michael.
^ permalink raw reply
* Re: iwl3945, after a while stops working with "No space for Tx"
From: reinette chatre @ 2009-10-26 16:25 UTC (permalink / raw)
To: Frederik Nosi
Cc: Zhu, Yi, Intel Linux Wireless, John W. Linville, Winkler, Tomas,
Kolekar, Abhijeet, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <177253.23325.qm@web53903.mail.re2.yahoo.com>
On Sat, 2009-10-24 at 06:44 -0700, Frederik Nosi wrote:
> Hi,
> first sorry if somebody is not the right contact, got the adressess from ./scripts/get_maintainer.pl -f drivers/net/wireless/iwlwifi.
> From some kernel versions now, after some time that im using this card it stops working and on messages i get this errors:
>
> Oct 24 14:38:24 kotys NetworkManager: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) complete.
> [snip pulseaudio's stuppid log spam warning]
> Oct 24 14:40:07 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out after 500ms.
> Oct 24 14:40:09 kotys pulseaudio[16469]: sap.c: sendmsg() failed: Invalid argument
> Oct 24 14:40:10 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_SCAN_CMD: time out after 500ms.
> Oct 24 14:40:11 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out after 500ms.
> Oct 24 14:40:11 kotys kernel: iwl3945 0000:04:00.0: Error sending POWER_TABLE_CMD: time out after 500ms.
> Oct 24 14:40:14 kotys kernel: iwl3945 0000:04:00.0: set power fail, ret = -110
> Oct 24 14:40:14 kotys kernel: No probe response from AP 00:1c:df:82:63:c9 after 500ms, disconnecting.
> Oct 24 14:40:14 kotys NetworkManager: <info> (wlan0): supplicant connection state: completed -> disconnected
> Oct 24 14:40:14 kotys NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning
> Oct 24 14:40:14 kotys pulseaudio[16469]: sap.c: sendmsg() failed: Invalid argument
> Oct 24 14:40:14 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_RXON: time out after 500ms.
> Oct 24 14:40:14 kotys kernel: iwl3945 0000:04:00.0: Error setting new configuration (-110).
> Oct 24 14:40:15 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_SCAN_CMD: time out after 500ms.
> Oct 24 14:40:15 kotys kernel: wlan0: direct probe to AP 00:1c:df:82:63:c9 (try 1)
> Oct 24 14:40:15 kotys NetworkManager: <info> (wlan0): supplicant connection state: scanning -> associating
> Oct 24 14:40:15 kotys kernel: wlan0: direct probe to AP 00:1c:df:82:63:c9 (try 2)
> Oct 24 14:40:15 kotys kernel: wlan0: direct probe to AP 00:1c:df:82:63:c9 (try 3)
> Oct 24 14:40:15 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_RXON: time out after 500ms.
> Oct 24 14:40:15 kotys kernel: iwl3945 0000:04:00.0: Error setting new configuration (-110).
> Oct 24 14:40:15 kotys kernel: wlan0: direct probe to AP 00:1c:df:82:63:c9 timed out
> Oct 24 14:40:16 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out after 500ms.
> Oct 24 14:40:16 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_RXON: time out after 500ms.
> Oct 24 14:40:16 kotys kernel: iwl3945 0000:04:00.0: Error setting new configuration (-110).
>
>
> When this happens i am able to use the card only after reloading the related modules, iwl3945 ecc. But the problem happens again after some minutes that im connected.
>
> Kernel is 2.6.32-rc5 but his started happening around 2.6.31, not sure exactly what version as i update kernel often. Firmware is iwl3945-ucode-15.32.2.9.
>
> Every other info that you need just ask. I hope i dont have to bisect as this is the laptop i use for work too, but if it's needed i'll do.
>
> I'm not subscribed on any ML, so in case please cc me.
>
We currently have a bug open for this issue. Could you please add this
information to
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1944 ?
Thank you
Reinette
^ permalink raw reply
* Re: [PATCH 2/4] ath9k_hw: distinguish single-chip solutions on initial probe print
From: Luis R. Rodriguez @ 2009-10-26 16:21 UTC (permalink / raw)
To: Kalle Valo; +Cc: linville, linux-wireless, ath9k-devel
In-Reply-To: <87hbtmgmj6.fsf@purkki.valot.fi>
On Mon, Oct 26, 2009 at 9:14 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
> "Luis R. Rodriguez" <lrodriguez@atheros.com> writes:
>
>> Devices with external radios have revisions which we can count on.
>> On single chip solutions these EEPROM values for these radio revision
>> also exist but are not meaningful as the radios are embedded onto the
>> same chip. Each single-chip device evolves together as one device.
>>
>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>> ---
>> drivers/net/wireless/ath/ath9k/ahb.c | 11 ++++-------
>> drivers/net/wireless/ath/ath9k/hw.c | 27 +++++++++++++++++++++++----
>> drivers/net/wireless/ath/ath9k/hw.h | 3 +--
>> drivers/net/wireless/ath/ath9k/pci.c | 11 ++++-------
>> 4 files changed, 32 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/ahb.c b/drivers/net/wireless/ath/ath9k/ahb.c
>> index 41422c4..925818c 100644
>> --- a/drivers/net/wireless/ath/ath9k/ahb.c
>> +++ b/drivers/net/wireless/ath/ath9k/ahb.c
>> @@ -69,6 +69,7 @@ static int ath_ahb_probe(struct platform_device *pdev)
>> int irq;
>> int ret = 0;
>> struct ath_hw *ah;
>> + char hw_name[1024];
>
> This is a bit too large to allocate from stack IMHO.
>
>
> [...]
>
>> --- a/drivers/net/wireless/ath/ath9k/pci.c
>> +++ b/drivers/net/wireless/ath/ath9k/pci.c
>> @@ -114,6 +114,7 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>> u32 val;
>> int ret = 0;
>> struct ath_hw *ah;
>> + char hw_name[1024];
>
> Ditto.
We use this for debugfs, so I went with that as an upper limit, given
that we just use it a probe it seemed sane.
Luis
^ permalink raw reply
* Re: [PATCH 2/4] ath9k_hw: distinguish single-chip solutions on initial probe print
From: Kalle Valo @ 2009-10-26 16:14 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless, ath9k-devel
In-Reply-To: <1256567941-26859-3-git-send-email-lrodriguez@atheros.com>
"Luis R. Rodriguez" <lrodriguez@atheros.com> writes:
> Devices with external radios have revisions which we can count on.
> On single chip solutions these EEPROM values for these radio revision
> also exist but are not meaningful as the radios are embedded onto the
> same chip. Each single-chip device evolves together as one device.
>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> drivers/net/wireless/ath/ath9k/ahb.c | 11 ++++-------
> drivers/net/wireless/ath/ath9k/hw.c | 27 +++++++++++++++++++++++----
> drivers/net/wireless/ath/ath9k/hw.h | 3 +--
> drivers/net/wireless/ath/ath9k/pci.c | 11 ++++-------
> 4 files changed, 32 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/ahb.c b/drivers/net/wireless/ath/ath9k/ahb.c
> index 41422c4..925818c 100644
> --- a/drivers/net/wireless/ath/ath9k/ahb.c
> +++ b/drivers/net/wireless/ath/ath9k/ahb.c
> @@ -69,6 +69,7 @@ static int ath_ahb_probe(struct platform_device *pdev)
> int irq;
> int ret = 0;
> struct ath_hw *ah;
> + char hw_name[1024];
This is a bit too large to allocate from stack IMHO.
[...]
> --- a/drivers/net/wireless/ath/ath9k/pci.c
> +++ b/drivers/net/wireless/ath/ath9k/pci.c
> @@ -114,6 +114,7 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> u32 val;
> int ret = 0;
> struct ath_hw *ah;
> + char hw_name[1024];
Ditto.
--
Kalle Valo
^ 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