radeon: Unsuspend does not turn screen on (vbetool called, but never returns)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
vbetool (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: pm-utils
I am using Jaunty with ~tormodvolden's -radeon driver.
This does not occur with fglrx.
Switching to a tty with Ctrl-Alt-F1 and switching back to the X display turns the screen on. ps output shows the following, which suggests that "vbetool post" is incorrectly called. Is the "quirk" not needed on this card?
31590 ? S 0:00 /bin/sh /usr/lib/
31592 ? R 6:30 vbetool post
xserver-
Installed: 1:6.12.
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Mobility Radeon HD 3400 Series [1002:95c4]
Subsystem: Dell Device [1028:029f]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR+ <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at d0000000 (32-bit, prefetchable) [size=256M]
Region 1: I/O ports at 2000 [size=256]
Region 2: Memory at cfef0000 (32-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at cfe00000 [disabled] [size=128K]
Capabilities: <access denied>
Relevant lines from dmesg after resume:
[46786.933471] [drm] Resetting GPU
[46795.967413] Modules linked in: usblp aes_x86_64 aes_generic ecb binfmt_misc ppdev radeon drm bridge stp bnep vboxnetflt vboxdrv kqemu input_polldev dm_crypt sbp2 lp parport joydev btusb psmouse dcdbas iTCO_wdt iTCO_vendor_support serio_raw pcspkr ricoh_mmc sdhci_pci sdhci ieee80211_
[46816.902145] [drm] Loading RV620 CP Microcode
[46816.902478] [drm] Loading RV620 PFP Microcode
[46816.917417] [drm] Resetting GPU
Perhaps the delay between 46786 and 46816 (~30s) is due to my waiting for the screen to turn on, and the "Loading RV620 [CP|PFP] Microcode" occurs when I switch back to the X server?
Rightly or wrongly, I do not know, but I am re-assigning this for now to vbetool following the pursuant information:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31592 root 20 0 13524 952 808 R 100 0.0 441:53.31 vbetool
It's been using 100% CPU for a while now...