| Summary: | [abrt] kernel: BUG: scheduling while atomic: evolution-addre/1414/0x00000002 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nicolas Mailhot <nicolas.mailhot> | ||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 19 | CC: | gansalmon, itamar, jforbes, jonathan, kernel-maint, madhu.chinakonda, sgruszka, wielkipiec | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | abrt_hash:30b13f131d59c494be90eec93180ec02610fbdaa | ||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2013-04-08 14:55:34 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
Nicolas Mailhot
2012-02-24 14:39:53 UTC
*** Bug 797201 has been marked as a duplicate of this bug. *** *** Bug 797199 has been marked as a duplicate of this bug. *** Your machine has an amazing ability to think it's in atomic context when it does a coredump: https://bugzilla.redhat.com/show_bug.cgi?id=766262 https://bugzilla.redhat.com/show_bug.cgi?id=783371 It doesn't have interrupts disabled, so in_atomic returning non-zero is what is causing this. In this case, the preempt_count is 2. Why that is, I have no idea. We don't build preempt kernels, so that will need some digging. Also, your machine has debug_locks = 0, which means lockdep has been disabled. Was there something else that happened on this machine that would have disabled them, or did you disable them yourself? (In reply to comment #3) > Also, your machine has debug_locks = 0, which means lockdep has been disabled. > Was there something else that happened on this machine that would have disabled > them, or did you disable them yourself? It's because of: (reported many times, in bug #662384 for example ; I've stopped filling bugzilla with duplicates but the end result is that I run with lockdep off all the time. I'm probably one of the few rawhide users that do this, so it wouldn't be surprising I hit bugs no one else does) [ 66.565017] ============================================= [ 66.565017] [ INFO: possible recursive locking detected ] [ 66.565017] 3.3.0-0.rc4.git3.1.fc18.x86_64 #1 Not tainted [ 66.565017] --------------------------------------------- [ 66.565017] udevd/464 is trying to acquire lock: [ 66.565017] (&hdl->lock){+.+...}, at: [<ffffffffa02a87e7>] find_ref_lock+0x27/0x60 [videodev] [ 66.565017] [ 66.565017] but task is already holding lock: [ 66.565017] (&hdl->lock){+.+...}, at: [<ffffffffa02ab339>] v4l2_ctrl_add_handler+0x79/0xc0 [videodev] [ 66.565017] [ 66.565017] other info that might help us debug this: [ 66.565017] Possible unsafe locking scenario: [ 66.565017] [ 66.565017] CPU0 [ 66.565017] ---- [ 66.565017] lock(&hdl->lock); [ 66.565017] lock(&hdl->lock); [ 66.565017] [ 66.565017] *** DEADLOCK *** [ 66.565017] [ 66.565017] May be due to missing lock nesting notation [ 66.565017] [ 66.565017] 3 locks held by udevd/464: [ 66.565017] #0: (&__lockdep_no_validate__){......}, at: [<ffffffff8141258b>] __driver_attach+0x5b/0xb0 [ 66.565017] #1: (&__lockdep_no_validate__){......}, at: [<ffffffff81412599>] __driver_attach+0x69/0xb0 [ 66.605544] #2: (&hdl->lock){+.+...}, at: [<ffffffffa02ab339>] v4l2_ctrl_add_handler+0x79/0xc0 [videodev] [ 66.605544] [ 66.605544] [ 66.605544] stack backtrace: [ 66.605544] Pid: 464, comm: udevd Not tainted 3.3.0-0.rc4.git3.1.fc18.x86_64 #1 [ 66.605544] Call Trace: [ 66.605544] [<ffffffff810cc20f>] __lock_acquire+0x168f/0x1bb0 [ 66.605544] [<ffffffff810cce01>] lock_acquire+0xa1/0x1e0 [ 66.605544] [<ffffffffa02a87e7>] ? find_ref_lock+0x27/0x60 [videodev] [ 66.605544] [<ffffffff8169a896>] mutex_lock_nested+0x76/0x3a0 [ 66.605544] [<ffffffffa02a87e7>] ? find_ref_lock+0x27/0x60 [videodev] [ 66.605544] [<ffffffffa02ab339>] ? v4l2_ctrl_add_handler+0x79/0xc0 [videodev] [ 66.605544] [<ffffffffa02a87e7>] ? find_ref_lock+0x27/0x60 [videodev] [ 66.605544] [<ffffffff810cd99d>] ? trace_hardirqs_on_caller+0x10d/0x1a0 [ 66.605544] [<ffffffffa02a87e7>] find_ref_lock+0x27/0x60 [videodev] [ 66.605544] [<ffffffffa02aaa91>] handler_new_ref+0x51/0x200 [videodev] [ 66.605544] [<ffffffffa02ab35f>] v4l2_ctrl_add_handler+0x9f/0xc0 [videodev] [ 66.605544] [<ffffffffa02a5a02>] v4l2_device_register_subdev+0xd2/0x2d0 [videodev] [ 66.605544] [<ffffffffa0316cae>] ivtv_gpio_init+0x14e/0x190 [ivtv] [ 66.605544] [<ffffffffa03281b0>] ivtv_probe+0xfb7/0x1958 [ivtv] [ 66.605544] [<ffffffff810c764d>] ? trace_hardirqs_off+0xd/0x10 [ 66.605544] [<ffffffff810a30cf>] ? local_clock+0x6f/0x80 [ 66.605544] [<ffffffff8169e83f>] ? _raw_spin_unlock_irqrestore+0x3f/0x80 [ 66.605544] [<ffffffff810cd99d>] ? trace_hardirqs_on_caller+0x10d/0x1a0 [ 66.605544] [<ffffffff810cda3d>] ? trace_hardirqs_on+0xd/0x10 [ 66.605544] [<ffffffff8134ae1c>] local_pci_probe+0x5c/0xd0 [ 66.605544] [<ffffffff8134afa1>] pci_device_probe+0x111/0x120 [ 66.605544] [<ffffffff814122d6>] driver_probe_device+0x96/0x2f0 [ 66.605544] [<ffffffff814125db>] __driver_attach+0xab/0xb0 [ 66.605544] [<ffffffff81412530>] ? driver_probe_device+0x2f0/0x2f0 [ 66.605544] [<ffffffff814104d5>] bus_for_each_dev+0x55/0x90 [ 66.605544] [<ffffffffa033c000>] ? 0xffffffffa033bfff [ 66.605544] [<ffffffff81411dbe>] driver_attach+0x1e/0x20 [ 66.605544] [<ffffffff81411ac8>] bus_add_driver+0x1b8/0x2b0 [ 66.605544] [<ffffffffa033c000>] ? 0xffffffffa033bfff [ 66.605544] [<ffffffff81412db7>] driver_register+0x77/0x160 [ 66.605544] [<ffffffffa033c000>] ? 0xffffffffa033bfff [ 66.605544] [<ffffffff81349bf3>] __pci_register_driver+0x73/0xf0 [ 66.605544] [<ffffffffa033c000>] ? 0xffffffffa033bfff [ 66.605544] [<ffffffffa033c078>] module_start+0x78/0x1000 [ivtv] [ 66.605544] [<ffffffff8100212a>] do_one_initcall+0x12a/0x180 [ 66.605544] [<ffffffff810db166>] sys_init_module+0x1146/0x2260 [ 66.605544] [<ffffffff816a74e9>] system_call_fastpath+0x16/0x1b OK, that at least explains why the lockdep stuff is off. I still have no idea why your preempt_count is 2 though. Can you attach the full dmesg for this boot, just to see if it gleans some more data? Created attachment 565665 [details]
dmesg
Occurs each time after logging in to graphical session via GDM3. ABRT informs about "error in package 'kernel'". Oddly, happens more seldom, when laptop is connected to AC Source, which has nothing to do with the "bug" itself. Lenovo ThinkPad R61i 8932-AEG, smolt enclosed. Package: kernel OS Release: Fedora release 18 (Rawhide) This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19 Is this still a problem with 3.9 based F19 kernels? Haven't got this one lately but then my evo use is episodic at best
The current kernel warning is
[ 40.188806] =============================================
[ 40.188809] [ INFO: possible recursive locking detected ]
[ 40.188814] 3.9.0-0.rc5.git3.1.fc20.x86_64 #1 Tainted: GF
[ 40.188818] ---------------------------------------------
[ 40.188821] systemd-udevd/373 is trying to acquire lock:
[ 40.188825] (hdl->lock){+.+...}, at: [<ffffffffa035e7b5>] find_ref_lock+0x25/0x60 [videodev]
[ 40.188839]
but task is already holding lock:
[ 40.188844] (hdl->lock){+.+...}, at: [<ffffffffa0361b38>] v4l2_ctrl_add_handler+0x78/0xf0 [videodev]
[ 40.188854]
other info that might help us debug this:
[ 40.188859] Possible unsafe locking scenario:
[ 40.188863] CPU0
[ 40.188865] ----
[ 40.188867] lock(hdl->lock);
[ 40.188871] lock(hdl->lock);
[ 40.188875]
*** DEADLOCK ***
[ 40.188880] May be due to missing lock nesting notation
[ 40.188885] 3 locks held by systemd-udevd/373:
[ 40.188888] #0: (&__lockdep_no_validate__){......}, at: [<ffffffff814709cb>] __driver_attach+0x4b/0xa0
[ 40.188899] #1: (&__lockdep_no_validate__){......}, at: [<ffffffff814709d9>] __driver_attach+0x59/0xa0
[ 40.188908] #2: (hdl->lock){+.+...}, at: [<ffffffffa0361b38>] v4l2_ctrl_add_handler+0x78/0xf0 [videodev]
[ 40.188919]
stack backtrace:
[ 40.188923] Pid: 373, comm: systemd-udevd Tainted: GF 3.9.0-0.rc5.git3.1.fc20.x86_64 #1
[ 40.188928] Call Trace:
[ 40.188934] [<ffffffff810da276>] __lock_acquire+0x1756/0x1a60
[ 40.188941] [<ffffffff810acd08>] ? sched_clock_cpu+0xa8/0x100
[ 40.188946] [<ffffffff810dad32>] lock_acquire+0xa2/0x1f0
[ 40.188953] [<ffffffffa035e7b5>] ? find_ref_lock+0x25/0x60 [videodev]
[ 40.188959] [<ffffffff81715a50>] mutex_lock_nested+0x80/0x3c0
[ 40.188966] [<ffffffffa035e7b5>] ? find_ref_lock+0x25/0x60 [videodev]
[ 40.188973] [<ffffffffa035e7b5>] ? find_ref_lock+0x25/0x60 [videodev]
[ 40.188978] [<ffffffff810d873d>] ? trace_hardirqs_on_caller+0xfd/0x190
[ 40.188985] [<ffffffffa035e7b5>] find_ref_lock+0x25/0x60 [videodev]
[ 40.188992] [<ffffffffa0360ff6>] handler_new_ref+0x46/0x1f0 [videodev]
[ 40.188999] [<ffffffffa0361b77>] v4l2_ctrl_add_handler+0xb7/0xf0 [videodev]
[ 40.189006] [<ffffffffa035b636>] v4l2_device_register_subdev+0xb6/0x160 [videodev]
[ 40.189007] [<ffffffffa0389a5e>] ivtv_gpio_init+0x13e/0x180 [ivtv]
[ 40.189007] [<ffffffffa0384cb4>] ivtv_probe+0x914/0x1bf0 [ivtv]
[ 40.189007] [<ffffffff810d509d>] ? trace_hardirqs_off+0xd/0x10
[ 40.189007] [<ffffffff810ace4f>] ? local_clock+0x5f/0x70
[ 40.189007] [<ffffffff81719046>] ? _raw_spin_unlock_irqrestore+0x36/0x70
[ 40.189007] [<ffffffff810d87dd>] ? trace_hardirqs_on+0xd/0x10
[ 40.189007] [<ffffffff8138e1ce>] local_pci_probe+0x3e/0x70
[ 40.189007] [<ffffffff8138f4d1>] pci_device_probe+0x111/0x120
[ 40.189007] [<ffffffff81470637>] driver_probe_device+0x87/0x390
[ 40.189007] [<ffffffff81470a13>] __driver_attach+0x93/0xa0
[ 40.189007] [<ffffffff81470980>] ? __device_attach+0x40/0x40
[ 40.189007] [<ffffffff8146e593>] bus_for_each_dev+0x63/0xa0
[ 40.189007] [<ffffffff8147008e>] driver_attach+0x1e/0x20
[ 40.189007] [<ffffffff8146fc10>] bus_add_driver+0x1f0/0x2b0
[ 40.189007] [<ffffffffa03ae000>] ? 0xffffffffa03adfff
[ 40.189007] [<ffffffff81471091>] driver_register+0x71/0x150
[ 40.189007] [<ffffffffa03ae000>] ? 0xffffffffa03adfff
[ 40.189007] [<ffffffff8138e060>] __pci_register_driver+0x60/0x70
[ 40.189007] [<ffffffffa03ae079>] module_start+0x79/0x1000 [ivtv]
[ 40.189007] [<ffffffff8100210a>] do_one_initcall+0x10a/0x160
[ 40.189007] [<ffffffff810e94ed>] load_module+0x1ead/0x2870
[ 40.189007] [<ffffffff8137cd20>] ? ddebug_proc_write+0xf0/0xf0
[ 40.189007] [<ffffffff810e9f71>] sys_init_module+0xc1/0x110
[ 40.189007] [<ffffffff81722c99>] system_call_fastpath+0x16/0x1b
No idea what Tainted: GF means, I run without out of tree drivers
(but this last message seems to be the continuation of bug #879843) Okay, closing out this bug, we can track the other issue in 879843 then. Feel free to reopen if the original issue resurfaces. |