Bug 29384 - Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
Summary: Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-03 08:04 UTC by Peter Weber
Modified: 2010-08-23 09:12 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
lspci of acer timelinex 3820tg (2.11 KB, patch)
2010-08-03 08:04 UTC, Peter Weber
no flags Details | Splinter Review
dmesg after bootup (62.92 KB, patch)
2010-08-03 08:05 UTC, Peter Weber
no flags Details | Splinter Review
dmesg after resuspend (2.11 KB, patch)
2010-08-03 08:05 UTC, Peter Weber
no flags Details | Splinter Review
complete run of dmesg after bootup, suspend and resuspend (46.74 KB, application/octet-stream)
2010-08-07 08:36 UTC, Peter Weber
no flags Details
.config of kernel 2.6.34 with first patch in directory radeon (65.33 KB, application/octet-stream)
2010-08-07 08:39 UTC, Peter Weber
no flags Details
dmesg of revision which includes the bug(s) (46.72 KB, patch)
2010-08-07 09:47 UTC, Peter Weber
no flags Details | Splinter Review
possible fix (1.20 KB, patch)
2010-08-16 07:10 UTC, Alex Deucher
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Weber 2010-08-03 08:04:55 UTC
Created attachment 37543 [details] [review]
lspci of acer timelinex 3820tg

Hello I made maybe a mistake and don't opened a new bug. But for additional information the old bug could be helpful, see here: https://bugs.freedesktop.org/show_bug.cgi?id=27744

Hardware: Radeon 5650
Kernel: 2.6.34
Status: everything is running fine

Hardware: Radeon 5650
Kernel: 2.6.35-rc6 and 2.6.35
Status: everything runs but with glitches

I have just use the TTY1-6 and switch between them everything is still okay with "2.6.35" but if the switch between TTY which are running applications with access to /dev/fb0 I got delays around 3 or 4 seconds when I switch away from TTY which is running fbida (framebuffer-image-viewer) or mplayer.
I case of mplayer this could lead to an uncontrolable system, only reaching the end of the movie gives here control back (help: MagicSysR, blind reboot or blind killing of mplayer).

Switching away from TTY7 with running X11 leads also to an delay around 3 or 4 seconds very similar to the delay which occurs while running fbida.
I think a connection between the "stuck atombios" problem and this problem could existed, but I am not sure. This could also a own dedicated problem, so I opened this bug.
Comment 1 Peter Weber 2010-08-03 08:05:32 UTC
Created attachment 37544 [details] [review]
dmesg after bootup
Comment 2 Peter Weber 2010-08-03 08:05:54 UTC
Created attachment 37545 [details] [review]
dmesg after resuspend
Comment 3 Peter Weber 2010-08-03 08:06:47 UTC
Of course I have the problem with delayed resuspend "atombios stuck", too.
Comment 4 Alex Deucher 2010-08-03 08:50:40 UTC
Did the patch in bug 27744 help?  If not, can you use git bisect between 2.6.34 and 2.6.35 and track down which commit causes the problem?
Comment 5 Peter Weber 2010-08-03 11:08:15 UTC
Thank you for your help.
But the answer is "No". I doesn't fix the slow resuspend (instead it feels slower, no wonder...) and also not the slow TTY-Switch between the terminals if /def/fb* is used. Both problems still exist.

To be honestly. Making a delay just longer doesn't look like a well solution.

