sometimes boot fails

[thom]

Probably not an Xorg problem:

Lubuntu Trusty
Linux xxxxxx 3.13.0-5-generic #20-Ubuntu SMP Mon Jan 20 19:58:23 UTC 2014 i686 athlon i686 GNU/Linux

CPU: dual core turion

1) sometimes i have to start lightdm manually
2) sometimes a big freeze during boot, even before attempting loading X . (reboot needed)
3) sometimes kernel complains about CPU-firmware missing.
4) sometimes b43 wlan hardware not detected

Sorry I can't be more clear about this.
Half of the times it is booting perfectly.
It feels like a racecondition somewhere ( module? / kernel? ).

Since this bug report was automagically generated by apport I hope you guys can make any sense of it.

ProblemType: Crash
DistroRelease: Ubuntu 14.04
Package: xserver-xorg-core 2:1.14.5-1ubuntu2
ProcVersionSignature: Ubuntu 3.13.0-5.20-generic 3.13.0
Uname: Linux 3.13.0-5-generic i686
ApportVersion: 2.13.1-0ubuntu2
Architecture: i386
CrashCounter: 1
Date: Sat Jan 25 18:03:23 2014
ExecutablePath: /usr/bin/Xorg
InstallationDate: Installed on 2014-01-04 (21 days ago)
InstallationMedia: Lubuntu 14.04 "Trusty Tahr" - Alpha i386 (20140102)
ProcCmdline: /usr/bin/X -core :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
ProcEnviron:

Signal: 6
SourcePackage: xorg-server
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

[thom (tsk)]

The computer (laptop hp6735s ) where this happens is not used for serious work, only for testing Lubuntu 14.04.
If you want me to test things, I will be glad to do so.

[Apport retracing service (apport)]

StacktraceTop:
 pci_device_next (iter=iter@entry=0xbf88b55c) at ../../src/common_iterator.c:179
 pci_device_find_by_slot (domain=0, bus=1, dev=5, func=0) at ../../src/common_iterator.c:230
 pci_device_vgaarb_init () at ../../src/common_vgaarb.c:144
 xf86VGAarbiterInit () at ../../../../hw/xfree86/common/xf86VGAarbiter.c:72
 xf86BusConfig () at ../../../../hw/xfree86/common/xf86Bus.c:135

[thom (tsk)]

Additional info:

When problem occurs, this is the output:

[ 17.200131] b43-phy0 ERROR: Microcode not responding
[ 17.200140] b43-phy0 ERROR: You must go to http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware and download the correct firmware for this driver version. Please carefully read all instructions on this website.
[ 17.200367] IPv6: ADDRCONF(NETDEV_UP): wlan2: link is not ready

I can start lightdm manually after that. X will start and the b43 driver seems to work properly.

I can attach the dmesg.log that I saved for this occasion if that is helpful.

[thom (tsk)]

Kernel update seems to have solved the issue:

Linux 3.13.0-6-generic #23-ubuntu SMP thu Jan 30 9:46:16 UTC 2014 i686 athlon i686 GNU/Linux

[thom (tsk)]

REGRESSION:

Bug reappeared after update to:

Linux 3.13.0-7-generic #26-Ubuntu SMP Wed Feb 5 21:33:39 UTC 2014 i686 athlon i686 Gnu/Linux

[thom (tsk)]

Addendum:

Booting the previous 3.13.0-6-generic will continue to boot but shows the "firmwre not responding" error briefly.
The update that triggered the regression was:

Start-Date: 2014-02-06 11:56:33
Commandline: apt-get -y upgrade
Upgrade: libdpkg-perl:i386 (1.17.5ubuntu2, 1.17.5ubuntu3), libfontembed1:i386 (1.0.44-1, 1.0.44-2), abiword-common:i386 (3.0.0-2ubuntu1, 3.0.0-4), ubuntu-standard:i386 (1.315, 1.316), dpkg:i386 (1.17.5ubuntu2, 1.17.5ubuntu3), libcupsfilters1:i386 (1.0.44-1, 1.0.44-2), libabiword-3.0:i386 (3.0.0-2ubuntu1, 3.0.0-4), libgirepository-1.0-1:i386 (1.39.3-0ubuntu1, 1.39.3-0ubuntu2), dpkg-dev:i386 (1.17.5ubuntu2, 1.17.5ubuntu3), libevview3-3:i386 (3.10.3-0ubuntu2, 3.10.3-0ubuntu3), gir1.2-freedesktop:i386 (1.39.3-0ubuntu1, 1.39.3-0ubuntu2), xserver-common:i386 (1.15.0-1ubuntu1, 1.15.0-1ubuntu2), cups-filters:i386 (1.0.44-1, 1.0.44-2), linux-libc-dev:i386 (3.13.0-7.25, 3.13.0-7.26), xserver-xorg-video-intel:i386 (2.99.907-0ubuntu2, 2.99.909-0ubuntu2), evince-common:i386 (3.10.3-0ubuntu2, 3.10.3-0ubuntu3), abiword:i386 (3.0.0-2ubuntu1, 3.0.0-4), gir1.2-glib-2.0:i386 (1.39.3-0ubuntu1, 1.39.3-0ubuntu2), linux-image-extra-3.13.0-7-generic:i386 (3.13.0-7.25, 3.13.0-7.26), linux-image-3.13.0-7-generic:i386 (3.13.0-7.25, 3.13.0-7.26), dh-python:i386 (1.20131021-1ubuntu8, 1.20140128-1ubuntu1), ubuntu-minimal:i386 (1.315, 1.316), evince:i386 (3.10.3-0ubuntu2, 3.10.3-0ubuntu3), libevdocument3-4:i386 (3.10.3-0ubuntu2, 3.10.3-0ubuntu3), cups-filters-core-drivers:i386 (1.0.44-1, 1.0.44-2)
End-Date: 2014-02-06 11:59:37

During upgrade this warning appeared twice:

dkms: WARNING: Linux headers are missing, which may explain the above failures.
      please install the linux-headers-3.13.0-7-generic package to fix this.

Even though there were no further failures in the log I installed linux-headers-3.13.0-7-generic manually afterwards.

[thom (tsk)]

UPDATE

After installing linux-headers-3.13.0-7-generic manually
and re-installing linux-image-3.13.0-7-generic
the problem seems solved.

Not that I fully understand what happened but nevertheless... :-)

[thom (tsk)]

After installing linux-image-3.13.0-8-generic the problem is back

one difference: it now boots to desktop "without problem" but apport is triggered due to the "Microcode not responding" error

[thom (tsk)]

After yesterdays update, the problem seems to be solved :-)

kernel: Linux 3.13.0-11-generic #31-Ubuntu SMP Wed Feb 19 19:59:55 UTC 2014 i686 athlon i686 Gnu/Linux

[thom (tsk)]

problem is back:

Linux 3.13.0-17-generic #37-Ubuntu SMP Mon Mar 10 21:47:52 UTC 2014 i686 athlon i686 GNU/Linux

installing the headers manually and reinstalling the kernel fixes the problem again

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Alberto Salvia Novella (es20490446e)]

It renders the system temporarily or permanently unusable.

[Timo Aaltonen (tjaalton)]

sounds like you have some dkms package installed that needs the headers to build, so just make sure you have linux-generic installed..

[thom (tsk)]

@Tima, yes that is correct, I have some dkms package installed that needs the headers. I do have the linux-generic package installed and it also pulls the headers in. The problem was that it consequently installed the headers *after* processing dkms.

Since the last few updates, the problem seems to be solved upstream. ( Now running kernel 3.13.0-24-generic at the moment).