Bug 835213
| Summary: | kernel panic in ath9k driver [Acer Aspire One D722] | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Pascal Dupuis <cdemills> | ||||||||||
| Component: | kernel | Assignee: | John W. Linville <linville> | ||||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
| Severity: | high | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 17 | CC: | gansalmon, itamar, jonathan, kernel-maint, levko.lb, madhu.chinakonda | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | x86_64 | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2012-06-29 14:40:20 UTC | Type: | Bug | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Pascal Dupuis
2012-06-25 19:31:39 UTC
Created attachment 594598 [details]
another picutre
Created attachment 594599 [details]
same occurence
The message I've seen today is: kernel bug at drivers/net/wireless/ath/ath9k/recv.c: 671 invalid opcode: 000 [#1] SMP Created attachment 594865 [details]
page fault in ath_rx_tasklet
The hang of the day: the system worked flawlessly for around two hours, then I got a page fault. The kernel trace can be seen in attachment https://bugzilla.redhat.com/attachment.cgi?id=594865 Interesting point: ath_rx_tasklet +0x165/0x1b00 followed by page_fault A new though: I'm using the laptop in a residential area in France. Doing "iwlist scan" reveals there are between 45 and 65 cells. Most of them comes from "boxes", i.e. Internet access point through telephone cable or optical fibers; yet the link with the user computer/laptop/smartphone is through Wifi. TV channels are also availables through those boxes; you can imagine the bandwith. Is there some issue with the number of beacons or link quality which is not handled properly ? patch for fix this: http://article.gmane.org/gmane.linux.kernel.wireless.general/93723/match=commit+3a2923e83c Pascal, none of the picture you are posting are useful. Please pan out enough to actually see the entire screen. Alex, on what basis do you believe that fix to apply to this problem? In any case...test kernels w/ the above mentioned patch are building here: http://koji.fedoraproject.org/koji/taskinfo?taskID=4206016 When they finish building, please give them a try and post the results here...thanks! uname -r 3.4.4-3.bz832927.1.fc17.x86_64 Testing the assembly. Copy a large file via scp. So far so good. Do not panic. screenshot: http://storage6.static.itmages.ru/i/12/0628/h_1340910789_9343523_b77e49aa36.png It works fine! More kernel does not panic. Installed the new kernel from koji. Removed all the work around, rebooted and ... not a single problem since two hours. Yet I played music from youtube, stress-tested the machine by processing a 10 Gig compressed archive, and so on. Not a single trouble. Congrat for killing this bug. Wait a minut. The behaviour I observed with the previous kernel was a leakage. If you look a bit around recv.c, line 685, in the lastest kernel:
685 if (ret == -EINVAL) {
686 /* corrupt descriptor, skip this one and the following one */
687 list_add_tail(&bf->list, &sc->rx.rxbuf);
688 ath_rx_edma_buf_link(sc, qtype);
689
690 skb = skb_peek(&rx_edma->rx_fifo);
691 if (skb) {
692 bf = SKB_CB_ATHBUF(skb);
693 BUG_ON(!bf);
694
695 __skb_unlink(skb, &rx_edma->rx_fifo);
696 list_add_tail(&bf->list, &sc->rx.rxbuf);
697 ath_rx_edma_buf_link(sc, qtype);
698 } else {
699 bf = NULL;
700 }
701 }
The idea is to remove the "else {" and the next "}". According to the code,two descriptors are skipped. Is there dynamic memory allocated through those decriptors? Is this memory freed before setting bf to NULL ?
Regards
Pascal
*** This bug has been marked as a duplicate of bug 832927 *** |
