* Re: [BUG] after starting wimaxd at boot iwlagn module will crash for intel 6250 card
From: Guy, Wey-Yi @ 2010-07-28 0:04 UTC (permalink / raw)
To: Sternberg, Jay E, Inaky Perez-Gonzalez
Cc: alexxy@gentoo.org, wimax@linuxwimax.org,
linux-wireless@vger.kernel.org
In-Reply-To: <1280270313.26204.288.camel@localhost.localdomain>
Hi,
On Tue, 2010-07-27 at 15:38 -0700, Inaky Perez-Gonzalez wrote:
> On Tue, 2010-07-27 at 13:28 -0700, Alexey Shvetsov wrote:
> > Hi all!
>
> [apologies, I forgot to mention to CC the linux-wireless mailing list,
> where the iwlagn guys lurk around -- done].
>
> Guys, seems the wifi device is tripping in the 6250 when we switch on
> WiMAX. Do you see anything interesting?
>
> > Seems i fund bug on my 64bit system. I have installed 32bit version
> > of wimax stack 1.5 and i'm running 2.6.35-rc6 kernel.
> >
> > After starting
> > wimaxd at boot time iwlagn driver will crash when i try to scan or connect
> > to any network. Stacktrace will be the following
> >
> > iwlagn 0000:02:00.0:
> > RF_KILL bit toggled to enable radio.
> > i2400m_usb 2-1.3:1.0: 'RF Control'
> > (0x4602) command failed: -84 - invalid state (3)
> > iwlagn 0000:02:00.0:
> > Microcode SW error detected. Restarting 0x2000000.
> > iwlagn 0000:02:00.0:
> > Loaded firmware version: 9.201.4.1 build 24255
> > iwlagn 0000:02:00.0: Start
> > IWL Error Log Dump:
> > iwlagn 0000:02:00.0: Status: 0x00020224, count: 5
> > iwlagn
> > 0000:02:00.0: Desc Time data1 data2
> > line
> > iwlagn 0000:02:00.0: SYSASSERT (#05) 0000012334
> > 0x0000008D 0x8000000D 453
> > iwlagn 0000:02:00.0: pc blink1 blink2
> > ilink1 ilink2 hcmd
> > iwlagn 0000:02:00.0: 0x1D074 0x1D066 0x1D066 0x009B2
> > 0x00000 0x400005A
> > iwlagn 0000:02:00.0: CSR values:
> > iwlagn 0000:02:00.0: (2nd
> > byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG)
> > iwlagn 0000:02:00.0:
> > CSR_HW_IF_CONFIG_REG: 0X00480303
> > iwlagn 0000:02:00.0:
> > CSR_INT_COALESCING: 0X0000ff40
> > iwlagn 0000:02:00.0:
> > CSR_INT: 0X00000000
> > iwlagn 0000:02:00.0: CSR_INT_MASK:
> > 0X00000000
> > iwlagn 0000:02:00.0: CSR_FH_INT_STATUS:
> > 0X00000000
> > iwlagn 0000:02:00.0: CSR_GPIO_IN:
> > 0X0000000f
> > iwlagn 0000:02:00.0: CSR_RESET:
> > 0X00000000
> > iwlagn 0000:02:00.0: CSR_GP_CNTRL:
> > 0X080403c5
> > iwlagn 0000:02:00.0: CSR_HW_REV:
> > 0X00000084
> > iwlagn 0000:02:00.0: CSR_EEPROM_REG:
> > 0Xe0a20ffd
> > iwlagn 0000:02:00.0: CSR_EEPROM_GP:
> > 0X90000801
> > iwlagn 0000:02:00.0: CSR_OTP_GP_REG:
> > 0X00030001
> > iwlagn 0000:02:00.0: CSR_GIO_REG:
> > 0X00080046
> > iwlagn 0000:02:00.0: CSR_GP_UCODE_REG:
> > 0X00000002
> > iwlagn 0000:02:00.0: CSR_GP_DRIVER_REG:
> > 0X00000004
> > iwlagn 0000:02:00.0: CSR_UCODE_DRV_GP1:
> > 0X00000000
> > iwlagn 0000:02:00.0: CSR_UCODE_DRV_GP2:
> > 0X00000000
> > iwlagn 0000:02:00.0: CSR_LED_REG:
> > 0X00000018
> > iwlagn 0000:02:00.0: CSR_DRAM_INT_TBL_REG:
> > 0X00000000
> > iwlagn 0000:02:00.0: CSR_GIO_CHICKEN_BITS:
> > 0X27800200
> > iwlagn 0000:02:00.0: CSR_ANA_PLL_CFG:
> > 0X00000000
> > iwlagn 0000:02:00.0: CSR_HW_REV_WA_REG:
> > 0X0001001a
> > iwlagn 0000:02:00.0: CSR_DBG_HPET_MEM_REG:
> > 0Xffff0000
> > iwlagn 0000:02:00.0: FH register values:
> > iwlagn 0000:02:00.0:
> > FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X0ffede00
> > iwlagn 0000:02:00.0:
> > FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X00ffedf0
> > iwlagn 0000:02:00.0:
> > FH_RSCSR_CHNL0_WPTR: 0X00000000
> > iwlagn 0000:02:00.0:
> > FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
> > iwlagn 0000:02:00.0:
> > FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
> > iwlagn 0000:02:00.0:
> > FH_MEM_RSSR_RX_STATUS_REG: 0X07030000
> > iwlagn 0000:02:00.0:
> > FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
> > iwlagn 0000:02:00.0:
> > FH_TSSR_TX_STATUS_REG: 0X07ff0001
> > iwlagn 0000:02:00.0:
> > FH_TSSR_TX_ERROR_REG: 0X00000000
> > iwlagn 0000:02:00.0: Start IWL Event Log
> > Dump: display last 20 entries
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000004384:0x000000ff:1100
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000004385:0x000000ff:1100
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000004385:0x000000ff:1100
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000004387:0x000000ff:1100
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000004388:0x000000ff:1100
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000004388:0x000000ff:1100
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000004389:0x000000ff:1100
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000004390:0x000000ff:1100
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000004391:0x000000ff:1100
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000004391:0x000000ff:1100
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000004392:0x000000ff:1100
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000004402:0x000003b1:0601
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000004402:0x10000000:0600
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000004403:0x000003c1:0660
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000004407:0x00000000:0661
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000012227:0x0400005a:0401
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000012228:0x0400005a:1513
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000012228:0x00000000:1513
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000012229:0x00000001:1523
> > iwlagn 0000:02:00.0:
> > EVT_LOGT:0000012344:0x00000000:0125
> > iwlagn 0000:02:00.0: Command
> > REPLY_PHY_CALIBRATION_CMD failed: FW Error
> > iwlagn 0000:02:00.0: Error -5
> > iteration 0
> > usb 1-1.4: new full speed USB device using ehci_hcd and address
> > 5
> > iwlagn 0000:02:00.0: Error sending CALIBRATION_CFG_CMD: time out after
> > 500ms.
> > Bluetooth: Generic Bluetooth USB driver ver 0.6
> > usbcore: registered
> > new interface driver btusb
> > Bluetooth: BNEP (Ethernet Emulation) ver
> > 1.3
> > Bluetooth: BNEP filters: protocol multicast
> > Bluetooth: SCO (Voice Link)
> > ver 0.6
> > Bluetooth: SCO socket layer initialized
> > iwlagn 0000:02:00.0:
> > START_ALIVE timeout after 4000ms.
> >
> >
Looks like iwlwifi driver stuck on loading uCode and performing
WiFi/WiMAX coex operation. I will forward the information to our uCode
team to look into it.
Thanks
Wey
^ permalink raw reply
* Re: [stable] [PATCH 1/4 2.6.33.y] mac80211: explicitly disable/enable QoS
From: Greg KH @ 2010-07-27 23:54 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Stanislaw Gruszka, stable, linux-wireless
In-Reply-To: <1280272525.13192.67.camel@localhost>
On Wed, Jul 28, 2010 at 12:15:25AM +0100, Ben Hutchings wrote:
> On Tue, 2010-07-27 at 15:40 -0700, Greg KH wrote:
> > On Mon, Jun 07, 2010 at 12:00:24PM +0200, Stanislaw Gruszka wrote:
> > > commit e1b3ec1a2a336c328c336cfa5485a5f0484cc90d upstream.
> > >
> > > Add interface to disable/enable QoS (aka WMM or WME). Currently drivers
> > > enable it explicitly when ->conf_tx method is called, and newer disable.
> > > Disabling is needed for some APs, which do not support QoS, such
> > > we should send QoS frames to them.
> >
> > Why is this a patch for a -stable tree? It looks like it adds a new api
> > for a new feature, right?
> [...]
>
> It extends the interface between the 802.11 stack and drivers so that
> drivers can avoid sending QoS frames to APs that don't support them.
> There is no new interface to userland. My understanding is that iwlwifi
> becomes unable to communicate with non-QoS-capable APs after having once
> associated with a QoS-capable AP, without this and the following change
> in iwlwifi itself.
Is this really true? And is it a bug that people are hitting?
thanks,
greg k-h
^ permalink raw reply
* Re: regulatory hiccup
From: Luis R. Rodriguez @ 2010-07-27 23:51 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: linux-wireless
In-Reply-To: <AANLkTimZsj6+cp6YGoVFn06NEQR3ZBCAheaWHaKPZNK6@mail.gmail.com>
On Tue, Jul 27, 2010 at 4:46 PM, Andrew Lutomirski <luto@mit.edu> wrote:
> On Tue, Jul 27, 2010 at 7:33 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>>>
>>> AFAICT net/wireless/reg.c ignores the last bit, and the other APs that
>>> work correctly here don't send country IEs.
>>
>> Can you provide the output of iw dev wlan0 scan from a fresh git
>> version of iw? That will actually tell me more than your listing.
>
> Unfortunately (or fortunately, I suppose) I can't, because a firmware
> upgrade for the AP removed the country IE entirely. But if we're
> ignoring that data in 2.6.36 anyway, I'm not too worried. If you
> really want that data, I can downgrade the AP the week after next and
> get it.
>
> (FWIW, it looks like the Intel driver on Windows refused to work with
> that AP but other people with macbooks could use it just fine. I'd
> guess that no one would complain if Linux ignored country IEs that
> were transmitted outside their own "allowed" band, but this seems to
> be moot anyway.)
If sounds like the AP may have had an issue if the country IE is no
longer present and by the quick looks of your output it could have
been.. so unless you're confident of the AP I would think this is an
AP bug. If its a STA bug for sure though we certainly need to address
the issue on 2.6.35 even if 2.6.36 has a proper fix of ignoring the IE
altogether.
> P.S. My thread about the AP that works on 2.6.34 but can't associate
> most of the time on 2.6.35-rc6 is the same AP but with the new
> firmware.
Wonderful.
Luis
^ permalink raw reply
* Re: iwlagn: two regressions 2.6.34->2.6.35-rc6
From: Luis R. Rodriguez @ 2010-07-27 23:48 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: linux-wireless, ilw
In-Reply-To: <AANLkTimWKV28m5aRFZzCkHoVkNBDV+0uGky8UdREJxHK@mail.gmail.com>
On Tue, Jul 27, 2010 at 4:42 PM, Andrew Lutomirski <luto@mit.edu> wrote:
> On Tue, Jul 27, 2010 at 7:26 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> On Tue, Jul 27, 2010 at 4:24 PM, Andrew Lutomirski <luto@mit.edu> wrote:
>>> On Mon, Jul 26, 2010 at 3:48 PM, Andrew Lutomirski <luto@mit.edu> wrote:
>>>>> In the attached log, you'll see the one successful connection to
>>>>> 00:02:6f:6e:d7:6c as well as a failure. The failure is just:
>>>>>
>>>>> [ 668.569218] wlan0: authenticate with 00:02:6f:6e:d7:6c (try 1)
>>>>> [ 668.769269] wlan0: authenticate with 00:02:6f:6e:d7:6c (try 2)
>>>>> [ 668.969150] wlan0: authenticate with 00:02:6f:6e:d7:6c (try 3)
>>>>> [ 669.169262] wlan0: authentication with 00:02:6f:6e:d7:6c timed out
>>>>
>>>> This time with actual attachment.
>>>
>>> Not sure if this is the same issue, but I've got another AP here
>>> (Ubiquiti RouterStation Pro + R52N ath9k minipci card running latest
>>> OpenWRT "backfire") that works quite nicely on 2.6.34 but requires me
>>> to reconnect every minute or so on 2.6.35-rc6+ to keep it working.
>>
>> Define 2.6.35-rc6+
>>
>> If you are using wireless-testing there was a regression there that I
>> just sent patches for.
>
> It's just Linus' kernel (specifically
> 6aa033d7efb85830535bb83cf6713d6025ae6e59) plus a few local i915
> patches. (I also have my aggregation failure warning patch in there,
> but that just changes a couple of printks.)
If you can test vanilla Linus and post a bug report that would help
for sure. I do not think we are aware of existing pending issues on
2.6.35, and in fact the regression list often posted by Rafael shows 0
regressions for 2.6.34 and 2.6.35-rc so far so you're issue is
certainly not reported until now, but we need more details, like
chipset, how to reproduce, etc.
>> Reporting issues is the way to go which BTW i have yet to get to your
>> other e-mail, sorry just got back from vacation and still catching up.
>
> No problem. (I didn't think you worked on iwlwifi anyway...)
No, but if its regulatory yes.
>>> I'm getting tempted to just revert the whole driver back to 2.6.34 and
>>> use the rest of 2.6.35 when it comes out. I can also try to bisect,
>>> either the normal way or just the iwlwifi driver, but that'll have to
>>> wait until the Monday after next at least because I'm leaving town.
>>> If any of you have any ideas to test *today*, I can do it.
>
> Do you know how hard it is to bisect compat-wireless?
Sure by date, it also has the specific dates it pulls stuff from
linux-next.git so you can use that as reference.
> Bisecting just
> the iwlwifi directory is a bit of a pain because I have to manually
> fix up everything that doesn't compile, and it's also a pain to bisect
> the whole tree because I need some local i915 patches to get a working
> system. (Also, IIRC, 2.6.35 was very broken around -rc2 or -rc3.)
I would just say to use wireless-testing directly and bisect that, I
did that yesterday night. You bisect wireless-testing by the
^master-$(date -I) tags. A little of a pain but its not so bad. As
John noted also you can just use his wireless-next.git too and you
should be able to bisect that regularly.
I understand your requirements for i915 changes.. but maybe you can
test with vesa in the meantime?
Luis
^ permalink raw reply
* Re: regulatory hiccup
From: Andrew Lutomirski @ 2010-07-27 23:46 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <AANLkTik2njXen5go8v2d8UPejC7THJiDJAvVunS7T5WU@mail.gmail.com>
On Tue, Jul 27, 2010 at 7:33 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>>
>> AFAICT net/wireless/reg.c ignores the last bit, and the other APs that
>> work correctly here don't send country IEs.
>
> Can you provide the output of iw dev wlan0 scan from a fresh git
> version of iw? That will actually tell me more than your listing.
Unfortunately (or fortunately, I suppose) I can't, because a firmware
upgrade for the AP removed the country IE entirely. But if we're
ignoring that data in 2.6.36 anyway, I'm not too worried. If you
really want that data, I can downgrade the AP the week after next and
get it.
(FWIW, it looks like the Intel driver on Windows refused to work with
that AP but other people with macbooks could use it just fine. I'd
guess that no one would complain if Linux ignored country IEs that
were transmitted outside their own "allowed" band, but this seems to
be moot anyway.)
--Andy
P.S. My thread about the AP that works on 2.6.34 but can't associate
most of the time on 2.6.35-rc6 is the same AP but with the new
firmware.
>
> Luis
>
^ permalink raw reply
* Re: iwlagn: two regressions 2.6.34->2.6.35-rc6
From: Andrew Lutomirski @ 2010-07-27 23:42 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, ilw
In-Reply-To: <AANLkTimb0r0LJCpU76rrLibG=1o7j+UtcsFTmHeUHdXH@mail.gmail.com>
On Tue, Jul 27, 2010 at 7:26 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Tue, Jul 27, 2010 at 4:24 PM, Andrew Lutomirski <luto@mit.edu> wrote:
>> On Mon, Jul 26, 2010 at 3:48 PM, Andrew Lutomirski <luto@mit.edu> wrote:
>>>> In the attached log, you'll see the one successful connection to
>>>> 00:02:6f:6e:d7:6c as well as a failure. The failure is just:
>>>>
>>>> [ 668.569218] wlan0: authenticate with 00:02:6f:6e:d7:6c (try 1)
>>>> [ 668.769269] wlan0: authenticate with 00:02:6f:6e:d7:6c (try 2)
>>>> [ 668.969150] wlan0: authenticate with 00:02:6f:6e:d7:6c (try 3)
>>>> [ 669.169262] wlan0: authentication with 00:02:6f:6e:d7:6c timed out
>>>
>>> This time with actual attachment.
>>
>> Not sure if this is the same issue, but I've got another AP here
>> (Ubiquiti RouterStation Pro + R52N ath9k minipci card running latest
>> OpenWRT "backfire") that works quite nicely on 2.6.34 but requires me
>> to reconnect every minute or so on 2.6.35-rc6+ to keep it working.
>
> Define 2.6.35-rc6+
>
> If you are using wireless-testing there was a regression there that I
> just sent patches for.
It's just Linus' kernel (specifically
6aa033d7efb85830535bb83cf6713d6025ae6e59) plus a few local i915
patches. (I also have my aggregation failure warning patch in there,
but that just changes a couple of printks.)
>
> Reporting issues is the way to go which BTW i have yet to get to your
> other e-mail, sorry just got back from vacation and still catching up.
No problem. (I didn't think you worked on iwlwifi anyway...)
>> I'm getting tempted to just revert the whole driver back to 2.6.34 and
>> use the rest of 2.6.35 when it comes out. I can also try to bisect,
>> either the normal way or just the iwlwifi driver, but that'll have to
>> wait until the Monday after next at least because I'm leaving town.
>> If any of you have any ideas to test *today*, I can do it.
Do you know how hard it is to bisect compat-wireless? Bisecting just
the iwlwifi directory is a bit of a pain because I have to manually
fix up everything that doesn't compile, and it's also a pain to bisect
the whole tree because I need some local i915 patches to get a working
system. (Also, IIRC, 2.6.35 was very broken around -rc2 or -rc3.)
--Andy
^ permalink raw reply
* Re: regulatory hiccup
From: Luis R. Rodriguez @ 2010-07-27 23:33 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: linux-wireless
In-Reply-To: <AANLkTi=Wy1r2C1xL289QQX10aVZaYfF7A1K8sd93ZXOd@mail.gmail.com>
T24gRnJpLCBKdWwgMjMsIDIwMTAgYXQgMTowMyBQTSwgQW5kcmV3IEx1dG9taXJza2kgPGx1dG9A
bWl0LmVkdT4gd3JvdGU6Cj4gT24gRnJpLCBKdWwgMjMsIDIwMTAgYXQgMzozNSBQTSwgQW5kcmV3
IEx1dG9taXJza2kgPGx1dG9AbWl0LmVkdT4gd3JvdGU6Cj4+IE9uIEZyaSwgSnVsIDIzLCAyMDEw
IGF0IDM6MzAgUE0sIEFuZHJldyBMdXRvbWlyc2tpIDxsdXRvQG1pdC5lZHU+IHdyb3RlOgo+Pj4K
Pj4+IFRoZW4sIGFmdGVyIGZpZGRsaW5nIHdpdGggYW4gQVAgZm9yIGEgYml0LCBJIGdvdDoKPj4+
Cj4+PiBbMTE3NDcuMjY0MjIxXSBjZmc4MDIxMTogQ2FsbGluZyBDUkRBIGZvciBjb3VudHJ5OiBV
Uwo+Pj4gWzExNzQ3LjI4MjY2NF0gY2ZnODAyMTE6IEN1cnJlbnQgcmVndWxhdG9yeSBkb21haW4g
dXBkYXRlZCBieSBBUCB0bzogVVMKPj4+IFsxMTc0Ny4yODI2NzJdIMKgIMKgIChzdGFydF9mcmVx
IC0gZW5kX2ZyZXEgQCBiYW5kd2lkdGgpLAo+Pj4gKG1heF9hbnRlbm5hX2dhaW4sIG1heF9laXJw
KQo+Pj4gWzExNzQ3LjI4MjY4MF0gwqAgwqAgKDUxNzAwMDAgS0h6IC0gNTI1MDAwMCBLSHogQCA0
MDAwMCBLSHopLCAoMzAwIG1CaSwgMTYwMCBtQm0pCj4+PiBbMTE3NDcuMjgyNjg4XSDCoCDCoCAo
NTI1MDAwMCBLSHogLSA1MzMwMDAwIEtIeiBAIDQwMDAwIEtIeiksICgzMDAgbUJpLCAxNjAwIG1C
bSkKPj4+Cj4+Cj4+IEl0J3Mgd29yc2UgdGhhbiB0aGF0LiDCoEkgcmVjb25uZWN0ZWQgdG8gdGhl
IEFQIChpdCBhcHBlYXJlZCB0byB3b3JrCj4+IGZvciBhIGZldyBzZWNvbmRzKSBhbmQgSSBzYXc6
Cj4+Cj4+IFdpcGh5IHBoeTAKPj4gWy4uLl0KPj4gwqAgwqAgwqAgwqBCYW5kIDI6Cj4+IMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgQ2FwYWJpbGl0aWVzOiAweDg3Mgo+PiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoEhUMjAvSFQ0MAo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoFN0YXRpYyBTTSBQb3dlciBTYXZlCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgUlggR3JlZW5maWVsZAo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoFJYIEhUMjAgU0dJCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
UlggSFQ0MCBTR0kKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBObyBSWCBT
VEJDCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgTWF4IEFNU0RVIGxlbmd0
aDogMzgzOSBieXRlcwo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoE5vIERT
U1MvQ0NLIEhUNDAKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBNYXhpbXVtIFJYIEFNUERVIGxl
bmd0aCA2NTUzNSBieXRlcyAoZXhwb25lbnQ6IDB4MDAzKQo+PiDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoE1pbmltdW0gUlggQU1QRFUgdGltZSBzcGFjaW5nOiA0IHVzZWMgKDB4MDUpCj4+IMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgSFQgVFgvUlggTUNTIHJhdGUgaW5kZXhlcyBzdXBwb3J0ZWQ6IDAt
MjMsIDMyCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgRnJlcXVlbmNpZXM6Cj4+IMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1MTgwIE1IeiBbMzZdICgxNS4wIGRCbSkgKHBh
c3NpdmUgc2Nhbm5pbmcsIG5vIElCU1MpCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgKiA1MjAwIE1IeiBbNDBdICgxNS4wIGRCbSkgKHBhc3NpdmUgc2Nhbm5pbmcsIG5vIElC
U1MpCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1MjIwIE1IeiBbNDRd
ICgxNS4wIGRCbSkgKHBhc3NpdmUgc2Nhbm5pbmcsIG5vIElCU1MpCj4+IMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1MjQwIE1IeiBbNDhdICgxNS4wIGRCbSkgKHBhc3NpdmUg
c2Nhbm5pbmcsIG5vIElCU1MpCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
KiA1MjYwIE1IeiBbNTJdICgxNS4wIGRCbSkgKHBhc3NpdmUgc2Nhbm5pbmcsIG5vIElCU1MsIHJh
ZGFyIGRldGVjdGlvbikKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDUy
ODAgTUh6IFs1Nl0gKDE1LjAgZEJtKSAocGFzc2l2ZSBzY2FubmluZywgbm8gSUJTUywgcmFkYXIg
ZGV0ZWN0aW9uKQo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogNTMwMCBN
SHogWzYwXSAoMTUuMCBkQm0pIChwYXNzaXZlIHNjYW5uaW5nLCBubyBJQlNTLCByYWRhciBkZXRl
Y3Rpb24pCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1MzIwIE1IeiBb
NjRdICgxNS4wIGRCbSkgKHBhc3NpdmUgc2Nhbm5pbmcsIG5vIElCU1MsIHJhZGFyIGRldGVjdGlv
bikKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU1MDAgTUh6IFsxMDBd
IChkaXNhYmxlZCkKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU1MjAg
TUh6IFsxMDRdIChkaXNhYmxlZCkKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAqIDU1NDAgTUh6IFsxMDhdIChkaXNhYmxlZCkKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAqIDU1NjAgTUh6IFsxMTJdIChkaXNhYmxlZCkKPj4gwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU1ODAgTUh6IFsxMTZdIChkaXNhYmxlZCkKPj4gwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU2MDAgTUh6IFsxMjBdIChkaXNhYmxlZCkK
Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU2MjAgTUh6IFsxMjRdIChk
aXNhYmxlZCkKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU2NDAgTUh6
IFsxMjhdIChkaXNhYmxlZCkKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAq
IDU2NjAgTUh6IFsxMzJdIChkaXNhYmxlZCkKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAqIDU2ODAgTUh6IFsxMzZdIChkaXNhYmxlZCkKPj4gwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAqIDU3MDAgTUh6IFsxNDBdIChkaXNhYmxlZCkKPj4gwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU3NDUgTUh6IFsxNDldIChkaXNhYmxlZCkKPj4g
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU3NjUgTUh6IFsxNTNdIChkaXNh
YmxlZCkKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU3ODUgTUh6IFsx
NTddIChkaXNhYmxlZCkKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU4
MDUgTUh6IFsxNjFdIChkaXNhYmxlZCkKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAqIDU4MjUgTUh6IFsxNjVdIChkaXNhYmxlZCkKPj4KPj4gV2hpY2ggaXMgYWJzdXJkLCBi
ZWNhdXNlOgo+Pgo+PiBDb25uZWN0ZWQgdG8gMDA6MDI6NmY6NmU6ZDc6NmMgKG9uIHdsYW4wKQo+
PiDCoCDCoCDCoCDCoFNTSUQ6IEZGVFQ1Cj4+IMKgIMKgIMKgIMKgZnJlcTogNTc4NSDCoCDCoCDC
oCDCoFshISEhISEhISEhIV0KPj4gwqAgwqAgwqAgwqBSWDogNzIwNTggYnl0ZXMgKDMxMCBwYWNr
ZXRzKQo+PiDCoCDCoCDCoCDCoFRYOiAyNTY4IGJ5dGVzICgyMCBwYWNrZXRzKQo+PiDCoCDCoCDC
oCDCoHNpZ25hbDogLTMzIGRCbQo+PiDCoCDCoCDCoCDCoHR4IGJpdHJhdGU6IDYuMCBNQml0L3MK
Pj4KPj4gVGhlIGNvbm5lY3Rpb24gZGllZCBhZnRlciBhIGxpdHRsZSB3aGlsZSwgcHJlc3VtYWJs
eSBiZWNhdXNlIHRoZSBBUAo+PiB3YXMgb3V0c2lkZSBvZiBpdHMgb3duIGFsbG93ZWQgYmFuZC4K
Pj4KPgo+IEhlcmUncyB0aGUgb2ZmZW5kaW5nIGNvdW50cnkgSUU6Cj4KPiBDb3VudHJ5IEluZm9y
bWF0aW9uOiBDb3VudHJ5IENvZGU6IFVTLCBJbmRvb3IgRW52aXJvbm1lbnQKPiBUYWcgTnVtYmVy
OiA3IChDb3VudHJ5IEluZm9ybWF0aW9uKQo+IFRhZyBsZW5ndGg6IDYKPiBUYWcgaW50ZXJwcmV0
YXRpb246IENvdW50cnkgQ29kZTogVVMsIEluZG9vciBFbnZpcm9ubWVudAo+IMKgU3RhcnQgQ2hh
bm5lbDogMzYsIENoYW5uZWxzOiAxMywgTWF4IFRYIFBvd2VyOiAxNiBkQm0KPgo+IEFGQUlDVCBu
ZXQvd2lyZWxlc3MvcmVnLmMgaWdub3JlcyB0aGUgbGFzdCBiaXQsIGFuZCB0aGUgb3RoZXIgQVBz
IHRoYXQKPiB3b3JrIGNvcnJlY3RseSBoZXJlIGRvbid0IHNlbmQgY291bnRyeSBJRXMuCgpDYW4g
eW91IHByb3ZpZGUgdGhlIG91dHB1dCBvZiBpdyBkZXYgd2xhbjAgc2NhbiBmcm9tIGEgZnJlc2gg
Z2l0CnZlcnNpb24gb2YgaXc/IFRoYXQgd2lsbCBhY3R1YWxseSB0ZWxsIG1lIG1vcmUgdGhhbiB5
b3VyIGxpc3RpbmcuCgogIEx1aXMK
^ permalink raw reply
* Re: regulatory hiccup
From: Luis R. Rodriguez @ 2010-07-27 23:32 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: linux-wireless
In-Reply-To: <AANLkTinfMiS=+dqi=azF2exJbkrSLYT9nN0aor7gff-Q@mail.gmail.com>
T24gRnJpLCBKdWwgMjMsIDIwMTAgYXQgMTI6MzUgUE0sIEFuZHJldyBMdXRvbWlyc2tpIDxsdXRv
QG1pdC5lZHU+IHdyb3RlOgo+IE9uIEZyaSwgSnVsIDIzLCAyMDEwIGF0IDM6MzAgUE0sIEFuZHJl
dyBMdXRvbWlyc2tpIDxsdXRvQG1pdC5lZHU+IHdyb3RlOgo+Pgo+PiBUaGVuLCBhZnRlciBmaWRk
bGluZyB3aXRoIGFuIEFQIGZvciBhIGJpdCwgSSBnb3Q6Cj4+Cj4+IFsxMTc0Ny4yNjQyMjFdIGNm
ZzgwMjExOiBDYWxsaW5nIENSREEgZm9yIGNvdW50cnk6IFVTCj4+IFsxMTc0Ny4yODI2NjRdIGNm
ZzgwMjExOiBDdXJyZW50IHJlZ3VsYXRvcnkgZG9tYWluIHVwZGF0ZWQgYnkgQVAgdG86IFVTCj4+
IFsxMTc0Ny4yODI2NzJdIMKgIMKgIChzdGFydF9mcmVxIC0gZW5kX2ZyZXEgQCBiYW5kd2lkdGgp
LAo+PiAobWF4X2FudGVubmFfZ2FpbiwgbWF4X2VpcnApCj4+IFsxMTc0Ny4yODI2ODBdIMKgIMKg
ICg1MTcwMDAwIEtIeiAtIDUyNTAwMDAgS0h6IEAgNDAwMDAgS0h6KSwgKDMwMCBtQmksIDE2MDAg
bUJtKQo+PiBbMTE3NDcuMjgyNjg4XSDCoCDCoCAoNTI1MDAwMCBLSHogLSA1MzMwMDAwIEtIeiBA
IDQwMDAwIEtIeiksICgzMDAgbUJpLCAxNjAwIG1CbSkKPj4KPgo+IEl0J3Mgd29yc2UgdGhhbiB0
aGF0LiDCoEkgcmVjb25uZWN0ZWQgdG8gdGhlIEFQIChpdCBhcHBlYXJlZCB0byB3b3JrCj4gZm9y
IGEgZmV3IHNlY29uZHMpIGFuZCBJIHNhdzoKPgo+IFdpcGh5IHBoeTAKPiBbLi4uXQo+IMKgIMKg
IMKgIMKgQmFuZCAyOgo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgQ2FwYWJpbGl0aWVzOiAweDg3
Mgo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgSFQyMC9IVDQwCj4gwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBTdGF0aWMgU00gUG93ZXIgU2F2ZQo+IMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgUlggR3JlZW5maWVsZAo+IMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgUlggSFQyMCBTR0kKPiDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoFJYIEhUNDAgU0dJCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqBObyBSWCBTVEJDCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBN
YXggQU1TRFUgbGVuZ3RoOiAzODM5IGJ5dGVzCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqBObyBEU1NTL0NDSyBIVDQwCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBNYXhpbXVt
IFJYIEFNUERVIGxlbmd0aCA2NTUzNSBieXRlcyAoZXhwb25lbnQ6IDB4MDAzKQo+IMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgTWluaW11bSBSWCBBTVBEVSB0aW1lIHNwYWNpbmc6IDQgdXNlYyAoMHgw
NSkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEhUIFRYL1JYIE1DUyByYXRlIGluZGV4ZXMgc3Vw
cG9ydGVkOiAwLTIzLCAzMgo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgRnJlcXVlbmNpZXM6Cj4g
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDUxODAgTUh6IFszNl0gKDE1LjAg
ZEJtKSAocGFzc2l2ZSBzY2FubmluZywgbm8gSUJTUykKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCogNTIwMCBNSHogWzQwXSAoMTUuMCBkQm0pIChwYXNzaXZlIHNjYW5uaW5n
LCBubyBJQlNTKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1MjIwIE1I
eiBbNDRdICgxNS4wIGRCbSkgKHBhc3NpdmUgc2Nhbm5pbmcsIG5vIElCU1MpCj4gwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDUyNDAgTUh6IFs0OF0gKDE1LjAgZEJtKSAocGFz
c2l2ZSBzY2FubmluZywgbm8gSUJTUykKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCogNTI2MCBNSHogWzUyXSAoMTUuMCBkQm0pIChwYXNzaXZlIHNjYW5uaW5nLCBubyBJQlNT
LCByYWRhciBkZXRlY3Rpb24pCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAq
IDUyODAgTUh6IFs1Nl0gKDE1LjAgZEJtKSAocGFzc2l2ZSBzY2FubmluZywgbm8gSUJTUywgcmFk
YXIgZGV0ZWN0aW9uKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1MzAw
IE1IeiBbNjBdICgxNS4wIGRCbSkgKHBhc3NpdmUgc2Nhbm5pbmcsIG5vIElCU1MsIHJhZGFyIGRl
dGVjdGlvbikKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogNTMyMCBNSHog
WzY0XSAoMTUuMCBkQm0pIChwYXNzaXZlIHNjYW5uaW5nLCBubyBJQlNTLCByYWRhciBkZXRlY3Rp
b24pCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU1MDAgTUh6IFsxMDBd
IChkaXNhYmxlZCkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogNTUyMCBN
SHogWzEwNF0gKGRpc2FibGVkKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
KiA1NTQwIE1IeiBbMTA4XSAoZGlzYWJsZWQpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAqIDU1NjAgTUh6IFsxMTJdIChkaXNhYmxlZCkKPiDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCogNTU4MCBNSHogWzExNl0gKGRpc2FibGVkKQo+IMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1NjAwIE1IeiBbMTIwXSAoZGlzYWJsZWQpCj4gwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU2MjAgTUh6IFsxMjRdIChkaXNhYmxl
ZCkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogNTY0MCBNSHogWzEyOF0g
KGRpc2FibGVkKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1NjYwIE1I
eiBbMTMyXSAoZGlzYWJsZWQpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAq
IDU2ODAgTUh6IFsxMzZdIChkaXNhYmxlZCkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCogNTcwMCBNSHogWzE0MF0gKGRpc2FibGVkKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgKiA1NzQ1IE1IeiBbMTQ5XSAoZGlzYWJsZWQpCj4gwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU3NjUgTUh6IFsxNTNdIChkaXNhYmxlZCkKPiDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogNTc4NSBNSHogWzE1N10gKGRpc2FibGVk
KQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1ODA1IE1IeiBbMTYxXSAo
ZGlzYWJsZWQpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU4MjUgTUh6
IFsxNjVdIChkaXNhYmxlZCkKPgo+IFdoaWNoIGlzIGFic3VyZCwgYmVjYXVzZToKPgo+IENvbm5l
Y3RlZCB0byAwMDowMjo2Zjo2ZTpkNzo2YyAob24gd2xhbjApCj4gwqAgwqAgwqAgwqBTU0lEOiBG
RlRUNQo+IMKgIMKgIMKgIMKgZnJlcTogNTc4NSDCoCDCoCDCoCDCoFshISEhISEhISEhIV0KPiDC
oCDCoCDCoCDCoFJYOiA3MjA1OCBieXRlcyAoMzEwIHBhY2tldHMpCj4gwqAgwqAgwqAgwqBUWDog
MjU2OCBieXRlcyAoMjAgcGFja2V0cykKPiDCoCDCoCDCoCDCoHNpZ25hbDogLTMzIGRCbQo+IMKg
IMKgIMKgIMKgdHggYml0cmF0ZTogNi4wIE1CaXQvcwo+Cj4gVGhlIGNvbm5lY3Rpb24gZGllZCBh
ZnRlciBhIGxpdHRsZSB3aGlsZSwgcHJlc3VtYWJseSBiZWNhdXNlIHRoZSBBUAo+IHdhcyBvdXRz
aWRlIG9mIGl0cyBvd24gYWxsb3dlZCBiYW5kLgoKSGVoIHllYWggaXQgY291bGQgYmUgdGhlIEFQ
IHNlbmRzIGEgY291bnRyeSBJRSB3aGljaCBkb2VzIG5vdCBoYXZlIHRoZQpjaGFubmVsIGl0IGl0
c2VsZiBpcyBvbiwgd291bGQgYmUgcmVhbGx5IG9kZCBidXQgYXQgdGhpcyBwb2ludCBJJ3ZlCnNl
ZW4gb3RoZXIgZHVtYiB0aGluZ3MgdGhhdCBBUHMgZG8uIFRoZSBJRSBkdW1wIHlvdSBnb3QgaXMg
T0sgYnV0IGRvZXMKbm90IGdpdmUgbWUgZW5vdWdoIGluZm8gYWJvdXQgaG93IGl0IGlzIGV4YWN0
bHkgc3RydWN0dXJlZC4gSSdsbCByZXBseQp0byB0aGF0IHRocmVhZCBuZXh0LgoKICBMdWlzCg==
^ permalink raw reply
* Re: iwlagn: two regressions 2.6.34->2.6.35-rc6
From: Luis R. Rodriguez @ 2010-07-27 23:26 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: linux-wireless, ilw
In-Reply-To: <AANLkTi=rNVifMZ_8UzmWH=f26X0pT9UM5XT7U7wE2FWd@mail.gmail.com>
On Tue, Jul 27, 2010 at 4:24 PM, Andrew Lutomirski <luto@mit.edu> wrote:
> On Mon, Jul 26, 2010 at 3:48 PM, Andrew Lutomirski <luto@mit.edu> wrote:
>>> In the attached log, you'll see the one successful connection to
>>> 00:02:6f:6e:d7:6c as well as a failure. The failure is just:
>>>
>>> [ 668.569218] wlan0: authenticate with 00:02:6f:6e:d7:6c (try 1)
>>> [ 668.769269] wlan0: authenticate with 00:02:6f:6e:d7:6c (try 2)
>>> [ 668.969150] wlan0: authenticate with 00:02:6f:6e:d7:6c (try 3)
>>> [ 669.169262] wlan0: authentication with 00:02:6f:6e:d7:6c timed out
>>
>> This time with actual attachment.
>
> Not sure if this is the same issue, but I've got another AP here
> (Ubiquiti RouterStation Pro + R52N ath9k minipci card running latest
> OpenWRT "backfire") that works quite nicely on 2.6.34 but requires me
> to reconnect every minute or so on 2.6.35-rc6+ to keep it working.
Define 2.6.35-rc6+
If you are using wireless-testing there was a regression there that I
just sent patches for.
Reporting issues is the way to go which BTW i have yet to get to your
other e-mail, sorry just got back from vacation and still catching up.
> I'm getting tempted to just revert the whole driver back to 2.6.34 and
> use the rest of 2.6.35 when it comes out. I can also try to bisect,
> either the normal way or just the iwlwifi driver, but that'll have to
> wait until the Monday after next at least because I'm leaving town.
> If any of you have any ideas to test *today*, I can do it.
>
> This is a 5350, which I guess is somewhat rare given the general lack
> of WiMAX coverage.
>
> --Andy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Luis
^ permalink raw reply
* Re: regulatory hiccup
From: Luis R. Rodriguez @ 2010-07-27 23:30 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: linux-wireless
In-Reply-To: <AANLkTimdDhHudW6_7Hwcf6UCumY_EgqGd7CLtmSgOzEz@mail.gmail.com>
On Fri, Jul 23, 2010 at 12:30 PM, Andrew Lutomirski <luto@mit.edu> wrote:
> This is 2.6.35-rc4, but this bug (?) might exist in other versions ,too.
>
> Early in boot, all was well:
>
> [ 5524.214376] cfg80211: Calling CRDA to update world regulatory domain
> [ 5524.219025] cfg80211: Calling CRDA for country: US
> [ 5524.238440] cfg80211: Regulatory domain changed to country: US
> [ 5524.238443] (start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> [ 5524.238446] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
> [ 5524.238448] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
> [ 5524.238451] (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ 5524.238454] (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ 5524.238456] (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ 5524.238459] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>
> Then, after fiddling with an AP for a bit, I got:
>
> [11747.264221] cfg80211: Calling CRDA for country: US
> [11747.282664] cfg80211: Current regulatory domain updated by AP to: US
> [11747.282672] (start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> [11747.282680] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1600 mBm)
> [11747.282688] (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 1600 mBm)
>
> (Note lots of missing channels after that.) iw phy phy0 info showed
> all the channels above 5.33GHz disabled. I didn't see some other APs
> that were there.
>
> Later on I disconnected, CRDA got called again, and all was well.
>
> The AP that I had just connected to when everything broke was an
> EnGenuis ESR7750 (brand new), and maybe it sent something wrong, but
> surely if it says US it shouldn't disable other APs on US bands that
> CRDA says is OK.
If you are saying the the AP's Country IE is a subset of what CRDA has
and complaining that we follow that, yes that is true. We were being
very careful and only recently revisited this again with our
regulatory folks. It was determined to be fair to disregard the AP's
own regulatory data and follow our own since we do keep good tabs on
our wireless-regdb. Patches for that were sent by Linville and will be
part of 2.6.36, you can either cherry pick those or wait for
2.6.36-rc1 or the respective compat-wireless-2.6.36-rc1
Luis
^ permalink raw reply
* Re: iwlagn: two regressions 2.6.34->2.6.35-rc6
From: Andrew Lutomirski @ 2010-07-27 23:24 UTC (permalink / raw)
To: linux-wireless, ilw
In-Reply-To: <AANLkTimr-tyyNfLz7c9hKVMwWm-5qQcsUniKmv8kvC8U@mail.gmail.com>
On Mon, Jul 26, 2010 at 3:48 PM, Andrew Lutomirski <luto@mit.edu> wrote:
>> In the attached log, you'll see the one successful connection to
>> 00:02:6f:6e:d7:6c as well as a failure. The failure is just:
>>
>> [ 668.569218] wlan0: authenticate with 00:02:6f:6e:d7:6c (try 1)
>> [ 668.769269] wlan0: authenticate with 00:02:6f:6e:d7:6c (try 2)
>> [ 668.969150] wlan0: authenticate with 00:02:6f:6e:d7:6c (try 3)
>> [ 669.169262] wlan0: authentication with 00:02:6f:6e:d7:6c timed out
>
> This time with actual attachment.
Not sure if this is the same issue, but I've got another AP here
(Ubiquiti RouterStation Pro + R52N ath9k minipci card running latest
OpenWRT "backfire") that works quite nicely on 2.6.34 but requires me
to reconnect every minute or so on 2.6.35-rc6+ to keep it working.
I'm getting tempted to just revert the whole driver back to 2.6.34 and
use the rest of 2.6.35 when it comes out. I can also try to bisect,
either the normal way or just the iwlwifi driver, but that'll have to
wait until the Monday after next at least because I'm leaving town.
If any of you have any ideas to test *today*, I can do it.
This is a 5350, which I guess is somewhat rare given the general lack
of WiMAX coverage.
--Andy
^ permalink raw reply
* Re: [stable] [PATCH 1/4 2.6.33.y] mac80211: explicitly disable/enable QoS
From: Ben Hutchings @ 2010-07-27 23:15 UTC (permalink / raw)
To: Greg KH; +Cc: Stanislaw Gruszka, stable, linux-wireless
In-Reply-To: <20100727224008.GM14257@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]
On Tue, 2010-07-27 at 15:40 -0700, Greg KH wrote:
> On Mon, Jun 07, 2010 at 12:00:24PM +0200, Stanislaw Gruszka wrote:
> > commit e1b3ec1a2a336c328c336cfa5485a5f0484cc90d upstream.
> >
> > Add interface to disable/enable QoS (aka WMM or WME). Currently drivers
> > enable it explicitly when ->conf_tx method is called, and newer disable.
> > Disabling is needed for some APs, which do not support QoS, such
> > we should send QoS frames to them.
>
> Why is this a patch for a -stable tree? It looks like it adds a new api
> for a new feature, right?
[...]
It extends the interface between the 802.11 stack and drivers so that
drivers can avoid sending QoS frames to APs that don't support them.
There is no new interface to userland. My understanding is that iwlwifi
becomes unable to communicate with non-QoS-capable APs after having once
associated with a QoS-capable AP, without this and the following change
in iwlwifi itself.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Pull request: bluetooth-next-2.6 2010-07-27
From: Marcel Holtmann @ 2010-07-27 22:53 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
Hi John,
I have a few more patches for the 2.6.36 merge window. Besides the SCO
setup fix they are just cleanups anyway.
Regards
Marcel
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-next-2.6.git master
This will update the following files:
drivers/bluetooth/hci_ath.c | 6 +-
drivers/bluetooth/hci_bcsp.c | 4 +-
drivers/bluetooth/hci_h4.c | 107 ++------------------------------------
drivers/bluetooth/hci_ll.c | 4 +-
include/net/bluetooth/hci_core.h | 2 +
net/bluetooth/hci_conn.c | 32 ++++++++++--
net/bluetooth/hci_core.c | 8 ++--
net/bluetooth/hci_event.c | 31 +++++------
net/bluetooth/rfcomm/sock.c | 2 +-
net/bluetooth/rfcomm/tty.c | 4 +-
10 files changed, 63 insertions(+), 137 deletions(-)
mode change 100755 => 100644 drivers/bluetooth/hci_ath.c
through these ChangeSets:
Dan Carpenter (1):
Bluetooth: Fix kfree() => kfree_skb() in hci_ath.c
Gustavo F. Padovan (5):
Bluetooth: Fix permission of hci_ath.c
Bluetooth: Test 'count' value before enter the loop
Bluetooth: Use hci_recv_stream_fragment() in UART driver
Bluetooth: Add __init and __exit marks to UART drivers
Bluetooth: Add __init and __exit marks to RFCOMM
Marcel Holtmann (1):
Bluetooth: Defer SCO setup if mode change is pending
^ permalink raw reply
* Re: [stable] [PATCH 1/4 2.6.33.y] mac80211: explicitly disable/enable QoS
From: Greg KH @ 2010-07-27 22:40 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: stable, linux-wireless, Ben Hutchings
In-Reply-To: <1275904827-6598-1-git-send-email-sgruszka@redhat.com>
On Mon, Jun 07, 2010 at 12:00:24PM +0200, Stanislaw Gruszka wrote:
> commit e1b3ec1a2a336c328c336cfa5485a5f0484cc90d upstream.
>
> Add interface to disable/enable QoS (aka WMM or WME). Currently drivers
> enable it explicitly when ->conf_tx method is called, and newer disable.
> Disabling is needed for some APs, which do not support QoS, such
> we should send QoS frames to them.
Why is this a patch for a -stable tree? It looks like it adds a new api
for a new feature, right?
confused,
greg k-h
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
> include/net/mac80211.h | 5 +++++
> net/mac80211/mlme.c | 9 ++++++++-
> net/mac80211/util.c | 5 +++++
> 3 files changed, 18 insertions(+), 1 deletions(-)
>
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index f39b303..8c1f0ee 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -577,11 +577,15 @@ struct ieee80211_rx_status {
> * may turn the device off as much as possible. Typically, this flag will
> * be set when an interface is set UP but not associated or scanning, but
> * it can also be unset in that case when monitor interfaces are active.
> + * @IEEE80211_CONF_QOS: Enable 802.11e QoS also know as WMM (Wireless
> + * Multimedia). On some drivers (iwlwifi is one of know) we have
> + * to enable/disable QoS explicitly.
> */
> enum ieee80211_conf_flags {
> IEEE80211_CONF_MONITOR = (1<<0),
> IEEE80211_CONF_PS = (1<<1),
> IEEE80211_CONF_IDLE = (1<<2),
> + IEEE80211_CONF_QOS = (1<<3),
> };
>
>
> @@ -604,6 +608,7 @@ enum ieee80211_conf_changed {
> IEEE80211_CONF_CHANGE_CHANNEL = BIT(6),
> IEEE80211_CONF_CHANGE_RETRY_LIMITS = BIT(7),
> IEEE80211_CONF_CHANGE_IDLE = BIT(8),
> + IEEE80211_CONF_CHANGE_QOS = BIT(9),
> };
>
> /**
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 1a209ac..950088d 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -798,6 +798,9 @@ static void ieee80211_sta_wmm_params(struct ieee80211_local *local,
> int count;
> u8 *pos;
>
> + if (!local->ops->conf_tx)
> + return;
> +
> if (!(ifmgd->flags & IEEE80211_STA_WMM_ENABLED))
> return;
>
> @@ -856,11 +859,15 @@ static void ieee80211_sta_wmm_params(struct ieee80211_local *local,
> wiphy_name(local->hw.wiphy), queue, aci, acm,
> params.aifs, params.cw_min, params.cw_max, params.txop);
> #endif
> - if (drv_conf_tx(local, queue, ¶ms) && local->ops->conf_tx)
> + if (drv_conf_tx(local, queue, ¶ms))
> printk(KERN_DEBUG "%s: failed to set TX queue "
> "parameters for queue %d\n",
> wiphy_name(local->hw.wiphy), queue);
> }
> +
> + /* enable WMM or activate new settings */
> + local->hw.conf.flags |= IEEE80211_CONF_QOS;
> + drv_config(local, IEEE80211_CONF_CHANGE_QOS);
> }
>
> static u32 ieee80211_handle_bss_capability(struct ieee80211_sub_if_data *sdata,
> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> index 27212e8..9e35dcb 100644
> --- a/net/mac80211/util.c
> +++ b/net/mac80211/util.c
> @@ -795,6 +795,11 @@ void ieee80211_set_wmm_default(struct ieee80211_sub_if_data *sdata)
>
> drv_conf_tx(local, queue, &qparam);
> }
> +
> + /* after reinitialize QoS TX queues setting to default,
> + * disable QoS at all */
> + local->hw.conf.flags &= ~IEEE80211_CONF_QOS;
> + drv_config(local, IEEE80211_CONF_CHANGE_QOS);
> }
>
> void ieee80211_sta_def_wmm_params(struct ieee80211_sub_if_data *sdata,
> --
> 1.6.2.5
>
> _______________________________________________
> stable mailing list
> stable@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/stable
^ permalink raw reply
* Re: [stable] [PATCH 2/2 2.6.32.y] mac80211: fix supported rates IE if AP doesn't give us it's rates
From: Greg KH @ 2010-07-27 22:39 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: stable, linux-wireless, Ben Hutchings
In-Reply-To: <1275904783-6563-2-git-send-email-sgruszka@redhat.com>
On Mon, Jun 07, 2010 at 11:59:43AM +0200, Stanislaw Gruszka wrote:
> If AP do not provide us supported rates before assiociation, send
> all rates we are supporting instead of empty information element.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
> net/mac80211/mlme.c | 17 +++++++++++------
What is the commit id of this patch upstream?
thanks,
greg k-h
> 1 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index d3950b7..abd62fc 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -269,12 +269,6 @@ static void ieee80211_send_assoc(struct ieee80211_sub_if_data *sdata,
> if (wk->bss->wmm_used)
> wmm = 1;
>
> - /* get all rates supported by the device and the AP as
> - * some APs don't like getting a superset of their rates
> - * in the association request (e.g. D-Link DAP 1353 in
> - * b-only mode) */
> - rates_len = ieee80211_compatible_rates(wk->bss, sband, &rates);
> -
> if ((wk->bss->cbss.capability & WLAN_CAPABILITY_SPECTRUM_MGMT) &&
> (local->hw.flags & IEEE80211_HW_SPECTRUM_MGMT))
> capab |= WLAN_CAPABILITY_SPECTRUM_MGMT;
> @@ -309,6 +303,17 @@ static void ieee80211_send_assoc(struct ieee80211_sub_if_data *sdata,
> *pos++ = wk->ssid_len;
> memcpy(pos, wk->ssid, wk->ssid_len);
>
> + if (wk->bss->supp_rates_len) {
> + /* get all rates supported by the device and the AP as
> + * some APs don't like getting a superset of their rates
> + * in the association request (e.g. D-Link DAP 1353 in
> + * b-only mode) */
> + rates_len = ieee80211_compatible_rates(wk->bss, sband, &rates);
> + } else {
> + rates = ~0;
> + rates_len = sband->n_bitrates;
> + }
> +
> /* add all rates which were marked to be used above */
> supp_rates_len = rates_len;
> if (supp_rates_len > 8)
> --
> 1.6.2.5
>
> _______________________________________________
> stable mailing list
> stable@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/stable
^ permalink raw reply
* Re: [stable] [PATCH 2.6.32.y] ath9k: re-enable ps by default for new single chip families
From: Greg KH @ 2010-07-27 22:22 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: stable, linux-wireless, John W. Linville, Kristoffer Ericson,
Justin P. Mattock, Peter Stuge
In-Reply-To: <1276640359-25360-1-git-send-email-lrodriguez@atheros.com>
On Tue, Jun 15, 2010 at 06:19:19PM -0400, Luis R. Rodriguez wrote:
> commit 14acdde6e527950f66c084dbf19bad6fbfcaeedc upstream.
>
> The newer single chip hardware family of chipsets have not been
> experiencing issues with power saving set by default with recent
> fixes merged (even into stable). The remaining issues are only
> reported with AR5416 and since enabling PS by default can increase
> power savings considerably best to take advantage of that feature
> as this has been tested properly.
>
> For more details on this issue see the bug report:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=14267
>
> We leave AR5416 with PS disabled by default, that seems to require
> some more work.
>
> Cc: stable@kernel.org
> Cc: Peter Stuge <peter@stuge.se>
> Cc: Justin P. Mattock <justinmattock@gmail.com>
> Cc: Kristoffer Ericson <kristoffer.ericson@gmail.com>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
>
> Greg, this is the long promised backport of the patch titled
> "ath9k: re-enable ps by default for new single chip families" backported
> down to 2.6.32.y. This just goes test compiled. Manual backport
> was required from the upstream Linus patch since the flag
> WIPHY_FLAG_PS_ON_BY_DEFAULT was not used back on 2.6.32 so instead
> we use the equivalent hw->wiphy->ps_default bool.
>
> Apologies for the delay, was just stuck with other stuff.
>
> I'll remove this from the stable pending list for 802.11 [1] once
> this gets sucked in.
Now queued up, thanks.
greg k-h
^ permalink raw reply
* Re: [stable] [PATCH 2.6.32..2.6.33] ath5k: drop warning on jumbo frames
From: Greg KH @ 2010-07-27 22:18 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: stable, linux-wireless, John W. Linville
In-Reply-To: <1276641307-10287-1-git-send-email-lrodriguez@atheros.com>
On Tue, Jun 15, 2010 at 06:35:07PM -0400, Luis R. Rodriguez wrote:
> commit 9637e516d16a58b13f6098cfe899e22963132be3 upstream.
>
> Jumbo frames are not supported, and if they are seen it is likely
> a bogus frame so just silently discard them instead of warning on
> them all time. Also, instead of dropping them immediately though
> move the check *after* we check for all sort of frame errors. This
> should enable us to discard these frames if the hardware picks
> other bogus items first. Lets see if we still get those jumbo
> counters increasing still with this.
>
> Jumbo frames would happen if we tell hardware we can support
> a small 802.11 chunks of DMA'd frame, hardware would split RX'd
> frames into parts and we'd have to reconstruct them in software.
> This is done with USB due to the bulk size but with ath5k we
> already provide a good limit to hardware and this should not be
> happening.
>
> This is reported quite often and if it fills the logs then this
> needs to be addressed and to avoid spurious reports.
>
> Cc: stable@kernel.org
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
>
> Greg, here's a stable ath5k patch which required some manual
> backport. The backported was needed since the sc->stats.rxerr_jumbo
> counter was not available until 2.6.34 and it was used on the upstream
> commit. This goes only compile tested against 2.6.32.y and 2.6.33.y.
Many thanks, I've now commited this one.
greg k-h
^ permalink raw reply
* Re: [BUG] after starting wimaxd at boot iwlagn module will crash for intel 6250 card
From: Inaky Perez-Gonzalez @ 2010-07-27 22:38 UTC (permalink / raw)
To: alexxy@gentoo.org; +Cc: wimax@linuxwimax.org, linux-wireless
In-Reply-To: <201007280028.48674.alexxy@gentoo.org>
On Tue, 2010-07-27 at 13:28 -0700, Alexey Shvetsov wrote:
> Hi all!
[apologies, I forgot to mention to CC the linux-wireless mailing list,
where the iwlagn guys lurk around -- done].
Guys, seems the wifi device is tripping in the 6250 when we switch on
WiMAX. Do you see anything interesting?
> Seems i fund bug on my 64bit system. I have installed 32bit version
> of wimax stack 1.5 and i'm running 2.6.35-rc6 kernel.
>
> After starting
> wimaxd at boot time iwlagn driver will crash when i try to scan or connect
> to any network. Stacktrace will be the following
>
> iwlagn 0000:02:00.0:
> RF_KILL bit toggled to enable radio.
> i2400m_usb 2-1.3:1.0: 'RF Control'
> (0x4602) command failed: -84 - invalid state (3)
> iwlagn 0000:02:00.0:
> Microcode SW error detected. Restarting 0x2000000.
> iwlagn 0000:02:00.0:
> Loaded firmware version: 9.201.4.1 build 24255
> iwlagn 0000:02:00.0: Start
> IWL Error Log Dump:
> iwlagn 0000:02:00.0: Status: 0x00020224, count: 5
> iwlagn
> 0000:02:00.0: Desc Time data1 data2
> line
> iwlagn 0000:02:00.0: SYSASSERT (#05) 0000012334
> 0x0000008D 0x8000000D 453
> iwlagn 0000:02:00.0: pc blink1 blink2
> ilink1 ilink2 hcmd
> iwlagn 0000:02:00.0: 0x1D074 0x1D066 0x1D066 0x009B2
> 0x00000 0x400005A
> iwlagn 0000:02:00.0: CSR values:
> iwlagn 0000:02:00.0: (2nd
> byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG)
> iwlagn 0000:02:00.0:
> CSR_HW_IF_CONFIG_REG: 0X00480303
> iwlagn 0000:02:00.0:
> CSR_INT_COALESCING: 0X0000ff40
> iwlagn 0000:02:00.0:
> CSR_INT: 0X00000000
> iwlagn 0000:02:00.0: CSR_INT_MASK:
> 0X00000000
> iwlagn 0000:02:00.0: CSR_FH_INT_STATUS:
> 0X00000000
> iwlagn 0000:02:00.0: CSR_GPIO_IN:
> 0X0000000f
> iwlagn 0000:02:00.0: CSR_RESET:
> 0X00000000
> iwlagn 0000:02:00.0: CSR_GP_CNTRL:
> 0X080403c5
> iwlagn 0000:02:00.0: CSR_HW_REV:
> 0X00000084
> iwlagn 0000:02:00.0: CSR_EEPROM_REG:
> 0Xe0a20ffd
> iwlagn 0000:02:00.0: CSR_EEPROM_GP:
> 0X90000801
> iwlagn 0000:02:00.0: CSR_OTP_GP_REG:
> 0X00030001
> iwlagn 0000:02:00.0: CSR_GIO_REG:
> 0X00080046
> iwlagn 0000:02:00.0: CSR_GP_UCODE_REG:
> 0X00000002
> iwlagn 0000:02:00.0: CSR_GP_DRIVER_REG:
> 0X00000004
> iwlagn 0000:02:00.0: CSR_UCODE_DRV_GP1:
> 0X00000000
> iwlagn 0000:02:00.0: CSR_UCODE_DRV_GP2:
> 0X00000000
> iwlagn 0000:02:00.0: CSR_LED_REG:
> 0X00000018
> iwlagn 0000:02:00.0: CSR_DRAM_INT_TBL_REG:
> 0X00000000
> iwlagn 0000:02:00.0: CSR_GIO_CHICKEN_BITS:
> 0X27800200
> iwlagn 0000:02:00.0: CSR_ANA_PLL_CFG:
> 0X00000000
> iwlagn 0000:02:00.0: CSR_HW_REV_WA_REG:
> 0X0001001a
> iwlagn 0000:02:00.0: CSR_DBG_HPET_MEM_REG:
> 0Xffff0000
> iwlagn 0000:02:00.0: FH register values:
> iwlagn 0000:02:00.0:
> FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X0ffede00
> iwlagn 0000:02:00.0:
> FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X00ffedf0
> iwlagn 0000:02:00.0:
> FH_RSCSR_CHNL0_WPTR: 0X00000000
> iwlagn 0000:02:00.0:
> FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
> iwlagn 0000:02:00.0:
> FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
> iwlagn 0000:02:00.0:
> FH_MEM_RSSR_RX_STATUS_REG: 0X07030000
> iwlagn 0000:02:00.0:
> FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
> iwlagn 0000:02:00.0:
> FH_TSSR_TX_STATUS_REG: 0X07ff0001
> iwlagn 0000:02:00.0:
> FH_TSSR_TX_ERROR_REG: 0X00000000
> iwlagn 0000:02:00.0: Start IWL Event Log
> Dump: display last 20 entries
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000004384:0x000000ff:1100
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000004385:0x000000ff:1100
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000004385:0x000000ff:1100
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000004387:0x000000ff:1100
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000004388:0x000000ff:1100
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000004388:0x000000ff:1100
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000004389:0x000000ff:1100
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000004390:0x000000ff:1100
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000004391:0x000000ff:1100
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000004391:0x000000ff:1100
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000004392:0x000000ff:1100
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000004402:0x000003b1:0601
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000004402:0x10000000:0600
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000004403:0x000003c1:0660
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000004407:0x00000000:0661
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000012227:0x0400005a:0401
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000012228:0x0400005a:1513
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000012228:0x00000000:1513
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000012229:0x00000001:1523
> iwlagn 0000:02:00.0:
> EVT_LOGT:0000012344:0x00000000:0125
> iwlagn 0000:02:00.0: Command
> REPLY_PHY_CALIBRATION_CMD failed: FW Error
> iwlagn 0000:02:00.0: Error -5
> iteration 0
> usb 1-1.4: new full speed USB device using ehci_hcd and address
> 5
> iwlagn 0000:02:00.0: Error sending CALIBRATION_CFG_CMD: time out after
> 500ms.
> Bluetooth: Generic Bluetooth USB driver ver 0.6
> usbcore: registered
> new interface driver btusb
> Bluetooth: BNEP (Ethernet Emulation) ver
> 1.3
> Bluetooth: BNEP filters: protocol multicast
> Bluetooth: SCO (Voice Link)
> ver 0.6
> Bluetooth: SCO socket layer initialized
> iwlagn 0000:02:00.0:
> START_ALIVE timeout after 4000ms.
>
> initial state for defices are
>
> rfkill
> list
> 0: tpacpi_bluetooth_sw: Bluetooth
> Soft blocked: no
>
> Hard blocked: no
> 1: hci0: Bluetooth
> Soft blocked: no
> Hard
> blocked: no
> 2: i2400m-usb:2-1.3:1.0: WiMAX
> Soft blocked: yes
>
> Hard blocked: no
> 3: phy0: Wireless LAN
> Soft blocked: no
> Hard
> blocked: no
>
^ permalink raw reply
* [PATCH 1/3] ath9k: remove the two wiphys scanning at the same time message
From: Luis R. Rodriguez @ 2010-07-27 20:33 UTC (permalink / raw)
To: linville, johannes; +Cc: linux-wireless, Luis R. Rodriguez, Johannes Berg
In-Reply-To: <1280262788-9890-1-git-send-email-lrodriguez@atheros.com>
When issuing two consecutive scans you could often end up
getting in the logs:
"ath9k: Two wiphys trying to scan at the same time"
This message is due to a race in mac80211 but addressing
that race requires some more major changes on the driver
and perhaps optimizations on mac80211 like removing the
scan complete callback alltogether. Its too late to address
this this kernel release so supress the complaint and annotate
this needs fixing for later.
Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/main.c | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 6cf0410..0429dda 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1994,11 +1994,12 @@ static void ath9k_sw_scan_start(struct ieee80211_hw *hw)
mutex_lock(&sc->mutex);
if (ath9k_wiphy_scanning(sc)) {
- printk(KERN_DEBUG "ath9k: Two wiphys trying to scan at the "
- "same time\n");
/*
- * Do not allow the concurrent scanning state for now. This
- * could be improved with scanning control moved into ath9k.
+ * There is a race here in mac80211 but fixing it requires
+ * we revisit how we handle the scan complete callback.
+ * After mac80211 fixes we will not have configured hardware
+ * to the home channel nor would we have configured the RX
+ * filter yet.
*/
mutex_unlock(&sc->mutex);
return;
@@ -2014,6 +2015,10 @@ static void ath9k_sw_scan_start(struct ieee80211_hw *hw)
mutex_unlock(&sc->mutex);
}
+/*
+ * XXX: this requires a revisit after the driver
+ * scan_complete gets moved to another place/removed in mac80211.
+ */
static void ath9k_sw_scan_complete(struct ieee80211_hw *hw)
{
struct ath_wiphy *aphy = hw->priv;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] mac80211_hwsim: supress scan conflict message
From: Luis R. Rodriguez @ 2010-07-27 20:33 UTC (permalink / raw)
To: linville, johannes; +Cc: linux-wireless, Luis R. Rodriguez, Johannes Berg
In-Reply-To: <1280262788-9890-1-git-send-email-lrodriguez@atheros.com>
Johannes already debugged this and determined it was due
to a race condition in mac80211, in order to fix this though
we would need to change drivers quite a bit so for now just
supress this and we'll correct this on the next kernel release.
Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/mac80211_hwsim.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 01ad7f7..d766a5f 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -995,10 +995,8 @@ static void mac80211_hwsim_sw_scan(struct ieee80211_hw *hw)
mutex_lock(&hwsim->mutex);
- if (hwsim->scanning) {
- printk(KERN_DEBUG "two hwsim sw_scans detected!\n");
+ if (hwsim->scanning)
goto out;
- }
printk(KERN_DEBUG "hwsim sw_scan request, prepping stuff\n");
hwsim->scanning = true;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/3] Revert "mac80211: fix sw scan bracketing"
From: Luis R. Rodriguez @ 2010-07-27 20:33 UTC (permalink / raw)
To: linville, johannes; +Cc: linux-wireless, Luis R. Rodriguez, Johannes Berg
In-Reply-To: <1280262788-9890-1-git-send-email-lrodriguez@atheros.com>
This reverts this commit. While in theory the change is
correct the patch does not address current assumptions made
by some drivers, one which is definitley affected is ath9k.
Prior to this change the scan complete callback would be
called after we returned to the home channel and configured
the hardware RX filters. After this change we call the scan
complete callback prior to both the hw config and the config
filter. At least for ath9k this breaks quite a few assumptions
on the callback, leading to disconnects to the AP after every scan
making the driver pretty useless on STA mode. The goal behind
this commit was to address the now understood spurious warnings
from ath9k and mac80211_hwsim on scanning on two wiphys at the
same time but we have now supressed these and will address this
issue in the next kernel release.
When fixing this for good next we must first review the other
driver's dependence on this logic and perhaps consider removal
of the scan complete callback all together.
Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
net/mac80211/scan.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index 4dcbf8b..9aa19ec 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -287,8 +287,6 @@ void ieee80211_scan_completed(struct ieee80211_hw *hw, bool aborted)
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);
@@ -298,6 +296,8 @@ void ieee80211_scan_completed(struct ieee80211_hw *hw, bool aborted)
ieee80211_configure_filter(local);
+ drv_sw_scan_complete(local);
+
ieee80211_offchannel_return(local, true);
done:
--
1.7.0.4
^ permalink raw reply related
* [PATCH 0/3] Revert of mac80211 scan complete callback move
From: Luis R. Rodriguez @ 2010-07-27 20:33 UTC (permalink / raw)
To: linville, johannes; +Cc: linux-wireless, Luis R. Rodriguez
The two virtual wiphy messages seen on both ath9k and mac80211_hwsim was
debugged by Johannes and fixed but required a little more work on the
drivers end. So for now revert that fix and supress the messages.
We can address this for the next kernel release.
Luis R. Rodriguez (3):
ath9k: remove the two wiphys scanning at the same time message
mac80211_hwsim: supress scan conflict message
Revert "mac80211: fix sw scan bracketing"
drivers/net/wireless/ath/ath9k/main.c | 13 +++++++++----
drivers/net/wireless/mac80211_hwsim.c | 4 +---
net/mac80211/scan.c | 4 ++--
3 files changed, 12 insertions(+), 9 deletions(-)
^ permalink raw reply
* Re: [PATCH] Revert "mac80211: fix sw scan bracketing"
From: Luis R. Rodriguez @ 2010-07-27 20:15 UTC (permalink / raw)
To: linville, johannes; +Cc: linux-wireless, Luis R. Rodriguez, Johannes Berg
In-Reply-To: <1280257471-9126-1-git-send-email-lrodriguez@atheros.com>
On Tue, Jul 27, 2010 at 12:04 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> The spurious warnings
> will come up still but since they are wrapped under KERN_DEBUG
> and this will be addressed in the next kernel release we leave
> then in place.
Johannes wants these to go away so I'll resend in a new series
removing these first.
Luis
^ permalink raw reply
* Re: [PATCH] mac80211: fix sw scan bracketing
From: Johannes Berg @ 2010-07-27 20:09 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: John Linville, linux-wireless
In-Reply-To: <AANLkTikFjgzL1DOfUVS_N_=p5N3r0Qp7VoC5+-9cbb1a@mail.gmail.com>
On Tue, 2010-07-27 at 10:29 -0700, Luis R. Rodriguez wrote:
> I just reviewed this and noticed both of these prints are using
> KERN_DEBUG, and since the warning will become valid *after* this gets
> properly fixed, are you OK with just a revert of your patch?
I've seen this show up in bug reports, and we _know_ that there's a
problem since I fixed it, so no, I really do want the message to go
away.
johannes
^ permalink raw reply
* Re: CARL9170
From: Ignacy Gawedzki @ 2010-07-27 19:25 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linux-wireless
In-Reply-To: <4C169610.5020907@dlasys.net>
Hi David,
I happen to be trying to achieve something very similar to what you are aiming
at. I need to measure each TX frame's "service time", i.e. the interval of
time between the instant this frame is considered for transmission and the
instant the corresponding ACK is received or the transmission is given up (too
many failed transmission attempts). Then I need this value to be returned to
the kernel with the TX status, for further processing.
Until now, I oversimplistically was doing that measurement upstream, in the
kernel driver, taking a timestamp between the instant a frame is shipped
through the USB framework and the instant the TX completion interrupt is
received. This approach worked well only when sending sustained traffic
(back-to-back frames), since the TX completion time of the previous frame was
then used as the starting instant of the current frame. When frames were sent
one-by-one, the measured interval was way too large (as a matter of fact, it
was a lot smaller, while still too large, when I used the ar9170
firmware+driver), so as to become unusable. Since I discovered the carl9170
firmware+driver, I'm seriously thinking about implementing that measurement
inside the firmware for much higher accuracy.
I read with great interest the threads you started and wanted to ask whether
you managed to advance in your quest. In the meantime, I continue to read
carl9170 firmware code thoroughly to get a feeling of how things are going on
in it.
Ignacy
--
Information wants to be beer, or something like that.
^ 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