Bug 202962 - [iwn] ampdu tx panic
Summary: [iwn] ampdu tx panic
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-wireless (Nobody)
URL:
Keywords:
Depends on:
Blocks: 278175
  Show dependency treegraph
 
Reported: 2015-09-08 03:52 UTC by Henry Hu
Modified: 2024-04-04 21:13 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Henry Hu 2015-09-08 03:52:09 UTC
I've got panic twice, but I don't have a coredump. Both times the panics are related to iwn AMPDU TX code. I've got screenshots for the 2nd time, and I've attached them.
1st:
https://goo.gl/photos/DfBKcERDHTdnYpda6
2nd:
https://goo.gl/photos/FmuuH7viE2fATpsj8
https://goo.gl/photos/hFqNumEaapkpbHzr5
https://goo.gl/photos/3NHhUrbYH6ugkWM38

system:
FreeBSD pepsi 11.0-CURRENT FreeBSD 11.0-CURRENT #11 r287028M: Sat Aug 22 20:22:32 EDT 2015     root@pepsi:/usr/obj/usr/src/sys/MYKERNEL  amd64

For the first time, the crash happened in iwn_tx_data()+0x183, at line
4431	ring = &sc->txq[ac];
4432	if ((seqno % 256) != ring->cur) {

I don't have the register info that time, but I think that it's mostly the same cause as the 2nd time. Possibly 'ac' is invalid.

The second crash happened in iwn_ampdu_tx_stop()+0x60, at line
7419    if (sc->txq[qid].queued != 0)

Disassemble says:
0000000000004090 <iwn_ampdu_tx_stop>:
...
    40e6:       4c 63 38                movslq (%rax),%r15
    40e9:       49 69 c7 98 28 00 00    imul   $0x2898,%r15,%rax
    40f0:       41 83 bc 05 8c 2a 00    cmpl   $0x0,0x2a8c(%r13,%rax,1)
    40f7:       00 00 

and 0x2898 = sizeof(iwn_tx_ring). %r15 should be qid, and %r15 = 0x42535f5c which is clearly invalid(This happened to be all ASCII chars. Maybe reused?).

It seems like that someone overwrites tap->txa_private, and this caused both panics. Or it's possible that it's freed and reused.
Comment 1 Henry Hu 2015-09-11 03:41:06 UTC
On the other hand, from time to time the network card suffers from unable to send anything. From tcpdump, I can see that the router is sending arp requests and we are sending arp replies, but from tcpdump on the router I can't see arp replies.