Thanks for TX power patch

Thanks for TX power patch

[Maxim Levitsky]

First, big thanks to Nick Kossifidis
Finally I get a decent speed out of my aspire one
iwconfig output specifies 54M/s.

Still transfer speeds are at 2.4~2.5M/s, while I could achieve 2.9~3.0
Mb/s on my iwl3945. Probably ANI support with fix that, or maybe just
that is the device maximum, for example due to noise at hardware paths,
not a perfect amplifier, etc... I need to test this in windows.

Also, ath5k issues many resets to the device, which results in transfer
stalls for few seconds, so effective speed is much lower.
But these are minor solvable problems, and thus thanks again.


So in summary your patch works fine.

But I noticed that few (or one) bugs crept into ath5k while I didn't
update it.

Latest version of wireless-testing that doesn't produce any
oopses/problems with suspend to disk, etc : master-2009-02-24


I now downloaded the 'compat-wireless-2009-03-10', and installed on the
above tree (I usually just install and use a wireless-testing tree, but
this time I was lazy, so I just installed compat-wireless package)


With or without (tested both) latest Nick's patches, it fails very badly
with suspend to disk.

After a suspend to disk, NM can't scan - iwlist scan says : device is
busy

(Btw I got same behavior with my iwl3945 - I disabled its hardware scan
to fix this temporally)


If I unload/reload the ath5k, it seems to work. but at next suspend to
disk, once  system hung, other time it showed many panic, in something
related to page allocator (one even was in page_alloc_pages or so)


Next time I just reloaded the ath5k, and got this in dmesg:



> [  125.144098] wlan0: no IPv6 routers present
> [  133.952101] __ratelimit: 52 callbacks suppressed
> [  133.952118] ath5k phy0: (ath5k_chan_set:1049): (2412 MHz) -> (2412 MHz)
> [  134.016143] ath5k phy0: (ath5k_chan_set:1049): (2412 MHz) -> (2417 MHz)
> [  134.016158] ath5k phy0: (ath5k_reset:2745): resetting
> [  134.016309] ath5k phy0: (ath5k_txq_cleanup:1530): beacon queue 0
> [  134.016453] ath5k phy0: (ath5k_txq_cleanup:1539): txq [0] 2479ed00, link (null)
> [  134.016493] rx queue 2479e0e0, link e479e0c0
> [  134.043236] ath5k phy0: (ath5k_rx_start:1582): cachelsz 64 rxbufsize 2560
> [  134.108204] ath5k phy0: (ath5k_chan_set:1049): (2417 MHz) -> (2422 MHz)
> [  134.108224] ath5k phy0: (ath5k_reset:2745): resetting
> [  134.108378] ath5k phy0: (ath5k_txq_cleanup:1530): beacon queue 0
> [  134.108526] ath5k phy0: (ath5k_txq_cleanup:1539): txq [0] 2479ed20, link (null)
> [  134.108575] rx queue 2479e100, link e479e0e0
> [  134.196477] rx queue 2479e100, link e479e0e0
> [  134.284343] rx queue 2479e100, link e479e0e0
> [  134.380353] rx queue 2479e140, link e479e120
> [  134.480370] rx queue 2479e1a0, link e479e180
> [  134.573328] rx queue 2479e1a0, link e479e180
> [  134.665381] rx queue 2479e1a0, link e479e180
> [  134.757380] rx queue 2479e1a0, link e479e180
> [  134.849377] rx queue 2479e1c0, link e479e1a0
> [  134.941818] rx queue 2479e1e0, link e479e1c0
> [  141.462491] BUG: unable to handle kernel paging request at 1fc6c2e4
> [  141.462522] IP: [<c02503f2>] rb_next+0x22/0x50
> [  141.462554] *pdpt = 000000002c965001 *pde = 0000000000000000 
> [  141.462579] Oops: 0000 [#1] PREEMPT SMP 
> [  141.462601] last sysfs file: /sys/devices/platform/coretemp.0/temp1_input
> [  141.462617] Modules linked in: ath5k mac80211 cfg80211 af_packet i915 drm ipv6 acpi_cpufreq cpufreq_stats cpufreq_userspace cpufreq_conservative cpufreq_powersave coretemp acpiphp snd_hda_codec_realtek snd_hda_intel snd_hda_codec acer_wmi joydev uvcvideo snd_hwdep rfkill videodev v4l1_compat snd_pcm_oss rtc_cmos serio_raw psmouse snd_mixer_oss pcspkr rtc_core rtc_lib intel_agp evdev snd_pcm iTCO_wdt iTCO_vendor_support agpgart snd_timer snd_page_alloc ext3 jbd mbcache ata_piix ehci_hcd uhci_hcd libata usbcore fuse [last unloaded: cfg80211]
> [  141.462842] 
> [  141.462859] Pid: 4525, comm: update-notifier Not tainted (2.6.29-rc6-wl-led #14) AOA150
> [  141.462879] EIP: 0060:[<c02503f2>] EFLAGS: 00010202 CPU: 0
> [  141.462899] EIP is at rb_next+0x22/0x50
> [  141.462914] EAX: 1fc6c2dc EBX: ec94a048 ECX: ec94a6c8 EDX: 1fc6c2dc
> [  141.462930] ESI: ecac1700 EDI: ec94a6c8 EBP: ec98bed4 ESP: ec98bed0
> [  141.462946]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> [  141.462964] Process update-notifier (pid: 4525, ti=ec98a000 task=f6402940 task.ti=ec98a000)
> [  141.462979] Stack:
> [  141.462989]  eca77620 ec98bf6c f874883a ec94a6c0 c01b57a4 bfbafedc ec98bf60 00000804
> [  141.463029]  00000000 00000000 0015e409 c01c0070 ec98bf94 ecac1700 00000000 00000000
> [  141.463072]  00000000 f6b17800 f29d4478 00000000 00001000 00000008 00000000 492f942e
> [  141.463117] Call Trace:
> [  141.463139]  [<f874883a>] ? ext3_readdir+0x50a/0x700 [ext3]
> [  141.463194]  [<c01b57a4>] ? cp_new_stat64+0xe4/0x100
> [  141.463219]  [<c01c0070>] ? filldir64+0x0/0xf0
> [  141.463242]  [<c01b5c52>] ? sys_fstat64+0x22/0x30
> [  141.463277]  [<c01c03a0>] ? vfs_readdir+0x90/0xb0
> [  141.463299]  [<c01c0070>] ? filldir64+0x0/0xf0
> [  141.463319]  [<c01c0429>] ? sys_getdents64+0x69/0xb0
> [  141.463339]  [<c010342d>] ? sysenter_do_call+0x12/0x21
> [  141.463363] Code: 90 90 90 90 90 90 90 90 90 55 89 c1 89 e5 31 d2 53 8b 18 89 d8 83 e0 fc 39 c1 74 18 8b 41 04 85 c0 75 08 eb 18 8d 74 26 00 89 d0 <8b> 50 08 85 d2 75 f7 89 c2 89 d0 5b c9 c3 8b 1a 89 d1 89 da 83 
> [  141.463611] EIP: [<c02503f2>] rb_next+0x22/0x50 SS:ESP 0068:ec98bed0
> [  141.463648] ---[ end trace ab9ecd084d01dbb6 ]---
> [  173.948145] __ratelimit: 46 callbacks suppressed
> [  173.948163] ath5k phy0: (ath5k_chan_set:1049): (2412 MHz) -> (2412 MHz)
> [  174.012091] ath5k phy0: (ath5k_chan_set:1049): (2412 MHz) -> (2417 MHz)
> [  174.012108] ath5k phy0: (ath5k_reset:2745): resetting
> [  174.012258] ath5k phy0: (ath5k_txq_cleanup:1530): beacon queue 0
> [  174.012402] ath5k phy0: (ath5k_txq_cleanup:1539): txq [0] 2479ef40, link (null)
> [  174.012442] rx queue 2479e060, link e479e040
> [  174.041089] ath5k phy0: (ath5k_rx_start:1582): cachelsz 64 rxbufsize 2560
> [  174.104165] ath5k phy0: (ath5k_chan_set:1049): (2417 MHz) -> (2422 MHz)
> [  174.104182] ath5k phy0: (ath5k_reset:2745): resetting
> [  174.104332] ath5k phy0: (ath5k_txq_cleanup:1530): beacon queue 0
> [  174.104476] ath5k phy0: (ath5k_txq_cleanup:1539): txq [0] 2479ef60, link (null)
> 


So thanks again,
	Best regards,
		Maxim Levitsky

Re: Thanks for TX power patch

[Nick Kossifidis]

2009/3/11 Maxim Levitsky <maximlevitsky@gmail.com>:
>
> First, big thanks to Nick Kossifidis
> Finally I get a decent speed out of my aspire one
> iwconfig output specifies 54M/s.
>

It's not only my work it's also Felix's work and of course Sam's work,
but thanks anyway ;-)

> Still transfer speeds are at 2.4~2.5M/s, while I could achieve 2.9~3.=
0
> Mb/s on my iwl3945. Probably ANI support with fix that, or maybe just
> that is the device maximum, for example due to noise at hardware path=
s,
> not a perfect amplifier, etc... I need to test this in windows.
>

It can also be the missing Spur mitigation stuff, missing WME stuff,
we have a lot of things to do (i'll update the TODO list on wiki
asap)...

> Also, ath5k issues many resets to the device, which results in transf=
er
> stalls for few seconds, so effective speed is much lower.
> But these are minor solvable problems, and thus thanks again.
>

Yup we need to stop calling reset so often also after i'm done with
phy stuff i'll focus on a smaller reset that'll only tweak some parts
of pcu/qcu to stop/resume queues without reseting the whole chip.

>
> So in summary your patch works fine.
>

Thanks a lot for your feedback ;-)

> But I noticed that few (or one) bugs crept into ath5k while I didn't
> update it.
>
> Latest version of wireless-testing that doesn't produce any
> oopses/problems with suspend to disk, etc : master-2009-02-24
>
>
> I now downloaded the 'compat-wireless-2009-03-10', and installed on t=
he
> above tree (I usually just install and use a wireless-testing tree, b=
ut
> this time I was lazy, so I just installed compat-wireless package)
>
>
> With or without (tested both) latest Nick's patches, it fails very ba=
dly
> with suspend to disk.
>
> After a suspend to disk, NM can't scan - iwlist scan says : device is
> busy
>
> (Btw I got same behavior with my iwl3945 - I disabled its hardware sc=
an
> to fix this temporally)
>
>
> If I unload/reload the ath5k, it seems to work. but at next suspend t=
o
> disk, once =C2=A0system hung, other time it showed many panic, in som=
ething
> related to page allocator (one even was in page_alloc_pages or so)
>
>
> Next time I just reloaded the ath5k, and got this in dmesg:
>
>
>

I got this too many times and also some kmemcheck stuff but i didn't
had any time to look at it, i don't think it's related to ath5k or
mac80211, i got such crashes with the applesmc module too.



--=20
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thanks for TX power patch

[Tulio Magno Quites Machado Filho]

On Wed, Mar 11, 2009 at 12:39 AM, Maxim Levitsky
<maximlevitsky@gmail.com> wrote:
> If I unload/reload the ath5k, it seems to work. but at next suspend t=
o
> disk, once =A0system hung, other time it showed many panic, in someth=
ing
> related to page allocator (one even was in page_alloc_pages or so)

I'm getting some Kernel oopses after unloading ath5k with Nick patches.
But I'm still debugging it to find where is the problem.

Here is the log:

Mar 10 19:51:52 joutaro kernel: [ 2299.030740] ath5k 0000:06:00.0: PCI
INT A disabled
Mar 10 19:51:52 joutaro ifdown: Network interface is managed from Netwo=
rkManager
Mar 10 19:51:52 joutaro ifdown: NetworkManager cannot be advised to
take down an interface.
Mar 10 19:51:52 joutaro ifdown: Set up another interface instead.
Mar 10 19:51:52 joutaro ifdown:     wmaster0
Mar 10 19:51:52 joutaro ifdown: Interface not available and no
configuration found.
Mar 10 19:51:52 joutaro kernel: [ 2299.266536] BUG: unable to handle
kernel paging request at 7774d524
Mar 10 19:51:52 joutaro kernel: [ 2299.266543] IP: [<f81cd0bb>]
ext3_htree_store_dirent+0x7b/0xe4 [ext3]
Mar 10 19:51:52 joutaro kernel: [ 2299.266563] *pdpt =3D
0000000028c13001 *pde =3D 0000000000000000
Mar 10 19:51:52 joutaro kernel: [ 2299.266568] Oops: 0000 [#1] SMP
Mar 10 19:51:52 joutaro kernel: [ 2299.266573] last sysfs file:
/sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device
:03/PNP0C0A:00/power_supply/BAT0/charge_full
Mar 10 19:51:52 joutaro kernel: [ 2299.266578] Modules linked in:
af_packet ip6t_LOG xt_tcpudp xt_pkttype ipt_LOG xt
_limit i915 drm i2c_algo_bit snd_pcm_oss snd_mixer_oss coretemp
binfmt_misc snd_seq snd_seq_device ip6t_REJECT nf_co
nntrack_ipv6 ip6table_raw xt_NOTRACK ipt_REJECT xt_state iptable_raw
iptable_filter ip6table_mangle nf_conntrack_net
bios_ns nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables
ip6table_filter ip6_tables x_tables ipv6 fuse loop d
m_mod arc4 ecb snd_hda_codec_realtek snd_hda_intel snd_hda_codec
snd_hwdep mac80211 snd_pcm snd_timer led_class vide
o snd i2c_i801 rtc_cmos soundcore iTCO_wdt cfg80211 output pcspkr
intel_agp rtc_core iTCO_vendor_support sr_mod wmi
i2c_core button agpgart sg battery rtc_lib ac cdrom tg3 libphy
snd_page_alloc usbhid hid sd_mod crc_t10dif uhci_hcd
ehci_hcd usbcore edd ext3 mbcache jbd fan ide_pci_generic piix
ide_core ata_generic ata_piix ahci libata scsi_mod th
ermal processor thermal_sys hwmon [last unloaded: ath5k]
Mar 10 19:51:52 joutaro kernel: [ 2299.266660]
Mar 10 19:51:52 joutaro kernel: [ 2299.266664] Pid: 10482, comm:
modprobe Not tainted (2.6.29-rc7-wl-pae-tuliom #8)
eMachines E510
Mar 10 19:51:52 joutaro kernel: [ 2299.266667] EIP: 0060:[<f81cd0bb>]
EFLAGS: 00010202 CPU: 0
Mar 10 19:51:52 joutaro kernel: [ 2299.266681] EIP is at
ext3_htree_store_dirent+0x7b/0xe4 [ext3]
Mar 10 19:51:52 joutaro kernel: [ 2299.266684] EAX: 33bd1312 EBX:
e843620c ECX: 7774d52c EDX: e8436208
Mar 10 19:51:52 joutaro kernel: [ 2299.266686] ESI: e8436200 EDI:
e8436210 EBP: e8cbfe5c ESP: e8cbfe4c
Mar 10 19:51:52 joutaro kernel: [ 2299.266689]  DS: 007b ES: 007b FS:
00d8 GS: 0033 SS: 0068
Mar 10 19:51:52 joutaro kernel: [ 2299.266692] Process modprobe (pid:
10482, ti=3De8cbe000 task=3De9028670 task.ti=3De8cbe
000)
Mar 10 19:51:52 joutaro kernel: [ 2299.266694] Stack:
Mar 10 19:51:52 joutaro kernel: [ 2299.266696]  e91a2a80 f52a50ec
f5925c88 0000000d e8cbfe88 f81d4b7c f52a50ec 00000
000
Mar 10 19:51:52 joutaro kernel: [ 2299.266703]  f585f698 f4d95d40
f52a5ff8 00000000 f4d95d40 f4d95d40 f585f698 e8cbf
ee8
Mar 10 19:51:52 joutaro kernel: [ 2299.266710]  f81d4c15 e8cbfec4
00000000 00000000 00000000 00000000 f4d95d40 f5c25
ec0
Mar 10 19:51:52 joutaro kernel: [ 2299.266717] Call Trace:
Mar 10 19:51:52 joutaro kernel: [ 2299.266725]  [<f81d4b7c>] ?
htree_dirblock_to_tree+0xd6/0x118 [ext3]
Mar 10 19:51:52 joutaro kernel: [ 2299.266744]  [<f81d4c15>] ?
ext3_htree_fill_tree+0x57/0x19e [ext3]
Mar 10 19:51:52 joutaro kernel: [ 2299.266759]  [<c01a1e5d>] ?
nameidata_to_filp+0x2c/0x43
Mar 10 19:51:52 joutaro kernel: [ 2299.266773]  [<f81ccbff>] ?
ext3_readdir+0x17a/0x5bb [ext3]
Mar 10 19:51:52 joutaro kernel: [ 2299.266786]  [<c01ae7f0>] ?
filldir64+0x0/0xcd
Mar 10 19:51:52 joutaro kernel: [ 2299.266792]  [<c01a64d0>] ?
sys_fstat64+0x22/0x28
Mar 10 19:51:52 joutaro kernel: [ 2299.266803]  [<c01aea8f>] ?
vfs_readdir+0x63/0x8f
Mar 10 19:51:52 joutaro kernel: [ 2299.266807]  [<c01ae7f0>] ?
filldir64+0x0/0xcd
Mar 10 19:51:52 joutaro kernel: [ 2299.266810]  [<c01aeb1e>] ?
sys_getdents64+0x63/0xa0
Mar 10 19:51:52 joutaro kernel: [ 2299.266814]  [<c010405b>] ?
sysenter_do_call+0x12/0x2f
Mar 10 19:51:52 joutaro kernel: [ 2299.266819]  [<c013007b>] ?
do_syslog+0x2fc/0x358
Mar 10 19:51:52 joutaro kernel: [ 2299.266824] Code: 1c 8a 42 07 88 43
1d 0f b6 42 06 89 c1 c1 e9 02 f3 a5 89 c1 83
e1 03 74 02 f3 a4 0f b6 42 06 31 d2 8b 7d f0 c6 44 03 1e 00 eb 3c <8b>
41 f8 8d 71 f8 39 03 75 13 8b 43 04 3b 46 04
75 19 8b 46 14
Mar 10 19:51:52 joutaro kernel: [ 2299.266865] EIP: [<f81cd0bb>]
ext3_htree_store_dirent+0x7b/0xe4 [ext3] SS:ESP 006
8:e8cbfe4c
Mar 10 19:51:52 joutaro kernel: [ 2299.266883] ---[ end trace
19566f297b710799 ]---

After this the system hang.

This isn't happening with wireless-testing tree in here.

Best regards,

--=20
Tulio Magno
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thanks for TX power patch

[Bob Copeland]

On Wed, Mar 11, 2009 at 4:15 AM, Tulio Magno Quites Machado Filho
<tuliom@gmail.com> wrote:
> On Wed, Mar 11, 2009 at 12:39 AM, Maxim Levitsky
> <maximlevitsky@gmail.com> wrote:
>> If I unload/reload the ath5k, it seems to work. but at next suspend =
to
>> disk, once =A0system hung, other time it showed many panic, in somet=
hing
>> related to page allocator (one even was in page_alloc_pages or so)
>
> I'm getting some Kernel oopses after unloading ath5k with Nick patche=
s.
> But I'm still debugging it to find where is the problem.

Ditto here.. looks like a bug in ath5k_eeprom_free_pcal_info(), which h=
as:

    struct ath5k_pdgain_info *pd =3D &chinfo->pd_curves[pdg];

    if (pd !=3D NULL) {
        kfree(pd->pd_step);
        kfree(pd->pd_pwr);
        kfree(pd);
    }

kfree(pd) looks wrong, because pd_curves is the kzalloc()ed part, not
the array elements themselves.  But I tried removing that and freeing
the pd_curves array outside of the loop and got more slab debugging
poop.  So, I punt for now.

Also, every alloc of pd_step, and pd_pwr can potentially leak earlier
allocated memory on ENOMEM.

--=20
Bob Copeland %% www.bobcopeland.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thanks for TX power patch

[Maxim Levitsky]

On Thu, 2009-03-12 at 10:14 -0400, Bob Copeland wrote:
> On Wed, Mar 11, 2009 at 4:15 AM, Tulio Magno Quites Machado Filho
> <tuliom@gmail.com> wrote:
> > On Wed, Mar 11, 2009 at 12:39 AM, Maxim Levitsky
> > <maximlevitsky@gmail.com> wrote:
> >> If I unload/reload the ath5k, it seems to work. but at next suspend to
> >> disk, once  system hung, other time it showed many panic, in something
> >> related to page allocator (one even was in page_alloc_pages or so)
> >
> > I'm getting some Kernel oopses after unloading ath5k with Nick patches.
> > But I'm still debugging it to find where is the problem.
> 
> Ditto here.. looks like a bug in ath5k_eeprom_free_pcal_info(), which has:
> 
>     struct ath5k_pdgain_info *pd = &chinfo->pd_curves[pdg];
> 
>     if (pd != NULL) {
>         kfree(pd->pd_step);
>         kfree(pd->pd_pwr);
>         kfree(pd);
>     }
> 
> kfree(pd) looks wrong, because pd_curves is the kzalloc()ed part, not
> the array elements themselves.  But I tried removing that and freeing
> the pd_curves array outside of the loop and got more slab debugging
> poop.  So, I punt for now.
> 
> Also, every alloc of pd_step, and pd_pwr can potentially leak earlier
> allocated memory on ENOMEM.
> 

Just to be clear, I got oopses, and hangs after resume from disk by just
using compat-wireless-2009-03-10 _without_ Nick's patches.

It seems that a memory corruption happens somewhere.
On the other hand if I avoid S2disk and module reload, everything seems
to be stable and fast (2.4 MB/s in both directions)

Best regards,
	Maxim Levitsky

Re: [ath5k-devel] Thanks for TX power patch

[Bob Copeland]

On Thu, Mar 12, 2009 at 5:25 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> Just to be clear, I got oopses, and hangs after resume from disk by just
> using compat-wireless-2009-03-10 _without_ Nick's patches.

Interesting, I thought you said that, but I tried the same stuff on
plain wireless testing and didn't have any problems.

The eeprom stuff was definitely implicated in my 1 sec modprobe + rmmod
test.

-- 
Bob Copeland %% www.bobcopeland.com

Re: [ath5k-devel] Thanks for TX power patch

[Bob Copeland]

On Thu, Mar 12, 2009 at 5:32 PM, Bob Copeland <me@bobcopeland.com> wrote:
> On Thu, Mar 12, 2009 at 5:25 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>> Just to be clear, I got oopses, and hangs after resume from disk by just
>> using compat-wireless-2009-03-10 _without_ Nick's patches.
>
> Interesting, I thought you said that, but I tried the same stuff on
> plain wireless testing and didn't have any problems.

Oh, and you said compat-wireless -- can you try wireless-testing just
to make sure it's not some structure definition build conflict with
compat-wireless?

-- 
Bob Copeland %% www.bobcopeland.com

Re: [ath5k-devel] Thanks for TX power patch

[Maxim Levitsky]

On Thu, 2009-03-12 at 17:33 -0400, Bob Copeland wrote:
> On Thu, Mar 12, 2009 at 5:32 PM, Bob Copeland <me@bobcopeland.com> wrote:
> > On Thu, Mar 12, 2009 at 5:25 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> >> Just to be clear, I got oopses, and hangs after resume from disk by just
> >> using compat-wireless-2009-03-10 _without_ Nick's patches.
> >
> > Interesting, I thought you said that, but I tried the same stuff on
> > plain wireless testing and didn't have any problems.
> 
> Oh, and you said compat-wireless -- can you try wireless-testing just
> to make sure it's not some structure definition build conflict with
> compat-wireless?
> 

Will do, soon.

Best regards,
	Maxim Levitsky

Re: Thanks for TX power patch

[Bob Copeland]

On Thu, Mar 12, 2009 at 10:14:09AM -0400, Bob Copeland wrote:
> 
> kfree(pd) looks wrong, because pd_curves is the kzalloc()ed part, not
> the array elements themselves.  But I tried removing that and freeing
> the pd_curves array outside of the loop and got more slab debugging
> poop.  So, I punt for now.

This seems to fix it for me...

diff --git a/drivers/net/wireless/ath5k/eeprom.c b/drivers/net/wireless/ath5k/eeprom.c
index f992b1b..0b062f6 100644
--- a/drivers/net/wireless/ath5k/eeprom.c
+++ b/drivers/net/wireless/ath5k/eeprom.c
@@ -1559,17 +1559,20 @@ ath5k_eeprom_free_pcal_info(struct ath5k_hw *ah, int mode)
 	}
 
 	for (pier = 0; pier < ee->ee_n_piers[mode]; pier++) {
+		if (!chinfo[pier].pd_curves)
+			continue;
+
 		for (pdg = 0; pdg < ee->ee_pd_gains[mode]; pdg++) {
-			struct ath5k_pdgain_info *pd = &chinfo->pd_curves[pdg];
+			struct ath5k_pdgain_info *pd =
+				&chinfo[pier].pd_curves[pdg];
 
 			if (pd != NULL) {
 				kfree(pd->pd_step);
 				kfree(pd->pd_pwr);
-				kfree(pd);
 			}
 		}
+		kfree(chinfo[pier].pd_curves);
 	}
-
 	return 0;
 }
 

-- 
Bob Copeland %% www.bobcopeland.com

Re: [ath5k-devel] Thanks for TX power patch

[Maxim Levitsky]

On Fri, 2009-03-13 at 00:04 +0200, Maxim Levitsky wrote:
> On Thu, 2009-03-12 at 17:33 -0400, Bob Copeland wrote:
> > On Thu, Mar 12, 2009 at 5:32 PM, Bob Copeland <me@bobcopeland.com> wrote:
> > > On Thu, Mar 12, 2009 at 5:25 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> > >> Just to be clear, I got oopses, and hangs after resume from disk by just
> > >> using compat-wireless-2009-03-10 _without_ Nick's patches.
> > >
> > > Interesting, I thought you said that, but I tried the same stuff on
> > > plain wireless testing and didn't have any problems.
> > 
> > Oh, and you said compat-wireless -- can you try wireless-testing just
> > to make sure it's not some structure definition build conflict with
> > compat-wireless?
> > 
> 
> Will do, soon.
> 
> Best regards,
> 	Maxim Levitsky
> 

Just compiled and installed latest wireless-testing with Nick's patches,
and your patch.

System is rock solid, module reload/s2disk/s2ram/long transfers work
just fine.

(I tested against my laptop, and got 1.5 Mbytes/s in both directions.
which is maximum speed possible - yes I know that everything goes
through AP...)

Now my both wifi device are supported almost perfectly:
still small issues with rate control on iwl3945, and
not that great led on ath5k - both issues are pure software issues, and
when I have time I will look at improving led algorithm.


Big thanks,
	Best regards,
		Maxim Levitsky

Re: [ath5k-devel] Thanks for TX power patch

[Bob Copeland]

On Fri, Mar 13, 2009 at 6:38 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>
> Just compiled and installed latest wireless-testing with Nick's patches,
> and your patch.
>
> System is rock solid, module reload/s2disk/s2ram/long transfers work
> just fine.

Great, thanks for the test!

-- 
Bob Copeland %% www.bobcopeland.com

Re: [ath5k-devel] Thanks for TX power patch

[Nick Kossifidis]

2009/3/13 Bob Copeland <me@bobcopeland.com>:
> On Fri, Mar 13, 2009 at 6:38 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>>
>> Just compiled and installed latest wireless-testing with Nick's patches,
>> and your patch.
>>
>> System is rock solid, module reload/s2disk/s2ram/long transfers work
>> just fine.
>
> Great, thanks for the test!
>
> --
> Bob Copeland %% www.bobcopeland.com

Cool, nice catch Bob ;-)

I'll resubmit the patches on the weekend and address this bug and
Jiri's comments...


-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Re: [ath5k-devel] Thanks for TX power patch

[Maxim Levitsky]

On Fri, 2009-03-13 at 14:23 -0400, Bob Copeland wrote:
> On Fri, Mar 13, 2009 at 6:38 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> >
> > Just compiled and installed latest wireless-testing with Nick's patches,
> > and your patch.
> >
> > System is rock solid, module reload/s2disk/s2ram/long transfers work
> > just fine.
> 
> Great, thanks for the test!
> 

Just few random notes:



I noticed that sometimes NM couldn't scan after  s2ram on aspire one.

On the other hand doing iwlist scan, doesn't say device is busy, but
also hangs. Nothing interesting in the logs.
Module reload helps.


The above with updated wpa_supplicant there (latest -git) NM is from
ubuntu PPA archive yet, not sure if happens with stable one.

I also applied two patches from Helmut Schaa, maybe it was the cause.



I also noticed on both my notebooks, that wpa supplicant (stable too)
fails to do first scan, and retries after 10 seconds.
I changed this to 1 sec on my main notebook, and 2 seconds on ath5k.




I also happy to say that I don't see anymore reset hangs. Maybe tx power
patches fixed that?



Also it seems that scan results show correct power levels for APs near
me, including mine (they usually were very different from these I got
from iwlwifi - now more or less they are the same)



My AP is -51dBm ~ -45 dBm 



>From now on, during two/three weeks I will try not to use my computers
I have very big exams very soon. So I might not read email.

But then I will be free for some long time to help with anything I can.


Best regards and thanks again,
	Maxim Levitsky