Bug 751299

Summary: [Regression] laptop locks up
Product: [Fedora] Fedora Reporter: Jan Willies <jan>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 16CC: gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-18 11:14:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Picture of backtrace
none
Picture of backtrace #2
none
Picture of backtrace #3
none
dmesg output
none
Picture of backtrace #4
none
Picture of backtrace #5 (with debug kernel) none

Description Jan Willies 2011-11-04 09:15:21 UTC
Created attachment 531726 [details]
Picture of backtrace

Description of problem: After a few seconds (or minutes) of uptime, X is beeing stopped and instead a backtrace is shown. This happens sooner (right at the end of booting) for debug-kernels and a little later for normal kernels. 

The machine isn't reachable via ssh and doesn't respond to keypresses. Nothing is saved in /var/log/messages


Version-Release number of selected component (if applicable): kernel-3.1.0-7.fc16


How reproducible: always


Steps to Reproduce:
1. boot kernel
2. wait
3.
  
Actual results: X is stopped and a backtrace is shown on the console


Expected results: working laptop


Additional info: it was working fine with F14, and still is if I boot kernel-PAE-2.6.35.14-100.fc14.i686. I have attached dmesg output and a few pictures of the backtraces

Neither 3.2.0-0.rc0.git4.1.fc17 nor kernel-3.0.1-3.fc16 solve the issue. Going back to 2.6.39-1.fc16.i686.PAE works (as do earlier kernels).

Comment 1 Jan Willies 2011-11-04 09:16:13 UTC
Created attachment 531727 [details]
Picture of backtrace #2

Comment 2 Jan Willies 2011-11-04 09:16:58 UTC
Created attachment 531728 [details]
Picture of backtrace #3

Comment 3 Jan Willies 2011-11-04 09:17:28 UTC
Created attachment 531729 [details]
dmesg output

Comment 4 Josh Boyer 2011-11-04 16:37:26 UTC
All of those traces seem to be subsequent fallout from something else (note the D taint flag).

Can you boot with pause_on_oops=60 (or some other suitable value) to see if you can capture the very first oops?

Also, you might want to run memtest on this machine for a while.

Comment 5 Jan Willies 2011-11-05 07:46:01 UTC
Created attachment 531879 [details]
Picture of backtrace #4

Comment 6 Jan Willies 2011-11-05 07:53:43 UTC
uploaded a hopefully better picture with pause_on_oops=60

It is definately related to the wireless card (rt2500pci). The laptop runs fine with deactived wifi, but as soon as I activate it with the hardware-button it takes 60 seconds to connect to the AP and another 45 until the bug appears.

Comment 7 Jan Willies 2011-11-05 08:19:29 UTC
Created attachment 531882 [details]
Picture of backtrace #5 (with debug kernel)

Comment 8 Jan Willies 2011-12-18 11:14:36 UTC
seems to be fixed with 3.1.5