Re: System alive but can't access from the monitor

2017-04-06 Thread Paolo Galtieri
The problem is nouveau related.  The system on which the problem does 
not show up doesn't use the nouveau driver.


00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell-ULT 
Integrated Graphics Controller [8086:0a16] (rev 09)

Subsystem: Dell Device [1028:05f9]
Kernel driver in use: i915
Kernel modules: i915

Paolo

On 04/03/2017 11:25 PM, Samuel Sieb wrote:

On 04/01/2017 11:36 AM, Robin Laing wrote:

On 31/03/17 23:28, Paolo Galtieri wrote:
I have 2 F25 systems, the problem I'm seeing with the monitor not 
coming

back from sleep only happens on one of them.  I did a grep for nouveau
on the 2 systems in /var/log/messages.  There are no messages including
nouveau on the system that does not exhibit the problem. This system 
has

an Intel graphics controller. On this system lspci shows

 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT
Integrated Graphics Controller (rev 09)


On the one that exhibits the problem I see the following:

Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: NVIDIA G86
(086100a2)



Goes to show that it isn't nouveau related.  Now that it shows two
different types of video cards, it points to something common

I think you misunderstood the message.  It is a little confusing, but 
my understanding of that is that the system that doesn't have the 
problem has Intel graphics and the one that does have the problem is 
NVidia.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org


Re: System alive but can't access from the monitor

2017-04-04 Thread Samuel Sieb

On 04/01/2017 11:36 AM, Robin Laing wrote:

On 31/03/17 23:28, Paolo Galtieri wrote:

I have 2 F25 systems, the problem I'm seeing with the monitor not coming
back from sleep only happens on one of them.  I did a grep for nouveau
on the 2 systems in /var/log/messages.  There are no messages including
nouveau on the system that does not exhibit the problem. This system has
an Intel graphics controller. On this system lspci shows

 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT
Integrated Graphics Controller (rev 09)


On the one that exhibits the problem I see the following:

Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: NVIDIA G86
(086100a2)



Goes to show that it isn't nouveau related.  Now that it shows two
different types of video cards, it points to something common

I think you misunderstood the message.  It is a little confusing, but my 
understanding of that is that the system that doesn't have the problem 
has Intel graphics and the one that does have the problem is NVidia.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org


Re: System alive but can't access from the monitor

2017-04-04 Thread Ed Greshko
On 04/04/17 03:54, Tim Jackson wrote:
> To add to this thread, I have the exact same problem using
> fully-updated (as of today, including libdrm-2.4.76-1) F25, GNOME and
> X11 session. To be a bit more specific: for me, when the problem
> occurs (after the screen locks and the monitors power down), I *can*
> "wake up" the screen, *and* I get a (moveable) mouse cursor, but
> behind the cursor is just a static copy of whatever happened to be on
> the screen prior to it going to sleep. In most cases, black
> (presumably because GNOME blanked the screen prior to lock). Or, if I
> happened to be on the login screen when the monitors went to sleep,
> possibly a static copy of the login screen.

Then your issue is different than mine.  And, possibly others.

In my case, while xrandr shows both monitors to be "connected" as normal
one of the monitors blank and obviously not receiving any signal since
it will not stay connected to DP-1 but switches to the HDMI connector
which has a Chromecast connected to it.


>
> As outlined by previous posters, I can't find any way out of this
> other than hard rebooting, which is a pretty nasty solution if I had
> unsaved stuff.
>
> On one occasion, the machine apparently fully crashed (not even
> pingable), but I can't reproduce that.
>
> The following kernels are affected:
>
> kernel-4.10.5-200.fc25.x86_64
> kernel-4.10.6-200.fc25.x86_64
>
> If I roll back to kernel-4.9.14-200.fc25.x86_64 the problem goes away.
>
> lspci -k -nn says:
>
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119
> [GeForce GT 610] [10de:104a] (rev a1)
> Subsystem: ASUSTeK Computer Inc. Device [1043:840d]
> Kernel driver in use: nouveau
> Kernel modules: nouveau
>
> I have two screens connected via DVI and HDMI respectively.
>
> To answer Ed Greshko's debugging questions:
>
>>> 1.  Are you using the nouveau driver or the nVidia driver for your
>>> card?
>
> nouveau. In fact this is a pretty fresh install of Fedora all round,
> without much extra.
>
>>> 2.  Are you running GNOME under Wayland or X11?
>
> X11.
>
>>> If you are using X11, and since you can ssh into  the system, what is
>>> the output if you do...
>>> ssh systemB
>>> export DISPLAY=:0
>>> xrandr
>
> The following (which is exactly the same as under a normal working
> session):
>
> Screen 0: minimum 320 x 200, current 2560 x 1024, maximum 16384 x 16384
> DVI-I-1 connected 1280x1024+1280+0 (normal left inverted right x axis
> y axis) 338mm x 270mm
>1280x1024 60.02 +  75.02*
>1152x864  75.00
>1024x768  75.0360.00
>800x600   75.0060.32
>640x480   75.0059.94
>720x400   70.08
> HDMI-1 connected primary 1280x1024+0+0 (normal left inverted right x
> axis y axis) 338mm x 270mm
>1280x1024 60.02 +  75.02*
>1152x864  75.00
>1024x768  75.0360.00
>800x600   75.0060.32
>640x480   75.0059.94
>720x400   70.08
>
>>> Using my system as an example, does doing something like this bring the
>>> monitor back?
> >> [snip xrandr blah --off, xrandr blah --auto]
>
> Note that from my description, the monitors are already on and awake,
> so they don't really need to be "brought back". But sure, turning them
> off and on with xrandr turns them off and on again. It doesn't change
> the underlying problem.

