Client takes more than 120 seconds connecting to server

Any ideas?
Could the creation of a new Data Source (ODBC) help?
Versions:
- SB1 2005 SP01 PL 16
- MS Windows Server 2003 R2 (Standar Edition) SP1
Thank's

Have you got multiple network cards in the license server? There is a known issue with this where the application has to wait for a reply or a timeout from each network card.
If this is the case and you try disabling one of the network cards does the issue go away?

Similar Messages

Ldap search query takes more than 10 seconds

LDAP query takes more than 10 seconds to execute.
For validating the policy configured, the Acess Manager(Sun Java System Access Manager) contacts the LDAP (Sun Java System Directory Server 6.2) to get the users in a dynamic group. The time out value configured in Access Manager for LDAP searches is 10 seconds.
Issue : The ldap query takes more than 10 seconds to execute at some times .
The query is executing with less than 10 seconds in most of the cases, but it takes more than 10 seconds in some cases. The total number of users available in the ldap is less than 1500.
7 etime =1
6 etime =1
102 etime=4
51 etime=5
26 etime=6
5 etime=7
4 etime=8
From the ldap access logs we can see the following entry,some times the query takes more than 10 seconds,
[28/May/2012:14:21:26 +0200] conn=281 op=41433 msgId=853995 - SRCH base="dc=****,dc=****,dc=com" scope=2 filter="(&(&(***=true)(**=true))(objectClass=vfperson))" attrs=ALL
[28/May/2012:14:21:36 +0200] conn=281 op=41434 msgId=854001 - ABANDON targetop=41433 msgid=853995 nentries=884 etime=10
The query was aborted by the access manger after 10 seconds.
Please post your suggestions to resolve this issue .
1.How we can find out , why the query is taking more than 10 seconds ?
2.Next steps to resolve this issue .

