Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 455356 - sys-kernel/gentoo-sources-3.6.11 panic in smp.c
Summary: sys-kernel/gentoo-sources-3.6.11 panic in smp.c
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Gentoo Kernel Bug Wranglers and Kernel Maintainers
Depends on:
Reported: 2013-02-03 22:00 UTC by Nick Leippe
Modified: 2013-10-14 17:37 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Nick Leippe 2013-02-03 22:00:19 UTC
Kernel panic on boot. 3.5.7 does not have this problem.

This describes the problem I'm seeing and has a patch that may fix it:

The hardware I believe to be involved is my PCIe ssd card, which uses a PCI bridge chip to expose the devices behind it.

The code in the section that the above patch addresses has changed significantly between 3.5.7 and 3.6.11 leading me to believe the patch is relevant.

Reproducible: Always

Steps to Reproduce:
1. build 3.6.11 with same .config as 3.5.7
2. install new kernel
3. boot new kernel

Actual Results:  
kernel panic

Expected Results:  
no kernel panic--successful boot.

------------[ cut here ]------------
WARNING: at arch/x86/kernel/smp.c:123 update_process_times+0x65/0x80()
Hardware name: To Be Filled By O.E.M.
Modules linked in:
Pid: 1, comm: swapper/0 Not tainted 3.6.11-gentoo #2
Call Trace:
 <IRQ>  [<ffffffff8106f4fb>] ? warn_slowpath_common+0x7b/0xc0
 [<ffffffff810a7c90>] ? tick_nohz_handler+0xd0/0xd0
 [<ffffffff8107c9a5>] ? update_process_times+0x65/0x80
 [<ffffffff810a7d03>] ? tick_sched_timer+0x73/0xc0
 [<ffffffff8108fbde>] ? __run_hrtimer.irsa.32+0x4e/0xe0
 [<ffffffff810903e4>] ? hrtimer_interrupt+0xf4/0x260
 [<ffffffff8105cca3>] ? smp_apic_timer_interrupt+0x63/0xa0
 [<ffffffff815e6fc7>] ? apic_timer_interrupt+0x67/0x70
 <EOI>  [<ffffffff815dde18>] ? panic+0x181/0x1b8
 [<ffffffff8184ce61>] ? mount_block_root+0x1d3/0x279
 [<ffffffff81002933>] ? kvm_free_physmem+0x43/0x50
 [<ffffffff8184d22a>] ? prepare_namespace+0x15d/0x193
 [<ffffffff8184cbea>] ? kernel_init+0x17b/0x180
 [<ffffffff8184c568>] ? do_early_param+0x7d/0x7d
 [<ffffffff815e75b4>] ? kernel_thread_helper+0x4/0x10
 [<ffffffff8184ca6f>] ? start_kernel+0x2c9/0x2c9
 [<ffffffff815e75b0>] ? gs_change+0xb/0xb
---[ end trace 1c5cf32b598c7985 ]---
Comment 1 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-02-03 22:52:48 UTC
Please don't change the importance, the maintainers will change this if needed.

> This describes the problem I'm seeing and has a patch that may fix it

Your stack trace is different, can you try to apply the patch to confirm?
Comment 2 Mike Pagano gentoo-dev 2013-03-04 22:40:25 UTC
Maybe even test newer kernels to see if this issue replicates.
Comment 3 Nick Leippe 2013-09-17 19:28:24 UTC
Still up through 3.10.x this is not fixed. I'm still running 3.5.7--it's the only kernel I've been able to boot.
Comment 4 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-09-17 21:01:50 UTC
> [<ffffffff8184ce61>] ? mount_block_root+0x1d3/0x279

Didn't spot this first time, this seems to indicate that you are not building in your hard drive controller (eg. SATA) into the kernel, not have built your file system into the kernel (eg. EXT4), are missing an initramfs in case of some kind of RAID or CRYPT solution or so, perhaps haven't enabled CONFIG_TMPFS or CONFIG_DEVTMPFS or are missing the root= parameter on the kernel command line.

Could you please verify everything needed to be able to mount /root is in place?
Comment 5 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-10-14 17:37:54 UTC
(In reply to Tom Wijsman (TomWij) from comment #4)
> Could you please verify everything needed to be able to mount /root is in
> place?