search for: 23s

Hey, I have rather new installation of xen, dom0 is running ntpd and is perfectly in time. All domU''s are ~23s in future. Running ntpd on the domU''s seem to have no effect, /proc/sys/xen/independent_wallclock appears to have no effect. I''m running xen-unstable and 2.6.16-rc4 in AMD64 box. Any tip would be appricated. Thanks, -- ++ytti _______________________________________________...

...gt; >resource fork stream itself (on Linux: by saving it to a ._ > > >AppleDouble file). > > > > I can confirm that with Samba 4.2.0rc2, with vfs_streams_xattr > > and vfs_fruit the time it takes to list a shared dir > > with ~8000 files in it drops from 3m25s to 23s. > > Tested with OSX 10.9.5. > > And this is just the beginning, once we have my AAPL patches in Samba, > this should go down to a just few seconds. A late followup question: since we work in a mixed Win/Mac environment: is there a performance penalty or change in behaviour expect...

When I try to umount btrfs filesystem I get always this error with kernel 3.11.4 and 3.11.3, but I can mount and umount without error on kernel 3.11.2. Exact error messages are: BUG: soft lockup - CPU#0 stuck for 23s! [btrfs-transacti:680] BUG: soft lockup - CPU#1 stuck for 23s! [umount:1575] I''m on Fedora 19 I have run scrub and there are no errors: # btrfs scrub status /home scrub status for xxxx scrub started at Tue Oct 22 17:06:16 2013 and finished after 3600 seconds total bytes scrubbed...

...ee, computing it conditionally based on whether there is a huge basic block in the function is another idea, but I am not sure if that is possible (I don't think this is currently supported). This brings down the compilation time (using clang -emit-llvm) from 350s to 30s (it still takes about 23s to do GVN). It also might fix PR17855 (the program that used to take 65s to compile now takes just 11s): http://llvm.org/bugs/show_bug.cgi?id=17855 2. Cache the ordering of loads and stores in LoadAndStorePromoter::run. I don't know how hard it would be to implement this, but I think it wou...

...tain conditions. Type `flac' for details. data.flac: done real 0m23.943s user 0m16.280s sys 0m0.970s As you can see, starting at the beginning of the file always takes about the same amount of time, and starting later still takes a reasonable amount of time to decode 1Msamples (~23s). I'm guessing this is a bug :-) donald (please CC me replies, I'm not subscribed to the list)

...TXSW_TIMEOUT] [ 4024.673513] nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] [ 4028.968450] nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] [ 4033.263426] nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] [ 4036.404132] NMI watchdog: BUG: soft lockup - CPU#4 stuck for 23s! [kworker/4:1:6743] [ 4036.404135] Modules linked in: xt_tcpudp(E) iptable_filter(E) pci_stub(E) vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) ipt_MASQUERADE(E) nf_nat_masquerade_ipv4(E) iptable_nat(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) nf_nat_ipv4(E) nf_nat(E) nf_conntrack(E) ip_tables...

Hi, Mike Snitzer wrote: > This particular dm-crypt on virtio-blk issue is fixed with this commit: > http://git.kernel.org/linus/586b286b110e94eb31840ac5afc0c24e0881fe34 > > Linus pulled this into v4.3-rc3. I have this patch applied to linux-4.1.9. This could be the reason why I don't see the issue on boot with linux-4.1.9. So is the freeze I am experiencing with linux-4.1.9

...roblem seems to be already fixed by Mike's patch. I applied the patch against linux-4.1.8, rebooted several times without a problem. But I'll keep testing for sure. The second problem is a new bug within linux-4.1.9: I experience the > NMI watchdog: BUG: soft lockup - CPU#3 stuck for 23s! freeze now on all my systems (virtual machines *and* physical systems; Gentoo boxes, Debian boxes, with and without dm (LUKS), with XFS or ext4 -- looks like a general problem). I will post it to LKML itself (I don't have a trace about what's hanging). Thanks for all your time and help!...

Hi, Mike Snitzer wrote: > This particular dm-crypt on virtio-blk issue is fixed with this commit: > http://git.kernel.org/linus/586b286b110e94eb31840ac5afc0c24e0881fe34 > > Linus pulled this into v4.3-rc3. I have this patch applied to linux-4.1.9. This could be the reason why I don't see the issue on boot with linux-4.1.9. So is the freeze I am experiencing with linux-4.1.9

Hello, With my new system centos 7.1 and KVM I have kernel crashes on boot in the DomU's like this id c51a566956f67146b061f2e7500c78090fe6eed4 reason: BUG: soft lockup - CPU#2 stuck for 23s! [192.168.90.200-:1459] time: Mo 25 Mai 2015 22:07:35 CEST cmdline: BOOT_IMAGE=/vmlinuz-3.10.0-229.4.2.el7.x86_64 root=UUID=b45384af-3198-4d06-a5c3-7d66741a4c04 ro crashkernel=auto rhgb quiet LANG=en_US.UTF-8 systemd.debug package: kernel count: 7 Directory:...

...gt; data.flac: done > > real 0m23.943s > user 0m16.280s > sys 0m0.970s > > As you can see, starting at the beginning of the file always takes > about > the same amount of time, and starting later still takes a reasonable > amount of time to decode 1Msamples (~23s). > > I'm guessing this is a bug :-) > > donald > (please CC me replies, I'm not subscribed to the list) __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree

...s 5 1.6266667 9702 Gapped Distances 5S Between species > levels(alldata$disttype) [1] "Gapped Distances" "Ungapped Distances" > levels(alldata$type) [1] "Between species" "Same species" > levels(alldata$moltype) [1] "16S" "23S" "5S" > Which I plot like this: xyplot(numbers~sqrt(breaks)|moltype+disttype, groups = type, data = alldata) This results in a plot consisting of six different panels. Now, I have a set of six different values that I would like to incorporate into these plots through a vertic...

...9 Kernel driver in use: nouveau hangs during the boot process, which never finishes. The problem can be avoided with nouveau.runpm=0 on the kernel command line. The following soft lockup is present on the kernel command line: [ 56.593134] NMI watchdog: BUG: soft lockup - CPU#6 stuck for 23s! [plymouthd:227] [ 56.593136] Modules linked in: ath9k(+) ath9k_common ath9k_hw kvm_intel(+) ath kvm mac80211 irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel uvcvideo asus_nb_wmi(+) snd_hda_intel(+) aesni_intel asus_wmi aes_x86_64 snd_hda_codec r8169(+) videobuf2_vmalloc videobuf2_mem...

We're using Samba in several schools. We generally have a single Samba server acting as a domain controller in each school. Until recently, this has worked very well. The number of workstations on our school networks has been steadily growing. Among other things, this has convinced us to split some school's networks into several VLANs/subnets. To add complication, the server running Samba

...d=128914&action=edit dmesg log from boot to bug Nouveau driver seems to produce soft lockups. The most notable effect is that some syscalls "hangs", the whole system become very slow and this kind f message appear in every terminals: NMI watchdog: BUG: soft lockup - CPU#6 stuck for 23s! [kworker/6:2:324] This seems related to power management, since adding the option runpm=0 doesn't produce the lockups. This bug can be triggered by many things, including running commands like lspci. I attach the dmesg log from boot up to the bug. -- You are receiving this mail because: Yo...

...packets get sent for a 40ms period. Thank you for this analysis. > > Add explicit (un)corking when processing (and responding to) requests. > "TCP_CORK, &zero" after earlier "CORK, &one" will flush pending data. > > VM Boot time: > main: no tls: 23s, with tls: 2m45s > patched: no tls: 14s, with tls: 15s > > VM Boot time, qemu-nbd via network (same lan): > main: no tls: 18s, with tls: 1m50s > patched: no tls: 17s, with tls: 18s And the timings bear proof that it matters. > > Future optimization: if we could detect...

Hello all. I'm having trouble resolving an issue with our Asterisk system that seems to have popped up recently (no one knows for sure when the issue started). I'm still somewhat of a Asterisk newb and have been tasked with administrating the system as the previous administrator has left the company. Within asterisk, we have a Zap interface setup connected to a PRI that we have through a

...8e80 RSI: 0000000000000720 RDI: 0000000000000003 RBP: 00005630d155b968 R08: 0000000000000001 R09: 00005630d15a1da0 R10: 0000000000000070 R11: 0000000000000246 R12: 00005630d1598e80 R13: 00005630d12f3d28 R14: 0000000000000720 R15: 00005630d12f3ce0 watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [sensors-detect:12438] Yikes! While I wanted to try to make it so that accessing an i2c bus on nouveau would wake up the GPU as needed, airlied pointed out that pretty much any usecase for userspace accessing an i2c bus on a GPU (mainly for the DDC brightness control that some displays have) is g...

...8e80 RSI: 0000000000000720 RDI: 0000000000000003 RBP: 00005630d155b968 R08: 0000000000000001 R09: 00005630d15a1da0 R10: 0000000000000070 R11: 0000000000000246 R12: 00005630d1598e80 R13: 00005630d12f3d28 R14: 0000000000000720 R15: 00005630d12f3ce0 watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [sensors-detect:12438] Yikes! While I wanted to try to make it so that accessing an i2c bus on nouveau would wake up the GPU as needed, airlied pointed out that pretty much any usecase for userspace accessing an i2c bus on a GPU (mainly for the DDC brightness control that some displays have) is g...

I came in this morning to find all the servers all locked up solid: # passenger-status ----------- General information ----------- max = 20 count = 20 active = 20 inactive = 0 Waiting on global queue: 236 ----------- Domains ----------- /etc/puppet/rack: PID: 2720 Sessions: 1 Processed: 939 Uptime: 9h 22m 18s PID: 1615 Sessions: 1 Processed: 947 Uptime: 9h 23m