Hi Marco,
Thanks for your suggestions.
Sorry for replying late. I was out of office for few weeks.
1) Have you already tuned the caches? (entry cache, db cache, filesystem cache?)
We are using db cache and we have not done any turning for cache. The application was working fine and there was no much changes in the number of users .
2) Unfortunately we don't have direct access to the environment and we have contacted the responsible team to verify the server health during the issue .
Regarding the IO operations we can see that, load balancer is pinging the ldap sever every 15 seconds to check the status of ldap servers which yields a new connection on every hit. (on average per minute 8 connections - )
3) We using cn=dsameuser to bind the directory server. Other configuration details for ldap
LDAP Connection Pool Minimum Size: 1
LDAP Connection Pool Maximum Size:10
Maximum Results Returned from Search: 1700
Search Timeout: 10
Is the Search Timeout value configured is proper ? ( We have less than 1500 user in the ldap server).
Also is there any impact if the value Maximum Results Returned from Search = set to 1700. ( The Sun document for AM says that the ideal value for this is 1000 and if its higher than this it will impact performance.
The application was running without time out issue for last 2 years and there was no much increase in the number of users in the system. ( at the max 200 users added to the system in last 2 years.)
Thanks,
Jay

[SOLVED] Cannot start X: Xorg.bin blocked for more than 120 seconds

I just rebooted my desktop after a couple of months and now I cannot run Xorg. When I run startx, I get a black screen for two minutes and then a backtrace pops up. At that point I can no longer interact with the console, but I can still ssh and run commands. I've tried setting Xwrapper.conf to needs_root_rights = yes and I have tried just running startx as root, with no help. I'm not sure how to isolate what would have broken this as I have updated so many packages in the last two months. Any ideas what I can try next?
If it helps, I am using the open source ati driver and my xorg.conf.d is empty.
Here is the dmesg showing the oops and the backtrace:
[ 72.778340] BUG: unable to handle kernel paging request at ffffec2003fffe00
[ 72.778368] IP: [<ffffffff811ac636>] kfree+0x56/0x1a0
[ 72.778389] PGD 0
[ 72.778397] Oops: 0000 [#1] PREEMPT SMP
[ 72.778413] Modules linked in: cfg80211 it87 hwmon_vid xpad ff_memless fuse mousedev joydev eeepc_wmi asus_wmi sparse_keymap led_class rfkill video evdev mxm_wmi mac_hid kvm_amd kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd psmouse serio_raw radeon r8169 snd_hda_codec_realtek edac_core fam15h_power mii k10temp snd_hda_codec_generic edac_mce_amd sp5100_tco ttm snd_hda_codec_hdmi drm_kms_helper i2c_piix4 snd_hda_intel snd_hda_controller drm snd_hda_codec snd_hwdep snd_pcm hwmon i2c_algo_bit snd_timer i2c_core snd soundcore tpm_infineon tpm_tis tpm wmi shpchp button processor sch_fq_codel vboxnetflt(O) vboxnetadp(O) vboxdrv(O) ext4 crc16 mbcache jbd2 hid_generic usbhid hid sd_mod crc_t10dif crct10dif_common sr_mod
[ 72.778702] cdrom atkbd libps2 ohci_pci ohci_hcd ehci_pci ahci sata_sil libahci xhci_hcd ehci_hcd libata usbcore usb_common scsi_mod i8042 serio zfs(PO) zunicode(PO) zavl(PO) zcommon(PO) znvpair(PO) spl(O)
[ 72.779931] CPU: 7 PID: 1534 Comm: Xorg.bin Tainted: P O 3.17.4-1-ARCH #1
[ 72.781110] Hardware name: To be filled by O.E.M. To be filled by O.E.M./SABERTOOTH 990FX R2.0, BIOS 1503 01/11/2013
[ 72.782332] task: ffff880808b264a0 ti: ffff8807fcd30000 task.ti: ffff8807fcd30000
[ 72.783574] RIP: 0010:[<ffffffff811ac636>] [<ffffffff811ac636>] kfree+0x56/0x1a0
[ 72.784796] RSP: 0018:ffff8807fcd33a30 EFLAGS: 00010286
[ 72.786010] RAX: 0000022003fffe00 RBX: 00001000ffff8807 RCX: 0000000000010005
[ 72.787227] RDX: 000077ff80000000 RSI: 0000000000000007 RDI: 00001000ffff8807
[ 72.788446] RBP: ffff8807fcd33a48 R08: 0000000000000007 R09: ffffec2003fffe00
[ 72.789714] R10: 0000000000000017 R11: 0000000000000000 R12: ffff88080887a400
[ 72.790978] R13: ffffffffa0678f8c R14: 00000000000108f0 R15: 0000000000001800
[ 72.792211] FS: 00007f0dd095e8c0(0000) GS:ffff88083edc0000(0000) knlGS:0000000000000000
[ 72.793455] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 72.794680] CR2: ffffec2003fffe00 CR3: 00000000b7c0c000 CR4: 00000000000407e0
[ 72.795924] Stack:
[ 72.797140] ffff880811db0000 ffff88080887a400 ffff880811db0000 ffff8807fcd33b30
[ 72.798358] ffffffffa0678f8c 000000000000004c 000108480001092c ffff880700000008
[ 72.799584] 0000ffff00010844 000000000001092c 0000000000010848 0000000000010844
[ 72.800809] Call Trace:
[ 72.802053] [<ffffffffa0678f8c>] evergreen_hdmi_setmode+0xd8c/0x1970 [radeon]
[ 72.803320] [<ffffffffa052b8d4>] ? drm_detect_hdmi_monitor+0x74/0xc0 [drm]
[ 72.804555] [<ffffffffa0681488>] radeon_atom_encoder_mode_set+0x178/0x3c0 [radeon]
[ 72.805789] [<ffffffffa0563986>] drm_crtc_helper_set_mode+0x356/0x530 [drm_kms_helper]
[ 72.807017] [<ffffffffa061b97c>] radeon_property_change_mode.isra.1+0x3c/0x40 [radeon]
[ 72.808240] [<ffffffffa061bb2e>] radeon_connector_set_property+0x1ae/0x3f0 [radeon]
[ 72.809490] [<ffffffffa05284e2>] drm_mode_obj_set_property_ioctl+0x1b2/0x3a0 [drm]
[ 72.810736] [<ffffffffa052870f>] drm_mode_connector_property_set_ioctl+0x3f/0x60 [drm]
[ 72.811961] [<ffffffffa0518fef>] drm_ioctl+0x1df/0x680 [drm]
[ 72.813175] [<ffffffff8105e9ac>] ? __do_page_fault+0x2ec/0x600
[ 72.814402] [<ffffffffa05f404c>] radeon_drm_ioctl+0x4c/0x80 [radeon]
[ 72.815649] [<ffffffff811da5f0>] do_vfs_ioctl+0x2d0/0x4b0
[ 72.816899] [<ffffffff811ca161>] ? __sb_end_write+0x31/0x60
[ 72.818124] [<ffffffff811da851>] SyS_ioctl+0x81/0xa0
[ 72.819332] [<ffffffff8153db29>] system_call_fastpath+0x16/0x1b
[ 72.820528] Code: 00 00 00 80 ff 77 00 00 49 b9 00 00 00 00 00 ea ff ff 48 01 d8 48 0f 42 15 e8 b9 66 00 48 01 d0 48 c1 e8 0c 48 c1 e0 06 49 01 c1 <49> 8b 01 f6 c4 80 0f 85 0e 01 00 00 49 8b 01 a8 80 0f 84 83 00
[ 72.823135] RIP [<ffffffff811ac636>] kfree+0x56/0x1a0
[ 72.824394] RSP <ffff8807fcd33a30>
[ 72.825653] CR2: ffffec2003fffe00
[ 240.461007] INFO: task Xorg.bin:1534 blocked for more than 120 seconds.
[ 240.462414] Tainted: P O 3.17.4-1-ARCH #1
[ 240.463701] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 240.465017] Xorg.bin D 0000000000000007 0 1534 1533 0x00000000
[ 240.466325] ffff8807fcd333b0 0000000000000082 ffff880808b264a0 00000000000145c0
[ 240.467623] ffff8807fcd33fd8 00000000000145c0 ffff880812e73250 ffff880808b264a0
[ 240.468886] 0000000000000080 0000000000000140 0000000000001e00 000000000000000a
[ 240.470155] Call Trace:
[ 240.471435] [<ffffffff813113db>] ? bit_putcs+0x30b/0x590
[ 240.472702] [<ffffffff81539519>] schedule+0x29/0x70
[ 240.473964] [<ffffffff81539986>] schedule_preempt_disabled+0x16/0x20
[ 240.475239] [<ffffffff8153b445>] __mutex_lock_slowpath+0xe5/0x250
[ 240.476495] [<ffffffff8153b5c7>] mutex_lock+0x17/0x30
[ 240.477770] [<ffffffffa0522f32>] drm_modeset_lock_all+0x42/0xd0 [drm]
[ 240.479016] [<ffffffffa056d07f>] drm_fb_helper_pan_display+0x2f/0xf0 [drm_kms_helper]
[ 240.480257] [<ffffffff8131683a>] fb_pan_display+0x9a/0x160
[ 240.481508] [<ffffffff81310950>] bit_update_start+0x20/0x50
[ 240.482732] [<ffffffff8130e15e>] fbcon_switch+0x3ae/0x5e0
[ 240.483936] [<ffffffff81385899>] redraw_screen+0x1a9/0x250
[ 240.485175] [<ffffffff8130d54a>] fbcon_blank+0x23a/0x340
[ 240.486375] [<ffffffff8113e74f>] ? irq_work_queue+0xf/0xa0
[ 240.487587] [<ffffffff810c476c>] ? wake_up_klogd+0x3c/0x60
[ 240.488771] [<ffffffff810c4a12>] ? console_unlock+0x282/0x460
[ 240.489894] [<ffffffff810d5d33>] ? internal_add_timer+0x63/0x80
[ 240.490988] [<ffffffff810d6c54>] ? mod_timer+0x114/0x250
[ 240.492058] [<ffffffff813863ba>] do_unblank_screen+0xaa/0x1d0
[ 240.493075] [<ffffffff813864f0>] unblank_screen+0x10/0x20
[ 240.494053] [<ffffffff812b7019>] bust_spinlocks+0x19/0x40
[ 240.495011] [<ffffffff810186b4>] oops_end+0x34/0xe0
[ 240.495982] [<ffffffff8105df4c>] no_context+0x17c/0x3c0
[ 240.496934] [<ffffffff8105e2bd>] __bad_area_nosemaphore+0x12d/0x250
[ 240.497886] [<ffffffff8105e3f3>] bad_area_nosemaphore+0x13/0x20
[ 240.498842] [<ffffffff8105ea04>] __do_page_fault+0x344/0x600
[ 240.499769] [<ffffffffa060fb4b>] ? atom_execute_table_locked+0x12b/0x3f0 [radeon]
[ 240.500709] [<ffffffffa060e7c0>] ? atom_put_dst+0x480/0x560 [radeon]
[ 240.501673] [<ffffffffa060dabb>] ? atom_op_test+0x9b/0x1b0 [radeon]
[ 240.502640] [<ffffffffa0678f8c>] ? evergreen_hdmi_setmode+0xd8c/0x1970 [radeon]
[ 240.503558] [<ffffffff8105ece2>] do_page_fault+0x22/0x30
[ 240.504494] [<ffffffff8153f9f8>] page_fault+0x28/0x30
[ 240.505441] [<ffffffffa0678f8c>] ? evergreen_hdmi_setmode+0xd8c/0x1970 [radeon]
[ 240.506373] [<ffffffff811ac636>] ? kfree+0x56/0x1a0
[ 240.507266] [<ffffffffa0678f8c>] evergreen_hdmi_setmode+0xd8c/0x1970 [radeon]
[ 240.508204] [<ffffffffa052b8d4>] ? drm_detect_hdmi_monitor+0x74/0xc0 [drm]
[ 240.509155] [<ffffffffa0681488>] radeon_atom_encoder_mode_set+0x178/0x3c0 [radeon]
[ 240.510085] [<ffffffffa0563986>] drm_crtc_helper_set_mode+0x356/0x530 [drm_kms_helper]
[ 240.511021] [<ffffffffa061b97c>] radeon_property_change_mode.isra.1+0x3c/0x40 [radeon]
[ 240.511944] [<ffffffffa061bb2e>] radeon_connector_set_property+0x1ae/0x3f0 [radeon]
[ 240.512875] [<ffffffffa05284e2>] drm_mode_obj_set_property_ioctl+0x1b2/0x3a0 [drm]
[ 240.513791] [<ffffffffa052870f>] drm_mode_connector_property_set_ioctl+0x3f/0x60 [drm]
[ 240.514728] [<ffffffffa0518fef>] drm_ioctl+0x1df/0x680 [drm]
[ 240.515632] [<ffffffff8105e9ac>] ? __do_page_fault+0x2ec/0x600
[ 240.516555] [<ffffffffa05f404c>] radeon_drm_ioctl+0x4c/0x80 [radeon]
[ 240.517455] [<ffffffff811da5f0>] do_vfs_ioctl+0x2d0/0x4b0
[ 240.518369] [<ffffffff811ca161>] ? __sb_end_write+0x31/0x60
[ 240.519267] [<ffffffff811da851>] SyS_ioctl+0x81/0xa0
[ 240.520176] [<ffffffff8153db29>] system_call_fastpath+0x16/0x1b
[ 360.455851] INFO: task Xorg.bin:1534 blocked for more than 120 seconds.
[ 360.456839] Tainted: P O 3.17.4-1-ARCH #1
[ 360.457713] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 360.458629] Xorg.bin D 0000000000000007 0 1534 1533 0x00000000
[ 360.459548] ffff8807fcd333b0 0000000000000082 ffff880808b264a0 00000000000145c0
[ 360.460442] ffff8807fcd33fd8 00000000000145c0 ffff880812e73250 ffff880808b264a0
[ 360.461294] 0000000000000080 0000000000000140 0000000000001e00 000000000000000a
[ 360.462160] Call Trace:
[ 360.463040] [<ffffffff813113db>] ? bit_putcs+0x30b/0x590
[ 360.463880] [<ffffffff81539519>] schedule+0x29/0x70
I do not see any errors in my Xorg.0.log file, but I've posted it here
Last edited by smpolymen (2014-12-06 04:04:55)

Ok, so I tried unplugging my HDMI monitor and that seems to prevent the hang. When I plug the monitor back in and try to have it detect, it hangs again. I tried connecting via DVI (desktop)-HDMI (monitor) cable instead and have the same issue. I wonder if my monitor is causing the issue (it is pretty flaky, taking several tries to turn it on,) although I find it odd that a bad monitor would cause the driver to hang. Maybe the monitor is not sending the right data to the driver to set the mode. I'll try to find another monitor and see if that resolves the issue.

[SOLVED]"kernel: task blocked for more than 120 seconds"

Hello,
today I just found this weird message in journalctl after running "pacman -Syu". Everything (even the update) worked fine, nothing unexpected had happened. RPi works as expected. I just wan't to be sure that this problem is not signaling something bigger.
Jun 16 09:17:06 smecpi sudo[6228]: puser : TTY=pts/0 ; PWD=/home/puser ; USER=root ; COMMAND=/usr/bin/pacman -Syu
Jun 16 09:17:06 smecpi sudo[6228]: pam_unix(sudo:session): session opened for user root by puser(uid=0)
Jun 16 09:19:53 smecpi kernel: INFO: task kworker/u2:0:6233 blocked for more than 120 seconds.
Jun 16 09:19:53 smecpi kernel: Not tainted 3.12.21-1-ARCH #1
Jun 16 09:19:53 smecpi kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jun 16 09:19:53 smecpi kernel: kworker/u2:0 D c05ce278 0 6233 2 0x00000000
Jun 16 09:19:53 smecpi kernel: Workqueue: kmmcd mmc_rescan
Jun 16 09:19:53 smecpi kernel: [<c05ce278>] (__schedule+0x290/0x5ec) from [<c04c43a0>] (__mmc_claim_host+0x90/0x1f0)
Jun 16 09:19:53 smecpi kernel: [<c04c43a0>] (__mmc_claim_host+0x90/0x1f0) from [<c04cab3c>] (mmc_sd_detect+0x1c/0x70)
Jun 16 09:19:53 smecpi kernel: [<c04cab3c>] (mmc_sd_detect+0x1c/0x70) from [<c04c6880>] (mmc_rescan+0x20c/0x3c8)
Jun 16 09:19:53 smecpi kernel: [<c04c6880>] (mmc_rescan+0x20c/0x3c8) from [<c003b9b8>] (process_one_work+0x130/0x43c)
Jun 16 09:19:53 smecpi kernel: [<c003b9b8>] (process_one_work+0x130/0x43c) from [<c003c908>] (worker_thread+0x134/0x3e4)
Jun 16 09:19:53 smecpi kernel: [<c003c908>] (worker_thread+0x134/0x3e4) from [<c0042544>] (kthread+0xa4/0xb0)
Jun 16 09:19:53 smecpi kernel: [<c0042544>] (kthread+0xa4/0xb0) from [<c000e178>] (ret_from_fork+0x14/0x3c)
Last edited by Kotrfa (2014-06-16 11:41:42)

Ir means just what it says. kworker (a kernel worker thread - https://raw.githubusercontent.com/torva … kqueue.txt) blocked for more than 120 seconds. This likely happened during one of pacman's big calculation jobs, and is also likely completely safe to ignore.
Last edited by samiam (2014-06-16 10:20:13)

Why does the first Firefox browser takes more than ten seconds to open?

Once my laptop is logged into, Firefox's initial browser takes more than 10 seconds to open. The subsequent windows take less than two seconds. Much more complex programmes like photoshop open in next to no time. Is Firefox a 'heavy' programme to start?
== This happened ==
Every time Firefox opened
== I shifted to Firefox Windows IE two weeks ago. Eversince.

See http://autonome.wordpress.com/2010/ for progress of work being done to improve that.40

Hang on copy: "btrfs-transacti:282 blocked for more than 120 seconds."

Lately (at least after upgrading to linux 3.15), when I try to copy lots of files between btrfs partitions, I'm getting these "IO hangs" (not sure what to call it) where I can use the system fine as long as I don't try to read/write from my btrfs /home. So I can log in as root and look around, but as soon as I try and ls some random dir within my btrfs /home, it blocks and I have to log in from a different tty to use the system.
A "sudo journalctl -b-1 |grep -i btrfs" will show stuff like
juli 17 14:25:54 arch kernel: [<ffffffffa049fadf>] wait_current_trans.isra.18+0xcf/0x120 [btrfs]
juli 17 14:25:54 arch kernel: [<ffffffffa04a12d8>] start_transaction+0x3a8/0x5c0 [btrfs]
juli 17 14:25:54 arch kernel: [<ffffffffa04a1547>] btrfs_join_transaction+0x17/0x20 [btrfs]
juli 17 14:25:54 arch kernel: [<ffffffffa04a6dd3>] btrfs_dirty_inode+0x43/0xf0 [btrfs]
juli 17 14:25:54 arch kernel: [<ffffffffa04a6eff>] btrfs_update_time+0x7f/0xc0 [btrfs]
juli 17 14:35:54 arch kernel: INFO: task btrfs-transacti:282 blocked for more than 120 seconds.
juli 17 14:35:54 arch kernel: btrfs-transacti D 0000000000000000 0 282 2 0x00000000
juli 17 14:35:54 arch kernel: [<ffffffffa04b0df6>] btrfs_wait_and_free_delalloc_work+0x16/0x30 [btrfs]
juli 17 14:35:54 arch kernel: [<ffffffffa04bb128>] btrfs_run_ordered_operations+0x1f8/0x2e0 [btrfs]
juli 17 14:35:54 arch kernel: [<ffffffffa04a0546>] btrfs_commit_transaction+0x36/0xa20 [btrfs]
juli 17 14:35:54 arch kernel: [<ffffffffa049c475>] transaction_kthread+0x1e5/0x250 [btrfs]
juli 17 14:35:54 arch kernel: [<ffffffffa049c290>] ? btrfs_cleanup_transaction+0x5a0/0x5a0 [btrfs]
juli 17 14:35:54 arch kernel: Workqueue: btrfs-flush_delalloc normal_work_helper [btrfs]
(see full paste at http://pastie.org/9399449)
There seems to be others with similar issues:
http://www.spinics.net/lists/linux-btrfs/msg34458.html
http://www.mail-archive.com/linux-btrfs … 33795.html
but no solution from what I can tell.
It may be that it would unhang itself if I waited a really long while, but haven't had the patience to wait and see yet. I do run nightly backups between the btrfs partitions and the computer seems fine each morning though …
Anyone know what to do about this?
Last edited by unhammer (2014-07-17 13:49:55)

Same thing for me when running rsync... It also corrupted my filesystem. So I restored from a backup and I'm using XFS@LVM@dm-crypt for the time being.
https://imgur.com/a/6gNhH

Info task systemd-shutdow:1 blocked for more than 120 seconds

On halting the system I receive these lines over and over (shutdown -r, or using GUI):
>info task systemd-shutdow:1 blocked for more than 120 seconds
>echo > 0 > /proc/sys/kernel/hung-task-timeout-secs
Here is the contents of journalctl for the last few days:
http://bpaste.net/show/d1b41dLoTYrKEthSXAQN/
Here is the output of dmesg:
http://bpaste.net/show/hcXNspocc4neg8Q683h5/
I will give you any other output you need. I am not sure what other logs would show more information concerning the shutdown process. If you would like a list of my systemd scripts, that is fine as well.
Thank you in advance.
Last edited by degmic71 (2013-10-08 22:40:03)

Thanks for the replies!
@Rexilion: To be honest I can't remember, I daily update the system.
I didn't notice the warnings in dmesg, only till now.
@anatolik: Yesterday I tried a few things:
- Installed Linux-ck (ck-bobcat)
- Removed some btrfs mount flags, now only: noatime,compress=zlib
It seems indeed to be btrfs related, because I don't have the issues (anymore) at the moment.
I cannot find the link at the moment, but I found a post on the Arch bug reports that it may be an issue when using compress=lzo instead of compress=zlib.
So at the moment no problems, but going to try out if I can reproduce the problem.
Thanks and keep you guys posted!
PS. Should I report this bug?
Last edited by beta990 (2014-08-09 20:06:38)

Blocked for more than 120 seconds

Hi,
after a fresh installation of Archlinux on a new SSD (dont know if this is related) on my old computer (no other hardware change) I am getting quite often a problem with firefox and other applications with following error:
[ 4921.272887] INFO: task firefox-bin:1371 blocked for more than 120 seconds.
[ 4921.272891] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 4921.272896] firefox-bin D f2f85f2c 0 1371 1186 0x00000000
[ 4921.272903] f2f85f3c 00200086 00000002 f2f85f2c 00000000 00000031 802c6004 00000000
[ 4921.272913] 00000000 00000001 c103d509 f2ee1ea0 f54032b8 f5403360 c1465e40 c1527480
[ 4921.272923] f2f85edc c1527480 f5406480 f2ee1ea0 c1463fe0 2af9d067 802f4000 55315437
[ 4921.272933] Call Trace:
[ 4921.272945] [<c103d509>] ? scheduler_tick+0xa9/0x220
[ 4921.272953] [<c10ebf3d>] ? handle_mm_fault+0xfd/0x210
[ 4921.272959] [<c10289f0>] ? vmalloc_sync_all+0x120/0x120
[ 4921.272965] [<c134a0d5>] rwsem_down_failed_common+0x95/0xe0
[ 4921.272970] [<c134a132>] rwsem_down_write_failed+0x12/0x20
[ 4921.272975] [<c134a19a>] call_rwsem_down_write_failed+0x6/0x8
[ 4921.272981] [<c13499ea>] ? down_write+0x1a/0x1c
[ 4921.272986] [<c10f02a8>] sys_mmap_pgoff+0xd8/0x1c0
[ 4921.272991] [<c134b31f>] sysenter_do_call+0x12/0x28
[ 4921.272996] [<c1340000>] ? cpu_callback+0x3a/0x289
[ 5041.272875] INFO: task firefox-bin:1371 blocked for more than 120 seconds.
[ 5041.272880] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 5041.272884] firefox-bin D f2f85f2c 0 1371 1186 0x00000000
[ 5041.272891] f2f85f3c 00200086 00000002 f2f85f2c 00000000 00000031 802c6004 00000000
[ 5041.272902] 00000000 00000001 c103d509 f2ee1ea0 f54032b8 f5403360 c1465e40 c1527480
[ 5041.272911] f2f85edc c1527480 f5406480 f2ee1ea0 c1463fe0 2af9d067 802f4000 55315437
[ 5041.272921] Call Trace:
[ 5041.272934] [<c103d509>] ? scheduler_tick+0xa9/0x220
[ 5041.272941] [<c10ebf3d>] ? handle_mm_fault+0xfd/0x210
[ 5041.272947] [<c10289f0>] ? vmalloc_sync_all+0x120/0x120
[ 5041.272953] [<c134a0d5>] rwsem_down_failed_common+0x95/0xe0
[ 5041.272958] [<c134a132>] rwsem_down_write_failed+0x12/0x20
[ 5041.272963] [<c134a19a>] call_rwsem_down_write_failed+0x6/0x8
[ 5041.272969] [<c13499ea>] ? down_write+0x1a/0x1c
[ 5041.272974] [<c10f02a8>] sys_mmap_pgoff+0xd8/0x1c0
[ 5041.272979] [<c134b31f>] sysenter_do_call+0x12/0x28
[ 5041.272985] [<c1340000>] ? cpu_callback+0x3a/0x289
[ 5161.272869] INFO: task firefox-bin:1371 blocked for more than 120 seconds.
[ 5161.272873] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 5161.272877] firefox-bin D f2f85f2c 0 1371 1186 0x00000000
[ 5161.272885] f2f85f3c 00200086 00000002 f2f85f2c 00000000 00000031 802c6004 00000000
[ 5161.272895] 00000000 00000001 c103d509 f2ee1ea0 f54032b8 f5403360 c1465e40 c1527480
[ 5161.272904] f2f85edc c1527480 f5406480 f2ee1ea0 c1463fe0 2af9d067 802f4000 55315437
[ 5161.272914] Call Trace:
[ 5161.272927] [<c103d509>] ? scheduler_tick+0xa9/0x220
[ 5161.272934] [<c10ebf3d>] ? handle_mm_fault+0xfd/0x210
[ 5161.272940] [<c10289f0>] ? vmalloc_sync_all+0x120/0x120
[ 5161.272946] [<c134a0d5>] rwsem_down_failed_common+0x95/0xe0
[ 5161.272951] [<c134a132>] rwsem_down_write_failed+0x12/0x20
[ 5161.272956] [<c134a19a>] call_rwsem_down_write_failed+0x6/0x8
[ 5161.272962] [<c13499ea>] ? down_write+0x1a/0x1c
[ 5161.272967] [<c10f02a8>] sys_mmap_pgoff+0xd8/0x1c0
[ 5161.272973] [<c134b31f>] sysenter_do_call+0x12/0x28
[ 5161.272978] [<c1340000>] ? cpu_callback+0x3a/0x289
[ 5161.272995] INFO: task pkill:2886 blocked for more than 120 seconds.
[ 5161.272998] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 5161.273001] pkill D c2201e50 0 2886 1 0x00000004
[ 5161.273007] c2201e60 00200086 00000002 c2201e50 f3e39c00 c2201de0 c220e208 f32b9918
[ 5161.273016] 00000000 c1409b29 00000000 00000000 00000000 f32b9918 c220e208 c1527480
[ 5161.273025] c2201e14 c1527480 f5506480 f4060d20 f4063020 c220e200 00000001 000a00d0
[ 5161.273035] Call Trace:
[ 5161.273042] [<c112eb7a>] ? mntput_no_expire+0x2a/0xd0
[ 5161.273047] [<c134a0d5>] rwsem_down_failed_common+0x95/0xe0
[ 5161.273052] [<c134a152>] rwsem_down_read_failed+0x12/0x14
[ 5161.273056] [<c134a18f>] call_rwsem_down_read_failed+0x7/0xc
[ 5161.273062] [<c13499c2>] ? down_read+0x12/0x20
[ 5161.273066] [<c10ec568>] __access_remote_vm+0x28/0x170
[ 5161.273072] [<c104366e>] ? get_task_mm+0x3e/0x60
[ 5161.273076] [<c10ec8fb>] access_process_vm+0x4b/0x70
[ 5161.273083] [<c115d855>] proc_pid_cmdline+0x75/0xf0
[ 5161.273088] [<c115df27>] proc_info_read+0x77/0xc0
[ 5161.273093] [<c1114a98>] vfs_read+0x88/0x160
[ 5161.273098] [<c115deb0>] ? proc_loginuid_read+0xc0/0xc0
[ 5161.273102] [<c1114bad>] sys_read+0x3d/0x70
[ 5161.273107] [<c134b31f>] sysenter_do_call+0x12/0x28
as you can see its even sometimes not possible to kill the process. I didnt used the normal kernel and didnt tried it with another yet.
Linux pc 2.6.39-ARCH #1 SMP PREEMPT Sat Jul 9 15:31:04 CEST 2011 i686 Intel(R) Pentium(R) D CPU 2.80GHz GenuineIntel GNU/Linux
Somebody knows the problem?
Thanks! && best regards bert2002

