Bug 207149 - System freeze after 10-15 minutes of heavy use with Atheros AR9271 wifi
Summary: System freeze after 10-15 minutes of heavy use with Atheros AR9271 wifi
Status: NEW
Alias: None
Product: Networking
Classification: Unclassified
Component: Wireless (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: networking_wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-07 13:55 UTC by Wilman Darnasutisna
Modified: 2020-06-18 06:01 UTC (History)
3 users (show)

See Also:
Kernel Version: 5.6.0-1-default
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg with latest kernel and latest freezing (83.17 KB, text/plain)
2020-04-07 13:55 UTC, Wilman Darnasutisna
Details

Description Wilman Darnasutisna 2020-04-07 13:55:04 UTC
Created attachment 288249 [details]
dmesg with latest kernel and latest freezing

My system often freezes when connected to a wifi hotspot. Usually around 10-15 minutes of computer usage. And especially when playing videos, music, and also when downloading fairly large files using XDM and torrenting via QBittorrent.
After my system is frozen. I can't restore my connection, when I unplug my wifi adapter, suddenly everything freezes. The music I'm playing is playing repeatedly/on loop. Until finally I had to force a reboot by pressing the reset button on my PC.
Comment 1 Wilman Darnasutisna 2020-04-08 16:28:26 UTC
hello
Comment 2 Wilman Darnasutisna 2020-04-09 03:14:27 UTC
ping
Comment 3 Jiri Slaby 2020-06-18 06:01:24 UTC
> kernel BUG at mm/slub.c:304!
> invalid opcode: 0000 [#1] SMP PTI
> CPU: 3 PID: 5055 Comm: kworker/u8:0 Not tainted 5.6.0-1-default #1 openSUSE
> Tumbleweed (unreleased)
> Hardware name: MSI MS-7978/B150A GAMING PRO (MS-7978), BIOS 1.G0 07/04/2018
> Workqueue: phy0 ath9k_led_work [ath9k_htc]
> RIP: 0010:kfree+0x22f/0x240
> Code: 5d 41 5c 41 5d e9 f1 75 fd ff 4d 89 e9 48 89 d9 48 89 da 48 89 ee 5b 4c
> 89 e7 5d 41 b8 01 00 00 00 41 5c 41 5d e9 91 f9 ff ff <0f> 0b 48 8b 05 58 e4
> 16 01 e9 01 fe ff ff 0f 1f 00 0f 1f 44 00 00
> RSP: 0018:ffffb6bb83293da0 EFLAGS: 00010246
> RAX: ffff9e532481ea00 RBX: ffff9e532481ea00 RCX: ffff9e532481ea00
> RDX: 000000000006cf7d RSI: 0000000000000246 RDI: ffff9e532481ea00
> RBP: fffff7a5c8920780 R08: ffff9e532481ea00 R09: 0000000000000000
> R10: 00000000000000cb R11: ffff9e5365dae064 R12: ffff9e5207c02e00
> R13: ffffffffb65da982 R14: ffff9e53641cfc18 R15: ffffb6bb83293e3c
> FS:  0000000000000000(0000) GS:ffff9e5365d80000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007feb98143000 CR3: 00000001c4a0a003 CR4: 00000000003606e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  kfree_skb+0x32/0xb0
>  ath9k_wmi_cmd+0x1a0/0x1c0 [ath9k_htc]
>  ath9k_reg_rmw+0x7d/0x180 [ath9k_htc]
>  process_one_work+0x1e8/0x3b0
>  worker_thread+0x4d/0x400
>  kthread+0xf9/0x130
>  ret_from_fork+0x3a/0x50

kfree_skb(cmd->skb) looks suspicious in hif_usb_regout_cb. As when hif_usb_send_regout fails, the urb callback frees the skb, but we free the skb in ath9k_wmi_cmd again.

Note You need to log in before you can comment on or make changes to this bug.