Here is my dmesg output, maybe it helps (last lines):
PM: early resume of devices complete after 0.753 msecs
ehci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
ehci_hcd 0000:00:1a.0: setting latency timer to 64
HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
HDA Intel 0000:00:1b.0: setting latency timer to 64
ehci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
pci 0000:00:1e.0: setting latency timer to 64
ehci_hcd 0000:00:1d.0: setting latency timer to 64
HDA Intel 0000:00:1b.0: irq 45 for MSI/MSI-X
ahci 0000:00:1f.2: setting latency timer to 64
pci 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
radeon 0000:02:00.0: setting latency timer to 64
HDA Intel 0000:02:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
HDA Intel 0000:02:00.1: setting latency timer to 64
ath9k 0000:05:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
HDA Intel 0000:02:00.1: irq 46 for MSI/MSI-X
sd 0:0:0:0: [sda] Starting disk
[drm] Clocks initialized !
[drm] ring test succeeded in 1 usecs
[drm] ib test succeeded in 0 usecs
usb 2-1.5: reset high speed USB device using ehci_hcd and address 3
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: configured for UDMA/133
[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting
[drm:atom_execute_table_locked] *ERROR* atombios stuck executing CB5A (len 67, WS 0, PS 0) @ 0xCB89
PM: resume of devices complete after 7531.240 msecs
Restarting tasks ... done.
video LNXVIDEO:00: Restoring backlight state
	[ pm_notifier_block : 170 ] event :4

atl1c 0000:03:00.0: irq 47 for MSI/MSI-X
ADDRCONF(NETDEV_UP): eth0: link is not ready
ADDRCONF(NETDEV_UP): wlan0: link is not ready
EXT4-fs (sda1): re-mounted. Opts: commit=0
EXT4-fs (sda2): re-mounted. Opts: commit=0
ath9k: Two wiphys trying to scan at the same time
ath9k: Two wiphys trying to scan at the same time
wlan0: deauthenticating from 00:1c:10:36:48:42 by local choice (reason=3)
wlan0: authenticate with 00:1c:10:36:48:42 (try 1)
wlan0: authenticated
wlan0: associate with 00:1c:10:36:48:42 (try 1)
wlan0: RX AssocResp from 00:1c:10:36:48:42 (capab=0x431 status=0 aid=1)
wlan0: associated
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
wlan0: no IPv6 routers present
Comment 6 Peter Weber 2010-08-03 11:13:58 UTC
Just to notice:
Switch from X11 to TTY1-6 is also still affected.
Switch from TTY1-6 to X11 is, like before, normal - this means: immediately

Switching from a TTY without access to /dev/fb* to a TTY with access (running fbida or mplayer) is immediately. Switching from a TTY with access (running fbida or mplayer) is slow. Closing fbida with "q" is also slow.
Closing of mplayer with "strg+c" is not possible. mplayer is it totally freaking out.
Comment 7 Peter Weber 2010-08-03 11:16:04 UTC
Notice:
With the patch resuspend need ~7 seconds.
Withtout the patch resuspend needs ~ 3 seconds.

With old kernel 2.6.34 resuspend need ~ 1 second.
Comment 8 Alex Deucher 2010-08-03 11:30:16 UTC
Can you use git bisect between 2.6.34 and 2.6.35 and track down which commit causes the problem?
Comment 9 Peter Weber 2010-08-03 11:41:29 UTC
I am awfully sorry, but I am not familiar with git/git-bitsect.
Of course I will try every patch you can over and give you as much as possible details about the effect.
Comment 10 Alex Deucher 2010-08-03 11:56:42 UTC
(In reply to comment #9)
> I am awfully sorry, but I am not familiar with git/git-bitsect.
> Of course I will try every patch you can over and give you as much as possible
> details about the effect.

It's very easy. Assuming you have a git tree checked out:

git bisect start
git bisect good v2.6.34
git bisect bad v2.6.35

After that git will walk you through the rest.  It will check out the appropriate commit, at which point you can compile it, test it, and if it's good, run:
git bisect good
and if it's bad:
git bisect bad
and git will select the next commit and the process continues.  If there is a commit that doesn't boot or build, you can skip it with:
git bisect skip

See this page for more info:
http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
Comment 11 Peter Weber 2010-08-03 12:41:51 UTC
I will try this, but I will have first freetime at weekend.
Here another very interesting fact:

I've I boot up the machine, then -> pm-suspend ->resuspend "stuck atombios"
Result:
I have no problem with switching between the TTY1-6 and X11, also fbida and mplayer work like the should! But I *MUST* use pm-suspend at first to "Suspend to RAM" for a first time. After this first "Suspend to RAM" everything works perfect, only the "stuck atombios"-message delays the resuspend.

WTF?
Comment 12 Peter Weber 2010-08-07 08:32:03 UTC
Okay, let's go:
$ mkdir project; cd project/linux-2.6
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
$ git bisect start -- drivers/gpu/drm/radeon /*thought this must be a bug in "radeon"*/
$ git bisect good v.2.6.34
$ git bisect bad v2.6.35
Bisecting: 79 revisions left to test after this (roughly 6 steps)
[ce8a3eb20c4cb7d9e0c33e7560070688cd9066fc] drm/radeon/kms/pm: make pm spam debug only


This told me, that are 79 patches in "radeon" and gave me the first one. Because I am new with "git" I decided to start not in the middle (around patch 40), instead with the first patch (want to see how it works). The result is that both bugs 29384 and 27744 are inside!

See new dmesg after resuspend:

PM: early resume of devices complete after 0.837 msecs
ehci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
ehci_hcd 0000:00:1a.0: setting latency timer to 64
HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
HDA Intel 0000:00:1b.0: setting latency timer to 64
HDA Intel 0000:00:1b.0: irq 29 for MSI/MSI-X
ehci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
ehci_hcd 0000:00:1d.0: setting latency timer to 64
pci 0000:00:1e.0: setting latency timer to 64
ahci 0000:00:1f.2: setting latency timer to 64
pci 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
radeon 0000:02:00.0: setting latency timer to 64
HDA Intel 0000:02:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
HDA Intel 0000:02:00.1: setting latency timer to 64
ath9k 0000:05:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
HDA Intel 0000:02:00.1: irq 30 for MSI/MSI-X
sd 0:0:0:0: [sda] Starting disk
[drm] Clocks initialized !
[drm] ring test succeeded in 1 usecs
radeon 0000:02:00.0: no free indirect buffer !
[drm:r600_ib_test] *ERROR* radeon: failed to get ib (-16).
[drm:evergreen_resume] *ERROR* radeon: failled testing IB (-16).
usb 2-1.5: reset high speed USB device using ehci_hcd and address 4
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: configured for UDMA/133
PM: resume of devices complete after 2312.599 msecs
Restarting tasks ... done.
video LNXVIDEO:00: Restoring backlight state
	[ pm_notifier_block : 171 ] event :4

atl1c 0000:03:00.0: irq 31 for MSI/MSI-X
ADDRCONF(NETDEV_UP): eth0: link is not ready
ADDRCONF(NETDEV_UP): wlan0: link is not ready
ath9k: Two wiphys trying to scan at the same time
ath9k: Two wiphys trying to scan at the same time
wlan0: deauthenticating from 00:1c:10:36:48:42 by local choice (reason=3)
wlan0: authenticate with 00:1c:10:36:48:42 (try 1)
wlan0: authenticated
wlan0: associate with 00:1c:10:36:48:42 (try 1)
wlan0: RX AssocResp from 00:1c:10:36:48:42 (capab=0x431 status=0 aid=1)
wlan0: associated
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
wlan0: no IPv6 routers present




Error message differs, but there is the same bug!?
I added complete dmesg (bootup,suspend, resuspend).

I think the bug must somewhere else outside "drives/gpu/drm/radeon",  but where?
Comment 13 Peter Weber 2010-08-07 08:33:05 UTC
$ git bisect good v2.6.34 /*of course*/
Comment 14 Peter Weber 2010-08-07 08:36:24 UTC
Created attachment 37667 [details]
complete run of dmesg after bootup, suspend and resuspend
Comment 15 Peter Weber 2010-08-07 08:39:53 UTC
Created attachment 37668 [details]
.config of kernel 2.6.34 with first patch in directory radeon
Comment 16 Peter Weber 2010-08-07 08:53:35 UTC
Reading helps...
bisect looks for revisions, not for single patches.
But that doesn't change the above context.
Comment 17 Peter Weber 2010-08-07 09:43:58 UTC
$ mkdir project; cd project/linux-2.6
$ git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
$ git bisect start /*now I'am testing everythin*/
$ git bisect good v.2.6.34
$ git bisect bad v2.6.35
Bisecting: 5279 revisions left to test after this (roughly 12 steps)
[e0bc5d4a54938eedcde14005210e6c08aa9727e4] Merge branch 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging

->
Here it compiled the kernel, this kernel works fine!

Bisecting: 2639 revisions left to test after this (roughly 11 steps)
[d30fda355188272430d3865db2ff9e24b4135ae3] posix-cpu-timers: avoid "task->signal != NULL" checks

->
I've got it!
This revision has both bugs!
Added new dmesg_2639revisions_roughly11steps
Comment 18 Peter Weber 2010-08-07 09:47:16 UTC
Created attachment 37675 [details] [review]
dmesg of revision which includes the bug(s)
Comment 19 Alex Deucher 2010-08-07 10:23:09 UTC
Please take the bisection to the end.  if a commit is broken, mark it bad (git bisect bad) if it's working, mark it good (git bisect good), if you can't compile it or it won't boot, skip it (git bisect skip). at the end it should identify the exact commit which caused the problem.
Comment 20 Alex Deucher 2010-08-07 10:23:37 UTC
'git bisect reset' will reset your tree when you are finished bisecting.
Comment 21 Peter Weber 2010-08-08 05:53:36 UTC
Okay!


[peter@timeline linux-2.6]$ git bisect log
git bisect start '--' 'drivers/gpu/drm/radeon'
# good: [e40152ee1e1c7a63f4777791863215e3faa37a86] Linus 2.6.34
git bisect good e40152ee1e1c7a63f4777791863215e3faa37a86
# bad: [9fe6206f400646a2322096b56c59891d530e8d51] Linux 2.6.35
git bisect bad 9fe6206f400646a2322096b56c59891d530e8d51
# bad: [ce8a3eb20c4cb7d9e0c33e7560070688cd9066fc] drm/radeon/kms/pm: make pm spam debug only
git bisect bad ce8a3eb20c4cb7d9e0c33e7560070688cd9066fc
# good: [f405a1ab2bf316b1969fc5355891e5dff4e1a54c] drivers/gpu/drm: Use kmemdup
git bisect good f405a1ab2bf316b1969fc5355891e5dff4e1a54c
# good: [2aba631c008e7d82e3ec45dd32bec1ea63a963cf] radeon: Unify PM entry paths
git bisect good 2aba631c008e7d82e3ec45dd32bec1ea63a963cf
# good: [539d24181753e40174746d576d415bfb56131975] drm/radeon/kms: more pm fixes
git bisect good 539d24181753e40174746d576d415bfb56131975
# good: [91700f3cac56a1998a56d41e4459a5cebdb4f752] radeon: Split out ring locking and allocation
git bisect good 91700f3cac56a1998a56d41e4459a5cebdb4f752
# good: [ca2af92311eee95820f3b48c35045e5f56bc1477] drm/radeon/kms: fix lock ordering in ring, ib handling
git bisect good ca2af92311eee95820f3b48c35045e5f56bc1477
# bad: [ce8f53709bf440100cb9d31b1303291551cf517f] drm/radeon/kms/pm: rework power management
git bisect bad ce8f53709bf440100cb9d31b1303291551cf517f
# good: [d7311171c4cc8d6231427f7ac5056b939a184b80] drm/radeon/kms/pm: add support for no display power states
git bisect good d7311171c4cc8d6231427f7ac5056b939a184b80
# good: [d7311171c4cc8d6231427f7ac5056b939a184b80] drm/radeon/kms/pm: add support for no display power states
git bisect good d7311171c4cc8d6231427f7ac5056b939a184b80

[peter@timeline linux-2.6]$ git bisect good
ce8f53709bf440100cb9d31b1303291551cf517f is the first bad commit
commit ce8f53709bf440100cb9d31b1303291551cf517f
Author: Alex Deucher <alexdeucher@gmail.com>
Date:   Fri May 7 15:10:16 2010 -0400

    drm/radeon/kms/pm: rework power management
    
    - Separate dynpm and profile based power management methods.  You can select the pm method
      by echoing the selected method ("dynpm" or "profile") to power_method in sysfs.
    - Expose basic 4 profile in profile method
      "default" - default clocks
      "auto" - select between low and high based on ac/dc state
      "low" - DC, low power mode
      "high" - AC, performance mode
      The current base profile is "default", but it should switched to "auto" once we've tested
      on more systems.  Switching the state is a matter of echoing the requested profile to
      power_profile in sysfs.  The lowest power states are selected automatically when dpms turns
      the monitors off in all states but default.
    - Remove dynamic fence-based reclocking for the moment.  We can revisit this later once we
      have basic pm in.
    - Move pm init/fini to modesetting path.  pm is tightly coupled with display state.  Make sure
      display side is initialized before pm.
    - Add pm suspend/resume functions to make sure pm state is properly reinitialized on resume.
    - Remove dynpm module option.  It's now selectable via sysfs.
    
    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

:040000 040000 fa3acba12b9886453c2de619577ae633abfc97bc faf940f2c2791f1382ed1abbfa54e22df7e1c936 M	drivers


Here I got the problem with to slow switch between tty1-tty6 if /dev/fb* is in use by a program (example: fbida with an png image)
Is this what you need?





Just a note to the other bug 27744 "stuck atombios"
After:
Bisecting: 39 revisions left to test after this (roughly 5 steps)
[f405a1ab2bf316b1969fc5355891e5dff4e1a54c] drivers/gpu/drm: Use kmemdup
herebiosbug_butnotswitchbug (END) 
I got this dmesg output after resuspend:
PM: early resume of devices complete after 0.838 msecs
ehci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
ehci_hcd 0000:00:1a.0: setting latency timer to 64
HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
HDA Intel 0000:00:1b.0: setting latency timer to 64
HDA Intel 0000:00:1b.0: irq 29 for MSI/MSI-X
ehci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
ehci_hcd 0000:00:1d.0: setting latency timer to 64
pci 0000:00:1e.0: setting latency timer to 64
ahci 0000:00:1f.2: setting latency timer to 64
pci 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
radeon 0000:02:00.0: setting latency timer to 64
HDA Intel 0000:02:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
HDA Intel 0000:02:00.1: setting latency timer to 64
ath9k 0000:05:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
HDA Intel 0000:02:00.1: irq 30 for MSI/MSI-X
sd 0:0:0:0: [sda] Starting disk
[drm] Clocks initialized !
[drm] ring test succeeded in 1 usecs
radeon 0000:02:00.0: no free indirect buffer !
[drm:r600_ib_test] *ERROR* radeon: failed to get ib (-16).
[drm:evergreen_resume] *ERROR* radeon: failled testing IB (-16).
usb 2-1.5: reset high speed USB device using ehci_hcd and address 3
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: configured for UDMA/133
PM: resume of devices complete after 419.798 msecs
Restarting tasks ... done.
video LNXVIDEO:00: Restoring backlight state
        [ pm_notifier_block : 171 ] event :4

atl1c 0000:03:00.0: irq 31 for MSI/MSI-X
ADDRCONF(NETDEV_UP): eth0: link is not ready
ADDRCONF(NETDEV_UP): wlan0: link is not ready
ath9k: Two wiphys trying to scan at the same time

If I have more time I will try to found the reason for this, too. And post it in 27744.
Comment 22 Alex Deucher 2010-08-09 09:40:24 UTC
Does the patch I attached to bug 27744 help?
https://bugs.freedesktop.org/attachment.cgi?id=37733
Comment 23 Peter Weber 2010-08-09 11:12:30 UTC
I will try the patch tomorrow!
Comment 24 Peter Weber 2010-08-10 04:20:44 UTC
I'am sorry, the patch doesn't fix 29384 and 27744.
The system reacts like before, dmesg output is also exactly the same.


To new hints/quesitions:
With 2.6.34 I had no delay while loading the ATOMBIOS, if feels "smooth". I see some kernel-messages at bootup in standard vga-resolution and the kernel switches immidiatley to 1380x768 (my native display resolution).
Instead with 2.6.35 is see the bootup-message from kernel
"Linux agpgart interface v0.103
[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled." in resolution  640x480 standard vga,
than I got a blank screen with a delay and some seconds after this I see the next bootup-messages.

Is it correct the the Radeon-Driver in the kernel creat all this frequencq-scaling stuff under /sys with a Evergreen GPU. I tought this is only supported till R700 GPUs?
Of course this could be just some generic stuff.
Comment 25 Peter Weber 2010-08-10 04:22:23 UTC
I mean "immediatley"
Comment 26 Peter Weber 2010-08-16 02:18:12 UTC
In Comment 11 I describe a workaround, which seems to be based on Bug 27744.
Boot up -> pm-suspend -> resuspend -> switching works fine

This requires a plug off power-cord, my laptop must run only on battery at the time! I think this is no wonder, because the bug was introduced with that commit:
Date:   Fri May 7 15:10:16 2010 -0400
drm/radeon/kms/pm: rework power management

Now it gets funny:
If I replug the power-cord, the "slow-switching" appears again!
Comment 27 Peter Weber 2010-08-16 02:20:51 UTC
Okay. All the people with this bug and the stuck-atombios have radeon mobility-cards!
Comment 28 Peter Weber 2010-08-16 04:11:17 UTC
Solution found for bug 29384!
I noticed that everything looks like the kernel uses the new power-managment-stuff also for the Evergreen graphics cards. And this leads to the solution, the power_method "profile" doesn't work correct, the all problems with slow switching while using /dev/fb* with fbi or mplayer are solved with switching the power_method to "dynpm".

$ echo "dynpm" > /sys/class/drm/card0/device/power_method
check with 
$ cat /sys/class/drm/card0/device/power_method" //should report dynpm

Now everything works.
I can load a png-image with fbi on tty1, check dmesg output on tty2, while I am watching a ioQuake3-Demo (of course without hardware-accleration) on X11. If necessary I can use "pm-supend" and wakeup the system again, everything still works.

@Alex Deucher:
Could it be a final solution
a) generally set "dynpm" for all Evergreen chips
or
b) switching of power-managment for Evergreen till is really supported in the kernel


Now the bad news:
Using dynpm doesn't fix bug 27744
Further information:
http://www.x.org/wiki/radeonBuildHowTo#Troubleshootingradeonpower-management
Comment 29 Alex Deucher 2010-08-16 07:10:58 UTC
Created attachment 37899 [details] [review]
possible fix

Does the attached patch fix the issue?
Comment 30 Peter Weber 2010-08-16 08:06:52 UTC
Yes it does! Good work, thank you!
Tested with Kernel 2.6.26-rc1 + patch https://bugs.freedesktop.org/attachment.cgi?id=37899

Switching beetween all TTYs and X11 works fine, with use of /dev/fb* through fbida or mplayer. Suspend with pm-suspend and gnome-power-manager and Resuspend works also fine.

A fair question:
Did my "work" here helped?
A second one:
Will this patch included in 2.6.36-rc2?

Bye and thanks!

PS: Of course I got still the "atombios stuck" message in the output of dmesg, but it seems finally nothing to do with this bug.
Comment 31 Alex Deucher 2010-08-16 08:57:32 UTC
(In reply to comment #30)
> Yes it does! Good work, thank you!

good.

> A fair question:
> Did my "work" here helped?

Of course. Thanks for sticking with this.  I know bisecting can be a lot of work.

> A second one:
> Will this patch included in 2.6.36-rc2?

Yes, I've already sent the patch to Dave for 2.6.36 and stable.
Comment 32 Peter Weber 2010-08-23 05:22:51 UTC
Linus didn't included the patch in rc2.
Typicall delay?
Comment 33 Alex Deucher 2010-08-23 07:08:16 UTC
(In reply to comment #32)
> Linus didn't included the patch in rc2.
> Typicall delay?

The pull request just went out today, so it should show up as soon as Linus pulls it.
Comment 34 Peter Weber 2010-08-23 09:12:16 UTC
Great!
This bug has one good side, I learned much stuff.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.