Right.  So, different issues.

I don't know if there is a BZ for the issue you're describing.  However,
it seems what I'm seeing has been around for quite some time.
https://bugzilla.redhat.com/show_bug.cgi?id=1179924  and others. 


-- 
Fedora Users List - The place to go to get others to do the work for you
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org


Re: System alive but can't access from the monitor

2017-04-03 Thread Robin Laing

On 03/04/17 13:54, Tim Jackson wrote:

To add to this thread, I have the exact same problem using fully-updated
(as of today, including libdrm-2.4.76-1) F25, GNOME and X11 session. To
be a bit more specific: for me, when the problem occurs (after the
screen locks and the monitors power down), I *can* "wake up" the screen,
*and* I get a (moveable) mouse cursor, but behind the cursor is just a
static copy of whatever happened to be on the screen prior to it going
to sleep. In most cases, black (presumably because GNOME blanked the
screen prior to lock). Or, if I happened to be on the login screen when
the monitors went to sleep, possibly a static copy of the login screen.

As outlined by previous posters, I can't find any way out of this other
than hard rebooting, which is a pretty nasty solution if I had unsaved
stuff.

On one occasion, the machine apparently fully crashed (not even
pingable), but I can't reproduce that.

The following kernels are affected:

kernel-4.10.5-200.fc25.x86_64
kernel-4.10.6-200.fc25.x86_64

If I roll back to kernel-4.9.14-200.fc25.x86_64 the problem goes away.

lspci -k -nn says:

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119
[GeForce GT 610] [10de:104a] (rev a1)
Subsystem: ASUSTeK Computer Inc. Device [1043:840d]
Kernel driver in use: nouveau
Kernel modules: nouveau

I have two screens connected via DVI and HDMI respectively.

To answer Ed Greshko's debugging questions:


1.  Are you using the nouveau driver or the nVidia driver for your card?


nouveau. In fact this is a pretty fresh install of Fedora all round,
without much extra.


2.  Are you running GNOME under Wayland or X11?


X11.


If you are using X11, and since you can ssh into  the system, what is
the output if you do...
ssh systemB
export DISPLAY=:0
xrandr


The following (which is exactly the same as under a normal working
session):

Screen 0: minimum 320 x 200, current 2560 x 1024, maximum 16384 x 16384
DVI-I-1 connected 1280x1024+1280+0 (normal left inverted right x axis y
axis) 338mm x 270mm
   1280x1024 60.02 +  75.02*
   1152x864  75.00
   1024x768  75.0360.00
   800x600   75.0060.32
   640x480   75.0059.94
   720x400   70.08
HDMI-1 connected primary 1280x1024+0+0 (normal left inverted right x
axis y axis) 338mm x 270mm
   1280x1024 60.02 +  75.02*
   1152x864  75.00
   1024x768  75.0360.00
   800x600   75.0060.32
   640x480   75.0059.94
   720x400   70.08


Using my system as an example, does doing something like this bring the
monitor back?
[snip xrandr blah --off, xrandr blah --auto]


Note that from my description, the monitors are already on and awake, so
they don't really need to be "brought back". But sure, turning them off
and on with xrandr turns them off and on again. It doesn't change the
underlying problem.

Is there any known BZ about this?

Tim
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org



Looks like bugzill 1435000 is the one we are looking at.

https://bugzilla.redhat.com/show_bug.cgi?id=1435000

Robin
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org


Re: System alive but can't access from the monitor

2017-04-03 Thread Tim Jackson
To add to this thread, I have the exact same problem using fully-updated (as 
of today, including libdrm-2.4.76-1) F25, GNOME and X11 session. To be a bit 
more specific: for me, when the problem occurs (after the screen locks and the 
monitors power down), I *can* "wake up" the screen, *and* I get a (moveable) 
mouse cursor, but behind the cursor is just a static copy of whatever happened 
to be on the screen prior to it going to sleep. In most cases, black 
(presumably because GNOME blanked the screen prior to lock). Or, if I happened 
to be on the login screen when the monitors went to sleep, possibly a static 
copy of the login screen.


As outlined by previous posters, I can't find any way out of this other than 
hard rebooting, which is a pretty nasty solution if I had unsaved stuff.


On one occasion, the machine apparently fully crashed (not even pingable), but 
I can't reproduce that.


The following kernels are affected:

kernel-4.10.5-200.fc25.x86_64
kernel-4.10.6-200.fc25.x86_64

If I roll back to kernel-4.9.14-200.fc25.x86_64 the problem goes away.

lspci -k -nn says:

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119 [GeForce GT 
610] [10de:104a] (rev a1)

Subsystem: ASUSTeK Computer Inc. Device [1043:840d]
Kernel driver in use: nouveau
Kernel modules: nouveau

I have two screens connected via DVI and HDMI respectively.

To answer Ed Greshko's debugging questions:


1.  Are you using the nouveau driver or the nVidia driver for your card?


nouveau. In fact this is a pretty fresh install of Fedora all round, without 
much extra.



2.  Are you running GNOME under Wayland or X11?


X11.


If you are using X11, and since you can ssh into  the system, what is
the output if you do...
ssh systemB
export DISPLAY=:0
xrandr


The following (which is exactly the same as under a normal working session):

Screen 0: minimum 320 x 200, current 2560 x 1024, maximum 16384 x 16384
DVI-I-1 connected 1280x1024+1280+0 (normal left inverted right x axis y axis) 
338mm x 270mm

   1280x1024 60.02 +  75.02*
   1152x864  75.00
   1024x768  75.0360.00
   800x600   75.0060.32
   640x480   75.0059.94
   720x400   70.08
HDMI-1 connected primary 1280x1024+0+0 (normal left inverted right x axis y 
axis) 338mm x 270mm

   1280x1024 60.02 +  75.02*
   1152x864  75.00
   1024x768  75.0360.00
   800x600   75.0060.32
   640x480   75.0059.94
   720x400   70.08


Using my system as an example, does doing something like this bring the
monitor back?

>> [snip xrandr blah --off, xrandr blah --auto]

Note that from my description, the monitors are already on and awake, so they 
don't really need to be "brought back". But sure, turning them off and on with 
xrandr turns them off and on again. It doesn't change the underlying problem.


Is there any known BZ about this?

Tim
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org


Re: System alive but can't access from the monitor

2017-04-01 Thread Robin Laing

On 31/03/17 23:28, Paolo Galtieri wrote:

I have 2 F25 systems, the problem I'm seeing with the monitor not coming
back from sleep only happens on one of them.  I did a grep for nouveau
on the 2 systems in /var/log/messages.  There are no messages including
nouveau on the system that does not exhibit the problem. This system has
an Intel graphics controller. On this system lspci shows

 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT
Integrated Graphics Controller (rev 09)


On the one that exhibits the problem I see the following:

Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: NVIDIA G86
(086100a2)
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: bios: version
60.86.37.00.51
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: bios: M0203T not
found
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: bios: M0203E not
matched!
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: fb: 512 MiB DDR2
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: VRAM: 512 MiB
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: GART:
1048576 MiB
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: TMDS table
version 2.0
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB version
4.0
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB outp
00: 02000300 0028
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB outp
01: 01000302 0030
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB outp
02: 04011310 0028
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB outp
03: 010223f1 00c0c080
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB conn
00: 1030
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB conn
01: 0100
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB conn
02: 0210
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB conn
03: 0211
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB conn
04: 0213
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: failed to
create encoder 0/1/0: -19
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: TV-1 has no
encoders, removing
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: MM: using
CRYPT for buffer copies
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: allocated
1920x1080 fb: 0x7, bo 9b51add56800
Mar 31 15:29:31 jackstraw kernel: fbcon: nouveaufb (fb0) is primary device
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: fb0: nouveaufb
frame buffer device
Mar 31 15:29:31 jackstraw kernel: [drm] Initialized nouveau 1.3.1
20120801 for :01:00.0 on minor 0

On this system lspci shows:

01:00.0 VGA compatible controller: NVIDIA Corporation G86 [GeForce 8500
GT] (rev a1)

This problem occurs on both 4.10.5 AN 4.10.6

Paolo

On 03/31/2017 04:08 PM, Robin Laing wrote:

On 30/03/17 01:35, Ed Greshko wrote:

On 03/30/17 14:24, Paolo Galtieri wrote:

Folks,
  I have 2 F25 systems that have been updated today.  These 2 systems
share a monitor.  One system is attached via a kvm switch to the
monitor, the other system is attached via hdmi.  This morning and
twice this evening a problem has started to manifest itself. This
configuration has been working fine for several years.  I will call
the systems A and B, system A is attached to the monitor via hdmi,
system B via VGA.  If I switch to system A for a while and then try to
switch back to system B the monitor instead of staying on VGA cycles
from VGA to DVI to HDMI and returns to system A.  I can ssh into
system B and everything looks fine, i.e. things that were running
under my user id are still running, e.g. chrome and firefox. I looked
at /var/log/messages and I see this:

