Boot issues after running kernel 3.8.x

This change was made by a bot.

I'd like to perform a bisect to figure out what commit caused this regression. It would be very helpful to know the earliest kernel where the issue started happening as well as the latest kernel that did not have this issue.

Can you test the following kernels and report back? We are looking for the first kernel version that exhibits this bug:

v3.7 final: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-raring/
v3.8-rc1: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc1-raring/
v3.8-rc3: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc3-raring/

You don't have to test every kernel, just up until the kernel that first has this bug.

Thanks in advance!

v3.7 final works just fine as well as 3.7.6, which I am currently running.
v3.8-rc1 doesn't work, nor does anything since (I have checked the last 2 night's daily build)

I noticed sp5100_tco fails to load in 3.7, but does load on 3.8-rc1. I am not sure if it is related in any manner, it just caught my attention.

dmesg from v3.7:

[ 14.431032] sp5100_tco: SP5100 TCO WatchDog Timer Driver v0.01
[ 14.431096] sp5100_tco: mmio address 0xfec000f0 already in use

dmesg from v3.8-rc1:

[ 10.854230] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.03
[ 10.854294] sp5100_tco: PCI Revision ID: 0x3a
[ 10.854341] sp5100_tco: Using 0xfed45000 for watchdog MMIO address
[ 10.854349] sp5100_tco: Last reboot was triggered by watchdog.
[ 10.854388] sp5100_tco: initialized (0xffffc90000678000). heartbeat=60 sec (n

Can you see if blacklisting the sp5100_tco driver in v3.8-rc1 causes the bug to go away? If not, I'll start a kernel bisect between v3.7 and v3.8-rc1.

Yes blacklisting the sp5100_tco driver has resolved the issue.

Here is the command I ran:

   sudo su -c 'echo "blacklist sp5100_tco" >> /etc/modprobe.d/blacklist-watchdog.conf'

This may be relates up upstream commit:
740fbddf5c3f9ad8b23c5d917ba1cc7e376a5104

I'll build a test kernel with that commit reverted and post a link to the kernel shortly.

I built a test kernel with commit 740fbddf5c3f9ad8b23c5d917ba1cc7e376a5104 reverted.

The test kernel can be downloaded from:
http://people.canonical.com/~jsalisbury/lp1116835

Can you test that kernel and report back if it has the bug or not.

Thanks in advance!

The test build does not have the bug. Everything works as expected.

Thanks for testing, Timothy. I sent a message to the patch author requesting feedback regarding this bug.

There are a couple of patches in upstream linux-next that may resolve this bug. Commits:
a6e26b1369b34760ca5e1f16039c9018bf68ce7e
adbdcc030be5f7bb54d229c04efdd0c6b7ed3ab7

I built a Raring test kernel with these two patches applied.

The test kernel can be downloaded from:
http://people.canonical.com/~jsalisbury/lp1116835

Can you test that kernel and report back if it has the bug or not.

Thanks in advance!

The issue still occured in the test build with the patches.

Thanks for testing, Timothy. I reported the results of your testing upstream. It would be helpful if you could get a screen capture or digital picture of the panic and post it to the bug.

Thanks again for all your help.

The issue occurs before the bios loads. There is no text on the screen, simply a blank screen until I cut off all power to the PSU.

Hi Timothy,

I received another patch from upstream. I'm building a new test kernel now.

The patch author is interested in the I/O resource of PC in which the problem has occurred, He requested the result of 'cat /proc/iomem'. The sp5100_tco driver does not have to be loaded when you run'cat /proc/iomem'.

I will post a link to the new test kernel shortly.

I built a Raring test kernel with a new patch[0] from upstream applied.

The test kernel can be downloaded from:
http://people.canonical.com/~jsalisbury/lp1116835

Can you test that kernel and report back if it has the bug or not.

Thanks in advance!

[0] http://lkml.org/lkml/2013/2/18/353

The latest test build resolves the issue as expected.

The upstream commit that introduced this regression will be revered upstream:
https://lkml.org/lkml/2013/2/23/10

Timothy G. Rundle,

could you please test the latest kernel in -updates (3.8.0-19.30) and
see if this bug is still reproducible? Thanks.

Should be fixed in 3.8.5-stable with

commit 18e4321276fcf083b85b788fee7cf15be29ed72a
Author: Takahisa Tanaka <email address hidden>
Date: Sun Mar 3 14:52:07 2013 +0900

    watchdog: sp5100_tco: Remove code that may cause a boot failure

Looks good. I rebooted and powered off/on a couple times without issue after performing the following:

timothy@thomas:~$ uname -a
Linux thomas 3.8.0-19-generic #30-Ubuntu SMP Wed May 1 16:35:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

timothy@thomas:~$ sudo vi /etc/modprobe.d/blacklist-watchdog.conf

timothy@thomas:~$ grep sp5100 /etc/modprobe.d/blacklist-watchdog.conf
#blacklist sp5100_tco

 sudo update-initramfs -u

timothy@thomas:~$ sudo update-initramfs -u
[sudo] password for timothy:
update-initramfs: Generating /boot/initrd.img-3.8.0-19-generic

Here are the dmesg entries:

timothy@thomas:~$ dmesg |grep sp5100
[ 20.505566] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05
[ 20.505612] sp5100_tco: PCI Revision ID: 0x3a
[ 20.505629] sp5100_tco: failed to find MMIO address, giving up.