search for: perf_event_max_sample_rate

...;/" "/tmp/tmpAWHkYv" > guestfsd: main_loop: proc 1 (mount) took 2.02 seconds > guestfsd: main_loop: new request, len 0x38 > cd /sysroot/ && find -type f -print0 | xargs -0 sha1sum > [ 25.580340] perf interrupt took too long (2540 > 2500), lowering > kernel.perf_event_max_sample_rate to 50000 > sha1sum: ./Windows/Prefetch/ReadyBoot/Trace7.fx: Value too large for > defined data type > [ 67.835952] perf interrupt took too long (5048 > 5000), lowering > kernel.perf_event_max_sample_rate to 25000 > [ 143.304037] perf interrupt took too long (10010 > 10000),...

...HkYv" > > guestfsd: main_loop: proc 1 (mount) took 2.02 seconds > > guestfsd: main_loop: new request, len 0x38 > > cd /sysroot/ && find -type f -print0 | xargs -0 sha1sum > > [ 25.580340] perf interrupt took too long (2540 > 2500), lowering > > kernel.perf_event_max_sample_rate to 50000 > > sha1sum: ./Windows/Prefetch/ReadyBoot/Trace7.fx: Value too large for > > defined data type > > [ 67.835952] perf interrupt took too long (5048 > 5000), lowering > > kernel.perf_event_max_sample_rate to 25000 > > [ 143.304037] perf interrupt took too...

...e cancelled by daemon" still persists. From the guestfs trace I can't see any evidence if not what seems a sort of overflow: sha1sum: ./Windows/Prefetch/ReadyBoot/Trace2.fx: Value too large for defined data type [ 65.347452] perf interrupt took too long (5124 > 5000), lowering kernel.perf_event_max_sample_rate to 25000 [ 139.668206] perf interrupt took too long (10140 > 10000), lowering kernel.perf_event_max_sample_rate to 12500 pclose: /: Success guestfsd: main_loop: proc 244 (checksums_out) took 244.89 seconds libguestfs: trace: checksums_out = -1 (error) Is there something else wrong?

2015-05-28 10:40 GMT+03:00 Richard W.M. Jones <rjones@redhat.com>: > On Thu, May 28, 2015 at 10:33:48AM +0300, NoxDaFox wrote: > > To create the snapshots I'm using the libvirt command snapshotCreateXML > > with no flag set. Does libvirt support consistent snapshotting or shall I > > rely on QEMU backup new feature only? > > According to:

...launching supertuxkart i see only: [ 22.471837] fuse init (API version 7.26) [ 52.346467] nouveau 0000:03:00.0: imem: OOM: 00100000 00001000 -28 [ 52.346516] nouveau 0000:03:00.0: imem: OOM: 00100000 00001000 -28 [ 108.372556] perf: interrupt took too long (2530 > 2500), lowering kernel.perf_event_max_sample_rate to 79000 No artefacts. -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/nouveau/attachments/20180301/f86c6b00/attachment.html>

...uveau 0000:04:00.0: fifo: intr 04800000 [ 563.418621] INFO: NMI handler (ghes_notify_nmi) took too long to run: 48.172 msecs [ 563.563141] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 48.172 msecs [ 563.659490] perf: interrupt took too long (376349 > 2500), lowering kernel.perf_event_max_sample_rate to 300 [ 578.942906] NMI watchdog: Watchdog detected hard LOCKUP on cpu 0 [ 578.942909] Modules linked in: netconsole snd_hda_codec_hdmi ipmi_ssif snd_hda_codec_realtek snd_hda_codec_generic i915 intel_gtt intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif...

...-2006 Netfilter Core Team [ 9.286038] input: ACPI Virtual Keyboard Device as /devices/virtual/input/input10 [ 10.351014] postgres (3900): /proc/3900/oom_adj is deprecated, please use /proc/3900/oom_score_adj instead. [21155.639953] perf interrupt took too long (2503 > 2500), lowering kernel.perf_event_max_sample_rate to 50000 [31883.976077] fuse init (API version 7.23) [60917.269345] perf interrupt took too long (5006 > 5000), lowering kernel.perf_event_max_sample_rate to 25000 [128872.463114] usb 4-4: USB disconnect, device number 3 [128872.984140] usb 4-4: new full-speed USB device number 5 using ohci-pci...

...uses the least common denominator. Is that accurate? In case it was missed, here are the dmesg errors being thrown by gluster (as far as I can tell). They definately started after I upgraded from gluster 3.8 to 3.12: [ 6604.536156] perf: interrupt took too long (9593 > 9565), lowering kernel.perf_event_max_sample_rate to 20000 [ 8280.188734] INFO: task xfsaild/dm-10:1061 blocked for more than 120 seconds. [ 8280.188787] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 8280.188837] xfsaild/dm-10 D ffff93203a2eeeb0 0 1061 2 0x00000000 [ 8280.188843] Call Trace: [...

...ssifier > > [ 60.506077] Performance counters on > > [ 60.506078] Actions configured > > [ 118.338005] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 2.220 msecs > > [ 118.338016] perf interrupt took too long (19624 > 2500), lowering kernel.perf_event_max_sample_rate to 50000 > > [ 180.970220] perf interrupt took too long (19751 > 5000), lowering kernel.perf_event_max_sample_rate to 25000 > > > > -Thomas

.... Is that accurate? > > In case it was missed, here are the dmesg errors being thrown by gluster > (as far as I can tell). They definately started after I upgraded from > gluster 3.8 to 3.12: > > [ 6604.536156] perf: interrupt took too long (9593 > 9565), lowering > kernel.perf_event_max_sample_rate to 20000 > [ 8280.188734] INFO: task xfsaild/dm-10:1061 blocked for more than 120 > seconds. > [ 8280.188787] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 8280.188837] xfsaild/dm-10 D ffff93203a2eeeb0 0 1061 2 > 0x0000000...

https://bugs.freedesktop.org/show_bug.cgi?id=88893 Bug ID: 88893 Summary: [NV46] GPU lockup with Quadro NVS 110M Product: xorg Version: 7.7 (2012.06) Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau Assignee:

...60.506072] u32 classifier > [ 60.506077] Performance counters on > [ 60.506078] Actions configured > [ 118.338005] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 2.220 msecs > [ 118.338016] perf interrupt took too long (19624 > 2500), lowering kernel.perf_event_max_sample_rate to 50000 > [ 180.970220] perf interrupt took too long (19751 > 5000), lowering kernel.perf_event_max_sample_rate to 25000 -Thomas

...60.506072] u32 classifier > [ 60.506077] Performance counters on > [ 60.506078] Actions configured > [ 118.338005] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 2.220 msecs > [ 118.338016] perf interrupt took too long (19624 > 2500), lowering kernel.perf_event_max_sample_rate to 50000 > [ 180.970220] perf interrupt took too long (19751 > 5000), lowering kernel.perf_event_max_sample_rate to 25000 -Thomas

https://bugs.freedesktop.org/show_bug.cgi?id=96876 Bug ID: 96876 Summary: system freeze "fifo: gr engine fault on channel 6" NVIDIA Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component:

...; >> In case it was missed, here are the dmesg errors being thrown by gluster >> (as far as I can tell). They definately started after I upgraded from >> gluster 3.8 to 3.12: >> >> [ 6604.536156] perf: interrupt took too long (9593 > 9565), lowering >> kernel.perf_event_max_sample_rate to 20000 >> [ 8280.188734] INFO: task xfsaild/dm-10:1061 blocked for more than 120 >> seconds. >> [ 8280.188787] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 8280.188837] xfsaild/dm-10 D ffff93203a2eeeb0 0 1061...

...ut "sha1" "/" "/tmp/tmpAWHkYv" guestfsd: main_loop: proc 1 (mount) took 2.02 seconds guestfsd: main_loop: new request, len 0x38 cd /sysroot/ && find -type f -print0 | xargs -0 sha1sum [ 25.580340] perf interrupt took too long (2540 > 2500), lowering kernel.perf_event_max_sample_rate to 50000 sha1sum: ./Windows/Prefetch/ReadyBoot/Trace7.fx: Value too large for defined data type [ 67.835952] perf interrupt took too long (5048 > 5000), lowering kernel.perf_event_max_sample_rate to 25000 [ 143.304037] perf interrupt took too long (10010 > 10000), lowering kernel.perf_even...

...1 audit(1565978098.063:116): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 1008.985212] perf: interrupt took too long (2507 > 2500), lowering kernel.perf_event_max_sample_rate to 79500 [ 3573.969403] perf: interrupt took too long (3144 > 3133), lowering kernel.perf_event_max_sample_rate to 63600 [ 3723.963109] nouveau 0000:01:00.0: disp: ERROR 4 [INVALID_ARG] 84 [] chid 0 mthd 089c data f0000001 [ 3723.963134] nouveau 0000:01:00.0: disp: ERROR 5 [INVALID_STATE] 0f []...

...Starting LSB: start Samba daemons for the AD DC... May 17 11:56:11 debian systemd[1]: Started LSB: start Samba daemons for the AD DC. May 17 12:02:19 debian crontab[1516]: (root) LIST (root) May 17 12:02:39 debian kernel: [ 7713.661907] perf interrupt took too long (5003 > 5000), lowering kernel.perf_event_max_sample_rate to 25000 May 17 12:03:30 debian samba[1521]: [2017/05/17 12:03:30.212614, 0] ../source4/smbd/server.c:370(binary_smbd_main) May 17 12:03:30 debian samba[1521]: samba version 4.2.14-Debian started. May 17 12:03:30 debian samba[1521]: Copyright Andrew Tridgell and the Samba Team 1992-2014 May 17...

...>>> [11279.504725] [<ffffffffb992082f>] system_call_fastpath+0x1c/0x21 >>> [11279.504730] [<ffffffffb992077b>] ? system_call_after_swapgs+0xc8/ >>> 0x160 >>> [12127.466494] perf: interrupt took too long (8263 > 8150), lowering >>> kernel.perf_event_max_sample_rate to 24000 >>> >>> -------------------- >>> I think this is the cause of the massive ovirt performance issues >>> irrespective of gluster volume. At the time this happened, I was also >>> ssh'ed into the host, and was doing some rpm querry commands....

Greetings, I am suffering of several weird errors which show randomly and make me suspect some concurrency issue. Libguestfs version is 1.28.1, linux kernel 3.16, libvirt 1.2.9 and qemu 2.1. What I'm trying to do is comparing the disk state at two different point of a guest execution. Disk snapshots are taken through libvirt in different moments (I am aware of caching issue), from such