Mar 29 23:00:02 jackstraw systemd: Stopping User Manager for UID 0...
Mar 29 23:00:02 jackstraw systemd: Stopped target Default.
Mar 29 23:00:02 jackstraw systemd: Stopped target Basic System.
Mar 29 23:00:02 jackstraw systemd: Stopped target Sockets.
Mar 29 23:00:02 jackstraw systemd: Closed D-Bus User Message Bus
Socket.
Mar 29 23:00:02 jackstraw systemd: Stopped target Timers.
Mar 29 23:00:02 jackstraw systemd: Stopped target Paths.
Mar 29 23:00:02 jackstraw systemd: Reached target Shutdown.
Mar 29 23:00:02 jackstraw systemd: Starting Exit the Session...
Mar 29 23:00:02 jackstraw systemd: Received SIGRTMIN+24 from PID 17588
(kill).

This was at the time I switched from system A to system B. Each of
the other times I saw this problem I see the same set of messages in
the log file.  Can someone explain what they mean and could they be
the cause of the problem?

I see the same messages on the other system, but there they were part
of other messages related to rebooting the system.

The only way I can recover is reboot the system.

Here's my video card info:

01:00.0 VGA compatible controller: NVIDIA Corporation G86 [GeForce
8500 GT] (rev a1)

Any assistance is appreciated.


Since everything is 

Re: System alive but can't access from the monitor

2017-03-31 Thread Paolo Galtieri
I have 2 F25 systems, the problem I'm seeing with the monitor not coming 
back from sleep only happens on one of them.  I did a grep for nouveau 
on the 2 systems in /var/log/messages.  There are no messages including 
nouveau on the system that does not exhibit the problem. This system has 
an Intel graphics controller. On this system lspci shows


 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT 
Integrated Graphics Controller (rev 09)



On the one that exhibits the problem I see the following:

Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: NVIDIA G86 
(086100a2)
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: bios: version 
60.86.37.00.51
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: bios: M0203T not 
found
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: bios: M0203E not 
matched!

Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: fb: 512 MiB DDR2
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: VRAM: 512 MiB
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: GART: 
1048576 MiB
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: TMDS table 
version 2.0

Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB version 4.0
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB outp 
00: 02000300 0028
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB outp 
01: 01000302 0030
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB outp 
02: 04011310 0028
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB outp 
03: 010223f1 00c0c080
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB conn 
00: 1030
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB conn 
01: 0100
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB conn 
02: 0210
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB conn 
03: 0211
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: DCB conn 
04: 0213
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: failed to 
create encoder 0/1/0: -19
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: TV-1 has no 
encoders, removing
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: MM: using 
CRYPT for buffer copies
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: DRM: allocated 
1920x1080 fb: 0x7, bo 9b51add56800

Mar 31 15:29:31 jackstraw kernel: fbcon: nouveaufb (fb0) is primary device
Mar 31 15:29:31 jackstraw kernel: nouveau :01:00.0: fb0: nouveaufb 
frame buffer device
Mar 31 15:29:31 jackstraw kernel: [drm] Initialized nouveau 1.3.1 
20120801 for :01:00.0 on minor 0


On this system lspci shows:

01:00.0 VGA compatible controller: NVIDIA Corporation G86 [GeForce 8500 
GT] (rev a1)


This problem occurs on both 4.10.5 AN 4.10.6

Paolo

On 03/31/2017 04:08 PM, Robin Laing wrote:

On 30/03/17 01:35, Ed Greshko wrote:

On 03/30/17 14:24, Paolo Galtieri wrote:

Folks,
  I have 2 F25 systems that have been updated today.  These 2 systems
share a monitor.  One system is attached via a kvm switch to the
monitor, the other system is attached via hdmi.  This morning and
twice this evening a problem has started to manifest itself. This
configuration has been working fine for several years.  I will call
the systems A and B, system A is attached to the monitor via hdmi,
system B via VGA.  If I switch to system A for a while and then try to
switch back to system B the monitor instead of staying on VGA cycles
from VGA to DVI to HDMI and returns to system A.  I can ssh into
system B and everything looks fine, i.e. things that were running
under my user id are still running, e.g. chrome and firefox. I looked
at /var/log/messages and I see this:

Mar 29 23:00:02 jackstraw systemd: Stopping User Manager for UID 0...
Mar 29 23:00:02 jackstraw systemd: Stopped target Default.
Mar 29 23:00:02 jackstraw systemd: Stopped target Basic System.
Mar 29 23:00:02 jackstraw systemd: Stopped target Sockets.
Mar 29 23:00:02 jackstraw systemd: Closed D-Bus User Message Bus 
Socket.

