WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] tg3 network stall in xen-3.4.x but not in xen-3.3.x

To: Teck Choon Giam <giamteckchoon@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] tg3 network stall in xen-3.4.x but not in xen-3.3.x
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Mon, 06 Jul 2009 08:19:01 +0100
Cc:
Delivery-date: Mon, 06 Jul 2009 00:19:28 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <9b5c9bb30907052055i58bd373bjdeeb533a7bc3d64@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acn97aM4NxE1hOfhTLS9GXiT2odglwAHGW5m
Thread-topic: [Xen-devel] tg3 network stall in xen-3.4.x but not in xen-3.3.x
User-agent: Microsoft-Entourage/12.19.0.090515
On 06/07/2009 04:55, "Teck Choon Giam" <giamteckchoon@xxxxxxxxx> wrote:

>> Hmm, that's rather disturbing. Its presumably the cpuidle parameter which is
>> having the effect. Quite why deeper sleep states can result in one particular
>> device interrupt getting stuck (as opposed to all of them) is a mystery. It
>> might be interesting to see the boot messages, and also to find out which of
>> the C states is causing the problem (presumably C2 or C3).
> 
> If I do not add cpuidle and cpufreq in xen boot para. I got the below:
> 
> # xenpm get-cpuidle-states
> Max C-state: C1
> 
> cpu id               : 0
> total C-states       : 2

That's interesting, since it appears the troublesome system does not even
support deep sleep states (e.g., C3). Just C0 and C1: which would normally
mean C0=running, C1=normal-HLT. I've cc'ed a couple of Intel guys to confirm
we couldn't be misreading the xenpm output.

If we're reading this correctly I think it really means that the special
acpi-cx idle handler has a bug in it somewhere. Actually one bug has been
found already, and I will forward the patch to you. It could be worth
applying it and rebuilding Xen and see if we're lucky enough for that to
solve your problem.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel