* Re: WLAN Regulatory Domain Germany
From: John W. Linville @ 2010-06-18 18:44 UTC (permalink / raw)
To: Kurt Garloff; +Cc: Johannes Berg, linux-wireless, Luis R. Rodriguez
In-Reply-To: <20100525151429.GC6342@tpkurt2.garloff.de>
On Tue, May 25, 2010 at 05:14:29PM +0200, Kurt Garloff wrote:
> OK, new suggestion.
>
> 8<------------------------------------------------------------------------
>
> # Data from "Frequenznutzungsplan" (as published in April 2008), downloaded from
> # http://www.bundesnetzagentur.de/cae/servlet/contentblob/38448/publicationFile/2659/Frequenznutzungsplan2008_Id17448pdf.pdf
> # For the 5GHz range also see
> # http://www.bundesnetzagentur.de/cae/servlet/contentblob/38216/publicationFile/6579/WLAN5GHzVfg7_2010_28042010pdf.pdf
> # The values have been reduced by a factor of 2 (3db) for non TPC devices
> # (in other words: devices with TPC can use twice the tx power of this table).
> # Note that the docs do not require TPC for 5150--5250; the reduction to
> # 100mW thus is not strictly required -- however the conservative 100mW
> # limit is used here as the non-interference with radar and satellite
> # apps relies on the attenuation by the building walls only in the
> # absence of DFS; the neighbour countries have 100mW limit here as well.
>
> country DE:
> # entries 279004 and 280006
> (2400 - 2483.5 @ 40), (N/A, 100 mW)
> # entry 303005
> (5150 - 5250 @ 40), (N/A, 100 mW), NO-OUTDOOR
> # entries 304002 and 305002
> (5250 - 5350 @ 40), (N/A, 100 mW), NO-OUTDOOR, DFS
> # entries 308002, 309001 and 310003
> (5470 - 5725 @ 40), (N/A, 500 mW), DFS
>
> 8<------------------------------------------------------------------------
Is this what we want? Are you going to submit an actual patch?
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: [RFC] wireless-regdb: Add A band in IL
From: John W. Linville @ 2010-06-18 18:42 UTC (permalink / raw)
To: Emmanuel Grumbach; +Cc: linux-wireless, Michael Green, David Quan
In-Reply-To: <1274856569-13436-1-git-send-email-emmanuel.grumbach@intel.com>
On Wed, May 26, 2010 at 09:49:29AM +0300, Emmanuel Grumbach wrote:
> A band in allowed in IL, according to official document issued by the Ministry
> of Communications: http://www.moc.gov.il/sip_storage/FILES/1/1061.pdf.
>
> 5150 - 5250 200mW e.i.r.p. OUTDOOR forbidden
> 5250 - 5350 200mW e.i.r.p. OUTDOOR forbidden DFS mandatory
>
> 40Mhz is allowed in A band for every WiFi-Alliance certified equipment.
>
> ***************************************************************
> Not to be merged for the moment
> ***************************************************************
>
> CC: Michael Green <Michael.Green@atheros.com>
> CC: David Quan <David.Quan@atheros.com>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> ---
> db.txt | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/db.txt b/db.txt
> index e63a43e..d49c397 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -319,6 +319,8 @@ country IE:
>
> country IL:
> (2402 - 2482 @ 40), (N/A, 20)
> + (5150 - 5250 @ 40). (N/A, 200 mW), NO-OUTDOOR
> + (5250 - 5350 @ 40). (N/A, 200 mW), NO-OUTDOOR, DFS
>
> country IN:
> (2402 - 2482 @ 40), (N/A, 20)
Is this issue now settled?
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: wireless-regdb: FI/CZ updates
From: John W. Linville @ 2010-06-18 18:43 UTC (permalink / raw)
To: Pekka Pietikainen
Cc: Luis R. Rodriguez, Michael Green, David Quan, linux-wireless
In-Reply-To: <20100528124258.GA27491@ee.oulu.fi>
On Fri, May 28, 2010 at 03:42:58PM +0300, Pekka Pietikainen wrote:
> On Wed, May 26, 2010 at 11:30:37AM -0700, Luis R. Rodriguez wrote:
> > Pekka, please remove these changes from this patch, you want to make
> > your patches atomic, with only one purpose to help the review process
> > easier. You stashed changes to CZ & FI on one... You also switched
> > from dBm to mW and note how you actually did change the EIRP here for
> > only one for FI. Please provide a separate set of patches for that for
> > FI. If you want to switch to mW for all of the entries for FI first do
> > that, and then on a separate patch make the actual regulatory changes
> > so this is crystal clear for the review process.
> Okie
>
> Looking at it a bit more probably makes sense to codify the current
> harmonized EU rules, and then just for each country note that they've
> actually implemented it in their local legislation (I checked FI, SE and
> CZ). Everyone should have, but some are pretty slow at this, or
> have some special national interests...
>
> The legislation uses mW, so that's the reason I switched them.
>
> For review (first hit on google for the decision number
> should find the official text), I can do patches once someone
> has verified, that this is what the legalese actually says:
>
> # EU Commission Decision 2009/381/EC
> (2400 - 2483.5 @ 40), (N/A, 100mW)
> # 2005/513/EC and 2007/90/EC, 5250 and 5470 can be doubled if TPC is in use
> (5150 - 5250 @ 40), (N/A, 200mW), NO-OUTDOOR
> (5250 - 5350 @ 40), (N/A, 100mW), NO-OUTDOOR, DFS
> (5470 - 5725 @ 40), (N/A, 500mW), DFS
Ping?
--
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 4/5]pci:setup_bus.c Fix warning: variable 'retval' set but not used
From: Justin P. Mattock @ 2010-06-18 18:38 UTC (permalink / raw)
To: Jesse Barnes
Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi, Yinghai Lu
In-Reply-To: <20100618102330.29eccb5b@virtuousgeek.org>
From b07231ddb853e9388cea77a82da210e36ab79aad Mon Sep 17 00:00:00 2001
From: Justin P. Mattock <justinmattock@gmail.com>
Date: Fri, 18 Jun 2010 11:32:20 -0700
Subject: [PATCH 2/2] setup-bus_test
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/pci/setup-bus.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 19b1113..7b57dd0 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -875,6 +875,7 @@ again:
pci_bus_size_bridges(parent);
__pci_bridge_assign_resources(bridge, &head);
retval = pci_reenable_device(bridge);
+ printk(KERN_DEBUG "PCI%d: re-enabling device\n", retval);
pci_set_master(bridge);
pci_enable_bridges(parent);
--
1.7.1.rc1.21.gf3bd6
o.k. I went through this as you had requested to the best of my
knowledge(bit confused with this, but will try).
let me know if more should be added and/or it's totally wrong
then I'll try again until correct..
Justin P. Mattock
^ permalink raw reply related
* rt61pci AP performance issues
From: David Ellingsworth @ 2010-06-18 18:02 UTC (permalink / raw)
To: rt2x00 Users List, wireless
I've been trying unsuccessfully for some time to use a rt61pci based
wireless card as an Access Point for my network. With kernel version
2.6.32-4 (Debian version) the AP works but has intermittent problems.
Notably, that version continuously prints the message
"ieee80211_tx_status: headroom too small" to my system log and the
driver simply stops working after a random amount of time. The first
of these errors was fixed some time ago after I reported it, but the
other still remains, even with the latest wireless-testing driver, and
there's no indication as to the cause of the issue. With regards to
this issue, it appears that performance steadily drops until it
becomes unusable. With the latest wireless-testing driver I can
reliably reproduce this issue by trying to transfer a large file from
my server to a client. Any help diagnosing and correcting this issue
would be greatly appreciated.
Regards,
David Ellingsworth
^ permalink raw reply
* Re: [PATCH 4/5]pci:setup_bus.c Fix warning: variable 'retval' set but not used
From: Justin P. Mattock @ 2010-06-18 17:31 UTC (permalink / raw)
To: Jesse Barnes
Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi, Yinghai Lu
In-Reply-To: <20100618102330.29eccb5b@virtuousgeek.org>
On 06/18/2010 10:23 AM, Jesse Barnes wrote:
> On Tue, 15 Jun 2010 22:33:53 -0700
> "Justin P. Mattock"<justinmattock@gmail.com> wrote:
>
>> The below patch fixes a warning message when using gcc 4.6.0
>> CC drivers/pci/setup-bus.o
>> drivers/pci/setup-bus.c: In function 'pci_assign_unassigned_bridge_resources':
>> drivers/pci/setup-bus.c:868:6: warning: variable 'retval' set but not used
>>
>> Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
>>
>> ---
>> drivers/pci/setup-bus.c | 2 --
>> 1 files changed, 0 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
>> index 19b1113..215590b 100644
>> --- a/drivers/pci/setup-bus.c
>> +++ b/drivers/pci/setup-bus.c
>> @@ -865,7 +865,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
>> struct pci_bus *parent = bridge->subordinate;
>> int tried_times = 0;
>> struct resource_list_x head, *list;
>> - int retval;
>> unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
>> IORESOURCE_PREFETCH;
>>
>> @@ -874,7 +873,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
>> again:
>> pci_bus_size_bridges(parent);
>> __pci_bridge_assign_resources(bridge,&head);
>> - retval = pci_reenable_device(bridge);
>> pci_set_master(bridge);
>> pci_enable_bridges(parent);
>>
>
> This has the same problem as your earlier bridge_enable patch; you need
> to keep the call to pci_reenable_device. I should have caught this
> issue when Yinghai's patch went in: the right way to silence a warning
> about not checking a return value isn't to simply assign it to
> something, you really should *do* something as well, at least some
> debug output would be nice, but ideally handling the error in a sane
> way.
>
yeah I was still looking into the scsi patch with adding a printk
then I can look at this as well.
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH 4/5]pci:setup_bus.c Fix warning: variable 'retval' set but not used
From: Jesse Barnes @ 2010-06-18 17:23 UTC (permalink / raw)
To: Justin P. Mattock
Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi, Yinghai Lu
In-Reply-To: <1276666434-11227-5-git-send-email-justinmattock@gmail.com>
On Tue, 15 Jun 2010 22:33:53 -0700
"Justin P. Mattock" <justinmattock@gmail.com> wrote:
> The below patch fixes a warning message when using gcc 4.6.0
> CC drivers/pci/setup-bus.o
> drivers/pci/setup-bus.c: In function 'pci_assign_unassigned_bridge_resources':
> drivers/pci/setup-bus.c:868:6: warning: variable 'retval' set but not used
>
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>
> ---
> drivers/pci/setup-bus.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 19b1113..215590b 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -865,7 +865,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
> struct pci_bus *parent = bridge->subordinate;
> int tried_times = 0;
> struct resource_list_x head, *list;
> - int retval;
> unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
> IORESOURCE_PREFETCH;
>
> @@ -874,7 +873,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
> again:
> pci_bus_size_bridges(parent);
> __pci_bridge_assign_resources(bridge, &head);
> - retval = pci_reenable_device(bridge);
> pci_set_master(bridge);
> pci_enable_bridges(parent);
>
This has the same problem as your earlier bridge_enable patch; you need
to keep the call to pci_reenable_device. I should have caught this
issue when Yinghai's patch went in: the right way to silence a warning
about not checking a return value isn't to simply assign it to
something, you really should *do* something as well, at least some
debug output would be nice, but ideally handling the error in a sane
way.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* [PATCH] ath5k: initialize ah->ah_current_channel
From: Bob Copeland @ 2010-06-18 17:15 UTC (permalink / raw)
To: linville, sbrown; +Cc: linux-wireless, ath5k-devel, Bob Copeland, stable
ath5k assumes ah_current_channel is always a valid pointer in
several places, but a newly created interface may not have a
channel. To avoid null pointer dereferences, set it up to point
to the first available channel until later reconfigured.
This fixes the following oops:
$ rmmod ath5k
$ insmod ath5k
$ iw phy0 set distance 11000
BUG: unable to handle kernel NULL pointer dereference at 00000006
IP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k]
*pde = 00000000
Oops: 0000 [#1]
last sysfs file: /sys/devices/pci0000:00/0000:00:0e.0/ieee80211/phy0/index
Modules linked in: usbhid option usb_storage usbserial usblp evdev lm90
scx200_acb i2c_algo_bit i2c_dev i2c_core via_rhine ohci_hcd ne2k_pci
8390 leds_alix2 xt_IMQ imq nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_cc
Pid: 1597, comm: iw Not tainted (2.6.32.14 #8)
EIP: 0060:[<d0a1ff24>] EFLAGS: 00010296 CPU: 0
EIP is at ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k]
EAX: 000000c2 EBX: 00000000 ECX: ffffffff EDX: c12d2080
ESI: 00000019 EDI: cf8c0000 EBP: d0a30edc ESP: cfa09bf4
DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
Process iw (pid: 1597, ti=cfa09000 task=cf88a000 task.ti=cfa09000)
Stack:
d0a34f35 d0a353f8 d0a30edc 000000fe cf8c0000 00000000 1900063d cfa8c9e0
<0> cfa8c9e8 cfa8c0c0 cfa8c000 d0a27f0c 199d84b4 cfa8c200 00000010 d09bfdc7
<0> 00000000 00000000 ffffffff d08e0d28 cf9263c0 00000001 cfa09cc4 00000000
Call Trace:
[<d0a27f0c>] ? ath5k_hw_attach+0xc8c/0x3c10 [ath5k]
[<d09bfdc7>] ? __ieee80211_request_smps+0x1347/0x1580 [mac80211]
[<d08e0d28>] ? nl80211_send_scan_start+0x7b8/0x4520 [cfg80211]
[<c10f5db9>] ? nla_parse+0x59/0xc0
[<c11ca8d9>] ? genl_rcv_msg+0x169/0x1a0
[<c11ca770>] ? genl_rcv_msg+0x0/0x1a0
[<c11c7e68>] ? netlink_rcv_skb+0x38/0x90
[<c11c9649>] ? genl_rcv+0x19/0x30
[<c11c7c03>] ? netlink_unicast+0x1b3/0x220
[<c11c893e>] ? netlink_sendmsg+0x26e/0x290
[<c11a409e>] ? sock_sendmsg+0xbe/0xf0
[<c1032780>] ? autoremove_wake_function+0x0/0x50
[<c104d846>] ? __alloc_pages_nodemask+0x106/0x530
[<c1074933>] ? do_lookup+0x53/0x1b0
[<c10766f9>] ? __link_path_walk+0x9b9/0x9e0
[<c11acab0>] ? verify_iovec+0x50/0x90
[<c11a42b1>] ? sys_sendmsg+0x1e1/0x270
[<c1048e50>] ? find_get_page+0x10/0x50
[<c104a96f>] ? filemap_fault+0x5f/0x370
[<c1059159>] ? __do_fault+0x319/0x370
[<c11a55b4>] ? sys_socketcall+0x244/0x290
[<c101962c>] ? do_page_fault+0x1ec/0x270
[<c1019440>] ? do_page_fault+0x0/0x270
[<c1002ae5>] ? syscall_call+0x7/0xb
Code: 00 b8 fe 00 00 00 b9 f8 53 a3 d0 89 5c 24 14 89 7c 24 10 89 44 24
0c 89 6c 24 08 89 4c 24 04 c7 04 24 35 4f a3 d0 e8 7c 30 60 f0 <0f> b7
43 06 ba 06 00 00 00 a8 10 75 0e 83 e0 20 83 f8 01 19 d2
EIP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] SS:ESP
0068:cfa09bf4
CR2: 0000000000000006
---[ end trace 54f73d6b10ceb87b ]---
Cc: stable@kernel.org
Reported-by: Steve Brown <sbrown@cortland.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath5k/attach.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/attach.c b/drivers/net/wireless/ath/ath5k/attach.c
index ef2dc1d..b32e28c 100644
--- a/drivers/net/wireless/ath/ath5k/attach.c
+++ b/drivers/net/wireless/ath/ath5k/attach.c
@@ -126,6 +126,7 @@ int ath5k_hw_attach(struct ath5k_softc *sc)
ah->ah_ant_mode = AR5K_ANTMODE_DEFAULT;
ah->ah_noise_floor = -95; /* until first NF calibration is run */
sc->ani_state.ani_mode = ATH5K_ANI_MODE_AUTO;
+ ah->ah_current_channel = &sc->channels[0];
/*
* Find the mac version
--
1.6.3.3
^ permalink raw reply related
* Re: USB device that supports master mode?
From: Pavel Roskin @ 2010-06-18 16:39 UTC (permalink / raw)
To: Denis 'GNUtoo' Carikli; +Cc: Robert Urban, linux-wireless
In-Reply-To: <1276871717.918.1.camel@gnutoo-laptop>
On Fri, 2010-06-18 at 16:35 +0200, Denis 'GNUtoo' Carikli wrote:
> On Wed, 2010-06-09 at 02:08 +0200, Robert Urban wrote:
> > Hello Wireless folks,
> >
> > I'm looking for a USB device that supports master mode, preferably with a
> > connection for an external antenna.
> >
> > Does anyone know of specific products that satisy these criteria?
> >
> > thanks,
> >
> > Rob Urban
> I've a rt3070 that can do access point,
> I've tried it with wireless-compat and it worked.
> But I've not used it extensively(I plan to do so altough because of the
> good range.)
> It also has a connector for the antenna,but I don't know the brand,
> there is no brand written on it.
TP-Link TL-WN422G has an external antenna, it's a USB device and it
supports master mode with the patches for ath9k_htc that were recently
posted:
http://marc.info/?t=127676699200001&r=1&w=3
The device appears to be capable of 802.11n, even though that capability
is not advertised on the box. I haven't run any benchmarks though.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH 1/2] ath9k_htc: Add AP mode to supported modes
From: Pavel Roskin @ 2010-06-18 16:33 UTC (permalink / raw)
To: Sujith; +Cc: linville, linux-wireless
In-Reply-To: <19481.60102.659111.953695@gargle.gargle.HOWL>
On Thu, 2010-06-17 at 14:58 +0530, Sujith wrote:
> Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
> ---
> drivers/net/wireless/ath/ath9k/htc_drv_init.c | 3 ++-
> drivers/net/wireless/ath/ath9k/htc_drv_main.c | 3 +++
> 2 files changed, 5 insertions(+), 1 deletions(-)
I confirm that the AP mode is working on TP-Link TL-WN422G (0cf3:1006).
I tested both patched of the series at once.
That's great news! TL-WN422G has an external antenna, connects over USB
and supports AP mode. Users keep asking about that combination of
features. Now we have an answer :-)
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2010-06-17
From: David Miller @ 2010-06-18 16:01 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20100617210242.GB2368@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 17 Jun 2010 17:02:42 -0400
> Another week, another bunch of patches intende for 2.6.36...
> This week's batch includes the usual updates to ath5k, ath9k,
> iwlwifi, rt2x00, and other drivers. Also included are a lot of
> cleanup/maintenance for mac80211 from Johannes and some IBSS-related
> changes from Teemu, as well as a number of other patches from a
> variety of contributors.
>
> Please let me know if there are problems!
Pulled, thanks JOhn.
^ permalink raw reply
* Re: [PATCH] p54usb: Remove duplicate Medion MD40900 device id
From: Larry Finger @ 2010-06-18 15:06 UTC (permalink / raw)
To: John W. Linville; +Cc: Leann Ogasawara, flamingice, linux-wireless, Ben Collins
In-Reply-To: <20100615194610.GB2415@tuxdriver.com>
On 06/15/2010 02:46 PM, John W. Linville wrote:
> On Tue, Jun 15, 2010 at 10:59:05AM -0700, Leann Ogasawara wrote:
>> On Mon, 2010-06-14 at 14:55 -0400, John W. Linville wrote:
>
>>> So, I guess you are concerned about the groupings because of the
>>> different firmwares or something like that? Perhaps a comment that
>>> says "this could be a version 2 device" is just as handy? Since the
>>> driver prints the name of the firmware it wants, is there any real
>>> need for grouping the IDs?
>>>
>>> OTOH, is there any actual harm from the duplicate entry? It "seems"
>>> wrong to me too, but I guess it does no harm...?
>>
>> I don't believe there is any harm from the duplicate entry, it just
>> seemed unnecessary.
>>
>>> Leann and/or Ben, was this just tidying-up? I'm guessing there wasn't
>>> an actual bug involved?
>>
>> Indeed, this was just a patch we'd been carrying to tidy things up.
>> There was no actual bug involved. I'd be happy to send a v2 of the
>> patch which comments out the duplicate entry and adds a note as to why.
>> Or I'd be fine just leaving the code as is and we'll drop the patch
>> we're carrying locally in Ubuntu.
>
> FWIW, I like the 'comment-out and add a note' option.
I'm a little late here after being offline, but I too like the comment
out option.
Larry
^ permalink raw reply
* Re: USB device that supports master mode?
From: Denis 'GNUtoo' Carikli @ 2010-06-18 14:35 UTC (permalink / raw)
To: Robert Urban; +Cc: linux-wireless
In-Reply-To: <4C0EDB71.1070104@unix-beratung.de>
On Wed, 2010-06-09 at 02:08 +0200, Robert Urban wrote:
> Hello Wireless folks,
>
> I'm looking for a USB device that supports master mode, preferably with a
> connection for an external antenna.
>
> Does anyone know of specific products that satisy these criteria?
>
> thanks,
>
> Rob Urban
I've a rt3070 that can do access point,
I've tried it with wireless-compat and it worked.
But I've not used it extensively(I plan to do so altough because of the
good range.)
It also has a connector for the antenna,but I don't know the brand,
there is no brand written on it.
Denis
^ permalink raw reply
* Re: [PATCH] ath5k: disable ASPM
From: Maxim Levitsky @ 2010-06-18 14:11 UTC (permalink / raw)
To: Bob Copeland
Cc: Jussi Kivilinna, ath5k-devel, linux-wireless, Luis R. Rodriguez,
linux-kernel
In-Reply-To: <AANLkTimdTjedtoeKAp5tcTqefrUB6k373Kx9EacuYFcO@mail.gmail.com>
On Fri, 2010-06-18 at 09:59 -0400, Bob Copeland wrote:
> On Fri, Jun 18, 2010 at 7:05 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> >> Patch I made uses GPL code from e1000e, but since ath5k is
> >> dual-licensed so patch can't be accepted. So if I got it right, patch
> >> has to be remade from scratch by someone who really knows about pci
> >> registers etc. I don't, and learning this to fix something that is
> >> already fixed in my point of view is waste of (my) time.
> > Sure, regardless of licensing, this patch has to be redone (and e1000
> > with it)
>
> At any rate, Jussi, thanks a bundle for tracking it down. I owe you a
> beer, lots of bugs have been reported on these devices.
>
> Maxim, this device was always broken in the same way, right? Just
> curious if anything made it worse recently.
Always was broken, of course even with madwifi.
Recently I think driver stopped doing reset on RXORN, which sometimes
helped. This did made things a bit worse.
Anyway, just disable L0S, and card works perfectly.
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: [PATCH] ath5k: disable ASPM
From: Bob Copeland @ 2010-06-18 13:59 UTC (permalink / raw)
To: Maxim Levitsky
Cc: Jussi Kivilinna, ath5k-devel, linux-wireless, Luis R. Rodriguez,
linux-kernel
In-Reply-To: <1276859156.19554.2.camel@maxim-laptop>
On Fri, Jun 18, 2010 at 7:05 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>> Patch I made uses GPL code from e1000e, but since ath5k is
>> dual-licensed so patch can't be accepted. So if I got it right, patch
>> has to be remade from scratch by someone who really knows about pci
>> registers etc. I don't, and learning this to fix something that is
>> already fixed in my point of view is waste of (my) time.
> Sure, regardless of licensing, this patch has to be redone (and e1000
> with it)
At any rate, Jussi, thanks a bundle for tracking it down. I owe you a
beer, lots of bugs have been reported on these devices.
Maxim, this device was always broken in the same way, right? Just
curious if anything made it worse recently.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: Problems connectring to an AP with Acer Aspire Revo
From: Carlos Balseiro @ 2010-06-18 13:06 UTC (permalink / raw)
To: linux-wireless
Any news on this item?
^ permalink raw reply
* Re: [PATCH] ath5k: disable ASPM
From: Maxim Levitsky @ 2010-06-18 11:05 UTC (permalink / raw)
To: Jussi Kivilinna
Cc: ath5k-devel, linux-wireless, Luis R. Rodriguez, Bob Copeland,
linux-kernel
In-Reply-To: <20100618134930.124225d4fsi8w1fk@naisho.dyndns.info>
On Fri, 2010-06-18 at 13:49 +0300, Jussi Kivilinna wrote:
> Quoting "Maxim Levitsky" <maximlevitsky@gmail.com>:
>
> >> (ok, I might switch back ath5k to work on this, but opening AAO is
> >> pain.. on the other hand, I'm just user in this case and pretty
> >> unwilling to work with dual-license)
> > What do you mean?
>
> Patch I made uses GPL code from e1000e, but since ath5k is
> dual-licensed so patch can't be accepted. So if I got it right, patch
> has to be remade from scratch by someone who really knows about pci
> registers etc. I don't, and learning this to fix something that is
> already fixed in my point of view is waste of (my) time.
Sure, regardless of licensing, this patch has to be redone (and e1000
with it)
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: [PATCH] ath5k: disable ASPM
From: Jussi Kivilinna @ 2010-06-18 10:49 UTC (permalink / raw)
To: Maxim Levitsky
Cc: ath5k-devel, linux-wireless, Luis R. Rodriguez, Bob Copeland
In-Reply-To: <1276856142.9114.1.camel@maxim-laptop>
Quoting "Maxim Levitsky" <maximlevitsky@gmail.com>:
>> (ok, I might switch back ath5k to work on this, but opening AAO is
>> pain.. on the other hand, I'm just user in this case and pretty
>> unwilling to work with dual-license)
> What do you mean?
Patch I made uses GPL code from e1000e, but since ath5k is
dual-licensed so patch can't be accepted. So if I got it right, patch
has to be remade from scratch by someone who really knows about pci
registers etc. I don't, and learning this to fix something that is
already fixed in my point of view is waste of (my) time.
>> I did test device with L0s+L1 enabled (aspm=force), on this setup
>> device fails within seconds. I tested patch with disabling L1 but not
>> L0s, still fails but after longer time. I did _not_ test with L0s off
>> but L1 enabled. So maybe it would be worth to test this patch with
>> just disabling L0s.
> I did, and it works.
Yeah, I noticed your reply at bugzilla (#13892).
-Jussi
^ permalink raw reply
* Re: OOPS in ath5k when setting coverage class
From: Steve Brown @ 2010-06-18 10:48 UTC (permalink / raw)
To: Bob Copeland; +Cc: ath5k-devel, linux-wireless
In-Reply-To: <20100618031635.GB18709@hash.localnet>
On 06/17/2010 09:16 PM, Bob Copeland wrote:
> On Thu, Jun 17, 2010 at 12:49:51PM -0600, Steve Brown wrote:
>
>> I went a little further and tested the following patch.
>>
>> If it makes sense to you, I'll submit it.
>>
> So I looked over the code and found a few more trouble spots.
> What about something like this instead? It shouldn't hurt to
> use a default channel but could avoid another round or two of
> whack-a-mole...
>
> From: Bob Copeland<me@bobcopeland.com>
> Date: Thu, 17 Jun 2010 23:05:55 -0400
> Subject: [PATCH] ath5k: initialize ah->ah_current_channel
>
> ath5k assumes ah_current_channel is always a valid pointer in
> several places, but a newly created interface may not have a
> channel. To avoid null pointer dereferences, set it up to point
> to the first available channel until later reconfigured.
>
> Signed-off-by: Bob Copeland<me@bobcopeland.com>
> ---
> drivers/net/wireless/ath/ath5k/attach.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/attach.c b/drivers/net/wireless/ath/ath5k/attach.c
> index ef2dc1d..b32e28c 100644
> --- a/drivers/net/wireless/ath/ath5k/attach.c
> +++ b/drivers/net/wireless/ath/ath5k/attach.c
> @@ -126,6 +126,7 @@ int ath5k_hw_attach(struct ath5k_softc *sc)
> ah->ah_ant_mode = AR5K_ANTMODE_DEFAULT;
> ah->ah_noise_floor = -95; /* until first NF calibration is run */
> sc->ani_state.ani_mode = ATH5K_ANI_MODE_AUTO;
> + ah->ah_current_channel =&sc->channels[0];
>
> /*
> * Find the mac version
>
Applied and tested. Works.
Thanks,
Steve
^ permalink raw reply
* Re: IWL3945 problems in 2.6.35-rc1
From: Maxim Levitsky @ 2010-06-18 10:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Reinette Chatre
In-Reply-To: <1276857009.3638.20.camel@jlt3.sipsolutions.net>
On Fri, 2010-06-18 at 12:30 +0200, Johannes Berg wrote:
> Maxim,
>
> Thanks for the quick reply!
>
> > > 1) with the patch reverted, which is what presumably you're running
> > > now, can you try
> > > ifconfig wlan0 allmulti
> > > ifconfig wlan0 -allmulti
> > >
> > > I think this will *break* the driver right now.
> >
> > I didn't exactly understand how this supposed to break it.
>
> Ok this needs some more explaining.
>
> The old code did:
>
> if (allmulti changed)
> "set grp-filter in hw according to allmulti"
>
> the new code just did
>
> "set grp-filter in hw according to allmulti"
>
>
> During normal operation the "allmulti changed" condition is never true.
> Therefore, the old code, despite being incorrect, never broke things.
> The above would make the condition true, and lead to it being broken
> because it would change to on/off and then the grp-filter in hw would be
> off, although it's required to be on.
>
> Thus the real bug was there before my change, but it never triggered,
> and when I "optimised away" the condition I broke it.
Got it.
>
> > > 2) with the patch *not* reverted, apply the patch below and see if that
> > > fixes the problem as well (if it gets mangled, just remove the one
> > > CHK() line manually)
> > >
> > > Actually, (2) is obviously more important to me, but (1) would indicate
> > > that my guess is correct wrt. what's causing the problem
>
> > I tested (2) and it works.
>
> Thank you. I'll submit this patch instead.
>
> johannes
>
Best regards,
Maxim Levitsky
^ permalink raw reply
* [PATCH] mac80211: fix sw scan bracketing
From: Johannes Berg @ 2010-06-18 10:32 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
Currently, detection in hwsim and ath9k can
detect that two sw scans are in flight at the
same time, which isn't really true. It is
caused by a race condition, because the scan
complete callback is called too late, after
the lock has been dropped, so that a new scan
can be started before it is called.
It is also called too early semantically, as
it is currently called _after_ the return to
the operating channel -- it should be before
so that drivers know this is the operating
channel again.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/scan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- wireless-testing.orig/net/mac80211/scan.c 2010-06-18 12:22:56.000000000 +0200
+++ wireless-testing/net/mac80211/scan.c 2010-06-18 12:23:25.000000000 +0200
@@ -287,6 +287,8 @@ void ieee80211_scan_completed(struct iee
local->scanning = 0;
local->scan_channel = NULL;
+ drv_sw_scan_complete(local);
+
/* we only have to protect scan_req and hw/sw scan */
mutex_unlock(&local->scan_mtx);
@@ -296,8 +298,6 @@ void ieee80211_scan_completed(struct iee
ieee80211_configure_filter(local);
- drv_sw_scan_complete(local);
-
ieee80211_offchannel_return(local, true);
done:
^ permalink raw reply
* [PATCH] mac80211_hwsim: fix fake_hw_scan
From: Johannes Berg @ 2010-06-18 10:31 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
Since mac80211 will not set the max_scan parameters
if hw scan is enabled, hwsim needs to do it so that
cfg80211 won't reject the scan.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/mac80211_hwsim.c | 5 +++++
1 file changed, 5 insertions(+)
--- wireless-testing.orig/drivers/net/wireless/mac80211_hwsim.c 2010-06-18 12:02:50.000000000 +0200
+++ wireless-testing/drivers/net/wireless/mac80211_hwsim.c 2010-06-18 12:17:43.000000000 +0200
@@ -1291,6 +1291,11 @@ static int __init init_mac80211_hwsim(vo
hw->wiphy->n_addresses = 2;
hw->wiphy->addresses = data->addresses;
+ if (fake_hw_scan) {
+ hw->wiphy->max_scan_ssids = 255;
+ hw->wiphy->max_scan_ie_len = IEEE80211_MAX_DATA_LEN;
+ }
+
hw->channel_change_time = 1;
hw->queues = 4;
hw->wiphy->interface_modes =
^ permalink raw reply
* Re: IWL3945 problems in 2.6.35-rc1
From: Johannes Berg @ 2010-06-18 10:30 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: linux-wireless, Reinette Chatre
In-Reply-To: <1276856384.9114.3.camel@maxim-laptop>
Maxim,
Thanks for the quick reply!
> > 1) with the patch reverted, which is what presumably you're running
> > now, can you try
> > ifconfig wlan0 allmulti
> > ifconfig wlan0 -allmulti
> >
> > I think this will *break* the driver right now.
>
> I didn't exactly understand how this supposed to break it.
Ok this needs some more explaining.
The old code did:
if (allmulti changed)
"set grp-filter in hw according to allmulti"
the new code just did
"set grp-filter in hw according to allmulti"
During normal operation the "allmulti changed" condition is never true.
Therefore, the old code, despite being incorrect, never broke things.
The above would make the condition true, and lead to it being broken
because it would change to on/off and then the grp-filter in hw would be
off, although it's required to be on.
Thus the real bug was there before my change, but it never triggered,
and when I "optimised away" the condition I broke it.
> > 2) with the patch *not* reverted, apply the patch below and see if that
> > fixes the problem as well (if it gets mangled, just remove the one
> > CHK() line manually)
> >
> > Actually, (2) is obviously more important to me, but (1) would indicate
> > that my guess is correct wrt. what's causing the problem
> I tested (2) and it works.
Thank you. I'll submit this patch instead.
johannes
^ permalink raw reply
* Re: IWL3945 problems in 2.6.35-rc1
From: Maxim Levitsky @ 2010-06-18 10:19 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Reinette Chatre
In-Reply-To: <1276853327.3638.17.camel@jlt3.sipsolutions.net>
On Fri, 2010-06-18 at 11:28 +0200, Johannes Berg wrote:
> Maxim,
>
> > 2. mulicast/broadcast is broken.
> > this results in DHCP non working on open access point.
> > It seems that DHCP does work on my home wireless, but avahi-autoipd
> > doesn't see any neighbours, and this is annoying.
> > It can be worked around by doing (sudo ifconfig wlan0 promisc)
>
> Reinette has reverted the patch in iwlwifi-2.6, but I think I actually
> just now identified the problem. Can you try one or two things for me?
>
> 1) with the patch reverted, which is what presumably you're running
> now, can you try
> ifconfig wlan0 allmulti
> ifconfig wlan0 -allmulti
>
> I think this will *break* the driver right now.
I didn't exactly understand how this supposed to break it.
>
> 2) with the patch *not* reverted, apply the patch below and see if that
> fixes the problem as well (if it gets mangled, just remove the one
> CHK() line manually)
>
> Actually, (2) is obviously more important to me, but (1) would indicate
> that my guess is correct wrt. what's causing the problem
I tested (2) and it works.
Best regards,
Maximm Levitsky
^ permalink raw reply
* Re: [PATCH] ath5k: disable ASPM
From: Maxim Levitsky @ 2010-06-18 10:15 UTC (permalink / raw)
To: Jussi Kivilinna
Cc: ath5k-devel, linux-wireless, Luis R. Rodriguez, Bob Copeland
In-Reply-To: <20100618112026.17623g6uhdjk8hts@naisho.dyndns.info>
On Fri, 2010-06-18 at 11:20 +0300, Jussi Kivilinna wrote:
> Quoting "Maxim Levitsky" <maximlevitsky@gmail.com>:
>
> > On Fri, 2010-05-28 at 13:09 +0300, Jussi Kivilinna wrote:
> >> Atheros card on Acer Aspire One (AOA150, Atheros Communications Inc. AR5001
> >> Wireless Network Adapter [168c:001c] (rev 01)) doesn't work well with ASPM
> >> enabled. With ASPM ath5k will eventually stall on heavy traffic with often
> >> 'unsupported jumbo' warnings appearing. Disabling ASPM L0s/L1 in ath5k fixes
> >> these problems.
> >>
> >> Reproduced with pcie_aspm=force and by using 'nc < /dev/zero > /dev/null' at
> >> both ends (usually stalls within seconds).
> >
> > This fixes the same nasty problem on my AR2425.
> >
> > My AR2425 will stall if it transmits for about 1~2 minutes.
> >
> > It sends storm of RXORN interrupts although it only transmits.
> >
> > I see that now lspci calls it AR5001.
> >
> > Jussi Kivilinna, million thanks to you. I would never think of going
> > this direction.
> >
> > Luis, so I was right after all, wasn't I?
> > It is a hardware bug that is worked around in windows driver by
> > disabling PCIE ASPM L0S.
>
> I noticed this L0s disabling in windows driver too. I cannot test this
> anymore, since I don't have ath5k hw installed anymore (I switched to
> b43).
>
> (ok, I might switch back ath5k to work on this, but opening AAO is
> pain.. on the other hand, I'm just user in this case and pretty
> unwilling to work with dual-license)
What do you mean?
>
> I did test device with L0s+L1 enabled (aspm=force), on this setup
> device fails within seconds. I tested patch with disabling L1 but not
> L0s, still fails but after longer time. I did _not_ test with L0s off
> but L1 enabled. So maybe it would be worth to test this patch with
> just disabling L0s.
I did, and it works.
>
> AAO150 seems to enable L0s from BIOS, so this happens without
> aspm=force or CONFIG_.._ASPM at all.
Exactly.
Best regards,
Maxim Levitsky
^ 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