Comment 19 for bug 1049383
Revision history for this message
| Sander Brandenburg (sander-brandenburg) wrote | #19 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
@Oleksij, it appears tougher to locate than I thought.
I'm back to kernel 3.11.0-15-generic. I tried to overheat by stressing the CPU, GPU and wireless device for 15 minutes by running stress --cpu 4, glxgears fullscreen (vsync on however) and setting txpower to 20 and pingflooding my gateway (sudo ping -f -s 1476 ). It did not succeed.
Only after 6-9 hours of moderately (ping -Di 0.2 -s 65507 192.168.1.1, you'll be the judge) pingflooding my gateway I got into this state where I could not ping my gateway anymore. Stopping the ping flood, waiting a while and trying a normal ping again did not appear to work. Only after suspending, waiting a while and resuming I can get the wifi adapter to function again. Resuming 1-2 seconds after suspending did not work for me. However, after this suspend-resume trick I can trigger the nonfunctional state quite easily after 10-15 minutes.
So I am a bit confused about whether this is related to overheating, if it takes such a long while to trigger. Can I enable some kind of debugging to show this behaviour?