Mar 29 23:00:02 jackstraw systemd: Stopped target Timers.
Mar 29 23:00:02 jackstraw systemd: Stopped target Paths.
Mar 29 23:00:02 jackstraw systemd: Reached target Shutdown.
Mar 29 23:00:02 jackstraw systemd: Starting Exit the Session...
Mar 29 23:00:02 jackstraw systemd: Received SIGRTMIN+24 from PID 17588
(kill).

This was at the time I switched from system A to system B. Each of
the other times I saw this problem I see the same set of messages in
the log file.  Can someone explain what they mean and could they be
the cause of the problem?

I see the same messages on the other system, but there they were part
of other messages related to rebooting the system.

The only way I can recover is reboot the system.

Here's my video card info:

01:00.0 VGA compatible controller: NVIDIA Corporation G86 [GeForce
8500 GT] (rev a1)

Any assistance is appreciated.


Since everything is still 

Re: System alive but can't access from the monitor

2017-03-31 Thread Robin Laing

On 30/03/17 01:35, Ed Greshko wrote:

On 03/30/17 14:24, Paolo Galtieri wrote:

Folks,
  I have 2 F25 systems that have been updated today.  These 2 systems
share a monitor.  One system is attached via a kvm switch to the
monitor, the other system is attached via hdmi.  This morning and
twice this evening a problem has started to manifest itself.  This
configuration has been working fine for several years.  I will call
the systems A and B, system A is attached to the monitor via hdmi,
system B via VGA.  If I switch to system A for a while and then try to
switch back to system B the monitor instead of staying on VGA cycles
from VGA to DVI to HDMI and returns to system A.  I can ssh into
system B and everything looks fine, i.e. things that were running
under my user id are still running, e.g. chrome and firefox. I looked
at /var/log/messages and I see this:

Mar 29 23:00:02 jackstraw systemd: Stopping User Manager for UID 0...
Mar 29 23:00:02 jackstraw systemd: Stopped target Default.
Mar 29 23:00:02 jackstraw systemd: Stopped target Basic System.
Mar 29 23:00:02 jackstraw systemd: Stopped target Sockets.
Mar 29 23:00:02 jackstraw systemd: Closed D-Bus User Message Bus Socket.
Mar 29 23:00:02 jackstraw systemd: Stopped target Timers.
Mar 29 23:00:02 jackstraw systemd: Stopped target Paths.
Mar 29 23:00:02 jackstraw systemd: Reached target Shutdown.
Mar 29 23:00:02 jackstraw systemd: Starting Exit the Session...
Mar 29 23:00:02 jackstraw systemd: Received SIGRTMIN+24 from PID 17588
(kill).

This was at the time I switched from system A to system B.  Each of
the other times I saw this problem I see the same set of messages in
the log file.  Can someone explain what they mean and could they be
the cause of the problem?

I see the same messages on the other system, but there they were part
of other messages related to rebooting the system.

The only way I can recover is reboot the system.

Here's my video card info:

01:00.0 VGA compatible controller: NVIDIA Corporation G86 [GeForce
8500 GT] (rev a1)

Any assistance is appreciated.


Since everything is still running as it was it sounds similar to
problems with monitors not coming back from sleep.

Couple of questions.

1.  Are you using the nouveau driver or the nVidia driver for your card?
2.  Are you running GNOME under Wayland or X11?

If you are using X11, and since you can ssh into  the system, what is
the output if you do...

ssh systemB
export DISPLAY=:0
xrandr

Using my system as an example, does doing something like this bring the
monitor back?

[egreshko@meimei ~]$ acer
Last login: Thu Mar 30 15:24:26 2017 from 192.168.1.18
[egreshko@acer ~]$ export DISPLAY=:0

[egreshko@acer ~]$ xrandr
Screen 0: minimum 8 x 8, current 1280 x 800, maximum 8192 x 8192
VGA-0 disconnected (normal left inverted right x axis y axis)
TV-0 disconnected (normal left inverted right x axis y axis)
LVDS-0 connected primary 1280x800+0+0 (normal left inverted right x axis
y axis) 331mm x 207mm
   1280x800  59.91*+
HDMI-0 disconnected (normal left inverted right x axis y axis)

[egreshko@acer ~]$ xrandr --output LVDS-0 --off
[egreshko@acer ~]$ xrandr --output LVDS-0 --auto




With the last two kernels, using the nouveau driver, I am having graphic 
issues.  I can open a session but once the screen locks, then I cannot 
get back to the desktop session.


Using KDE from sddm and Xorg.  These are in the dmesg output.

