Am Mittwoch, den 04.07.2012, 09:55 -0400 schrieb Alex Deucher: > On Wed, Jul 4, 2012 at 9:41 AM, Paul Menzel wrote: > > Am Samstag, den 30.06.2012, 21:00 +0200 schrieb Paul Menzel: > >> Am Dienstag, den 26.06.2012, 07:42 +0200 schrieb Michel Dänzer: > >> > On Mon, 2012-06-25 at 21:14 +0200, Paul Menzel wrote: > >> > > > >> > > resuming from suspend to RAM the monitor was indicating by a blinking > >> > > LED that it did not receive any signal. This is the first time this > >> > > happened. Resuming from suspend to RAM had worked without problems > >> > > before (and probably will work again the next tries). > >> > > > >> > > Logging in from SSH worked fine though. Switching terminal to tty1 > >> > > nothing changed but going back to tty7, where X was supposed to run), > >> > > and the monitor detected a signal and showed the screensaver. > >> > > > >> > > Switching to tty1 still does not work though, that means the monitor > >> > > indicates that it gets no signal. > >> > > >> > What about tty2-6 or any others? > >> > >> It just happened again. tty2–6 also do not show anything. > >> > >> > What does fbset -i say when the problem occurs? > >> > >> I logged in over SSH not having switched the ttys yet. This is the > >> result. > >> > >> $ fbset -i > >> > >> mode "1280x1024" > >> geometry 1280 1024 1280 1024 32 > >> timings 0 0 0 0 0 0 0 > >> accel true > >> rgba 8/16,8/8,8/0,0/0 > >> endmode > >> > >> Frame buffer device information: > >> Name : radeondrmfb > >> Address : 0xd0142000 > >> Size : 5242880 > >> Type : PACKED PIXELS > >> Visual : TRUECOLOR > >> XPanStep : 1 > >> YPanStep : 1 > >> YWrapStep : 0 > >> LineLength : 5120 > >> Accelerator : No > >> > >> This does not differ though after having switched between ttys and > >> getting a working X server again. The other ttys do not just show black. > >> When switching from tty7 with the X server running to a console(?) tty > >> then I shortly (half second) see some kind of test image, which contains > >> four horizontal colored stripes red, green, blue and white(?). > >> > >> I could not find anything in the output of `dmesg`, but > >> `/var/log/syslog` contains several of the following lines. > >> > >> Jun 29 19:44:57 debian-host acpid: client 8677[0:0] has disconnected > >> Jun 29 19:45:08 debian-host acpid: client connected from 8677[0:0] > >> Jun 29 19:45:08 debian-host acpid: 1 client rule loaded > > > > Does someone have an idea what the problem might be and how to fix it? > > Is this a regression? If so can you bisect? I do not think so. But the problem is I just got that board, have only used it with Linux 3.2.x (from Debian Sid/unstable) and this issue is not reproducible, that means, it happens in less then 5(?) percent of the suspend and resume cycles. Any idea what these acpid messages could mean? Thanks, Paul
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
