Viestialustana vianhallintajärjestelmät

There were seemingly similar freezes before Precise

20. helmikuuta 2012 klo 19.22
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Linux

@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?

Vastaa viestiin sen kontekstissa (Launchpad)

unity-2d-shell crashed with SIGSEGV

20. helmikuuta 2012 klo 6.36
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Unity

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).

Vastaa viestiin sen kontekstissa (Launchpad)

It should save the shots into your ’Pictures’ directory without launching the GUI now

20. helmikuuta 2012 klo 6.16
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Gnome

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

Vastaa viestiin sen kontekstissa (Launchpad)

Not reproducible under Unity 3D.

19. helmikuuta 2012 klo 21.32
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Chromium, Unity

Not reproducible under Unity 3D.

Vastaa viestiin sen kontekstissa (Launchpad)

Wireless network interfaces’ names: eth1 vs. wlan0

19. helmikuuta 2012 klo 20.42
Sijainti: Vianhallintajärjestelmät: Launchpad

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.

Vastaa viestiin sen kontekstissa (Launchpad)

This is apparently caused by something not in Chromium itself

19. helmikuuta 2012 klo 20.14
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Chrome, Chromium, Epiphany, Firefox

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.

Vastaa viestiin sen kontekstissa (Launchpad)

Can no longer drop tabs onto tabs area

18. helmikuuta 2012 klo 22.03
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Chromium

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).

Vastaa viestiin sen kontekstissa (Launchpad)

”Restart services during package upgrades without asking?” fails to honor –yes for apt-get

18. helmikuuta 2012 klo 21.37
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: saavutettavuus

I left an old netbook to do an ”apt-get -y dist-upgrade” overnight, and when I returned to it the next morning, the upgrades were unfinished because libc upgrade was waiting for me to respond to ”Restart services during package upgrades without asking?”

It looks like the question is prioritized depending on whether the upgrade is done on desktop or not, and if it’s not, the priority is set critical. According to documentation [1], critical is for ”Items that will probably break the system without user intervention.” I don’t think restart-without-asking satisfies that condition.

* [1] http://www.debian.org/doc/packaging-manuals/debconf_specification.html#AEN101

Vastaa viestiin sen kontekstissa (Launchpad)

With both 3.2.0-16 and 3.2.0-17, what I said in #8 still holds

18. helmikuuta 2012 klo 20.04
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Linux

With both 3.2.0-16 and 3.2.0-17, what I said in #8 still holds, with -16 and -17 behaving just as -15 did. 3.2.0-17 added something interesting though: booting 3.2.0-17-pae in recovery mode ”breaks” the -pae’s like (non-recovery booting) 3.2.0-14-pae does. To be sure, I tried recovery booting other kernels going back to 3.2.0-14, and couldn’t reproduce this with them (not even with 3.2.0-14-pae!) . Recovery booting 3.2.0-17 non-pae also doesn’t bring it on, it’s just recovery booting 3.2.0-17-pae.

The steps to reproducing this freeze with 3.2.0-17 are:
1. Boot 3.2.0-17-pae in recovery mode.
2. In the recovery menu, select ”root”.
3. From the root prompt, just reboot.
4. Boot 3.2.0-17-pae (normally).

The ”fix” also still holds: just boot a non-pae kernel once, and the pae’s again work.

Vastaa viestiin sen kontekstissa (Launchpad)

After dozens and dozens of boots with the 3.2.0-14 and 3.2.0-15 kernels, here’s what I know.

11. helmikuuta 2012 klo 20.14
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Linux

After dozens and dozens of boots with the 3.2.0-14 and 3.2.0-15 kernels, here’s what I know.

1. This *is* tied to wistron_btns as I reported. Without it, boot never fails (the way I initially reported, though I’ll redefine what ”fails” means further below).
2. With non-pae kernels, boot never fails.
3. With 3.2.0-14-pae, the boot always fails.
4. A cold boot with 3.2.0-15-pae never fails.
5. A re-boot with 3.2.0-15-pae after a *non-failing* boot never fails.
6. A re-boot of 3.2.0-15-pae, after a *failing* boot (of 3.2.0-14-pae for instance), is *almost* sure to fail. I’d give it a 10% chance of not failing.

If you put it another way, this appears is pretty interesting:
1. You can ”break” 3.2.0-15-pae by booting 3.2.0-14-pae first.
2. You ”fix” a thus ”broken” 3.2.0-15-pae by booting a non-pae kernel.

I suspect this brokenness is actually hidden in the hardware, in something (the wifi key perhaps?) controlled by wistron_btns. Booting 3.2.0-14-pae puts the controller(?) in a ”broken” state from which 3.2.0-15-pae can’t recover, but a non-pae kernel can. And though 3.2.0-15-pae can’t recover a ”broken” controller, it also cannot put it into that ”broken” state (which is a good turn of development).

So now, about that ”fails” part.

I discovered by accident that although the system appears to freeze in boots I referred to as ”fails”, it has in fact been brought down to *almost* complete halt, but *just* almost. If I’m patient enough to wait, it does actually boot into LDM, from where I can switch to another VT and log in… slooooooowly.

Thus I was able to find out what’s going on that makes it so slow:

jani@amilo:~$ head dmesg.fail
stron_btns: Unknown key code 10
[ 1011.554522] wistron_btns: Unknown key code 10
[ 1011.554722] wistron_btns: Unknown key code 10
[ 1011.554921] wistron_btns: Unknown key code 10
[ 1011.555120] wistron_btns: Unknown key code 10
[ 1011.555320] wistron_btns: Unknown key code 10
[ 1011.555518] wistron_btns: Unknown key code 10
[ 1011.555717] wistron_btns: Unknown key code 10
[ 1011.555916] wistron_btns: Unknown key code 10
[ 1011.556134] wistron_btns: Unknown key code 10
jani@amilo:~$ grep wistron dmesg.fail | wc -l
2520

Note that this is unrelated to pressing any actual physical buttons. It’ wistron_btns misbehaving under the conditions I described above.

Vastaa viestiin sen kontekstissa (Launchpad)

« Uudempia - Vanhempia »