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.