This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 476253 - Resume from Suspend Crashes X on x86_64 Fedora 10 with Radeon 200M / b43 broadcom wireless card
Resume from Suspend Crashes X on x86_64 Fedora 10 with Radeon 200M / b43 broa...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
10
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-12 13:00 EST by Kevin Johnson
Modified: 2009-05-26 16:42 EDT (History)
2 users (show)

See Also:
Fixed In Version: as of 2009-02-11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-11 19:19:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg from resume-from-suspend hang (108.23 KB, text/plain)
2008-12-12 13:00 EST, Kevin Johnson
no flags Details
lspci output (1.80 KB, text/plain)
2008-12-12 13:01 EST, Kevin Johnson
no flags Details

  None (edit)
Description Kevin Johnson 2008-12-12 13:00:22 EST
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 13:01:07 EST
Created attachment 326749 [details]
lspci output

lspci output
Comment 2 Kevin Johnson 2009-02-11 10:57:03 EST
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-11 19:19:03 EST
Thanks for letting us know.
Comment 4 Bruno Maia 2009-05-26 16:42:33 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.