fukawi2 wrote:
I used to get this on several CentOS boxes, but I never got a solution...
Are you able to strace the process before it happens?
Not yet, but to get one it should be no problem since it occurs quite often. I will keep you updated when I got a strace.

Takes more than 90 seconds to start iTunes

When I start iTunes, Airtunes is trying to connect to my Airport Express for more than one minute. When I press "stop" in the "Connecting to Airport Express" dialog, iTunes is immediately launched and I can immediately stream music through the Airport Express.
This proves the AE is set up as it should (I suppose), so why is AirTunes taking so long to connect?
When I set Airtunes to use my "Computer" speakers, iTunes launches in a number of seconds. When swtiching the speakers back to AE, it's immediately streaming to AE.
What's wrong with my setup?
Just to be complete...AE is not showing in my Airport System Preferences, Advanced Options, "Show Networks"

I have the same problem. Did you find out how to fix it?

MacBookPro mid-2010 setting up WiFi connection takes more than 5 seconds

When I open the lid of my MacBookPro (mid-2010), it sets up the WiFi connection. This takes about five seconds. If I unlock my iPad, the connection is there almost immediately. Is there a way to speed up the MacBookPro, setting up the WiFi connection?
Still running Snow Leopard, not Lion.

Have a cup of coffee while you wait the five seconds.

