Dear Linux folks,
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.
The motherboard is an ASRock A780FullHD [1] and the OS is Debian Sid/unstable.
I attach the output of `dmesg` and `/var/log/Xorg.0.log`.
Thanks,
Paul
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?
What does fbset -i say when the problem occurs?
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
Thanks,
Paul
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 : NoThis 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?
Thanks,
Paul
On Wed, Jul 4, 2012 at 9:41 AM, Paul Menzel paulepanter@users.sourceforge.net 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 : NoThis 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 loadedDoes someone have an idea what the problem might be and how to fix it?
Is this a regression? If so can you bisect?
Alex
Thanks,
Paul
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
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 : NoThis 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 loadedDoes 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
On Wed, Jul 4, 2012 at 10:11 AM, Paul Menzel paulepanter@users.sourceforge.net 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 : NoThis 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 loadedDoes 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
Am Donnerstag, den 05.07.2012, 08:58 -0400 schrieb Alex Deucher:
On Wed, Jul 4, 2012 at 10:11 AM, Paul Menzel 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 : NoThis 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 loadedDoes 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?
It just happened again. This time with the monitor not getting any signal. Switching to other virtual terminals does not work.
What debug levels should I increase?
Thanks,
Paul
Am Freitag, den 06.07.2012, 17:34 +0200 schrieb Paul Menzel:
Am Donnerstag, den 05.07.2012, 08:58 -0400 schrieb Alex Deucher:
On Wed, Jul 4, 2012 at 10:11 AM, Paul Menzel 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 : NoThis 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 loadedDoes 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?
It just happened again. This time with the monitor not getting any signal. Switching to other virtual terminals does not work.
What debug levels should I increase?
I attach the output of `dmesg`.
Thanks,
Paul
Am Freitag, den 06.07.2012, 17:39 +0200 schrieb Paul Menzel:
Am Freitag, den 06.07.2012, 17:34 +0200 schrieb Paul Menzel:
Am Donnerstag, den 05.07.2012, 08:58 -0400 schrieb Alex Deucher:
On Wed, Jul 4, 2012 at 10:11 AM, Paul Menzel 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?
It just happened again. This time with the monitor not getting any signal. Switching to other virtual terminals does not work.
What debug levels should I increase?
I attach the output of `dmesg`.
Yesterday it finally happened again. After resume the monitor stayed black. Only switching virtual consoles with Ctrl + Alt + F6 and back fixed this. This is the time for the resume.
[ 8688.180746] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:15:DVI-D-1] disconnected [ 9069.400626] PM: Syncing filesystems ... done.
Please find the output of `dmesg` and `drm.debug=0x06` attached.
Thanks,
Paul
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Michel Dänzer -
Paul Menzel