Running Kubuntu 12.10 on a Dell Latitude E6500 running the free NVIDIA driver for my display. If I hit alt-tab to switch between windows too fast the display locks up and the only way I can unlock it is restart the machine, either hard power the box off or SSH into and reboot. All other services and applications continue to run. Nothing locks or crashes, no other messages, just the display locks.
Any ideas where to start troubleshooting this?
This is a bug, so I'm assuming you're asking how to collect the necessary information to report it. (Otherwise, this question is probably off-topic; see the FAQ and this meta question.)
You said:
I'm running the Project Neon ppa and when I login with the user asscocatied w/ that i don't seem to have any lockups.
I'm assuming that means when you log in to a KDE desktop, the problem does not occur, but that it does occur when you log into a dekstop not provided by packages from the Project Neon PPA.
However, if this is happening in a GUI provided by Project Neon, please make sure you've read this carefully and are following its guidelines when reporting the bug.
Whether or not this is a bug in Project Neon software, I highly recommend reading this all the way through before reporting bugs in Ubuntu. For Kubuntu, I recommend still reading that, but also this (and take a look at this portal page). This question is also a useful resource. And here's some good general bug reporting advice.
If you've already read all that and understand how to report bugs, you can skip ahead...
If you report the bug against the wrong package, provided that the report is otherwise good and has all the necessary information, this usually can be figured out by a triager or developer, and the bug report can be pretty easily retargeted to another package.
However, since much of the important technical information in an Ubuntu bug report is often provided by running Apport, and Apport figures out what to send based on what package the bug is being reported against, it's good to make an initial effort to select the right one, especially for video, sound, driver, or kernel problems, where Apport can often submit a lot of highly valuable information.
The screen freeze is probably due either to, or at least closely related to, the X server or the window manager.
At the login screen you can select between different interfaces. All of them use the same X server, but some use different window managers.
If you're experiencing this with all options, then this bug probably relates to the X server, and it can be reported against xserver-xorg by running ubuntu-bug xserver-xorg. But it's better to run ubuntu-bug with the PID of the running Xorg process that may be malfunctioning. ubuntu-bug $(pidof Xorg) should do this.
(See below for an explanation of how to run ubuntu-bug when your screen is frozen.)
However, it sounds from what you said that this is not the case--that at least one option (logging in with a desktop provided by Project Neon) works.
Kubuntu's window manager is kwin, provided by the kde-window-manager package. To report a bug against it, you can run ubuntu-bug kde-window-manager, but it's better to run ubuntu-bug with the PID of the running kwin process that may be malfunctioning. ubuntu-bug $(pidof kwin) should do this.
If the problem is specific to a 3D Unity session, the window manager running when it occurs is compiz.
ubuntu-bug compiz is okay. ubuntu-bug $(pidof compiz) is betterOn the other hand if it just happens in Unity 2D (and a GNOME Classic/Fallback session), the window manager is metacity:
ubuntu-bug metacity is okay. ubuntu-bug $(pidof metacity) is better.If it happens in a GNOME 3 desktop running GNOME Shell (not Unity), the window manager is mutter.
ubuntu-bug mutter is okay. ubuntu-bug $(pidof mutter) is better.If it happens in an Xubuntu desktop, the window manager is xfwm4.
ubuntu-bug xfwm4 is okay. ubuntu-bug $(pidof xfwm4) is better.If it happens in an LXDE desktop, the window manager is openbox.
ubuntu-bug openbox is okay. ubuntu-bug $(pidof openbox) is better.If you have one user account that boots to one UI by default, and another user account that boots to another UI by default, and the bug happens in one but not the other, then (since this is a UI bug) the UI difference is probably what's important.
But you sure make sure, since sometimes a specific user's configuration manages to trigger a bug. You should verify that it happens with a user account logged in with one UI, and with the same user account logged in to a different UI.
You should also see if usage patterns are what trigger the bug. For example, see if the number of windows you're Alt+Tabing through is relevant to whether or not the bug occurs. (If it occurs with only one window, that's particularly interesting.) This sort of information should be included in your bug report.
It's possible the bug is in some package other than the X Server or the window manager.
In any case, reporting the bug against either the window manager or the X Server, depending on which appears more likely, will usually cause Apport to upload enough of the right information that if the bug is in something else, that can be figured out.
You've found you can SSH in. So it seems likely that you can access a virtual console with Ctrl+Alt+F1, Ctrl+Alt+F2, and so forth, up to F6.
(To switch back to the GUI, use Alt+F7.)
If that works, you can report the bug from the virtual console while the GUI is still running and malfunctioning. ubuntu-bug, when run in a virtual console, should detect there is no GUI and run in text mode instead. Or if you prefer to use the apport-cli command instead, that works too.
SSHing in to report it is probably easier though, as then you can copy the Launchpad URL provided by ubuntu-bug/apport-cli and paste it into a graphical web browser on the SSH client.
Alternatively you might consider using ssh -X to connect. Then you can run GUI programs on the malfunctioning machine (that you're SSHed into), and make their interfaces (their windows) appear on the SSH client. You could then run ubuntu-bug graphically and report the bug from a graphical web browser that runs on the malfunctioning machine that is the SSH server but displays on the properly functioning machine that is the SSH client.
Depending on the nature of the bug, it might be particularly helpful to run ubuntu-bug (or apport-cli) with the PID of the buggy process, rather than just with the name of the package. This will automatically include information about the running state of the process, in the files uploaded to Launchpad by Apport.
So if ubuntu-bug $(pidof processname) doesn't work or doesn't get the right process, you can also:
Run pidof manually and see what you get. If you get nothing, it means no process by that name is running.
Run pgrep, which shows PID's of all processes matching the argument as a regular expression (rather than whose names are equal to the argument, as pidof does).
Use the tried-and-true, classic technique (ps, piped to grep):
ps ax | grep -v grep | grep processnameThat provides more detailed information--it gives a listing of the name, PID, and states of any matching processes.
Make sure /var/log/Xorg.0.log and (if it exists) /var/log/Xorg.0.log.old are attached.
Similarly, make sure ~/.xsession-errors and (if it exists) ~/.xsession-errors.old are attached. (~ represents your home folder.) Dotfiles are not shown in Nautilus by default, so if you want to see them in a graphical file browser window, do Ctrl+H (or View > Show Hidden Files).
When you report a bug on Launchpad, Apport will have automatically sent a number of files, which will have been attached. You can also attach one more file. To attach different files, submit the bug report first--then you can attach them.