Task blocked for more than 120 seconds

Oracle Linux 5.6 on VBox 4.3.12, on Windows 7 Pro, 64bit with 16gb of memory.
I've been picking at this problem for quite some time. Posted some time back on the vbox.org forum, then later on the OTN Vbox forum when I discovered it. No help there so thought I'd try attacking it from a Linux point of view.
First off --
oracle:+ASM$ uname -a
Linux vbdwprod.vbdomain 2.6.18-238.1.1.0.1.el5 #1 SMP Thu Jan 20 23:52:48 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
Here's the problem. After a VM has been up for a while it throws the following:
And the real frustration comes in that I can anticipate when it will throw this error because everything -- and I mean everything - else running on the host comes grinding to a halt. Most other applications will start showing "Not responding". Even if they don't show that in their title bar, they do stop responding. Even getting Windows Task Manager up can be painfully slow, and when it does come up, it shows no stress on the CPU - still up around 95% idle.
I'm thinking some sort of clock timing issue between the guest and host, but that is really outside of my expertise. I do add 'divisor=10' to my grub.conf as part of the initial build of all my vm's.
So, does anyone have any ideas what all this means and how I might address it?

Dude! wrote:
The divisor parameter helped to reduce CPU idle consumption. OL 5.6 ships with the UEK kernel as default, which is a tickless kernel, and does no longer need the "divisor=10" parameter that was used in the 5.5 and earlier versions.
What are the implications for my kernel and version? This vm was built to be my personal test counterpart to one of my 'live' servers, so I wanted to keep kernel and version as close to that as I could.
When did you start to experience this problem? Was this working before or is this a new installation?
It's been intermittent, but experienced on 3 different host machines. I haven't kept such close records, but if I had to guess when it started it would be at one of the upgrades to vbox. I'll dig back through my posting history at virtualbox.org and see if I can spot anything relevant.
If it worked before, chances are that you have a hardware issue, e.g. dying disk or faulty memory. Or perhaps your virtual disk got corrupted or someting else is causing problems. Since you are on Windows, there is antivirus, defragmetnation tools, etc. that can cause very strange affect to systems inside a virtual machine.
Yeah, the first time I brought this up on virtualbox.org, they insisted it had to be a corrupt hard drive on the host. Wouldn't even entertain the possibility of anything else. Never mind the fact that it was occurring on two different machines at the time, never mind the fact that absolutely nothing else on either machine indicated any HD issues - including a very thorough Windows disk analysis.
Personally I have not been too happy with VirtualBox
I've had a love/hate relationship with it ever since I switched from VMWorkstation.
4.3 and found 4.2 more compatible and usable, but I think before anything else you might want upgrade to 4.3.18 and also update to OL 5.11 and see if the problem persists. Both tasks are very easy to accomplish.
Given my usage of this VM, I'd have to think long and hard about version changes on the OS. Perhaps a point upgrade like that really isn't relevant to my concerns - I just don't know enough about that area.
Changing the version of VBox is definitely a possibility.
One other thing that might factor in somehow, and seems to relate to the link posted by Wadhah DAOUEHI, above. When the machine is in this state and I am finally able to get Task Manger and Resource Monitor open, the one thing that seems "out there" is disk activity. Resource Monitor will show the disk (C; drive on the host) nearly maxed out, with over a million total b/sec attributed to vbox.exe. That is several orders of magnitude greater than any of the other processes.
In one sense, I think I'm more concerned about why this is having such an impact on all other operations on the host. The error as reported by the linux machine seems to be a bit of a transient, eventually getting cleared and things moving one. But as I said, until that occurs, I can't really get anything else done either.

