* Re: [PATCH 2.6.31] iwlwifi: Reenable power_level
From: Andrew Lutomirski @ 2009-09-02 16:41 UTC (permalink / raw)
To: reinette chatre; +Cc: linux-wireless@vger.kernel.org, Zhu, Yi
In-Reply-To: <1251906970.13180.137.camel@rc-desk>
On Wed, Sep 2, 2009 at 11:56 AM, reinette
chatre<reinette.chatre@intel.com> wrote:
> Hi Andy,
>
> On Wed, 2009-09-02 at 07:53 -0700, Andrew Lutomirski wrote:
>> Right now, enabling power saving on iwlwifi is impossible, because
>> mac80211 won't tell iwlwifi that power saving is on (since
>> IEEE80211_HW_SUPPORTS_PS is not set) and iwlwifi will ignore the
>> user's power_level setting until mac80211 asks for power saving.
>> Setting this flag allows the user to manually enable power saving if
>> desired.
>>
>> Signed-off-by: Andy Lutomirski <luto@mit.edu>
>>
>> ---
>
> nack.
>
> http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2053 and
> http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2051 are two
> examples of what happens if power save support is enabled. In addition
> to this we are also seeing issues with 4965 that are described in the
> commit that disabled powersave in 2.6.31 in the first place
> (286d94906587901851906a5e2ddc09bc1a7ba1d9).
>
Fair enough. Would you accept a patch to remove power_level from sysfs instead?
>
>> This fixes what looks to me like a regression: power_level used to
>> work but now fails silently. In 2.6.32 I think this code is going
>> away, but this patch seems like a safe stopgap measure.
>
> 2.6.32 will have power save support disabled also.
Any ETA for getting this fixed for real? I like my battery life :)
--Andy
^ permalink raw reply
* Re: [PATCH 2.6.31] iwlwifi: Reenable power_level
From: Johannes Berg @ 2009-09-02 16:48 UTC (permalink / raw)
To: reinette chatre
Cc: Andrew Lutomirski, linux-wireless@vger.kernel.org, Zhu, Yi
In-Reply-To: <1251906970.13180.137.camel@rc-desk>
[-- Attachment #1: Type: text/plain, Size: 285 bytes --]
On Wed, 2009-09-02 at 08:56 -0700, reinette chatre wrote:
> 2.6.32 will have power save support disabled also.
Only by default -- there you can actually enable it as a user with
"iwconfig wlan0 power timeout 100ms" to turn it on -- unless that patch
didn't go in?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 2.6.31] iwlwifi: Reenable power_level
From: reinette chatre @ 2009-09-02 16:54 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: linux-wireless@vger.kernel.org, Zhu, Yi
In-Reply-To: <cb0375e10909020941qa54215cqb6af7ac01e87ccb3@mail.gmail.com>
Hi Andrew,
On Wed, 2009-09-02 at 09:41 -0700, Andrew Lutomirski wrote:
> Fair enough. Would you accept a patch to remove power_level from sysfs instead?
No. This file is used when users want to manually reduce the power used
by device. This is the file you want to change if you want to extend
your battery life.
> >> This fixes what looks to me like a regression: power_level used to
> >> work but now fails silently. In 2.6.32 I think this code is going
> >> away, but this patch seems like a safe stopgap measure.
> >
> > 2.6.32 will have power save support disabled also.
>
> Any ETA for getting this fixed for real? I like my battery life :)
We are working on it.
Reinette
^ permalink raw reply
* Re: [PATCH 2.6.31] iwlwifi: Reenable power_level
From: reinette chatre @ 2009-09-02 16:57 UTC (permalink / raw)
To: Johannes Berg; +Cc: Andrew Lutomirski, linux-wireless@vger.kernel.org, Zhu, Yi
In-Reply-To: <1251910084.24846.29.camel@johannes.local>
On Wed, 2009-09-02 at 09:48 -0700, Johannes Berg wrote:
> On Wed, 2009-09-02 at 08:56 -0700, reinette chatre wrote:
>
> > 2.6.32 will have power save support disabled also.
>
> Only by default -- there you can actually enable it as a user with
> "iwconfig wlan0 power timeout 100ms" to turn it on -- unless that patch
> didn't go in?
yes - sorry, I should have added that it is disabled by default but
users can enable it using iwconfig.
Reinette
^ permalink raw reply
* Re: [PATCH 2.6.31] iwlwifi: Reenable power_level
From: Johannes Berg @ 2009-09-02 17:03 UTC (permalink / raw)
To: reinette chatre
Cc: Andrew Lutomirski, linux-wireless@vger.kernel.org, Zhu, Yi
In-Reply-To: <1251910457.13180.160.camel@rc-desk>
[-- Attachment #1: Type: text/plain, Size: 559 bytes --]
On Wed, 2009-09-02 at 09:54 -0700, reinette chatre wrote:
> Hi Andrew,
>
> On Wed, 2009-09-02 at 09:41 -0700, Andrew Lutomirski wrote:
>
> > Fair enough. Would you accept a patch to remove power_level from sysfs instead?
>
> No. This file is used when users want to manually reduce the power used
> by device. This is the file you want to change if you want to extend
> your battery life.
Actually, we have already removed that file for 2.6.32 I think? So it
may be fair to remove it for .31 since there you can't use it anyway.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: compat-wireless and DKMS
From: Jeremy Wolcott @ 2009-09-02 17:11 UTC (permalink / raw)
To: tim.gardner; +Cc: linux-wireless
In-Reply-To: <4A9E9AEE.4060409@canonical.com>
Oh, cool. Is that in the Jaunty repositories? The latest kernel
release I'm seeing (with -proposed and -backports enabled) is 2.6.28-15...
Thanks,
-Jeremy
Tim Gardner wrote:
> Jeremy Wolcott wrote:
>> Has anybody tried to get compat-wireless working with DKMS? This
>> would be really handy for me since I run Ubuntu and they have been
>> pushing kernel updates pretty frequently lately, but I need the newest
>> compat-wireless to run my Atheros card in master mode via ath5k...
>>
>> I tried for quite a while today and the build just won't work. (The
>> 'make clean' step returns error 2, and then the build itself fails
>> with "(directory it's building in) is a directory. Stop.") I think
>> it's because the Makefile for compat-wireless uses the PWD environment
>> variable, but I'm not well-versed enough in Makefiles to fix it up so
>> that it'll work from a different directory (DKMS builds modules in
>> /var/lib/dkms/MODULE_NAME/VERSION/build instead of wherever I unpacked
>> the source).
>>
>> Any advice would be appreciated...
>>
>> Thanks,
>>
>> -Jeremy
>> --
>> 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
>
> I've been packaging compat-wireless in linux-backports-modules-2.6.31 on
> a semi-spasmodic basis. Current version contains wireless-testing
> master-2009-09-01.
>
> rtg
^ permalink raw reply
* Re: [PATCH 2.6.31] iwlwifi: Reenable power_level
From: reinette chatre @ 2009-09-02 17:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: Andrew Lutomirski, linux-wireless@vger.kernel.org, Zhu, Yi
In-Reply-To: <1251911029.2999.0.camel@johannes.local>
Hi Johannes,
On Wed, 2009-09-02 at 10:03 -0700, Johannes Berg wrote:
> On Wed, 2009-09-02 at 09:54 -0700, reinette chatre wrote:
> > On Wed, 2009-09-02 at 09:41 -0700, Andrew Lutomirski wrote:
> > > Fair enough. Would you accept a patch to remove power_level from sysfs instead?
> > No. This file is used when users want to manually reduce the power used
> > by device. This is the file you want to change if you want to extend
> > your battery life.
> Actually, we have already removed that file for 2.6.32 I think?
The file itself was removed, but from what I understand the same
functionality can now be obtained from sleep_level_override. Users who
previously used power_level can thus now use sleep_level_override, but
with sleep_level_override not existing in 2.6.31 they will have no
alternative if we remove power_level.
> So it
> may be fair to remove it for .31 since there you can't use it anyway.
You can still use it to manually set power index used by device to
reduce power usage.
Reinette
^ permalink raw reply
* Re: [PATCH 2.6.31] iwlwifi: Reenable power_level
From: Johannes Berg @ 2009-09-02 17:30 UTC (permalink / raw)
To: reinette chatre
Cc: Andrew Lutomirski, linux-wireless@vger.kernel.org, Zhu, Yi
In-Reply-To: <1251911825.13180.173.camel@rc-desk>
[-- Attachment #1: Type: text/plain, Size: 633 bytes --]
Hi Reinette,
> The file itself was removed, but from what I understand the same
> functionality can now be obtained from sleep_level_override.
Indeed.
> Users who
> previously used power_level can thus now use sleep_level_override, but
> with sleep_level_override not existing in 2.6.31 they will have no
> alternative if we remove power_level.
>
> > So it
> > may be fair to remove it for .31 since there you can't use it anyway.
>
> You can still use it to manually set power index used by device to
> reduce power usage.
I was under the impression that Andrew said this actually didn't work.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 2.6.31] iwlwifi: Reenable power_level
From: Andrew Lutomirski @ 2009-09-02 17:38 UTC (permalink / raw)
To: Johannes Berg; +Cc: reinette chatre, linux-wireless@vger.kernel.org, Zhu, Yi
In-Reply-To: <1251912629.2999.1.camel@johannes.local>
On Wed, Sep 2, 2009 at 1:30 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> Hi Reinette,
>
>> The file itself was removed, but from what I understand the same
>> functionality can now be obtained from sleep_level_override.
>
> Indeed.
>
>> Users who
>> previously used power_level can thus now use sleep_level_override, but
>> with sleep_level_override not existing in 2.6.31 they will have no
>> alternative if we remove power_level.
>>
>> > So it
>> > may be fair to remove it for .31 since there you can't use it anyway.
>>
>> You can still use it to manually set power index used by device to
>> reduce power usage.
>
> I was under the impression that Andrew said this actually didn't work.
Exactly. My patch fixes that, although there might be a better way to do that.
--Andy
>
> johannes
>
^ permalink raw reply
* Re: ipw2200: firmware DMA loading rework
From: Bartlomiej Zolnierkiewicz @ 2009-09-02 17:48 UTC (permalink / raw)
To: Zhu Yi
Cc: Andrew Morton, Mel Gorman, Johannes Weiner, Pekka Enberg,
Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Mel Gorman, netdev@vger.kernel.org, linux-mm@kvack.org,
James Ketrenos, Chatre, Reinette, linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <200908301437.42133.bzolnier@gmail.com>
On Sunday 30 August 2009 14:37:42 Bartlomiej Zolnierkiewicz wrote:
> On Friday 28 August 2009 05:42:31 Zhu Yi wrote:
> > Bartlomiej Zolnierkiewicz reported an atomic order-6 allocation failure
> > for ipw2200 firmware loading in kernel 2.6.30. High order allocation is
>
> s/2.6.30/2.6.31-rc6/
>
> The issue has always been there but it was some recent change that
> explicitly triggered the allocation failures (after 2.6.31-rc1).
ipw2200 fix works fine but yesterday I got the following error while mounting
ext4 filesystem (mb_history is optional so the mount succeeded):
EXT4-fs (dm-2): barriers enabled
kjournald2 starting: pid 3137, dev dm-2:8, commit interval 5 seconds
EXT4-fs (dm-2): internal journal on dm-2:8
EXT4-fs (dm-2): delayed allocation enabled
EXT4-fs: file extents enabled
mount: page allocation failure. order:5, mode:0xc0d0
Pid: 3136, comm: mount Not tainted 2.6.31-rc8-00015-gadda766-dirty #78
Call Trace:
[<c0394de3>] ? printk+0xf/0x14
[<c016a693>] __alloc_pages_nodemask+0x400/0x442
[<c016a71b>] __get_free_pages+0xf/0x32
[<c01865cf>] __kmalloc+0x28/0xfa
[<c023d96f>] ? __spin_lock_init+0x28/0x4d
[<c01f529d>] ext4_mb_init+0x392/0x460
[<c01e99d2>] ext4_fill_super+0x1b96/0x2012
[<c0239bc8>] ? snprintf+0x15/0x17
[<c01c0b26>] ? disk_name+0x24/0x69
[<c018ba63>] get_sb_bdev+0xda/0x117
[<c01e6711>] ext4_get_sb+0x13/0x15
[<c01e7e3c>] ? ext4_fill_super+0x0/0x2012
[<c018ad2d>] vfs_kern_mount+0x3b/0x76
[<c018adad>] do_kern_mount+0x33/0xbd
[<c019d0af>] do_mount+0x660/0x6b8
[<c016a71b>] ? __get_free_pages+0xf/0x32
[<c019d168>] sys_mount+0x61/0x99
[<c0102908>] sysenter_do_call+0x12/0x36
Mem-Info:
DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
Normal per-cpu:
CPU 0: hi: 186, btch: 31 usd: 0
Active_anon:25471 active_file:22802 inactive_anon:25812
inactive_file:33619 unevictable:2 dirty:2452 writeback:135 unstable:0
free:4346 slab:4308 mapped:26038 pagetables:912 bounce:0
DMA free:2060kB min:84kB low:104kB high:124kB active_anon:1660kB inactive_anon:1848kB active_file:144kB inactive_file:868kB unevictable:0kB present:15788kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 489 489
Normal free:15324kB min:2788kB low:3484kB high:4180kB active_anon:100224kB inactive_anon:101400kB active_file:91064kB inactive_file:133608kB unevictable:8kB present:501392kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 1*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2060kB
Normal: 1283*4kB 648*8kB 159*16kB 53*32kB 10*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 15324kB
57947 total pagecache pages
878 pages in swap cache
Swap cache stats: add 920, delete 42, find 11/11
Free swap = 1016436kB
Total swap = 1020116kB
131056 pages RAM
4233 pages reserved
90573 pages shared
77286 pages non-shared
EXT4-fs: mballoc enabled
EXT4-fs (dm-2): mounted filesystem with ordered data mode
Thus it seems like the original bug is still there and any ideas how to
debug the problem further are appreciated..
The complete dmesg and kernel config are here:
http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.dmesg
http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.config
^ permalink raw reply
* Re: ipw2200: firmware DMA loading rework
From: Luis R. Rodriguez @ 2009-09-02 18:02 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz, Tso Ted, Aneesh Kumar K.V
Cc: Zhu Yi, Andrew Morton, Mel Gorman, Johannes Weiner, Pekka Enberg,
Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Mel Gorman, netdev@vger.kernel.org, linux-mm@kvack.org,
James Ketrenos, Chatre, Reinette, linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <200909021948.13262.bzolnier@gmail.com>
On Wed, Sep 2, 2009 at 10:48 AM, Bartlomiej
Zolnierkiewicz<bzolnier@gmail.com> wrote:
> On Sunday 30 August 2009 14:37:42 Bartlomiej Zolnierkiewicz wrote:
>> On Friday 28 August 2009 05:42:31 Zhu Yi wrote:
>> > Bartlomiej Zolnierkiewicz reported an atomic order-6 allocation failure
>> > for ipw2200 firmware loading in kernel 2.6.30. High order allocation is
>>
>> s/2.6.30/2.6.31-rc6/
>>
>> The issue has always been there but it was some recent change that
>> explicitly triggered the allocation failures (after 2.6.31-rc1).
>
> ipw2200 fix works fine but yesterday I got the following error while mounting
> ext4 filesystem (mb_history is optional so the mount succeeded):
OK so the mount succeeded.
> EXT4-fs (dm-2): barriers enabled
> kjournald2 starting: pid 3137, dev dm-2:8, commit interval 5 seconds
> EXT4-fs (dm-2): internal journal on dm-2:8
> EXT4-fs (dm-2): delayed allocation enabled
> EXT4-fs: file extents enabled
> mount: page allocation failure. order:5, mode:0xc0d0
> Pid: 3136, comm: mount Not tainted 2.6.31-rc8-00015-gadda766-dirty #78
> Call Trace:
> [<c0394de3>] ? printk+0xf/0x14
> [<c016a693>] __alloc_pages_nodemask+0x400/0x442
> [<c016a71b>] __get_free_pages+0xf/0x32
> [<c01865cf>] __kmalloc+0x28/0xfa
> [<c023d96f>] ? __spin_lock_init+0x28/0x4d
> [<c01f529d>] ext4_mb_init+0x392/0x460
> [<c01e99d2>] ext4_fill_super+0x1b96/0x2012
> [<c0239bc8>] ? snprintf+0x15/0x17
> [<c01c0b26>] ? disk_name+0x24/0x69
> [<c018ba63>] get_sb_bdev+0xda/0x117
> [<c01e6711>] ext4_get_sb+0x13/0x15
> [<c01e7e3c>] ? ext4_fill_super+0x0/0x2012
> [<c018ad2d>] vfs_kern_mount+0x3b/0x76
> [<c018adad>] do_kern_mount+0x33/0xbd
> [<c019d0af>] do_mount+0x660/0x6b8
> [<c016a71b>] ? __get_free_pages+0xf/0x32
> [<c019d168>] sys_mount+0x61/0x99
> [<c0102908>] sysenter_do_call+0x12/0x36
> Mem-Info:
> DMA per-cpu:
> CPU 0: hi: 0, btch: 1 usd: 0
> Normal per-cpu:
> CPU 0: hi: 186, btch: 31 usd: 0
> Active_anon:25471 active_file:22802 inactive_anon:25812
> inactive_file:33619 unevictable:2 dirty:2452 writeback:135 unstable:0
> free:4346 slab:4308 mapped:26038 pagetables:912 bounce:0
> DMA free:2060kB min:84kB low:104kB high:124kB active_anon:1660kB inactive_anon:1848kB active_file:144kB inactive_file:868kB unevictable:0kB present:15788kB pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 489 489
> Normal free:15324kB min:2788kB low:3484kB high:4180kB active_anon:100224kB inactive_anon:101400kB active_file:91064kB inactive_file:133608kB unevictable:8kB present:501392kB pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 0 0
> DMA: 1*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2060kB
> Normal: 1283*4kB 648*8kB 159*16kB 53*32kB 10*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 15324kB
> 57947 total pagecache pages
> 878 pages in swap cache
> Swap cache stats: add 920, delete 42, find 11/11
> Free swap = 1016436kB
> Total swap = 1020116kB
> 131056 pages RAM
> 4233 pages reserved
> 90573 pages shared
> 77286 pages non-shared
> EXT4-fs: mballoc enabled
> EXT4-fs (dm-2): mounted filesystem with ordered data mode
>
> Thus it seems like the original bug is still there and any ideas how to
> debug the problem further are appreciated..
>
> The complete dmesg and kernel config are here:
>
> http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.dmesg
> http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.config
This looks very similar to the kmemleak ext4 reports upon a mount. If
it is the same issue, which from the trace it seems it is, then this
is due to an extra kmalloc() allocation and this apparently will not
get fixed on 2.6.31 due to the closeness of the merge window and the
non-criticalness this issue has been deemed.
A patch fix is part of the ext4-patchqueue
http://repo.or.cz/w/ext4-patch-queue.git
Luis
^ permalink raw reply
* Re: [PATCH 2.6.31] iwlwifi: Reenable power_level
From: reinette chatre @ 2009-09-02 18:23 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: Johannes Berg, linux-wireless@vger.kernel.org, Zhu, Yi
In-Reply-To: <cb0375e10909021038k32a576f1hd519e8dcdff9ef3d@mail.gmail.com>
On Wed, 2009-09-02 at 10:38 -0700, Andrew Lutomirski wrote:
> On Wed, Sep 2, 2009 at 1:30 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> >
> > I was under the impression that Andrew said this actually didn't work.
>
> Exactly. My patch fixes that, although there might be a better way to do that.
Seems to be in iwl_power_update_mode() the mode is forced to CAM if
power save disabled, and power save is set to disabled if mac considers
it disabled (see setting of power_disabled in iwl_mac_config()).
One way around this is to always allow user to set power mode, even if
it is disabled from mac perspective. Since the power mode is updated in
many more spots (not always triggered by user) I do not know the full
implications of this change. Considering the unknown of this change and
the problems we have encountered when enabling power save I would rather
not merge such a patch without significant testing. I think it is too
late for 2.6.31.
The same problem should not exist in 2.6.32.
Reinette
^ permalink raw reply
* Re: ipw2200: firmware DMA loading rework
From: Bartlomiej Zolnierkiewicz @ 2009-09-02 18:26 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Tso Ted, Aneesh Kumar K.V, Zhu Yi, Andrew Morton, Mel Gorman,
Johannes Weiner, Pekka Enberg, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Mel Gorman,
netdev@vger.kernel.org, linux-mm@kvack.org, James Ketrenos,
Chatre, Reinette, linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <43e72e890909021102g7f844c79xefccf305f5f5c5b6@mail.gmail.com>
On Wednesday 02 September 2009 20:02:14 Luis R. Rodriguez wrote:
> On Wed, Sep 2, 2009 at 10:48 AM, Bartlomiej
> Zolnierkiewicz<bzolnier@gmail.com> wrote:
> > On Sunday 30 August 2009 14:37:42 Bartlomiej Zolnierkiewicz wrote:
> >> On Friday 28 August 2009 05:42:31 Zhu Yi wrote:
> >> > Bartlomiej Zolnierkiewicz reported an atomic order-6 allocation failure
> >> > for ipw2200 firmware loading in kernel 2.6.30. High order allocation is
> >>
> >> s/2.6.30/2.6.31-rc6/
> >>
> >> The issue has always been there but it was some recent change that
> >> explicitly triggered the allocation failures (after 2.6.31-rc1).
> >
> > ipw2200 fix works fine but yesterday I got the following error while mounting
> > ext4 filesystem (mb_history is optional so the mount succeeded):
>
> OK so the mount succeeded.
>
> > EXT4-fs (dm-2): barriers enabled
> > kjournald2 starting: pid 3137, dev dm-2:8, commit interval 5 seconds
> > EXT4-fs (dm-2): internal journal on dm-2:8
> > EXT4-fs (dm-2): delayed allocation enabled
> > EXT4-fs: file extents enabled
> > mount: page allocation failure. order:5, mode:0xc0d0
> > Pid: 3136, comm: mount Not tainted 2.6.31-rc8-00015-gadda766-dirty #78
> > Call Trace:
> > [<c0394de3>] ? printk+0xf/0x14
> > [<c016a693>] __alloc_pages_nodemask+0x400/0x442
> > [<c016a71b>] __get_free_pages+0xf/0x32
> > [<c01865cf>] __kmalloc+0x28/0xfa
> > [<c023d96f>] ? __spin_lock_init+0x28/0x4d
> > [<c01f529d>] ext4_mb_init+0x392/0x460
> > [<c01e99d2>] ext4_fill_super+0x1b96/0x2012
> > [<c0239bc8>] ? snprintf+0x15/0x17
> > [<c01c0b26>] ? disk_name+0x24/0x69
> > [<c018ba63>] get_sb_bdev+0xda/0x117
> > [<c01e6711>] ext4_get_sb+0x13/0x15
> > [<c01e7e3c>] ? ext4_fill_super+0x0/0x2012
> > [<c018ad2d>] vfs_kern_mount+0x3b/0x76
> > [<c018adad>] do_kern_mount+0x33/0xbd
> > [<c019d0af>] do_mount+0x660/0x6b8
> > [<c016a71b>] ? __get_free_pages+0xf/0x32
> > [<c019d168>] sys_mount+0x61/0x99
> > [<c0102908>] sysenter_do_call+0x12/0x36
> > Mem-Info:
> > DMA per-cpu:
> > CPU 0: hi: 0, btch: 1 usd: 0
> > Normal per-cpu:
> > CPU 0: hi: 186, btch: 31 usd: 0
> > Active_anon:25471 active_file:22802 inactive_anon:25812
> > inactive_file:33619 unevictable:2 dirty:2452 writeback:135 unstable:0
> > free:4346 slab:4308 mapped:26038 pagetables:912 bounce:0
> > DMA free:2060kB min:84kB low:104kB high:124kB active_anon:1660kB inactive_anon:1848kB active_file:144kB inactive_file:868kB unevictable:0kB present:15788kB pages_scanned:0 all_unreclaimable? no
> > lowmem_reserve[]: 0 489 489
> > Normal free:15324kB min:2788kB low:3484kB high:4180kB active_anon:100224kB inactive_anon:101400kB active_file:91064kB inactive_file:133608kB unevictable:8kB present:501392kB pages_scanned:0 all_unreclaimable? no
> > lowmem_reserve[]: 0 0 0
> > DMA: 1*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2060kB
> > Normal: 1283*4kB 648*8kB 159*16kB 53*32kB 10*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 15324kB
> > 57947 total pagecache pages
> > 878 pages in swap cache
> > Swap cache stats: add 920, delete 42, find 11/11
> > Free swap = 1016436kB
> > Total swap = 1020116kB
> > 131056 pages RAM
> > 4233 pages reserved
> > 90573 pages shared
> > 77286 pages non-shared
> > EXT4-fs: mballoc enabled
> > EXT4-fs (dm-2): mounted filesystem with ordered data mode
> >
> > Thus it seems like the original bug is still there and any ideas how to
> > debug the problem further are appreciated..
> >
> > The complete dmesg and kernel config are here:
> >
> > http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.dmesg
> > http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.config
>
> This looks very similar to the kmemleak ext4 reports upon a mount. If
> it is the same issue, which from the trace it seems it is, then this
> is due to an extra kmalloc() allocation and this apparently will not
> get fixed on 2.6.31 due to the closeness of the merge window and the
> non-criticalness this issue has been deemed.
>
> A patch fix is part of the ext4-patchqueue
> http://repo.or.cz/w/ext4-patch-queue.git
Thanks for the pointer but the page allocation failures that I hit seem
to be caused by the memory management itself and the ext4 issue fixed by:
http://repo.or.cz/w/ext4-patch-queue.git?a=blob;f=memory-leak-fix-ext4_group_info-allocation;h=c919fff34e70ec85f96d1833f9ce460c451000de;hb=HEAD
is a different problem (unrelated to this one).
^ permalink raw reply
* Reproducing sme __cfg80211_disconnected warning
From: Luis R. Rodriguez @ 2009-09-02 18:45 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, ic.felix
I can now reproduce this, at least once, will try in a bit again, but
here is the recipe:
* Connected to work AP with WPA2 with Network manager
* Issued sudo iw dev wlan0 connect home-ap-ssid
* sudo pm-suspend
* NM will show trace once you come up
[ 195.961614] wlan0: deauthenticating by local choice (reason=3)
[ 195.961940] phy0: device now idle
[ 196.083964] phy0: Removed STA <my-work-ap-mac>
[ 196.102260] phy0: Destroyed STA <my-work-ap-mac>
[ 196.102504] wlan0: deauthenticating by local choice (reason=3)
[ 196.102516] ------------[ cut here ]------------
[ 196.102550] WARNING: at net/wireless/sme.c:617
__cfg80211_disconnected+0x209/0x260 [cfg80211]()
[ 196.102557] Hardware name: 7660A14
[ 196.102563] deauth failed: -67
[ 196.102567] Modules linked in: <bleh>
[ 196.102713] Pid: 3340, comm: wpa_supplicant Not tainted 2.6.31-rc8-wl #4
[ 196.102720] Call Trace:
[ 196.102737] [<ffffffff81058588>] warn_slowpath_common+0x78/0xb0
[ 196.102746] [<ffffffff8105861c>] warn_slowpath_fmt+0x3c/0x40
[ 196.102774] [<ffffffffa017e3f9>]
__cfg80211_disconnected+0x209/0x260 [cfg80211]
[ 196.102802] [<ffffffffa017c0d8>]
__cfg80211_send_deauth+0x228/0x2a0 [cfg80211]
[ 196.102829] [<ffffffffa017c191>] cfg80211_send_deauth+0x41/0x80 [cfg80211]
[ 196.102864] [<ffffffffa020bc1f>]
ieee80211_send_deauth_disassoc+0x14f/0x170 [mac80211]
[ 196.102898] [<ffffffffa020d318>] ieee80211_mgd_deauth+0xe8/0x110 [mac80211]
[ 196.102931] [<ffffffffa0212fb9>] ieee80211_deauth+0x19/0x20 [mac80211]
[ 196.102960] [<ffffffffa017aade>] __cfg80211_mlme_deauth+0xee/0x130
[cfg80211]
[ 196.102986] [<ffffffffa018218e>] ?
cfg80211_mgd_wext_siwfreq+0x9e/0x1b8 [cfg80211]
[ 196.103013] [<ffffffffa017e969>] __cfg80211_disconnect+0x159/0x1d0
[cfg80211]
[ 196.103038] [<ffffffffa01821c5>]
cfg80211_mgd_wext_siwfreq+0xd5/0x1b8 [cfg80211]
[ 196.103052] [<ffffffff81507920>] ? ioctl_standard_call+0x0/0xd0
[ 196.103077] [<ffffffffa018068d>] cfg80211_wext_siwfreq+0x4d/0xd0 [cfg80211]
[ 196.103088] [<ffffffff8150797b>] ioctl_standard_call+0x5b/0xd0
[ 196.103099] [<ffffffff81452320>] ? __dev_get_by_name+0xa0/0xc0
[ 196.103109] [<ffffffff815070c5>] wext_ioctl_dispatch+0x165/0x1d0
[ 196.103118] [<ffffffff81507510>] ? ioctl_private_call+0x0/0xa0
[ 196.103128] [<ffffffff81507261>] wext_handle_ioctl+0x41/0x90
[ 196.103137] [<ffffffff814535f6>] dev_ioctl+0x676/0x820
[ 196.103148] [<ffffffff81087c90>] ? __lock_acquire+0x270/0x1120
[ 196.103160] [<ffffffff8143dd55>] sock_ioctl+0x95/0x280
[ 196.103171] [<ffffffff8113349d>] vfs_ioctl+0x1d/0xa0
[ 196.103181] [<ffffffff8113363a>] do_vfs_ioctl+0x8a/0x5a0
[ 196.103191] [<ffffffff81526cbb>] ? thread_return+0x4e/0x733
[ 196.103203] [<ffffffff81011f3a>] ? sysret_check+0x2e/0x69
[ 196.103213] [<ffffffff81133bd1>] sys_ioctl+0x81/0xa0
[ 196.103222] [<ffffffff81011f02>] system_call_fastpath+0x16/0x1b
[ 196.103230] ---[ end trace 219bc7170d2a18cd ]---
[ 196.148637] phy0: device no longer idle - in use
^ permalink raw reply
* pull request: wireless-next-2.6 2009-09-02
From: John W. Linville @ 2009-09-02 19:56 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
Dave,
Once again, the usual batch of wireless updates for -next... This time
its mostly a random collection of driver updates...
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6/
---
The following changes since commit 9e39f7c5b311a306977c5471f9e2ce4c456aa038:
Joe Perches (1):
s2io: Generate complete messages using single line DBG_PRINTs
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Bob Copeland (1):
cfg80211: fix looping soft lockup in find_ie()
Daniel C Halperin (3):
iwlwifi: remove 60 Mbps from sband bitrates table
iwlwifi: remove incorrect uses of ieee80211_get_tx_rate to prevent TX stall
iwlwifi: use iwl_hwrate_get_mac80211_idx where appropriate
Gábor Stefanik (4):
b43: Refactor and update antenna diversity for A/G-PHY
b43: Add myself to module authors & to LP-PHY file copyright notices
b43: Fix typo in modparam_btcoex description
b43: LP-PHY: Fix TX gain tables
Ivo van Doorn (2):
rt2x00: Fix TX status reporting
rt2x00: Reorganize padding & L2 padding
Johannes Berg (2):
iwlwifi: use sleep interval succession
rfkill: relicense header file
Jussi Kivilinna (4):
rndis_wlan: use bool for on/off switches
rndis_wlan: cleanup
rndis_wlan: fix sparse endianess warnings
rndis_wlan: remove 'select WIRELESS_EXT' in Kconfig
Luis R. Rodriguez (3):
wireless: update top level wireless driver entry
wireless: update reg debug kconfig entry
wireless: remove mac80211 rate selection extra menu
Randy Dunlap (1):
ipw2200: fix kconfig dependencies
Reinette Chatre (2):
iwlwifi: fix situation in which debug message is printed
iwl3945: reduce debug noise when default debug flags used
Samuel Ortiz (5):
iwmc3200wifi: Set WEP key from connect
iwmc3200wifi: Fix sparse warning
iwmc3200wifi: New initial LMAC calibration
iwmc3200wifi: Handle UMAC stalls and UMAC assert properly
iwmc3200wifi: Add a last_fw_err debugfs entry
Vasanthakumar Thiagarajan (3):
ath9k: Do an AHB reset before doing RTC reset
ath9k: Move generic hw timer intr handler to bottom-half
ath9k: Call spin_lock_bh() on btcoex_lock
Vivek Natarajan (1):
ath9k: Reconfigure beacon timers after the scan is completed.
Zhu Yi (4):
iwmc3200wifi: invalidate profile when necessary before connect
iwmc3200wifi: use cfg80211_roamed to send roam event
iwmc3200wifi: add disconnect work
iwmc3200wifi: fix misuse of le16_to_cpu
drivers/net/wireless/Kconfig | 14 +-
drivers/net/wireless/ath/ath9k/btcoex.c | 10 +-
drivers/net/wireless/ath/ath9k/hw.c | 7 +
drivers/net/wireless/ath/ath9k/main.c | 12 +-
drivers/net/wireless/b43/main.c | 3 +-
drivers/net/wireless/b43/phy_a.c | 48 ++---
drivers/net/wireless/b43/phy_g.c | 53 ++---
drivers/net/wireless/b43/phy_lp.c | 3 +-
drivers/net/wireless/b43/tables_lpphy.c | 309 +++++++++++++-------------
drivers/net/wireless/ipw2x00/Kconfig | 6 +-
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 56 +++---
drivers/net/wireless/iwlwifi/iwl-agn-rs.h | 1 +
drivers/net/wireless/iwlwifi/iwl-core.c | 39 +++-
drivers/net/wireless/iwlwifi/iwl-core.h | 1 +
drivers/net/wireless/iwlwifi/iwl-power.c | 24 ++-
drivers/net/wireless/iwlwifi/iwl-rx.c | 9 +-
drivers/net/wireless/iwlwifi/iwl-tx.c | 111 +++++----
drivers/net/wireless/iwlwifi/iwl3945-base.c | 8 +-
drivers/net/wireless/iwmc3200wifi/cfg80211.c | 66 +++++-
drivers/net/wireless/iwmc3200wifi/commands.c | 1 +
drivers/net/wireless/iwmc3200wifi/debug.h | 2 +
drivers/net/wireless/iwmc3200wifi/debugfs.c | 105 +++++++++-
drivers/net/wireless/iwmc3200wifi/fw.c | 56 ++++--
drivers/net/wireless/iwmc3200wifi/iwm.h | 8 +-
drivers/net/wireless/iwmc3200wifi/lmac.h | 15 ++
drivers/net/wireless/iwmc3200wifi/main.c | 60 +++++-
drivers/net/wireless/iwmc3200wifi/rx.c | 87 ++++++--
drivers/net/wireless/rndis_wlan.c | 98 ++------
drivers/net/wireless/rt2x00/rt2x00crypto.c | 6 +-
drivers/net/wireless/rt2x00/rt2x00dev.c | 38 ++--
drivers/net/wireless/rt2x00/rt2x00lib.h | 45 +++-
drivers/net/wireless/rt2x00/rt2x00queue.c | 99 +++++++--
include/linux/rfkill.h | 23 +-
net/mac80211/Kconfig | 5 +-
net/wireless/Kconfig | 4 +
net/wireless/scan.c | 2 +-
36 files changed, 894 insertions(+), 540 deletions(-)
Omnibus patch available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2009-09-02.patch.bz2
--
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
* building compat-wireless for other than running kernels
From: Natanael Copa @ 2009-09-02 20:53 UTC (permalink / raw)
To: linux-wireless
Hi,
I'm trying to create a compat-wireless package for Alpine Linux. I get
errors like this:
FATAL: Could not load
/lib/modules/2.6.29.4-vs2.3.0.36.14-ARCH/modules.dep: No such file or
directory
This comes from the fact that the package is not for the current running kernel.
It would be nice if modprobe and depmod could respect the KLIB
variable in makefile. (I have not figured out how to do that for
modprobe -l)
Alternatively you could define a DEPMOD=/sbin/depmod in the Makefile
so its possible to override it with: make DEPMOD=: ...
Thanks!
--
Natanael Copa
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-09-02
From: David Miller @ 2009-09-02 21:18 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20090902195651.GF2662@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 2 Sep 2009 15:56:51 -0400
> Once again, the usual batch of wireless updates for -next... This time
> its mostly a random collection of driver updates...
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: building compat-wireless for other than running kernels
From: Luis R. Rodriguez @ 2009-09-02 21:25 UTC (permalink / raw)
To: Natanael Copa; +Cc: linux-wireless
In-Reply-To: <95408c820909021353i5b2d0e5dpeddefcdb5065d724@mail.gmail.com>
On Wed, Sep 2, 2009 at 1:53 PM, Natanael Copa<natanael.copa@gmail.com> wrote:
> Hi,
> I'm trying to create a compat-wireless package for Alpine Linux. I get
> errors like this:
> FATAL: Could not load
> /lib/modules/2.6.29.4-vs2.3.0.36.14-ARCH/modules.dep: No such file or
> directory
> This comes from the fact that the package is not for the current running kernel.
>
> It would be nice if modprobe and depmod could respect the KLIB
> variable in makefile. (I have not figured out how to do that for
> modprobe -l)
>
> Alternatively you could define a DEPMOD=/sbin/depmod in the Makefile
> so its possible to override it with: make DEPMOD=: ...
Patches are welcomed. I considered just now added the depmod stuff you
mentioned but remembered that there are also scripts which may use
this on compat-wireless. We could just export it though and then all
the scripts would have access to it -- but note that it means then
that you'd need the Makefile to run certain scripts -- and if you
don't you have to define your own depmod. Because of this I welcome
your patches on this if you test it.
Luis
^ permalink raw reply
* Re: ar6k driver
From: Luis R. Rodriguez @ 2009-09-02 21:46 UTC (permalink / raw)
To: Werner Almesberger; +Cc: Luis Rodriguez, Len.Widra, linux-wireless
In-Reply-To: <20090902071849.GM4363@almesberger.net>
On Wed, Sep 02, 2009 at 12:18:49AM -0700, Werner Almesberger wrote:
> Luis R. Rodriguez wrote:
> > I know I found it last time I looked through the openmoko wiki but
> > it took me a lot of time to actually find the git tree and then
> > the branch name. Today I gave up looking for it so resorting to
> > asking you for the git url.
>
> Yeah, it can be a little hard to find, particularly the right branch :-)
>
> The repository is here:
> git://git.openmoko.org/git/openmoko.git
>
> The branch with the latest code is origin/andy-tracking
>
> Finally, my HIF is here:
> drivers/ar6000/hif/hif2.c
Thanks, I've created a new page for ar6k on the wireless.kernel.org wiki so
we don't loose track of this and so that this can be easier to find for others.
http://wireless.kernel.org/en/users/Drivers/ar6k
I've updated the openmoko wiki respectively:
http://wiki.openmoko.org/wiki/AR6K
Luis
^ permalink raw reply
* Re: building compat-wireless for other than running kernels
From: Natanael Copa @ 2009-09-02 22:00 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <43e72e890909021425s13784658r342e52eefb7b582d@mail.gmail.com>
On Wed, Sep 2, 2009 at 9:25 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Wed, Sep 2, 2009 at 1:53 PM, Natanael Copa<natanael.copa@gmail.com> wrote:
>> Hi,
>> I'm trying to create a compat-wireless package for Alpine Linux. I get
>> errors like this:
>> FATAL: Could not load
>> /lib/modules/2.6.29.4-vs2.3.0.36.14-ARCH/modules.dep: No such file or
>> directory
>> This comes from the fact that the package is not for the current running kernel.
...
>> Alternatively you could define a DEPMOD=/sbin/depmod in the Makefile
>> so its possible to override it with: make DEPMOD=: ...
>
> Patches are welcomed. I considered just now added the depmod stuff you
> mentioned but remembered that there are also scripts which may use
> this on compat-wireless. We could just export it though and then all
> the scripts would have access to it -- but note that it means then
> that you'd need the Makefile to run certain scripts -- and if you
> don't you have to define your own depmod. Because of this I welcome
> your patches on this if you test it.
That explains why I saw the error message even with my patch. For my
use the scripts are not critical as they don't exit with error and
make just continues. I do have an idea how to fix that too though.
I also have some simple fix to split the install so you can easily
have multiple binary packages for different kernel flavors but still
share the userspace scripts.
Thanks!
--
Natanael Copa
^ permalink raw reply
* Re: ar6k driver
From: Luis R. Rodriguez @ 2009-09-02 22:18 UTC (permalink / raw)
To: Werner Almesberger; +Cc: Luis Rodriguez, Len.Widra, linux-wireless
In-Reply-To: <20090902214601.GB5614@mosca>
On Wed, Sep 2, 2009 at 2:46 PM, Luis R. Rodriguez<lrodriguez@atheros.com> wrote:
> On Wed, Sep 02, 2009 at 12:18:49AM -0700, Werner Almesberger wrote:
>> Luis R. Rodriguez wrote:
>> > I know I found it last time I looked through the openmoko wiki but
>> > it took me a lot of time to actually find the git tree and then
>> > the branch name. Today I gave up looking for it so resorting to
>> > asking you for the git url.
>>
>> Yeah, it can be a little hard to find, particularly the right branch :-)
>>
>> The repository is here:
>> git://git.openmoko.org/git/openmoko.git
>>
>> The branch with the latest code is origin/andy-tracking
>>
>> Finally, my HIF is here:
>> drivers/ar6000/hif/hif2.c
>
> Thanks, I've created a new page for ar6k on the wireless.kernel.org wiki so
> we don't loose track of this and so that this can be easier to find for others.
>
> http://wireless.kernel.org/en/users/Drivers/ar6k
>
> I've updated the openmoko wiki respectively:
>
> http://wiki.openmoko.org/wiki/AR6K
Hm, seems origin/andy-tracking branch is gone:
mcgrof@tux ~/devel/openmoko (git::org.openmoko.dev)$ git branch -r
origin/HEAD -> origin/org.openmoko.dev
origin/historic/org.openembedded.dev
origin/historic/org.openmoko.asu.dev
origin/historic/org.openmoko.asu.stable
origin/historic/org.openmoko.asu.testing
origin/org.openmoko.dev
origin/org.openmoko.stable
Any ideas which one I should use, or is the master branch OK?
Luis
^ permalink raw reply
* [PATCH v2] ar9170: added phy register initialisation from eeprom values
From: Joerg Albert @ 2009-09-02 23:02 UTC (permalink / raw)
To: Christian Lamparter, John W. Linville
Cc: Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <22ee4e770908311437y4954a79eje48976a0203f1806@mail.gmail.com>
This patch adds the initialisation of some PHY registers
from the modal_header[] values in the EEPROM
(see otus/hal/hpmain.c, line 333 ff.)
Signed-off-by: Joerg Albert <jal2@gmx.de>
---
Compared to v1 I've included Christian's suggestions and removed
three unnecessary defval assignments for "ant * control".
This patch seems to depend on Christian's
"[RFT] ar9170: use eeprom's frequency calibration values"
(2009-08-21), I get a poor throughput here without it (1-stage fw,
802.11g AP).
drivers/net/wireless/ath/ar9170/phy.c | 136 ++++++++++++++++++++++++++++++++-
1 files changed, 135 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ar9170/phy.c b/drivers/net/wireless/ath/ar9170/phy.c
index df86f70..8fb1fa8 100644
--- a/drivers/net/wireless/ath/ar9170/phy.c
+++ b/drivers/net/wireless/ath/ar9170/phy.c
@@ -396,6 +396,138 @@ static struct ar9170_phy_init ar5416_phy_init[] = {
{ 0x1c9384, 0xf3307ff0, 0xf3307ff0, 0xf3307ff0, 0xf3307ff0, }
};
+/*
+ * look up a certain register in ar5416_phy_init[] and return the init. value
+ * for the band and bandwidth given. Return 0 if register address not found.
+ */
+static u32 ar9170_get_default_phy_reg_val(u32 reg, bool is_2ghz, bool is_40mhz)
+{
+ unsigned int i;
+ for (i = 0; i < ARRAY_SIZE(ar5416_phy_init); i++) {
+ if (ar5416_phy_init[i].reg != reg)
+ continue;
+
+ if (is_2ghz) {
+ if (is_40mhz)
+ return ar5416_phy_init[i]._2ghz_40;
+ else
+ return ar5416_phy_init[i]._2ghz_20;
+ } else {
+ if (is_40mhz)
+ return ar5416_phy_init[i]._5ghz_40;
+ else
+ return ar5416_phy_init[i]._5ghz_20;
+ }
+ }
+ return 0;
+}
+
+/*
+ * initialize some phy regs from eeprom values in modal_header[]
+ * acc. to band and bandwith
+ */
+static int ar9170_init_phy_from_eeprom(struct ar9170 *ar,
+ bool is_2ghz, bool is_40mhz)
+{
+ static const u8 xpd2pd[16] = {
+ 0x2, 0x2, 0x2, 0x1, 0x2, 0x2, 0x6, 0x2,
+ 0x2, 0x3, 0x7, 0x2, 0xB, 0x2, 0x2, 0x2
+ };
+ u32 defval, newval;
+ /* pointer to the modal_header acc. to band */
+ struct ar9170_eeprom_modal *m = &ar->eeprom.modal_header[is_2ghz];
+
+ ar9170_regwrite_begin(ar);
+
+ /* ant common control (index 0) */
+ newval = le32_to_cpu(m->antCtrlCommon);
+ ar9170_regwrite(0x1c5964, newval);
+
+ /* ant control chain 0 (index 1) */
+ newval = le32_to_cpu(m->antCtrlChain[0]);
+ ar9170_regwrite(0x1c5960, newval);
+
+ /* ant control chain 2 (index 2) */
+ newval = le32_to_cpu(m->antCtrlChain[1]);
+ ar9170_regwrite(0x1c7960, newval);
+
+ /* SwSettle (index 3) */
+ if (!is_40mhz) {
+ defval = ar9170_get_default_phy_reg_val(0x1c5844,
+ is_2ghz, is_40mhz);
+ newval = (defval & ~0x3f80) |
+ ((m->switchSettling & 0x7f) << 7);
+ ar9170_regwrite(0x1c5844, newval);
+ }
+
+ /* adcDesired, pdaDesired (index 4) */
+ defval = ar9170_get_default_phy_reg_val(0x1c5850, is_2ghz, is_40mhz);
+ newval = (defval & ~0xffff) | ((u8)m->pgaDesiredSize << 8) |
+ ((u8)m->adcDesiredSize);
+ ar9170_regwrite(0x1c5850, newval);
+
+ /* TxEndToXpaOff, TxFrameToXpaOn (index 5) */
+ defval = ar9170_get_default_phy_reg_val(0x1c5834, is_2ghz, is_40mhz);
+ newval = (m->txEndToXpaOff << 24) | (m->txEndToXpaOff << 16) |
+ (m->txFrameToXpaOn << 8) | m->txFrameToXpaOn;
+ ar9170_regwrite(0x1c5834, newval);
+
+ /* TxEndToRxOn (index 6) */
+ defval = ar9170_get_default_phy_reg_val(0x1c5828, is_2ghz, is_40mhz);
+ newval = (defval & ~0xff0000) | (m->txEndToRxOn << 16);
+ ar9170_regwrite(0x1c5828, newval);
+
+ /* thresh62 (index 7) */
+ defval = ar9170_get_default_phy_reg_val(0x1c8864, is_2ghz, is_40mhz);
+ newval = (defval & ~0x7f000) | (m->thresh62 << 12);
+ ar9170_regwrite(0x1c8864, newval);
+
+ /* tx/rx attenuation chain 0 (index 8) */
+ defval = ar9170_get_default_phy_reg_val(0x1c5848, is_2ghz, is_40mhz);
+ newval = (defval & ~0x3f000) | ((m->txRxAttenCh[0] & 0x3f) << 12);
+ ar9170_regwrite(0x1c5848, newval);
+
+ /* tx/rx attenuation chain 2 (index 9) */
+ defval = ar9170_get_default_phy_reg_val(0x1c7848, is_2ghz, is_40mhz);
+ newval = (defval & ~0x3f000) | ((m->txRxAttenCh[1] & 0x3f) << 12);
+ ar9170_regwrite(0x1c7848, newval);
+
+ /* tx/rx margin chain 0 (index 10) */
+ defval = ar9170_get_default_phy_reg_val(0x1c620c, is_2ghz, is_40mhz);
+ newval = (defval & ~0xfc0000) | ((m->rxTxMarginCh[0] & 0x3f) << 18);
+ /* bsw margin chain 0 for 5GHz only */
+ if (!is_2ghz)
+ newval = (newval & ~0x3c00) | ((m->bswMargin[0] & 0xf) << 10);
+ ar9170_regwrite(0x1c620c, newval);
+
+ /* tx/rx margin chain 2 (index 11) */
+ defval = ar9170_get_default_phy_reg_val(0x1c820c, is_2ghz, is_40mhz);
+ newval = (defval & ~0xfc0000) | ((m->rxTxMarginCh[1] & 0x3f) << 18);
+ ar9170_regwrite(0x1c820c, newval);
+
+ /* iqCall, iqCallq chain 0 (index 12) */
+ defval = ar9170_get_default_phy_reg_val(0x1c5920, is_2ghz, is_40mhz);
+ newval = (defval & ~0x7ff) | (((u8)m->iqCalICh[0] & 0x3f) << 5) |
+ ((u8)m->iqCalQCh[0] & 0x1f);
+ ar9170_regwrite(0x1c5920, newval);
+
+ /* iqCall, iqCallq chain 2 (index 13) */
+ defval = ar9170_get_default_phy_reg_val(0x1c7920, is_2ghz, is_40mhz);
+ newval = (defval & ~0x7ff) | (((u8)m->iqCalICh[1] & 0x3f) << 5) |
+ ((u8)m->iqCalQCh[1] & 0x1f);
+ ar9170_regwrite(0x1c7920, newval);
+
+ /* xpd gain mask (index 14) */
+ defval = ar9170_get_default_phy_reg_val(0x1c6258, is_2ghz, is_40mhz);
+ newval = (defval & ~0xf0000) | (xpd2pd[m->xpdGain & 0xf] << 16);
+ ar9170_regwrite(0x1c6258, newval);
+
+
+ ar9170_regwrite_finish();
+
+ return ar9170_regwrite_result();
+}
+
int ar9170_init_phy(struct ar9170 *ar, enum ieee80211_band band)
{
int i, err;
@@ -426,7 +558,9 @@ int ar9170_init_phy(struct ar9170 *ar, enum ieee80211_band band)
if (err)
return err;
- /* XXX: use EEPROM data here! */
+ err = ar9170_init_phy_from_eeprom(ar, is_2ghz, is_40mhz);
+ if (err)
+ return err;
err = ar9170_init_power_cal(ar);
if (err)
--
1.6.0.4
^ permalink raw reply related
* [PATCH] ath9k: propagate ieee80211_alloc_hw() failure
From: Luis R. Rodriguez @ 2009-09-02 23:34 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
The -ENOMEM was never being passed on failure.
While at it use dev_err() as ahb does upon failure.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/pci.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
index 685a8ce..17862cc 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -160,8 +160,9 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
hw = ieee80211_alloc_hw(sizeof(struct ath_wiphy) +
sizeof(struct ath_softc), &ath9k_ops);
- if (hw == NULL) {
- printk(KERN_ERR "ath_pci: no memory for ieee80211_hw\n");
+ if (!hw) {
+ dev_err(&pdev->dev, "no memory for ieee80211_hw\n");
+ ret = -ENOMEM;
goto bad2;
}
--
1.6.3.3
^ permalink raw reply related
* [PATCH] ath9k: propagate errors on ath_init_device() and request_irq()
From: Luis R. Rodriguez @ 2009-09-03 0:02 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
We've cleaned up ath_init_device() and its children enough
to pass meaninful errors back from probe. When this fails
it means our device could not be initialized and a meaninful
error will have been passed.
Do the same for request_irq() and also synchronize the error
messages while at it.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/ahb.c | 8 +++-----
drivers/net/wireless/ath/ath9k/pci.c | 12 ++++++------
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ahb.c b/drivers/net/wireless/ath/ath9k/ahb.c
index 5618fc2..7dc6301 100644
--- a/drivers/net/wireless/ath/ath9k/ahb.c
+++ b/drivers/net/wireless/ath/ath9k/ahb.c
@@ -120,16 +120,14 @@ static int ath_ahb_probe(struct platform_device *pdev)
sc->irq = irq;
ret = ath_init_device(AR5416_AR9100_DEVID, sc);
- if (ret != 0) {
- dev_err(&pdev->dev, "failed to attach device, err=%d\n", ret);
- ret = -ENODEV;
+ if (ret) {
+ dev_err(&pdev->dev, "failed to initialize device\n");
goto err_free_hw;
}
ret = request_irq(irq, ath_isr, IRQF_SHARED, "ath9k", sc);
if (ret) {
- dev_err(&pdev->dev, "request_irq failed, err=%d\n", ret);
- ret = -EIO;
+ dev_err(&pdev->dev, "request_irq failed\n");
goto err_detach;
}
diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
index 17862cc..bc4bc2c 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -179,17 +179,17 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
sc->mem = mem;
sc->bus_ops = &ath_pci_bus_ops;
- if (ath_init_device(id->device, sc) != 0) {
- ret = -ENODEV;
+ ret = ath_init_device(id->device, sc);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to initialize device\n");
goto bad3;
}
/* setup interrupt service routine */
- if (request_irq(pdev->irq, ath_isr, IRQF_SHARED, "ath", sc)) {
- printk(KERN_ERR "%s: request_irq failed\n",
- wiphy_name(hw->wiphy));
- ret = -EIO;
+ ret = request_irq(pdev->irq, ath_isr, IRQF_SHARED, "ath", sc);
+ if (ret) {
+ dev_err(&pdev->dev, "request_irq failed\n");
goto bad4;
}
--
1.6.3.3
^ permalink raw reply related
* [PATCH] ath9k: claim irq for ath9k, not ath for pci
From: Luis R. Rodriguez @ 2009-09-03 0:06 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
ath9k ahb requests an IRQ and indicates 'ath9k' claimed it,
ath9k pci requests an IRQ and indicates 'ath' claims it;
since 'ath' is another module sync both ahb and pci to claim
the irq using 'ath9k'.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/pci.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
index bc4bc2c..8bb286d 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -187,7 +187,7 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
/* setup interrupt service routine */
- ret = request_irq(pdev->irq, ath_isr, IRQF_SHARED, "ath", sc);
+ ret = request_irq(pdev->irq, ath_isr, IRQF_SHARED, "ath9k", sc);
if (ret) {
dev_err(&pdev->dev, "request_irq failed\n");
goto bad4;
--
1.6.3.3
^ permalink raw reply related
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