This happened to me just now. I killed u2d-shell, because it was rendering wrong already: it left a white vertical column when hiding, obscuring the view to the app underneath. When it restarted, the launcher was only 7,5 icons high (looks like Lohith’s screenshot, though slightly higher). Neither of these symptoms have occurred prior to this.

A new `killall unity-2d-shell` fixed the issue for this session.

Forgot to mention I could reboot after the crash with Alt+PrtSc+REISUB (if that matters).

A crash that threw me (from the desktop) into the console to show the Oops. Hasn’t happened before as to my knowledge, looks different from bug #917668 (which I’m affected by), but similar to bug #886706 (and bug #495322), but kernel bugs are too much out of my league to tell for sure.

Wasn’t doing anything specific that I could reproduce this with currently. At least Chromium, Transmission and Rhythmbox were active during the time.

Syslog has some data, I’ll attach it manually if apport doesn’t bring it in automatically.

I’ll happily do further testing and/or log uploads at request.

@jsalisbury: On this setup, there were seemingly similar freezes before Precise (I was using Lucid until then), but being so far apart and without a reliable recipe for reproducing, I mostly just ignored the issue. To give a clue as to the rarity, an (again seemingly) similar freeze happened just now, for the first time since I reported the bug, so if it’s the same issue, it’s been in hiding for over a month.

Unfortunately the logs didn’t have anything about this crash, and I couldn’t ssh in either. As I have yet to gather any substantial data apart from the little I posted above, there’s no way of knowing whether it’s always been the same issue or not. The symptom on the surface has always been very similar, but I guess that’s true for most freezes are even if brought on by unrelated causes.

I’m not afraid of testing the mainline kernel per se, but I’m hesitant because with this occurence rate, wouldn’t I be trying to prove a negative? Would 2 months without the issue constitute a ’kernel-fixed-upstream’? 6 months? Also, should I install v3.3-rc2-precise as you suggested, or the more recent 3.3-rc4-precise now? If the more recent one, should I then stick to it, or keep upgrading as new mainline kernels are built?

After upgrading Unity to 5.4, the launcher regularly gets stuck on the side despite being set to hide automatically both in Appearance settings and dconf. It does hide initially as it should, but then eventually no longer does and just stays there on top, blocking that part of the app underneath it. It usually then freezes after some time, then crashes and restarts, after which the autohide again works for a while. Before the freeze it does otherwise work save for the autohiding.

This is the report generated from such a crash. I have a feeling the freezing/crashing can be triggered by scrolling the launcher contents (when it’s in the ”stuck” mode).

It should save the shots into your ’Pictures’ directory without launching the GUI now (see Bug #928364). Is that what’s not happening?

Not reproducible under Unity 3D.

I noticed my laptop’s wireless interface is named eth1, whereas the wireless on a netbook is named wlan0 (both have a wired eth0 in addition to wireless).

I suppose both are set by /etc/udev/rules.d/70-persistent-net.rules:

# PCI device 0x8086:0x1043 (ipw2100)
SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==” (the MAC address) ”, ATTR{dev_id}==”0x0″, ATTR{type}==”1″, KERNEL==”eth*”, NAME=”eth1″

vs.

# PCI device 0x168c:0x001c (ath5k)
SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==” (the MAC address) ”, ATTR{dev_id}==”0x0″, ATTR{type}==”1″, KERNEL==”wlan*”, NAME=”wlan0″

Is there a reasoning behind calling ipw2100’s interface eth1 and not wlan0? Is there any reason I shouldn’t change the name (by editing 70-persistent-net.rules to name the ipw2100 interface ”wlan0”, to make the two systems more alike)? I’m not sure I’ll actually do that, but was interested in what the difference means from both theoretical and practical points of view.

This is apparently caused by something not in Chromium itself: it’s not reproducible in a VM running Oneiric, with 17.0.963.26 from ppa:chromium-daily/dev nor with Chrome 17.0.96356. It *is* reproducible in Precise with the latter too, but not reproducible with Firefox nor Epiphany. In Precise with Chromium 17, it’s reproducible with a temporary profile and a guest login also.

With Chromium 17, I can no longer drag ’n’ drop tabs to reorganize them in an existing window: the tabs area no longer lets me drop tabs onto it, so each tab I pick up gets a new window when dropped. Dragging the tab from the new window into the old won’t work either (cannot drop the tab into where the tabs area should be).