[8.664136] nouveau :01:00.0: NVIDIA G84 (084000a2)
[8.787588] nouveau :01:00.0: bios: version 60.84.55.00.08
[8.808963] nouveau :01:00.0: fb: 512 MiB GDDR3
[8.859472] nouveau :01:00.0: DRM: VRAM: 512 MiB
[8.859476] nouveau :01:00.0: DRM: GART: 1048576 MiB
[8.859484] nouveau :01:00.0: DRM: TMDS table version 2.0
[8.859488] nouveau :01:00.0: DRM: DCB version 4.0
[8.859494] nouveau :01:00.0: DRM: DCB outp 00: 02000300 0028
[8.859499] nouveau :01:00.0: DRM: DCB outp 01: 01000302 0030
[8.859503] nouveau :01:00.0: DRM: DCB outp 02: 04011310 0028
[8.859507] nouveau :01:00.0: DRM: DCB outp 03: 02011312 0030
[8.859511] nouveau :01:00.0: DRM: DCB outp 04: 010223f1 00c0c080
[8.859515] nouveau :01:00.0: DRM: DCB conn 00: 1030
[8.859518] nouveau :01:00.0: DRM: DCB conn 01: 2130
[8.859522] nouveau :01:00.0: DRM: DCB conn 02: 0210
[8.859525] nouveau :01:00.0: DRM: DCB conn 03: 0211
[8.859529] nouveau :01:00.0: DRM: DCB conn 04: 0213
[8.865523] nouveau :01:00.0: DRM: failed to create encoder
0/1/0: -19
[8.865528] nouveau :01:00.0: DRM: TV-1 has no encoders, removing
[8.865830] nouveau :01:00.0: hwmon_device_register() is
deprecated. Please convert the driver to use
hwmon_device_register_with_info().
[8.877852] nouveau :01:00.0: DRM: MM: using CRYPT for buffer copies
[8.938575] nouveau :01:00.0: DRM: allocated 1920x1080 fb:
0x7, bo 936ca13d1c00
[8.940133] fbcon: nouveaufb (fb0) is 

Re: System alive but can't access from the monitor

2017-03-30 Thread Paolo Galtieri
I booted off a prior kernel (4.9.14-200) and I don't see the problem. so 
the issue islikely to be related to the latest kernel.


Paolo

On 03/30/2017 12:35 AM, Ed Greshko wrote:

On 03/30/17 14:24, Paolo Galtieri wrote:

Folks,
   I have 2 F25 systems that have been updated today.  These 2 systems
share a monitor.  One system is attached via a kvm switch to the
monitor, the other system is attached via hdmi.  This morning and
twice this evening a problem has started to manifest itself.  This
configuration has been working fine for several years.  I will call
the systems A and B, system A is attached to the monitor via hdmi,
system B via VGA.  If I switch to system A for a while and then try to
switch back to system B the monitor instead of staying on VGA cycles
from VGA to DVI to HDMI and returns to system A.  I can ssh into
system B and everything looks fine, i.e. things that were running
under my user id are still running, e.g. chrome and firefox. I looked
at /var/log/messages and I see this:

Mar 29 23:00:02 jackstraw systemd: Stopping User Manager for UID 0...
Mar 29 23:00:02 jackstraw systemd: Stopped target Default.
Mar 29 23:00:02 jackstraw systemd: Stopped target Basic System.
Mar 29 23:00:02 jackstraw systemd: Stopped target Sockets.
Mar 29 23:00:02 jackstraw systemd: Closed D-Bus User Message Bus Socket.
Mar 29 23:00:02 jackstraw systemd: Stopped target Timers.
Mar 29 23:00:02 jackstraw systemd: Stopped target Paths.
Mar 29 23:00:02 jackstraw systemd: Reached target Shutdown.
Mar 29 23:00:02 jackstraw systemd: Starting Exit the Session...
Mar 29 23:00:02 jackstraw systemd: Received SIGRTMIN+24 from PID 17588
(kill).

This was at the time I switched from system A to system B.  Each of
the other times I saw this problem I see the same set of messages in
the log file.  Can someone explain what they mean and could they be
the cause of the problem?

I see the same messages on the other system, but there they were part
of other messages related to rebooting the system.

The only way I can recover is reboot the system.

Here's my video card info:

01:00.0 VGA compatible controller: NVIDIA Corporation G86 [GeForce
8500 GT] (rev a1)

Any assistance is appreciated.

Since everything is still running as it was it sounds similar to
problems with monitors not coming back from sleep.

Couple of questions.

1.  Are you using the nouveau driver or the nVidia driver for your card?
2.  Are you running GNOME under Wayland or X11?

If you are using X11, and since you can ssh into  the system, what is
the output if you do...

ssh systemB
export DISPLAY=:0
xrandr

Using my system as an example, does doing something like this bring the
monitor back?

[egreshko@meimei ~]$ acer
Last login: Thu Mar 30 15:24:26 2017 from 192.168.1.18
[egreshko@acer ~]$ export DISPLAY=:0

[egreshko@acer ~]$ xrandr
Screen 0: minimum 8 x 8, current 1280 x 800, maximum 8192 x 8192
VGA-0 disconnected (normal left inverted right x axis y axis)
TV-0 disconnected (normal left inverted right x axis y axis)
LVDS-0 connected primary 1280x800+0+0 (normal left inverted right x axis
y axis) 331mm x 207mm
1280x800  59.91*+
HDMI-0 disconnected (normal left inverted right x axis y axis)

[egreshko@acer ~]$ xrandr --output LVDS-0 --off
[egreshko@acer ~]$ xrandr --output LVDS-0 --auto


___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org


Re: System alive but can't access from the monitor

2017-03-30 Thread Paolo Galtieri

I'm using the nouveau drivers and I'm running MATE under X11.

If I do

ssh systemB
export DISPLAY=:0
xrandr

I get no output, it just hangs, and the monitor does not wakeup.

Paolo

On 03/30/2017 12:35 AM, Ed Greshko wrote:

On 03/30/17 14:24, Paolo Galtieri wrote:

Folks,
   I have 2 F25 systems that have been updated today.  These 2 systems
share a monitor.  One system is attached via a kvm switch to the
monitor, the other system is attached via hdmi.  This morning and
twice this evening a problem has started to manifest itself.  This
configuration has been working fine for several years.  I will call
the systems A and B, system A is attached to the monitor via hdmi,
system B via VGA.  If I switch to system A for a while and then try to
switch back to system B the monitor instead of staying on VGA cycles
from VGA to DVI to HDMI and returns to system A.  I can ssh into
system B and everything looks fine, i.e. things that were running
under my user id are still running, e.g. chrome and firefox. I looked
at /var/log/messages and I see this:

Mar 29 23:00:02 jackstraw systemd: Stopping User Manager for UID 0...
Mar 29 23:00:02 jackstraw systemd: Stopped target Default.
Mar 29 23:00:02 jackstraw systemd: Stopped target Basic System.
Mar 29 23:00:02 jackstraw systemd: Stopped target Sockets.
Mar 29 23:00:02 jackstraw systemd: Closed D-Bus User Message Bus Socket.
Mar 29 23:00:02 jackstraw systemd: Stopped target Timers.
Mar 29 23:00:02 jackstraw systemd: Stopped target Paths.
Mar 29 23:00:02 jackstraw systemd: Reached target Shutdown.
Mar 29 23:00:02 jackstraw systemd: Starting Exit the Session...
Mar 29 23:00:02 jackstraw systemd: Received SIGRTMIN+24 from PID 17588
(kill).

This was at the time I switched from system A to system B.  Each of
the other times I saw this problem I see the same set of messages in
the log file.  Can someone explain what they mean and could they be
the cause of the problem?

I see the same messages on the other system, but there they were part
of other messages related to rebooting the system.

The only way I can recover is reboot the system.

Here's my video card info:

01:00.0 VGA compatible controller: NVIDIA Corporation G86 [GeForce
8500 GT] (rev a1)

Any assistance is appreciated.

Since everything is still running as it was it sounds similar to
problems with monitors not coming back from sleep.

Couple of questions.

1.  Are you using the nouveau driver or the nVidia driver for your card?
2.  Are you running GNOME under Wayland or X11?

If you are using X11, and since you can ssh into  the system, what is
the output if you do...

ssh systemB
export DISPLAY=:0
xrandr

Using my system as an example, does doing something like this bring the
monitor back?

[egreshko@meimei ~]$ acer
Last login: Thu Mar 30 15:24:26 2017 from 192.168.1.18
[egreshko@acer ~]$ export DISPLAY=:0

[egreshko@acer ~]$ xrandr
Screen 0: minimum 8 x 8, current 1280 x 800, maximum 8192 x 8192
VGA-0 disconnected (normal left inverted right x axis y axis)
TV-0 disconnected (normal left inverted right x axis y axis)
LVDS-0 connected primary 1280x800+0+0 (normal left inverted right x axis
y axis) 331mm x 207mm
1280x800  59.91*+
HDMI-0 disconnected (normal left inverted right x axis y axis)

[egreshko@acer ~]$ xrandr --output LVDS-0 --off
[egreshko@acer ~]$ xrandr --output LVDS-0 --auto


___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org


Re: System alive but can't access from the monitor

2017-03-30 Thread Ed Greshko
On 03/30/17 14:24, Paolo Galtieri wrote:
> Folks,
>   I have 2 F25 systems that have been updated today.  These 2 systems
> share a monitor.  One system is attached via a kvm switch to the
> monitor, the other system is attached via hdmi.  This morning and
> twice this evening a problem has started to manifest itself.  This
> configuration has been working fine for several years.  I will call
> the systems A and B, system A is attached to the monitor via hdmi,
> system B via VGA.  If I switch to system A for a while and then try to
> switch back to system B the monitor instead of staying on VGA cycles
> from VGA to DVI to HDMI and returns to system A.  I can ssh into
> system B and everything looks fine, i.e. things that were running
> under my user id are still running, e.g. chrome and firefox. I looked
> at /var/log/messages and I see this:
>
> Mar 29 23:00:02 jackstraw systemd: Stopping User Manager for UID 0...
> Mar 29 23:00:02 jackstraw systemd: Stopped target Default.
> Mar 29 23:00:02 jackstraw systemd: Stopped target Basic System.
> Mar 29 23:00:02 jackstraw systemd: Stopped target Sockets.
> Mar 29 23:00:02 jackstraw systemd: Closed D-Bus User Message Bus Socket.
> Mar 29 23:00:02 jackstraw systemd: Stopped target Timers.
> Mar 29 23:00:02 jackstraw systemd: Stopped target Paths.
> Mar 29 23:00:02 jackstraw systemd: Reached target Shutdown.
> Mar 29 23:00:02 jackstraw systemd: Starting Exit the Session...
> Mar 29 23:00:02 jackstraw systemd: Received SIGRTMIN+24 from PID 17588
> (kill).
>
> This was at the time I switched from system A to system B.  Each of
> the other times I saw this problem I see the same set of messages in
> the log file.  Can someone explain what they mean and could they be
> the cause of the problem?
>
> I see the same messages on the other system, but there they were part
> of other messages related to rebooting the system.
>
> The only way I can recover is reboot the system.
>
> Here's my video card info:
>
> 01:00.0 VGA compatible controller: NVIDIA Corporation G86 [GeForce
> 8500 GT] (rev a1)
>
> Any assistance is appreciated.

Since everything is still running as it was it sounds similar to
problems with monitors not coming back from sleep.

Couple of questions.  

1.  Are you using the nouveau driver or the nVidia driver for your card?
2.  Are you running GNOME under Wayland or X11?

If you are using X11, and since you can ssh into  the system, what is
the output if you do...

ssh systemB
export DISPLAY=:0
xrandr

Using my system as an example, does doing something like this bring the
monitor back?

[egreshko@meimei ~]$ acer
Last login: Thu Mar 30 15:24:26 2017 from 192.168.1.18
[egreshko@acer ~]$ export DISPLAY=:0

[egreshko@acer ~]$ xrandr
Screen 0: minimum 8 x 8, current 1280 x 800, maximum 8192 x 8192
VGA-0 disconnected (normal left inverted right x axis y axis)
TV-0 disconnected (normal left inverted right x axis y axis)
LVDS-0 connected primary 1280x800+0+0 (normal left inverted right x axis
y axis) 331mm x 207mm
   1280x800  59.91*+
HDMI-0 disconnected (normal left inverted right x axis y axis)

[egreshko@acer ~]$ xrandr --output LVDS-0 --off
[egreshko@acer ~]$ xrandr --output LVDS-0 --auto

-- 
Fedora Users List - The place to go to get others to do the work for you
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org


System alive but can't access from the monitor

2017-03-30 Thread Paolo Galtieri

Folks,
  I have 2 F25 systems that have been updated today.  These 2 systems 
share a monitor.  One system is attached via a kvm switch to the 
monitor, the other system is attached via hdmi.  This morning and twice 
this evening a problem has started to manifest itself.  This 
configuration has been working fine for several years.  I will call the 
systems A and B, system A is attached to the monitor via hdmi, system B 
via VGA.  If I switch to system A for a while and then try to switch 
back to system B the monitor instead of staying on VGA cycles from VGA 
to DVI to HDMI and returns to system A.  I can ssh into system B and 
everything looks fine, i.e. things that were running under my user id 
are still running, e.g. chrome and firefox. I looked at 
/var/log/messages and I see this:


Mar 29 23:00:02 jackstraw systemd: Stopping User Manager for UID 0...
Mar 29 23:00:02 jackstraw systemd: Stopped target Default.
Mar 29 23:00:02 jackstraw systemd: Stopped target Basic System.
Mar 29 23:00:02 jackstraw systemd: Stopped target Sockets.
Mar 29 23:00:02 jackstraw systemd: Closed D-Bus User Message Bus Socket.
Mar 29 23:00:02 jackstraw systemd: Stopped target Timers.
Mar 29 23:00:02 jackstraw systemd: Stopped target Paths.
Mar 29 23:00:02 jackstraw systemd: Reached target Shutdown.
Mar 29 23:00:02 jackstraw systemd: Starting Exit the Session...
Mar 29 23:00:02 jackstraw systemd: Received SIGRTMIN+24 from PID 17588 
(kill).


This was at the time I switched from system A to system B.  Each of the 
other times I saw this problem I see the same set of messages in the log 
file.  Can someone explain what they mean and could they be the cause of 
the problem?


I see the same messages on the other system, but there they were part of 
other messages related to rebooting the system.


The only way I can recover is reboot the system.

Here's my video card info:

01:00.0 VGA compatible controller: NVIDIA Corporation G86 [GeForce 8500 
GT] (rev a1)


Any assistance is appreciated.

Thanks,
Paolo
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org