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: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 14 | CC: | 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
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 It is filed against RAWHIDE. The fc13 tag is just it's current tag in RAWHIDE but it is RAWHIDe, nonetheless. Raising priority. irqpoll is often a required parameter to boot the kdump kernel 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. 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 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. 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). 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? 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. 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 (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. 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. http://fedoraproject.org/wiki/Docs/CustomKernel It would be better if you just changed the CONFIG_LOCKDEP line by itself by editing config-nodebug. Does this still happen on a current f14 or f15 kernel? 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 |