search for: do_select

https://bugs.freedesktop.org/show_bug.cgi?id=90482 Bug ID: 90482 Summary: Xorg take 100% CPU when using multiple independent screen configuration Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium

...16 zen kernel: [skb_checksum+317/704] skb_checksum+0x13d/0x2c0 Jun 2 12:13:16 zen kernel: [__pollwait+140/208] __pollwait+0x8c/0xd0 Jun 2 12:13:16 zen kernel: [udp_poll+154/352] udp_poll+0x9a/0x160 Jun 2 12:13:16 zen kernel: [sock_poll+41/64] sock_poll+0x29/0x40 Jun 2 12:13:16 zen kernel: [do_select+611/752] do_select+0x263/0x2f0 Jun 2 12:13:16 zen kernel: [__pollwait+0/208] __pollwait+0x0/0xd0 Jun 2 12:13:16 zen kernel: [sys_select+731/1264] sys_select+0x2db/0x4f0 Jun 2 12:13:16 zen kernel: [__fput+187/304] __fput+0xbb/0x130 Jun 2 12:13:16 zen kernel: [sys_close+97/160] sys_close+0x61...

...lt;c0121178>] local_bh_enable+0x47/0x6f Dec 2 16:05:21 noc kernel: [<c02177d5>] skb_checksum+0x133/0x25e Dec 2 16:05:21 noc kernel: [<c0250f06>] udp_poll+0x66/0x113 Dec 2 16:05:21 noc kernel: [<c02135fd>] sock_poll+0x19/0x1d Dec 2 16:05:21 noc kernel: [<c016d1a6>] do_select+0x190/0x2c7 Dec 2 16:05:21 noc kernel: [<c016ceb5>] __pollwait+0x0/0x9b Dec 2 16:05:21 noc kernel: [<c0144ae4>] __kmalloc+0x56/0xd3 Dec 2 16:05:21 noc kernel: [<c016d5dc>] sys_select+0x2e7/0x45c Dec 2 16:05:21 noc kernel: [<c010740f>] syscall_call+0x7/0xb Any idea w...

...ode+111/132] [clear_inode+0/132] [dispose_list+28/88] [try_to_free_inodes+204/260] [try_to_free_inodes+223/260] [update_wall_time+18/72] Aug 16 11:33:15 asc_server kernel: [cprt+9024/38422] [grow_inodes+32/428] [get_new_inode+197/304] [iget+103/116] [ext2_lookup+90/140] [real_lookup+91/180] [do_select+487/512] [lookup_dentry+304/504] Aug 16 11:33:15 asc_server kernel: [getname+95/156] [__namei+49/104] [sys_newstat+20/116] [system_call+52/64] Aug 16 11:33:15 asc_server kernel: Code: 89 50 04 89 02 5b 83 c4 18 c3 89 f6 83 ec 18 53 8b 5c 24 20 ... /var/log/messages ... Aug 16 11:30:01 asc_...

...4_ind_map_blocks+0xb9b/0xc20 [ext4] [ 1085.193968] [<ffffffffa94c6258>] ? hrtimer_cancel+0x28/0x40 [ 1085.193973] [<ffffffffa95d82c8>] ? zone_statistics+0x88/0xa0 [ 1085.193987] [<ffffffffc1bdfd35>] ext4_map_blocks+0x295/0x6e0 [ext4] [ 1085.193993] [<ffffffffa9657c7e>] ? do_select+0x73e/0x7c0 [ 1085.193999] [<ffffffffa961c0b2>] ? kmem_cache_alloc+0x1c2/0x1f0 [ 1085.194006] [<ffffffffa96787b1>] ? alloc_buffer_head+0x21/0x60 [ 1085.194018] [<ffffffffc1be035f>] _ext4_get_block+0x1df/0x220 [ext4] [ 1085.194030] [<ffffffffc1be03b6>] ext4_get_block+0x16...

...[...] var/spool/postfix/incoming/F/1/ var/spool/postfix/incoming/F/2/ var/spool/postfix/incoming/F/3/ var/spool/postfix/maildrop/ var/tmp/ and then nothing more happens, it's blocked there. ps shows that the three rsync processes are syspended waiting on do_sel (do_select). A dead-lock I would say. [root@thalassa root]# ps axflww | egrep rsync\|RSS\|backup F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 000 0 19243 22982 9 0 2448 136 wait4 S pts/2 0:00 \_ /bin/bash /local/sbin/do-backup 004 0 19458 1...

