Bug 476253

Summary: Resume from Suspend Crashes X on x86_64 Fedora 10 with Radeon 200M / b43 broadcom wireless card
Product: [Fedora] Fedora Reporter: Kevin Johnson <kpj104>
Component: xorg-x11-drv-atiAssignee: Dave Airlie <airlied>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 10CC: brunix.java, mcepl, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: as of 2009-02-11 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-02-12 00:19:03 UTC Type: ---
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 Flags
Xorg from resume-from-suspend hang
none
lspci output none

Description Kevin Johnson 2008-12-12 18:00:22 UTC
Created attachment 326748 [details]
Xorg from resume-from-suspend hang

Description of problem:

After suspend-to-ram is kicked off, every time user attempts to resume the Xorg process crashes.  

Version-Release number of selected component (if applicable):


How reproducible:  100%


Steps to Reproduce:
1.  Suspend-to-Ram
2.  Wake computer
3.
  
Actual results:

Xorg process hangs.  It appears that evdev believes that the b43 broadcom 4318 wireless card is a keyboard and initializes it as such.  This is the last line in the log.  No function is available via real mouse / keyboard.

Expected results:

Xorg allows keyboard / mouse control and shows password input screen

Additional info:

I haven't figured out how to blacklist the bcm4318 card from evdev yet.. and I have not tried it with an Xorg.conf file either.  I have to use nomodeset or there are random lockups.  

kernel:  kernel-2.6.27.7-134.fc10.x86_64
xorg drv: xorg-x11-drv-ati-6.9.0-61.fc10.x86_64
broadcom firmware:  broadcom-wl-4.150.10.5

Comment 1 Kevin Johnson 2008-12-12 18:01:07 UTC
Created attachment 326749 [details]
lspci output

lspci output

Comment 2 Kevin Johnson 2009-02-11 15:57:03 UTC
OK -- resume from suspend works now with the latest packages in f10 repo --- I am not sure what changed, but I can suspend and wake it back up without a problem now...

Comment 3 Matěj Cepl 2009-02-12 00:19:03 UTC
Thanks for letting us know.

Comment 4 Bruno Maia 2009-05-26 20:42:33 UTC
Folks, 

I would like to let you know that I am also going through this bug on resuming from my fedora 10 on suspend.

All this theory about 

"It appears that evdev believes that the b43 broadcom 4318
wireless card is a keyboard and initializes it as such.  This is the last line
in the log.  No function is available via real mouse / keyboard." 

sounds nice, but I have a Sony Vaio VGN-4000 with a Core2Duo T93, 2.5GHz, 6MB L2 cache, 4GB RAM, came with some NVidia card,  7GB swap partition, and can't come back from suspend either. 

Actually, not even from hibernate. I even tried to add more swap creating a swap file (dd if=/dev/zero of=....) and summing up 12GB swap to go for a disk suspend, hibernate. no good.
  
Please, notice that same problem happened on my former ubuntu 8.04, but not on the 8.10. Maybe you guys could check to see what they did in order to fix it!

I hope This could help, because now that I am using my fedora 10 64bit I find it a lot more responsive than the Ubuntu 64bit and I don't want to ever go back.  
But the suspending is definitely necessary to make the notebook there for me
Imagine that situation  when that algorithm finally cooks and you want to quickly code it  before that insight goes away or the phone goes off in the middle of the boot delay...
By the way, on  boot, it  waits 10 seconds just because it can't find some "stabilization" during the beginning of the boot process! I wonder what it is. 

Thank you for the excellent work.