Opening PDF-files in Outlook 2007 takes more than 30 seconds.

Some of our users get multiple PDF-files as attachments in their Outlook 2007 mailbox. (In Citrix)
They have to read and print multiple PDF-files per day,
It takes them at least 30 seconds before the attachement opens, then another 30 seconds before the printoptions appears, and then another 30 seconds to give the actual printorder.
If yoy have to process 50-100 of those per day it is very annoying.
Does anywhone have a solution for this?
We work with Acrobat 10 and 11

Just for the heck of it, I renamed a FDF file to a PDF file and tried to open it, no go. I was able to import a FDF to the original PDF. The install option is a bit of an issue and I am not sure what to say to that. It may be looking for the PDF file on the hard drive and not actually be trying to install Acrobat. I opened a FDF in the same folder as the PDF and it opened right up. Otherwise, I think the location of the PDF has to be encoded in the FDF file. The form name is typically at the end of the FDF file (OPEN in notepad or such to look at the details of the FDF). You will not that it does not start as %PDF, but %FDF.
As I mentioned, Acrobat is likely looking for the original document listed at the end of the FDF file.

Why does my MBP 2011 take more than 90 seconds to boot and be usable

MBP 13" 2011, OS 10.9.4, 4G RAM
The boot time from press start to when I can use my MAC is excruciating, at least 90 seconds.
I have REPAIRED DISK PERMISSIONS AFTER EACH UPDATE OF SOFTWARE,
I have created a Guest Account and the 'start/to use time is 1/3.
I have NO 3rd party software, all Apple,
My iPhono Library is only? 10.5G
I have reset the SMC-Shift/Control/Option-hold- start
Once the Mac is up and running it seems to run ok with Safari, Mail running, but add to that NUMBERS or Garage Band 10, (fagedabowdit),
so, short of more patience, or RAM, any suggestions on this LOOOOOOOONG boot time?
Thank you all
jojoguitar
Message was edited by: jojoguitar

Ok, I'm gonna re-read this Transferring files from one User Account to another coupla times. Trying to see how I can see both accounts/homes at the same time.
Is this the home folder items on the right I copy and paste into the new HOME on the newly created Admin Account (using a different name)? So I select the the 10 folders, select copy and I assume all content is copied as well and then paste that into.....ok, I'll bug off and read and re-read and then decide to try--or not.
This has been good, your help is spot on.
jojoguitar

[Solved] dhcpcd Takes more than 9 seconds to start up. How to lower?

Hi, I've tried many things to optimize my boot time, but the only one I'm very unhappy about is the time it takes for dhcpcd...
When I use "systemd-analyze", it says:
Startup finished in 6315ms (kernel) + 11435ms (userspace) = 17750ms
Also "systemd-analyze blame", says:
9576ms [email protected]
276ms systemd-vconsole-setup.service
276ms systemd-remount-fs.service
206ms systemd-udev-trigger.service
121ms systemd-sysctl.service
110ms systemd-modules-load.service
106ms dev-hugepages.mount
101ms sys-kernel-debug.mount
84ms systemd-udevd.service
60ms dev-mqueue.mount
57ms systemd-tmpfiles-setup.service
23ms tmp.mount
23ms home.mount
15ms systemd-user-sessions.service
14ms systemd-logind.service
I did install e4rat and am currently using it. My /etc/rc.conf contains only this:
DAEMONS=(vboxservice)
I'm running ArchLinux as a guest in virtualbox (host is Windows 7) If you need anymore information, please tell me. I've been wondering why my dhcpcd takes >9500 ms just to starting up. Also, before using e4rat, I've got >5000 ms for dhcpcd instead of >9500. And before using e4rat, I get around 10000 ms, not 17000. However, I'm completely satisfied with all of the other times that it takes to start up the other processes, only dhcpcd seemed to increase, not decrease.
Thanks.
Last edited by reportados (2012-12-16 01:09:14)

rebootl wrote:
Maybe see this: https://wiki.archlinux.org/index.php/Ne … ith_dhcpcd
Don't know if it makes sense to add it globally, or how it could be done only on boot w/o netcfg...
Thanks! This fixed my problem! From ~17000 ms to ~7000 ms when running systemd-analyze. If I run systemd-analyze blame I get this:
462ms systemd-vconsole-setup.service
439ms systemd-remount-fs.service
153ms systemd-udev-trigger.service
121ms [email protected]
106ms systemd-sysctl.service
97ms systemd-modules-load.service
93ms dev-hugepages.mount
83ms sys-kernel-debug.mount
49ms systemd-tmpfiles-setup.service
46ms dev-mqueue.mount
43ms systemd-udevd.service
32ms tmp.mount
26ms home.mount
20ms systemd-user-sessions.service
17ms systemd-logind.service
Editing /etc/dhcpcd.conf and appending "noarp" cuts down the time significantly! Thanks a lot.

Xorg takes more than two seconds before start

I was trying to speed up my boot process yesterday.
but, there is a problem that xorg starts slow.
http://miko.tw/~virtuemood/bootchart.png
it hangs before it starts.
what should I do?
Last edited by virtuemood (2009-07-17 10:48:50)

I remove some line from my xinitrc .
but,It start up more slowly ...
this is my xinitrc:
==================
#!/bin/sh
export LC_CTYPE="zh_TW.UTF-8"
export LC_NAME="zh_TW.UTF-8"
export LC_ALL="zh_TW.UTF-8"
/usr/bin/xfce4-panel &
/usr/bin/xfdesktop &
export GCIN_XIM=gcin
export XMODIFIERS=@im=gcin
export XIM_PROGRAM=gcin
export GTK_IM_MODULE=gcin
if [ ifconfig -a|grep eth1 ]
then syndaemon -d -i 0.2
else numlockx on
fi
exec /usr/bin/openbox
==================
Last edited by virtuemood (2009-07-18 16:39:16)

Client takes more than 120 seconds connecting to server

Similar Messages

Maybe you are looking for