Bug 617906

Summary: irqpoll as kernel parameter makes the kernel freeze after initializing lockdep code
Product: [Fedora] Fedora Reporter: Jasper O'neal Hartline <Jasper.Hartline>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 14CC: anton, david.r, dougsland, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, nhorman
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-16 16:41:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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):
kernel-2.6.35-0.55.rc6.git0.fc13.i686

How reproducible:
Use irqpoll as a kernel parameter.

Steps to Reproduce:
1. use irqpoll
2. 
3.
  
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.
 #2
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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.org:/cvs/pkgs co kernel
Then:
[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 
Then:
[root@localhost vanilla-2.6.35-rc6-git1]# cat .config | grep LOCKDEP
CONFIG_LOCKDEP_SUPPORT=y
[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
http://fedoraproject.org/wiki/Docs/CustomKernel

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping