Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 617906 - irqpoll as kernel parameter makes the kernel freeze after initializing lockdep code
irqpoll as kernel parameter makes the kernel freeze after initializing lockde...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
14
i686 Linux
high Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-24 15:33 EDT by Jasper O'neal Hartline
Modified: 2012-08-16 12:41 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-16 12:41:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jasper O'neal Hartline 2010-07-24 15:33:29 EDT
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 16:12:09 EDT
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 16:28:35 EDT
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 13:28:51 EDT
Raising priority.  irqpoll is often a required parameter to boot the kdump kernel
Comment 4 Chuck Ebbert 2010-07-25 17:38:40 EDT
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-25 20:33:39 EDT
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-25 20:35:16 EDT
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 06:36:42 EDT
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 16:41:56 EDT
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 09:07:04 EDT
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 08:49:16 EDT
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 15:47:51 EDT
(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 18:46:10 EDT
I ran cvs -d:pserver:anonymous@cvs.fedoraproject.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 19:14:12 EDT
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 15:10:37 EDT
Does this still happen on a current f14 or f15 kernel?
Comment 15 Fedora End Of Life 2012-08-16 12:41:13 EDT
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

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