RE: VTI hitting the blocked state (was RE: [PATCH][RESEND]RE:[Xen-ia64-devel] [PATCH 0/6] Add fullevtchnmechanism for xen/ia64)

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Alex Williamson [mailto:alex.williamson@xxxxxx]
>Sent: 2006年5月25日 2:55
>
>On Wed, 2006-05-24 at 09:46 -0600, Alex Williamson wrote:
>> On Tue, 2006-05-23 at 23:48 -0600, Alex Williamson wrote:
>> >    It appeared to be stuck in the "-b----" state as shown by xm list,
>> > but let me do some verification tomorrow.  Thanks for testing this.
>I'm
>> > running UP dom0 + 4-way SMP domU + UP domVTI on an 8 thread
>(4 core)
>> > system.  Thanks,
>>
>>    Actually, running networking in domU concurrently accelerates the
>> problem, but is not required.  I hit it again with only a domVTI
>> running.  I'm pulling a 512MB empty file from another server and
>writing
>> it to /dev/null using wget.  At some point it just stops and xm list
>> reports the domain as blocked.  There's nothing in xend.log or
>> xend-debug.log to indicate something went bad.  The qemu-dm
>process has
>> select listed in it's wait channel, so seems like it's ok.  Thanks,
>
>  I hit this again building a kernel in a domVTI (RHEL4U3 guest).  I was
>only using the network for an ssh login.  The build ran for a while,
>consumed 3600+ seconds as reported by xm list, but is now stuck in the
>blocked state.  Thanks,
>
>       Alex

VTI network has not been tested aggressively and thus your observation 
is new and we'll take a look.

I'll try again by following your steps. As a confirmation required from you:
        - Simple dom0+domVTI can trigger the block issue. DomU can 
accelerate
        - dom0 and domVTI are running on different processors.
        - can that happen steadily? If not, how about the frequency.
        - which test case do you propose to try? 'wget' or KB. Previously I 
always try with wget.

Thanks,
Kevin

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