headers
Erik Hardesty | 1 Jul 2011 01:12
Picon

Re: iwlagn: Problems with Intel Wifi Link 1000 on newer kernels

Forcing iwlwifi-1000-3.ucode results in the same issues. No change in
linux 3.0-rc5.

On Thu, Jun 30, 2011 at 9:19 AM, wwguy <wey-yi.w.guy@...> wrote:
> On Thu, 2011-06-30 at 02:51 -0700, Stanislaw Gruszka wrote:
>> On Fri, Jun 17, 2011 at 01:14:11AM -0500, Erik Hardesty wrote:
>> > Having trouble with iwlagn in kernels newer than 2.6.38.
>> > I've tried 2.6.39 and 3.0rc3 and both give me the same problem.
>> > I have the latest intel firmware installed on the system. Both
>> > iwlwifi-1000-3.ucode
>> > and iwlwifi-1000-5.ucode are in /lib/firmware
>> >
>> > Note: 2.6.38 does not exhibit the same issue and works fine.
>>
>> If there is no other proposition to fix the issue from Intel,
>> perhaps you could bisect the problem.
>
> what if you remove iwlwifi-1000-5.ucode and force to use -3 version of
> uCode; are you still seeing the problem with new kernel?
>
> Thanks
> Wey
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
wwguy | 1 Jul 2011 01:12
Picon
Favicon

Re: iwlagn: Problems with Intel Wifi Link 1000 on newer kernels

On Thu, 2011-06-30 at 16:12 -0700, Erik Hardesty wrote:
> Forcing iwlwifi-1000-3.ucode results in the same issues. No change in
> linux 3.0-rc5.
> 
> On Thu, Jun 30, 2011 at 9:19 AM, wwguy <wey-yi.w.guy@...> wrote:
> > On Thu, 2011-06-30 at 02:51 -0700, Stanislaw Gruszka wrote:
> >> On Fri, Jun 17, 2011 at 01:14:11AM -0500, Erik Hardesty wrote:
> >> > Having trouble with iwlagn in kernels newer than 2.6.38.
> >> > I've tried 2.6.39 and 3.0rc3 and both give me the same problem.
> >> > I have the latest intel firmware installed on the system. Both
> >> > iwlwifi-1000-3.ucode
> >> > and iwlwifi-1000-5.ucode are in /lib/firmware
> >> >
> >> > Note: 2.6.38 does not exhibit the same issue and works fine.
> >>
> >> If there is no other proposition to fix the issue from Intel,
> >> perhaps you could bisect the problem.
> >
> > what if you remove iwlwifi-1000-5.ucode and force to use -3 version of
> > uCode; are you still seeing the problem with new kernel?
> >
then no idea :-(, maybe has to bisect it.

what exactally the problem you facing, do you have a bugzilla# ?

Thanks
Wey
> >
> >
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Carpenter | 1 Jul 2011 02:05
Picon

Re: [PATCH 000/119] staging: brcm80211: more code cleanup and bug fixed

On Thu, Jun 30, 2011 at 02:40:19PM -0700, Henry Ptasinski wrote:
> So there are two suggestions here:
> 
> 1. post patches in smaller bunches, and include dependency info in
> the 0/X patch.  Presumably, if one of the dependencies is dropped,
> then people will know to drop this series as well, and we would have
> to repost everything that was dropped once we fix the identified
> issues.
> 
> 2. maintain a public git tree that people can pull from.  If we do
> (1), is this needed and/or still useful?

Yes.  Patches hiding in git trees never get reviewed.  They just
pile up until there too many to review.

> Do community folks that
> want to contribute changes send them to us or Greg/John/whoever is
> upstream? Pros/cons?

That stuff is between you and Greg.  The rest of us don't care.

But what I'm saying is don't delay sending these patches because
you're not sure if the other patches were going to go in or not.
It's not an unpredictable thing.  Everyone is supposed to CC you
along with Greg, linux-wireless and driver-devel.  You're the
maintainer.  If you ack a patch or nack it, then 99% of the time
Greg is going to go along with your decision.

It's not like Greg is going to complain if you start recording which
patches have to go in next and deal with any merge conflicts...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Greg KH | 1 Jul 2011 02:14
Picon

Re: [PATCH 000/119] staging: brcm80211: more code cleanup and bug fixed

On Fri, Jul 01, 2011 at 03:05:26AM +0300, Dan Carpenter wrote:
> On Thu, Jun 30, 2011 at 02:40:19PM -0700, Henry Ptasinski wrote:
> > So there are two suggestions here:
> > 
> > 1. post patches in smaller bunches, and include dependency info in
> > the 0/X patch.  Presumably, if one of the dependencies is dropped,
> > then people will know to drop this series as well, and we would have
> > to repost everything that was dropped once we fix the identified
> > issues.
> > 
> > 2. maintain a public git tree that people can pull from.  If we do
> > (1), is this needed and/or still useful?
> 
> Yes.  Patches hiding in git trees never get reviewed.  They just
> pile up until there too many to review.
> 
> > Do community folks that
> > want to contribute changes send them to us or Greg/John/whoever is
> > upstream? Pros/cons?
> 
> That stuff is between you and Greg.  The rest of us don't care.
> 
> But what I'm saying is don't delay sending these patches because
> you're not sure if the other patches were going to go in or not.
> It's not an unpredictable thing.  Everyone is supposed to CC you
> along with Greg, linux-wireless and driver-devel.  You're the
> maintainer.  If you ack a patch or nack it, then 99% of the time
> Greg is going to go along with your decision.
> 
> It's not like Greg is going to complain if you start recording which
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johannes Berg | 1 Jul 2011 10:10
Favicon

Re: Crash in mlme.c, wireless-testing 2.6.39-wl + hacks


> Very little significant changes in this area, but I've a non-related
> proprietary module loaded, and patches to various other parts of the
> networking code.
> 
> The full tree is here if you want to take a look, or I can send
> you a full unified diff:
> 
> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux.wireless-testing-ct.ct/.git;a=summary

Fair enough, I don't see anything there that would impact this bug.

> Seems a tricky timing related bug, possibly we're only hitting it because
> we're testing on an older C3 processor system that is significantly slower
> than our normal test systems.

Hm. That seems odd. I didn't see anything that lacked locking either.

I think the detail that we need to investigate is what you said before:

> configured for in-kernel authentication,
> re-configure them for supplicant, let them associate, delete one of
> them.

but I don't see anything there either right now.

johannes

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ben Greear | 1 Jul 2011 15:00
Favicon

Re: Crash in mlme.c, wireless-testing 2.6.39-wl + hacks

On 07/01/2011 01:10 AM, Johannes Berg wrote:
>
>> Very little significant changes in this area, but I've a non-related
>> proprietary module loaded, and patches to various other parts of the
>> networking code.
>>
>> The full tree is here if you want to take a look, or I can send
>> you a full unified diff:
>>
>> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux.wireless-testing-ct.ct/.git;a=summary
>
> Fair enough, I don't see anything there that would impact this bug.
>
>> Seems a tricky timing related bug, possibly we're only hitting it because
>> we're testing on an older C3 processor system that is significantly slower
>> than our normal test systems.
>
> Hm. That seems odd. I didn't see anything that lacked locking either.
>
> I think the detail that we need to investigate is what you said before:
>
>> configured for in-kernel authentication,
>> re-configure them for supplicant, let them associate, delete one of
>> them.
>
> but I don't see anything there either right now.

Well, would you accept a patch that checked for null bssid, and did a WARN_ON
and bailed out if found?  Seems little harm, and we verified that the system
otherwise remained stable with such a patch added...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rajkumar Manoharan | 1 Jul 2011 15:07
Favicon

[PATCH] ath9k: Fix tx throughput drops for AR9003 chips with AES encryption

While sending aggregated frames in AES, the AR5416 chips
required additional padding b/w subframes. This workaround
is not needed for edma (AR9003 family) chips. With this patch
~4Mbps thoughput improvement was observed in clear environment.

Cc: stable@...
Signed-off-by: Rajkumar Manoharan <rmanohar@...>
---
 drivers/net/wireless/ath/ath9k/xmit.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index a1fed6c..9283440 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
 <at>  <at>  -661,7 +661,8  <at>  <at>  static int ath_compute_num_delims(struct ath_softc *sc, struct ath_atx_tid *tid,
 	 * TODO - this could be improved to be dependent on the rate.
 	 *      The hardware can keep up at lower rates, but not higher rates
 	 */
-	if (fi->keyix != ATH9K_TXKEYIX_INVALID)
+	if ((fi->keyix != ATH9K_TXKEYIX_INVALID) &&
+	    !(sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_EDMA))
 		ndelim += ATH_AGGR_ENCRYPTDELIM;

 	/*
--

-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Lamparter | 1 Jul 2011 15:19

[RFT] carl9170: improve site survey

The hardware provides main and extension channel busy
counters to monitor channel usage.

Survey data from wlan
        frequency:                      2412 MHz [in use]
        noise:                          -85 dBm
        channel active time:            1198041 ms
        channel busy time:              57835 ms
        extension channel busy time:    57213 ms
Survey data from wlan
        frequency:                      2417 MHz
        noise:                          -86 dBm
        channel active time:            0 ms
        channel busy time:              0 ms
        extension channel busy time:    0 ms
...

Stehpen, do you know if the hardware has a counter which
accumulates rx / tx air time like ath9k 0x80ec MAC_PCU_TX_FRAME_CNT?
This will be needed for Automatic Channel Selection.
---
diff --git a/drivers/net/wireless/ath/carl9170/carl9170.h b/drivers/net/wireless/ath/carl9170/carl9170.h
index 20bed04..36ed450 100644
--- a/drivers/net/wireless/ath/carl9170/carl9170.h
+++ b/drivers/net/wireless/ath/carl9170/carl9170.h
 <at>  <at>  -152,6 +152,7  <at>  <at>  struct carl9170_sta_tid {
 #define CARL9170_TX_TIMEOUT		2500
 #define CARL9170_JANITOR_DELAY		128
 #define CARL9170_QUEUE_STUCK_TIMEOUT	5500
+#define CARL9170_STAT_WORK		30000
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christian Lamparter | 1 Jul 2011 15:28

[PATCH] carl9170: use carl9170 queue enums

Signed-off-by: Christian Lamparter <chunkeey@...>
---
 drivers/net/wireless/ath/carl9170/main.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/carl9170/main.c b/drivers/net/wireless/ath/carl9170/main.c
index fe82d1f..91b3fd3 100644
--- a/drivers/net/wireless/ath/carl9170/main.c
+++ b/drivers/net/wireless/ath/carl9170/main.c
 <at>  <at>  -345,11 +345,11  <at>  <at>  static int carl9170_op_start(struct ieee80211_hw *hw)
 	carl9170_zap_queues(ar);

 	/* reset QoS defaults */
-	CARL9170_FILL_QUEUE(ar->edcf[0], 3, 15, 1023,  0); /* BEST EFFORT */
-	CARL9170_FILL_QUEUE(ar->edcf[1], 2, 7,    15, 94); /* VIDEO */
-	CARL9170_FILL_QUEUE(ar->edcf[2], 2, 3,     7, 47); /* VOICE */
-	CARL9170_FILL_QUEUE(ar->edcf[3], 7, 15, 1023,  0); /* BACKGROUND */
-	CARL9170_FILL_QUEUE(ar->edcf[4], 2, 3,     7,  0); /* SPECIAL */
+	CARL9170_FILL_QUEUE(ar->edcf[AR9170_TXQ_VO], 2, 3,     7, 47);
+	CARL9170_FILL_QUEUE(ar->edcf[AR9170_TXQ_VI], 2, 7,    15, 94);
+	CARL9170_FILL_QUEUE(ar->edcf[AR9170_TXQ_BE], 3, 15, 1023,  0);
+	CARL9170_FILL_QUEUE(ar->edcf[AR9170_TXQ_BK], 7, 15, 1023,  0);
+	CARL9170_FILL_QUEUE(ar->edcf[AR9170_TXQ_SPECIAL], 2, 3, 7, 0);

 	ar->current_factor = ar->current_density = -1;
 	/* "The first key is unique." */
--

-- 
1.7.5.4

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Forest Bond | 1 Jul 2011 15:35
Gravatar

ath9k_htc fails to initialize TL-WN721N with compat-wireless 3.0-rc4-1

Hi,

I am running compat-wireless 3.0-rc4-1 on an Ubuntu 8.04 (Hardy) system with
Ubuntu kernel version 2.6.24-21-generic.  Yes, I know this kernel version is
ancient, but that's what c-w is for, right? ;)

First, I should mention that had to apply this patch for c-w to build:

  http://permalink.gmane.org/gmane.linux.kernel.wireless.general/72402

I also ran into problems because the c-w Makefile installs the udev
compat_firmware rules file into /lib/udev/rules.d, which is not a supported
location on Hardy.  Moving the rules file to /etc/udev/rules.d solved that.

Now the module loads fine and appears to load the firmware correctly, but the
interface never comes up.  Here's what happens when I insert the device:

[  206.270348] usb 5-7: new high speed USB device using ehci_hcd and address 5
[  206.422393] usb 5-7: configuration #1 chosen from 1 choice
[  206.657723] Compat-wireless backport release: compat-wireless-v3.0-rc4-1
[  206.657732] Backport based on linux-2.6-allstable.git v3.0-rc4
[  206.864667] Calling CRDA to update world regulatory domain
[  207.714633] usb 5-7: ath9k_htc: Transferred FW: htc_9271.fw, size: 51288
[  207.861037] ath9k_htc 5-7:1.0: ath9k_htc: HTC initialized with 33 credits

At this point the interface is not visible in the output of ifconfig.  Something
has gone wrong with USB, because lsusb hangs until I unplug the device, at which
point I see the following in dmesg:

[  225.464212] usb 5-7: USB disconnect, address 5
(Continue reading)

Permalink | Reply | 1 comment |

Gmane