18.04 daily build "hang"

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

18.04 daily build "hang"

David L
I downloaded and installed a daily build of bionic-desktop-amd64.iso yesterday and found it to be unstable... the X interface became unresponsive other than the ability to move the mouse. This happened using the default environment and in plasma with and without Wayland. I have 4 monitors with an nvidia graphics card.

VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 660] (rev a1)

I didn't try to install the proprietary driver for it. I understand that daily builds can be unstable, so my question is, should I bother trying to report this problem and if so, how can I get any useful debug info from a system that is non-responsive other than the ability to move the mouse? Or is this kind of bug typical at this stage in testing and I should wait and try again in a month?

Thanks,

         Dave




--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: 18.04 daily build "hang"

Robert Heller
At Tue, 13 Feb 2018 09:47:13 -0800 "Ubuntu user technical support,  not for general discussions" <[hidden email]> wrote:

>
>
>
> I downloaded and installed a daily build of bionic-desktop-amd64.iso yesterday
> and found it to be unstable... the X interface became unresponsive other
> than the ability to move the mouse. This happened using the default
> environment and in plasma with and without Wayland. I have 4 monitors with
> an nvidia graphics card.
>
> VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 660] (rev
> a1)
>
> I didn't try to install the proprietary driver for it. I understand that
> daily builds can be unstable, so my question is, should I bother trying to
> report this problem and if so, how can I get any useful debug info from a
> system that is non-responsive other than the ability to move the mouse? Or
> is this kind of bug typical at this stage in testing and I should wait and
> try again in a month?

About getting "useful debug info from a system that is non-responsive other
than the ability to move the mouse": can you do any of these:

ssh into the machine from another computer?
did you try installing as a non-graphical startup/login?
were you able to switch to another virtual console?

*I* *always* install Linux without the graphical boot or login. ALL of *my*
linux machines come up to a black console login, and generally with the
verbose boot up. I use startx/xinit to start the GUI, if that is something I
need, *after* I have logged in.

>
> Thanks,
>
>          Dave
>
> MIME-Version: 1.0
>

--
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
[hidden email]       -- Webhosting Services
                                                                                         

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: 18.04 daily build "hang"

David L


On Tue, Feb 13, 2018 at 10:02 AM, Robert Heller <[hidden email]> wrote:
At Tue, 13 Feb 2018 09:47:13 -0800 "Ubuntu user technical support,  not for general discussions" <[hidden email]> wrote:

>
>
>
> I downloaded and installed a daily build of bionic-desktop-amd64.iso yesterday
> and found it to be unstable... the X interface became unresponsive other
> than the ability to move the mouse. This happened using the default
> environment and in plasma with and without Wayland. I have 4 monitors with
> an nvidia graphics card.
>
> VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 660] (rev
> a1)
>
> I didn't try to install the proprietary driver for it. I understand that
> daily builds can be unstable, so my question is, should I bother trying to
> report this problem and if so, how can I get any useful debug info from a
> system that is non-responsive other than the ability to move the mouse? Or
> is this kind of bug typical at this stage in testing and I should wait and
> try again in a month?

About getting "useful debug info from a system that is non-responsive other
than the ability to move the mouse": can you do any of these:

ssh into the machine from another computer?
Didn't try yet. I didn't know the IP address and my firewalls are locked down pretty tight on that network, so I'd have to reconfigure things to try. If I did get in, what should I look for? tail of logs, dmesg??? 
did you try installing as a non-graphical startup/login?
No I didn't but I don't anticipate any problems in that environment, so there would be nothing to debug.
 
were you able to switch to another virtual console?

I didn't try that yet either... would that be ctrl-alt-F2? Again, what commands would I run to capture useful data on a partially responsive graphical session?

Thanks again,

         Dave


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: 18.04 daily build "hang"

Robert Heller
At Tue, 13 Feb 2018 10:26:17 -0800 "Ubuntu user technical support,  not for general discussions" <[hidden email]> wrote:

>
>
>
> On Tue, Feb 13, 2018 at 10:02 AM, Robert Heller <[hidden email]> wrote:
>
> > At Tue, 13 Feb 2018 09:47:13 -0800 "Ubuntu user technical support,  not
> > for general discussions" <[hidden email]> wrote:
> >
> > >
> > >
> > >
> > > I downloaded and installed a daily build of bionic-desktop-amd64.iso
> > yesterday
> > > and found it to be unstable... the X interface became unresponsive other
> > > than the ability to move the mouse. This happened using the default
> > > environment and in plasma with and without Wayland. I have 4 monitors
> > with
> > > an nvidia graphics card.
> > >
> > > VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 660]
> > (rev
> > > a1)
> > >
> > > I didn't try to install the proprietary driver for it. I understand that
> > > daily builds can be unstable, so my question is, should I bother trying
> > to
> > > report this problem and if so, how can I get any useful debug info from a
> > > system that is non-responsive other than the ability to move the mouse?
> > Or
> > > is this kind of bug typical at this stage in testing and I should wait
> > and
> > > try again in a month?
> >
> > About getting "useful debug info from a system that is non-responsive other
> > than the ability to move the mouse": can you do any of these:
> >
> > ssh into the machine from another computer?
> >
> Didn't try yet. I didn't know the IP address and my firewalls are locked
> down pretty tight on that network, so I'd have to reconfigure things to
> try. If I did get in, what should I look for? tail of logs, dmesg???

Looking at /var/log/Xorg.0.log could be enlightening, otherwise, yes looking
at log files can could be useful.  Seeing what sort of state X is in (S or D
or R or what).  Seeing what kill X or kill -9 X does, etc.

>
> > did you try installing as a non-graphical startup/login?
> >
> No I didn't but I don't anticipate any problems in that environment, so
> there would be nothing to debug.

*Excecpt* you could verify that it is indeed the *GUI* subsystem that is
borked.  Also, you can separate the GUI *login* from the GUI itself.  And you
can try ctrl-alt-backspace to kill X11 and return to the console terminal and
then look at log files, etc.  Doing ctrl-alt-backspace with a GUI login, just
restarts the GUI login and if the *GUI* is borked, that can be fruitless.

>
>
> > were you able to switch to another virtual console?
> >
>
> I didn't try that yet either... would that be ctrl-alt-F2? Again, what
> commands would I run to capture useful data on a partially responsive
> graphical session?

ctrl-alt-F[1234567]

Usually ctrl-alt-F7 would be the GUI screen, but sometimes ctrl-alt-F1 is.  
ctrl-alt-F2 is likely be safe and will give you a terminal console.

Looking at /var/log/Xorg.0.log and/or various other log files.

(The commands cat, more, less, tail, or vi would be your friends here.)

Looking at /var/log/Xorg.0.log may also be cluefull in terms of what you can
try putting in /etc/X11/xorg.conf.d/ to deal with possible problems
(incompatable hardware, workarounds for buggy video drivers, etc.). And if
some hack there "works" then that can be helpful for the people writing those
video drivers in terms of what they can do to fix the video drivers.

>
> Thanks again,
>
>          Dave
>
> MIME-Version: 1.0
>

--
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
[hidden email]       -- Webhosting Services
                                                                                                             

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: 18.04 daily build "hang"

David L


On Tue, Feb 13, 2018 at 11:13 AM, Robert Heller <[hidden email]> wrote:
At Tue, 13 Feb 2018 10:26:17 -0800 "Ubuntu user technical support,  not for general discussions" <[hidden email]> wrote:

>
>
>
> On Tue, Feb 13, 2018 at 10:02 AM, Robert Heller <[hidden email]> wrote:
>
> > At Tue, 13 Feb 2018 09:47:13 -0800 "Ubuntu user technical support,  not
> > for general discussions" <[hidden email]> wrote:
> >
> > >
> > >
> > >
> > > I downloaded and installed a daily build of bionic-desktop-amd64.iso
> > yesterday
> > > and found it to be unstable... the X interface became unresponsive other
> > > than the ability to move the mouse. This happened using the default
> > > environment and in plasma with and without Wayland. I have 4 monitors
> > with
> > > an nvidia graphics card.
> > >
> > > VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 660]
> > (rev
> > > a1)
> > >
> > > I didn't try to install the proprietary driver for it. I understand that
> > > daily builds can be unstable, so my question is, should I bother trying
> > to
> > > report this problem and if so, how can I get any useful debug info from a
> > > system that is non-responsive other than the ability to move the mouse?
> > Or
> > > is this kind of bug typical at this stage in testing and I should wait
> > and
> > > try again in a month?
> >
> > About getting "useful debug info from a system that is non-responsive other
> > than the ability to move the mouse": can you do any of these:
> >
> > ssh into the machine from another computer?
> >
> Didn't try yet. I didn't know the IP address and my firewalls are locked
> down pretty tight on that network, so I'd have to reconfigure things to
> try. If I did get in, what should I look for? tail of logs, dmesg???

Looking at /var/log/Xorg.0.log could be enlightening, otherwise, yes looking
at log files can could be useful.  Seeing what sort of state X is in (S or D
or R or what).  Seeing what kill X or kill -9 X does, etc.

>
> > did you try installing as a non-graphical startup/login?
> >
> No I didn't but I don't anticipate any problems in that environment, so
> there would be nothing to debug.

*Excecpt* you could verify that it is indeed the *GUI* subsystem that is
borked.  Also, you can separate the GUI *login* from the GUI itself.  And you
can try ctrl-alt-backspace to kill X11 and return to the console terminal and
then look at log files, etc.  Doing ctrl-alt-backspace with a GUI login, just
restarts the GUI login and if the *GUI* is borked, that can be fruitless.

>
>
> > were you able to switch to another virtual console?
> >
>
> I didn't try that yet either... would that be ctrl-alt-F2? Again, what
> commands would I run to capture useful data on a partially responsive
> graphical session?

ctrl-alt-F[1234567]

So the answer is that ctrl-alt-F[1234567] don't work when it gets into that state and neither does the caps lock light change when I press the button. Furthermore, after an upgrade, it gets into an even less responsive state where the mouse doesn't respond.

Additionally, after I installed kubuntu-desktop and logged in under plasma with Wayland and then rebooted and tried to log into a standard Ubuntu session, I got this error window on a black screen:

"unsupported number of arguments (4); falling back to default session"

Another problem I saw was that one of my monitors is in portrait mode and when I move the mouse across the right boundary, I see two mouse pointers for a while... one where it should be in the window the to right and one where it would be if it was in landscape mode.

Cheers,

          Dave


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: 18.04 daily build "hang"

Liam Proven
On 14 February 2018 at 03:39, David L <[hidden email]> wrote:

> So the answer is that ctrl-alt-F[1234567] don't work when it gets into that
> state and neither does the caps lock light change when I press the button.
> Furthermore, after an upgrade, it gets into an even less responsive state
> where the mouse doesn't respond.
>
> Additionally, after I installed kubuntu-desktop and logged in under plasma
> with Wayland and then rebooted and tried to log into a standard Ubuntu
> session, I got this error window on a black screen:
>
> "unsupported number of arguments (4); falling back to default session"
>
> Another problem I saw was that one of my monitors is in portrait mode and
> when I move the mouse across the right boundary, I see two mouse pointers
> for a while... one where it should be in the window the to right and one
> where it would be if it was in landscape mode.


Does it freeze before or after login?

If before, how did you install KDE?

Try booting with the ``nomodeswitch'' kernel parameter.

You can also try the nVidia drivers if you can get to a console -- no
harm if it's already broken.

Install an ssh server, then you can connect from another machine and
have a poke around and see what's going on.


--
Liam Proven • Profile: https://about.me/liamproven
Email: [hidden email] • Google Mail/Hangouts/Plus: [hidden email]
Twitter/Facebook/Flickr: lproven • Skype/LinkedIn: liamproven
UK: +44 7939-087884 • ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: 18.04 daily build "hang"

David L


On Tue, Feb 13, 2018 at 11:09 PM, Liam Proven <[hidden email]> wrote:
On 14 February 2018 at 03:39, David L <[hidden email]> wrote:

> So the answer is that ctrl-alt-F[1234567] don't work when it gets into that
> state and neither does the caps lock light change when I press the button.
> Furthermore, after an upgrade, it gets into an even less responsive state
> where the mouse doesn't respond.
>
> Additionally, after I installed kubuntu-desktop and logged in under plasma
> with Wayland and then rebooted and tried to log into a standard Ubuntu
> session, I got this error window on a black screen:
>
> "unsupported number of arguments (4); falling back to default session"
>
> Another problem I saw was that one of my monitors is in portrait mode and
> when I move the mouse across the right boundary, I see two mouse pointers
> for a while... one where it should be in the window the to right and one
> where it would be if it was in landscape mode.


Does it freeze before or after login?
It hangs after login.
 
Try booting with the ``nomodeswitch'' kernel parameter.

Ok, I'll try that next time. For some reason I haven't been able to stop grub before booting, but I'll try again.
 
You can also try the nVidia drivers if you can get to a console -- no
harm if it's already broken.

I tried to install the nVidia drivers, but nvidia-settings gave me some error about not finding any displays.


 
Install an ssh server, then you can connect from another machine and
have a poke around and see what's going on.

I did install the sshd, but I forgot the right static IP address that I needed to get to this system from my other computer through firewalls.  Next time I boot to it, I'll try that, but I'm pretty sure the ssh connection will die at the same time as the hang. 


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: 18.04 daily build "hang"

David L


On Tue, Feb 13, 2018 at 11:45 PM, David L <[hidden email]> wrote:


On Tue, Feb 13, 2018 at 11:09 PM, Liam Proven <[hidden email]> wrote:
On 14 February 2018 at 03:39, David L <[hidden email]> wrote:

> So the answer is that ctrl-alt-F[1234567] don't work when it gets into that
> state and neither does the caps lock light change when I press the button.
> Furthermore, after an upgrade, it gets into an even less responsive state
> where the mouse doesn't respond.
>
> Additionally, after I installed kubuntu-desktop and logged in under plasma
> with Wayland and then rebooted and tried to log into a standard Ubuntu
> session, I got this error window on a black screen:
>
> "unsupported number of arguments (4); falling back to default session"
>
> Another problem I saw was that one of my monitors is in portrait mode and
> when I move the mouse across the right boundary, I see two mouse pointers
> for a while... one where it should be in the window the to right and one
> where it would be if it was in landscape mode.


Does it freeze before or after login?
It hangs after login.
 
Try booting with the ``nomodeswitch'' kernel parameter.

Ok, I'll try that next time. For some reason I haven't been able to stop grub before booting, but I'll try again.
 
You can also try the nVidia drivers if you can get to a console -- no
harm if it's already broken.

I tried to install the nVidia drivers, but nvidia-settings gave me some error about not finding any displays.


I recently installed the 18.04 beta release, updated/upgraded and was still seeing the hangs. But this time I was able to install nvidia drivers and I stopped seeing the hangs with the nvidia drivers installed.

One time when it partially hung with the nouveau driver, I could move the mouse, but no other sign of life...even the keyboard caps lock button was not changing the caps lock light, I was still able to ssh into it.

So I assume this is a nouveau driver bug with my video card:
04:00.0 VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 660] (rev a1)


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users