...kernel: [<ffffffff81094b70>] ? hrtimer_wakeup+0x0/0x30 Jan 12 10:16:39 name kernel: [<ffffffff81095bd4>] ? hrtimer_start_range_ns+0x14/0x20 Jan 12 10:16:39 name kernel: [<ffffffff8118b079>] ? poll_schedule_timeout+0x39/0x60 Jan 12 10:16:39 name kernel: [<ffffffff8118b6e8>] ? do_select+0x578/0x6b0 Jan 12 10:16:39 name kernel: [<ffffffff8104d80d>] ? check_preempt_curr+0x6d/0x90 Jan 12 10:16:39 name kernel: [<ffffffff8118b820>] ? __pollwait+0x0/0xf0 Jan 12 10:16:39 name kernel: [<ffffffff8118b910>] ? pollwake+0x0/0x60 Jan 12 10:16:39 name kernel: [<ffffffff8118...

...000e65 00000cad 00000003 f7bacbac c302a9e0 c042daae f7d20000 f1c87b70 00000286 ffffffff 00000000 00000000 00ed957a 00ed957a Call Trace: [<c042daae>] lock_timer_base+0x15/0x2f [<c0604dfc>] schedule_timeout+0x71/0x8c [<c042d1d3>] process_timeout+0x0/0x5 [<c04803a8>] do_select+0x371/0x3cb [<c048092b>] __pollwait+0x0/0xb2 [<c04202b1>] default_wake_function+0x0/0xc [<c04202b1>] default_wake_function+0x0/0xc [<c06046b9>] schedule+0x90d/0x9ba [<c0436066>] autoremove_wake_function+0xd/0x2d [<c042daae>] lock_timer_base+0x15/0x2f [<...

...75 0000000000000000 00000000000a1e58 000001060006aa80 0000000e00000246 0000010037ecb7f0 0000000000001b5d Call Trace:<ffffffff8013fa18>{__mod_timer+293} <ffffffff8030a1ef>{schedule_timeout+367} <ffffffff80140442>{process_timeout+0} <ffffffff8018add7>{do_select+939} <ffffffff8018a971>{__pollwait+0} <ffffffff8018b156>{sys_select+820} <ffffffff8011026a>{system_call+126} migration/0 S 0000010008002a20 0 2 1 3 (L-TLB) 00000102fc72dec8 0000000000000046 0000010100069760 0000000000000002 00000...

...n di->d_name; #endif } + +/** + * A wrapper around select(2) that guarantees Linux-like updating of + * the timeout argument to contain the time left, so we can simply + * re-invoke in case of EINTR or EAGAIN. On BSD, select(2) doesn't + * change the timeout argument by itself. + **/ +int do_select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout) +{ + if (timeout==NULL) { + return select(n, readfds, writefds, exceptfds, timeout); + } else { + struct timeval intended, before, after; + int result; + + intended = *timeout; + gettimeofday(&before,...

...rentuc kernel: 00002000 c0d2df1c c021d804 016bb3f0 c0d0c000 c011121c 00000000 c012f821 Mar 5 11:14:59 trentuc kernel: c06bd994 0000000e c06bd998 0000002d 00000104 0000000e c0d0c000 00000062 Mar 5 11:14:59 trentuc kernel: Call Trace: [schedule_timeout+108/140] [process_timeout+0/16] [do_select+157/532] [sys_select+1014/1360] [syst em_call+52/56] Mar 5 11:14:59 trentuc kernel: Code: 89 42 40 89 50 3c c7 43 3c 00 00 00 00 c7 43 40 00 00 00 00 any ideas would be appreciated Coruscare icq 37404155 ------------------------------------------------------------- Sign up for ICQmail at ht...

...144281>] __get_free_pages+0x18/0x24 Sep 20 13:35:31 hagar kernel: [<c016b3a2>] __pollwait+0x2d/0x95 Sep 20 13:35:35 hagar kernel: [<c029d7c1>] tcp_poll+0x31/0x146 Sep 20 13:35:35 hagar kernel: [<c0278741>] sock_poll+0x12/0x14 Sep 20 13:35:36 hagar kernel: [<c016b645>] do_select+0x196/0x2c6 Sep 20 13:35:37 hagar kernel: [<c016b375>] __pollwait+0x0/0x95 Sep 20 13:35:37 hagar kernel: [<c016ba68>] sys_select+0x2e0/0x43a Sep 20 13:35:38 hagar kernel: [<c02d47bf>] syscall_call+0x7/0xb Sep 20 13:35:38 hagar kernel: [<c02d007b>] packet_rcv+0x18a/0x307...

...02dd665>] tcp_poll+0x31/0x144 Feb 4 00:08:24 server1 kernel: [<c0188fc8>] destroy_inode+0x3d/0x4c Feb 4 00:08:24 server1 kernel: [<c018b1e2>] iput+0x5f/0x61 Feb 4 00:08:24 server1 kernel: [<c02b40f4>] sock_poll+0x12/0x14 Feb 4 00:08:24 server1 kernel: [<c0180cca>] do_select+0x25c/0x378 Feb 4 00:08:24 server1 kernel: [<c0180935>] __pollwait+0x0/0x94 Feb 4 00:08:24 server1 kernel: [<c01810d9>] sys_select+0x2e0/0x43a Feb 4 00:08:24 server1 kernel: [<c02b520c>] sys_socketcall+0x10c/0x1fb Feb 4 00:08:24 server1 kernel: [<c0318eeb>] syscall_c...

