Bug#758622: marked as done (kernel crashes after soft lockups in xen domU)
Your message dated Wed, 28 Apr 2021 18:39:58 +0200 with message-id and subject line Closing this bug has caused the Debian Bug report #758622, regarding kernel crashes after soft lockups in xen domU to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 758622: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758622 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:linux Version: 3.2.60-1+deb7u3 Severity: important Hello, I encounter kernel crashes on an up-to-date Debian/Wheezy Xen domU with the stock kernel. The dom0 runs the same linux kernel and xen/4.1.4-3+deb7u1. It seems like the crashes are related to a RT process, even though no sched_fifo/rr processes are started on this system intentionally. Also, the CPU usage is low all the time, no peaks at all. But the kernel reports: kernel: [39101.461586] sched: RT throttling activated Usually, a few minutes later, soft lockups start to happen, and then the system crashes: [36.127400] BUG: soft lockup - CPU#7 stuck for 22s! [/usr/share/webm:16190] [36.128652] Modules linked in: evdev coretemp crc32c_intel ghash_clmulni_intel snd_pcm snd_timer aesni_intel snd cryptd soundcore snd_page_alloc aes_x86_64 pcspkr aes_generic ext4 crc16 jbd2 mbcache dm_mod xen_netfront xen_blkfront [36.128679] CPU 7 [36.128680] Modules linked in: evdev coretemp crc32c_intel ghash_clmulni_intel snd_pcm snd_timer aesni_intel snd cryptd soundcore snd_page_alloc aes_x86_64 pcspkr aes_generic ext4 crc16 jbd2 mbcache dm_mod xen_netfront xen_blkfront [36.128701] [36.128704] Pid: 16190, comm: /usr/share/webm Not tainted 3.2.0-4-amd64 #1 Debian 3.2.60-1+deb7u3 [36.128711] RIP: e030:[] [] hypercall_page+0x22a/0x1000 [36.128720] RSP: e02b:8801c4b8dc00 EFLAGS: 0246 [36.128724] RAX: 00040001 RBX: 88020280 RCX: 8100122a [36.128728] RDX: RSI: RDI: [36.128733] RBP: 000e R08: 0200 R09: dead00100100 [36.128737] R10: dead00200200 R11: 0246 R12: 8800b4f53da0 [36.128741] R13: 8802be00 R14: ea0001e526d0 R15: 000d [36.128749] FS: 7f1a46e3a700() GS:8802ffdc() knlGS: [36.128754] CS: e033 DS: ES: CR0: 8005003b [36.128758] CR2: 7fcbe7683000 CR3: 0001bcba5000 CR4: 2660 [36.128762] DR0: DR1: DR2: [36.128767] DR3: DR6: 0ff0 DR7: 0400 [36.128771] Process /usr/share/webm (pid: 16190, threadinfo 8801c4b8c000, task 8801d175b0c0) [36.128776] Stack: [36.128779] 0200 81006790 81006d22 [36.128786] dead00200200 dead00100100 0200 [36.128792] 88020280 88020280 0200 [36.130901] Call Trace: [36.130908] [] ? xen_force_evtchn_callback+0x9/0xa [36.130914] [] ? check_events+0x12/0x20 [36.130919] [] ? xen_restore_fl_direct_reloc+0x4/0x4 [36.130925] [] ? arch_local_irq_restore+0x7/0x8 [36.130932] [] ? _raw_spin_unlock_irqrestore+0xe/0xf [36.130939] [] ? release_pages+0x9d/0x14d [36.130945] [] ? free_pages_and_swap_cache+0x48/0x60 [36.130951] [] ? tlb_flush_mmu+0x37/0x50 [36.130956] [] ? tlb_finish_mmu+0xc/0x31 [36.130961] [] ? exit_mmap+0xc4/0xe9 [36.130967] [] ? mmput+0x56/0xf8 [36.130971] [] ? exit_mm+0x117/0x122 [36.130975] [] ? arch_local_irq_disable+0x7/0x8 [36.130980] [] ? _raw_spin_lock_irq+0xa/0x14 [36.130984] [] ? arch_local_irq_disable+0x7/0x8 [36.130988] [] ? do_exit+0x245/0x713 [36.130993] [] ? error_exit+0x2a/0x60 [36.130999] [] ? fsnotify_find_inode_mark_locked+0x16/0x47 [36.131004] [] ? fsnotify_find_inode_mark+0x21/0x2c [36.131009] [] ? do_group_exit+0x74/0x9e [36.131013] [] ? sys_exit_group+0xf/0xf [36.131018] [] ? system_call_fastpath+0x16/0x1b [36.131021] Code: cc 51 41 53 b8 10 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 11 00 00 00 0f 05 <41> 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc [36.131061] Call Trace: [36.131065] [] ? xen_force_evtchn_callback+0x9/0xa [36.131070] [] ? check_events+0x12/0x20 [36.131075] [] ? xen_restore_fl_direct_reloc+0x4/0x4 [36.131079] [] ? arch_local_irq_restore+0
Re: kernel crashes after soft lockups in xen domU
reassign 758622 linux-image-3.16.0-4-amd64 thanks Hi Ben, thanks for your response. Am 2014-11-05 21:40, schrieb Ben Hutchings: On Wed, 2014-11-05 at 17:56 +0100, Jonas Meurer wrote: [...] So the question is: why does the VM run stable on xen1 while it crashes all the time on xen2. If I compare xen1 and xen2, only real difference is mainboard (Supermicro X8 on xen1; Supermicro X9 on xen2) and CPU (Xeon L5939 on xen1; E5-2609 on xen2) As a next step I'll put the harddisks into another X8/Xeon L5639 server system and try to reproduce the crashes there. My bet is that this system will not crash anymore. In other words, I guess that this very bug is only triggered with the X9 + E-2609 combination. Can I do anything additional to help debugging the bug? Shall I report it to Xen upstream or send it to lkml? Still the same question. Shall I send the bugreport to upstream? Unfortunately nobody from Debian Linux kernel and/or Xen team seems to care :-/ [...] Sorry you haven't had a response from us so far. This seems to be fairly clearly a Linux/Xen interaction and I don't know enough about Xen to suggest how to debug it. As it involves a relatively old kernel version, I don't think Linux upstream developers will want to hear about this unless you can also reproduce it with a more recent version. Linux 3.16 is available (in testing and wheezy-backports) if you would like to try that. I tried linux-image-3.16 from wheezy-backports as VM kernel in the meantime. Sorry to report back that the bug is still reproducible with this kernel. I'm reassigning it to the jessie kernel for that reason. The kernel backtrace was slightly different, but the behaviour was the same: After putting the webserver on test VM under heavy load with siege and pylot, the load exploded until the machine crashed. Now I replaced the hardware again with a Supermicro S8 board and a Intel Xeon L5639 CPU - and you know what: the bug disappeared. I'll have to put the system back into production mode now, so further debugging will be complicated. To sum up the situation: - a setup with Debian Wheezy Dom0 and Debian Wheezy or Jessie VM - the VM runs an apache webserver with mysql backend, nothing more - the VM crashes under load if Dom0 CPU is Intel Xeon E5-2609 - the VM doesn't crash under load if Dom0 CPU is Intel Xeon 5639 - tested on four completely different hardware setups, all components except harddisks replaced several times Kind regards, jonas -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0c5360de19b1627cd9d7448973e7e...@imap.steindlberger.de
Processed: Re: kernel crashes after soft lockups in xen domU
Processing commands for cont...@bugs.debian.org: reassign 758622 linux-image-3.16.0-4-amd64 Bug #758622 [src:linux] kernel crashes after soft lockups in xen domU Bug reassigned from package 'src:linux' to 'linux-image-3.16.0-4-amd64'. No longer marked as found in versions linux/3.2.60-1+deb7u3. Ignoring request to alter fixed versions of bug #758622 to the same values previously set thanks Stopping processing here. Please contact me if you need assistance. -- 758622: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758622 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.14158061223245.transcr...@bugs.debian.org
Re: kernel crashes after soft lockups in xen domU
On Wed, 2014-11-12 at 16:28 +0100, Jonas Meurer wrote: - the VM crashes under load if Dom0 CPU is Intel Xeon E5-2609 - the VM doesn't crash under load if Dom0 CPU is Intel Xeon 5639 Someone just suggested to me (by their own admission on a hunch) that a microcode update might help with this sort of issue. That probably means updating to the latest BIOS as a first step (which will probably include a microcode update), then if that doesn't help messing around with the runtime microcode update tools (since there will undoubtedly be something newer than what the BIOS contains). Ian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415811872.1155.27.ca...@hellion.org.uk
Re: kernel crashes after soft lockups in xen domU
And some more information ... Am 2014-10-13 12:04, schrieb Jonas Meurer: Am 2014-08-19 12:26, schrieb Jonas Meurer: I encounter kernel crashes on an up-to-date Debian/Wheezy Xen domU with the stock kernel. The dom0 runs the same linux kernel and xen/4.1.4-3+deb7u1. the bug is still reproducible with the latest kernel and Xen packages from Debian Wheezy. Unfortunately it seems like a corner case, somehow related to the hardware setup. I'm unable to reproduce the crash on another Xen system with same kernel an Xen versions but different CPU and motherboard. The VM runs in production mode on the second Xen system since several weeks without one single crash. I've got a test system now where I'm able to reproduce the bug by putting the VM (a webserver) under heavy load with the help of siege and pylot. The VM crashes every time I put the webserver under heavy load, everytime with the same backtrace. I replaced the full system (all hardware components except the harddisks) with a new one in the meantime - and still the bug is repoducible. I'll try to describe the setup: Two Xen virtualization servers (xen1 and xen2), mirroring one block device with DRBD using a primary/secondary setup. The DRBD device holds LVM with the LVs for one single virtual machine (the webserver). This webserver runs an Apache2 daemon. The first virtualization server (xen1, the one that's live) runs rock stable, same for the webserver VM on top. No crashes, no exploding load. The second virtualization server (xen2) runs well as long as it's only secondary (i.e. no virtual machine started). As soon as I switch the DRBD primary to xen2 and start the webserver VM there, load on the webserver is unusual high, it becomes laggy and after some hours (sometimes minutes) it crashes like described in earlier mails. Now I created a test-VM on xen2 that is not on top of the DRBD device in order to factor out DRBD as reason. As already written, if I fire some HTTP requests against the Apache daemon on the test-VM, the VM crashes the same way. I first replaced memory modules and CPU by similar ones without results. Now I replaced the whole hardware (except harddisks) by another one - still the same crashes. So the question is: why does the VM run stable on xen1 while it crashes all the time on xen2. If I compare xen1 and xen2, only real difference is mainboard (Supermicro X8 on xen1; Supermicro X9 on xen2) and CPU (Xeon L5939 on xen1; E5-2609 on xen2) As a next step I'll put the harddisks into another X8/Xeon L5639 server system and try to reproduce the crashes there. My bet is that this system will not crash anymore. In other words, I guess that this very bug is only triggered with the X9 + E-2609 combination. Can I do anything additional to help debugging the bug? Shall I report it to Xen upstream or send it to lkml? Still the same question. Shall I send the bugreport to upstream? Unfortunately nobody from Debian Linux kernel and/or Xen team seems to care :-/ Cheers, jonas Regarding the hardware: the RAM was checked with memtest86+ and no errors found and the CPU has been replaced by a new one (same model). Still, the VM crash is reproducible. The hardware on the crashing system is: CPU: Intel Xeon E5-2609v2/4x2,5GHz Motherboard: Supermicro X9SRI-F For information, the hardware on non-crashing system is: CPU: Intel XEON L5639/6x2,13 GHz Motherboard: Supermicro X8STi It seems like the crashes are related to a RT process, even though no sched_fifo/rr processes are started on this system intentionally. Also, the CPU usage is low all the time, no peaks at all. But the kernel reports: kernel: [39101.461586] sched: RT throttling activated This is still valid, even though I no longer think that it's related to a RT process at all, as no sched_fifo/rr processes are started. Usually, a few minutes later, soft lockups start to happen, and then the system crashes: The backtrace is slightly different now due to kernel and Xen updates: [353013.384931] sched: RT throttling activated [354008.100835] BUG: soft lockup - CPU#5 stuck for 22s! [apache2:24848] [354008.100846] Modules linked in: evdev coretemp crc32c_intel ghash_clmulni_intel snd_pcm snd_page_alloc aesni_intel snd_timer aes_x86_64 snd aes_generic soundcore cryptd pcspkr ext4 crc16 jbd2 mbcache dm_mod xen_netfront xen_blkfront [354008.100872] CPU 5 [354008.100874] Modules linked in: evdev coretemp crc32c_intel ghash_clmulni_intel snd_pcm snd_page_alloc aesni_intel snd_timer aes_x86_64 snd aes_generic soundcore cryptd pcspkr ext4 crc16 jbd2 mbcache dm_mod xen_netfront xen_blkfront [354008.100894] [354008.100898] Pid: 24848, comm: apache2 Not tainted 3.2.0-4-amd64 #1 Debian 3.2.60-1+deb7u3 [354008.100904] RIP: e030:[8100122a] [8100122a] hypercall_page+0x22a/0x1000 [354008.100914] RSP: e02b:8802f0b41c00 EFLAGS: 0246 [354008.100918] RAX: 00040001 RBX: 88020200 RCX: 8100122a [354008.100922] RDX:
Re: kernel crashes after soft lockups in xen domU
On Wed, 2014-11-05 at 17:56 +0100, Jonas Meurer wrote: [...] So the question is: why does the VM run stable on xen1 while it crashes all the time on xen2. If I compare xen1 and xen2, only real difference is mainboard (Supermicro X8 on xen1; Supermicro X9 on xen2) and CPU (Xeon L5939 on xen1; E5-2609 on xen2) As a next step I'll put the harddisks into another X8/Xeon L5639 server system and try to reproduce the crashes there. My bet is that this system will not crash anymore. In other words, I guess that this very bug is only triggered with the X9 + E-2609 combination. Can I do anything additional to help debugging the bug? Shall I report it to Xen upstream or send it to lkml? Still the same question. Shall I send the bugreport to upstream? Unfortunately nobody from Debian Linux kernel and/or Xen team seems to care :-/ [...] Sorry you haven't had a response from us so far. This seems to be fairly clearly a Linux/Xen interaction and I don't know enough about Xen to suggest how to debug it. As it involves a relatively old kernel version, I don't think Linux upstream developers will want to hear about this unless you can also reproduce it with a more recent version. Linux 3.16 is available (in testing and wheezy-backports) if you would like to try that. I don't know whether the Xen upstream developers will accept a bug report against this version. Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong. signature.asc Description: This is a digitally signed message part
Bug#758622: kernel crashes after soft lockups in xen domU
Hey again, Am 2014-08-19 12:26, schrieb Jonas Meurer: I encounter kernel crashes on an up-to-date Debian/Wheezy Xen domU with the stock kernel. The dom0 runs the same linux kernel and xen/4.1.4-3+deb7u1. the bug is still reproducible with the latest kernel and Xen packages from Debian Wheezy. Unfortunately it seems like a corner case, somehow related to the hardware setup. I'm unable to reproduce the crash on another Xen system with same kernel an Xen versions but different CPU and motherboard. The VM runs in production mode on the second Xen system since several weeks without one single crash. I've got a test system now where I'm able to reproduce the bug by putting the VM (a webserver) under heavy load with the help of siege and pylot. The VM crashes every time I put the webserver under heavy load, everytime with the same backtrace. Can I do anything additional to help debugging the bug? Shall I report it to Xen upstream or send it to lkml? Regarding the hardware: the RAM was checked with memtest86+ and no errors found and the CPU has been replaced by a new one (same model). Still, the VM crash is reproducible. The hardware on the crashing system is: CPU: Intel Xeon E5-2609v2/4x2,5GHz Motherboard: Supermicro X9SRI-F For information, the hardware on non-crashing system is: CPU: Intel XEON L5639/6x2,13 GHz Motherboard: Supermicro X8STi It seems like the crashes are related to a RT process, even though no sched_fifo/rr processes are started on this system intentionally. Also, the CPU usage is low all the time, no peaks at all. But the kernel reports: kernel: [39101.461586] sched: RT throttling activated This is still valid, even though I no longer think that it's related to a RT process at all, as no sched_fifo/rr processes are started. Usually, a few minutes later, soft lockups start to happen, and then the system crashes: The backtrace is slightly different now due to kernel and Xen updates: [353013.384931] sched: RT throttling activated [354008.100835] BUG: soft lockup - CPU#5 stuck for 22s! [apache2:24848] [354008.100846] Modules linked in: evdev coretemp crc32c_intel ghash_clmulni_intel snd_pcm snd_page_alloc aesni_intel snd_timer aes_x86_64 snd aes_generic soundcore cryptd pcspkr ext4 crc16 jbd2 mbcache dm_mod xen_netfront xen_blkfront [354008.100872] CPU 5 [354008.100874] Modules linked in: evdev coretemp crc32c_intel ghash_clmulni_intel snd_pcm snd_page_alloc aesni_intel snd_timer aes_x86_64 snd aes_generic soundcore cryptd pcspkr ext4 crc16 jbd2 mbcache dm_mod xen_netfront xen_blkfront [354008.100894] [354008.100898] Pid: 24848, comm: apache2 Not tainted 3.2.0-4-amd64 #1 Debian 3.2.60-1+deb7u3 [354008.100904] RIP: e030:[8100122a] [8100122a] hypercall_page+0x22a/0x1000 [354008.100914] RSP: e02b:8802f0b41c00 EFLAGS: 0246 [354008.100918] RAX: 00040001 RBX: 88020200 RCX: 8100122a [354008.100922] RDX: ffc8 RSI: RDI: [354008.100927] RBP: 000e R08: 0200 R09: dead00100100 [354008.100931] R10: dead00200200 R11: 0246 R12: 88028e261da0 [354008.100935] R13: 8802be00 R14: ea00099905e8 R15: 000d [354008.100944] FS: 7f7b66cd2740() GS:8802ffd4() knlGS: [354008.100949] CS: e033 DS: ES: CR0: 8005003b [354008.100953] CR2: 7f7b68c2b000 CR3: 0002855b7000 CR4: 2660 [354008.100958] DR0: DR1: DR2: [354008.100962] DR3: DR6: 0ff0 DR7: 0400 [354008.100967] Process apache2 (pid: 24848, threadinfo 8802f0b4, task 8802ef49c8c0) [354008.100972] Stack: [354008.100974] 0200 81006790 81006d22 [354008.100981] dead00200200 dead00100100 0200 [354008.100988] 88020200 88020200 ffc8 0200 [354008.100995] Call Trace: [354008.101000] [81006790] ? xen_force_evtchn_callback+0x9/0xa [354008.101006] [81006d22] ? check_events+0x12/0x20 [354008.101011] [81006d0f] ? xen_restore_fl_direct_reloc+0x4/0x4 [354008.101017] [81071153] ? arch_local_irq_restore+0x7/0x8 [354008.101024] [8135049f] ? _raw_spin_unlock_irqrestore+0xe/0xf [354008.101031] [810be895] ? release_pages+0xf4/0x14d [354008.101038] [810de78b] ? free_pages_and_swap_cache+0x48/0x60 [354008.101045] [810cf527] ? tlb_flush_mmu+0x37/0x50 [354008.101049] [810cf54c] ? tlb_finish_mmu+0xc/0x31 [354008.101054] [810d5e79] ? exit_mmap+0xc4/0xe9 [354008.101060] [81044b82] ? mmput+0x56/0xf8 [354008.101064] [81049d07] ? exit_mm+0x117/0x122 [354008.101069] [8107115b] ? arch_local_irq_disable+0x7/0x8 [354008.101074] [81350487] ?
Bug#758622: kernel crashes after soft lockups in xen domU
Package: src:linux Version: 3.2.60-1+deb7u3 Severity: important Hello, I encounter kernel crashes on an up-to-date Debian/Wheezy Xen domU with the stock kernel. The dom0 runs the same linux kernel and xen/4.1.4-3+deb7u1. It seems like the crashes are related to a RT process, even though no sched_fifo/rr processes are started on this system intentionally. Also, the CPU usage is low all the time, no peaks at all. But the kernel reports: kernel: [39101.461586] sched: RT throttling activated Usually, a few minutes later, soft lockups start to happen, and then the system crashes: [36.127400] BUG: soft lockup - CPU#7 stuck for 22s! [/usr/share/webm:16190] [36.128652] Modules linked in: evdev coretemp crc32c_intel ghash_clmulni_intel snd_pcm snd_timer aesni_intel snd cryptd soundcore snd_page_alloc aes_x86_64 pcspkr aes_generic ext4 crc16 jbd2 mbcache dm_mod xen_netfront xen_blkfront [36.128679] CPU 7 [36.128680] Modules linked in: evdev coretemp crc32c_intel ghash_clmulni_intel snd_pcm snd_timer aesni_intel snd cryptd soundcore snd_page_alloc aes_x86_64 pcspkr aes_generic ext4 crc16 jbd2 mbcache dm_mod xen_netfront xen_blkfront [36.128701] [36.128704] Pid: 16190, comm: /usr/share/webm Not tainted 3.2.0-4-amd64 #1 Debian 3.2.60-1+deb7u3 [36.128711] RIP: e030:[8100122a] [8100122a] hypercall_page+0x22a/0x1000 [36.128720] RSP: e02b:8801c4b8dc00 EFLAGS: 0246 [36.128724] RAX: 00040001 RBX: 88020280 RCX: 8100122a [36.128728] RDX: RSI: RDI: [36.128733] RBP: 000e R08: 0200 R09: dead00100100 [36.128737] R10: dead00200200 R11: 0246 R12: 8800b4f53da0 [36.128741] R13: 8802be00 R14: ea0001e526d0 R15: 000d [36.128749] FS: 7f1a46e3a700() GS:8802ffdc() knlGS: [36.128754] CS: e033 DS: ES: CR0: 8005003b [36.128758] CR2: 7fcbe7683000 CR3: 0001bcba5000 CR4: 2660 [36.128762] DR0: DR1: DR2: [36.128767] DR3: DR6: 0ff0 DR7: 0400 [36.128771] Process /usr/share/webm (pid: 16190, threadinfo 8801c4b8c000, task 8801d175b0c0) [36.128776] Stack: [36.128779] 0200 81006790 81006d22 [36.128786] dead00200200 dead00100100 0200 [36.128792] 88020280 88020280 0200 [36.130901] Call Trace: [36.130908] [81006790] ? xen_force_evtchn_callback+0x9/0xa [36.130914] [81006d22] ? check_events+0x12/0x20 [36.130919] [81006d0f] ? xen_restore_fl_direct_reloc+0x4/0x4 [36.130925] [81071153] ? arch_local_irq_restore+0x7/0x8 [36.130932] [8135049f] ? _raw_spin_unlock_irqrestore+0xe/0xf [36.130939] [810be83e] ? release_pages+0x9d/0x14d [36.130945] [810de78b] ? free_pages_and_swap_cache+0x48/0x60 [36.130951] [810cf527] ? tlb_flush_mmu+0x37/0x50 [36.130956] [810cf54c] ? tlb_finish_mmu+0xc/0x31 [36.130961] [810d5e79] ? exit_mmap+0xc4/0xe9 [36.130967] [81044b82] ? mmput+0x56/0xf8 [36.130971] [81049d07] ? exit_mm+0x117/0x122 [36.130975] [8107115b] ? arch_local_irq_disable+0x7/0x8 [36.130980] [81350487] ? _raw_spin_lock_irq+0xa/0x14 [36.130984] [8107115b] ? arch_local_irq_disable+0x7/0x8 [36.130988] [81049f57] ? do_exit+0x245/0x713 [36.130993] [81350c5a] ? error_exit+0x2a/0x60 [36.130999] [811275b3] ? fsnotify_find_inode_mark_locked+0x16/0x47 [36.131004] [81127605] ? fsnotify_find_inode_mark+0x21/0x2c [36.131009] [8104a6a5] ? do_group_exit+0x74/0x9e [36.131013] [8104a6de] ? sys_exit_group+0xf/0xf [36.131018] [81355452] ? system_call_fastpath+0x16/0x1b [36.131021] Code: cc 51 41 53 b8 10 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 11 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc [36.131061] Call Trace: [36.131065] [81006790] ? xen_force_evtchn_callback+0x9/0xa [36.131070] [81006d22] ? check_events+0x12/0x20 [36.131075] [81006d0f] ? xen_restore_fl_direct_reloc+0x4/0x4 [36.131079] [81071153] ? arch_local_irq_restore+0x7/0x8 [36.131395] [8135049f] ? _raw_spin_unlock_irqrestore+0xe/0xf [36.131395] [810be83e] ? release_pages+0x9d/0x14d [36.131395] [810de78b] ? free_pages_and_swap_cache+0x48/0x60 [36.131395] [810cf527] ? tlb_flush_mmu+0x37/0x50 [36.131395] [810cf54c] ? tlb_finish_mmu+0xc/0x31
