* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Johannes Stezenbach @ 2010-06-23 14:39 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Matthew Garrett, Jussi Kivilinna, Maxim Levitsky, David Quan,
Bob Copeland, Luis R. Rodriguez, ath5k-devel, linux-wireless,
linux-kernel, Jonathan May, Tim Gardner
In-Reply-To: <AANLkTimsEkff4sMiMB_VyWqkZOjy9PIuJ4AiC95PASOZ@mail.gmail.com>
On Tue, Jun 22, 2010 at 12:38:03PM -0700, Luis R. Rodriguez wrote:
> On Tue, Jun 22, 2010 at 12:37 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> > On Tue, Jun 22, 2010 at 12:31 PM, Johannes Stezenbach <js@sig21.net> wrote:
> >>
> >> Does CONFIG_PCIEASPM provide a way for the user to modifiy
> >> the settings at runtime?
> >
> > You can tune ASPM settings at runtime, regardless of CONFIG_PCIEASPM. See:
> >
> > http://kernel.org/pub/linux/kernel/people/mcgrof/aspm/enable-aspm
> > http://wireless.kernel.org/en/users/Documentation/ASPM
> >
> >> I have a Samsung N130 netbook which has a BIOS setting
> >> called "CPU Power Saving Mode". When enabled it activates
> >> ASPM L1 and L0s for the ethernet chip (Realtek RTL8102e, 100Mbit)
> >> and the PCIE bridge (with the BIOS setting off it's just L1).
> >> The result is that the ethernet througput is reduced to 25Mbit/s.
> >
> > L0s is not going to buy you much gains, getting at least L1 will
> > however. L0s is just a further enhancement. I recommend you test by
> > enabling L1 and L0s, check how longer your battery lasts and then test
> > again with just L1. Then test without both L1 and L0s.
>
> So defaults should always be sane and you should not have to play with
> this stuff, unless you're a hacker, or are testing something for
> development purposes. Tweaking ASPM settings is not something a user
> should have to worry about. Period.
OK, let me put the question another way:
If enabling ASPM comes with a performance penalty (which is not unexpected,
there is usually a tradeoff between performance and power consumption),
do you think a boot time option (pcie_aspm=) or compile time option
(CONFIG_PCIEASPM) is the right user interface?
But meanwhile I found that CONFIG_PCIEASPM has a runtime
interface, /sys/module/pcie_aspm/parameters/policy.
http://lwn.net/Articles/266585/
I have not tested it on my N130 yet.
Johannes
^ permalink raw reply
* [PATCH 2/3] libertas: unmangle capability value
From: John W. Linville @ 2010-06-23 14:37 UTC (permalink / raw)
To: linux-wireless; +Cc: dkiran, Johannes Berg, John W. Linville
In-Reply-To: <1277281556.3642.6.camel@jlt3.sipsolutions.net>
Address fall-out from patch converting libertas to use cfg80211...
+drivers/net/wireless/libertas/cfg.c:1844:13: warning: incorrect type in assignment (different base types)
+drivers/net/wireless/libertas/cfg.c:1844:13: expected unsigned short [unsigned] [usertype] capability
+drivers/net/wireless/libertas/cfg.c:1844:13: got restricted __le16 [usertype] <noident>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/libertas/cfg.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/libertas/cfg.c b/drivers/net/wireless/libertas/cfg.c
index 23c1dc6..f36cc97 100644
--- a/drivers/net/wireless/libertas/cfg.c
+++ b/drivers/net/wireless/libertas/cfg.c
@@ -1841,7 +1841,7 @@ static int lbs_ibss_start_new(struct lbs_private *priv,
if (MRVL_FW_MAJOR_REV(priv->fwrelease) <= 8)
cmd.probedelay = cpu_to_le16(CMD_SCAN_PROBE_DELAY_TIME);
/* TODO: mix in WLAN_CAPABILITY_PRIVACY */
- capability = cpu_to_le16(WLAN_CAPABILITY_IBSS);
+ capability = WLAN_CAPABILITY_IBSS;
cmd.capability = cpu_to_le16(capability);
lbs_add_rates(cmd.rates);
--
1.7.0.1
^ permalink raw reply related
* [PATCH 3/3] libertas: mark lbs_ret_802_11d_domain_info static
From: John W. Linville @ 2010-06-23 14:37 UTC (permalink / raw)
To: linux-wireless; +Cc: dkiran, Johannes Berg, John W. Linville
In-Reply-To: <1277281556.3642.6.camel@jlt3.sipsolutions.net>
Probably little risk of namespace polution, but good practice... :-)
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/libertas/cmdresp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/libertas/cmdresp.c b/drivers/net/wireless/libertas/cmdresp.c
index b4bc103..a0d9482 100644
--- a/drivers/net/wireless/libertas/cmdresp.c
+++ b/drivers/net/wireless/libertas/cmdresp.c
@@ -103,7 +103,7 @@ static int lbs_ret_reg_access(struct lbs_private *priv,
* @param resp pointer to command response buffer
* @return 0; -1
*/
-int lbs_ret_802_11d_domain_info(struct cmd_ds_command *resp)
+static int lbs_ret_802_11d_domain_info(struct cmd_ds_command *resp)
{
struct cmd_ds_802_11d_domain_info *domaininfo =
&resp->params.domaininforesp;
--
1.7.0.1
^ permalink raw reply related
* [PATCH 1/3] libertas: fix build error due to undefined symbol
From: John W. Linville @ 2010-06-23 14:37 UTC (permalink / raw)
To: linux-wireless; +Cc: dkiran, Johannes Berg, John W. Linville
In-Reply-To: <1277281556.3642.6.camel@jlt3.sipsolutions.net>
ERROR: "mesh_handler_def" [drivers/net/wireless/libertas/libertas.ko] undefined!
Caused by a hunk missed by "Libertas: cfg80211 support" when building
with CONFIG_WIRELESS_EXT enabled.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/libertas/mesh.c | 3 ---
drivers/net/wireless/libertas/mesh.h | 5 -----
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/libertas/mesh.c b/drivers/net/wireless/libertas/mesh.c
index 00b36b0..bc5bc13 100644
--- a/drivers/net/wireless/libertas/mesh.c
+++ b/drivers/net/wireless/libertas/mesh.c
@@ -370,9 +370,6 @@ int lbs_add_mesh(struct lbs_private *priv)
SET_NETDEV_DEV(priv->mesh_dev, priv->dev->dev.parent);
-#ifdef WIRELESS_EXT
- mesh_dev->wireless_handlers = &mesh_handler_def;
-#endif
mesh_dev->flags |= IFF_BROADCAST | IFF_MULTICAST;
/* Register virtual mesh interface */
ret = register_netdev(mesh_dev);
diff --git a/drivers/net/wireless/libertas/mesh.h b/drivers/net/wireless/libertas/mesh.h
index e257330..84ea248 100644
--- a/drivers/net/wireless/libertas/mesh.h
+++ b/drivers/net/wireless/libertas/mesh.h
@@ -70,11 +70,6 @@ void lbs_persist_config_init(struct net_device *net);
void lbs_persist_config_remove(struct net_device *net);
-/* WEXT handler */
-
-extern struct iw_handler_def mesh_handler_def;
-
-
/* Ethtool statistics */
struct ethtool_stats;
--
1.7.0.1
^ permalink raw reply related
* Re: 2.6.34 kernel + compat-wireless + Bluez-4.66 --- no Bluetooth devices
From: Luis R. Rodriguez @ 2010-06-23 16:30 UTC (permalink / raw)
To: Andrei Moraru; +Cc: linux-wireless
In-Reply-To: <AANLkTiljOFA7zY_wyP6p-4lCTHT_dhrEUuL2ktvvOsvc@mail.gmail.com>
On Wed, Jun 23, 2010 at 2:04 AM, Andrei Moraru
<andrei.moraru.n@gmail.com> wrote:
> Hello,
>
> I have a machine with Centos 5.4, kernel version 2.6.34, Bluez-4.66,
> compat-wireless for 2.6.34 kernel version.
>
> The system knows about USB Bluetooth adapters
>
> [root@voip ~]# lsusb
> Bus 002 Device 004: ID 1131:1001 Integrated System Solution Corp.
> KY-BT100 Bluetooth Adapter
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 002 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd
> Bluetooth Dongle (HCI mode)
> Bus 002 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd
> Bluetooth Dongle (HCI mode)
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> However, hciconfig shows no devices:
>
> [root@voip ~]# hciconfig -a
> [root@voip ~]#
>
>
> Also, hcitool dev
>
> [root@voip ~]# hcitool dev
> Devices:
>
> the dmesg output about bluetooth shows
>
> Bluetooth: Core ver 2.15
> NET: Registered protocol family 31
> Bluetooth: HCI device and connection manager initialized
> Bluetooth: HCI socket layer initialized
> Bluetooth: L2CAP ver 2.14
> Bluetooth: L2CAP socket layer initialized
> Bluetooth: SCO (Voice Link) ver 0.6
> Bluetooth: SCO socket layer initialized
> Bluetooth: HIDP (Human Interface Emulation) ver 1.2
> Bluetooth: RFCOMM TTY layer initialized
> Bluetooth: RFCOMM socket layer initialized
> Bluetooth: RFCOMM ver 1.11
> Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> Bluetooth: BNEP filters: protocol multicast
>
>
> Please suggest your opinions.
dmesg looks good, repost to linux-bluetooth and show also the version
of compat-wireless you used.
Luis
^ permalink raw reply
* Re: [PATCH] wireless: orphan ipw2x00 drivers
From: maximilian attems @ 2010-06-23 16:33 UTC (permalink / raw)
To: reinette chatre
Cc: Zhu Yi, linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1276186201.1835.17488.camel@rchatre-DESK>
On Thu, 10 Jun 2010, reinette chatre wrote:
> On Wed, 2010-06-09 at 18:44 -0700, Zhu Yi wrote:
> > Signed-off-by: Zhu Yi <yi.zhu@intel.com>
>
> Not sure if it is needed but the sourceforge pages will still have the
> firmware available for download. We are in process of cleaning those
> pages up.
while you are at it:
it be cool to have the firmware license also "cleaned up" to allow
at least distribution.
thanks
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Luis R. Rodriguez @ 2010-06-23 16:28 UTC (permalink / raw)
To: Johannes Stezenbach
Cc: Matthew Garrett, Jussi Kivilinna, Maxim Levitsky, David Quan,
Bob Copeland, Luis R. Rodriguez, ath5k-devel, linux-wireless,
linux-kernel, Jonathan May, Tim Gardner
In-Reply-To: <20100623143940.GA5424@sig21.net>
On Wed, Jun 23, 2010 at 7:39 AM, Johannes Stezenbach <js@sig21.net> wrote:
> On Tue, Jun 22, 2010 at 12:38:03PM -0700, Luis R. Rodriguez wrote:
>> On Tue, Jun 22, 2010 at 12:37 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> > On Tue, Jun 22, 2010 at 12:31 PM, Johannes Stezenbach <js@sig21.net> wrote:
>> >>
>> >> Does CONFIG_PCIEASPM provide a way for the user to modifiy
>> >> the settings at runtime?
>> >
>> > You can tune ASPM settings at runtime, regardless of CONFIG_PCIEASPM. See:
>> >
>> > http://kernel.org/pub/linux/kernel/people/mcgrof/aspm/enable-aspm
>> > http://wireless.kernel.org/en/users/Documentation/ASPM
>> >
>> >> I have a Samsung N130 netbook which has a BIOS setting
>> >> called "CPU Power Saving Mode". When enabled it activates
>> >> ASPM L1 and L0s for the ethernet chip (Realtek RTL8102e, 100Mbit)
>> >> and the PCIE bridge (with the BIOS setting off it's just L1).
>> >> The result is that the ethernet througput is reduced to 25Mbit/s.
>> >
>> > L0s is not going to buy you much gains, getting at least L1 will
>> > however. L0s is just a further enhancement. I recommend you test by
>> > enabling L1 and L0s, check how longer your battery lasts and then test
>> > again with just L1. Then test without both L1 and L0s.
>>
>> So defaults should always be sane and you should not have to play with
>> this stuff, unless you're a hacker, or are testing something for
>> development purposes. Tweaking ASPM settings is not something a user
>> should have to worry about. Period.
>
> OK, let me put the question another way:
>
> If enabling ASPM comes with a performance penalty (which is not unexpected,
> there is usually a tradeoff between performance and power consumption),
> do you think a boot time option (pcie_aspm=) or compile time option
> (CONFIG_PCIEASPM) is the right user interface?
>
>
> But meanwhile I found that CONFIG_PCIEASPM has a runtime
> interface, /sys/module/pcie_aspm/parameters/policy.
> http://lwn.net/Articles/266585/
>
> I have not tested it on my N130 yet.
Same thing, its to be used by developers not users, damn it we should
just remove this crap.
Luis
^ permalink raw reply
* Re: [RFC/RFT] minstrel_ht: new rate control module for 802.11n
From: Björn Smedman @ 2010-06-23 16:36 UTC (permalink / raw)
To: Felix Fietkau
Cc: linux-wireless, Derek Smithies, Benoit PAPILLAULT,
Luis R. Rodriguez, Christian Lamparter, Johannes Berg,
ath9k-devel
In-Reply-To: <4B8D396B.5040007@openwrt.org>
2010/3/2 Felix Fietkau <nbd@openwrt.org>:
> On 2010-03-02 4:47 PM, Björn Smedman wrote:
>> 2010/3/2 Felix Fietkau <nbd@openwrt.org>:
[snip]
>> You mean the hardware interprets the block-ack and keeps retrying the
>> un-acked frames? I thought it stopped as soon as it got a block-ack to
>> let software sort out the acked and un-acked frames and handle the
>> "partial" A-MPDU retry.
> Not sure, actually. I just looked at the ath9k tx path again, and it
> seems that you're right. However it looks like it's not sending rate
> control updates until it's done with the software retry, so that's
> probably the reason why I wasn't able to make it more precise yet.
I had another look at the code now and if I read it correctly this
delay in the rate control feedback is really scary. In the extreme
case where all the rates in the MRR stop working you have to make 10
(ATH_MAX_SW_RETRIES) aggregate software retries (of about 20 frames
each) with approx 10 hardware retries each before you give the rate
control algorithm any feedback whatsoever. That is a worst case of
several thousand (pointless) subframe retransmissions before the rate
control algorithm has a chance to adjust...
If I'm not wrong above then the rate control feedback must also be
incorrect: a disaster of that magnitude simply cannot be conveyed to
the rate control algorithm through the thin tx status interface. As
far as I can tell, whenever the first subframe of an aggregate fails
and is software retried, the rate control feedback for that aggregate
is lost (ath_tx_rc_status() is never called with update_rc = true in
xmit.c).
Any ideas on how to fix this? To me the aggregation and rate control
code seems to need a major overhaul, something which would require
changes to the interface between mac80211 and drivers, e.g. ath9k.
That's out of my league unfortunately...
^ permalink raw reply
* Re: [PATCH] wireless: orphan ipw2x00 drivers
From: reinette chatre @ 2010-06-23 16:42 UTC (permalink / raw)
To: maximilian attems
Cc: Zhu, Yi, linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <20100623163335.GA14856@stro.at>
On Wed, 2010-06-23 at 09:33 -0700, maximilian attems wrote:
> On Thu, 10 Jun 2010, reinette chatre wrote:
>
> > On Wed, 2010-06-09 at 18:44 -0700, Zhu Yi wrote:
> > > Signed-off-by: Zhu Yi <yi.zhu@intel.com>
> >
> > Not sure if it is needed but the sourceforge pages will still have the
> > firmware available for download. We are in process of cleaning those
> > pages up.
>
> while you are at it:
> it be cool to have the firmware license also "cleaned up" to allow
> at least distribution.
Please see http://ipw2100.sourceforge.net/firmware_faq.php
Reinette
^ permalink raw reply
* Re: [PATCH] wireless: orphan ipw2x00 drivers
From: maximilian attems @ 2010-06-23 16:39 UTC (permalink / raw)
To: reinette chatre
Cc: Zhu, Yi, linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1277311325.25793.2299.camel@rchatre-DESK>
On Wed, Jun 23, 2010 at 09:42:05AM -0700, reinette chatre wrote:
> On Wed, 2010-06-23 at 09:33 -0700, maximilian attems wrote:
> > On Thu, 10 Jun 2010, reinette chatre wrote:
> >
> > > On Wed, 2010-06-09 at 18:44 -0700, Zhu Yi wrote:
> > > > Signed-off-by: Zhu Yi <yi.zhu@intel.com>
> > >
> > > Not sure if it is needed but the sourceforge pages will still have the
> > > firmware available for download. We are in process of cleaning those
> > > pages up.
> >
> > while you are at it:
> > it be cool to have the firmware license also "cleaned up" to allow
> > at least distribution.
>
> Please see http://ipw2100.sourceforge.net/firmware_faq.php
I know that strange page and we (Debian) adhere to it.
still sad that you don't care to change it now that you don't care
anymore about the driver.
^ permalink raw reply
* Re: [RFC/RFT] minstrel_ht: new rate control module for 802.11n
From: Felix Fietkau @ 2010-06-23 17:07 UTC (permalink / raw)
To: Björn Smedman
Cc: linux-wireless, Derek Smithies, Benoit PAPILLAULT,
Luis R. Rodriguez, Christian Lamparter, Johannes Berg,
ath9k-devel
In-Reply-To: <AANLkTilWfp6LzCYhxFweqAP_GceRz5PQBIBl5AksLKUf@mail.gmail.com>
On 2010-06-23 6:36 PM, Björn Smedman wrote:
> 2010/3/2 Felix Fietkau <nbd@openwrt.org>:
>> On 2010-03-02 4:47 PM, Björn Smedman wrote:
>>> 2010/3/2 Felix Fietkau <nbd@openwrt.org>:
> [snip]
>>> You mean the hardware interprets the block-ack and keeps retrying the
>>> un-acked frames? I thought it stopped as soon as it got a block-ack to
>>> let software sort out the acked and un-acked frames and handle the
>>> "partial" A-MPDU retry.
>> Not sure, actually. I just looked at the ath9k tx path again, and it
>> seems that you're right. However it looks like it's not sending rate
>> control updates until it's done with the software retry, so that's
>> probably the reason why I wasn't able to make it more precise yet.
>
> I had another look at the code now and if I read it correctly this
> delay in the rate control feedback is really scary. In the extreme
> case where all the rates in the MRR stop working you have to make 10
> (ATH_MAX_SW_RETRIES) aggregate software retries (of about 20 frames
> each) with approx 10 hardware retries each before you give the rate
> control algorithm any feedback whatsoever. That is a worst case of
> several thousand (pointless) subframe retransmissions before the rate
> control algorithm has a chance to adjust...
Yes, the extreme case is currently not handled properly. However the
extreme case is also extremely unlikely to trigger. With minstrel_ht,
the max_prob_rate is always in the MRR series. If the conditions jump
from all rates working down to even max_prob_rate failing, then
something must be so wrong with the radio, that there's probably no
possibility of a graceful fallback at all. I do agree that this should
be fixed, though.
> If I'm not wrong above then the rate control feedback must also be
> incorrect: a disaster of that magnitude simply cannot be conveyed to
> the rate control algorithm through the thin tx status interface. As
> far as I can tell, whenever the first subframe of an aggregate fails
> and is software retried, the rate control feedback for that aggregate
> is lost (ath_tx_rc_status() is never called with update_rc = true in
> xmit.c).
I think you misread that part. The loop iterates over all subframes in
the aggregate, and the first successful or swretry-expired frame will
trigger an AMPDU status report, which will update the RC. The first
subframe of the A-MPDU is not getting any special treatment here.
> Any ideas on how to fix this? To me the aggregation and rate control
> code seems to need a major overhaul, something which would require
> changes to the interface between mac80211 and drivers, e.g. ath9k.
> That's out of my league unfortunately...
I've already made a lot of progress rewriting the entire aggregation
logic (it'll be in mac80211 instead of ath9k).
As soon as I'm done fixing the current batch of bugs that I'm debugging
at the moment, I will post my changes as RFC on the linux-wireless list.
- Felix
^ permalink raw reply
* Re: 2.6.34 kernel + compat-wireless + Bluez-4.66 --- no Bluetooth devices
From: Andrei Moraru @ 2010-06-23 17:19 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <AANLkTimcw-AVVFGbSJioJIcVw75tzUYCKt4plNMtQJr1@mail.gmail.com>
On Wed, Jun 23, 2010 at 7:30 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Wed, Jun 23, 2010 at 2:04 AM, Andrei Moraru
> <andrei.moraru.n@gmail.com> wrote:
>> Hello,
>>
>> I have a machine with Centos 5.4, kernel version 2.6.34, Bluez-4.66,
>> compat-wireless for 2.6.34 kernel version.
>>
>> The system knows about USB Bluetooth adapters
>>
>> [root@voip ~]# lsusb
>> Bus 002 Device 004: ID 1131:1001 Integrated System Solution Corp.
>> KY-BT100 Bluetooth Adapter
>> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>> Bus 002 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd
>> Bluetooth Dongle (HCI mode)
>> Bus 002 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd
>> Bluetooth Dongle (HCI mode)
>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>
>> However, hciconfig shows no devices:
>>
>> [root@voip ~]# hciconfig -a
>> [root@voip ~]#
>>
>>
>> Also, hcitool dev
>>
>> [root@voip ~]# hcitool dev
>> Devices:
>>
>> the dmesg output about bluetooth shows
>>
>> Bluetooth: Core ver 2.15
>> NET: Registered protocol family 31
>> Bluetooth: HCI device and connection manager initialized
>> Bluetooth: HCI socket layer initialized
>> Bluetooth: L2CAP ver 2.14
>> Bluetooth: L2CAP socket layer initialized
>> Bluetooth: SCO (Voice Link) ver 0.6
>> Bluetooth: SCO socket layer initialized
>> Bluetooth: HIDP (Human Interface Emulation) ver 1.2
>> Bluetooth: RFCOMM TTY layer initialized
>> Bluetooth: RFCOMM socket layer initialized
>> Bluetooth: RFCOMM ver 1.11
>> Bluetooth: BNEP (Ethernet Emulation) ver 1.3
>> Bluetooth: BNEP filters: protocol multicast
>>
>>
>> Please suggest your opinions.
>
> dmesg looks good, repost to linux-bluetooth and show also the version
> of compat-wireless you used.
>
> Luis
>
Thanks Luis.
I solved the issue with no BT devices on hciconfig -a
The problem was that 2.6.34 kernel was built without HCI USB support.
So, I have rebuilt it, rebooted, then the hciconfig -a shows me BT
dongles.
The sugestion was made to me on #bluez-users on freenode
Ok, after detection of BT devices, i rebuilt the compat-wireless with
new kernel sources. When make btload was issued, then the dmesg output
was many lines similar to:
Jun 23 17:13:31 voip kernel: l2cap: Unknown symbol bt_sock_wait_state
Jun 23 17:13:31 voip kernel: l2cap: disagrees about version of symbol
bt_sock_register
The steps to get rid of that errors were:
1) be sure no bluetooth related file is in use:
the command:
lsof | grep blue*
should return nothing
2) remove all Bluez-4.66 files (hciconfig, libbluetooth.so, etc)
3) rebuilt the Bluez-4.66
4) start the compat-wireless stack
make btload
Now, the dmesg shows me clear output,
Bluetooth: Core ver 2.15
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: Generic Bluetooth USB driver ver 0.6
usbcore: registered new interface driver btusb
Bluetooth: L2CAP ver 2.14
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO (Voice Link) ver 0.6
Bluetooth: SCO socket layer initialized
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM ver 1.11
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Thats all.
Andrei Moraru.
^ permalink raw reply
* Re: [PATCH] ath9k: Fix the LED behaviour in idle unassociated state.
From: Pavel Roskin @ 2010-06-23 17:55 UTC (permalink / raw)
To: Vivek Natarajan; +Cc: linville, linux-wireless
In-Reply-To: <1277275109-4662-1-git-send-email-vnatarajan@atheros.com>
On Wed, 2010-06-23 at 12:08 +0530, Vivek Natarajan wrote:
> LED should be ON when the radio is put into FULL SLEEP mode during the idle
> unassociated state.
Why? Is there any written policy for the LED behavior? I think we want
to conserve power if sleeping, which means turning LEDs off.
Or is it a workaround for some quirk in Atheros hardware?
In any case, I don't like the new comment. The comment says "Keep the
LED on...", but the code is still turning the LED off.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] ath9k: declare MODULE_FIRMWARE for ath9k_htc
From: John W. Linville @ 2010-06-23 18:23 UTC (permalink / raw)
To: linux-wireless; +Cc: ath9k-devel, John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 74bc80f..4949f83 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -16,6 +16,11 @@
#include "htc.h"
+/* identify firmware images */
+MODULE_FIRMWARE("ar7010.fw");
+MODULE_FIRMWARE("ar7010_1_1.fw");
+MODULE_FIRMWARE("ar9271.fw");
+
static struct usb_device_id ath9k_hif_usb_ids[] = {
{ USB_DEVICE(0x0cf3, 0x9271) }, /* Atheros */
{ USB_DEVICE(0x0cf3, 0x1006) }, /* Atheros */
--
1.7.0.1
^ permalink raw reply related
* Re: [RFC/RFT] minstrel_ht: new rate control module for 802.11n
From: Björn Smedman @ 2010-06-23 18:47 UTC (permalink / raw)
To: Felix Fietkau
Cc: linux-wireless, Derek Smithies, Benoit PAPILLAULT,
Luis R. Rodriguez, Christian Lamparter, Johannes Berg,
ath9k-devel
In-Reply-To: <4C223F58.3060509@openwrt.org>
2010/6/23 Felix Fietkau <nbd@openwrt.org>:
> On 2010-06-23 6:36 PM, Björn Smedman wrote:
[snip]
>> If I'm not wrong above then the rate control feedback must also be
>> incorrect: a disaster of that magnitude simply cannot be conveyed to
>> the rate control algorithm through the thin tx status interface. As
>> far as I can tell, whenever the first subframe of an aggregate fails
>> and is software retried, the rate control feedback for that aggregate
>> is lost (ath_tx_rc_status() is never called with update_rc = true in
>> xmit.c).
> I think you misread that part. The loop iterates over all subframes in
> the aggregate, and the first successful or swretry-expired frame will
> trigger an AMPDU status report, which will update the RC. The first
> subframe of the A-MPDU is not getting any special treatment here.
You're right, I missed that part. And I guess that's also why the
worst case is so rare.
But on the other hand doesn't that also mean that MRR rates and counts
in the tx status will be incorrect? I.e. one set of rates/counts used
to transmit the aggregate (first subframe) and (possibly) another set
reported back in tx status (first acked/expired subframe)?
Also, bf->bf_retries is used in ath_tx_rc_status() but the logic makes
no sense if bf_retries holds the number of software retries...
>> Any ideas on how to fix this? To me the aggregation and rate control
>> code seems to need a major overhaul, something which would require
>> changes to the interface between mac80211 and drivers, e.g. ath9k.
>> That's out of my league unfortunately...
> I've already made a lot of progress rewriting the entire aggregation
> logic (it'll be in mac80211 instead of ath9k).
> As soon as I'm done fixing the current batch of bugs that I'm debugging
> at the moment, I will post my changes as RFC on the linux-wireless list.
Very nice to hear a rewrite is in progress. :) Looking forward to those patches.
> - Felix
>
/Björn
^ permalink raw reply
* [PATCH v2] ath9k: declare MODULE_FIRMWARE for ath9k_htc
From: John W. Linville @ 2010-06-23 18:50 UTC (permalink / raw)
To: linux-wireless; +Cc: ath9k-devel, John W. Linville
In-Reply-To: <1277317393-20245-1-git-send-email-linville@tuxdriver.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
v2 -> avoid duplicate strings for firmware names and simultaneously
attract attention to MODULE_FIRMWARE section in the even of
any updates
drivers/net/wireless/ath/ath9k/hif_usb.c | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 74bc80f..ad9134b 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -16,6 +16,15 @@
#include "htc.h"
+/* identify firmware images */
+#define FIRMWARE_AR7010 "ar7010.fw"
+#define FIRMWARE_AR7010_1_1 "ar7010_1_1.fw"
+#define FIRMWARE_AR9271 "ar9271.fw"
+
+MODULE_FIRMWARE(FIRMWARE_AR7010);
+MODULE_FIRMWARE(FIRMWARE_AR7010_1_1);
+MODULE_FIRMWARE(FIRMWARE_AR9271);
+
static struct usb_device_id ath9k_hif_usb_ids[] = {
{ USB_DEVICE(0x0cf3, 0x9271) }, /* Atheros */
{ USB_DEVICE(0x0cf3, 0x1006) }, /* Atheros */
@@ -890,12 +899,12 @@ static int ath9k_hif_usb_probe(struct usb_interface *interface,
case 0x7010:
case 0x9018:
if (le16_to_cpu(udev->descriptor.bcdDevice) == 0x0202)
- hif_dev->fw_name = "ar7010_1_1.fw";
+ hif_dev->fw_name = FIRMWARE_AR7010_1_1;
else
- hif_dev->fw_name = "ar7010.fw";
+ hif_dev->fw_name = FIRMWARE_AR7010;
break;
default:
- hif_dev->fw_name = "ar9271.fw";
+ hif_dev->fw_name = FIRMWARE_AR9271;
break;
}
--
1.7.0.1
^ permalink raw reply related
* Compat-wireless release for 2010-06-23 is baked
From: Compat-wireless cronjob account @ 2010-06-23 19:03 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
7df472d..87dca92 master -> origin/master
8e2a8ea..dac1811 wl -> origin/wl
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
41d99c6..951149c history -> origin/history
+ d82e647...fca5ab0 master -> origin/master (forced update)
* [new tag] next-20100623 -> next-20100623
compat-wireless code metrics
498619 - Total upstream lines of code being pulled
1410 - backport code changes
1177 - backport code additions
233 - backport code deletions
5748 - backport from compat module
7158 - total backport code
1.4356 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet posted
39 - Crap deletions not yet posted
0.2443 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100623
compat-wireless release: compat-wireless-2010-06-17-4-g87dca92
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Johannes Stezenbach @ 2010-06-23 19:07 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Matthew Garrett, Jussi Kivilinna, Maxim Levitsky, David Quan,
Bob Copeland, Luis R. Rodriguez, ath5k-devel, linux-wireless,
linux-kernel, Jonathan May, Tim Gardner
In-Reply-To: <AANLkTilyQB-q8Xf9Mu3F5SnKbRqbBuLjbdx8EcyCt_0v@mail.gmail.com>
On Wed, Jun 23, 2010 at 09:28:57AM -0700, Luis R. Rodriguez wrote:
> On Wed, Jun 23, 2010 at 7:39 AM, Johannes Stezenbach <js@sig21.net> wrote:
> >
> > If enabling ASPM comes with a performance penalty (which is not unexpected,
> > there is usually a tradeoff between performance and power consumption),
> > do you think a boot time option (pcie_aspm=) or compile time option
> > (CONFIG_PCIEASPM) is the right user interface?
> >
> >
> > But meanwhile I found that CONFIG_PCIEASPM has a runtime
> > interface, /sys/module/pcie_aspm/parameters/policy.
> > http://lwn.net/Articles/266585/
>
> Same thing, its to be used by developers not users, damn it we should
> just remove this crap.
Hopefully I got at least the message across that there is
a good reason to have an interface where the user can
select the ASPM policy?
If your answer is "reboot and change the BIOS setting" then
you didn't get what I was talking about _at all_.
Also, having now briefly looked at pcie/aspm.c, I do not share your
opinion that it is crap, except maybe for the force enable.
If I read it correctly it will by default keep the BIOS settings,
but offers a per-device sysfs attribute to change the ASPM link
state, and it seems to do sanity checking, and takes care that
both ends of the link agree.
(disclaimer: I haven't tested any of it, only briefly looked at the code)
Johannes
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Johannes Stezenbach @ 2010-06-23 19:23 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Matthew Garrett, Jussi Kivilinna, Maxim Levitsky, David Quan,
Bob Copeland, Luis R. Rodriguez, ath5k-devel, linux-wireless,
linux-kernel, Jonathan May, Tim Gardner
In-Reply-To: <AANLkTin1fAAgYTYegqaadkYIYP2NXRNRzCR48e-uIgYV@mail.gmail.com>
On Tue, Jun 22, 2010 at 12:37:01PM -0700, Luis R. Rodriguez wrote:
> On Tue, Jun 22, 2010 at 12:31 PM, Johannes Stezenbach <js@sig21.net> wrote:
> > I have a Samsung N130 netbook which has a BIOS setting
> > called "CPU Power Saving Mode". When enabled it activates
> > ASPM L1 and L0s for the ethernet chip (Realtek RTL8102e, 100Mbit)
> > and the PCIE bridge (with the BIOS setting off it's just L1).
> > The result is that the ethernet througput is reduced to 25Mbit/s.
> > (The BIOS setting does not activa L0s for the Atheros AR9285 WLAN.)
>
> L0s is not going to buy you much gains, getting at least L1 will
> however. L0s is just a further enhancement. I recommend you test by
> enabling L1 and L0s, check how longer your battery lasts and then test
> again with just L1. Then test without both L1 and L0s.
What I did was to dump lspci output to a file, for both settings
of the BIOS option, and then diff.
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) (prog-if 00 [Normal decode])
...
LnkCap: Port #3, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
- LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
+ LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)
...
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot-
- LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
+ LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
I suspect the performance penalty is because L0s is entered very often
even during ethernet bulk transfer, whereas L1 is only entered
when the link is idle for longer time.
The difference in battery run time due to the BIOS option is
significant (IIRC, it's been a while back), but I don't know
what else the BIOS option changes.
Johannes
^ permalink raw reply
* Re: [RFC/RFT] minstrel_ht: new rate control module for 802.11n
From: Felix Fietkau @ 2010-06-23 19:27 UTC (permalink / raw)
To: Björn Smedman
Cc: linux-wireless, Derek Smithies, Benoit PAPILLAULT,
Luis R. Rodriguez, Christian Lamparter, Johannes Berg,
ath9k-devel
In-Reply-To: <AANLkTilDTZRUk_3iI5NPX0JhqG7N8LtKcE3VSSnqFGk9@mail.gmail.com>
On 2010-06-23 8:47 PM, Björn Smedman wrote:
> 2010/6/23 Felix Fietkau <nbd@openwrt.org>:
>> On 2010-06-23 6:36 PM, Björn Smedman wrote:
> [snip]
>>> If I'm not wrong above then the rate control feedback must also be
>>> incorrect: a disaster of that magnitude simply cannot be conveyed to
>>> the rate control algorithm through the thin tx status interface. As
>>> far as I can tell, whenever the first subframe of an aggregate fails
>>> and is software retried, the rate control feedback for that aggregate
>>> is lost (ath_tx_rc_status() is never called with update_rc = true in
>>> xmit.c).
>> I think you misread that part. The loop iterates over all subframes in
>> the aggregate, and the first successful or swretry-expired frame will
>> trigger an AMPDU status report, which will update the RC. The first
>> subframe of the A-MPDU is not getting any special treatment here.
>
> You're right, I missed that part. And I guess that's also why the
> worst case is so rare.
>
> But on the other hand doesn't that also mean that MRR rates and counts
> in the tx status will be incorrect? I.e. one set of rates/counts used
> to transmit the aggregate (first subframe) and (possibly) another set
> reported back in tx status (first acked/expired subframe)?
No, MRR info is just fine. The retry stats are reported for the whole
A-MPDU, not for indvididual subframes. It's always present in the last
descriptor of the whole batch. Also, since my code cleanup a while ago,
the converted rx/tx status info is not longer part of the allocated
descriptor space, but instead kept on stack in the function that
processes the tx status. This on stack tx status is then passed to the
rc update function, which sends the data to mac80211 along with the
AMPDU tx status report.
> Also, bf->bf_retries is used in ath_tx_rc_status() but the logic makes
> no sense if bf_retries holds the number of software retries...
Hmm, that part might indeed be buggy. I'll review it in detail when I'm
at home again.
- Felix
^ permalink raw reply
* wireless-next-2.6 rebase 2010-06-23
From: John W. Linville @ 2010-06-23 19:42 UTC (permalink / raw)
To: linux-wireless
FYI...in order to avoid merging a patch series with build breakage, I'm
rebasing wireless-next-2.6. The master-2010-06-21 tag is still valid,
but the master-2010-06-22 tag is no longer an ancestor of master.
If you have no idea what I mean, then feel free to ignore this
message. :-) Most people should be using wireless-testing anyway.
Thanks,
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Recent results with BCM4312 on Netbook
From: Larry Finger @ 2010-06-23 20:49 UTC (permalink / raw)
To: Michael Büsch; +Cc: Gábor Stefanik, wireless, b43-dev
In-Reply-To: <4C22014A.3000102@bu3sch.de>
On 06/23/2010 07:42 AM, Michael Büsch wrote:
> Please note that there were some rewrites recently in the kernel
> DMA subsystem. b43 does now use the generic DMA interface, which
> should work on all busses. I would not rule out an error in
> that area, though it's unlikely.
I don't think that is a problem. None of my other 3 systems developed an
error with that change. In addition, the Netbook started working as
mysteriously as it had failed earlier. I just love intermittent cases. ;-)
Larry
^ permalink raw reply
* Re: [PATCH 1/3] libertas: fix build error due to undefined symbol
From: Dan Williams @ 2010-06-23 23:24 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, dkiran, Johannes Berg
In-Reply-To: <1277303846-17257-1-git-send-email-linville@tuxdriver.com>
On Wed, 2010-06-23 at 10:37 -0400, John W. Linville wrote:
> ERROR: "mesh_handler_def" [drivers/net/wireless/libertas/libertas.ko] undefined!
>
> Caused by a hunk missed by "Libertas: cfg80211 support" when building
> with CONFIG_WIRELESS_EXT enabled.
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Acked-by: Dan Williams <dcbw@redhat.com>
> ---
> drivers/net/wireless/libertas/mesh.c | 3 ---
> drivers/net/wireless/libertas/mesh.h | 5 -----
> 2 files changed, 0 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/mesh.c b/drivers/net/wireless/libertas/mesh.c
> index 00b36b0..bc5bc13 100644
> --- a/drivers/net/wireless/libertas/mesh.c
> +++ b/drivers/net/wireless/libertas/mesh.c
> @@ -370,9 +370,6 @@ int lbs_add_mesh(struct lbs_private *priv)
>
> SET_NETDEV_DEV(priv->mesh_dev, priv->dev->dev.parent);
>
> -#ifdef WIRELESS_EXT
> - mesh_dev->wireless_handlers = &mesh_handler_def;
> -#endif
> mesh_dev->flags |= IFF_BROADCAST | IFF_MULTICAST;
> /* Register virtual mesh interface */
> ret = register_netdev(mesh_dev);
> diff --git a/drivers/net/wireless/libertas/mesh.h b/drivers/net/wireless/libertas/mesh.h
> index e257330..84ea248 100644
> --- a/drivers/net/wireless/libertas/mesh.h
> +++ b/drivers/net/wireless/libertas/mesh.h
> @@ -70,11 +70,6 @@ void lbs_persist_config_init(struct net_device *net);
> void lbs_persist_config_remove(struct net_device *net);
>
>
> -/* WEXT handler */
> -
> -extern struct iw_handler_def mesh_handler_def;
> -
> -
> /* Ethtool statistics */
>
> struct ethtool_stats;
^ permalink raw reply
* Re: [PATCH 2/3] libertas: unmangle capability value
From: Dan Williams @ 2010-06-23 23:24 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, dkiran, Johannes Berg
In-Reply-To: <1277303846-17257-2-git-send-email-linville@tuxdriver.com>
On Wed, 2010-06-23 at 10:37 -0400, John W. Linville wrote:
> Address fall-out from patch converting libertas to use cfg80211...
>
> +drivers/net/wireless/libertas/cfg.c:1844:13: warning: incorrect type in assignment (different base types)
> +drivers/net/wireless/libertas/cfg.c:1844:13: expected unsigned short [unsigned] [usertype] capability
> +drivers/net/wireless/libertas/cfg.c:1844:13: got restricted __le16 [usertype] <noident>
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Acked-by: Dan Williams <dcbw@redhat.com>
> ---
> drivers/net/wireless/libertas/cfg.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/cfg.c b/drivers/net/wireless/libertas/cfg.c
> index 23c1dc6..f36cc97 100644
> --- a/drivers/net/wireless/libertas/cfg.c
> +++ b/drivers/net/wireless/libertas/cfg.c
> @@ -1841,7 +1841,7 @@ static int lbs_ibss_start_new(struct lbs_private *priv,
> if (MRVL_FW_MAJOR_REV(priv->fwrelease) <= 8)
> cmd.probedelay = cpu_to_le16(CMD_SCAN_PROBE_DELAY_TIME);
> /* TODO: mix in WLAN_CAPABILITY_PRIVACY */
> - capability = cpu_to_le16(WLAN_CAPABILITY_IBSS);
> + capability = WLAN_CAPABILITY_IBSS;
> cmd.capability = cpu_to_le16(capability);
> lbs_add_rates(cmd.rates);
>
^ permalink raw reply
* Re: [PATCH 3/3] libertas: mark lbs_ret_802_11d_domain_info static
From: Dan Williams @ 2010-06-23 23:24 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, dkiran, Johannes Berg
In-Reply-To: <1277303846-17257-3-git-send-email-linville@tuxdriver.com>
On Wed, 2010-06-23 at 10:37 -0400, John W. Linville wrote:
> Probably little risk of namespace polution, but good practice... :-)
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Acked-by: Dan Williams <dcbw@redhat.com>
> ---
> drivers/net/wireless/libertas/cmdresp.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/cmdresp.c b/drivers/net/wireless/libertas/cmdresp.c
> index b4bc103..a0d9482 100644
> --- a/drivers/net/wireless/libertas/cmdresp.c
> +++ b/drivers/net/wireless/libertas/cmdresp.c
> @@ -103,7 +103,7 @@ static int lbs_ret_reg_access(struct lbs_private *priv,
> * @param resp pointer to command response buffer
> * @return 0; -1
> */
> -int lbs_ret_802_11d_domain_info(struct cmd_ds_command *resp)
> +static int lbs_ret_802_11d_domain_info(struct cmd_ds_command *resp)
> {
> struct cmd_ds_802_11d_domain_info *domaininfo =
> &resp->params.domaininforesp;
^ 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