From pinter@tresorium.hu  Mon Apr  2 04:11:29 2012
Return-Path: <pinter@tresorium.hu>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 04BDF106564A
	for <FreeBSD-gnats-submit@freebsd.org>; Mon,  2 Apr 2012 04:11:29 +0000 (UTC)
	(envelope-from pinter@tresorium.hu)
Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50])
	by mx1.freebsd.org (Postfix) with ESMTP id 898878FC14
	for <FreeBSD-gnats-submit@freebsd.org>; Mon,  2 Apr 2012 04:11:27 +0000 (UTC)
Received: by wgbds12 with SMTP id ds12so2173683wgb.31
        for <FreeBSD-gnats-submit@freebsd.org>; Sun, 01 Apr 2012 21:11:20 -0700 (PDT)
Received: by 10.180.104.65 with SMTP id gc1mr20757364wib.13.1333339880821;
        Sun, 01 Apr 2012 21:11:20 -0700 (PDT)
Received: from peonia (peonia.teteny.elte.hu. [157.181.96.25])
        by mx.google.com with ESMTPS id n15sm30734016wiw.6.2012.04.01.21.11.19
        (version=TLSv1/SSLv3 cipher=OTHER);
        Sun, 01 Apr 2012 21:11:19 -0700 (PDT)
Message-Id: <201204020608.43755.pinter@tresorium.hu>
Date: Mon, 2 Apr 2012 06:08:43 +0200
From: Oliver Pinter <pinter@tresorium.hu>
To: FreeBSD-gnats-submit@freebsd.org
Cc: oliver.pntr@opn.teteny.bme.hu,
 mav@freebsd.org
Subject: [ULE] intr stucked in WAIT state

>Number:         166568
>Category:       kern
>Synopsis:       [sched_ule] intr stuck in WAIT state
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Apr 02 04:20:10 UTC 2012
>Closed-Date:    
>Last-Modified:  Thu Apr 05 01:36:22 UTC 2012
>Originator:     Oliver Pinter
>Release:        FreeBSD 9.0-STABLE amd64
>Organization:
Tresorium Ltd.
>Environment:
System: FreeBSD opn 9.0-STABLE FreeBSD 9.0-STABLE #44 r233763+8676c89: Mon Apr 
2 05:17:04 CEST 2012 root@opn:/usr/obj/usr/src/sys/stable amd64


	
>Description:
last pid: 16662;  load averages:  1.02,  0.99,  0.97  up 0+01:28:12    
05:08:46
99 processes:  2 running, 96 sleeping, >>>>>>>>> 1 waiting <<<<<<<<<<
Mem: 167M Active, 768M Inact, 455M Wired, 1156K Cache, 258M Buf, 2440M Free
Swap: 4096M Total, 4096M Free



  PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   11 root          2 155 ki31     0K    32K CPU1    1 148:42 200.00% [idle]
   16 root          1 -16    -     0K    16K tzpoll  0   3:33  3.86% 
[acpi_therm
al]
25912 root          1  20    0   452M   330M select  0   1:04  
0.00% /usr/local/
bin/X -nolisten tcp -retro :0 -auth /var/lib/xd

 >>>>>>>>>>>>>>>>>>>>>
    12 root         17 -53    -     0K   272K WAIT    1   0:46  0.00% [intr]
 <<<<<<<<<<<<<<<<<<<<<
     0 root         11 -52    0     0K   176K -       1   0:24  0.00% [kernel]
 
>How-To-Repeat:
	compile 9-STABLE and boot
>Fix:
revert r233599

commit 1d9c514e52cc2aa97852f8ea946f28f6df62ab3a
Author: mav <mav@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Date:   Wed Mar 28 11:37:06 2012 +0000

    MFC r232207, r232454:
    Rework CPU load balancing in SCHED_ULE:

    [...]

    git-svn-id: svn://svn.freebsd.org/base/stable/9@233599 
ccf9f872-aa2e-dd11-9f

>Release-Note:
>Audit-Trail:

From: Andriy Gapon <avg@FreeBSD.org>
To: bug-followup@FreeBSD.org, pinter@tresorium.hu
Cc:  
Subject: Re: kern/166568: [sched_ule] intr stuck in WAIT state
Date: Mon, 02 Apr 2012 10:17:35 +0300

 Apologies, but could you please be a little bit less terse in describing what
 problem you are reporting?
 
 -- 
 Andriy Gapon

From: Andriy Gapon <avg@FreeBSD.org>
To: Oliver Pinter <oliver.pntr@gmail.com>, bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/166568: [sched_ule] intr stuck in WAIT state
Date: Mon, 02 Apr 2012 12:10:58 +0300

 Basically I don't understand what you mean by "stuck in WAIT state".
 What's so bad about the WAIT state in your opinion?  Why being in that state
 implies being "stuck"?
 As far as I understand it's a normal state for the interrupt threads when they
 are not servicing any interrupts.  Do you have a different understanding?
 
 -- 
 Andriy Gapon
>Unformatted:
