On Wed, Jul 4, 2012 at 10:11 AM, Paul Menzel <paulepanter@xxxxxxxxxxxxxxxxxxxxx> wrote: > 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? Nope sorry. Alex > > > Thanks, > > Paul _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
