[Xen-ia64-devel] [PATCH][RFC] correction trouble of short message in UDP

[Tomonari Horikoshi]

Hi all.

I modified the patch to the following trouble.

When I executed netperf by a short message of UDP, 
 PV domain issued Call trace.

This error occurs because earliness grant is filled from 
the queue check of tx_slot when a lot of message is sent. 

I stopped Add netfornt tx_queue_len being used, and I was added to check 
gnttab_empty_grant_references() in netfront_tx_slot_available().


I confirmed the not error because of this correction. 
Is there a better correction?


Best regards.

Tomonari Horikoshi,


Tomonari Horikoshi wrote:--
Sent:Thu, 25 Jan 2007 13:44:30 +0900
Subject: Re: [Xen-devel] [PATCH] Add netfornt tx_queue_len

 Hi Herbert-san
 
 Thank you for your comment.
 
 I agreed.
 I examine the another way. 
 
 It is likely to go well if something is added to the check 
 on netfront_tx_slot_available(). 
 
 Best regards.
 
 Tomonari Horikoshi,
 
 Herbert Xu wrote:--
 Sent:Wed, 24 Jan 2007 13:29:51 +1100
 Subject: Re: [Xen-devel] [PATCH] Add netfornt tx_queue_len
 
  On Wed, Jan 24, 2007 at 01:37:55AM +, Tomonari Horikoshi wrote:
   
   When I executed netperf by a short message of UDP, 
   PV domain and PV-on-HVM driver issued Call trace.
   
   I think that GrantEntry was filled with a lot of messages processings.
   
   This problem is generated in IA64 only.
   Probably, I think that I am the following problems. 
   
 In IA64
   NET_TX_RING_SIZE 1024,  NR_GRANT_ENTRIES 2048
 In x86
   NET_TX_RING_SIZE  256,  NR_GRANT_ENTRIES 2048
   
   I corrected to check number of unprocessing queue  tx_queue_len before 
   Grant was filled.
   
   However, my correction influences x86. 
   Please teach to me in that when there is a better improvement. 
  
  Sorry, but this patch looks bogus.  The tx queue is maintained by
  Linux and has nothing to do with the driver.  So limiting its length
  based on internal state of the driver can't be right.
  
  We need to find out what's really going wrong with the grant table
  entries here.
  
  Cheers,




netfront_chk_grant.patch
Description: Binary data
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

Re: [Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dumpcore is failed for PAL_HALT)

[Akio Takebe]

Hi, Alex and all

Machine restart/reboot should (and does) happen transparently when Xen
catches the EFI call.  To support poweroff, I think we should set
pm_power_off to a Xen specific hypervisor shutdown routine.  The
abstraction is already in place to do this.
OK, I'll try it.

pm_power_off is not called from machine_halt().
So if we use halt command to shutdown domain,
we cannot halt system...
But is this ia64 achtecture specific?

I think notifier_chain of ia64die_chain is the best choice.
Which is good patch?

Signed-off-by: Akio Takebe [EMAIL PROTECTED]

Best Regards,

Akio Takebe

pm_power_off_version.patch
Description: Binary data


notifier_call_version.patch
Description: Binary data
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

RE: [Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dumpcore is failed for PAL_HALT)

[Akio Takebe]

Hi, Anthony

In VTI side, ACPI is emulated by ACPI module of Qemu.
I think it supports S5.
Good news. But I look like Qemu don't trap acpi_power_off called by linux on 
VTI.
I'll investigate it.

Best Regards,

Akio Takebe


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

[Xen-ia64-devel][PATCH] Remove dead code

[Xu, Anthony]

Remove dead code,


- Anthony


remove_XEN_DBL_MAPPING.patch
Description: remove_XEN_DBL_MAPPING.patch
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel