ath9k causes lockups since kernel 2.6.33

ath9k causes lockups since kernel 2.6.33

[Tony Houghton]

[Posted to linux-wireless and 611946@bugs.debian.org. Sorry about the
repost, I got the bug number wrong before]

After upgrading my netbook's kernel from 2.6.32 in Debian squeeze I
found it could not reliably shut down the wireless connection eg when
suspending. It would almost always completely lock up. Ubuntu's 2.6.35
kernel is also affected, and so are certain versions pulled from git,
compiled with a config based on the Debian default.

While testing different kernels I found it would crash at different
times, usually before the screen turned off for suspending, but
sometimes it would crash on resuming and occasionally it locked up while
booting, but it's always a complete lock-up ie the keyboard is
completely responsive, including caps lock, the mouse won't move if the
display is still on, and the only way out is to hold down the power
button.

The adaptor is an AR9285:

84: udi = '/org/freedesktop/Hal/devices/pci_168c_2b'
  pci.device_protocol = 0  (0x0)  (int)
  pci.vendor = 'Atheros Communications Inc.'  (string)
  info.vendor = 'Atheros Communications Inc.'  (string)
  pci.product = 'AR9285 Wireless Network Adapter
(PCI-Express)'  (string) linux.sysfs_path =
'/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0'  (strin g)
  info.parent = '/org/freedesktop/Hal/devices/pci_10de_ac6'  (string)
  info.linux.driver = 'ath9k'  (string)
  pci.subsys_vendor = 'Hewlett-Packard Company'  (string)
  linux.hotplug_type = 2  (0x2)  (int)
  linux.subsystem = 'pci'  (string)
  info.subsystem = 'pci'  (string)
  info.product = 'AR9285 Wireless Network Adapter
(PCI-Express)'  (string) info.udi =
'/org/freedesktop/Hal/devices/pci_168c_2b'  (string)
pci.linux.sysfs_path =
'/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0'  (string)
pci.product_id = 43  (0x2b)  (int) pci.vendor_id = 5772  (0x168c)
(int) pci.subsys_product_id = 12352  (0x3040)  (int)
pci.subsys_vendor_id = 4156  (0x103c)  (int) pci.device_class = 2
(0x2)  (int) pci.device_subclass = 128  (0x80)  (int)

I haven't tried looking in logs because the crashes are so severe I
don't think they'd be able to record anything useful. But using git
bisect I think I have tracked down the change that started causing this
problem:

53bc7aa08b48e5cd745f986731cc7dc24eef2a9f is the first bad commit
commit 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
Author: Vivek Natarajan <vnatarajan@atheros.com>
Date:   Mon Apr 5 14:48:04 2010 +0530

    ath9k: Add support for newer AR9285 chipsets.
    
    This patch adds support for a modified newer version of AR9285
    chipsets.
    
    Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

:040000 040000 2ceb3a80ec957f3304308169c4ab9e5356622a95
14b6922350867c88d7ba6823408a9ce9aa15ddf5 M	drivers

git bisect start
# good: [66f41d4c5c8a5deed66fdcc84509376c9a0bf9d8] Linux 2.6.34-rc6
git bisect good 66f41d4c5c8a5deed66fdcc84509376c9a0bf9d8
# bad: [9fe6206f400646a2322096b56c59891d530e8d51] Linux 2.6.35
git bisect bad 9fe6206f400646a2322096b56c59891d530e8d51
# bad: [c316ba3b518bc35ce5aef5421135220389f4eb98] Merge branch
'linux-next' of git://git.infradead.org/ubi-2.6 git bisect bad
c316ba3b518bc35ce5aef5421135220389f4eb98 # good:
[fb091be08d1acf184e8801dfdcace6e0cb19b1fe] Merge branch
'v4l_for_2.6.35' of
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6 git
bisect good fb091be08d1acf184e8801dfdcace6e0cb19b1fe # bad:
[b56f2d55c6c22b0c5774b3b22e336fb6cc5f4094] netfilter: use
rcu_dereference_protected() git bisect bad
b56f2d55c6c22b0c5774b3b22e336fb6cc5f4094 # bad:
[adfba3c7c026a6a5560d2a43fefc9b198cb74462] mac80211: use fixed channel
in ibss join when appropriate git bisect bad
adfba3c7c026a6a5560d2a43fefc9b198cb74462 # bad:
[1968cc78d91c79857089713bf3f3cceb5e9c63ae] ath5k: correct channel
setting for 2.5 mhz spacing git bisect bad
1968cc78d91c79857089713bf3f3cceb5e9c63ae # good:
[56b632e8cc7a13cece861d890deb2843116f9372] drivers/net: Remove local
#define IW_IOCTL, use IW_HANDLER git bisect good
56b632e8cc7a13cece861d890deb2843116f9372 # good:
[ecdf94b81237d272b1514b76f27a5d22782bcaa6] iwlwifi: remove
skb_linearize for rx frames git bisect good
ecdf94b81237d272b1514b76f27a5d22782bcaa6 # skip:
[c81494d548d0735f13c04dd2c336cde470d1a5ae] ath9k: rename symbols in
enum ath9k_internal_frame_type to avoid confusion git bisect skip
c81494d548d0735f13c04dd2c336cde470d1a5ae # skip:
[f9ea3eb44218b0e12a190f222400f8d56136915f] include/net/iw_handler.h:
Use SIOCIWFIRST not SIOCSIWCOMMIT in comment git bisect skip
f9ea3eb44218b0e12a190f222400f8d56136915f # skip:
[152d530d9edbb08424dc1b6561252597a7932c49] ath9k: remove ah->mask_reg,
it's never used properly git bisect skip
152d530d9edbb08424dc1b6561252597a7932c49 # skip:
[879999cec9489f8942ebce3ec1b5f23ef948dda7] ar9170usb: fix panic
triggered by undersized rxstream buffer git bisect skip
879999cec9489f8942ebce3ec1b5f23ef948dda7 # skip:
[b409894f9d6961bd5feffb86ba1d8dbbebfb5b72] ath: fix coding
style/readability in ath/ar9170 git bisect skip
b409894f9d6961bd5feffb86ba1d8dbbebfb5b72 # skip:
[9fd1ea428590cf6e35e5a7df32ff6bccfd371db2] wireless/ipw2x00: remove
trailing space in messages git bisect skip
9fd1ea428590cf6e35e5a7df32ff6bccfd371db2 # skip:
[3069168c82d65f88e4ac76eda09baff02adfd743] ath9k: move imask from sc to
ah git bisect skip 3069168c82d65f88e4ac76eda09baff02adfd743 # good:
[7590a550b88b8c3cb025f0a8ed58e279ad62e4c1] wl1251: use DRIVER_NAME
macro in wl1251_spi_driver git bisect good
7590a550b88b8c3cb025f0a8ed58e279ad62e4c1 # bad:
[0f2df9eac70423838a1f8d410fd3899ddd88317b] Merge branch 'master' of
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
into merge git bisect bad 0f2df9eac70423838a1f8d410fd3899ddd88317b #
bad: [2b43ae6daf26f29cec49fa3a3f18025355495500] mac80211: remove irq
disabling for sta lock git bisect bad
2b43ae6daf26f29cec49fa3a3f18025355495500 # bad:
[bde748a40d4d5a9915def6772e208848c105e616] ath9k_htc: Add support for
power save. git bisect bad bde748a40d4d5a9915def6772e208848c105e616 #
bad: [53bc7aa08b48e5cd745f986731cc7dc24eef2a9f] ath9k: Add support for
newer AR9285 chipsets. git bisect bad
53bc7aa08b48e5cd745f986731cc7dc24eef2a9f # good:
[d5cdfacb35ed886271d1ccfffbded98d3447da17] cfg80211: Add
local-state-change-only auth/deauth/disassoc git bisect good
d5cdfacb35ed886271d1ccfffbded98d3447da17

Re: ath9k causes lockups since kernel 2.6.35

[Jonathan Nieder]

(just cc-ing some people listed in MAINTAINERS)
Hi,

Tony Houghton wrote:

> With 2.6.37 I can not use suspend on my Compaq/HP 311c (Intel Atom
> N270/NVidia Ion LE). Originally the machine just kept locking up without
> even blanking the display when I tried to suspend (using the GNOME menu
> or by shutting the lid). I upgraded upower and gnome-power-manager etc
> to experimental and after that the machine suspended OK but could not
> resume. The backlight came on but the screen stayed blank and I could
> not get to a console or anything with Alt+Fn.
[...]
> I tried replacing network-manager with wicd but that crashed the system
> when it connected instead of when disconnected.
[...]
> While testing different kernels I found it would crash at different
> times, usually before the screen turned off for suspending, but
> sometimes it would crash on resuming and occasionally it locked up while
> booting, but it's always a complete lock-up ie the keyboard is
> completely responsive, including caps lock, the mouse won't move if the
> display is still on, and the only way out is to hold down the power
> button.
[...]
> I haven't tried looking in logs because the crashes are so severe I
> don't think they'd be able to record anything useful. But using git
> bisect I think I have tracked down the change that started causing this
> problem:
>
> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f is the first bad commit
> commit 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
> Author: Vivek Natarajan <vnatarajan@atheros.com>
> Date:   Mon Apr 5 14:48:04 2010 +0530
> 
>     ath9k: Add support for newer AR9285 chipsets.
>     
>     This patch adds support for a modified newer version of AR9285
>     chipsets.
>     
>     Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
>     Signed-off-by: John W. Linville <linville@tuxdriver.com>

The adaptor is an AR9285[1].

That commit is based against v2.6.33 and was merged in v2.6.35-rc1

$ git describe 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
v2.6.33-3523-g53bc7aa
$ git name-rev --tags 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
53bc7aa08b48e5cd745f986731cc7dc24eef2a9f tags/v2.6.35-rc1~473^2~167^2~346

Any ideas for tracking this down?

Thanks,
Jonathan

[1]
> 84: udi = '/org/freedesktop/Hal/devices/pci_168c_2b'
>   pci.device_protocol = 0  (0x0)  (int)
>   pci.vendor = 'Atheros Communications Inc.'  (string)
>   info.vendor = 'Atheros Communications Inc.'  (string)
>   pci.product = 'AR9285 Wireless Network Adapter
> (PCI-Express)'  (string) linux.sysfs_path =
> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0'  (strin g)
>   info.parent = '/org/freedesktop/Hal/devices/pci_10de_ac6'  (string)
>   info.linux.driver = 'ath9k'  (string)
>   pci.subsys_vendor = 'Hewlett-Packard Company'  (string)
>   linux.hotplug_type = 2  (0x2)  (int)
>   linux.subsystem = 'pci'  (string)
>   info.subsystem = 'pci'  (string)
>   info.product = 'AR9285 Wireless Network Adapter
> (PCI-Express)'  (string) info.udi =
> '/org/freedesktop/Hal/devices/pci_168c_2b'  (string)
> pci.linux.sysfs_path =
> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0'  (string)
> pci.product_id = 43  (0x2b)  (int) pci.vendor_id = 5772  (0x168c)
> (int) pci.subsys_product_id = 12352  (0x3040)  (int)
> pci.subsys_vendor_id = 4156  (0x103c)  (int) pci.device_class = 2
> (0x2)  (int) pci.device_subclass = 128  (0x80)  (int)

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Jonathan Nieder]

(just cc-ing some people listed in MAINTAINERS)
Hi,

Tony Houghton wrote:

> With 2.6.37 I can not use suspend on my Compaq/HP 311c (Intel Atom
> N270/NVidia Ion LE). Originally the machine just kept locking up without
> even blanking the display when I tried to suspend (using the GNOME menu
> or by shutting the lid). I upgraded upower and gnome-power-manager etc
> to experimental and after that the machine suspended OK but could not
> resume. The backlight came on but the screen stayed blank and I could
> not get to a console or anything with Alt+Fn.
[...]
> I tried replacing network-manager with wicd but that crashed the system
> when it connected instead of when disconnected.
[...]
> While testing different kernels I found it would crash at different
> times, usually before the screen turned off for suspending, but
> sometimes it would crash on resuming and occasionally it locked up while
> booting, but it's always a complete lock-up ie the keyboard is
> completely responsive, including caps lock, the mouse won't move if the
> display is still on, and the only way out is to hold down the power
> button.
[...]
> I haven't tried looking in logs because the crashes are so severe I
> don't think they'd be able to record anything useful. But using git
> bisect I think I have tracked down the change that started causing this
> problem:
>
> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f is the first bad commit
> commit 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
> Author: Vivek Natarajan <vnatarajan@atheros.com>
> Date:   Mon Apr 5 14:48:04 2010 +0530
> 
>     ath9k: Add support for newer AR9285 chipsets.
>     
>     This patch adds support for a modified newer version of AR9285
>     chipsets.
>     
>     Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
>     Signed-off-by: John W. Linville <linville@tuxdriver.com>

The adaptor is an AR9285[1].

That commit is based against v2.6.33 and was merged in v2.6.35-rc1

$ git describe 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
v2.6.33-3523-g53bc7aa
$ git name-rev --tags 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
53bc7aa08b48e5cd745f986731cc7dc24eef2a9f tags/v2.6.35-rc1~473^2~167^2~346

Any ideas for tracking this down?

Thanks,
Jonathan

[1]
> 84: udi = '/org/freedesktop/Hal/devices/pci_168c_2b'
>   pci.device_protocol = 0  (0x0)  (int)
>   pci.vendor = 'Atheros Communications Inc.'  (string)
>   info.vendor = 'Atheros Communications Inc.'  (string)
>   pci.product = 'AR9285 Wireless Network Adapter
> (PCI-Express)'  (string) linux.sysfs_path =
> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0'  (strin g)
>   info.parent = '/org/freedesktop/Hal/devices/pci_10de_ac6'  (string)
>   info.linux.driver = 'ath9k'  (string)
>   pci.subsys_vendor = 'Hewlett-Packard Company'  (string)
>   linux.hotplug_type = 2  (0x2)  (int)
>   linux.subsystem = 'pci'  (string)
>   info.subsystem = 'pci'  (string)
>   info.product = 'AR9285 Wireless Network Adapter
> (PCI-Express)'  (string) info.udi =
> '/org/freedesktop/Hal/devices/pci_168c_2b'  (string)
> pci.linux.sysfs_path =
> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0'  (string)
> pci.product_id = 43  (0x2b)  (int) pci.vendor_id = 5772  (0x168c)
> (int) pci.subsys_product_id = 12352  (0x3040)  (int)
> pci.subsys_vendor_id = 4156  (0x103c)  (int) pci.device_class = 2
> (0x2)  (int) pci.device_subclass = 128  (0x80)  (int)

Re: [ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Fri, Feb 25, 2011 at 1:32 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> (just cc-ing some people listed in MAINTAINERS)
> Hi,
>
> Tony Houghton wrote:
>
>> With 2.6.37 I can not use suspend on my Compaq/HP 311c (Intel Atom
>> N270/NVidia Ion LE). Originally the machine just kept locking up without
>> even blanking the display when I tried to suspend (using the GNOME menu
>> or by shutting the lid). I upgraded upower and gnome-power-manager etc
>> to experimental and after that the machine suspended OK but could not
>> resume. The backlight came on but the screen stayed blank and I could
>> not get to a console or anything with Alt+Fn.
> [...]
>> I tried replacing network-manager with wicd but that crashed the system
>> when it connected instead of when disconnected.
> [...]
>> While testing different kernels I found it would crash at different
>> times, usually before the screen turned off for suspending, but
>> sometimes it would crash on resuming and occasionally it locked up while
>> booting, but it's always a complete lock-up ie the keyboard is
>> completely responsive, including caps lock, the mouse won't move if the
>> display is still on, and the only way out is to hold down the power
>> button.
> [...]
>> I haven't tried looking in logs because the crashes are so severe I
>> don't think they'd be able to record anything useful. But using git
>> bisect I think I have tracked down the change that started causing this
>> problem:
>>
>> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f is the first bad commit
>> commit 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
>> Author: Vivek Natarajan <vnatarajan@atheros.com>
>> Date:   Mon Apr 5 14:48:04 2010 +0530
>>
>>     ath9k: Add support for newer AR9285 chipsets.
>>
>>     This patch adds support for a modified newer version of AR9285
>>     chipsets.
>>
>>     Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
>>     Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> The adaptor is an AR9285[1].
>
> That commit is based against v2.6.33 and was merged in v2.6.35-rc1
>
> $ git describe 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
> v2.6.33-3523-g53bc7aa
> $ git name-rev --tags 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f tags/v2.6.35-rc1~473^2~167^2~346
>
> Any ideas for tracking this down?

is this issue still reproducible ?
Apart from this reporting I have not seen any other  issues for AR9285.

>
> Thanks,
> Jonathan
>
> [1]
>> 84: udi = '/org/freedesktop/Hal/devices/pci_168c_2b'
>>   pci.device_protocol = 0  (0x0)  (int)
>>   pci.vendor = 'Atheros Communications Inc.'  (string)
>>   info.vendor = 'Atheros Communications Inc.'  (string)
>>   pci.product = 'AR9285 Wireless Network Adapter
>> (PCI-Express)'  (string) linux.sysfs_path =
>> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0'  (strin g)
>>   info.parent = '/org/freedesktop/Hal/devices/pci_10de_ac6'  (string)
>>   info.linux.driver = 'ath9k'  (string)
>>   pci.subsys_vendor = 'Hewlett-Packard Company'  (string)
>>   linux.hotplug_type = 2  (0x2)  (int)
>>   linux.subsystem = 'pci'  (string)
>>   info.subsystem = 'pci'  (string)
>>   info.product = 'AR9285 Wireless Network Adapter
>> (PCI-Express)'  (string) info.udi =
>> '/org/freedesktop/Hal/devices/pci_168c_2b'  (string)
>> pci.linux.sysfs_path =
>> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0'  (string)
>> pci.product_id = 43  (0x2b)  (int) pci.vendor_id = 5772  (0x168c)
>> (int) pci.subsys_product_id = 12352  (0x3040)  (int)
>> pci.subsys_vendor_id = 4156  (0x103c)  (int) pci.device_class = 2
>> (0x2)  (int) pci.device_subclass = 128  (0x80)  (int)
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Fri, Feb 25, 2011 at 1:32 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> (just cc-ing some people listed in MAINTAINERS)
> Hi,
>
> Tony Houghton wrote:
>
>> With 2.6.37 I can not use suspend on my Compaq/HP 311c (Intel Atom
>> N270/NVidia Ion LE). Originally the machine just kept locking up without
>> even blanking the display when I tried to suspend (using the GNOME menu
>> or by shutting the lid). I upgraded upower and gnome-power-manager etc
>> to experimental and after that the machine suspended OK but could not
>> resume. The backlight came on but the screen stayed blank and I could
>> not get to a console or anything with Alt+Fn.
> [...]
>> I tried replacing network-manager with wicd but that crashed the system
>> when it connected instead of when disconnected.
> [...]
>> While testing different kernels I found it would crash at different
>> times, usually before the screen turned off for suspending, but
>> sometimes it would crash on resuming and occasionally it locked up while
>> booting, but it's always a complete lock-up ie the keyboard is
>> completely responsive, including caps lock, the mouse won't move if the
>> display is still on, and the only way out is to hold down the power
>> button.
> [...]
>> I haven't tried looking in logs because the crashes are so severe I
>> don't think they'd be able to record anything useful. But using git
>> bisect I think I have tracked down the change that started causing this
>> problem:
>>
>> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f is the first bad commit
>> commit 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
>> Author: Vivek Natarajan <vnatarajan@atheros.com>
>> Date: ? Mon Apr 5 14:48:04 2010 +0530
>>
>> ? ? ath9k: Add support for newer AR9285 chipsets.
>>
>> ? ? This patch adds support for a modified newer version of AR9285
>> ? ? chipsets.
>>
>> ? ? Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
>> ? ? Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> The adaptor is an AR9285[1].
>
> That commit is based against v2.6.33 and was merged in v2.6.35-rc1
>
> $ git describe 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
> v2.6.33-3523-g53bc7aa
> $ git name-rev --tags 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f tags/v2.6.35-rc1~473^2~167^2~346
>
> Any ideas for tracking this down?

is this issue still reproducible ?
Apart from this reporting I have not seen any other  issues for AR9285.

>
> Thanks,
> Jonathan
>
> [1]
>> 84: udi = '/org/freedesktop/Hal/devices/pci_168c_2b'
>> ? pci.device_protocol = 0 ?(0x0) ?(int)
>> ? pci.vendor = 'Atheros Communications Inc.' ?(string)
>> ? info.vendor = 'Atheros Communications Inc.' ?(string)
>> ? pci.product = 'AR9285 Wireless Network Adapter
>> (PCI-Express)' ?(string) linux.sysfs_path =
>> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0' ?(strin g)
>> ? info.parent = '/org/freedesktop/Hal/devices/pci_10de_ac6' ?(string)
>> ? info.linux.driver = 'ath9k' ?(string)
>> ? pci.subsys_vendor = 'Hewlett-Packard Company' ?(string)
>> ? linux.hotplug_type = 2 ?(0x2) ?(int)
>> ? linux.subsystem = 'pci' ?(string)
>> ? info.subsystem = 'pci' ?(string)
>> ? info.product = 'AR9285 Wireless Network Adapter
>> (PCI-Express)' ?(string) info.udi =
>> '/org/freedesktop/Hal/devices/pci_168c_2b' ?(string)
>> pci.linux.sysfs_path =
>> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0' ?(string)
>> pci.product_id = 43 ?(0x2b) ?(int) pci.vendor_id = 5772 ?(0x168c)
>> (int) pci.subsys_product_id = 12352 ?(0x3040) ?(int)
>> pci.subsys_vendor_id = 4156 ?(0x103c) ?(int) pci.device_class = 2
>> (0x2) ?(int) pci.device_subclass = 128 ?(0x80) ?(int)
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

Re: ath9k causes lockups since kernel 2.6.35

[Sedat Dilek]

Just FYI:

(As I know you are on Debian...)
Debian/experimental provides now 2.6.38-rc6 kernel packages, might be
worth a test?

- Sedat -

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Sedat Dilek]

Just FYI:

(As I know you are on Debian...)
Debian/experimental provides now 2.6.38-rc6 kernel packages, might be
worth a test?

- Sedat -

Re: [ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Fri, Feb 25, 2011 at 1:21 PM, Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
> On Fri, Feb 25, 2011 at 1:32 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> (just cc-ing some people listed in MAINTAINERS)
>> Hi,
>>
>> Tony Houghton wrote:
>>
>>> With 2.6.37 I can not use suspend on my Compaq/HP 311c (Intel Atom
>>> N270/NVidia Ion LE). Originally the machine just kept locking up without
>>> even blanking the display when I tried to suspend (using the GNOME menu
>>> or by shutting the lid). I upgraded upower and gnome-power-manager etc
>>> to experimental and after that the machine suspended OK but could not
>>> resume. The backlight came on but the screen stayed blank and I could
>>> not get to a console or anything with Alt+Fn.
>> [...]
>>> I tried replacing network-manager with wicd but that crashed the system
>>> when it connected instead of when disconnected.
>> [...]
>>> While testing different kernels I found it would crash at different
>>> times, usually before the screen turned off for suspending, but
>>> sometimes it would crash on resuming and occasionally it locked up while
>>> booting, but it's always a complete lock-up ie the keyboard is
>>> completely responsive, including caps lock, the mouse won't move if the
>>> display is still on, and the only way out is to hold down the power
>>> button.
>> [...]
>>> I haven't tried looking in logs because the crashes are so severe I
>>> don't think they'd be able to record anything useful. But using git
>>> bisect I think I have tracked down the change that started causing this
>>> problem:
>>>
>>> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f is the first bad commit
>>> commit 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
>>> Author: Vivek Natarajan <vnatarajan@atheros.com>
>>> Date:   Mon Apr 5 14:48:04 2010 +0530
>>>
>>>     ath9k: Add support for newer AR9285 chipsets.
>>>
>>>     This patch adds support for a modified newer version of AR9285
>>>     chipsets.
>>>
>>>     Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
>>>     Signed-off-by: John W. Linville <linville@tuxdriver.com>
>>
>> The adaptor is an AR9285[1].
>>
>> That commit is based against v2.6.33 and was merged in v2.6.35-rc1
>>
>> $ git describe 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
>> v2.6.33-3523-g53bc7aa
>> $ git name-rev --tags 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
>> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f tags/v2.6.35-rc1~473^2~167^2~346
>>
>> Any ideas for tracking this down?
>
> is this issue still reproducible ?
> Apart from this reporting I have not seen any other  issues for AR9285.

sorry just now saw's Tonys message in linux wireless mailing list
>
>>
>> Thanks,
>> Jonathan
>>
>> [1]
>>> 84: udi = '/org/freedesktop/Hal/devices/pci_168c_2b'
>>>   pci.device_protocol = 0  (0x0)  (int)
>>>   pci.vendor = 'Atheros Communications Inc.'  (string)
>>>   info.vendor = 'Atheros Communications Inc.'  (string)
>>>   pci.product = 'AR9285 Wireless Network Adapter
>>> (PCI-Express)'  (string) linux.sysfs_path =
>>> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0'  (strin g)
>>>   info.parent = '/org/freedesktop/Hal/devices/pci_10de_ac6'  (string)
>>>   info.linux.driver = 'ath9k'  (string)
>>>   pci.subsys_vendor = 'Hewlett-Packard Company'  (string)
>>>   linux.hotplug_type = 2  (0x2)  (int)
>>>   linux.subsystem = 'pci'  (string)
>>>   info.subsystem = 'pci'  (string)
>>>   info.product = 'AR9285 Wireless Network Adapter
>>> (PCI-Express)'  (string) info.udi =
>>> '/org/freedesktop/Hal/devices/pci_168c_2b'  (string)
>>> pci.linux.sysfs_path =
>>> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0'  (string)
>>> pci.product_id = 43  (0x2b)  (int) pci.vendor_id = 5772  (0x168c)
>>> (int) pci.subsys_product_id = 12352  (0x3040)  (int)
>>> pci.subsys_vendor_id = 4156  (0x103c)  (int) pci.device_class = 2
>>> (0x2)  (int) pci.device_subclass = 128  (0x80)  (int)
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel@lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Fri, Feb 25, 2011 at 1:21 PM, Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
> On Fri, Feb 25, 2011 at 1:32 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> (just cc-ing some people listed in MAINTAINERS)
>> Hi,
>>
>> Tony Houghton wrote:
>>
>>> With 2.6.37 I can not use suspend on my Compaq/HP 311c (Intel Atom
>>> N270/NVidia Ion LE). Originally the machine just kept locking up without
>>> even blanking the display when I tried to suspend (using the GNOME menu
>>> or by shutting the lid). I upgraded upower and gnome-power-manager etc
>>> to experimental and after that the machine suspended OK but could not
>>> resume. The backlight came on but the screen stayed blank and I could
>>> not get to a console or anything with Alt+Fn.
>> [...]
>>> I tried replacing network-manager with wicd but that crashed the system
>>> when it connected instead of when disconnected.
>> [...]
>>> While testing different kernels I found it would crash at different
>>> times, usually before the screen turned off for suspending, but
>>> sometimes it would crash on resuming and occasionally it locked up while
>>> booting, but it's always a complete lock-up ie the keyboard is
>>> completely responsive, including caps lock, the mouse won't move if the
>>> display is still on, and the only way out is to hold down the power
>>> button.
>> [...]
>>> I haven't tried looking in logs because the crashes are so severe I
>>> don't think they'd be able to record anything useful. But using git
>>> bisect I think I have tracked down the change that started causing this
>>> problem:
>>>
>>> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f is the first bad commit
>>> commit 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
>>> Author: Vivek Natarajan <vnatarajan@atheros.com>
>>> Date: ? Mon Apr 5 14:48:04 2010 +0530
>>>
>>> ? ? ath9k: Add support for newer AR9285 chipsets.
>>>
>>> ? ? This patch adds support for a modified newer version of AR9285
>>> ? ? chipsets.
>>>
>>> ? ? Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
>>> ? ? Signed-off-by: John W. Linville <linville@tuxdriver.com>
>>
>> The adaptor is an AR9285[1].
>>
>> That commit is based against v2.6.33 and was merged in v2.6.35-rc1
>>
>> $ git describe 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
>> v2.6.33-3523-g53bc7aa
>> $ git name-rev --tags 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
>> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f tags/v2.6.35-rc1~473^2~167^2~346
>>
>> Any ideas for tracking this down?
>
> is this issue still reproducible ?
> Apart from this reporting I have not seen any other ?issues for AR9285.

sorry just now saw's Tonys message in linux wireless mailing list
>
>>
>> Thanks,
>> Jonathan
>>
>> [1]
>>> 84: udi = '/org/freedesktop/Hal/devices/pci_168c_2b'
>>> ? pci.device_protocol = 0 ?(0x0) ?(int)
>>> ? pci.vendor = 'Atheros Communications Inc.' ?(string)
>>> ? info.vendor = 'Atheros Communications Inc.' ?(string)
>>> ? pci.product = 'AR9285 Wireless Network Adapter
>>> (PCI-Express)' ?(string) linux.sysfs_path =
>>> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0' ?(strin g)
>>> ? info.parent = '/org/freedesktop/Hal/devices/pci_10de_ac6' ?(string)
>>> ? info.linux.driver = 'ath9k' ?(string)
>>> ? pci.subsys_vendor = 'Hewlett-Packard Company' ?(string)
>>> ? linux.hotplug_type = 2 ?(0x2) ?(int)
>>> ? linux.subsystem = 'pci' ?(string)
>>> ? info.subsystem = 'pci' ?(string)
>>> ? info.product = 'AR9285 Wireless Network Adapter
>>> (PCI-Express)' ?(string) info.udi =
>>> '/org/freedesktop/Hal/devices/pci_168c_2b' ?(string)
>>> pci.linux.sysfs_path =
>>> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0' ?(string)
>>> pci.product_id = 43 ?(0x2b) ?(int) pci.vendor_id = 5772 ?(0x168c)
>>> (int) pci.subsys_product_id = 12352 ?(0x3040) ?(int)
>>> pci.subsys_vendor_id = 4156 ?(0x103c) ?(int) pci.device_class = 2
>>> (0x2) ?(int) pci.device_subclass = 128 ?(0x80) ?(int)
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>

Re: ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Fri, 25 Feb 2011 08:57:11 +0100
Sedat Dilek <sedat.dilek@googlemail.com> wrote:

> Debian/experimental provides now 2.6.38-rc6 kernel packages, might be
> worth a test?

I just tried that and at first it looked as if it might be working,
because it successfully disabled and reenabled wireless (via
network-manager). But when I tried suspend it crashed on resuming. IIRC
I also tried the newest tagged version from git and that was a fail too.

FWIW this last crash was on battery power, but most of the time I've
been plugged in to the mains. I saw some commit messages about
power-saving mode but it didn't occur to me that battery/mains might
make a difference and it looks like it doesn't.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Fri, 25 Feb 2011 08:57:11 +0100
Sedat Dilek <sedat.dilek@googlemail.com> wrote:

> Debian/experimental provides now 2.6.38-rc6 kernel packages, might be
> worth a test?

I just tried that and at first it looked as if it might be working,
because it successfully disabled and reenabled wireless (via
network-manager). But when I tried suspend it crashed on resuming. IIRC
I also tried the newest tagged version from git and that was a fail too.

FWIW this last crash was on battery power, but most of the time I've
been plugged in to the mains. I saw some commit messages about
power-saving mode but it didn't occur to me that battery/mains might
make a difference and it looks like it doesn't.

Re: [ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Fri, 25 Feb 2011 13:21:32 +0530
Mohammed Shafi <shafi.ath9k@gmail.com> wrote:

> > Tony Houghton wrote:
> >
> >> With 2.6.37 I can not use suspend on my Compaq/HP 311c (Intel Atom
> >> N270/NVidia Ion LE). Originally the machine just kept locking up without
> >> even blanking the display when I tried to suspend (using the GNOME menu
> >> or by shutting the lid).

[Snip]

The above was from my original message before I worked out that the
problem was in the wireless because disabling and reneabling wireless,
killing the ath9k module etc, would often produce similar crashes, but
suspend seems to do it more consistently.

> >> booting, but it's always a complete lock-up ie the keyboard is
> >> completely responsive, including caps lock, the mouse won't move if the

I meant *un*responsive of course!

> >> I haven't tried looking in logs because the crashes are so severe I
> >> don't think they'd be able to record anything useful.

If I enable debugging is there a way to get it to sync to disc after
every message? I think the developers are going to need at least that
information to be able to track this down.

> is this issue still reproducible ?

Yes :-(.

> Apart from this reporting I have not seen any other  issues for AR9285.

Strange, isn't it. I can't be the only person trying to use a recent
version of Linux on one of these netbooks, but I couldn't find any
similar complaints on Google. Maybe mine has an obscure fault which is
only triggered by a feature supported in the newer kernels.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Fri, 25 Feb 2011 13:21:32 +0530
Mohammed Shafi <shafi.ath9k@gmail.com> wrote:

> > Tony Houghton wrote:
> >
> >> With 2.6.37 I can not use suspend on my Compaq/HP 311c (Intel Atom
> >> N270/NVidia Ion LE). Originally the machine just kept locking up without
> >> even blanking the display when I tried to suspend (using the GNOME menu
> >> or by shutting the lid).

[Snip]

The above was from my original message before I worked out that the
problem was in the wireless because disabling and reneabling wireless,
killing the ath9k module etc, would often produce similar crashes, but
suspend seems to do it more consistently.

> >> booting, but it's always a complete lock-up ie the keyboard is
> >> completely responsive, including caps lock, the mouse won't move if the

I meant *un*responsive of course!

> >> I haven't tried looking in logs because the crashes are so severe I
> >> don't think they'd be able to record anything useful.

If I enable debugging is there a way to get it to sync to disc after
every message? I think the developers are going to need at least that
information to be able to track this down.

> is this issue still reproducible ?

Yes :-(.

> Apart from this reporting I have not seen any other  issues for AR9285.

Strange, isn't it. I can't be the only person trying to use a recent
version of Linux on one of these netbooks, but I couldn't find any
similar complaints on Google. Maybe mine has an obscure fault which is
only triggered by a feature supported in the newer kernels.

Re: [ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Fri, Feb 25, 2011 at 8:17 PM, Tony Houghton <h@realh.co.uk> wrote:
> On Fri, 25 Feb 2011 13:21:32 +0530
> Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
>
>> > Tony Houghton wrote:
>> >
>> >> With 2.6.37 I can not use suspend on my Compaq/HP 311c (Intel Atom
>> >> N270/NVidia Ion LE). Originally the machine just kept locking up without
>> >> even blanking the display when I tried to suspend (using the GNOME menu
>> >> or by shutting the lid).
>
> [Snip]
>
> The above was from my original message before I worked out that the
> problem was in the wireless because disabling and reneabling wireless,
> killing the ath9k module etc, would often produce similar crashes, but
> suspend seems to do it more consistently.

Ok.

>
>> >> booting, but it's always a complete lock-up ie the keyboard is
>> >> completely responsive, including caps lock, the mouse won't move if the
>
> I meant *un*responsive of course!
>
>> >> I haven't tried looking in logs because the crashes are so severe I
>> >> don't think they'd be able to record anything useful.

Can you please get those messages with net console ?

>
> If I enable debugging is there a way to get it to sync to disc after
> every message? I think the developers are going to need at least that
> information to be able to track this down.

Yes sure, that could narrow down the issue.

>
>> is this issue still reproducible ?
>
> Yes :-(.

It would be highly helpful if this issue is reproducible in the latest
wireless testing or compat wireless. It will help us to fix it cleanly

>
>> Apart from this reporting I have not seen any other  issues for AR9285.
>
> Strange, isn't it. I can't be the only person trying to use a recent
> version of Linux on one of these netbooks, but I couldn't find any
> similar complaints on Google. Maybe mine has an obscure fault which is
> only triggered by a feature supported in the newer kernels.
>

also need to rule out its a platform independent issue.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Fri, Feb 25, 2011 at 8:17 PM, Tony Houghton <h@realh.co.uk> wrote:
> On Fri, 25 Feb 2011 13:21:32 +0530
> Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
>
>> > Tony Houghton wrote:
>> >
>> >> With 2.6.37 I can not use suspend on my Compaq/HP 311c (Intel Atom
>> >> N270/NVidia Ion LE). Originally the machine just kept locking up without
>> >> even blanking the display when I tried to suspend (using the GNOME menu
>> >> or by shutting the lid).
>
> [Snip]
>
> The above was from my original message before I worked out that the
> problem was in the wireless because disabling and reneabling wireless,
> killing the ath9k module etc, would often produce similar crashes, but
> suspend seems to do it more consistently.

Ok.

>
>> >> booting, but it's always a complete lock-up ie the keyboard is
>> >> completely responsive, including caps lock, the mouse won't move if the
>
> I meant *un*responsive of course!
>
>> >> I haven't tried looking in logs because the crashes are so severe I
>> >> don't think they'd be able to record anything useful.

Can you please get those messages with net console ?

>
> If I enable debugging is there a way to get it to sync to disc after
> every message? I think the developers are going to need at least that
> information to be able to track this down.

Yes sure, that could narrow down the issue.

>
>> is this issue still reproducible ?
>
> Yes :-(.

It would be highly helpful if this issue is reproducible in the latest
wireless testing or compat wireless. It will help us to fix it cleanly

>
>> Apart from this reporting I have not seen any other ?issues for AR9285.
>
> Strange, isn't it. I can't be the only person trying to use a recent
> version of Linux on one of these netbooks, but I couldn't find any
> similar complaints on Google. Maybe mine has an obscure fault which is
> only triggered by a feature supported in the newer kernels.
>

also need to rule out its a platform independent issue.

Re: [ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Fri, 25 Feb 2011 21:37:25 +0530
Mohammed Shafi <shafi.ath9k@gmail.com> wrote:

> On Fri, Feb 25, 2011 at 8:17 PM, Tony Houghton <h@realh.co.uk> wrote:
> >
> >> >> I haven't tried looking in logs because the crashes are so severe I
> >> >> don't think they'd be able to record anything useful.
> 
> Can you please get those messages with net console ?
> 
> > If I enable debugging is there a way to get it to sync to disc after
> > every message? I think the developers are going to need at least that
> > information to be able to track this down.
> 
> Yes sure, that could narrow down the issue.

I'll try that first because it should be easier than setting up net
console.

> >> is this issue still reproducible ?
> >
> > Yes :-(.
> 
> It would be highly helpful if this issue is reproducible in the latest
> wireless testing or compat wireless. It will help us to fix it cleanly

I think I'll need to rebuild anyway to enable ath9k debugging so I might
as well build whichever version would be most useful to developers. Is
there a particular branch I should pull from? If it's maintained
separately from the main kernel please give me instructions on how to
merge it or whatever, because I'm not very familiar with the kernel or
more advanced git usage.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Fri, 25 Feb 2011 21:37:25 +0530
Mohammed Shafi <shafi.ath9k@gmail.com> wrote:

> On Fri, Feb 25, 2011 at 8:17 PM, Tony Houghton <h@realh.co.uk> wrote:
> >
> >> >> I haven't tried looking in logs because the crashes are so severe I
> >> >> don't think they'd be able to record anything useful.
> 
> Can you please get those messages with net console ?
> 
> > If I enable debugging is there a way to get it to sync to disc after
> > every message? I think the developers are going to need at least that
> > information to be able to track this down.
> 
> Yes sure, that could narrow down the issue.

I'll try that first because it should be easier than setting up net
console.

> >> is this issue still reproducible ?
> >
> > Yes :-(.
> 
> It would be highly helpful if this issue is reproducible in the latest
> wireless testing or compat wireless. It will help us to fix it cleanly

I think I'll need to rebuild anyway to enable ath9k debugging so I might
as well build whichever version would be most useful to developers. Is
there a particular branch I should pull from? If it's maintained
separately from the main kernel please give me instructions on how to
merge it or whatever, because I'm not very familiar with the kernel or
more advanced git usage.

Re: [ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Fri, 25 Feb 2011 16:57:45 +0000
Tony Houghton <h@realh.co.uk> wrote:

> On Fri, 25 Feb 2011 21:37:25 +0530
> Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
> 
> > On Fri, Feb 25, 2011 at 8:17 PM, Tony Houghton <h@realh.co.uk> wrote:
> > >
> > >> >> I haven't tried looking in logs because the crashes are so severe I
> > >> >> don't think they'd be able to record anything useful.
> > 
> > Can you please get those messages with net console ?

No, I can't get it to work. I found a good guide at
<http://www.novell.com/communities/node/4753/netconsole-howto-send-kernel-boot-messages-over-ethernet>
and adapted it for Debian but absolutely no messages appear. I connected
it via Ethernet to another netbook which runs Ubuntu. On the Debian one
(the one with the problem I want to debug) I added to
/etc/network/interfaces:

auto eth0
iface eth0 inet static
    address 10.0.0.20
    netmask 255.255.255.0

and on Ubuntu:

auto eth0
iface eth0 inet static
    address 10.0.0.10
    netmask 255.255.255.0

On the Debian one I added netconsole to
/etc/modules and created /etc/modprobe.d/netconsole.conf containing:

options netconsole netconsole=4444@10.0.0.20/eth0,6666@10.0.0.10/00:1E:68:DD:DB:40

On the Ubuntu one I ran:

nc -l -u 6666

I've double-checked the addresses etc and verified that the link is up
and the netconsole module is loaded, but no messages appear.

> > > If I enable debugging is there a way to get it to sync to disc after
> > > every message? I think the developers are going to need at least that
> > > information to be able to track this down.
> > 
> > Yes sure, that could narrow down the issue.
> 
> I'll try that first because it should be easier than setting up net
> console.

I tried to reconfigure rsyslog to sync on each message but it didn't log
anything useful :-(.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Fri, 25 Feb 2011 16:57:45 +0000
Tony Houghton <h@realh.co.uk> wrote:

> On Fri, 25 Feb 2011 21:37:25 +0530
> Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
> 
> > On Fri, Feb 25, 2011 at 8:17 PM, Tony Houghton <h@realh.co.uk> wrote:
> > >
> > >> >> I haven't tried looking in logs because the crashes are so severe I
> > >> >> don't think they'd be able to record anything useful.
> > 
> > Can you please get those messages with net console ?

No, I can't get it to work. I found a good guide at
<http://www.novell.com/communities/node/4753/netconsole-howto-send-kernel-boot-messages-over-ethernet>
and adapted it for Debian but absolutely no messages appear. I connected
it via Ethernet to another netbook which runs Ubuntu. On the Debian one
(the one with the problem I want to debug) I added to
/etc/network/interfaces:

auto eth0
iface eth0 inet static
    address 10.0.0.20
    netmask 255.255.255.0

and on Ubuntu:

auto eth0
iface eth0 inet static
    address 10.0.0.10
    netmask 255.255.255.0

On the Debian one I added netconsole to
/etc/modules and created /etc/modprobe.d/netconsole.conf containing:

options netconsole netconsole=4444 at 10.0.0.20/eth0,6666 at 10.0.0.10/00:1E:68:DD:DB:40

On the Ubuntu one I ran:

nc -l -u 6666

I've double-checked the addresses etc and verified that the link is up
and the netconsole module is loaded, but no messages appear.

> > > If I enable debugging is there a way to get it to sync to disc after
> > > every message? I think the developers are going to need at least that
> > > information to be able to track this down.
> > 
> > Yes sure, that could narrow down the issue.
> 
> I'll try that first because it should be easier than setting up net
> console.

I tried to reconfigure rsyslog to sync on each message but it didn't log
anything useful :-(.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[crocket]

I think I have to postpone buying Dell New Inspirion Mini 1012 since
it contains AR9285 and ath9k will cause kernel panics with AR9285.

On Fri, Feb 25, 2011 at 5:02 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> (just cc-ing some people listed in MAINTAINERS)
> Hi,
>
> Tony Houghton wrote:
>
>> With 2.6.37 I can not use suspend on my Compaq/HP 311c (Intel Atom
>> N270/NVidia Ion LE). Originally the machine just kept locking up without
>> even blanking the display when I tried to suspend (using the GNOME menu
>> or by shutting the lid). I upgraded upower and gnome-power-manager etc
>> to experimental and after that the machine suspended OK but could not
>> resume. The backlight came on but the screen stayed blank and I could
>> not get to a console or anything with Alt+Fn.
> [...]
>> I tried replacing network-manager with wicd but that crashed the system
>> when it connected instead of when disconnected.
> [...]
>> While testing different kernels I found it would crash at different
>> times, usually before the screen turned off for suspending, but
>> sometimes it would crash on resuming and occasionally it locked up while
>> booting, but it's always a complete lock-up ie the keyboard is
>> completely responsive, including caps lock, the mouse won't move if the
>> display is still on, and the only way out is to hold down the power
>> button.
> [...]
>> I haven't tried looking in logs because the crashes are so severe I
>> don't think they'd be able to record anything useful. But using git
>> bisect I think I have tracked down the change that started causing this
>> problem:
>>
>> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f is the first bad commit
>> commit 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
>> Author: Vivek Natarajan <vnatarajan@atheros.com>
>> Date: ? Mon Apr 5 14:48:04 2010 +0530
>>
>> ? ? ath9k: Add support for newer AR9285 chipsets.
>>
>> ? ? This patch adds support for a modified newer version of AR9285
>> ? ? chipsets.
>>
>> ? ? Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
>> ? ? Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> The adaptor is an AR9285[1].
>
> That commit is based against v2.6.33 and was merged in v2.6.35-rc1
>
> $ git describe 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
> v2.6.33-3523-g53bc7aa
> $ git name-rev --tags 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f tags/v2.6.35-rc1~473^2~167^2~346
>
> Any ideas for tracking this down?
>
> Thanks,
> Jonathan
>
> [1]
>> 84: udi = '/org/freedesktop/Hal/devices/pci_168c_2b'
>> ? pci.device_protocol = 0 ?(0x0) ?(int)
>> ? pci.vendor = 'Atheros Communications Inc.' ?(string)
>> ? info.vendor = 'Atheros Communications Inc.' ?(string)
>> ? pci.product = 'AR9285 Wireless Network Adapter
>> (PCI-Express)' ?(string) linux.sysfs_path =
>> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0' ?(strin g)
>> ? info.parent = '/org/freedesktop/Hal/devices/pci_10de_ac6' ?(string)
>> ? info.linux.driver = 'ath9k' ?(string)
>> ? pci.subsys_vendor = 'Hewlett-Packard Company' ?(string)
>> ? linux.hotplug_type = 2 ?(0x2) ?(int)
>> ? linux.subsystem = 'pci' ?(string)
>> ? info.subsystem = 'pci' ?(string)
>> ? info.product = 'AR9285 Wireless Network Adapter
>> (PCI-Express)' ?(string) info.udi =
>> '/org/freedesktop/Hal/devices/pci_168c_2b' ?(string)
>> pci.linux.sysfs_path =
>> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0' ?(string)
>> pci.product_id = 43 ?(0x2b) ?(int) pci.vendor_id = 5772 ?(0x168c)
>> (int) pci.subsys_product_id = 12352 ?(0x3040) ?(int)
>> pci.subsys_vendor_id = 4156 ?(0x103c) ?(int) pci.device_class = 2
>> (0x2) ?(int) pci.device_subclass = 128 ?(0x80) ?(int)
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

Re: [ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Sun, Feb 27, 2011 at 12:05 AM, Tony Houghton <h@realh.co.uk> wrote:
> On Fri, 25 Feb 2011 16:57:45 +0000
> Tony Houghton <h@realh.co.uk> wrote:
>
>> On Fri, 25 Feb 2011 21:37:25 +0530
>> Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
>>
>> > On Fri, Feb 25, 2011 at 8:17 PM, Tony Houghton <h@realh.co.uk> wrote:
>> > >
>> > >> >> I haven't tried looking in logs because the crashes are so severe I
>> > >> >> don't think they'd be able to record anything useful.
>> >
>> > Can you please get those messages with net console ?
>
> No, I can't get it to work. I found a good guide at
> <http://www.novell.com/communities/node/4753/netconsole-howto-send-kernel-boot-messages-over-ethernet>
> and adapted it for Debian but absolutely no messages appear. I connected
> it via Ethernet to another netbook which runs Ubuntu. On the Debian one
> (the one with the problem I want to debug) I added to
> /etc/network/interfaces:
>
> auto eth0
> iface eth0 inet static
>    address 10.0.0.20
>    netmask 255.255.255.0
>
> and on Ubuntu:
>
> auto eth0
> iface eth0 inet static
>    address 10.0.0.10
>    netmask 255.255.255.0
>
> On the Debian one I added netconsole to
> /etc/modules and created /etc/modprobe.d/netconsole.conf containing:
>
> options netconsole netconsole=4444@10.0.0.20/eth0,6666@10.0.0.10/00:1E:68:DD:DB:40
>
> On the Ubuntu one I ran:
>
> nc -l -u 6666
>
> I've double-checked the addresses etc and verified that the link is up
> and the netconsole module is loaded, but no messages appear.
>
>> > > If I enable debugging is there a way to get it to sync to disc after
>> > > every message? I think the developers are going to need at least that
>> > > information to be able to track this down.
>> >
>> > Yes sure, that could narrow down the issue.
>>
>> I'll try that first because it should be easier than setting up net
>> console.
>
> I tried to reconfigure rsyslog to sync on each message but it didn't log
> anything useful :-(.

I will try to reproduce here with my platform.

> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Sun, Feb 27, 2011 at 12:05 AM, Tony Houghton <h@realh.co.uk> wrote:
> On Fri, 25 Feb 2011 16:57:45 +0000
> Tony Houghton <h@realh.co.uk> wrote:
>
>> On Fri, 25 Feb 2011 21:37:25 +0530
>> Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
>>
>> > On Fri, Feb 25, 2011 at 8:17 PM, Tony Houghton <h@realh.co.uk> wrote:
>> > >
>> > >> >> I haven't tried looking in logs because the crashes are so severe I
>> > >> >> don't think they'd be able to record anything useful.
>> >
>> > Can you please get those messages with net console ?
>
> No, I can't get it to work. I found a good guide at
> <http://www.novell.com/communities/node/4753/netconsole-howto-send-kernel-boot-messages-over-ethernet>
> and adapted it for Debian but absolutely no messages appear. I connected
> it via Ethernet to another netbook which runs Ubuntu. On the Debian one
> (the one with the problem I want to debug) I added to
> /etc/network/interfaces:
>
> auto eth0
> iface eth0 inet static
> ? ?address 10.0.0.20
> ? ?netmask 255.255.255.0
>
> and on Ubuntu:
>
> auto eth0
> iface eth0 inet static
> ? ?address 10.0.0.10
> ? ?netmask 255.255.255.0
>
> On the Debian one I added netconsole to
> /etc/modules and created /etc/modprobe.d/netconsole.conf containing:
>
> options netconsole netconsole=4444 at 10.0.0.20/eth0,6666 at 10.0.0.10/00:1E:68:DD:DB:40
>
> On the Ubuntu one I ran:
>
> nc -l -u 6666
>
> I've double-checked the addresses etc and verified that the link is up
> and the netconsole module is loaded, but no messages appear.
>
>> > > If I enable debugging is there a way to get it to sync to disc after
>> > > every message? I think the developers are going to need at least that
>> > > information to be able to track this down.
>> >
>> > Yes sure, that could narrow down the issue.
>>
>> I'll try that first because it should be easier than setting up net
>> console.
>
> I tried to reconfigure rsyslog to sync on each message but it didn't log
> anything useful :-(.

I will try to reproduce here with my platform.

> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

Re: [ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Mon, 28 Feb 2011 11:06:54 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> On Sun, Feb 27, 2011 at 12:05 AM, Tony Houghton <h@realh.co.uk> wrote:
> > I tried to reconfigure rsyslog to sync on each message but it
> > didn't log anything useful :-(.
> 
> I will try to reproduce here with my platform.

Is this still not reproducible? I'd like to do more to help trace the
problem but I'm a bit stuck. Is there something I can do to make sure
all the debug/log messages from ath9k appear on the console?

I'm using rsyslog ATM, which is Debian's default logger AFAIK, but I'm
willing to install something different if it will help capture these
messages.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Mon, 28 Feb 2011 11:06:54 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> On Sun, Feb 27, 2011 at 12:05 AM, Tony Houghton <h@realh.co.uk> wrote:
> > I tried to reconfigure rsyslog to sync on each message but it
> > didn't log anything useful :-(.
> 
> I will try to reproduce here with my platform.

Is this still not reproducible? I'd like to do more to help trace the
problem but I'm a bit stuck. Is there something I can do to make sure
all the debug/log messages from ath9k appear on the console?

I'm using rsyslog ATM, which is Debian's default logger AFAIK, but I'm
willing to install something different if it will help capture these
messages.

Re: [ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Wed, Mar 2, 2011 at 10:00 PM, Tony Houghton <h@realh.co.uk> wrote:
> On Mon, 28 Feb 2011 11:06:54 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> On Sun, Feb 27, 2011 at 12:05 AM, Tony Houghton <h@realh.co.uk> wrote:
>> > I tried to reconfigure rsyslog to sync on each message but it
>> > didn't log anything useful :-(.
>>
>> I will try to reproduce here with my platform.
>
> Is this still not reproducible? I'd like to do more to help trace the
> problem but I'm a bit stuck. Is there something I can do to make sure
> all the debug/log messages from ath9k appear on the console?

sudo dmesg -n 8?

>
> I'm using rsyslog ATM, which is Debian's default logger AFAIK, but I'm
> willing to install something different if it will help capture these
> messages.

Tony, it looks like we are not having the card you are using. Any way
I will try to recreate the issue with the AR9285 card I have.

>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Wed, Mar 2, 2011 at 10:00 PM, Tony Houghton <h@realh.co.uk> wrote:
> On Mon, 28 Feb 2011 11:06:54 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> On Sun, Feb 27, 2011 at 12:05 AM, Tony Houghton <h@realh.co.uk> wrote:
>> > I tried to reconfigure rsyslog to sync on each message but it
>> > didn't log anything useful :-(.
>>
>> I will try to reproduce here with my platform.
>
> Is this still not reproducible? I'd like to do more to help trace the
> problem but I'm a bit stuck. Is there something I can do to make sure
> all the debug/log messages from ath9k appear on the console?

sudo dmesg -n 8?

>
> I'm using rsyslog ATM, which is Debian's default logger AFAIK, but I'm
> willing to install something different if it will help capture these
> messages.

Tony, it looks like we are not having the card you are using. Any way
I will try to recreate the issue with the AR9285 card I have.

>

Re: [ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Vivek Natarajan]

On Sun, Feb 27, 2011 at 12:05 AM, Tony Houghton <h@realh.co.uk> wrote:
> On Fri, 25 Feb 2011 16:57:45 +0000
> Tony Houghton <h@realh.co.uk> wrote:
>
>> On Fri, 25 Feb 2011 21:37:25 +0530
>> Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
>>
>> > On Fri, Feb 25, 2011 at 8:17 PM, Tony Houghton <h@realh.co.uk> wrote:
>> > >
>> > >> >> I haven't tried looking in logs because the crashes are so severe I
>> > >> >> don't think they'd be able to record anything useful.
>> >
>> > Can you please get those messages with net console ?
>
> No, I can't get it to work. I found a good guide at
> <http://www.novell.com/communities/node/4753/netconsole-howto-send-kernel-boot-messages-over-ethernet>
> and adapted it for Debian but absolutely no messages appear. I connected
> it via Ethernet to another netbook which runs Ubuntu. On the Debian one
> (the one with the problem I want to debug) I added to
> /etc/network/interfaces:
>
> auto eth0
> iface eth0 inet static
>    address 10.0.0.20
>    netmask 255.255.255.0
>
> and on Ubuntu:
>
> auto eth0
> iface eth0 inet static
>    address 10.0.0.10
>    netmask 255.255.255.0
>
> On the Debian one I added netconsole to
> /etc/modules and created /etc/modprobe.d/netconsole.conf containing:
>
> options netconsole netconsole=4444@10.0.0.20/eth0,6666@10.0.0.10/00:1E:68:DD:DB:40

I used to give
 dmesg -n 8
along  with the above command and I get all the messages in the remote laptop.

>
> On the Ubuntu one I ran:
>
> nc -l -u 6666
>
> I've double-checked the addresses etc and verified that the link is up
> and the netconsole module is loaded, but no messages appear.
>

Can you please try this once again with the above debug level and see
if you get the crash log?

Vivek.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Vivek Natarajan]

On Sun, Feb 27, 2011 at 12:05 AM, Tony Houghton <h@realh.co.uk> wrote:
> On Fri, 25 Feb 2011 16:57:45 +0000
> Tony Houghton <h@realh.co.uk> wrote:
>
>> On Fri, 25 Feb 2011 21:37:25 +0530
>> Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
>>
>> > On Fri, Feb 25, 2011 at 8:17 PM, Tony Houghton <h@realh.co.uk> wrote:
>> > >
>> > >> >> I haven't tried looking in logs because the crashes are so severe I
>> > >> >> don't think they'd be able to record anything useful.
>> >
>> > Can you please get those messages with net console ?
>
> No, I can't get it to work. I found a good guide at
> <http://www.novell.com/communities/node/4753/netconsole-howto-send-kernel-boot-messages-over-ethernet>
> and adapted it for Debian but absolutely no messages appear. I connected
> it via Ethernet to another netbook which runs Ubuntu. On the Debian one
> (the one with the problem I want to debug) I added to
> /etc/network/interfaces:
>
> auto eth0
> iface eth0 inet static
> ? ?address 10.0.0.20
> ? ?netmask 255.255.255.0
>
> and on Ubuntu:
>
> auto eth0
> iface eth0 inet static
> ? ?address 10.0.0.10
> ? ?netmask 255.255.255.0
>
> On the Debian one I added netconsole to
> /etc/modules and created /etc/modprobe.d/netconsole.conf containing:
>
> options netconsole netconsole=4444 at 10.0.0.20/eth0,6666 at 10.0.0.10/00:1E:68:DD:DB:40

I used to give
 dmesg -n 8
along  with the above command and I get all the messages in the remote laptop.

>
> On the Ubuntu one I ran:
>
> nc -l -u 6666
>
> I've double-checked the addresses etc and verified that the link is up
> and the netconsole module is loaded, but no messages appear.
>

Can you please try this once again with the above debug level and see
if you get the crash log?

Vivek.

Re: [ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Thu, 3 Mar 2011 10:51:15 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> On Wed, Mar 2, 2011 at 10:00 PM, Tony Houghton <h@realh.co.uk> wrote:
> >
> > Is this still not reproducible? I'd like to do more to help trace
> > the problem but I'm a bit stuck. Is there something I can do to
> > make sure all the debug/log messages from ath9k appear on the
> > console?
> 
> sudo dmesg -n 8?

AFAICT that will just make sure the debug messages get logged, but not
make them appear anywhere the other messages aren't appearing eg on a
console or net console. I could try tail -f /dev/xconsole.

The ath9k module has a "debug" parameter. It just says it's a mask and I
don't know how to use it. Do I set bits to enable or disable levels?
What value to log "everything"?

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Thu, 3 Mar 2011 10:51:15 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> On Wed, Mar 2, 2011 at 10:00 PM, Tony Houghton <h@realh.co.uk> wrote:
> >
> > Is this still not reproducible? I'd like to do more to help trace
> > the problem but I'm a bit stuck. Is there something I can do to
> > make sure all the debug/log messages from ath9k appear on the
> > console?
> 
> sudo dmesg -n 8?

AFAICT that will just make sure the debug messages get logged, but not
make them appear anywhere the other messages aren't appearing eg on a
console or net console. I could try tail -f /dev/xconsole.

The ath9k module has a "debug" parameter. It just says it's a mask and I
don't know how to use it. Do I set bits to enable or disable levels?
What value to log "everything"?

Re: [ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Thu, Mar 3, 2011 at 8:01 PM, Tony Houghton <h@realh.co.uk> wrote:
> On Thu, 3 Mar 2011 10:51:15 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> On Wed, Mar 2, 2011 at 10:00 PM, Tony Houghton <h@realh.co.uk> wrote:
>> >
>> > Is this still not reproducible? I'd like to do more to help trace
>> > the problem but I'm a bit stuck. Is there something I can do to
>> > make sure all the debug/log messages from ath9k appear on the
>> > console?
>>
>> sudo dmesg -n 8?
>
> AFAICT that will just make sure the debug messages get logged, but not
> make them appear anywhere the other messages aren't appearing eg on a
> console or net console. I could try tail -f /dev/xconsole.
>
> The ath9k module has a "debug" parameter. It just says it's a mask and I
> don't know how to use it. Do I set bits to enable or disable levels?
> What value to log "everything"?
>

Please make sure of the following things
CONFIG_ATH_COMMON=m
CONFIG_ATH_DEBUG=y

CONFIG_ATH9K_HW=m
CONFIG_ATH9K_COMMON=m
CONFIG_ATH9K=m
CONFIG_ATH9K_DEBUGFS=y
CONFIG_ATH9K_RATE_CONTROL=y
CONFIG_ATH9K_HTC=m
CONFIG_ATH9K_HTC_DEBUGFS=y

sudo modprobe ath9k debug=0xffffffff

you will get lot of messages from the debug log.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Thu, Mar 3, 2011 at 8:01 PM, Tony Houghton <h@realh.co.uk> wrote:
> On Thu, 3 Mar 2011 10:51:15 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> On Wed, Mar 2, 2011 at 10:00 PM, Tony Houghton <h@realh.co.uk> wrote:
>> >
>> > Is this still not reproducible? I'd like to do more to help trace
>> > the problem but I'm a bit stuck. Is there something I can do to
>> > make sure all the debug/log messages from ath9k appear on the
>> > console?
>>
>> sudo dmesg -n 8?
>
> AFAICT that will just make sure the debug messages get logged, but not
> make them appear anywhere the other messages aren't appearing eg on a
> console or net console. I could try tail -f /dev/xconsole.
>
> The ath9k module has a "debug" parameter. It just says it's a mask and I
> don't know how to use it. Do I set bits to enable or disable levels?
> What value to log "everything"?
>

Please make sure of the following things
CONFIG_ATH_COMMON=m
CONFIG_ATH_DEBUG=y

CONFIG_ATH9K_HW=m
CONFIG_ATH9K_COMMON=m
CONFIG_ATH9K=m
CONFIG_ATH9K_DEBUGFS=y
CONFIG_ATH9K_RATE_CONTROL=y
CONFIG_ATH9K_HTC=m
CONFIG_ATH9K_HTC_DEBUGFS=y

sudo modprobe ath9k debug=0xffffffff

you will get lot of messages from the debug log.

Re: [ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

On Thu, 3 Mar 2011 21:27:32 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> sudo modprobe ath9k debug=0xffffffff

That debug option was what I needed. I'm attaching what I captured with
netconsole leading up to a crash.

I also found that I couldn't reproduce the problem while running on
battery, but as soon as I connected the PSU it crashed the very next
time I disabled wireless. I hadn't noticed that PSU/battery made a
difference before, but it does seem to be an issue.

[-- Attachment #2: netconsole.log --]
[-- Type: text/x-log, Size: 18765 bytes --]

[  656.568676] ath: NETWORK SLEEP -> AWAKE
[  656.573331] ath: disable IER
[  656.573423] ath: enable IER
[  656.573449] ath: AR_IMR 0x918414b0 IER 0x1
[  656.573488] ath: AWAKE -> NETWORK SLEEP
[  656.671069] ath: NETWORK SLEEP -> AWAKE
[  656.675728] ath: disable IER
[  656.675839] ath: enable IER
[  656.675871] ath: AR_IMR 0x918414b0 IER 0x1
[  656.675909] ath: AWAKE -> NETWORK SLEEP
[  656.773479] ath: NETWORK SLEEP -> AWAKE
[  656.778163] ath: disable IER
[  656.778276] ath: enable IER
[  656.778306] ath: AR_IMR 0x918414b0 IER 0x1
[  656.778345] ath: AWAKE -> NETWORK SLEEP
[  656.875865] ath: NETWORK SLEEP -> AWAKE
[  656.880517] ath: disable IER
[  656.880621] ath: enable IER
[  656.880652] ath: AR_IMR 0x918414b0 IER 0x1
[  656.880691] ath: AWAKE -> NETWORK SLEEP
[  656.978277] ath: NETWORK SLEEP -> AWAKE
[  656.982919] ath: disable IER
[  656.983010] ath: enable IER
[  656.983038] ath: AR_IMR 0x918414b0 IER 0x1
[  656.983076] ath: AWAKE -> NETWORK SLEEP
[  657.080663] ath: NETWORK SLEEP -> AWAKE
[  657.085311] ath: disable IER
[  657.085401] ath: enable IER
[  657.085430] ath: AR_IMR 0x918414b0 IER 0x1
[  657.085468] ath: AWAKE -> NETWORK SLEEP
[  657.183041] ath: NETWORK SLEEP -> AWAKE
[  657.187720] ath: disable IER
[  657.187812] ath: enable IER
[  657.187839] ath: AR_IMR 0x918414b0 IER 0x1
[  657.187878] ath: AWAKE -> NETWORK SLEEP
[  657.285466] ath: NETWORK SLEEP -> AWAKE
[  657.290164] ath: disable IER
[  657.290275] ath: enable IER
[  657.290307] ath: AR_IMR 0x918414b0 IER 0x1
[  657.290345] ath: AWAKE -> NETWORK SLEEP
[  657.387853] ath: NETWORK SLEEP -> AWAKE
[  657.392509] ath: disable IER
[  657.392590] ath: enable IER
[  657.392608] ath: AR_IMR 0x918414b0 IER 0x1
[  657.392640] ath: AWAKE -> NETWORK SLEEP
[  657.490269] ath: NETWORK SLEEP -> AWAKE
[  657.494909] ath: disable IER
[  657.495020] ath: enable IER
[  657.495052] ath: AR_IMR 0x918414b0 IER 0x1
[  657.495090] ath: AWAKE -> NETWORK SLEEP
[  657.592643] ath: NETWORK SLEEP -> AWAKE
[  657.597299] ath: disable IER
[  657.597390] ath: enable IER
[  657.597417] ath: AR_IMR 0x918414b0 IER 0x1
[  657.597455] ath: AWAKE -> NETWORK SLEEP
[  657.695037] ath: NETWORK SLEEP -> AWAKE
[  657.699728] ath: disable IER
[  657.699839] ath: enable IER
[  657.699871] ath: AR_IMR 0x918414b0 IER 0x1
[  657.699909] ath: AWAKE -> NETWORK SLEEP
[  657.797450] ath: NETWORK SLEEP -> AWAKE
[  657.802098] ath: disable IER
[  657.802191] ath: enable IER
[  657.802209] ath: AR_IMR 0x918414b0 IER 0x1
[  657.802241] ath: AWAKE -> NETWORK SLEEP
[  657.899841] ath: NETWORK SLEEP -> AWAKE
[  657.904500] ath: disable IER
[  657.904612] ath: enable IER
[  657.904643] ath: AR_IMR 0x918414b0 IER 0x1
[  657.904681] ath: AWAKE -> NETWORK SLEEP
[  658.002248] ath: NETWORK SLEEP -> AWAKE
[  658.006897] ath: disable IER
[  658.006989] ath: enable IER
[  658.007022] ath: AR_IMR 0x918414b0 IER 0x1
[  658.007060] ath: AWAKE -> NETWORK SLEEP
[  658.104631] ath: NETWORK SLEEP -> AWAKE
[  658.108051] ath: shortcal @89527
[  658.108149] ath: listenTime=247 OFDM:0 errs=89/s CCK:2 errs=16/s ofdm_turn=1
[  658.108224] ath: NF calibrated [ctl] [chain 0] is -115
[  658.109291] ath: disable IER
[  658.109399] ath: enable IER
[  658.109425] ath: AR_IMR 0x918414b0 IER 0x1
[  658.109464] ath: AWAKE -> NETWORK SLEEP
[  658.207056] ath: NETWORK SLEEP -> AWAKE
[  658.208212] ath: listenTime=249 OFDM:0 errs=88/s CCK:2 errs=16/s ofdm_turn=1
[  658.211693] ath: disable IER
[  658.211797] ath: enable IER
[  658.211825] ath: AR_IMR 0x918414b0 IER 0x1
[  658.211864] ath: AWAKE -> NETWORK SLEEP
[  658.309434] ath: NETWORK SLEEP -> AWAKE
[  658.314082] ath: disable IER
[  658.314232] ath: enable IER
[  658.314255] ath: AR_IMR 0x918414b0 IER 0x1
[  658.314294] ath: AWAKE -> NETWORK SLEEP
[  658.411826] ath: NETWORK SLEEP -> AWAKE
[  658.416489] ath: disable IER
[  658.416571] ath: enable IER
[  658.416594] ath: AR_IMR 0x918414b0 IER 0x1
[  658.416626] ath: AWAKE -> NETWORK SLEEP
[  658.514243] ath: NETWORK SLEEP -> AWAKE
[  658.518890] ath: disable IER
[  658.519001] ath: enable IER
[  658.519032] ath: AR_IMR 0x918414b0 IER 0x1
[  658.519071] ath: AWAKE -> NETWORK SLEEP
[  658.616624] ath: NETWORK SLEEP -> AWAKE
[  658.621286] ath: disable IER
[  658.621377] ath: enable IER
[  658.621404] ath: AR_IMR 0x918414b0 IER 0x1
[  658.621443] ath: AWAKE -> NETWORK SLEEP
[  658.719044] ath: NETWORK SLEEP -> AWAKE
[  658.723685] ath: disable IER
[  658.723797] ath: enable IER
[  658.723828] ath: AR_IMR 0x918414b0 IER 0x1
[  658.723866] ath: AWAKE -> NETWORK SLEEP
[  658.821426] ath: NETWORK SLEEP -> AWAKE
[  658.826147] ath: disable IER
[  658.826264] ath: enable IER
[  658.826295] ath: AR_IMR 0x918414b0 IER 0x1
[  658.826334] ath: AWAKE -> NETWORK SLEEP
[  658.923813] ath: NETWORK SLEEP -> AWAKE
[  658.928477] ath: disable IER
[  658.928552] ath: enable IER
[  658.928577] ath: AR_IMR 0x918414b0 IER 0x1
[  658.928609] ath: AWAKE -> NETWORK SLEEP
[  659.026244] ath: NETWORK SLEEP -> AWAKE
[  659.030883] ath: disable IER
[  659.030995] ath: enable IER
[  659.031026] ath: AR_IMR 0x918414b0 IER 0x1
[  659.031064] ath: AWAKE -> NETWORK SLEEP
[  659.128612] ath: NETWORK SLEEP -> AWAKE
[  659.133273] ath: disable IER
[  659.133385] ath: enable IER
[  659.133416] ath: AR_IMR 0x918414b0 IER 0x1
[  659.133465] ath: AWAKE -> NETWORK SLEEP
[  659.231035] ath: NETWORK SLEEP -> AWAKE
[  659.235665] ath: disable IER
[  659.235787] ath: enable IER
[  659.235825] ath: AR_IMR 0x918414b0 IER 0x1
[  659.235863] ath: AWAKE -> NETWORK SLEEP
[  659.333422] ath: NETWORK SLEEP -> AWAKE
[  659.338119] ath: disable IER
[  659.338228] ath: enable IER
[  659.338262] ath: AR_IMR 0x918414b0 IER 0x1
[  659.338301] ath: AWAKE -> NETWORK SLEEP
[  659.435801] ath: NETWORK SLEEP -> AWAKE
[  659.440472] ath: disable IER
[  659.440586] ath: enable IER
[  659.440615] ath: AR_IMR 0x918414b0 IER 0x1
[  659.440654] ath: AWAKE -> NETWORK SLEEP
[  659.538214] ath: NETWORK SLEEP -> AWAKE
[  659.542869] ath: disable IER
[  659.542960] ath: enable IER
[  659.542987] ath: AR_IMR 0x918414b0 IER 0x1
[  659.543026] ath: AWAKE -> NETWORK SLEEP
[  659.640605] ath: NETWORK SLEEP -> AWAKE
[  659.645260] ath: disable IER
[  659.645350] ath: enable IER
[  659.645379] ath: AR_IMR 0x918414b0 IER 0x1
[  659.645417] ath: AWAKE -> NETWORK SLEEP
[  659.743019] ath: NETWORK SLEEP -> AWAKE
[  659.747666] ath: disable IER
[  659.747770] ath: enable IER
[  659.747801] ath: AR_IMR 0x918414b0 IER 0x1
[  659.747839] ath: AWAKE -> NETWORK SLEEP
[  659.845408] ath: NETWORK SLEEP -> AWAKE
[  659.850061] ath: disable IER
[  659.850175] ath: enable IER
[  659.850205] ath: AR_IMR 0x918414b0 IER 0x1
[  659.850243] ath: AWAKE -> NETWORK SLEEP
[  659.947820] ath: NETWORK SLEEP -> AWAKE
[  659.952453] ath: disable IER
[  659.952567] ath: enable IER
[  659.952596] ath: AR_IMR 0x918414b0 IER 0x1
[  659.952635] ath: AWAKE -> NETWORK SLEEP
[  660.050205] ath: NETWORK SLEEP -> AWAKE
[  660.054844] ath: disable IER
[  660.054942] ath: enable IER
[  660.054968] ath: AR_IMR 0x918414b0 IER 0x1
[  660.055006] ath: AWAKE -> NETWORK SLEEP
[  660.152590] ath: NETWORK SLEEP -> AWAKE
[  660.157255] ath: disable IER
[  660.157414] ath: enable IER
[  660.157451] ath: AR_IMR 0x918414b0 IER 0x1
[  660.157496] ath: AWAKE -> NETWORK SLEEP
[  660.255011] ath: NETWORK SLEEP -> AWAKE
[  660.259661] ath: disable IER
[  660.259786] ath: enable IER
[  660.259815] ath: AR_IMR 0x918414b0 IER 0x1
[  660.259853] ath: AWAKE -> NETWORK SLEEP
[  660.357398] ath: NETWORK SLEEP -> AWAKE
[  660.362114] ath: disable IER
[  660.362226] ath: enable IER
[  660.362257] ath: AR_IMR 0x918414b0 IER 0x1
[  660.362296] ath: AWAKE -> NETWORK SLEEP
[  660.459815] ath: NETWORK SLEEP -> AWAKE
[  660.464772] ath: disable IER
[  660.464882] ath: enable IER
[  660.464914] ath: AR_IMR 0x918414b0 IER 0x1
[  660.464952] ath: AWAKE -> NETWORK SLEEP
[  660.562196] ath: NETWORK SLEEP -> AWAKE
[  660.566845] ath: disable IER
[  660.566937] ath: enable IER
[  660.566964] ath: AR_IMR 0x918414b0 IER 0x1
[  660.567002] ath: AWAKE -> NETWORK SLEEP
[  660.664578] ath: NETWORK SLEEP -> AWAKE
[  660.669250] ath: disable IER
[  660.669365] ath: enable IER
[  660.669393] ath: AR_IMR 0x918414b0 IER 0x1
[  660.669432] ath: AWAKE -> NETWORK SLEEP
[  660.766992] ath: NETWORK SLEEP -> AWAKE
[  660.771647] ath: disable IER
[  660.771738] ath: enable IER
[  660.771766] ath: AR_IMR 0x918414b0 IER 0x1
[  660.771804] ath: AWAKE -> NETWORK SLEEP
[  660.869379] ath: NETWORK SLEEP -> AWAKE
[  660.874052] ath: disable IER
[  660.874164] ath: enable IER
[  660.874195] ath: AR_IMR 0x918414b0 IER 0x1
[  660.874234] ath: AWAKE -> NETWORK SLEEP
[  660.971804] ath: NETWORK SLEEP -> AWAKE
[  660.976449] ath: disable IER
[  660.976562] ath: enable IER
[  660.976592] ath: AR_IMR 0x918414b0 IER 0x1
[  660.976630] ath: AWAKE -> NETWORK SLEEP
[  661.074187] ath: NETWORK SLEEP -> AWAKE
[  661.078840] ath: disable IER
[  661.078951] ath: enable IER
[  661.078983] ath: AR_IMR 0x918414b0 IER 0x1
[  661.079021] ath: AWAKE -> NETWORK SLEEP
[  661.176604] ath: NETWORK SLEEP -> AWAKE
[  661.181243] ath: disable IER
[  661.181356] ath: enable IER
[  661.181387] ath: AR_IMR 0x918414b0 IER 0x1
[  661.181426] ath: AWAKE -> NETWORK SLEEP
[  661.278987] ath: NETWORK SLEEP -> AWAKE
[  661.283640] ath: disable IER
[  661.283752] ath: enable IER
[  661.283783] ath: AR_IMR 0x918414b0 IER 0x1
[  661.283821] ath: AWAKE -> NETWORK SLEEP
[  661.344896] ath: Configure tx [queue/halq] [0/0], aifs: 2, cw_min: 3, cw_max: 7, txop: 47
[  661.344922] ath: Set queue properties for: 0
[  661.344933] ath: Reset TX queue: 0
[  661.344968] ath: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0
[  661.345022] ath: Configure tx [queue/halq] [1/1], aifs: 2, cw_min: 7, cw_max: 15, txop: 94
[  661.345069] ath: Set queue properties for: 1
[  661.345078] ath: Reset TX queue: 1
[  661.345088] ath: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0
[  661.345145] ath: Configure tx [queue/halq] [2/2], aifs: 3, cw_min: 15, cw_max: 1023, txop: 0
[  661.345191] ath: Set queue properties for: 2
[  661.345200] ath: Reset TX queue: 2
[  661.345209] ath: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0
[  661.345266] ath: Configure tx [queue/halq] [3/3], aifs: 7, cw_min: 15, cw_max: 1023, txop: 0
[  661.345312] ath: Set queue properties for: 3
[  661.345321] ath: Reset TX queue: 3
[  661.345331] ath: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0
[  661.345390] ath: NETWORK SLEEP -> AWAKE
[  661.345478] ath: 0xf4041071 => 0xf4041071
[  661.345486] ath: new IMR 0x918414b0
[  661.345496] ath: enable IER
[  661.345516] ath: AR_IMR 0x918414b0 IER 0x1
[  661.345570] ath: BSSID: 00:00:00:00:00:00 aid: 0x0
[  661.345579] ath: ah->misc_mode 0x4
[  661.345612] ath: BSS Changed PREAMBLE 0
[  661.345620] ath: BSS Changed CTS PROT 0
[  661.345628] ath: BSS Changed ASSOC 0
[  661.345635] ath: Bss Info DISASSOC
[  661.345645] wlan0: deauthenticating from 00:1f:9f:eb:41:e1 by local choice (reason=3)
[  661.360110] ath: Set HW Key
[  661.360229] ath: transmitting packet, skb: f5a94480
[  661.360256] ath: qnum: 0, txq depth: 0
[  661.360273] ath: link[0] (f63b652c)=363b6590 (f63b6590)
[  661.360287] ath: Enable TXE on queue: 0
[  661.360381] ath: disable IER
[  661.360419] ath: tx queue 0 (363b6590), link f63b6590
[  661.360426] ath: enable IER
[  661.360444] ath: AR_IMR 0x918414b0 IER 0x1
[  661.361133] ath: disable IER
[  661.361177] ath: tx queue 0 (363b6590), link f63b6590
[  661.361195] ath: TX complete: skb: f5a94480
[  661.361219] ath: enable IER
[  661.361245] ath: AR_IMR 0x918414b0 IER 0x1
[  661.372083] ath: Set HW Key
[  661.376651] ath: Marking phy0 as idle
[  661.376674] ath: idle: disabling radio
[  661.376691] ath: disable IER
[  661.376952] ath: Disable MIB counters
[  661.377035] ath: Disable MIB counters
[  661.377114] ath: NF calibrated [ctl] [chain 0] is -115
[  661.379715] ath: PDADC (0,   0): a280 03020100
[  661.379730] ath: PDADC: Chain 0 | PDADC   0 Value   0 | PDADC   1 Value   1 | PDADC   2 Value   2 | PDADC   3 Value   3 |
[  661.379740] ath: PDADC (0,   0): a284 07060504
[  661.379750] ath: PDADC: Chain 0 | PDADC   4 Value   4 | PDADC   5 Value   5 | PDADC   6 Value   6 | PDADC   7 Value   7 |
[  661.379760] ath: PDADC (0,   0): a288 0a0a0908
[  661.379769] ath: PDADC: Chain 0 | PDADC   8 Value   8 | PDADC   9 Value   9 | PDADC  10 Value  10 | PDADC  11 Value  10 |
[  661.379779] ath: PDADC (0,   0): a28c 110f0d0b
[  661.379789] ath: PDADC: Chain 0 | PDADC  12 Value  11 | PDADC  13 Value  13 | PDADC  14 Value  15 | PDADC  15 Value  17 |
[  661.379798] ath: PDADC (0,   0): a290 18161412
[  661.379808] ath: PDADC: Chain 0 | PDADC  16 Value  18 | PDADC  17 Value  20 | PDADC  18 Value  22 | PDADC  19 Value  24 |
[  661.379817] ath: PDADC (0,   0): a294 24201d1b
[  661.379827] ath: PDADC: Chain 0 | PDADC  20 Value  27 | PDADC  21 Value  29 | PDADC  22 Value  32 | PDADC  23 Value  36 |
[  661.379837] ath: PDADC (0,   0): a298 2f2c2926
[  661.379847] ath: PDADC: Chain 0 | PDADC  24 Value  38 | PDADC  25 Value  41 | PDADC  26 Value  44 | PDADC  27 Value  47 |
[  661.379862] ath: PDADC (0,   0): a29c 453f3933
[  661.379876] ath: PDADC: Chain 0 | PDADC  28 Value  51 | PDADC  29 Value  57 | PDADC  30 Value  63 | PDADC  31 Value  69 |
[  661.379886] ath: PDADC (0,   0): a2a0 5d57514b
[  661.379895] ath: PDADC: Chain 0 | PDADC  32 Value  75 | PDADC  33 Value  81 | PDADC  34 Value  87 | PDADC  35 Value  93 |
[  661.379905] ath: PDADC (0,   0): a2a4 756f6963
[  661.379914] ath: PDADC: Chain 0 | PDADC  36 Value  99 | PDADC  37 Value 105 | PDADC  38 Value 111 | PDADC  39 Value 117 |
[  661.379924] ath: PDADC (0,   0): a2a8 100e817b
[  661.379933] ath: PDADC: Chain 0 | PDADC  40 Value 123 | PDADC  41 Value 129 | PDADC  42 Value  14 | PDADC  43 Value  16 |
[  661.379943] ath: PDADC (0,   0): a2ac 18161412
[  661.379952] ath: PDADC: Chain 0 | PDADC  44 Value  18 | PDADC  45 Value  20 | PDADC  46 Value  22 | PDADC  47 Value  24 |
[  661.379962] ath: PDADC (0,   0): a2b0 1f1d1b19
[  661.379971] ath: PDADC: Chain 0 | PDADC  48 Value  25 | PDADC  49 Value  27 | PDADC  50 Value  29 | PDADC  51 Value  31 |
[  661.379982] ath: PDADC (0,   0): a2b4 2b282522
[  661.379994] ath: PDADC: Chain 0 | PDADC  52 Value  34 | PDADC  53 Value  37 | PDADC  54 Value  40 | PDADC  55 Value  43 |
[  661.380009] ath: PDADC (0,   0): a2b8 3a36322e
[  661.380053] ath: PDADC: Chain 0 | PDADC  56 Value  46 | PDADC  57 Value  50 | PDADC  58 Value  54 | PDADC  59 Value  58 |
[  661.380068] ath: PDADC (0,   0): a2bc 4a46423e
[  661.380081] ath: PDADC: Chain 0 | PDADC  60 Value  62 | PDADC  61 Value  66 | PDADC  62 Value  70 | PDADC  63 Value  74 |
[  661.380094] ath: PDADC (0,   0): a2c0 5e59544f
[  661.380106] ath: PDADC: Chain 0 | PDADC  64 Value  79 | PDADC  65 Value  84 | PDADC  66 Value  89 | PDADC  67 Value  94 |
[  661.380119] ath: PDADC (0,   0): a2c4 6d6d6863
[  661.380132] ath: PDADC: Chain 0 | PDADC  68 Value  99 | PDADC  69 Value 104 | PDADC  70 Value 109 | PDADC  71 Value 109 |
[  661.380145] ath: PDADC (0,   0): a2c8 6d6d6d6d
[  661.380159] ath: PDADC: Chain 0 | PDADC  72 Value 109 | PDADC  73 Value 109 | PDADC  74 Value 109 | PDADC  75 Value 109 |
[  661.380172] ath: PDADC (0,   0): a2cc 6d6d6d6d
[  661.380184] ath: PDADC: Chain 0 | PDADC  76 Value 109 | PDADC  77 Value 109 | PDADC  78 Value 109 | PDADC  79 Value 109 |
[  661.380198] ath: PDADC (0,   0): a2d0 6d6d6d6d
[  661.380210] ath: PDADC: Chain 0 | PDADC  80 Value 109 | PDADC  81 Value 109 | PDADC  82 Value 109 | PDADC  83 Value 109 |
[  661.380223] ath: PDADC (0,   0): a2d4 6d6d6d6d
[  661.380235] ath: PDADC: Chain 0 | PDADC  84 Value 109 | PDADC  85 Value 109 | PDADC  86 Value 109 | PDADC  87 Value 109 |
[  661.380249] ath: PDADC (0,   0): a2d8 6d6d6d6d
[  661.380262] ath: PDADC: Chain 0 | PDADC  88 Value 109 | PDADC  89 Value 109 | PDADC  90 Value 109 | PDADC  91 Value 109 |
[  661.380275] ath: PDADC (0,   0): a2dc 6d6d6d6d
[  661.380289] ath: PDADC: Chain 0 | PDADC  92 Value 109 | PDADC  93 Value 109 | PDADC  94 Value 109 | PDADC  95 Value 109 |
[  661.380303] ath: PDADC (0,   0): a2e0 6d6d6d6d
[  661.380316] ath: PDADC: Chain 0 | PDADC  96 Value 109 | PDADC  97 Value 109 | PDADC  98 Value 109 | PDADC  99 Value 109 |
[  661.380329] ath: PDADC (0,   0): a2e4 6d6d6d6d
[  661.380341] ath: PDADC: Chain 0 | PDADC 100 Value 109 | PDADC 101 Value 109 | PDADC 102 Value 109 | PDADC 103 Value 109 |
[  661.380354] ath: PDADC (0,   0): a2e8 6d6d6d6d
[  661.380367] ath: PDADC: Chain 0 | PDADC 104 Value 109 | PDADC 105 Value 109 | PDADC 106 Value 109 | PDADC 107 Value 109 |
[  661.380380] ath: PDADC (0,   0): a2ec 6d6d6d6d
[  661.380392] ath: PDADC: Chain 0 | PDADC 108 Value 109 | PDADC 109 Value 109 | PDADC 110 Value 109 | PDADC 111 Value 109 |
[  661.380405] ath: PDADC (0,   0): a2f0 6d6d6d6d
[  661.380417] ath: PDADC: Chain 0 | PDADC 112 Value 109 | PDADC 113 Value 109 | PDADC 114 Value 109 | PDADC 115 Value 109 |
[  661.380431] ath: PDADC (0,   0): a2f4 6d6d6d6d
[  661.380444] ath: PDADC: Chain 0 | PDADC 116 Value 109 | PDADC 117 Value 109 | PDADC 118 Value 109 | PDADC 119 Value 109 |
[  661.380457] ath: PDADC (0,   0): a2f8 6d6d6d6d
[  661.380469] ath: PDADC: Chain 0 | PDADC 120 Value 109 | PDADC 121 Value 109 | PDADC 122 Value 109 | PDADC 123 Value 109 |
[  661.380481] ath: PDADC (0,   0): a2fc 6d6d6d6d
[  661.380494] ath: PDADC: Chain 0 | PDADC 124 Value 109 | PDADC 125 Value 109 | PDADC 126 Value 109 | PDADC 127 Value 109 |
[  661.380542] ath: Getting spur idx:0 is2Ghz:1 val:8000
[  661.382342] ath: Reset TX queue: 0
[  661.382367] ath: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0
[  661.382383] ath: Reset TX queue: 1
[  661.382396] ath: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0
[  661.382412] ath: Reset TX queue: 2
[  661.382425] ath: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0
[  661.382437] ath: Reset TX queue: 3
[  661.382451] ath: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0
[  661.382463] ath: Reset TXQ, inactive queue: 4
[  661.382475] ath: Reset TXQ, inactive queue: 5
[  661.382486] ath: Reset TXQ, inactive queue: 6
[  661.382496] ath: Reset TXQ, inactive queue: 7
[  661.382506] ath: Reset TX queue: 8
[  661.382535] ath: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0
[  661.382547] ath: Reset TX queue: 9
[  661.382572] ath: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0
[  661.382595] ath: ah->misc_mode 0x4
[  661.384209] ath: Running PA Calibration
[  661.384933] ath: enabling ADC Gain Calibration.
[  661.384945] ath: enabling ADC DC Calibration.
[  661.384953] ath: enabling IQ Calibration.
[  661.384963] ath: starting ADC Gain Calibration
[  661.388029] ath: AWAKE -> FULL-SLEEP
[  662.368089] cfg80211: Calling CRDA to update world regulatory domain
[  662.370424] ath: FULL-SLEEP -> AWAKE

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Thu, 3 Mar 2011 21:27:32 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> sudo modprobe ath9k debug=0xffffffff

That debug option was what I needed. I'm attaching what I captured with
netconsole leading up to a crash.

I also found that I couldn't reproduce the problem while running on
battery, but as soon as I connected the PSU it crashed the very next
time I disabled wireless. I hadn't noticed that PSU/battery made a
difference before, but it does seem to be an issue.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: netconsole.log
Type: text/x-log
Size: 18765 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110303/eab9d9d9/attachment-0001.bin 

Re: [ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

2011/3/4 Tony Houghton <h@realh.co.uk>:
> On Thu, 3 Mar 2011 21:27:32 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> sudo modprobe ath9k debug=0xffffffff
>
> That debug option was what I needed. I'm attaching what I captured with
> netconsole leading up to a crash.

Could not find something suspicious, but need to look more into it.
The patch you mentioned adds support for new version of a  chip and I
am not quite clear how it can directly cause a kernel lock. All those
things added are mainly hardware code and need to see whether some
thing basic is missed in the patch.

>
> I also found that I couldn't reproduce the problem while running on
> battery, but as soon as I connected the PSU it crashed the very next
> time I disabled wireless. I hadn't noticed that PSU/battery made a
> difference before, but it does seem to be an issue.
>

Please see whether this is consistently reproducible.
As a try can you please disable the network manager and use iw command
to connect?

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

2011/3/4 Tony Houghton <h@realh.co.uk>:
> On Thu, 3 Mar 2011 21:27:32 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> sudo modprobe ath9k debug=0xffffffff
>
> That debug option was what I needed. I'm attaching what I captured with
> netconsole leading up to a crash.

Could not find something suspicious, but need to look more into it.
The patch you mentioned adds support for new version of a  chip and I
am not quite clear how it can directly cause a kernel lock. All those
things added are mainly hardware code and need to see whether some
thing basic is missed in the patch.

>
> I also found that I couldn't reproduce the problem while running on
> battery, but as soon as I connected the PSU it crashed the very next
> time I disabled wireless. I hadn't noticed that PSU/battery made a
> difference before, but it does seem to be an issue.
>

Please see whether this is consistently reproducible.
As a try can you please disable the network manager and use iw command
to connect?

Re: [ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Fri, 4 Mar 2011 21:20:02 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> 2011/3/4 Tony Houghton <h@realh.co.uk>:  
> >
> > I also found that I couldn't reproduce the problem while running on
> > battery, but as soon as I connected the PSU it crashed the very next
> > time I disabled wireless. I hadn't noticed that PSU/battery made a
> > difference before, but it does seem to be an issue.
> >  
> 
> Please see whether this is consistently reproducible.  

No, today it crashed on battery power. Something else must have been
different too when I tried on battery before, because I restarted the
wireless several times without problem, and usually it crashes almost
every time.

> As a try can you please disable the network manager and use iw command
> to connect?  

I tried wicd early on, that crashed too.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Fri, 4 Mar 2011 21:20:02 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> 2011/3/4 Tony Houghton <h@realh.co.uk>:  
> >
> > I also found that I couldn't reproduce the problem while running on
> > battery, but as soon as I connected the PSU it crashed the very next
> > time I disabled wireless. I hadn't noticed that PSU/battery made a
> > difference before, but it does seem to be an issue.
> >  
> 
> Please see whether this is consistently reproducible.  

No, today it crashed on battery power. Something else must have been
different too when I tried on battery before, because I restarted the
wireless several times without problem, and usually it crashes almost
every time.

> As a try can you please disable the network manager and use iw command
> to connect?  

I tried wicd early on, that crashed too.

Could ath9k and rt2800pci bugs be related?

[Tony Houghton]

[I am no longer subscribed to the list so please Cc me]

I'm the person who reported that my system kept freezing when shutting
down my AR9285 wireless with kernel 2.6.35 or newer.

I've just bought an Acer Aspire Revo 3700 and this had very similar
symptoms with a different adapter. Luckily another customer had posted
about it on the vendor's website and his fix works for me. The fix is to
blacklist the rt2800pci module and the rt2860sta driver seems to work
quite happily without it.

It looks as if rt2800pci was introduced somewhere between 2.6.32 and
2.6.34 and I experienced the crashes with 2.6.35 (Mint 10/Ubuntu 10.10)
and 2.6.37 (Debian unstable), but not with 2.6.32 (Debian squeeze) which
doesn't have that module.

It's probably just coincidence, but I was struck by how similar the
symptoms are and wondered whether these different drivers have anything
in common? 

lspci output:

02:00.0 Network controller [0280]: RaLink RT3090 Wireless 802.11n 1T/1R PCIe [1814:3090]
	Subsystem: Lite-On Communications Inc Device [11ad:6622]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 18
	Region 0: Memory at febf0000 (32-bit, non-prefetchable) [size=64K]
	Capabilities: <access denied>
	Kernel driver in use: rt2860

Re: Could ath9k and rt2800pci bugs be related?

[Mohammed Shafi]

On Mon, Mar 14, 2011 at 10:18 PM, Tony Houghton <h@realh.co.uk> wrote:
> [I am no longer subscribed to the list so please Cc me]
>
> I'm the person who reported that my system kept freezing when shutting
> down my AR9285 wireless with kernel 2.6.35 or newer.
>
> I've just bought an Acer Aspire Revo 3700 and this had very similar
> symptoms with a different adapter. Luckily another customer had posted
> about it on the vendor's website and his fix works for me. The fix is to
> blacklist the rt2800pci module and the rt2860sta driver seems to work
> quite happily without it.
>
> It looks as if rt2800pci was introduced somewhere between 2.6.32 and
> 2.6.34 and I experienced the crashes with 2.6.35 (Mint 10/Ubuntu 10.10)
> and 2.6.37 (Debian unstable), but not with 2.6.32 (Debian squeeze) which
> doesn't have that module.

can you please check by disabling the supicious rt modules and see
whether this problems happens.
for quick check please try with the latest compat wireless.

>
> It's probably just coincidence, but I was struck by how similar the
> symptoms are and wondered whether these different drivers have anything
> in common?
>
> lspci output:
>
> 02:00.0 Network controller [0280]: RaLink RT3090 Wireless 802.11n 1T/1R PCIe [1814:3090]
>        Subsystem: Lite-On Communications Inc Device [11ad:6622]
>        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>        Latency: 0, Cache Line Size: 32 bytes
>        Interrupt: pin A routed to IRQ 18
>        Region 0: Memory at febf0000 (32-bit, non-prefetchable) [size=64K]
>        Capabilities: <access denied>
>        Kernel driver in use: rt2860
> --
> 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
>

Re: Could ath9k and rt2800pci bugs be related?

[Tony Houghton]

On Tue, 15 Mar 2011 13:17:40 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> On Mon, Mar 14, 2011 at 10:18 PM, Tony Houghton <h@realh.co.uk> wrote:
> >
> > I've just bought an Acer Aspire Revo 3700 and this had very similar
> > symptoms with a different adapter. Luckily another customer had
> > posted about it on the vendor's website and his fix works for me.
> > The fix is to blacklist the rt2800pci module and the rt2860sta
> > driver seems to work quite happily without it.
> 
> can you please check by disabling the supicious rt modules and see
> whether this problems happens.

Yes, I did blacklist rt2800pci and the system works correctly without
the module loaded. Even the wireless connection still works.

> for quick check please try with the latest compat wireless.

How do I do that?

I would also be willing to add extra debugging messages to ath9k to help
track down the AR9285 problem. I'm a C programmer, but not a kernel
hacker so I think I would need some advice about which functions to
examine.

Re: Could ath9k and rt2800pci bugs be related?

[Mohammed Shafi]

On Tue, Mar 15, 2011 at 6:49 PM, Tony Houghton <h@realh.co.uk> wrote:
> On Tue, 15 Mar 2011 13:17:40 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> On Mon, Mar 14, 2011 at 10:18 PM, Tony Houghton <h@realh.co.uk> wrote:
>> >
>> > I've just bought an Acer Aspire Revo 3700 and this had very similar
>> > symptoms with a different adapter. Luckily another customer had
>> > posted about it on the vendor's website and his fix works for me.
>> > The fix is to blacklist the rt2800pci module and the rt2860sta
>> > driver seems to work quite happily without it.
>>
>> can you please check by disabling the supicious rt modules and see
>> whether this problems happens.
>
> Yes, I did blacklist rt2800pci and the system works correctly without
> the module loaded. Even the wireless connection still works.

Ok still there is also one or two guys reporting this locking issue,
so we need to be very sure.

>
>> for quick check please try with the latest compat wireless.
>
> How do I do that?
>
> I would also be willing to add extra debugging messages to ath9k to help
> track down the AR9285 problem. I'm a C programmer, but not a kernel
> hacker so I think I would need some advice about which functions to
> examine.
>

No its nothing to do with kernel hacking, its just a wireless package.
instead of compiling the whole kernel or wireless testing, we can
install a wireless package within our linux distribution in few
minutes. This package is called compat-wireless which includes latest
fixes in wireless testing.
more information in:
http://wireless.kernel.org/en/users/Download

1.now download the compat wireless package in
http://linuxwireless.org/download/compat-wireless-2.6/
2. cd compat-wireless-...
3. As you are suspicious about rt modules remove them in config.mk
4.now do ./scripts/driver-select ath9k
5.make
6.make install
7.make unload
8.sudo modprobe ath9k

thanks,
shafi

Re: Could ath9k and rt2800pci bugs be related?

[Tony Houghton]

On Tue, 15 Mar 2011 19:05:27 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> On Tue, Mar 15, 2011 at 6:49 PM, Tony Houghton <h@realh.co.uk> wrote:
> > On Tue, 15 Mar 2011 13:17:40 +0530
> > Mohammed Shafi <shafi.wireless@gmail.com> wrote:
> >
> >> On Mon, Mar 14, 2011 at 10:18 PM, Tony Houghton <h@realh.co.uk>
> >> wrote:
> >> >
> >> > I've just bought an Acer Aspire Revo 3700 and this had very
> >> > similar symptoms with a different adapter. Luckily another
> >> > customer had posted about it on the vendor's website and his fix
> >> > works for me. The fix is to blacklist the rt2800pci module and
> >> > the rt2860sta driver seems to work quite happily without it.
> >>
> >> can you please check by disabling the supicious rt modules and see
> >> whether this problems happens.
> >
> > Yes, I did blacklist rt2800pci and the system works correctly
> > without the module loaded. Even the wireless connection still works.
> 
> Ok still there is also one or two guys reporting this locking issue,
> so we need to be very sure.

I'm afraid you misunderstood me. The rt28* issue is on a different
system with an Ralink adapter. AFAIK the actual rt28* modules have
nothing to do with the Atheros problem. I only made a connection because
the symptoms are so similar, and I thought it possible that the two
different drivers might share some code, but it's more likely to be a
coincidence.

Has anyone else reported the rt28* problem and/or are the developers
aware of it? I know I'm not the only affected person because I read
about it in a customer comment on the vendor's web site for the Acer
R3700.

> >> for quick check please try with the latest compat wireless.
> >
> > How do I do that?
> >
> > I would also be willing to add extra debugging messages to ath9k to
> > help track down the AR9285 problem. I'm a C programmer, but not a
> > kernel hacker so I think I would need some advice about which
> > functions to examine.
> 
> No its nothing to do with kernel hacking, its just a wireless package.

For kernel hacking I meant I would like to experiment with the code
myself. If you can't reproduce the problem I think it would be very
helpful if I can make it print extra messages to narrow it down. If you
could tell me something like, "The shutdown process should start at
function X and end at function Y," I'll know better which code to
experiment with. BTW, all types of wireless shutdown seem to be
affected, whether I turn off the WAP, click Disconnect in network
manager, press the rfkill switch, suspend, shutdown or rmmod ath9k.

Should I use printk to print the debugging messages or something else?
As there is the debug module parameter I guess the latter. Is there also
some sort of sleep function which I can safely add after each debug
message to make sure the message is made visible before the crash?

Re: Could ath9k and rt2800pci bugs be related?

[Tony Houghton]

On Tue, 15 Mar 2011 19:05:27 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> No its nothing to do with kernel hacking, its just a wireless package.
> instead of compiling the whole kernel or wireless testing, we can
> install a wireless package within our linux distribution in few
> minutes. This package is called compat-wireless which includes latest
> fixes in wireless testing.
> more information in:
> http://wireless.kernel.org/en/users/Download

I tried that and I can confirm that it still crashes. I used the
compat-wireless-2011-03-14 snapshot with a Debian stock 2.6.37-2 kernel.

BTW one of the files had an error with TASK_INTERRUPTIBLE undefined. I
can't remember which file because I forgot to make a note of it before
make wlunload caused the expected crash. The apparent cause was that
/usr/include/linux/sched.h contains far less than sched.h in the kernel
source. I worked around it by defining the macro as 1 at the top of the
affected file.

Re: Could ath9k and rt2800pci bugs be related?

[Mohammed Shafi]

On Tue, Mar 15, 2011 at 8:47 PM, Tony Houghton <h@realh.co.uk> wrote:
> On Tue, 15 Mar 2011 19:05:27 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> On Tue, Mar 15, 2011 at 6:49 PM, Tony Houghton <h@realh.co.uk> wrote:
>> > On Tue, 15 Mar 2011 13:17:40 +0530
>> > Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>> >
>> >> On Mon, Mar 14, 2011 at 10:18 PM, Tony Houghton <h@realh.co.uk>
>> >> wrote:
>> >> >
>> >> > I've just bought an Acer Aspire Revo 3700 and this had very
>> >> > similar symptoms with a different adapter. Luckily another
>> >> > customer had posted about it on the vendor's website and his fix
>> >> > works for me. The fix is to blacklist the rt2800pci module and
>> >> > the rt2860sta driver seems to work quite happily without it.
>> >>
>> >> can you please check by disabling the supicious rt modules and see
>> >> whether this problems happens.
>> >
>> > Yes, I did blacklist rt2800pci and the system works correctly
>> > without the module loaded. Even the wireless connection still works.
>>
>> Ok still there is also one or two guys reporting this locking issue,
>> so we need to be very sure.
>
> I'm afraid you misunderstood me. The rt28* issue is on a different
> system with an Ralink adapter. AFAIK the actual rt28* modules have
> nothing to do with the Atheros problem. I only made a connection because
> the symptoms are so similar, and I thought it possible that the two
> different drivers might share some code, but it's more likely to be a
> coincidence.

Ok fine.

>
> Has anyone else reported the rt28* problem and/or are the developers
> aware of it? I know I'm not the only affected person because I read
> about it in a customer comment on the vendor's web site for the Acer
> R3700.

 no i am not aware of it.

>
>> >> for quick check please try with the latest compat wireless.
>> >
>> > How do I do that?
>> >
>> > I would also be willing to add extra debugging messages to ath9k to
>> > help track down the AR9285 problem. I'm a C programmer, but not a
>> > kernel hacker so I think I would need some advice about which
>> > functions to examine.
>>
>> No its nothing to do with kernel hacking, its just a wireless package.
>
> For kernel hacking I meant I would like to experiment with the code
> myself. If you can't reproduce the problem I think it would be very
> helpful if I can make it print extra messages to narrow it down. If you
> could tell me something like, "The shutdown process should start at
> function X and end at function Y," I'll know better which code to
> experiment with. BTW, all types of wireless shutdown seem to be
> affected, whether I turn off the WAP, click Disconnect in network
> manager, press the rfkill switch, suspend, shutdown or rmmod ath9k.

i dont know what to say, may be you can look at
vim /drivers/net/wireless/ath/ath9k/pci.c
and
vim /net/mac80211/pm.c
let me also see if i can get the problem reproduced

>
> Should I use printk to print the debugging messages or something else?
> As there is the debug module parameter I guess the latter. Is there also
> some sort of sleep function which I can safely add after each debug
> message to make sure the message is made visible before the crash?

printk is sufficient and if you can enable all debugs by ath9k debug=0xfffffffff
> --
> 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
>

Re: Could ath9k and rt2800pci bugs be related?

[Tony Houghton]

On Tue, 15 Mar 2011 21:47:14 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> i dont know what to say, may be you can look at
> vim /drivers/net/wireless/ath/ath9k/pci.c
> and
> vim /net/mac80211/pm.c
> let me also see if i can get the problem reproduced

When I installed wireless-compat it didn't replace all the modules it
provides, only the ones I'd activated with driver-select ath9k. I didn't
notice whether mac80211 drivers got replaced too. If I want to alter
pm.c do I need to add anything to the driver-select line to make sure my
altered version gets installed?

Re: Could ath9k and rt2800pci bugs be related?

[Mohammed Shafi]

On Tue, Mar 15, 2011 at 10:45 PM, Tony Houghton <h@realh.co.uk> wrote:
> On Tue, 15 Mar 2011 21:47:14 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> i dont know what to say, may be you can look at
>> vim /drivers/net/wireless/ath/ath9k/pci.c
>> and
>> vim /net/mac80211/pm.c
>> let me also see if i can get the problem reproduced
>
> When I installed wireless-compat it didn't replace all the modules it
> provides, only the ones I'd activated with driver-select ath9k. I didn't
> notice whether mac80211 drivers got replaced too. If I want to alter
> pm.c do I need to add anything to the driver-select line to make sure my
> altered version gets installed?
>
No it won't be necessary. recompilation takes care of it.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

Hi all,

I've been talking privately with Tony and I think we've narrowed down
what's going on.

In short - the pcie powersave stuff is somehow messed up.

On 25 February 2011 04:02, Jonathan Nieder <jrnieder@gmail.com> wrote:

>> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f is the first bad commit
>> commit 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
>> Author: Vivek Natarajan <vnatarajan@atheros.com>
>> Date: ? Mon Apr 5 14:48:04 2010 +0530
>>
>> ? ? ath9k: Add support for newer AR9285 chipsets.

The long: the AR9285_WA_DEFAULT change in the above patch causes
Tony's NIC to become unstable when powered down.

The long(er): When he tested the latest wireless-testing tree with the
AR9285_WA_DEFAULT value reverted, he had the same problem.
Since the pcie powersave function has changed considerably between
that above commit and today, there's also very likely something subtly
evil going on.

Given that we've now narrowed down the specific change that's causing
this, and that the latest ath9k ath9k_hw_configpcipowersave() function
is doing quite a bit different (and I think disabling those bits too),
I think we can conclude that there's something strange going on.

What I haven't yet tried is getting Tony to test wireless-testing but
with an older ath9k_hw_configpcipowersave().

Since this is affecting a variety of people, would it be possible to
get it looked at by someone with a better understanding of the PCIe
power saving/APSM stuff?

I hereby punt this to Atheros/Qualcomm to resolve. :)



Adrian

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Fri, Jun 10, 2011 at 7:17 AM, Adrian Chadd <adrian@freebsd.org> wrote:
> Hi all,
>
> I've been talking privately with Tony and I think we've narrowed down
> what's going on.
>
> In short - the pcie powersave stuff is somehow messed up.
>
> On 25 February 2011 04:02, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
>>> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f is the first bad commit
>>> commit 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
>>> Author: Vivek Natarajan <vnatarajan@atheros.com>
>>> Date: ? Mon Apr 5 14:48:04 2010 +0530
>>>
>>> ? ? ath9k: Add support for newer AR9285 chipsets.
>
> The long: the AR9285_WA_DEFAULT change in the above patch causes
> Tony's NIC to become unstable when powered down.

but we had verified in the internal code base and the change looks
correct. you can also a take look at it. there are also some comments
regarding the lock up. i think they had taken this value as a best
combination as we had lock-up problems with different platforms.

>
> The long(er): When he tested the latest wireless-testing tree with the
> AR9285_WA_DEFAULT value reverted, he had the same problem.
> Since the pcie powersave function has changed considerably between
> that above commit and today, there's also very likely something subtly
> evil going on.
>
> Given that we've now narrowed down the specific change that's causing
> this, and that the latest ath9k ath9k_hw_configpcipowersave() function
> is doing quite a bit different (and I think disabling those bits too),
> I think we can conclude that there's something strange going on.
>
> What I haven't yet tried is getting Tony to test wireless-testing but
> with an older ath9k_hw_configpcipowersave().
>
> Since this is affecting a variety of people, would it be possible to
> get it looked at by someone with a better understanding of the PCIe
> power saving/APSM stuff?
>
> I hereby punt this to Atheros/Qualcomm to resolve. :)
>
>
>
> Adrian
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>



-- 
shafi

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

On 10 June 2011 12:52, Mohammed Shafi <shafi.wireless@gmail.com> wrote:

>>>> ? ? ath9k: Add support for newer AR9285 chipsets.
>>
>> The long: the AR9285_WA_DEFAULT change in the above patch causes
>> Tony's NIC to become unstable when powered down.
>
> but we had verified in the internal code base and the change looks
> correct. you can also a take look at it. there are also some comments
> regarding the lock up. i think they had taken this value as a best
> combination as we had lock-up problems with different platforms.

Right. But I bet that its something different between current Linux
PCI(e) and power saving setup/handling versus say, earlier Linux code,
and/or differences between the above and Windows. So I bet the driver
is fine when paired up against a specific version/config of Linux (And
windows. :)

If someone buys me the exact model laptop, then sure, I'll help debug
it. :) It doesn't happen on any of the hardware I currently have!


Adrian

Re: ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

Hi all,

This patch against the current wireless-testing tree restores bit 6/7
being set for the AR9285.

Tony, would you please test this out and see if this works? This is
against the latest wireless-testing.

Thanks,


Adrian

diff --git a/drivers/net/wireless/ath/ath9k/ar9002_hw.c
b/drivers/net/wireless/ath/ath9k/ar9002_hw.c
index f344cc2..5e4e37f 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_hw.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_hw.c
@@ -384,6 +384,7 @@ static void ar9002_hw_configpcipowersave(struct ath_hw *ah,
                        }
                }

+#if 0
                if (AR_SREV_9280(ah) || AR_SREV_9285(ah) || AR_SREV_9287(ah)) {
                        /*
                         * Disable bit 6 and 7 before entering D3 to
@@ -391,6 +392,7 @@ static void ar9002_hw_configpcipowersave(struct ath_hw *ah,
                         */
                        val &= ~(AR_WA_BIT6 | AR_WA_BIT7);
                }
+#endif

                if (AR_SREV_9280(ah))
                        val |= AR_WA_BIT22;
diff --git a/drivers/net/wireless/ath/ath9k/reg.h
b/drivers/net/wireless/ath/ath9k/reg.h
index c18ee99..a3c893d 100644
--- a/drivers/net/wireless/ath/ath9k/reg.h
+++ b/drivers/net/wireless/ath/ath9k/reg.h
@@ -704,7 +704,7 @@
 #define AR_WA_ANALOG_SHIFT              (1 << 20)
 #define AR_WA_POR_SHORT                 (1 << 21) /* PCI-E Phy reset control */
 #define AR_WA_BIT22                    (1 << 22)
-#define AR9285_WA_DEFAULT              0x004a050b
+#define AR9285_WA_DEFAULT              0x004a05cb
 #define AR9280_WA_DEFAULT              0x0040073b
 #define AR_WA_DEFAULT                  0x0000073f

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

Hi all,

This patch against the current wireless-testing tree restores bit 6/7
being set for the AR9285.

Tony, would you please test this out and see if this works? This is
against the latest wireless-testing.

Thanks,


Adrian

diff --git a/drivers/net/wireless/ath/ath9k/ar9002_hw.c
b/drivers/net/wireless/ath/ath9k/ar9002_hw.c
index f344cc2..5e4e37f 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_hw.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_hw.c
@@ -384,6 +384,7 @@ static void ar9002_hw_configpcipowersave(struct ath_hw *ah,
                        }
                }

+#if 0
                if (AR_SREV_9280(ah) || AR_SREV_9285(ah) || AR_SREV_9287(ah)) {
                        /*
                         * Disable bit 6 and 7 before entering D3 to
@@ -391,6 +392,7 @@ static void ar9002_hw_configpcipowersave(struct ath_hw *ah,
                         */
                        val &= ~(AR_WA_BIT6 | AR_WA_BIT7);
                }
+#endif

                if (AR_SREV_9280(ah))
                        val |= AR_WA_BIT22;
diff --git a/drivers/net/wireless/ath/ath9k/reg.h
b/drivers/net/wireless/ath/ath9k/reg.h
index c18ee99..a3c893d 100644
--- a/drivers/net/wireless/ath/ath9k/reg.h
+++ b/drivers/net/wireless/ath/ath9k/reg.h
@@ -704,7 +704,7 @@
 #define AR_WA_ANALOG_SHIFT              (1 << 20)
 #define AR_WA_POR_SHORT                 (1 << 21) /* PCI-E Phy reset control */
 #define AR_WA_BIT22                    (1 << 22)
-#define AR9285_WA_DEFAULT              0x004a050b
+#define AR9285_WA_DEFAULT              0x004a05cb
 #define AR9280_WA_DEFAULT              0x0040073b
 #define AR_WA_DEFAULT                  0x0000073f

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Camilo Mesias]

Hmm it sounds like a fast approaching dead end, the amount of effort
to solve the problem vs. the number of people affected doesn't look
good.

I think I will try to update the BIOS with one that removes the PCI ID
whitelist and so supports the Intel card I have bought...

-Cam

On Fri, Jun 10, 2011 at 7:13 AM, Adrian Chadd <adrian@freebsd.org> wrote:
> On 10 June 2011 12:52, Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>>>>> ? ? ath9k: Add support for newer AR9285 chipsets.
>>>
>>> The long: the AR9285_WA_DEFAULT change in the above patch causes
>>> Tony's NIC to become unstable when powered down.
>>
>> but we had verified in the internal code base and the change looks
>> correct. you can also a take look at it. there are also some comments
>> regarding the lock up. i think they had taken this value as a best
>> combination as we had lock-up problems with different platforms.
>
> Right. But I bet that its something different between current Linux
> PCI(e) and power saving setup/handling versus say, earlier Linux code,
> and/or differences between the above and Windows. So I bet the driver
> is fine when paired up against a specific version/config of Linux (And
> windows. :)
>
> If someone buys me the exact model laptop, then sure, I'll help debug
> it. :) It doesn't happen on any of the hardware I currently have!
>
>
> Adrian
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

On 10 June 2011 14:51, Camilo Mesias <camilo@mesias.co.uk> wrote:
> Hmm it sounds like a fast approaching dead end, the amount of effort
> to solve the problem vs. the number of people affected doesn't look
> good.
>
> I think I will try to update the BIOS with one that removes the PCI ID
> whitelist and so supports the Intel card I have bought...

Oh no, I'll get it licked eventually, I just would like a very
detailed list of exactly what laptop model(s), with chipset and bios
details.

It may be that some chipsets require the power saving bits to be
handled differently due to bus code or bus hardware bugs. I absolutely
don't pray to know anything about this area, but I'll at least try to
get a workaround in place whilst Those Who Know More can take a look
at it.

The trouble I have right now is that I don't have any hardware that
exhibits this behaviour so I can't begin to really do any in-depth
debugging.. :/


adrian

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Fri, 10 Jun 2011 14:53:17 +0800
Adrian Chadd <adrian@freebsd.org> wrote:

> The trouble I have right now is that I don't have any hardware that
> exhibits this behaviour so I can't begin to really do any in-depth
> debugging.. :/

Do any developers willing to work on this live in the UK, or at least in
Europe? I'm almost certainly going to replace this netbook very soon
(for other reasons as well as this bug) and I'd be willing to loan it to
a developer for a while to get this bug fixed, but AFAICT Adrian lives
in Australia, so shipping charges make it impractical. Alternatively, if
you (Adrian) have another laptop/netbook you could plug the adapter in
to, I could send just that to keep the cost down. But it might turn out
to work in conjunction with other hardware!

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

On 10 June 2011 20:43, Tony Houghton <h@realh.co.uk> wrote:

> Do any developers willing to work on this live in the UK, or at least in
> Europe? I'm almost certainly going to replace this netbook very soon
> (for other reasons as well as this bug) and I'd be willing to loan it to
> a developer for a while to get this bug fixed, but AFAICT Adrian lives
> in Australia, so shipping charges make it impractical. Alternatively, if
> you (Adrian) have another laptop/netbook you could plug the adapter in
> to, I could send just that to keep the cost down. But it might turn out
> to work in conjunction with other hardware!

It's very likely in conjunction with your chipset and kernel build options.

I have a nice selection of AR9285's to choose from too. They all work
fine in whatever PCIe hardware I have. It's going to be something
strange with the combination of linux kernel version/build and the
chipset/bios features.

Let's just try the patch I emailed you to apply to wireless-testing.
Hopefully that restores functionality enough and we can punt it to the
Atheros guys to do some further investigation.


Adrian

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

Good news below, read on :-).

On Fri, 10 Jun 2011 21:18:37 +0800
Adrian Chadd <adrian@freebsd.org> wrote:

> It's very likely in conjunction with your chipset and kernel build
> options.
> 
> I have a nice selection of AR9285's to choose from too. They all work
> fine in whatever PCIe hardware I have. It's going to be something
> strange with the combination of linux kernel version/build and the
> chipset/bios features.

And/or possibly even something specific to the UK or Europe? I think I
heard there are some subtle differences in the wifi standard depending
on region.

I have tried quite a few different kernel versions, including Ubuntu
(2.6.35) as well as Debian 2.6.37 through -39 and the crash has been
very consistent on everything since 2.6.35 (or 2.6.33 with the "bad"
commit).

> Let's just try the patch I emailed you to apply to wireless-testing.
> Hopefully that restores functionality enough and we can punt it to the
> Atheros guys to do some further investigation.

That change seems to have fixed it! I've managed at least 3
suspend/resumes and an rmmod/modprobe without crashing. Perhaps a little
early to say it's definitely fixed, but I don't think I've ever managed
more than 2 attempts in a row without a "bad" version crashing.

PS I used compat-wireless rather than testing. I tried to build it for
2.6.39-2-686-pae (the name for the Debian stock kernel) while running on
2.6.32, but I couldn't work out how. The kernel's top-level Makefile
offers no clues. From compat-wireless' Makefile I deduced I could set
KLIB=/lib/modules/2.6.39-2-686-pae. It built OK but installed the
modules under
/lib/modules/2.6.39-2-686-pae/lib/modules/2.6.39-2-686-pae/updates
instead of /lib/modules/2.6.39-2-686-pae/updates/ and depmod didn't seem
to recognise that. What variable should I have set?

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

On 11 June 2011 02:47, Tony Houghton <h@realh.co.uk> wrote:
> Good news below, read on :-).

Yay!

> And/or possibly even something specific to the UK or Europe? I think I
> heard there are some subtle differences in the wifi standard depending
> on region.

The wifi regulatory stuff shouldn't matter. Unless the regional
differences have to do with power saving. ;)

> I have tried quite a few different kernel versions, including Ubuntu
> (2.6.35) as well as Debian 2.6.37 through -39 and the crash has been
> very consistent on everything since 2.6.35 (or 2.6.33 with the "bad"
> commit).

:(

>> Let's just try the patch I emailed you to apply to wireless-testing.
>> Hopefully that restores functionality enough and we can punt it to the
>> Atheros guys to do some further investigation.
>
> That change seems to have fixed it! I've managed at least 3
> suspend/resumes and an rmmod/modprobe without crashing. Perhaps a little
> early to say it's definitely fixed, but I don't think I've ever managed
> more than 2 attempts in a row without a "bad" version crashing.

Excellent! Let's see if it fixes it for other users.
Camilo? :)

> PS I used compat-wireless rather than testing. I tried to build it for
> 2.6.39-2-686-pae (the name for the Debian stock kernel) while running on
> 2.6.32, but I couldn't work out how. The kernel's top-level Makefile
> offers no clues. From compat-wireless' Makefile I deduced I could set
> KLIB=/lib/modules/2.6.39-2-686-pae. It built OK but installed the
> modules under
> /lib/modules/2.6.39-2-686-pae/lib/modules/2.6.39-2-686-pae/updates
> instead of /lib/modules/2.6.39-2-686-pae/updates/ and depmod didn't seem
> to recognise that. What variable should I have set?

I've no idea. I'm not a Linux developer. :-)
compat-wireless is fine though!


Adrian

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Camilo Mesias]

Hi,

On Fri, Jun 10, 2011 at 5:10 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> On 11 June 2011 02:47, Tony Houghton <h@realh.co.uk> wrote:
[...]
>>> Let's just try the patch I emailed you to apply to wireless-testing.
>>> Hopefully that restores functionality enough and we can punt it to the
>>> Atheros guys to do some further investigation.
>>
>> That change seems to have fixed it! I've managed at least 3
>> suspend/resumes and an rmmod/modprobe without crashing. Perhaps a little
>> early to say it's definitely fixed, but I don't think I've ever managed
>> more than 2 attempts in a row without a "bad" version crashing.
>
> Excellent! Let's see if it fixes it for other users.
> Camilo? :)

I had some problems with the wireless-testing software but managed to
rebuild the current kernel from source (2.6.38.7-30.fc15.i686) then
commented out the relevant driver part and changed the
AR9285_WA_DEFAULT value too. I made sure I was running the rebuilt
modules and... it works. I suspended and resumed just fine.

I'm not sure how I can quickly get a clean fix, I think this might be
tweakable with the patch:

http://people.redhat.com/sgruszka/compact_wireless.html

Or I could just stay on my bodged kernel for a while (although this
doesn't help anyone else)

Thanks for all the help, it looks like my netbook is useful again :D

-Cam

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

ok. Mohammed, APSM is broken in a different way on some laptops. maybe
the state transition between sleep states is different somehow.

Which model notebook is this Camilo? :)


adrian

On 11 June 2011 14:42, Camilo Mesias <camilo@mesias.co.uk> wrote:
> Hi,
>
> On Fri, Jun 10, 2011 at 5:10 PM, Adrian Chadd <adrian@freebsd.org> wrote:
>> On 11 June 2011 02:47, Tony Houghton <h@realh.co.uk> wrote:
> [...]
>>>> Let's just try the patch I emailed you to apply to wireless-testing.
>>>> Hopefully that restores functionality enough and we can punt it to the
>>>> Atheros guys to do some further investigation.
>>>
>>> That change seems to have fixed it! I've managed at least 3
>>> suspend/resumes and an rmmod/modprobe without crashing. Perhaps a little
>>> early to say it's definitely fixed, but I don't think I've ever managed
>>> more than 2 attempts in a row without a "bad" version crashing.
>>
>> Excellent! Let's see if it fixes it for other users.
>> Camilo? :)
>
> I had some problems with the wireless-testing software but managed to
> rebuild the current kernel from source (2.6.38.7-30.fc15.i686) then
> commented out the relevant driver part and changed the
> AR9285_WA_DEFAULT value too. I made sure I was running the rebuilt
> modules and... it works. I suspended and resumed just fine.
>
> I'm not sure how I can quickly get a clean fix, I think this might be
> tweakable with the patch:
>
> http://people.redhat.com/sgruszka/compact_wireless.html
>
> Or I could just stay on my bodged kernel for a while (although this
> doesn't help anyone else)
>
> Thanks for all the help, it looks like my netbook is useful again :D
>
> -Cam
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Camilo Mesias]

Hi,

it's a HP/Compaq Mini 311c-1101sa

Here is a 'smolt' report if that helps:
http://www.smolts.org/client/show/pub_324e9961-79a1-4fdf-a3ab-7a64bb330245

I will update Fedora's bugzilla bug with the info about the patch working.

https://bugzilla.redhat.com/show_bug.cgi?id=697157

-Cam


On Sat, Jun 11, 2011 at 3:12 AM, Adrian Chadd <adrian@freebsd.org> wrote:
> ok. Mohammed, APSM is broken in a different way on some laptops. maybe
> the state transition between sleep states is different somehow.
>
> Which model notebook is this Camilo? :)
>
>
> adrian
>
> On 11 June 2011 14:42, Camilo Mesias <camilo@mesias.co.uk> wrote:
>> Hi,
>>
>> On Fri, Jun 10, 2011 at 5:10 PM, Adrian Chadd <adrian@freebsd.org> wrote:
>>> On 11 June 2011 02:47, Tony Houghton <h@realh.co.uk> wrote:
>> [...]
>>>>> Let's just try the patch I emailed you to apply to wireless-testing.
>>>>> Hopefully that restores functionality enough and we can punt it to the
>>>>> Atheros guys to do some further investigation.
>>>>
>>>> That change seems to have fixed it! I've managed at least 3
>>>> suspend/resumes and an rmmod/modprobe without crashing. Perhaps a little
>>>> early to say it's definitely fixed, but I don't think I've ever managed
>>>> more than 2 attempts in a row without a "bad" version crashing.
>>>
>>> Excellent! Let's see if it fixes it for other users.
>>> Camilo? :)
>>
>> I had some problems with the wireless-testing software but managed to
>> rebuild the current kernel from source (2.6.38.7-30.fc15.i686) then
>> commented out the relevant driver part and changed the
>> AR9285_WA_DEFAULT value too. I made sure I was running the rebuilt
>> modules and... it works. I suspended and resumed just fine.
>>
>> I'm not sure how I can quickly get a clean fix, I think this might be
>> tweakable with the patch:
>>
>> http://people.redhat.com/sgruszka/compact_wireless.html
>>
>> Or I could just stay on my bodged kernel for a while (although this
>> doesn't help anyone else)
>>
>> Thanks for all the help, it looks like my netbook is useful again :D
>>
>> -Cam
>>
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Camilo Mesias]

Hi,

As a side issue, I remember trying pcie_aspm=off as a boot parameter
and interestingly the output of lspci seemed to show it wasn't
disabled in all entries. Is this a bug? Should ath9k in particular
honour this boot option?

[root at newt ~]# lspci -vvv|egrep '^[0-9]|ASPM'

00:00.0 Host bridge: nVidia Corporation MCP79 Host Bridge (rev b1)
00:00.1 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
00:03.0 ISA bridge: nVidia Corporation MCP79 LPC Bridge (rev b3)
00:03.1 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
00:03.2 SMBus: nVidia Corporation MCP79 SMBus (rev b1)
00:03.3 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
00:03.5 Co-processor: nVidia Corporation MCP79 Co-processor (rev b1)
00:04.0 USB Controller: nVidia Corporation MCP79 OHCI USB 1.1
Controller (rev b1) (prog-if 10 [OHCI])
00:04.1 USB Controller: nVidia Corporation MCP79 EHCI USB 2.0
Controller (rev b1) (prog-if 20 [EHCI])
00:06.0 USB Controller: nVidia Corporation MCP79 OHCI USB 1.1
Controller (rev b1) (prog-if 10 [OHCI])
00:06.1 USB Controller: nVidia Corporation MCP79 EHCI USB 2.0
Controller (rev b1) (prog-if 20 [EHCI])
00:08.0 Audio device: nVidia Corporation MCP79 High Definition Audio (rev b1)
00:09.0 PCI bridge: nVidia Corporation MCP79 PCI Bridge (rev b1)
(prog-if 01 [Subtractive decode])
00:0a.0 Ethernet controller: nVidia Corporation MCP79 Ethernet (rev b1)
00:0b.0 SATA controller: nVidia Corporation MCP79 AHCI Controller (rev
b1) (prog-if 01 [AHCI 1.0])
00:10.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev
b1) (prog-if 00 [Normal decode])
00:15.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev
b1) (prog-if 00 [Normal decode])
		LnkCap:	Port #3, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0
<512ns, L1 <4us
		LnkCtl:	ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk-
   ^^^ enabled here?

00:16.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev
b1) (prog-if 00 [Normal decode])
		LnkCap:	Port #4, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0
<512ns, L1 <4us
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
   ^^^ disabled here, good

02:00.0 VGA compatible controller: nVidia Corporation ION LE VGA (rev
b1) (prog-if 00 [VGA controller])
03:00.0 Network controller: Atheros Communications Inc. AR9285
Wireless Network Adapter (PCI-Express) (rev 01)
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0
<512ns, L1 <64us
		LnkCtl:	ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk-
   ^^^ not disabled for ath9k, bug?

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrià Cereto Massagué]

Hi,

I'm trying that patch on debian amd64 with 2.6.39 kernel from repos,
manually applied against latest compat-wireless, and so far it seems to work
:)

I've been able to connect to a network, where before the patch just bringing
the interface up would have frozen the OS.

2011/6/11 Camilo Mesias <camilo@mesias.co.uk>

> Hi,
>
> As a side issue, I remember trying pcie_aspm=off as a boot parameter
> and interestingly the output of lspci seemed to show it wasn't
> disabled in all entries. Is this a bug? Should ath9k in particular
> honour this boot option?
>
> [root at newt ~]# lspci -vvv|egrep '^[0-9]|ASPM'
>
> 00:00.0 Host bridge: nVidia Corporation MCP79 Host Bridge (rev b1)
> 00:00.1 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
> 00:03.0 ISA bridge: nVidia Corporation MCP79 LPC Bridge (rev b3)
> 00:03.1 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
> 00:03.2 SMBus: nVidia Corporation MCP79 SMBus (rev b1)
> 00:03.3 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
> 00:03.5 Co-processor: nVidia Corporation MCP79 Co-processor (rev b1)
> 00:04.0 USB Controller: nVidia Corporation MCP79 OHCI USB 1.1
> Controller (rev b1) (prog-if 10 [OHCI])
> 00:04.1 USB Controller: nVidia Corporation MCP79 EHCI USB 2.0
> Controller (rev b1) (prog-if 20 [EHCI])
> 00:06.0 USB Controller: nVidia Corporation MCP79 OHCI USB 1.1
> Controller (rev b1) (prog-if 10 [OHCI])
> 00:06.1 USB Controller: nVidia Corporation MCP79 EHCI USB 2.0
> Controller (rev b1) (prog-if 20 [EHCI])
> 00:08.0 Audio device: nVidia Corporation MCP79 High Definition Audio (rev
> b1)
> 00:09.0 PCI bridge: nVidia Corporation MCP79 PCI Bridge (rev b1)
> (prog-if 01 [Subtractive decode])
> 00:0a.0 Ethernet controller: nVidia Corporation MCP79 Ethernet (rev b1)
> 00:0b.0 SATA controller: nVidia Corporation MCP79 AHCI Controller (rev
> b1) (prog-if 01 [AHCI 1.0])
> 00:10.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev
> b1) (prog-if 00 [Normal decode])
> 00:15.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev
> b1) (prog-if 00 [Normal decode])
>                LnkCap: Port #3, Speed 5GT/s, Width x1, ASPM L0s L1, Latency
> L0
> <512ns, L1 <4us
>                LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain-
> CommClk-
>   ^^^ enabled here?
>
> 00:16.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev
> b1) (prog-if 00 [Normal decode])
>                LnkCap: Port #4, Speed 2.5GT/s, Width x1, ASPM L0s L1,
> Latency L0
> <512ns, L1 <4us
>                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
> CommClk-
>   ^^^ disabled here, good
>
> 02:00.0 VGA compatible controller: nVidia Corporation ION LE VGA (rev
> b1) (prog-if 00 [VGA controller])
> 03:00.0 Network controller: Atheros Communications Inc. AR9285
> Wireless Network Adapter (PCI-Express) (rev 01)
>                 LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
> Latency L0
> <512ns, L1 <64us
>                 LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain-
> CommClk-
>   ^^^ not disabled for ath9k, bug?
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>



-- 
*Adri? Cereto Massagu?*
Biotechnology student
Universitat Rovira i Virgili

Languages: Catal?, Espa?ol, English, Fran?ais, Deutsch, Portugu?s, Esperanto

Nota importante
<http://www.gnu.org/philosophy/no-word-attachments.es.html>| Important
Notice <http://www.gnu.org/philosophy/no-word-attachments.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110612/e9783c0c/attachment.htm 

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

2011/6/12 Adri? Cereto Massagu? <ssorgatem@gmail.com>:
> Hi,
>
> I'm trying that patch on debian amd64 with 2.6.39 kernel from repos,
> manually applied against latest compat-wireless, and so far it seems to work
> :)
>
> I've been able to connect to a network, where before the patch just bringing
> the interface up would have frozen the OS.

What laptop are you using? What hardware is in it?


Adrian

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrià Cereto Massagué]

It's a Packard-Bell dot m/a, the european version of the Gateway LT31.
Here is the output of lspci:

ssorgatem at mrasp134:~$ lspci
00:00.0 Host bridge: ATI Technologies Inc RS690 Host Bridge
00:01.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (Internal
gfx)
00:05.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI
Express Port 1)
00:06.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI
Express Port 2)
00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA
00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0)
00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1)
00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3)
00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4)
00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI)
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 14)
00:14.1 IDE interface: ATI Technologies Inc SB600 IDE
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200
Series]
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)
04:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless
Network Adapter (PCI-Express) (rev 01)

El 12 de juny de 2011 10:01, Adrian Chadd <adrian@freebsd.org> ha escrit:

> 2011/6/12 Adri? Cereto Massagu? <ssorgatem@gmail.com>:
> > Hi,
> >
> > I'm trying that patch on debian amd64 with 2.6.39 kernel from repos,
> > manually applied against latest compat-wireless, and so far it seems to
> work
> > :)
> >
> > I've been able to connect to a network, where before the patch just
> bringing
> > the interface up would have frozen the OS.
>
> What laptop are you using? What hardware is in it?
>
>
> Adrian
>



-- 
*Adri? Cereto Massagu?*
Biotechnology student
Universitat Rovira i Virgili

Languages: Catal?, Espa?ol, English, Fran?ais, Deutsch, Portugu?s, Esperanto

Nota importante
<http://www.gnu.org/philosophy/no-word-attachments.es.html>| Important
Notice <http://www.gnu.org/philosophy/no-word-attachments.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110612/37fcc8e0/attachment.htm 

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

2011/6/12 Adri? Cereto Massagu? <ssorgatem@gmail.com>:
> It's a Packard-Bell dot m/a, the european version of the Gateway LT31.
> Here is the output of lspci:

So what CPU/peripheral chipset is it?


Adrian

Re: ath9k causes lockups since kernel 2.6.35

[Stanislaw Gruszka]

On Fri, Jun 10, 2011 at 02:48:00PM +0800, Adrian Chadd wrote:
> This patch against the current wireless-testing tree restores bit 6/7
> being set for the AR9285.
> 
> Tony, would you please test this out and see if this works? This is
> against the latest wireless-testing.

cam a fedora user, confirms that patch fixes the locks-ups
https://bugzilla.redhat.com/show_bug.cgi?id=697157#c26

We are waiting for fix now :-)

Thanks
Stanislaw

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Stanislaw Gruszka]

On Fri, Jun 10, 2011 at 02:48:00PM +0800, Adrian Chadd wrote:
> This patch against the current wireless-testing tree restores bit 6/7
> being set for the AR9285.
> 
> Tony, would you please test this out and see if this works? This is
> against the latest wireless-testing.

cam a fedora user, confirms that patch fixes the locks-ups
https://bugzilla.redhat.com/show_bug.cgi?id=697157#c26

We are waiting for fix now :-)

Thanks
Stanislaw

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

Also, is there a kernel.org bugzilla report entry for this? I'll
update it with the relevant information so the regression isn't
forgotten about.

Thanks,


Adrian

On 11 June 2011 15:12, Adrian Chadd <adrian@freebsd.org> wrote:
> ok. Mohammed, APSM is broken in a different way on some laptops. maybe
> the state transition between sleep states is different somehow.
>
> Which model notebook is this Camilo? :)
>
>
> adrian
>
> On 11 June 2011 14:42, Camilo Mesias <camilo@mesias.co.uk> wrote:
>> Hi,
>>
>> On Fri, Jun 10, 2011 at 5:10 PM, Adrian Chadd <adrian@freebsd.org> wrote:
>>> On 11 June 2011 02:47, Tony Houghton <h@realh.co.uk> wrote:
>> [...]
>>>>> Let's just try the patch I emailed you to apply to wireless-testing.
>>>>> Hopefully that restores functionality enough and we can punt it to the
>>>>> Atheros guys to do some further investigation.
>>>>
>>>> That change seems to have fixed it! I've managed at least 3
>>>> suspend/resumes and an rmmod/modprobe without crashing. Perhaps a little
>>>> early to say it's definitely fixed, but I don't think I've ever managed
>>>> more than 2 attempts in a row without a "bad" version crashing.
>>>
>>> Excellent! Let's see if it fixes it for other users.
>>> Camilo? :)
>>
>> I had some problems with the wireless-testing software but managed to
>> rebuild the current kernel from source (2.6.38.7-30.fc15.i686) then
>> commented out the relevant driver part and changed the
>> AR9285_WA_DEFAULT value too. I made sure I was running the rebuilt
>> modules and... it works. I suspended and resumed just fine.
>>
>> I'm not sure how I can quickly get a clean fix, I think this might be
>> tweakable with the patch:
>>
>> http://people.redhat.com/sgruszka/compact_wireless.html
>>
>> Or I could just stay on my bodged kernel for a while (although this
>> doesn't help anyone else)
>>
>> Thanks for all the help, it looks like my netbook is useful again :D
>>
>> -Cam
>>
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Jonathan Nieder]

Hi Adrian,

Adrian Chadd wrote:

> Also, is there a kernel.org bugzilla report entry for this? I'll
> update it with the relevant information so the regression isn't
> forgotten about.

Let's use https://bugzilla.kernel.org/show_bug.cgi?id=37082

Thanks,
Jonathan

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Jonathan Nieder]

Jonathan Nieder wrote:
> Adrian Chadd wrote:

>> Also, is there a kernel.org bugzilla report entry for this? I'll
>> update it with the relevant information so the regression isn't
>> forgotten about.
>
> Let's use https://bugzilla.kernel.org/show_bug.cgi?id=37082

Or even better, a new bug, since that one is about behavior at
startup.  Sorry for the noise.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

On 14 June 2011 08:20, Jonathan Nieder <jrnieder@gmail.com> wrote:

>> Let's use https://bugzilla.kernel.org/show_bug.cgi?id=37082
>
> Or even better, a new bug, since that one is about behavior at
> startup. ?Sorry for the noise.

It could be much the same. But yes, let's create a new bug with the
specific details we've tracked down here. If other bugs are related
they can be linked in at a later date.

Would you mind creating it?


Adrian

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Mon, 13 Jun 2011 19:20:17 -0500
Jonathan Nieder <jrnieder@gmail.com> wrote:

> Jonathan Nieder wrote:
> > Adrian Chadd wrote:
> 
> >> Also, is there a kernel.org bugzilla report entry for this? I'll
> >> update it with the relevant information so the regression isn't
> >> forgotten about.
> >
> > Let's use https://bugzilla.kernel.org/show_bug.cgi?id=37082
> 
> Or even better, a new bug, since that one is about behavior at
> startup.  Sorry for the noise.

Mine would sometimes crash at startup but the crashes at
shutdown/suspend etc were much more consistent.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Sat, Jun 11, 2011 at 12:42 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> ok. Mohammed, APSM is broken in a different way on some laptops. maybe
> the state transition between sleep states is different somehow.
>
> Which model notebook is this Camilo? :)
>
>
> adrian
>
> On 11 June 2011 14:42, Camilo Mesias <camilo@mesias.co.uk> wrote:
>> Hi,
>>
>> On Fri, Jun 10, 2011 at 5:10 PM, Adrian Chadd <adrian@freebsd.org> wrote:
>>> On 11 June 2011 02:47, Tony Houghton <h@realh.co.uk> wrote:
>> [...]
>>>>> Let's just try the patch I emailed you to apply to wireless-testing.
>>>>> Hopefully that restores functionality enough and we can punt it to the
>>>>> Atheros guys to do some further investigation.
>>>>
>>>> That change seems to have fixed it! I've managed at least 3
>>>> suspend/resumes and an rmmod/modprobe without crashing. Perhaps a little
>>>> early to say it's definitely fixed, but I don't think I've ever managed
>>>> more than 2 attempts in a row without a "bad" version crashing.
>>>
>>> Excellent! Let's see if it fixes it for other users.
>>> Camilo? :)
>>
>> I had some problems with the wireless-testing software but managed to
>> rebuild the current kernel from source (2.6.38.7-30.fc15.i686) then
>> commented out the relevant driver part and changed the
>> AR9285_WA_DEFAULT value too. I made sure I was running the rebuilt
>> modules and... it works. I suspended and resumed just fine.
>>
>> I'm not sure how I can quickly get a clean fix, I think this might be
>> tweakable with the patch:
>>
>> http://people.redhat.com/sgruszka/compact_wireless.html
>>
>> Or I could just stay on my bodged kernel for a while (although this
>> doesn't help anyone else)
>>
>> Thanks for all the help, it looks like my netbook is useful again :D

I had removed a check that looks redundant. this will be anyway called
in radio_disable.
 if some one has time and has easy way of applying the patch like in
compat wireless, can they see if it fixes by any chance(less
probably).
FYI I had gone through the pcipowersave module itself and did not find
any obvious deviation apart from some junk work around that need to be
done for AR9285E which does not seems to be related to this

diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index 7f94533..e7f8ef2 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1259,7 +1259,6 @@ static void ath9k_stop(struct ieee80211_hw *hw)

        /* disable HAL and put h/w to sleep */
        ath9k_hw_disable(ah);
-       ath9k_hw_configpcipowersave(ah, 1, 1);

        spin_unlock_bh(&sc->sc_pcu_lock);


>>
>> -Cam
>>
>



-- 
shafi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: remove-redundant-call.patch
Type: text/x-diff
Size: 426 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110614/b10825e1/attachment.patch 

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

On 14 June 2011 21:20, Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> I had removed a check that looks redundant. this will be anyway called
> in radio_disable.
> ?if some one has time and has easy way of applying the patch like in
> compat wireless, can they see if it fixes by any chance(less
> probably).
> FYI I had gone through the pcipowersave module itself and did not find
> any obvious deviation apart from some junk work around that need to be
> done for AR9285E which does not seems to be related to this

Right. I did the same and yes, I came to the same conclusion. So I
figured it wasn't the powersave function itself.

Tony/Camilo, can you revert the patch I've done and see if this patch
from Mohammed Shafi fixes it?

Thanks,


Adrian

> diff --git a/drivers/net/wireless/ath/ath9k/main.c
> b/drivers/net/wireless/ath/ath9k/main.c
> index 7f94533..e7f8ef2 100644
> --- a/drivers/net/wireless/ath/ath9k/main.c
> +++ b/drivers/net/wireless/ath/ath9k/main.c
> @@ -1259,7 +1259,6 @@ static void ath9k_stop(struct ieee80211_hw *hw)
>
> ? ? ? ?/* disable HAL and put h/w to sleep */
> ? ? ? ?ath9k_hw_disable(ah);
> - ? ? ? ath9k_hw_configpcipowersave(ah, 1, 1);
>
> ? ? ? ?spin_unlock_bh(&sc->sc_pcu_lock);
>
>
>>>
>>> -Cam
>>>
>>
>
>
>
> --
> shafi
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Camilo Mesias]

I'll give it a try and report back, might take a couple of days though

-Cam

On Wed, Jun 15, 2011 at 3:02 AM, Adrian Chadd <adrian@freebsd.org> wrote:
> On 14 June 2011 21:20, Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> I had removed a check that looks redundant. this will be anyway called
>> in radio_disable.
>> ?if some one has time and has easy way of applying the patch like in
>> compat wireless, can they see if it fixes by any chance(less
>> probably).
>> FYI I had gone through the pcipowersave module itself and did not find
>> any obvious deviation apart from some junk work around that need to be
>> done for AR9285E which does not seems to be related to this
>
> Right. I did the same and yes, I came to the same conclusion. So I
> figured it wasn't the powersave function itself.
>
> Tony/Camilo, can you revert the patch I've done and see if this patch
> from Mohammed Shafi fixes it?
>
> Thanks,
>
>
> Adrian
>
>> diff --git a/drivers/net/wireless/ath/ath9k/main.c
>> b/drivers/net/wireless/ath/ath9k/main.c
>> index 7f94533..e7f8ef2 100644
>> --- a/drivers/net/wireless/ath/ath9k/main.c
>> +++ b/drivers/net/wireless/ath/ath9k/main.c
>> @@ -1259,7 +1259,6 @@ static void ath9k_stop(struct ieee80211_hw *hw)
>>
>> ? ? ? ?/* disable HAL and put h/w to sleep */
>> ? ? ? ?ath9k_hw_disable(ah);
>> - ? ? ? ath9k_hw_configpcipowersave(ah, 1, 1);
>>
>> ? ? ? ?spin_unlock_bh(&sc->sc_pcu_lock);
>>
>>
>>>>
>>>> -Cam
>>>>
>>>
>>
>>
>>
>> --
>> shafi
>>
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

On 15 June 2011 17:27, Camilo Mesias <camilo@mesias.co.uk> wrote:
> I'll give it a try and report back, might take a couple of days though

No worries, I should be studying..


Adrian

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Wed, Jun 15, 2011 at 10:14 PM, Tony Houghton <h@realh.co.uk> wrote:
> On Tue, 14 Jun 2011 18:50:24 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> I had removed a check that looks redundant. this will be anyway called
>> in radio_disable.
>> ?if some one has time and has easy way of applying the patch like in
>> compat wireless, can they see if it fixes by any chance(less
>> probably).
>> FYI I had gone through the pcipowersave module itself and did not find
>> any obvious deviation apart from some junk work around that need to be
>> done for AR9285E which does not seems to be related to this
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/main.c
>> b/drivers/net/wireless/ath/ath9k/main.c
>> index 7f94533..e7f8ef2 100644
>> --- a/drivers/net/wireless/ath/ath9k/main.c
>> +++ b/drivers/net/wireless/ath/ath9k/main.c
>> @@ -1259,7 +1259,6 @@ static void ath9k_stop(struct ieee80211_hw *hw)
>>
>> ? ? ? ? /* disable HAL and put h/w to sleep */
>> ? ? ? ? ath9k_hw_disable(ah);
>> - ? ? ? ath9k_hw_configpcipowersave(ah, 1, 1);
>>
>> ? ? ? ? spin_unlock_bh(&sc->sc_pcu_lock);
>
> This does seem to work for me (with compat-wireless 2011-06-14). Better
> wait for the other affected people to confirm before committing the fix
> though.

thats surprising because that just removes a redundant call, please
check if you don't have Adrian's work around and also if it works
without this patch itself :-)  may be you can do some stress test to
confirm if you have time
>



-- 
shafi

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Thu, 16 Jun 2011 09:48:21 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> On Wed, Jun 15, 2011 at 10:14 PM, Tony Houghton <h@realh.co.uk> wrote:
> > On Tue, 14 Jun 2011 18:50:24 +0530
> > Mohammed Shafi <shafi.wireless@gmail.com> wrote:
> >
> >> --- a/drivers/net/wireless/ath/ath9k/main.c
> >> +++ b/drivers/net/wireless/ath/ath9k/main.c
> >> @@ -1259,7 +1259,6 @@ static void ath9k_stop(struct ieee80211_hw *hw)
> >>
> >> ? ? ? ? /* disable HAL and put h/w to sleep */
> >> ? ? ? ? ath9k_hw_disable(ah);
> >> - ? ? ? ath9k_hw_configpcipowersave(ah, 1, 1);
> >>
> >> ? ? ? ? spin_unlock_bh(&sc->sc_pcu_lock);
> >
> > This does seem to work for me (with compat-wireless 2011-06-14). Better
> > wait for the other affected people to confirm before committing the fix
> > though.
> 
> thats surprising because that just removes a redundant call, please
> check if you don't have Adrian's work around and also if it works
> without this patch itself :-)  may be you can do some stress test to
> confirm if you have time

I just had a lockup when NetworkManager shut down, so perhaps the patch
didn't work after all, but I'd say it greatly improved behaviour ie it
crashed far less often.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Thu, Jun 16, 2011 at 5:46 PM, Tony Houghton <h@realh.co.uk> wrote:
> On Thu, 16 Jun 2011 09:48:21 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> On Wed, Jun 15, 2011 at 10:14 PM, Tony Houghton <h@realh.co.uk> wrote:
>> > On Tue, 14 Jun 2011 18:50:24 +0530
>> > Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>> >
>> >> --- a/drivers/net/wireless/ath/ath9k/main.c
>> >> +++ b/drivers/net/wireless/ath/ath9k/main.c
>> >> @@ -1259,7 +1259,6 @@ static void ath9k_stop(struct ieee80211_hw *hw)
>> >>
>> >> ? ? ? ? /* disable HAL and put h/w to sleep */
>> >> ? ? ? ? ath9k_hw_disable(ah);
>> >> - ? ? ? ath9k_hw_configpcipowersave(ah, 1, 1);
>> >>
>> >> ? ? ? ? spin_unlock_bh(&sc->sc_pcu_lock);
>> >
>> > This does seem to work for me (with compat-wireless 2011-06-14). Better
>> > wait for the other affected people to confirm before committing the fix
>> > though.
>>
>> thats surprising because that just removes a redundant call, please
>> check if you don't have Adrian's work around and also if it works
>> without this patch itself :-) ?may be you can do some stress test to
>> confirm if you have time
>
> I just had a lockup when NetworkManager shut down, so perhaps the patch
> didn't work after all, but I'd say it greatly improved behaviour ie it
> crashed far less often.
>
:( thought that would fix it by chance



-- 
shafi

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Camilo Mesias]

Hi everyone,

as requested I reverted the patch and tried this alternative, it
wasn't effective. With the redundant code removed, the system still
hung just as it did with the vanilla kernel.

-Cam

On Tue, Jun 14, 2011 at 10:02 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> Tony/Camilo, can you revert the patch I've done and see if this patch
> from Mohammed Shafi fixes it?

Re: ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

Hi guys,

This article just popped up, wrt Linux APSM handling changes and some
rather negative effects..

http://www.phoronix.com/scan.php?page=article&item=linux_2638_aspm&num=2

The commit is: 2f671e2dbff6eb5ef4e2600adbec550c13b8fe72

>From the article:

"Evidently, some BIOSes have their ASPM support misconfigured and thus
problems can arise if the PCI-E link power mode is dropped on an
unsupported device. There are a few mentions of hangs and other issues
under Linux associated with this power management feature. It's not
really a surprise though that the BIOSes would be misconfigured given
all of the other BIOS-related problems under Linux and the once very
poor suspend-and-resume support due to all of the workarounds and
hacks that BIOS/hardware vendors have done to cater towards Microsoft
Windows power management. In this case, it seems a large number of
mobile systems are supporting ASPM but not properly advertising the
support via the standard BIOS ACPI FADT (Fixed ACPI Description
Table). Some Linux drivers even forcibly disable ASPM on Linux (e.g.
this kernel patch)."

Would someone please take charge of testing an unmodified ath9k (ie,
without my APSM disable fix) and try reverting this kernel patch?

Thanks,


Adrian

On 25 February 2011 04:02, Jonathan Nieder <jrnieder@gmail.com> wrote:
> (just cc-ing some people listed in MAINTAINERS)
> Hi,
>
> Tony Houghton wrote:
>
>> With 2.6.37 I can not use suspend on my Compaq/HP 311c (Intel Atom
>> N270/NVidia Ion LE). Originally the machine just kept locking up without
>> even blanking the display when I tried to suspend (using the GNOME menu
>> or by shutting the lid). I upgraded upower and gnome-power-manager etc
>> to experimental and after that the machine suspended OK but could not
>> resume. The backlight came on but the screen stayed blank and I could
>> not get to a console or anything with Alt+Fn.
> [...]
>> I tried replacing network-manager with wicd but that crashed the system
>> when it connected instead of when disconnected.
> [...]
>> While testing different kernels I found it would crash at different
>> times, usually before the screen turned off for suspending, but
>> sometimes it would crash on resuming and occasionally it locked up while
>> booting, but it's always a complete lock-up ie the keyboard is
>> completely responsive, including caps lock, the mouse won't move if the
>> display is still on, and the only way out is to hold down the power
>> button.
> [...]
>> I haven't tried looking in logs because the crashes are so severe I
>> don't think they'd be able to record anything useful. But using git
>> bisect I think I have tracked down the change that started causing this
>> problem:
>>
>> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f is the first bad commit
>> commit 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
>> Author: Vivek Natarajan <vnatarajan@atheros.com>
>> Date:   Mon Apr 5 14:48:04 2010 +0530
>>
>>     ath9k: Add support for newer AR9285 chipsets.
>>
>>     This patch adds support for a modified newer version of AR9285
>>     chipsets.
>>
>>     Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
>>     Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> The adaptor is an AR9285[1].
>
> That commit is based against v2.6.33 and was merged in v2.6.35-rc1
>
> $ git describe 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
> v2.6.33-3523-g53bc7aa
> $ git name-rev --tags 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f tags/v2.6.35-rc1~473^2~167^2~346
>
> Any ideas for tracking this down?
>
> Thanks,
> Jonathan
>
> [1]
>> 84: udi = '/org/freedesktop/Hal/devices/pci_168c_2b'
>>   pci.device_protocol = 0  (0x0)  (int)
>>   pci.vendor = 'Atheros Communications Inc.'  (string)
>>   info.vendor = 'Atheros Communications Inc.'  (string)
>>   pci.product = 'AR9285 Wireless Network Adapter
>> (PCI-Express)'  (string) linux.sysfs_path =
>> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0'  (strin g)
>>   info.parent = '/org/freedesktop/Hal/devices/pci_10de_ac6'  (string)
>>   info.linux.driver = 'ath9k'  (string)
>>   pci.subsys_vendor = 'Hewlett-Packard Company'  (string)
>>   linux.hotplug_type = 2  (0x2)  (int)
>>   linux.subsystem = 'pci'  (string)
>>   info.subsystem = 'pci'  (string)
>>   info.product = 'AR9285 Wireless Network Adapter
>> (PCI-Express)'  (string) info.udi =
>> '/org/freedesktop/Hal/devices/pci_168c_2b'  (string)
>> pci.linux.sysfs_path =
>> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0'  (string)
>> pci.product_id = 43  (0x2b)  (int) pci.vendor_id = 5772  (0x168c)
>> (int) pci.subsys_product_id = 12352  (0x3040)  (int)
>> pci.subsys_vendor_id = 4156  (0x103c)  (int) pci.device_class = 2
>> (0x2)  (int) pci.device_subclass = 128  (0x80)  (int)
> --
> 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
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

Hi guys,

This article just popped up, wrt Linux APSM handling changes and some
rather negative effects..

http://www.phoronix.com/scan.php?page=article&item=linux_2638_aspm&num=2

The commit is: 2f671e2dbff6eb5ef4e2600adbec550c13b8fe72

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

Camilo, Tony, etc:

Please read this article and try what they're suggesting. It has to do
with an APSM commit which has negatively impacted some users (eg by
causing hangs.) Sound familiar? :)

http://www.phoronix.com/scan.php?page=article&item=linux_2638_aspm&num=2

(Obviously with my ath9k patch backed out.)

Thanks,


Adrian

On 11 June 2011 14:42, Camilo Mesias <camilo@mesias.co.uk> wrote:
> Hi,
>
> On Fri, Jun 10, 2011 at 5:10 PM, Adrian Chadd <adrian@freebsd.org> wrote:
>> On 11 June 2011 02:47, Tony Houghton <h@realh.co.uk> wrote:
> [...]
>>>> Let's just try the patch I emailed you to apply to wireless-testing.
>>>> Hopefully that restores functionality enough and we can punt it to the
>>>> Atheros guys to do some further investigation.
>>>
>>> That change seems to have fixed it! I've managed at least 3
>>> suspend/resumes and an rmmod/modprobe without crashing. Perhaps a little
>>> early to say it's definitely fixed, but I don't think I've ever managed
>>> more than 2 attempts in a row without a "bad" version crashing.
>>
>> Excellent! Let's see if it fixes it for other users.
>> Camilo? :)
>
> I had some problems with the wireless-testing software but managed to
> rebuild the current kernel from source (2.6.38.7-30.fc15.i686) then
> commented out the relevant driver part and changed the
> AR9285_WA_DEFAULT value too. I made sure I was running the rebuilt
> modules and... it works. I suspended and resumed just fine.
>
> I'm not sure how I can quickly get a clean fix, I think this might be
> tweakable with the patch:
>
> http://people.redhat.com/sgruszka/compact_wireless.html
>
> Or I could just stay on my bodged kernel for a while (although this
> doesn't help anyone else)
>
> Thanks for all the help, it looks like my netbook is useful again :D
>
> -Cam
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Mon, 27 Jun 2011 18:37:00 +0800
Adrian Chadd <adrian@freebsd.org> wrote:

> Camilo, Tony, etc:
> 
> Please read this article and try what they're suggesting. It has to do
> with an APSM commit which has negatively impacted some users (eg by
> causing hangs.) Sound familiar? :)
> 
> http://www.phoronix.com/scan.php?page=article&item=linux_2638_aspm&num=2
> 
> (Obviously with my ath9k patch backed out.)

Sorry about the delay, I don't regularly use the offending netbook any
more. But I've reverted that APSM commit and removed your patch, and it
does seem to cure the problem! I'm quite surprised, because the
timescales/releases of the bug and that commit don't seem to match. So
as before, I hope Camilo and/or others can confirm this.

It also seems to fix a similar issue I had experienced with rt2800pci.
Is there some sort of bug report or discussion for that APSM commit? I
should probably report my findings there.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

Hi!

That's great news.

Please create a couple of linux kernel bugzilla reports, one for each device.

Someone related to the Debian project commented earlier on this bug;
perhaps they'd like to be told too.

thanks! I'm so very, very glad we all got to the bottom of this complete mess.
(I'm glad it wasn't ath9k :-)


Adrian

On 12 July 2011 21:46, Tony Houghton <h@realh.co.uk> wrote:
> On Mon, 27 Jun 2011 18:37:00 +0800
> Adrian Chadd <adrian@freebsd.org> wrote:
>
>> Camilo, Tony, etc:
>>
>> Please read this article and try what they're suggesting. It has to do
>> with an APSM commit which has negatively impacted some users (eg by
>> causing hangs.) Sound familiar? :)
>>
>> http://www.phoronix.com/scan.php?page=article&item=linux_2638_aspm&num=2
>>
>> (Obviously with my ath9k patch backed out.)
>
> Sorry about the delay, I don't regularly use the offending netbook any
> more. But I've reverted that APSM commit and removed your patch, and it
> does seem to cure the problem! I'm quite surprised, because the
> timescales/releases of the bug and that commit don't seem to match. So
> as before, I hope Camilo and/or others can confirm this.
>
> It also seems to fix a similar issue I had experienced with rt2800pci.
> Is there some sort of bug report or discussion for that APSM commit? I
> should probably report my findings there.
>
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Tue, Jul 12, 2011 at 8:40 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> Hi!
>
> That's great news.
>
> Please create a couple of linux kernel bugzilla reports, one for each device.
>
> Someone related to the Debian project commented earlier on this bug;
> perhaps they'd like to be told too.
>
> thanks! I'm so very, very glad we all got to the bottom of this complete mess.
> (I'm glad it wasn't ath9k :-)

Adrian, great! you did it :-)

>
>
> Adrian
>
> On 12 July 2011 21:46, Tony Houghton <h@realh.co.uk> wrote:
>> On Mon, 27 Jun 2011 18:37:00 +0800
>> Adrian Chadd <adrian@freebsd.org> wrote:
>>
>>> Camilo, Tony, etc:
>>>
>>> Please read this article and try what they're suggesting. It has to do
>>> with an APSM commit which has negatively impacted some users (eg by
>>> causing hangs.) Sound familiar? :)
>>>
>>> http://www.phoronix.com/scan.php?page=article&item=linux_2638_aspm&num=2
>>>
>>> (Obviously with my ath9k patch backed out.)
>>
>> Sorry about the delay, I don't regularly use the offending netbook any
>> more. But I've reverted that APSM commit and removed your patch, and it
>> does seem to cure the problem! I'm quite surprised, because the
>> timescales/releases of the bug and that commit don't seem to match. So
>> as before, I hope Camilo and/or others can confirm this.
>>
>> It also seems to fix a similar issue I had experienced with rt2800pci.
>> Is there some sort of bug report or discussion for that APSM commit? I
>> should probably report my findings there.
>>
>>
>



-- 
shafi

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Camilo Mesias]

Hi,

sorry I have been a bit lax on this (since the machine works well with
the driver hack). Last night I got the latest Fedora 15 kernel and
noticed several APSM related patches. I retested and it still fails. I
started work on a patch to back out the commit mentioned recently,
which has stopped the kernel building. It doesn't look like it will be
too hard to fix and I will get back on to it hopefully this evening.

-Cam

On Tue, Jul 12, 2011 at 2:46 PM, Tony Houghton <h@realh.co.uk> wrote:
> On Mon, 27 Jun 2011 18:37:00 +0800
> Adrian Chadd <adrian@freebsd.org> wrote:
>
>> Camilo, Tony, etc:
>>
>> Please read this article and try what they're suggesting. It has to do
>> with an APSM commit which has negatively impacted some users (eg by
>> causing hangs.) Sound familiar? :)
>>
>> http://www.phoronix.com/scan.php?page=article&item=linux_2638_aspm&num=2
>>
>> (Obviously with my ath9k patch backed out.)
>
> Sorry about the delay, I don't regularly use the offending netbook any
> more. But I've reverted that APSM commit and removed your patch, and it
> does seem to cure the problem! I'm quite surprised, because the
> timescales/releases of the bug and that commit don't seem to match. So
> as before, I hope Camilo and/or others can confirm this.
>
> It also seems to fix a similar issue I had experienced with rt2800pci.
> Is there some sort of bug report or discussion for that APSM commit? I
> should probably report my findings there.
>
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Camilo Mesias]

OK, I took my current Fedora Kernel and applied a patch to remove the
commit mentioned above, basically removing aspm_clear_state ... I
found that it DIDN'T cure the problem. I am wondering if any of the
other Fedora patches (some are ASPM related) might not help. I did
have to go beyond the changes in the commit as there was one further
mention of aspm_clear_state.

The other patches are:
linux-2.6-defaults-aspm.patch
pci-enable-aspm-state-clearing-regardless-of-policy.patch
pci-pcie-links-may-not-get-configured-for-aspm-under-powersave-mode.patch

The kernel I used was 2.6.38.8-35.fc15.i686

If I can tonight, I will read those patches and see which might be
involved in this mess, but for now I have to say I can't confirm any
fix based on simply backing out that commit.

-Cam

On Tue, Jul 12, 2011 at 2:46 PM, Tony Houghton <h@realh.co.uk> wrote:
> On Mon, 27 Jun 2011 18:37:00 +0800
> Adrian Chadd <adrian@freebsd.org> wrote:
>
>> Camilo, Tony, etc:
>>
>> Please read this article and try what they're suggesting. It has to do
>> with an APSM commit which has negatively impacted some users (eg by
>> causing hangs.) Sound familiar? :)
>>
>> http://www.phoronix.com/scan.php?page=article&item=linux_2638_aspm&num=2
>>
>> (Obviously with my ath9k patch backed out.)
>
> Sorry about the delay, I don't regularly use the offending netbook any
> more. But I've reverted that APSM commit and removed your patch, and it
> does seem to cure the problem! I'm quite surprised, because the
> timescales/releases of the bug and that commit don't seem to match. So
> as before, I hope Camilo and/or others can confirm this.
>
> It also seems to fix a similar issue I had experienced with rt2800pci.
> Is there some sort of bug report or discussion for that APSM commit? I
> should probably report my findings there.
>
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Camilo Mesias]

I have found an interesting workaround that seems quite effective and
requires no code changes for a Fedora user with my hardware... would
be interested to see if anyone else can reproduce this or explain why
it fixes the problem.

Recall I was trying to audit the Fedora kernel ASPM related patches -
I tried but really don't have enough knowledge of PCIE and related
stuff to completely make sense of it all. Also I have to treat all the
patches and code comments with healthy skepticism because they seem to
have an air of black art about them. As if they are guesses at a
solution rather than something guranteed to conform to some
specification.

Anyway reading the code and understanding a little about the changes
that had worked, I saw that there was another option for pcie_aspm.
Tony had tried pcie_aspm=off previously but it seemed to me that
pcie_aspm=force might be worth a try. I tried it with the
2.6.38.8-35.fc15.i686 kernel straight from Fedora (ie. without any
patches or hacking from me) and it worked.

So for me at least, no more hacking bleeding edge wireless packages or
building specially patched kernels. Just add:

pcie_aspm=force

to the kernel command line.

Comments?

-Cam


On Thu, Jul 14, 2011 at 8:02 AM, Camilo Mesias <camilo@mesias.co.uk> wrote:
> OK, I took my current Fedora Kernel and applied a patch to remove the
> commit mentioned above, basically removing aspm_clear_state ... I
> found that it DIDN'T cure the problem. I am wondering if any of the
> other Fedora patches (some are ASPM related) might not help. I did
> have to go beyond the changes in the commit as there was one further
> mention of aspm_clear_state.
>
> The other patches are:
> linux-2.6-defaults-aspm.patch
> pci-enable-aspm-state-clearing-regardless-of-policy.patch
> pci-pcie-links-may-not-get-configured-for-aspm-under-powersave-mode.patch
>
> The kernel I used was 2.6.38.8-35.fc15.i686
>
> If I can tonight, I will read those patches and see which might be
> involved in this mess, but for now I have to say I can't confirm any
> fix based on simply backing out that commit.
>
> -Cam
>
> On Tue, Jul 12, 2011 at 2:46 PM, Tony Houghton <h@realh.co.uk> wrote:
>> On Mon, 27 Jun 2011 18:37:00 +0800
>> Adrian Chadd <adrian@freebsd.org> wrote:
>>
>>> Camilo, Tony, etc:
>>>
>>> Please read this article and try what they're suggesting. It has to do
>>> with an APSM commit which has negatively impacted some users (eg by
>>> causing hangs.) Sound familiar? :)
>>>
>>> http://www.phoronix.com/scan.php?page=article&item=linux_2638_aspm&num=2
>>>
>>> (Obviously with my ath9k patch backed out.)
>>
>> Sorry about the delay, I don't regularly use the offending netbook any
>> more. But I've reverted that APSM commit and removed your patch, and it
>> does seem to cure the problem! I'm quite surprised, because the
>> timescales/releases of the bug and that commit don't seem to match. So
>> as before, I hope Camilo and/or others can confirm this.
>>
>> It also seems to fix a similar issue I had experienced with rt2800pci.
>> Is there some sort of bug report or discussion for that APSM commit? I
>> should probably report my findings there.
>>
>>
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Jonathan Nieder]

Hi,

Camilo Mesias wrote:

> Anyway reading the code and understanding a little about the changes
> that had worked, I saw that there was another option for pcie_aspm.
> Tony had tried pcie_aspm=off previously but it seemed to me that
> pcie_aspm=force might be worth a try. I tried it with the
> 2.6.38.8-35.fc15.i686 kernel straight from Fedora (ie. without any
> patches or hacking from me) and it worked.

Yep, that's quite believable.  See

  http://lwn.net/Articles/449448/ and especially
  http://lwn.net/Articles/449648/

for context.  Ugly stuff.

Now _ideally_ disabling aspm wouldn't cause the wireless driver to
hang.  So alas I think there's still more to fix around here.

Cc-ing mjg and the linux-pci list in case they have hints[1].

Thanks,
Jonathan

[1] We are discussing the ath9k hangs described at
<https://bugzilla.kernel.org/show_bug.cgi?id=37462> fwiw.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

On 9 June 2011 00:51, Tony Houghton <h@realh.co.uk> wrote:
>> Go back to the first good commit, then apply the patch to reg.h to
>> pick up the change to AR9285_WA_DEFAULT.
>> Then test with that.
>>
>> The only change in your tree should be to reg.h:
>>
>> http://git390.marist.edu/cgi-bin/gitweb.cgi?p=linux-2.6.git;a=blobdiff;f=drivers/net/wireless/ath/ath9k/reg.h;h=7e36ad7421b77f6464c8bc810c9b1276209fe329;hp=198e41dd38a6142e232a22807d665f78dbecae72;hb=53bc7aa08b48e5cd745f986731cc7dc24eef2a9f;hpb=d5cdfacb35ed886271d1ccfffbded98d3447da17
>
> Right, it did crash with this patch. This time I was able to rmmod ath9k
> once but it crashed on rmload ath9k. I also had a freeze while booting
> up. That was on AC power. With this version, running on battery power
> seems to greatly reduce the chances of a crash, if not prevent it
> altogether. I had noticed this on previous stock kernels, but recent
> ones crash on battery power too.

Ok, so just to be sure:

* if you boot a kernel without that AR9285_WA_DEFAULT patch from the
"bad" commit, things work fine, and
* if you boot a kernel with the AR9285_WA_DEFAULT patch applied from
the "bad" commit, things break?


Adrian

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Wed, 8 Jun 2011 07:22:04 +0800
Adrian Chadd <adrian@freebsd.org> wrote:

> On 8 June 2011 04:54, Tony Houghton <h@realh.co.uk> wrote:
> 
> > My bisect log showed the last "good" commit was
> > d5cdfacb35ed886271d1ccfffbded98d3447da17 and the first "bad"
> > 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f.
> >
> > I tested those again and it seemed to confirm the initial finding.
> > With the "good" one I suspended/resumed at least twice, did rmmod
> > ath9k at least twice, and disabled wireless with NetworkManager,
> > all without incident. The "bad" one crashed the first time I tried
> > rmmod ath9k.
> 
> Ok. Let's try the patches in turn, ok?
> 
> Go back to the first good commit, then apply the patch to reg.h to
> pick up the change to AR9285_WA_DEFAULT.
> Then test with that.
> 
> The only change in your tree should be to reg.h:
> 
> http://git390.marist.edu/cgi-bin/gitweb.cgi?p=linux-2.6.git;a=blobdiff;f=drivers/net/wireless/ath/ath9k/reg.h;h=7e36ad7421b77f6464c8bc810c9b1276209fe329;hp=198e41dd38a6142e232a22807d665f78dbecae72;hb=53bc7aa08b48e5cd745f986731cc7dc24eef2a9f;hpb=d5cdfacb35ed886271d1ccfffbded98d3447da17

Right, it did crash with this patch. This time I was able to rmmod ath9k
once but it crashed on rmload ath9k. I also had a freeze while booting
up. That was on AC power. With this version, running on battery power
seems to greatly reduce the chances of a crash, if not prevent it
altogether. I had noticed this on previous stock kernels, but recent
ones crash on battery power too.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

On 8 June 2011 04:54, Tony Houghton <h@realh.co.uk> wrote:

> My bisect log showed the last "good" commit was
> d5cdfacb35ed886271d1ccfffbded98d3447da17 and the first "bad"
> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f.
>
> I tested those again and it seemed to confirm the initial finding. With
> the "good" one I suspended/resumed at least twice, did rmmod ath9k at
> least twice, and disabled wireless with NetworkManager, all without
> incident. The "bad" one crashed the first time I tried rmmod ath9k.

Ok. Let's try the patches in turn, ok?

Go back to the first good commit, then apply the patch to reg.h to
pick up the change to AR9285_WA_DEFAULT.
Then test with that.

The only change in your tree should be to reg.h:

http://git390.marist.edu/cgi-bin/gitweb.cgi?p=linux-2.6.git;a=blobdiff;f=drivers/net/wireless/ath/ath9k/reg.h;h=7e36ad7421b77f6464c8bc810c9b1276209fe329;hp=198e41dd38a6142e232a22807d665f78dbecae72;hb=53bc7aa08b48e5cd745f986731cc7dc24eef2a9f;hpb=d5cdfacb35ed886271d1ccfffbded98d3447da17

Thanks,



Adrian

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Camilo Mesias]

Interesting. For what it's worth I tried the pcie_aspm=off boot
parameter and ASPM was still shown as enabled for the device.

-Cam

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Tue, 7 Jun 2011 09:21:51 +0800
Adrian Chadd <adrian@freebsd.org> wrote:

> Ok, checking out a previous version of the wireless-testing tree (@
> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f) shows that
> ath9k_hw_configpcipowersave() is  different in that version to later
> versions.
> 
> So moral of the story tony - please checkout a tree before that commit
> and test. :-) There's significant differences between ath9k back then
> and now to make comparison non-trivial.

My bisect log showed the last "good" commit was
d5cdfacb35ed886271d1ccfffbded98d3447da17 and the first "bad"
53bc7aa08b48e5cd745f986731cc7dc24eef2a9f.

I tested those again and it seemed to confirm the initial finding. With
the "good" one I suspended/resumed at least twice, did rmmod ath9k at
least twice, and disabled wireless with NetworkManager, all without
incident. The "bad" one crashed the first time I tried rmmod ath9k.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

Well, that patch did a few things besides add AR9285SE specific stuff:

* added the carrier leak calibration workaround for AR9285;
* changed initvals for the normal ar9285 v1.2 case (they look like
BB/PHY and analog related settings, but I have no idea what misc bits
are floating around there, lurking to bite an unsuspecting
traveller..)
* modified the AR9285_WA_DEFAULT value from 0x004a05cb to 0x004a050b,
clearing bits 6+7. These bits are set on poweron and cleared on
poweroff. I can't see any use of this register outside of
ar9002_hw_configpcipowersave(), so unless the code has changed
significantly since this commit, I don't think that modification would
have hurt.

In FreeBSD though, I just write the AR9285 serdes then set the
AR9285_WA_DEFAULT value to AR_WA. I don't do any tricky pcie powersave
yet primarily because I'm not sure if it's fully debugged. ;)

Ok, checking out a previous version of the wireless-testing tree (@
53bc7aa08b48e5cd745f986731cc7dc24eef2a9f) shows that
ath9k_hw_configpcipowersave() is  different in that version to later
versions.

So moral of the story tony - please checkout a tree before that commit
and test. :-) There's significant differences between ath9k back then
and now to make comparison non-trivial.



Adrian

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Tue, Jun 7, 2011 at 5:47 AM, Tony Houghton <h@realh.co.uk> wrote:
> On Tue, 7 Jun 2011 01:31:25 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> On Tue, Jun 7, 2011 at 1:24 AM, Tony Houghton <h@realh.co.uk> wrote:
>> > OK, I'll try disabling that. Can I just use setpci as documented
>> > under "Enabling ASPM with setpci" on that page or do I have to make
>> > sure PCIEASPM is enabled and use the boot parameter?
>>
>> you can do that and also try with the patch I had provided.
>
> It seems Debian kernels are built with PCIEASPM=y so I added
> pcie_aspm=off as a boot parameter, but still I got the crash :-(.
>
> Then I tried your patch (against compat-wireless) and that still crashed
> too :-(.

:-( :-( thought ASPM is the issue .. couldn't think of anything else :(

>
> I couldn't use the setpci hack from the ASPM web page either because
> lspci didn't produce usable results:
>
> # lspci -vvv | grep 9285
> 03:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
> # lspci -t
> -[0000:00]-+-00.0
> ? ? ? ? ? +-00.1
> ? ? ? ? ? +-03.0
> ? ? ? ? ? +-03.1
> ? ? ? ? ? +-03.2
> ? ? ? ? ? +-03.3
> ? ? ? ? ? +-03.5
> ? ? ? ? ? +-04.0
> ? ? ? ? ? +-04.1
> ? ? ? ? ? +-06.0
> ? ? ? ? ? +-06.1
> ? ? ? ? ? +-08.0
> ? ? ? ? ? +-09.0-[01]--
> ? ? ? ? ? +-0a.0
> ? ? ? ? ? +-0b.0
> ? ? ? ? ? +-10.0-[02]----00.0
> ? ? ? ? ? +-15.0-[03]----00.0
> ? ? ? ? ? \-16.0-[04]--
> # lspci -s 00:15.0 -xxx
> 00:15.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
> 00: de 10 c6 0a 07 04 10 00 b1 00 04 06 10 00 01 00
> 10: 00 00 00 00 00 00 00 00 00 03 03 00 f1 01 00 00
> 20: 00 53 00 53 f1 ff 01 00 00 00 00 00 00 00 00 00
> 30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00
> 40: 0d 48 00 00 3c 10 51 36 01 50 03 f8 00 00 00 00
> 50: 05 80 83 00 0c 30 e0 fe 00 00 00 00 51 41 00 00
> 60: 08 80 00 a8 00 00 e0 fe 00 00 00 00 00 00 00 00
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 80: 10 00 42 01 21 80 00 00 10 20 00 00 12 3c 31 03
> 90: 42 00 11 70 00 00 00 00 e0 11 40 01 00 00 00 00
> a0: 00 00 00 00 13 00 00 00 06 00 00 00 00 00 00 00
> b0: 42 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
>



-- 
shafi

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

Hi Tony,

Would you please try to revert back to a kernel before that commit
mentioned above, then test a kernel with that commit?

It's possible that other stuff in the kernel that's been introduced
since is also causing issues. It's also possible we're not fixing the
root cause.
Either way, the best way to get to the root of this is to fall back to
a known working mode, then vary one thing at a time to see what
breaks.

We'll nail this nice and quickly, but only as long as that pre-commit
kernel worked and the post-commit doesn't. So please verify that
first. :-)

(And ask here for git help, I'm not really up to scratch on the git
magic needed.)


Adrian

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Tue, 7 Jun 2011 01:31:25 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> On Tue, Jun 7, 2011 at 1:24 AM, Tony Houghton <h@realh.co.uk> wrote:
> > OK, I'll try disabling that. Can I just use setpci as documented
> > under "Enabling ASPM with setpci" on that page or do I have to make
> > sure PCIEASPM is enabled and use the boot parameter?
> 
> you can do that and also try with the patch I had provided.

It seems Debian kernels are built with PCIEASPM=y so I added
pcie_aspm=off as a boot parameter, but still I got the crash :-(.

Then I tried your patch (against compat-wireless) and that still crashed
too :-(.

I couldn't use the setpci hack from the ASPM web page either because
lspci didn't produce usable results:

# lspci -vvv | grep 9285
03:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
# lspci -t
-[0000:00]-+-00.0
           +-00.1
           +-03.0
           +-03.1
           +-03.2
           +-03.3
           +-03.5
           +-04.0
           +-04.1
           +-06.0
           +-06.1
           +-08.0
           +-09.0-[01]--
           +-0a.0
           +-0b.0
           +-10.0-[02]----00.0
           +-15.0-[03]----00.0
           \-16.0-[04]--
# lspci -s 00:15.0 -xxx
00:15.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
00: de 10 c6 0a 07 04 10 00 b1 00 04 06 10 00 01 00
10: 00 00 00 00 00 00 00 00 00 03 03 00 f1 01 00 00
20: 00 53 00 53 f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00
40: 0d 48 00 00 3c 10 51 36 01 50 03 f8 00 00 00 00
50: 05 80 83 00 0c 30 e0 fe 00 00 00 00 51 41 00 00
60: 08 80 00 a8 00 00 e0 fe 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 10 00 42 01 21 80 00 00 10 20 00 00 12 3c 31 03
90: 42 00 11 70 00 00 00 00 e0 11 40 01 00 00 00 00
a0: 00 00 00 00 13 00 00 00 06 00 00 00 00 00 00 00
b0: 42 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Lars Schotte]

look, i just came back from the city and my computer was crashed. it
didnt respond to anything. ath9k was loaded, but i do not see any error
being written out somewhere in system log.

so this lockups are not a myth. they are real, i know that now. i ll
may buy a new adapter ... :-(

On Tue, 7 Jun 2011 01:31:25 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> On Tue, Jun 7, 2011 at 1:24 AM, Tony Houghton <h@realh.co.uk> wrote:
> > On Tue, 7 Jun 2011 00:52:11 +0530
> > Mohammed Shafi <shafi.wireless@gmail.com> wrote:
> >
> >> On Mon, Jun 6, 2011 at 10:23 PM, Mohammed Shafi
> >> <shafi.wireless@gmail.com> wrote:
> >> >
> >> > another difference I found ASPM enabled in your device(based on
> >> > lspci 2.6.37-config), but not in mine.
> >>
> >> http://wireless.kernel.org/en/users/Documentation/ASPM
> >> WARNING: Forcing ASPM on may cause system lockups!
> >> hopefully I am not misleading
> >
> > OK, I'll try disabling that. Can I just use setpci as documented
> > under "Enabling ASPM with setpci" on that page or do I have to make
> > sure PCIEASPM is enabled and use the boot parameter?
> 
> you can do that and also try with the patch I had provided.
> 
> >
> 
> 
> 


-- 
Lars Schotte
@ Hana (F14)

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Tue, Jun 7, 2011 at 1:24 AM, Tony Houghton <h@realh.co.uk> wrote:
> On Tue, 7 Jun 2011 00:52:11 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> On Mon, Jun 6, 2011 at 10:23 PM, Mohammed Shafi
>> <shafi.wireless@gmail.com> wrote:
>> >
>> > another difference I found ASPM enabled in your device(based on lspci
>> > 2.6.37-config), but not in mine.
>>
>> http://wireless.kernel.org/en/users/Documentation/ASPM
>> WARNING: Forcing ASPM on may cause system lockups!
>> hopefully I am not misleading
>
> OK, I'll try disabling that. Can I just use setpci as documented under
> "Enabling ASPM with setpci" on that page or do I have to make sure
> PCIEASPM is enabled and use the boot parameter?

you can do that and also try with the patch I had provided.

>



-- 
shafi

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Tue, 7 Jun 2011 00:52:11 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> On Mon, Jun 6, 2011 at 10:23 PM, Mohammed Shafi
> <shafi.wireless@gmail.com> wrote:
> >
> > another difference I found ASPM enabled in your device(based on lspci
> > 2.6.37-config), but not in mine.
> 
> http://wireless.kernel.org/en/users/Documentation/ASPM
> WARNING: Forcing ASPM on may cause system lockups!
> hopefully I am not misleading

OK, I'll try disabling that. Can I just use setpci as documented under
"Enabling ASPM with setpci" on that page or do I have to make sure
PCIEASPM is enabled and use the boot parameter?

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Mon, Jun 6, 2011 at 10:23 PM, Mohammed Shafi
<shafi.wireless@gmail.com> wrote:
> On Mon, Mar 14, 2011 at 9:57 PM, Tony Houghton <h@realh.co.uk> wrote:
>> On Mon, 14 Mar 2011 11:53:42 +0530
>> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>>
>>> On Mon, Mar 14, 2011 at 11:51 AM, Mohammed Shafi
>>> <shafi.wireless@gmail.com> wrote:
>>> >
>>> > ? ? ? ? not reproducible in 2.6.38-rc7-wl wireless testing under
>>> > Ubuntu, dont know where i am missing.
>>> > I tried suspend-resume with/without disabling network manager. no
>>> > kernel lock ups.
>>> > also attaching my wireless tesing .config which may be of some
>>> > help. any ideas?
>>>
>>> also lspci -vvvnn looks the card we are using ?is same as yours?
>>>
>>> 05:00.0 Network controller [0280]: Atheros Communications Inc. AR9285
>>> Wireless Network Adapter (PCI-Express) [168c:002b] (rev 01)
>>> ? ? ? ? Subsystem: Atheros Communications Inc. Device [168c:30a1]
>>> ? ? ? ? Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>>> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>>> ? ? ? ? Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>> ? ? ? ? Latency: 0, Cache Line Size: 64 bytes
>>> ? ? ? ? Interrupt: pin A routed to IRQ 19
>>> ? ? ? ? Region 0: Memory at f4800000 (64-bit, non-prefetchable)
>>> [size=64K] Capabilities: <access denied>
>>> ? ? ? ? Kernel driver in use: ath9k
>>> ? ? ? ? Kernel modules: ath9k
>>
>> Here is my lspci output (it's the same for kernel 2.6.34 and 2.6.37) and
>> the kernel configs for 2.6.34 (one of the most recent versions I
>> compiled from git that doesn't crash) and 2.6.37 (Debian stock which
>> does crash).
>>
>
> another difference I found ASPM enabled in your device(based on lspci
> 2.6.37-config), but not in mine.

nice chance that ASPM is the problem..

/*
 * Helper for ASPM support.
 *
 * Disable PLL when in L0s as well as receiver clock when in L1.
 * This power saving option must be enabled through the SerDes.
 *
 * Programming the SerDes must go through the same 288 bit serial shift
 * register as the other analog registers.  Hence the 9 writes.
 */
static void ar9002_hw_configpcipowersave(struct ath_hw *ah,
                                         int restore,
                                         int power_off)

....
    /* WAR for ASPM system hang */
                if (AR_SREV_9285(ah) || AR_SREV_9287(ah))
                        val |= (AR_WA_BIT6 | AR_WA_BIT7);

                if (AR_SREV_9285E_20(ah))
                        val |= AR_WA_BIT23;




>
>>
>
>
>
> --
> shafi
>



-- 
shafi

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Mon, Mar 14, 2011 at 9:57 PM, Tony Houghton <h@realh.co.uk> wrote:
> On Mon, 14 Mar 2011 11:53:42 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> On Mon, Mar 14, 2011 at 11:51 AM, Mohammed Shafi
>> <shafi.wireless@gmail.com> wrote:
>> >
>> > ? ? ? ? not reproducible in 2.6.38-rc7-wl wireless testing under
>> > Ubuntu, dont know where i am missing.
>> > I tried suspend-resume with/without disabling network manager. no
>> > kernel lock ups.
>> > also attaching my wireless tesing .config which may be of some
>> > help. any ideas?
>>
>> also lspci -vvvnn looks the card we are using ?is same as yours?
>>
>> 05:00.0 Network controller [0280]: Atheros Communications Inc. AR9285
>> Wireless Network Adapter (PCI-Express) [168c:002b] (rev 01)
>> ? ? ? ? Subsystem: Atheros Communications Inc. Device [168c:30a1]
>> ? ? ? ? Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>> ? ? ? ? Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>> ? ? ? ? Latency: 0, Cache Line Size: 64 bytes
>> ? ? ? ? Interrupt: pin A routed to IRQ 19
>> ? ? ? ? Region 0: Memory at f4800000 (64-bit, non-prefetchable)
>> [size=64K] Capabilities: <access denied>
>> ? ? ? ? Kernel driver in use: ath9k
>> ? ? ? ? Kernel modules: ath9k
>
> Here is my lspci output (it's the same for kernel 2.6.34 and 2.6.37) and
> the kernel configs for 2.6.34 (one of the most recent versions I
> compiled from git that doesn't crash) and 2.6.37 (Debian stock which
> does crash).
>

another difference I found ASPM enabled in your device(based on lspci
2.6.37-config), but not in mine.

>



-- 
shafi

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

2011/6/5 Camilo Mesias <camilo@mesias.co.uk>:
> I have a suspicion the lockup happens in the rf off code, because I can
> cause the lockup reliably simply with iwconfig wlan0 tx off
> Can other people confirm this? Is it worth putting more defensive code in
> that function?

based on all of your inputs and from Adrian Chadd, i thought removing
config pci powersave module may help. wild shot and may help to narrow
down the problem
some analysis, either suspend/resume or tx power off path
ath9k_stop
ath_radio_disable
will be called. both of them has this pci power save stuff. attached a
patch to remove it. please test it.


>
> -Cam
>
> On 5 Jun 2011 12:21, "Adri? Cereto Massagu?" <ssorgatem@gmail.com> wrote:
>
> Hi,
>
> Just wanted to say that I have the exact same issue with a Packard-Bell dot
> m/a 134, and I reported it before too.
>
> 2011/6/5 Adrian Chadd <adrian@freebsd.org>
>>
>> On 5 June 2011 01:08, Tony Houghton <h@realh.co.uk> ...
>
> --
> Adri? Cereto Massagu?
> Biotechnology student
> Universitat Rovira i Virgili
>
> Languages: Catal?, Espa?ol, English, Fran?ais, Deutsch, Portugu?s, Esperanto
>
> Nota importante | Important Notice
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>



-- 
shafi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: remove-configpcipowersave.patch
Type: text/x-diff
Size: 1596 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110606/fd4c55a2/attachment.patch 

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Camilo Mesias]

On Sun, Jun 5, 2011 at 2:57 PM, Lars Schotte <lars.schotte@schotteweb.de> wrote:
> helps in what? in preventing the lockup?

No, sorry! It's just how I got the regval / regidx to appear under /sys...

I didn't see any interesting debug when I used that - when I tried
iwconfig wlan0 tx off

-Cam

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Lars Schotte]

helps in what? in preventing the lockup?

On Sun, 5 Jun 2011 09:43:50 -0400
Camilo Mesias <camilo@mesias.co.uk> wrote:

> Hi,
> 
> I should mention I have:
> 
> [root at newt ~]# cat /etc/modprobe.d/ath9k.conf
> options ath9k debug=0xffffffff nohwcrypt=1
> 
> I put that in there ages ago and had forgotten about it. Hope it
> helps.
> 
> -Cam
> 
> On Sun, Jun 5, 2011 at 9:19 AM, Tony Houghton <h@realh.co.uk> wrote:
> > I can't find regval or regidx. Looking at another reply I can see
> > they live in a debug subdirectory. Do I need to enable debugging
> > for ath9k?
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel


-- 
Lars Schotte
@ Hana (F14)

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Camilo Mesias]

Hi,

I should mention I have:

[root at newt ~]# cat /etc/modprobe.d/ath9k.conf
options ath9k debug=0xffffffff nohwcrypt=1

I put that in there ages ago and had forgotten about it. Hope it helps.

-Cam

On Sun, Jun 5, 2011 at 9:19 AM, Tony Houghton <h@realh.co.uk> wrote:
> I can't find regval or regidx. Looking at another reply I can see they
> live in a debug subdirectory. Do I need to enable debugging for ath9k?

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Lars Schotte]

your debian 2.6.32 problem seems to me like a radeon UMS setup, because
debian crashes w/ KMS enabled on a radeon card. thats because the old
Xorg and buggy KMS radeon driver.

On Sun, 5 Jun 2011 14:19:02 +0100
Tony Houghton <h@realh.co.uk> wrote:

> On Sun, 5 Jun 2011 20:26:03 +0800
> Adrian Chadd <adrian@freebsd.org> wrote:
> 
> > To check, find where in the proc/sys fs's regval/regidx now live,
> > and
> > 
> > echo "0x7868" > regidx
> > cat regval
> 
> I can't find regval or regidx. Looking at another reply I can see they
> live in a debug subdirectory. Do I need to enable debugging for ath9k?
> Or do I need a newer kernel than 2.6.32. I'm using that because it's
> the latest Debian stock kernel I can use without crashing, but it has
> drawbacks such as issues with nouveau, and I guess it will eventually
> hold me back from other upgrades.
> 
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel


-- 
Lars Schotte
@ Hana (F14)

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Lars Schotte]

this suspicion that the lockup happens in the rf off code is a good
start. i am experiencing it when i leave atk9k unassociated on network
manager and am connected w/ cat5 (which makes no difference). after
some time there appears the [phy0] process w/ 100% CPU load again and
again with some pauses in between of approx 2 - 3 minutes.

i am fixing it everytime with rmmod ath9k as long as i am not connected
and/or dont want to be connected through wlan.

On Sun, 5 Jun 2011 14:11:30 +0100
Tony Houghton <h@realh.co.uk> wrote:

> On Sun, 5 Jun 2011 07:30:34 -0400
> Camilo Mesias <camilo@mesias.co.uk> wrote:
> 
> > I have a suspicion the lockup happens in the rf off code, because I
> > can cause the lockup reliably simply with iwconfig wlan0 tx off
> > Can other people confirm this? Is it worth putting more defensive
> > code in that function?
> 
> This is what I found (I forgot to use Reply To All so I only sent this
> to Mohammed Shafi before):
> 
> : The freeze is in ath9k_hw_set_power_awake during the for() loop
> when it : calls
> : REG_SET_BIT(ah, AR_RTC_FORCE_WAKE, AR_RTC_FORCE_WAKE_EN);
> 
> That could be wrong because I used printk to track it down and there
> may be a race condition between the crash and the messages appearing
> on the console.
> 
> I also discovered that
>   val = REG_READ(ah, AR_RTC_STATUS) & AR_RTC_STATUS_M;
> had a result of 15, but the status should only have one bit set at a
> time I think?
> 
> I also wondered why it was trying to go into a wake state when it was
> supposed to be shutting down.
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel


-- 
Lars Schotte
@ Hana (F14)

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Lars Schotte]

want to see how far it gets? ... not far. this looks like the problem i
just reported w/ the busy waiting and driver defunct.

On Sun, 5 Jun 2011 21:18:34 +0800
Adrian Chadd <adrian@freebsd.org> wrote:

> On 5 June 2011 21:04, Camilo Mesias <camilo@mesias.co.uk> wrote:
> > Hi,
> >
> > thanks for the suggestions.
> >
> > I didn't get back a stable value from that regidx/regval, I settled
> > on this:
> >
> > [root at newt ~]# for x in $(seq 1 1000) ; do echo "0x7868" >
> > /sys/kernel/debug/ieee80211/phy0/ath9k/regidx; cat
> > /sys/kernel/debug/ieee80211/phy0/ath9k/regval; done|sort |uniq
> > 0x02036085
> > 0x42030085
> > 0x42035885
> > 0x42036085
> > 0x82030085
> > 0x82036085
> >
> > Does that trailing 5 mean anything? Here is the corresponding lspci
> > output:
> 
> It means you have an AR9285, not AR9285SE. (the last three bits have
> to be 0x01, and yours is 0x5. :-)
> 
> >> You could also try flipping the AR9285_WA_DEFAULT value and/or
> >> register inivals back to the previous version?
> >
> > Is this a rebuild of the kernel module or configuration?
> 
> The kernel module.
> 
> >> So I bet it's something more subtle, like strange behaviour with
> >> sleep state, powering down the PCIe bus right, etc, etc.
> >
> > I can trigger the hang with iwconfig wlan0 tx off, if that helps. I
> > thought that sounded fairly specific to the chip...
> 
> Have you compiled the driver with debugging? You could enable ath
> debugging (set debug to 0xffffffff; I think there's a proc/sysfs
> variable for this too) and then run iwconfig wlan0 tx off; see how far
> it gets. It may not even be an ath9k bug.. :-)
> 
> 
> Adrian
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel


-- 
Lars Schotte
@ Hana (F14)

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Sun, 5 Jun 2011 20:26:03 +0800
Adrian Chadd <adrian@freebsd.org> wrote:

> To check, find where in the proc/sys fs's regval/regidx now live, and
> 
> echo "0x7868" > regidx
> cat regval

I can't find regval or regidx. Looking at another reply I can see they
live in a debug subdirectory. Do I need to enable debugging for ath9k?
Or do I need a newer kernel than 2.6.32. I'm using that because it's the
latest Debian stock kernel I can use without crashing, but it has
drawbacks such as issues with nouveau, and I guess it will eventually
hold me back from other upgrades.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

On 5 June 2011 21:04, Camilo Mesias <camilo@mesias.co.uk> wrote:
> Hi,
>
> thanks for the suggestions.
>
> I didn't get back a stable value from that regidx/regval, I settled on this:
>
> [root at newt ~]# for x in $(seq 1 1000) ; do echo "0x7868" >
> /sys/kernel/debug/ieee80211/phy0/ath9k/regidx; cat
> /sys/kernel/debug/ieee80211/phy0/ath9k/regval; done|sort |uniq
> 0x02036085
> 0x42030085
> 0x42035885
> 0x42036085
> 0x82030085
> 0x82036085
>
> Does that trailing 5 mean anything? Here is the corresponding lspci output:

It means you have an AR9285, not AR9285SE. (the last three bits have
to be 0x01, and yours is 0x5. :-)

>> You could also try flipping the AR9285_WA_DEFAULT value and/or
>> register inivals back to the previous version?
>
> Is this a rebuild of the kernel module or configuration?

The kernel module.

>> So I bet it's something more subtle, like strange behaviour with sleep
>> state, powering down the PCIe bus right, etc, etc.
>
> I can trigger the hang with iwconfig wlan0 tx off, if that helps. I
> thought that sounded fairly specific to the chip...

Have you compiled the driver with debugging? You could enable ath
debugging (set debug to 0xffffffff; I think there's a proc/sysfs
variable for this too) and then run iwconfig wlan0 tx off; see how far
it gets. It may not even be an ath9k bug.. :-)


Adrian

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Sun, 5 Jun 2011 07:30:34 -0400
Camilo Mesias <camilo@mesias.co.uk> wrote:

> I have a suspicion the lockup happens in the rf off code, because I
> can cause the lockup reliably simply with iwconfig wlan0 tx off
> Can other people confirm this? Is it worth putting more defensive
> code in that function?

This is what I found (I forgot to use Reply To All so I only sent this
to Mohammed Shafi before):

: The freeze is in ath9k_hw_set_power_awake during the for() loop when it
: calls
: REG_SET_BIT(ah, AR_RTC_FORCE_WAKE, AR_RTC_FORCE_WAKE_EN);

That could be wrong because I used printk to track it down and there may
be a race condition between the crash and the messages appearing on the
console.

I also discovered that
  val = REG_READ(ah, AR_RTC_STATUS) & AR_RTC_STATUS_M;
had a result of 15, but the status should only have one bit set at a
time I think?

I also wondered why it was trying to go into a wake state when it was
supposed to be shutting down.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Camilo Mesias]

Hi,

thanks for the suggestions.

I didn't get back a stable value from that regidx/regval, I settled on this:

[root at newt ~]# for x in $(seq 1 1000) ; do echo "0x7868" >
/sys/kernel/debug/ieee80211/phy0/ath9k/regidx; cat
/sys/kernel/debug/ieee80211/phy0/ath9k/regval; done|sort |uniq
0x02036085
0x42030085
0x42035885
0x42036085
0x82030085
0x82036085

Does that trailing 5 mean anything? Here is the corresponding lspci output:

03:00.0 Network controller: Atheros Communications Inc. AR9285
Wireless Network Adapter (PCI-Express) (rev 01)
        Subsystem: Hewlett-Packard Company Device 3040
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory@d3000000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA
PME(D0+,D1+,D2-,D3hot+,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
                Address: 00000000  Data: 0000
        Capabilities: [60] Express (v2) Legacy Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
<512ns, L1 <64us
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq-
AuxPwr- TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
Latency L0 <512ns, L1 <64us
                        ClockPM- Surprise- LLActRep- BwNot-
                LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled-
Retrain- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train-
SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Not Supported, TimeoutDis+
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
                LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
SpeedDis-, Selectable De-emphasis: -6dB
                         Transmit Margin: Normal Operating Range,
EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB
        Capabilities: [100 v1] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
                AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
        Capabilities: [140 v1] Virtual Channel
                Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
                Arb:    Fixed- WRR32- WRR64- WRR128-
                Ctrl:   ArbSelect=Fixed
                Status: InProgress-
                VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
                        Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
                        Status: NegoPending- InProgress-
        Capabilities: [160 v1] Device Serial Number 00-15-17-ff-ff-24-14-12
        Capabilities: [170 v1] Power Budgeting <?>
        Kernel driver in use: ath9k
        Kernel modules: ath9k


> You could also try flipping the AR9285_WA_DEFAULT value and/or
> register inivals back to the previous version?

Is this a rebuild of the kernel module or configuration?

> So I bet it's something more subtle, like strange behaviour with sleep
> state, powering down the PCIe bus right, etc, etc.

I can trigger the hang with iwconfig wlan0 tx off, if that helps. I
thought that sounded fairly specific to the chip...

-Cam

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

I went back to the original commit message:

http://git390.marist.edu/cgi-bin/gitweb.cgi?p=linux-2.6.git;a=commit;h=53bc7aa08b48e5cd745f986731cc7dc24eef2a9f

It looks like the commit did more than "add a new AR9285 chip."

It did add the AR9285SE initvals and version check macro, but it also:

* added new calibration code;
* changed the inivals a bit
* changed the AR9285_WA_DEFAULT register, which is involved in PCI powersave

I can't imagine it's the calibration code, but hey. :-)

If your AR9285 happens to be one of these AR9285SE versions, then it
could be due to that.
To check, find where in the proc/sys fs's regval/regidx now live, and

echo "0x7868" > regidx
cat regval

The last digit in the regval should either be 0x1 or 0x9 for an
AR9285SE. If that's the case, I can step you through disabling the
AR9285SE macro in the source so your device attaches as a normal
AR9285, but I have no idea if it works that way or not. :)

You could also try flipping the AR9285_WA_DEFAULT value and/or
register inivals back to the previous version?

I've tried a recent ath9k on my test laptop and it works fine, and I
have a very large stack of cards which include half a dozen different
AR9285s (but alas no AR9285SEs.)

So I bet it's something more subtle, like strange behaviour with sleep
state, powering down the PCIe bus right, etc, etc.

Good luck!


Adrian

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Camilo Mesias]

I have a suspicion the lockup happens in the rf off code, because I can
cause the lockup reliably simply with iwconfig wlan0 tx off
Can other people confirm this? Is it worth putting more defensive code in
that function?

-Cam

On 5 Jun 2011 12:21, "Adri? Cereto Massagu?" <ssorgatem@gmail.com> wrote:

Hi,

Just wanted to say that I have the exact same issue with a Packard-Bell dot
m/a 134, and I reported it before too.


2011/6/5 Adrian Chadd <adrian@freebsd.org>
>
> On 5 June 2011 01:08, Tony Houghton <h@realh.co.uk> ...
-- 
*Adri? Cereto Massagu?*
Biotechnology student
Universitat Rovira i Virgili

Languages: Catal?, Espa?ol, English, Fran?ais, Deutsch, Portugu?s, Esperanto

Nota importante
<http://www.gnu.org/philosophy/no-word-attachments.es.html>| Important
Notice <http://www.gnu.org/philosophy/no-word-attachments.html>


_______________________________________________
ath9k-devel mailing list
ath9k-devel at lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110605/aa25f93f/attachment.htm 

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrià Cereto Massagué]

Hi,

Just wanted to say that I have the exact same issue with a Packard-Bell dot
m/a 134, and I reported it before too.

2011/6/5 Adrian Chadd <adrian@freebsd.org>

> On 5 June 2011 01:08, Tony Houghton <h@realh.co.uk> wrote:
>
> > I'm puzzled about why the driver works without the changes that
> > supposedly introduced support for AR9285. Does the older version use a
> > sort of generic 9k driver and the later version introduces specific
> > support for certain features of the AR9285? Is there any way I can force
> > an up-to-date kernel to use this generic mode?
>
> It wouldn't have worked without AR9285-specific stuff, because the
> radio setup code is specific to the EEPROM version and the AR9285 has
> a different radio to the previous members of the AR9002 family (AR9280
> in particular.)
>
> I suggest just doing the standard bisect trick to figure out where
> things stopped working for you.
>
> It could be hanging the computer for a variety of reasons which may be
> related to ath9k (eg changes to the chip power on/off logic), power
> saving mode config, or maybe non-ath9k reasons (eg generic PCI(e) bus
> attach/detach handling.)
>
>
>
> Adrian
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>



-- 
*Adri? Cereto Massagu?*
Biotechnology student
Universitat Rovira i Virgili

Languages: Catal?, Espa?ol, English, Fran?ais, Deutsch, Portugu?s, Esperanto

Nota importante
<http://www.gnu.org/philosophy/no-word-attachments.es.html>| Important
Notice <http://www.gnu.org/philosophy/no-word-attachments.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110605/ac4de22e/attachment.html 

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrian Chadd]

On 5 June 2011 01:08, Tony Houghton <h@realh.co.uk> wrote:

> I'm puzzled about why the driver works without the changes that
> supposedly introduced support for AR9285. Does the older version use a
> sort of generic 9k driver and the later version introduces specific
> support for certain features of the AR9285? Is there any way I can force
> an up-to-date kernel to use this generic mode?

It wouldn't have worked without AR9285-specific stuff, because the
radio setup code is specific to the EEPROM version and the AR9285 has
a different radio to the previous members of the AR9002 family (AR9280
in particular.)

I suggest just doing the standard bisect trick to figure out where
things stopped working for you.

It could be hanging the computer for a variety of reasons which may be
related to ath9k (eg changes to the chip power on/off logic), power
saving mode config, or maybe non-ath9k reasons (eg generic PCI(e) bus
attach/detach handling.)



Adrian

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Sat, 4 Jun 2011 14:56:10 -0400
Camilo Mesias <camilo@mesias.co.uk> wrote:

> I have the same hardware and the same fault, I don't think it's faulty
> hardware. My tale of woe is reported here too.

Ah well, I suppose it's good to know I'm not the only one. More
incentive for the bug to be fixed perhaps. I wonder if it's something
specific to the UK or Europe.

> Currently I'm trying to shoehorn an Intel based wifi card into the
> machine but there is a BIOS whitelist in the way. There is a tweaked
> BIOS where the whitelist is disabled, but reflashing the BIOS from
> Linux is difficult / impossible, it seems.

I didn't know they'd crippled the BIOS like that. I won't be buying HP
again.

> I'm doing this because a
> git bisect of the driver since when it worked isn't an attractive
> option.

No, but I've done it! If you're interested I can look back through my
old emails and find the git SHA code. I can't be 100% sure I found the
right commit, but I tested the "good" one fairly thoroughly. The commit
message said that the changeset introduced support for AR9285.

> This is a reproducible problem though, maybe not reported by many
> people but very real. Even a simple rmmod will lock up the machine.
> Commands like ifconfig X down / iwconfig X tx off / rmmod don't help
> either.

Same here. At one point I found that I could safely suspend and resume
by disconnecting the PSU before rmmod ath9k but that seemed to stop
working after a while. It might help to also be on battery power when
booting or loading the module though.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Camilo Mesias]

Hi,

I have the same hardware and the same fault, I don't think it's faulty
hardware. My tale of woe is reported here too.

Currently I'm trying to shoehorn an Intel based wifi card into the
machine but there is a BIOS whitelist in the way. There is a tweaked
BIOS where the whitelist is disabled, but reflashing the BIOS from
Linux is difficult / impossible, it seems. I'm doing this because a
git bisect of the driver since when it worked isn't an attractive
option.

This is a reproducible problem though, maybe not reported by many
people but very real. Even a simple rmmod will lock up the machine.
Commands like ifconfig X down / iwconfig X tx off / rmmod don't help
either.

Where I first reported my problem:
https://bugzilla.redhat.com/show_bug.cgi?id=697157

Reported on this list:
http://permalink.gmane.org/gmane.linux.drivers.ath9k.devel/6237

-Cam

On Sat, Jun 4, 2011 at 1:08 PM, Tony Houghton <h@realh.co.uk> wrote:
>> On Mon, May 9, 2011 at 9:15 PM, Tony Houghton <h@realh.co.uk> wrote:
>> > [Recap: my Compaq/HP 311c Mini netbook with AR9285 locks up when the
>> > wifi connection is shut down for any reason, since kernel 2.6.35]
>
> I think if you can't reproduce it and nobody else has complained I might
> have a hardware fault. It looks like it's possible to replace the wifi
> unit, is there any you recommend? Apparently the same device is
> responsible for Bluetooth too and I would like to keep that
> functionality.
>
> I'm puzzled about why the driver works without the changes that
> supposedly introduced support for AR9285. Does the older version use a
> sort of generic 9k driver and the later version introduces specific
> support for certain features of the AR9285? Is there any way I can force
> an up-to-date kernel to use this generic mode?
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

> On Mon, May 9, 2011 at 9:15 PM, Tony Houghton <h@realh.co.uk> wrote:
> > [Recap: my Compaq/HP 311c Mini netbook with AR9285 locks up when the
> > wifi connection is shut down for any reason, since kernel 2.6.35]

I think if you can't reproduce it and nobody else has complained I might
have a hardware fault. It looks like it's possible to replace the wifi
unit, is there any you recommend? Apparently the same device is
responsible for Bluetooth too and I would like to keep that
functionality.

I'm puzzled about why the driver works without the changes that
supposedly introduced support for AR9285. Does the older version use a
sort of generic 9k driver and the later version introduces specific
support for certain features of the AR9285? Is there any way I can force
an up-to-date kernel to use this generic mode?

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Mon, May 9, 2011 at 9:15 PM, Tony Houghton <h@realh.co.uk> wrote:
> [Recap: my Compaq/HP 311c Mini netbook with AR9285 locks up when the
> wifi connection is shut down for any reason, since kernel 2.6.35]
>
> On Mon, 21 Mar 2011 20:20:23 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> I got a compaq machine, i will try to reproduce the issue now, most
>> probable i will hit it.
>
> I guess you haven't been able to reproduce it?
>
> Yesterday I fetched wireless-testing from git and added some printk
> calls. I tested it by logging all kernel messages to the console and
> running rmmod ath9k. The freeze is in ath9k_hw_set_power_awake during
> the for() loop when it calls
> ? ?REG_SET_BIT(ah, AR_RTC_FORCE_WAKE,
> ? ? ? ?AR_RTC_FORCE_WAKE_EN);

instead of adding printk's please increase the udelay(50) to some higher value

>
> On my most recent test, val (from
> ? ?val = REG_READ(ah, AR_RTC_STATUS) & AR_RTC_STATUS_M;
> ) was 15 and i (the loop iterator) was 199 ie it happened on the second
> iteration. Unfortunately I neglected to note what happened at this
> point:

value 15 does not seems to be correct. it looks all the bits of
RTC_STATUS are set

bit 0 - shutdown
bit 1- ON
bit 2 - sleep
BIT 3 -wake up
bit 4 -cold reset.

for me I am getting RTC status as 0X2(ON).

>
> ? ?/* Set Bits 14 and 17 of AR_WA before powering on the chip. */
> ? ?if (AR_SREV_9300_20_OR_LATER(ah)) {
> ? ? ? ? ? ?REG_WRITE(ah, AR_WA, ah->WARegVal);
> ? ? ? ? ? ?udelay(10);
> ? ?}
>
> Could that be critical?
>
> On one try, after adding printk statements inside the loop, I could not
> reproduce the crash for several attempts in a row, so I surmised that
> the chip can't cope with the FORCE_WAKE bit being set so rapidly and the
> printks had slowed it down sufficiently, but on a subsequent run it did
> crash again with those printks in the loop.
>
> I wonder if it's incorrect to try to set the power mode to AWAKE during
> shutdown? It doesn't seem right to me. It does this after setting the
> mode to ATH9K_PM_FULL_SLEEP.
>
> I hope you will be able to work out what the problem is and fix it soon.
> Please do not hesitate to ask me if you need more information from
> debugging.
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Mon, May 9, 2011 at 9:15 PM, Tony Houghton <h@realh.co.uk> wrote:
> [Recap: my Compaq/HP 311c Mini netbook with AR9285 locks up when the
> wifi connection is shut down for any reason, since kernel 2.6.35]
>
> On Mon, 21 Mar 2011 20:20:23 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> I got a compaq machine, i will try to reproduce the issue now, most
>> probable i will hit it.
>
> I guess you haven't been able to reproduce it?
>
> Yesterday I fetched wireless-testing from git and added some printk
> calls. I tested it by logging all kernel messages to the console and
> running rmmod ath9k. The freeze is in ath9k_hw_set_power_awake during
> the for() loop when it calls
> ? ?REG_SET_BIT(ah, AR_RTC_FORCE_WAKE,
> ? ? ? ?AR_RTC_FORCE_WAKE_EN);
>
> On my most recent test, val (from
> ? ?val = REG_READ(ah, AR_RTC_STATUS) & AR_RTC_STATUS_M;
> ) was 15 and i (the loop iterator) was 199 ie it happened on the second
> iteration. Unfortunately I neglected to note what happened at this
> point:
>
> ? ?/* Set Bits 14 and 17 of AR_WA before powering on the chip. */
> ? ?if (AR_SREV_9300_20_OR_LATER(ah)) {
> ? ? ? ? ? ?REG_WRITE(ah, AR_WA, ah->WARegVal);
> ? ? ? ? ? ?udelay(10);
> ? ?}

please neglect the above lines, its only for AR9003 chip sets, our is
AR9002 based.. so the code wont hit

>
> Could that be critical?
>
> On one try, after adding printk statements inside the loop, I could not
> reproduce the crash for several attempts in a row, so I surmised that
> the chip can't cope with the FORCE_WAKE bit being set so rapidly and the
> printks had slowed it down sufficiently, but on a subsequent run it did
> crash again with those printks in the loop.
>
> I wonder if it's incorrect to try to set the power mode to AWAKE during
> shutdown? It doesn't seem right to me. It does this after setting the
> mode to ATH9K_PM_FULL_SLEEP.
>
> I hope you will be able to work out what the problem is and fix it soon.
> Please do not hesitate to ask me if you need more information from
> debugging.
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Mon, May 9, 2011 at 9:15 PM, Tony Houghton <h@realh.co.uk> wrote:
> [Recap: my Compaq/HP 311c Mini netbook with AR9285 locks up when the
> wifi connection is shut down for any reason, since kernel 2.6.35]
>
> On Mon, 21 Mar 2011 20:20:23 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> I got a compaq machine, i will try to reproduce the issue now, most
>> probable i will hit it.
>
> I guess you haven't been able to reproduce it?

you got me :)  I am leaving office now, its too late. let me please
check those registers in the data sheet and see if some things is
wrong.

thanks,
shafi

>
> Yesterday I fetched wireless-testing from git and added some printk
> calls. I tested it by logging all kernel messages to the console and
> running rmmod ath9k. The freeze is in ath9k_hw_set_power_awake during
> the for() loop when it calls
> ? ?REG_SET_BIT(ah, AR_RTC_FORCE_WAKE,
> ? ? ? ?AR_RTC_FORCE_WAKE_EN);
>
> On my most recent test, val (from
> ? ?val = REG_READ(ah, AR_RTC_STATUS) & AR_RTC_STATUS_M;
> ) was 15 and i (the loop iterator) was 199 ie it happened on the second
> iteration. Unfortunately I neglected to note what happened at this
> point:
>
> ? ?/* Set Bits 14 and 17 of AR_WA before powering on the chip. */
> ? ?if (AR_SREV_9300_20_OR_LATER(ah)) {
> ? ? ? ? ? ?REG_WRITE(ah, AR_WA, ah->WARegVal);
> ? ? ? ? ? ?udelay(10);
> ? ?}
>
> Could that be critical?
>
> On one try, after adding printk statements inside the loop, I could not
> reproduce the crash for several attempts in a row, so I surmised that
> the chip can't cope with the FORCE_WAKE bit being set so rapidly and the
> printks had slowed it down sufficiently, but on a subsequent run it did
> crash again with those printks in the loop.
>
> I wonder if it's incorrect to try to set the power mode to AWAKE during
> shutdown? It doesn't seem right to me. It does this after setting the
> mode to ATH9K_PM_FULL_SLEEP.
>
> I hope you will be able to work out what the problem is and fix it soon.
> Please do not hesitate to ask me if you need more information from
> debugging.
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

[Recap: my Compaq/HP 311c Mini netbook with AR9285 locks up when the
wifi connection is shut down for any reason, since kernel 2.6.35]

On Mon, 21 Mar 2011 20:20:23 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> I got a compaq machine, i will try to reproduce the issue now, most
> probable i will hit it.

I guess you haven't been able to reproduce it?

Yesterday I fetched wireless-testing from git and added some printk
calls. I tested it by logging all kernel messages to the console and
running rmmod ath9k. The freeze is in ath9k_hw_set_power_awake during
the for() loop when it calls
    REG_SET_BIT(ah, AR_RTC_FORCE_WAKE,
        AR_RTC_FORCE_WAKE_EN);

On my most recent test, val (from
    val = REG_READ(ah, AR_RTC_STATUS) & AR_RTC_STATUS_M;
) was 15 and i (the loop iterator) was 199 ie it happened on the second
iteration. Unfortunately I neglected to note what happened at this
point:

    /* Set Bits 14 and 17 of AR_WA before powering on the chip. */
    if (AR_SREV_9300_20_OR_LATER(ah)) {
            REG_WRITE(ah, AR_WA, ah->WARegVal);
            udelay(10);
    }

Could that be critical?

On one try, after adding printk statements inside the loop, I could not
reproduce the crash for several attempts in a row, so I surmised that
the chip can't cope with the FORCE_WAKE bit being set so rapidly and the
printks had slowed it down sufficiently, but on a subsequent run it did
crash again with those printks in the loop.

I wonder if it's incorrect to try to set the power mode to AWAKE during
shutdown? It doesn't seem right to me. It does this after setting the
mode to ATH9K_PM_FULL_SLEEP.

I hope you will be able to work out what the problem is and fix it soon.
Please do not hesitate to ask me if you need more information from
debugging.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Mon, 21 Mar 2011 20:20:23 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> I got a compaq machine, i will try to reproduce the issue now, most
> probable i will hit it.

I hope so.

I've just tested the fix-kernel-panic.patch you sent. I applied it to
compat-wireless-2011-03-20 built against Debian kernel 2.6.38-1-686. As
you thought, it didn't cure the crashing. I've got another netconsole
log, but I don't think it will help because no new lines appeared
between disconnecting the wireless and the crash (possibly the last one
or two did, but I think they were probably there before).

The behaviour with the mains power disconnected seems quite consistent
too. I can then freely disconnect/disable wireless etc except that if I
suspend it crashes on resume (with no netconsole message). I confirmed
that was ath9k and not something else by issuing rmmod before
suspending, and then it resumed successfully. So at least now I think I
can make the machine usable with an up-to-date kernel as long as I
remember to unplug then rmmod before suspending or shutting down.

I also noticed that when I loaded the module while on battery power and
plugged the power in afterwards it behaved the same as if it was still
on battery power, but I've only done that once so I don't know if that's
consistent.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: toddlog
Type: application/octet-stream
Size: 2695 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110321/9e828293/attachment-0001.obj 

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Mon, Mar 14, 2011 at 9:57 PM, Tony Houghton <h@realh.co.uk> wrote:
> On Mon, 14 Mar 2011 11:53:42 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> On Mon, Mar 14, 2011 at 11:51 AM, Mohammed Shafi
>> <shafi.wireless@gmail.com> wrote:
>> >
>> > ? ? ? ? not reproducible in 2.6.38-rc7-wl wireless testing under
>> > Ubuntu, dont know where i am missing.
>> > I tried suspend-resume with/without disabling network manager. no
>> > kernel lock ups.
>> > also attaching my wireless tesing .config which may be of some
>> > help. any ideas?
>>
>> also lspci -vvvnn looks the card we are using ?is same as yours?
>>
>> 05:00.0 Network controller [0280]: Atheros Communications Inc. AR9285
>> Wireless Network Adapter (PCI-Express) [168c:002b] (rev 01)
>> ? ? ? ? Subsystem: Atheros Communications Inc. Device [168c:30a1]
>> ? ? ? ? Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>> ? ? ? ? Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>> ? ? ? ? Latency: 0, Cache Line Size: 64 bytes
>> ? ? ? ? Interrupt: pin A routed to IRQ 19
>> ? ? ? ? Region 0: Memory at f4800000 (64-bit, non-prefetchable)
>> [size=64K] Capabilities: <access denied>
>> ? ? ? ? Kernel driver in use: ath9k
>> ? ? ? ? Kernel modules: ath9k
>
> Here is my lspci output (it's the same for kernel 2.6.34 and 2.6.37) and
> the kernel configs for 2.6.34 (one of the most recent versions I
> compiled from git that doesn't crash) and 2.6.37 (Debian stock which
> does crash).
>

I got a compaq machine, i will try to reproduce the issue now, most
probable i will hit it.

>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Sat, Mar 19, 2011 at 9:09 PM, Mohammed Shafi
<shafi.wireless@gmail.com> wrote:
> On Mon, Mar 14, 2011 at 9:57 PM, Tony Houghton <h@realh.co.uk> wrote:
>> On Mon, 14 Mar 2011 11:53:42 +0530
>> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>>
>>> On Mon, Mar 14, 2011 at 11:51 AM, Mohammed Shafi
>>> <shafi.wireless@gmail.com> wrote:
>>> >
>>> > ? ? ? ? not reproducible in 2.6.38-rc7-wl wireless testing under
>>> > Ubuntu, dont know where i am missing.
>>> > I tried suspend-resume with/without disabling network manager. no
>>> > kernel lock ups.
>>> > also attaching my wireless tesing .config which may be of some
>>> > help. any ideas?
>>>
>>> also lspci -vvvnn looks the card we are using ?is same as yours?
>>>
>>> 05:00.0 Network controller [0280]: Atheros Communications Inc. AR9285
>>> Wireless Network Adapter (PCI-Express) [168c:002b] (rev 01)
>>> ? ? ? ? Subsystem: Atheros Communications Inc. Device [168c:30a1]
>>> ? ? ? ? Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>>> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>>> ? ? ? ? Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>> ? ? ? ? Latency: 0, Cache Line Size: 64 bytes
>>> ? ? ? ? Interrupt: pin A routed to IRQ 19
>>> ? ? ? ? Region 0: Memory at f4800000 (64-bit, non-prefetchable)
>>> [size=64K] Capabilities: <access denied>
>>> ? ? ? ? Kernel driver in use: ath9k
>>> ? ? ? ? Kernel modules: ath9k
>>
>> Here is my lspci output (it's the same for kernel 2.6.34 and 2.6.37) and
>> the kernel configs for 2.6.34 (one of the most recent versions I
>> compiled from git that doesn't crash) and 2.6.37 (Debian stock which
>> does crash).
>>
>>
>
> Tony if you have time please try with the attached patch. Its
> possibility of fixing your issue is very less. This patch does fixes a
> kernel panic thing in another AR9285 card(fortunately the issue got
> reproduced every time when i connect to an AP).
> ? ? The difficult thing for me is to reproduce your issue. I can try
> hard to reproduce your issue when I get some ample time.
> Attached diff patch which you can try with your compat wireless with
> the patch -p1 command.

FYI i got the following call trace in the netconsole when the system
completely froze. if you can get some thing like that it can be
helpful.
  1
  2 [  191.320157] BUG: unable to handle kernel NULL pointer
dereference at (null)
  3 [  191.320164] IP: [<fd2586d4>] ath_tx_start+0x474/0x770 [ath9k]
  4 [  191.320172] *pde = b9010067
  5 [  191.320176] Thread overran stack, or stack corrupted
  6 [  191.320179] Oops: 0000 [#1] SMP
  7 [  191.320185] last sysfs file:
/sys/devices/pci0000:00/0000:00:19.0/net/eth0/carrier
  8 [  191.320188] Modules linked in: ath9k mac80211 ath9k_common
ath9k_hw ath cfg80211 compat netconsole configfs binfmt_misc ppdev
snd_hda_codec_conexant fbcon tileblit font b    itblit softcursor
vga16fb vgastate joydev arc4 pcmcia snd_hda_intel snd_hda_codec
snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss
snd_seq_midi snd_rawm    idi snd_seq_midi_event snd_seq i915 snd_timer
uvcvideo drm_kms_helper snd_seq_device videodev v4l1_compat psmouse
serio_raw yenta_socket rsrc_nonstatic tpm_tis tpm thinkpad_    acpi
snd bluetooth drm tpm_bios nvram led_class pcmcia_core soundcore
snd_page_alloc intel_agp i2c_algo_bit video output agpgart lp parport
ohci1394 ieee1394 ahci e1000e [la    st unloaded: compat]
  9 [  191.320294]
 10 [  191.320298] Pid: 0, comm: swapper Not tainted
(2.6.32-25-generic #45-Ubuntu) 64756D6
 11 [  191.320301] EIP: 0060:[<fd2586d4>] EFLAGS: 00010246 CPU: 0
 12 [  191.320305] EIP is at ath_tx_start+0x474/0x770 [ath9k]
 13 [  191.320307] EAX: 00000000 EBX: 00000000 ECX: c0761b10 EDX: f0ddaa60
 14 [  191.320310] ESI: f0ddaa54 EDI: f29ad540 EBP: c0761aec ESP: c0761a90
 15 [  191.320313]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
 16 [  191.320316] Process swapper (pid: 0, ti=c0760000 task=c0766e80
task.ti=c0760000)
 17 [  191.320318] Stack:
 18 [  191.320320]  00000001 00000001 f229125c 30ddc82c 00000002
f0dd4fe0 0000001a 00000000
 19 [  191.320332] <0> f0dd59d8 f29ad578 f229125c f0ddaa60 f0dd4fe0
00000000 f21f88a0 c0761b10
 20 [  191.320345] <0> f0dd4fe0 f29ad540 c0761b24 c0761aec f0dd4fe0
f29ad540 c0761b24 c0761b30
 21 [  191.320358] Call Trace:
 22 [  191.320364]  [<fd250ea7>] ? ath9k_tx+0xa7/0x200 [ath9k]
 23 [  191.320376]  [<fd1ec7fc>] ? __ieee80211_tx+0x5c/0x1e0 [mac80211]
 24 [  191.320386]  [<fd1edd2b>] ? ieee80211_tx+0x7b/0x90 [mac80211]
 25 [  191.320395]  [<fd1edddd>] ? ieee80211_xmit+0x9d/0x1d0 [mac80211]
 26 [  191.320401]  [<c014218f>] ? wake_up_state+0xf/0x20
 27 [  191.320405]  [<c015dbc8>] ? signal_wake_up+0x28/0x40
 28 [  191.320410]  [<c012a578>] ? default_spin_lock_flags+0x8/0x10
 29 [  191.320420]  [<fd1ee308>] ?
ieee80211_subif_start_xmit+0x2e8/0x7c0 [mac80211]
 30 [  191.320425]  [<c058f905>] ? do_page_fault+0x295/0x3a0
 31 [  191.320431]  [<c04c4a3d>] ? dev_hard_start_xmit+0x1ad/0x210
 32 [  191.320436]  [<c04d96b5>] ? sch_direct_xmit+0x105/0x170
 33 [  191.320445]  [<fd1f161a>] ? get_sta_flags+0x2a/0x40 [mac80211]
 34 [  191.320449]  [<c04c780f>] ? dev_queue_xmit+0x37f/0x4b0
 35 [  191.320452]  [<c04d75b0>] ? eth_header+0x0/0xb0
 36 [  191.320456]  [<c04cc479>] ? neigh_resolve_output+0xe9/0x310
 37 [  191.320461]  [<c053d295>] ? ip6_output_finish+0xa5/0x110
 38 [  191.320464]  [<c053e354>] ? ip6_output2+0x134/0x250
 39 [  191.320468]  [<c053f7dd>] ? ip6_output+0x6d/0x100
 40 [  191.320471]  [<c0559665>] ? mld_sendpack+0x395/0x3e0
 41 [  191.320475]  [<c0557f81>] ? add_grhead+0x31/0xa0
 42 [  191.320478]  [<c055a83c>] ? mld_send_cr+0x1bc/0x2b0
 43 [  191.320482]  [<c01535d9>] ? irq_exit+0x39/0x70
 44 [  191.320485]  [<c055a940>] ? mld_ifc_timer_expire+0x10/0x40
 45 [  191.320489]  [<c015b92e>] ? run_timer_softirq+0x13e/0x2c0
 46 [  191.320493]  [<c0103a30>] ? common_interrupt+0x30/0x40




> thanks,
> shafi
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Mon, Mar 14, 2011 at 9:57 PM, Tony Houghton <h@realh.co.uk> wrote:
> On Mon, 14 Mar 2011 11:53:42 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>
>> On Mon, Mar 14, 2011 at 11:51 AM, Mohammed Shafi
>> <shafi.wireless@gmail.com> wrote:
>> >
>> > ? ? ? ? not reproducible in 2.6.38-rc7-wl wireless testing under
>> > Ubuntu, dont know where i am missing.
>> > I tried suspend-resume with/without disabling network manager. no
>> > kernel lock ups.
>> > also attaching my wireless tesing .config which may be of some
>> > help. any ideas?
>>
>> also lspci -vvvnn looks the card we are using ?is same as yours?
>>
>> 05:00.0 Network controller [0280]: Atheros Communications Inc. AR9285
>> Wireless Network Adapter (PCI-Express) [168c:002b] (rev 01)
>> ? ? ? ? Subsystem: Atheros Communications Inc. Device [168c:30a1]
>> ? ? ? ? Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>> ? ? ? ? Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>> ? ? ? ? Latency: 0, Cache Line Size: 64 bytes
>> ? ? ? ? Interrupt: pin A routed to IRQ 19
>> ? ? ? ? Region 0: Memory at f4800000 (64-bit, non-prefetchable)
>> [size=64K] Capabilities: <access denied>
>> ? ? ? ? Kernel driver in use: ath9k
>> ? ? ? ? Kernel modules: ath9k
>
> Here is my lspci output (it's the same for kernel 2.6.34 and 2.6.37) and
> the kernel configs for 2.6.34 (one of the most recent versions I
> compiled from git that doesn't crash) and 2.6.37 (Debian stock which
> does crash).
>
>

Tony if you have time please try with the attached patch. Its
possibility of fixing your issue is very less. This patch does fixes a
kernel panic thing in another AR9285 card(fortunately the issue got
reproduced every time when i connect to an AP).
     The difficult thing for me is to reproduce your issue. I can try
hard to reproduce your issue when I get some ample time.
Attached diff patch which you can try with your compat wireless with
the patch -p1 command.
thanks,
shafi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-kernel-panic.patch
Type: text/x-diff
Size: 636 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110319/ab668f4d/attachment.patch 

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Mon, 14 Mar 2011 11:53:42 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> On Mon, Mar 14, 2011 at 11:51 AM, Mohammed Shafi
> <shafi.wireless@gmail.com> wrote:
> >
> > ? ? ? ? not reproducible in 2.6.38-rc7-wl wireless testing under
> > Ubuntu, dont know where i am missing.
> > I tried suspend-resume with/without disabling network manager. no
> > kernel lock ups.
> > also attaching my wireless tesing .config which may be of some
> > help. any ideas?
> 
> also lspci -vvvnn looks the card we are using  is same as yours?
> 
> 05:00.0 Network controller [0280]: Atheros Communications Inc. AR9285
> Wireless Network Adapter (PCI-Express) [168c:002b] (rev 01)
>         Subsystem: Atheros Communications Inc. Device [168c:30a1]
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 0, Cache Line Size: 64 bytes
>         Interrupt: pin A routed to IRQ 19
>         Region 0: Memory at f4800000 (64-bit, non-prefetchable)
> [size=64K] Capabilities: <access denied>
>         Kernel driver in use: ath9k
>         Kernel modules: ath9k

Here is my lspci output (it's the same for kernel 2.6.34 and 2.6.37) and
the kernel configs for 2.6.34 (one of the most recent versions I
compiled from git that doesn't crash) and 2.6.37 (Debian stock which
does crash).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lspci-2.6.37
Type: application/octet-stream
Size: 2969 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110314/249357c5/attachment-0003.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config-2.6.34
Type: application/octet-stream
Size: 114206 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110314/249357c5/attachment-0004.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config-2.6.37-2-686
Type: application/octet-stream
Size: 124740 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110314/249357c5/attachment-0005.obj 

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

2011/3/14 Adri? Cereto Massagu? <ssorgatem@gmail.com>:
>
>
> 2011/3/14 Mohammed Shafi <shafi.wireless@gmail.com>
>>
>> On Mon, Mar 14, 2011 at 11:51 AM, Mohammed Shafi
>> <shafi.wireless@gmail.com> wrote:
>> > 2011/3/10 Tony Houghton <h@realh.co.uk>:
>> >> On Thu, 10 Mar 2011 12:02:21 +0100
>> >> Adri? Cereto Massagu? <ssorgatem@gmail.com> wrote:
>> >>
>> >>> I can reproduce the same issue, since kernel 2.6.35 ?and a AR9285.
>> >>>
>> >>> I'm also using debian (sid).
>> >>>
>> >>> Seeing we both having this issue use debian, could it be something
>> >>> debian-specific?
>> >>
>> >> I don't think so. I reproduced the problem with Ubuntu and I also
>> >> tested
>> >> kernels straight from git - but I did use make deb-pkg and a .config
>> >> based on Debian's.
>> >
>> > ? ? ? ? not reproducible in 2.6.38-rc7-wl wireless testing under
>> > Ubuntu, dont know where i am missing.
>> > I tried suspend-resume with/without disabling network manager. no
>> > kernel lock ups.
>> > also attaching my wireless tesing .config which may be of some help. any
>> > ideas?
>>
>> also lspci -vvvnn looks the card we are using ?is same as yours?
>>
>> 05:00.0 Network controller [0280]: Atheros Communications Inc. AR9285
>> Wireless Network Adapter (PCI-Express) [168c:002b] (rev 01)
>> ? ? ? ?Subsystem: Atheros Communications Inc. Device [168c:30a1]
>> ? ? ? ?Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>> ? ? ? ?Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>> ? ? ? ?Latency: 0, Cache Line Size: 64 bytes
>> ? ? ? ?Interrupt: pin A routed to IRQ 19
>> ? ? ? ?Region 0: Memory at f4800000 (64-bit, non-prefetchable) [size=64K]
>> ? ? ? ?Capabilities: <access denied>
>> ? ? ? ?Kernel driver in use: ath9k
>> ? ? ? ?Kernel modules: ath9k
>>
>>
>> > thanks,
>> > shafi
>> >
>> >
>> >> _______________________________________________
>> >> ath9k-devel mailing list
>> >> ath9k-devel at lists.ath9k.org
>> >> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>> >>
>> >
>
> I attach my lspci (for me it looks like it's the same card) output and a
> kernel configuration file where it's reproducible.
>
> In my case, I've noticed that, when running wicd, it crashes faster when
> there are visible WPA networks, if no WPA networks can be seen it lasts a
> few minutes longer to crash, may even be able to connect to an unsecured
> acces point.

here also few WPA networks, but not able to reproduce.
>
>
> --
> Adri? Cereto Massagu?
> Biotechnology student
> Universitat Rovira i Virgili
>
> Languages: Catal?, Espa?ol, English, Fran?ais, Deutsch
>
> Nota importante | Important Notice
>
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Mon, Mar 14, 2011 at 2:58 PM, Peter Stuge <peter@stuge.se> wrote:
> Mohammed Shafi wrote:
>> not reproducible in 2.6.38-rc7-wl wireless testing under
>> Ubuntu, dont know where i am missing.
>
> You are in a different environment. Obviously it is not so useful to
> try to reproduce an issue in different circumstances. That will only
> work for very few and very simple errors.

Ok.

>
> I think it would be very useful to instead focus on how users who
> experience issues can gather significant information from hardware
> and from driver about their state, and report this back.

thanks for the suggestion.

>
> I find the obsession with trying to reproduce issues locally naive
> and counter-productive. :\
>
>
> //Peter
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrià Cereto Massagué]

2011/3/14 Mohammed Shafi <shafi.wireless@gmail.com>

> On Mon, Mar 14, 2011 at 11:51 AM, Mohammed Shafi
> <shafi.wireless@gmail.com> wrote:
> > 2011/3/10 Tony Houghton <h@realh.co.uk>:
> >> On Thu, 10 Mar 2011 12:02:21 +0100
> >> Adri? Cereto Massagu? <ssorgatem@gmail.com> wrote:
> >>
> >>> I can reproduce the same issue, since kernel 2.6.35  and a AR9285.
> >>>
> >>> I'm also using debian (sid).
> >>>
> >>> Seeing we both having this issue use debian, could it be something
> >>> debian-specific?
> >>
> >> I don't think so. I reproduced the problem with Ubuntu and I also tested
> >> kernels straight from git - but I did use make deb-pkg and a .config
> >> based on Debian's.
> >
> >         not reproducible in 2.6.38-rc7-wl wireless testing under
> > Ubuntu, dont know where i am missing.
> > I tried suspend-resume with/without disabling network manager. no
> > kernel lock ups.
> > also attaching my wireless tesing .config which may be of some help. any
> ideas?
>
> also lspci -vvvnn looks the card we are using  is same as yours?
>
> 05:00.0 Network controller [0280]: Atheros Communications Inc. AR9285
> Wireless Network Adapter (PCI-Express) [168c:002b] (rev 01)
>        Subsystem: Atheros Communications Inc. Device [168c:30a1]
>        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
>        Latency: 0, Cache Line Size: 64 bytes
>        Interrupt: pin A routed to IRQ 19
>        Region 0: Memory at f4800000 (64-bit, non-prefetchable) [size=64K]
>        Capabilities: <access denied>
>        Kernel driver in use: ath9k
>        Kernel modules: ath9k
>
>
> > thanks,
> > shafi
> >
> >
> >> _______________________________________________
> >> ath9k-devel mailing list
> >> ath9k-devel at lists.ath9k.org
> >> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> >>
> >
>

I attach my lspci (for me it looks like it's the same card) output and a
kernel configuration file where it's reproducible.

In my case, I've noticed that, when running wicd, it crashes faster when
there are visible WPA networks, if no WPA networks can be seen it lasts a
few minutes longer to crash, may even be able to connect to an unsecured
acces point.


-- 
*Adri? Cereto Massagu?*
Biotechnology student
Universitat Rovira i Virgili

Languages: Catal?, Espa?ol, English, Fran?ais, Deutsch

Nota importante
<http://www.gnu.org/philosophy/no-word-attachments.es.html>| Important
Notice <http://www.gnu.org/philosophy/no-word-attachments.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110314/b0de393e/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lspci.log
Type: text/x-log
Size: 23005 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110314/b0de393e/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config-2.6.37-3.slh.3-aptosid-amd64
Type: application/octet-stream
Size: 114228 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110314/b0de393e/attachment-0001.obj 

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Peter Stuge]

Mohammed Shafi wrote:
> not reproducible in 2.6.38-rc7-wl wireless testing under
> Ubuntu, dont know where i am missing.

You are in a different environment. Obviously it is not so useful to
try to reproduce an issue in different circumstances. That will only
work for very few and very simple errors.

I think it would be very useful to instead focus on how users who
experience issues can gather significant information from hardware
and from driver about their state, and report this back.

I find the obsession with trying to reproduce issues locally naive
and counter-productive. :\


//Peter

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

On Mon, Mar 14, 2011 at 11:51 AM, Mohammed Shafi
<shafi.wireless@gmail.com> wrote:
> 2011/3/10 Tony Houghton <h@realh.co.uk>:
>> On Thu, 10 Mar 2011 12:02:21 +0100
>> Adri? Cereto Massagu? <ssorgatem@gmail.com> wrote:
>>
>>> I can reproduce the same issue, since kernel 2.6.35 ?and a AR9285.
>>>
>>> I'm also using debian (sid).
>>>
>>> Seeing we both having this issue use debian, could it be something
>>> debian-specific?
>>
>> I don't think so. I reproduced the problem with Ubuntu and I also tested
>> kernels straight from git - but I did use make deb-pkg and a .config
>> based on Debian's.
>
> ? ? ? ? not reproducible in 2.6.38-rc7-wl wireless testing under
> Ubuntu, dont know where i am missing.
> I tried suspend-resume with/without disabling network manager. no
> kernel lock ups.
> also attaching my wireless tesing .config which may be of some help. any ideas?

also lspci -vvvnn looks the card we are using  is same as yours?

05:00.0 Network controller [0280]: Atheros Communications Inc. AR9285
Wireless Network Adapter (PCI-Express) [168c:002b] (rev 01)
        Subsystem: Atheros Communications Inc. Device [168c:30a1]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 19
        Region 0: Memory@f4800000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>
        Kernel driver in use: ath9k
        Kernel modules: ath9k


> thanks,
> shafi
>
>
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

2011/3/10 Tony Houghton <h@realh.co.uk>:
> On Thu, 10 Mar 2011 12:02:21 +0100
> Adri? Cereto Massagu? <ssorgatem@gmail.com> wrote:
>
>> I can reproduce the same issue, since kernel 2.6.35 ?and a AR9285.
>>
>> I'm also using debian (sid).
>>
>> Seeing we both having this issue use debian, could it be something
>> debian-specific?
>
> I don't think so. I reproduced the problem with Ubuntu and I also tested
> kernels straight from git - but I did use make deb-pkg and a .config
> based on Debian's.

         not reproducible in 2.6.38-rc7-wl wireless testing under
Ubuntu, dont know where i am missing.
I tried suspend-resume with/without disabling network manager. no
kernel lock ups.
also attaching my wireless tesing .config which may be of some help. any ideas?
thanks,
shafi


> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel-config
Type: application/octet-stream
Size: 135408 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110314/5bef7445/attachment-0001.obj 

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Christopher Jolley]

Tony Houghton <h <at> realh.co.uk> writes:

> 
> On Thu, 10 Mar 2011 12:02:21 +0100
> Adri? Cereto Massagu? <ssorgatem <at> gmail.com> wrote:
> 
> > I can reproduce the same issue, since kernel 2.6.35  and a AR9285.
> > 
> > I'm also using debian (sid).
> > 
> > Seeing we both having this issue use debian, could it be something
> > debian-specific?
> 
> I don't think so. I reproduced the problem with Ubuntu and I also tested
> kernels straight from git - but I did use make deb-pkg and a .config
> based on Debian's.
> 


I've experienced the AR9285 issues (nobody cared, IRQ dropping until reboot)
under Fedora 10-14, Slackware 10, and Debian distros.  The drivers have
previously improved across the board, dependent only on the driver or kernel
updates themselves, rather than on the distro. This problem reproduces itself on
a daily basis across multiple routers.

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Tony Houghton]

On Thu, 10 Mar 2011 12:02:21 +0100
Adri? Cereto Massagu? <ssorgatem@gmail.com> wrote:

> I can reproduce the same issue, since kernel 2.6.35  and a AR9285.
> 
> I'm also using debian (sid).
> 
> Seeing we both having this issue use debian, could it be something
> debian-specific?

I don't think so. I reproduced the problem with Ubuntu and I also tested
kernels straight from git - but I did use make deb-pkg and a .config
based on Debian's.

Re: [ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

2011/3/10 Adrià Cereto Massagué <ssorgatem@gmail.com>:
> Hi,
>
> I can reproduce the same issue, since kernel 2.6.35  and a AR9285.

We had got the card, will try to reproduce very soon.
thanks,
shafi

>
> I'm also using debian (sid).
>
> Seeing we both having this issue use debian, could it be something
> debian-specific?
>
> --
> Adrià Cereto Massagué
> Biotechnology student
> Universitat Rovira i Virgili
>
> Languages: Català, Español, English, Français, Deutsch
>
> Nota importante | Important Notice
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Mohammed Shafi]

2011/3/10 Adri? Cereto Massagu? <ssorgatem@gmail.com>:
> Hi,
>
> I can reproduce the same issue, since kernel 2.6.35? and a AR9285.

We had got the card, will try to reproduce very soon.
thanks,
shafi

>
> I'm also using debian (sid).
>
> Seeing we both having this issue use debian, could it be something
> debian-specific?
>
> --
> Adri? Cereto Massagu?
> Biotechnology student
> Universitat Rovira i Virgili
>
> Languages: Catal?, Espa?ol, English, Fran?ais, Deutsch
>
> Nota importante | Important Notice
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>

[ath9k-devel] ath9k causes lockups since kernel 2.6.35

[Adrià Cereto Massagué]

Hi,

I can reproduce the same issue, since kernel 2.6.35  and a AR9285.

I'm also using debian (sid).

Seeing we both having this issue use debian, could it be something
debian-specific?

-- 
*Adri? Cereto Massagu?*
Biotechnology student
Universitat Rovira i Virgili

Languages: Catal?, Espa?ol, English, Fran?ais, Deutsch

Nota importante
<http://www.gnu.org/philosophy/no-word-attachments.es.html>| Important
Notice <http://www.gnu.org/philosophy/no-word-attachments.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110310/240b5669/attachment.htm