...00 c4afe4d4 00000007 c4afe4d8 00000026 Feb 18 14:39:54 file kernel: 00000145 00000007 c560c000 000016f8 00000000 c2d1a000 c012dd0a 00000007 Feb 18 14:39:54 file kernel: c560dfa8 c560dfa4 c560c000 00000000 bffffc4c bffffc54 c4afe4cc 0000000a Feb 18 14:39:54 file kernel: Call Trace: [do_select+509/532] [sys_select+1014/1360] [system_call+52/56] [startup_32+43/286] Feb 18 14:39:54 file kernel: Code: 8b 47 04 89 c6 c1 e6 04 03 77 08 85 c0 74 3d 90 48 89 47 04 Due to our own research in Samba-related Mail archives and FAQs, we think that the problem may have something to do with very lon...

...6fe>] avc_has_perm_noaudit+0xb8/0x11b [<021846ee>] selinux_file_ioctl+0x2f6/0x303 [<021817a0>] avc_has_perm+0x3f/0x49 [<12a83157>] zt_chan_ioctl+0x77/0xb30 [zaptel] [<02281e48>] schedule_timeout+0x13/0x99 [<0214fdec>] poll_freewait+0x33/0x3a [<02150199>] do_select+0x265/0x279 [<0213639b>] follow_page_pfn+0xec/0xfd [<0213fe44>] rw_vm+0x1f8/0x218 [<0213639b>] follow_page_pfn+0xec/0xfd [<12a7f60a>] zt_ioctl+0x5a/0x100 [zaptel] [<0214f7f6>] sys_ioctl+0x1f2/0x224 [<0211a7c3>] sys_time+0x2b/0x3d ======================= [...

...14f7f4>] __get_free_pages+0x18/0x24 Jul 3 04:02:03 lvs2 kernel: [<c018083e>] __pollwait+0x2d/0x94 Jul 3 04:02:03 lvs2 kernel: [<c02b8ca0>] datagram_poll+0x25/0xc5 Jul 3 04:02:03 lvs2 kernel: [<c02b2d28>] sock_poll+0x12/0x14 Jul 3 04:02:03 lvs2 kernel: [<c0180ba5>] do_select+0x25b/0x377 Jul 3 04:02:03 lvs2 kernel: [<c0180811>] __pollwait+0x0/0x94 Jul 3 04:02:03 lvs2 kernel: [<c0180fb1>] sys_select+0x2dd/0x437 Jul 3 04:02:03 lvs2 kernel: [<c016db16>] sys_fsync+0xcd/0xd5 Jul 3 04:02:03 lvs2 kernel: [<c0317637>] syscall_call+0x7/0xb Jul 3...

changeset: 8830:fcc833cbaf82 tag: tip user: kaf24@firebug.cl.cam.ac.uk date: Mon Feb 13 10:41:23 2006 +0100 summary: Return real error code from Xen /dev/mem, not EAGAIN. x460: x86_32: Status: - dom0 boots fine - xend loads fine - single HVM domain loads fine - Multiple HVM domains load fine - destruction of any HVM domain causes dom0 to reboot Issues affecting

Hello, I've been consistently attempting to make the setup mentioned in the subject work on the following hardware: Xeon E3 1275 (v1, Sandy Bridge) Asus P8B WS (Firmware: 0904 and 2009) 16 GB RAM Sapphire Radeon HD 7950 OC (Firmware: 015.013.000.010.000705) Linux 3.4.1 dom0, x86-64, pvops. Xen 4.1.2 (+ security patch) and 4.1.3-rc1. Old qemu-dm setup. (not new mainline qemu) Windows 7 64-bit

Hello I recently switched from Nvidia binary driver to Nouveau. I have encountered a possible bug in the kernel module. Before I file a bug report I would like to know if this is a known issue or not. I believe it is related to sleep state and power management of the driver. The Bug: When the computer is left on it's own to go to a power save mode X takes 100% CPU-time in its thread. A

(The list appears to have eaten my previous attempt to send this. Apologies if you receive multiple copies.) The attached patches allow you to use paravirtualised network and block interfaces from fully virtualised domains, based on Intel''s patches from a few months ago. These are significantly faster than the equivalent ioemu devices, sometimes by more than an order of magnitude.