Bug 617906 - irqpoll as kernel parameter makes the kernel freeze after initializing lockdep code
Summary: irqpoll as kernel parameter makes the kernel freeze after initializing lockde...
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 14
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-24 19:33 UTC by Jasper O'neal Hartline
Modified: 2012-08-16 16:41 UTC (History)
9 users (show)

Clone Of:
Last Closed: 2012-08-16 16:41:10 UTC

Attachments (Terms of Use)

Description Jasper O'neal Hartline 2010-07-24 19:33:29 UTC
Description of problem:
irqpoll as kernel parameter makes the kernel freeze after initializing lockdep code

Version-Release number of selected component (if applicable):

How reproducible:
Use irqpoll as a kernel parameter.

Steps to Reproduce:
1. use irqpoll
Actual results:
title Fedora (2.6.35-0.55.rc6.git0.fc13.i686)
        root (hd0,1)
        kernel /boot/vmlinuz-2.6.35-0.55.rc6.git0.fc13.i686 ro root=UUID=4a6fb4da-0786-41a3-bcfd-f70aa81ba15b SYSFONT=latarcyrheb-sun16 resume=/dev/sda2 resume_offset=15794690 selinux=0 vmalloc=256M irqpoll elevator=deadline clocksource=hpet panic=0 3 LANG=en_US.UTF-8 KEYTABLE=us
        initrd /boot/initramfs-2.6.35-0.55.rc6.git0.fc13.i686.img

Freezes kernel in lockdep code
Expected results:
Shouldn't freeze.

Additional info:

Comment 1 David Riches 2010-07-24 20:12:09 UTC
Same here, although this isn't a stock F13 kernel, this really needs checking against rawhide.

My only addition to the boot line was irqpoll , complete freeze just after lockdep.

kernel /vmlinuz-2.6.35-0.55.rc6.git0.fc13.i686 ro root=/dev/mapper/vg_drlaptop-lv_root rd_LVM_LV=vg_drlaptop/lv_root rd_LVM_LV=vg_drlaptop/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=uk irqpoll

Comment 2 Jasper O'neal Hartline 2010-07-24 20:28:35 UTC
It is filed against RAWHIDE. The fc13 tag is just it's current tag in RAWHIDE
but it is RAWHIDe, nonetheless.

Comment 3 Neil Horman 2010-07-25 17:28:51 UTC
Raising priority.  irqpoll is often a required parameter to boot the kdump kernel

Comment 4 Chuck Ebbert 2010-07-25 21:38:40 UTC
Can you try adding "lock_stat=0" and/or "prove_locking=0" to the boot options and see if that lets it continue? That should help us see if lockdep is causing this problem.

Comment 5 Jasper O'neal Hartline 2010-07-26 00:33:39 UTC
Adding lock_stat=0 irqpoll still resulted in the kernel becoming frozen.
Adding lock_stat=0 prove_locking=0 irqpoll resulted in the above. (frozen)
Adding prove_locking irqpoll resulted in the kernel being frozen.

The last lines echoed to the screen before it becomes frozen are:

memory used by lock dependency info: 3823 KB
per task-sctruct memory footprint: 1920 bytes

Comment 6 Jasper O'neal Hartline 2010-07-26 00:35:16 UTC
Please ignore the typo on prove_locking in line 3 in Comment 5
The results were the same, a frozen kernel using the correct options.

Comment 7 Jasper O'neal Hartline 2010-07-27 10:36:42 UTC
I also got this in dmesg when booting without irqpoll:

Enabling APIC mode:  Flat.  Using 1 I/O APICs
..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1
CPU0: Dual Core AMD Opteron(tm) Processor 270 stepping 02
lockdep: fixing up alternatives.

[ INFO: suspicious rcu_dereference_check() usage. ]
kernel/sched.c:616 invoked rcu_dereference_check() without protection!

other info that might help us debug this:

rcu_scheduler_active = 1, debug_locks = 0
3 locks held by swapper/1:
 #0:  (cpu_add_remove_lock){+.+.+.}, at: [<c043c5fb>] cpu_maps_update_begin+0x14/0x16
 #1:  (cpu_hotplug.lock){+.+.+.}, at: [<c043c633>] cpu_hotplug_begin+0x22/0x45
 #2:  (&rq->lock){-.....}, at: [<c07cd066>] init_idle+0x25/0x98

stack backtrace:
Pid: 1, comm: swapper Not tainted 2.6.35-0.55.rc6.git0.fc13.i686 #1
Call Trace:
 [<c07cf1c4>] ? printk+0x25/0x29
 [<c04604cd>] lockdep_rcu_dereference+0x7d/0x86
 [<c042cb23>] task_group+0x72/0x7e
 [<c042cb42>] set_task_rq+0x13/0x5c
 [<c07cd0a6>] init_idle+0x65/0x98
 [<c07cd408>] fork_idle+0x9d/0xa6
 [<c07cc1b9>] do_fork_idle+0x13/0x21
 [<c07cb6df>] do_boot_cpu+0x113/0x8eb
 [<c0499dba>] ? kzalloc_node.clone.0+0xd/0xf
 [<c07cc1a6>] ? do_fork_idle+0x0/0x21
 [<c07cbfc7>] native_cpu_up+0x110/0x1ef
 [<c07cd4c1>] _cpu_up+0x85/0xed
 [<c07cd575>] cpu_up+0x4c/0x5c
 [<c0a5831c>] kernel_init+0xc1/0x23a
 [<c0a5825b>] ? kernel_init+0x0/0x23a
 [<c0403a02>] kernel_thread_helper+0x6/0x10
Booting Node   0, Processors  #1
Initializing CPU#1
lockdep: fixing up alternatives.
Initializing CPU#2
lockdep: fixing up alternatives.
 #3 Ok.
Initializing CPU#3
Brought up 4 CPUs
Total of 4 processors activated (15998.59 BogoMIPS).

Comment 8 Chuck Ebbert 2010-07-27 20:41:56 UTC
Are we really sure that lockdep is causing this? Can someone build a rawhide kernel with only CONFIG_LOCKDEP disabled and try that with irqpoll?

Comment 9 Jasper O'neal Hartline 2010-07-28 13:07:04 UTC
I am trying to disable LOCKDEP in a kernel to get ready to compile it, but it keeps turning it's self back on. Have any suggestions on how to disable lockdep in this config before I compile this kernel?

It's like trying to wrestle with a bar of soap.

Comment 10 Bug Zapper 2010-07-30 12:49:16 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:

Comment 11 Dave Jones 2010-07-30 19:47:51 UTC
(In reply to comment #9)
> I am trying to disable LOCKDEP in a kernel to get ready to compile it, but it
> keeps turning it's self back on. Have any suggestions on how to disable lockdep
> in this config before I compile this kernel?

if you have a cvs checkout, you can 'make release' in devel/ and it'll turn off all the debugging options.
CONFIG_DEBUG_LOCK_ALLOC and CONFIG_PROVE_LOCKING should be the only ones that matter though.

Comment 12 Jasper O'neal Hartline 2010-07-30 22:46:10 UTC
I ran cvs -d:pserver:anonymous@cvs.fedoraproject.org:/cvs/pkgs co kernel
[root@localhost BUILD]# cd kernel/devel
[root@localhost devel]# make release
#@perl -pi -e 's/CONFIG_KGDB_KDB=y/# CONFIG_KGDB_KDB is not set/' config-nodebug
#@perl -pi -e 's/CONFIG_KDB_KEYBOARD=y/# CONFIG_KDB_KEYBOARD is not set/' config-nodebug
[root@localhost devel]#

[root@localhost devel]# for in in config*; do cat $i | grep LOCKDEP && echo $i; done
[root@localhost devel]# for in in config*; do cat $i | grep PROVE_LOCKING && echo $i; done
[root@localhost devel]#

[root@localhost devel]# cp config-x86-generic ../../kernel-2.6.34/vanilla-2.6.35-rc6-git1/.config
cp: overwrite `../../kernel-2.6.34/vanilla-2.6.35-rc6-git1/.config'? y
[root@localhost devel]#

make oldconfig asks me questions
It writes .config 
[root@localhost vanilla-2.6.35-rc6-git1]# cat .config | grep LOCKDEP
[root@localhost vanilla-2.6.35-rc6-git1]#

cat and grep on PROVE_LOCKING shows nothing.
Looks like I'm doing something wrong.

Comment 13 Chuck Ebbert 2010-08-03 23:14:12 UTC

It would be better if you just changed the CONFIG_LOCKDEP line by itself by editing config-nodebug.

Comment 14 Josh Boyer 2011-08-26 19:10:37 UTC
Does this still happen on a current f14 or f15 kernel?

Comment 15 Fedora End Of Life 2012-08-16 16:41:13 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Note You need to log in before you can comment on or make changes to this bug.