Xen devel - Jan 2007 - [PATCH] make balloon driver not return pages which are in [xen_start_info->nr_pages, max_pfn] on ia64

make balloon driver not return pages which are in
[xen_start_info->nr_pages, max_pfn] on ia64.
On ia64 memory might be assigned sparsely. In that case
xen_start_info->nr_pages and max_pfn doesn''t match while pages which
are in
[xen_start_info->nr_pages, max_pfn] are used.

-- 
yamahata


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

>>> Isaku Yamahata <yamahata@valinux.co.jp> 04.01.07 10:06
>>>
>make balloon driver not return pages which are in
>[xen_start_info->nr_pages, max_pfn] on ia64.
>On ia64 memory might be assigned sparsely. In that case
>xen_start_info->nr_pages and max_pfn doesn''t match while pages
which are in
>[xen_start_info->nr_pages, max_pfn] are used.
But where do you fill the balloon initially then instead, to support the case
where
one wants the domain to be able to grow its memory consumption?

Jan

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

On Thu, Jan 04, 2007 at 10:03:59AM +0000, Jan Beulich
wrote:
> >>> Isaku Yamahata <yamahata@valinux.co.jp> 04.01.07 10:06
>>>
> >make balloon driver not return pages which are in
> >[xen_start_info->nr_pages, max_pfn] on ia64.
> >On ia64 memory might be assigned sparsely. In that case
> >xen_start_info->nr_pages and max_pfn doesn''t match while
pages which are in
> >[xen_start_info->nr_pages, max_pfn] are used.
> 
> But where do you fill the balloon initially then instead, to support the
case where
> one wants the domain to be able to grow its memory consumption?
Xen/IA64 haven''t supported growing memory beyond
xen_start_info->nr_pages yet so far.
If it were supported on IA64, probably memory would have to be populated
sparsely to relfect underlying machine. So code would be more complex.

-- 
yamahata

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

Hi Keir,

   Any comments on this one?  With this and the patches we already have
in the xen-ia64-unstable tree we can eliminate our current dom0 memory
restrictions on ia64 (ie. allowing dom0 to have more that 1-2GB of
memory).  Thanks,

	Alex

On Thu, 2007-01-04 at 18:06 +0900, Isaku Yamahata wrote:
> make balloon driver not return pages which are in
> [xen_start_info->nr_pages, max_pfn] on ia64.
> On ia64 memory might be assigned sparsely. In that case
> xen_start_info->nr_pages and max_pfn doesn''t match while pages
which
> are in
> [xen_start_info->nr_pages, max_pfn] are used.
> 
> -- 
> yamahata
> 
> # HG changeset patch
> # User yamahata@valinux.co.jp
> # Date 1166688432 -32400
> # Node ID 222d8ad625624a4880d63c40d46907cd3ce23d86
> # Parent  407401ea3792efe50b713381e62ef59d3b0964fe
> make balloon driver not return pages which are in
> [xen_start_info->nr_pages, max_pfn] on ia64.
> On ia64 memory might be assigned sparsely. In that case
> xen_start_info->nr_pages and max_pfn doesn''t match while pages
which
> are in
> [xen_start_info->nr_pages, max_pfn] are used.
> PATCHNAME: fix_balloon_init
> 
> Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
> 
> diff -r 407401ea3792 -r 222d8ad62562
> linux-2.6-xen-sparse/drivers/xen/balloon/balloon.c
> --- a/linux-2.6-xen-sparse/drivers/xen/balloon/balloon.c        Thu
> Dec 21 15:36:31 2006 +0900
> +++ b/linux-2.6-xen-sparse/drivers/xen/balloon/balloon.c        Thu
> Dec 21 17:07:12 2006 +0900
> @@ -446,8 +446,10 @@ static struct notifier_block xenstore_no
>  
>  static int __init balloon_init(void)
>  {
> +#ifndef __ia64__
>         unsigned long pfn;
>         struct page *page;
> +#endif
>  
>         if (!is_running_on_xen())
>                 return -ENODEV;
> @@ -477,12 +479,14 @@ static int __init balloon_init(void)
>  #endif
>         balloon_sysfs_init();
>      
> +#ifndef __ia64__
>         /* Initialise the balloon with excess memory space. */
>         for (pfn = xen_start_info->nr_pages; pfn < max_pfn; pfn++) {
>                 page = pfn_to_page(pfn);
>                 if (!PageReserved(page))
>                         balloon_append(page);
>         }
> +#endif
>  
>         target_watch.callback = watch_target;
>         xenstore_notifier.notifier_call = balloon_init_watcher;
> 
-- 
Alex Williamson                             HP Open Source & Linux Org.


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

On 5/1/07 17:04, "Alex Williamson" <alex.williamson@hp.com>
wrote:
>    Any comments on this one?  With this and the patches we already have
> in the xen-ia64-unstable tree we can eliminate our current dom0 memory
> restrictions on ia64 (ie. allowing dom0 to have more that 1-2GB of
> memory).  Thanks,
It''s probably x86-specific code actually. I''ll ifdef it as
such which will
make it clear it really ought to get moved to an arch file.

 -- Keir


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

Hi,

I tried to load unmodified_drivers modules for vbd device and got error when 
doing insmod xen-platform-pci.ko in HVM Linux domain:
xen_platform_pci: disagrees about version of symbol struct_module
insmod: error inserting ''xen-platform-pci.ko'' : -1 invalid
module format.

I used the same kernel version for HVM Linux kernel and the kernel I was 
building unmodified_drivers, i.e. they are both 2.6.16.33. I tested 
xen-3.0.4-testing and xen-unstable, all got the same problem. Xen 3.0.2 with 
2.6.16.29 kernel version still works fine.

Could anyone point out some links to fix this?

Thanks,

Liang


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

On Fri, 2007-01-05 at 16:51 -0700, Liang Yang wrote:
> Hi,
> 
> I tried to load unmodified_drivers modules for vbd device and got error
when
> doing insmod xen-platform-pci.ko in HVM Linux domain:
> xen_platform_pci: disagrees about version of symbol struct_module
> insmod: error inserting ''xen-platform-pci.ko'' : -1
invalid module format.
> 
> I used the same kernel version for HVM Linux kernel and the kernel I was 
> building unmodified_drivers, i.e. they are both 2.6.16.33. I tested 
> xen-3.0.4-testing and xen-unstable, all got the same problem. Xen 3.0.2
with
> 2.6.16.29 kernel version still works fine.
> 
> Could anyone point out some links to fix this?
I needed the patch below when I tried the xen-unstable version
yesterday. I don''t see how it can be related to the problem you are
seeing but with it they work fine for me on RHEL4 and SLES9. I didn''t
try 2.6.16 but I will on Monday.

Are you sure you are building against the correct kernel headers for the
kernel you are running?

Ian.

diff -r d04ff58bbe18 unmodified_drivers/linux-2.6/platform-pci/evtchn.c
--- a/unmodified_drivers/linux-2.6/platform-pci/evtchn.c	Fri Jan 05 10:40:19
2007 +0000
+++ b/unmodified_drivers/linux-2.6/platform-pci/evtchn.c	Fri Jan 05 14:40:02
2007 +0000
@@ -48,6 +48,12 @@ static struct {
 	void *dev_id;
 	int close; /* close on unbind_from_irqhandler()? */
 } evtchns[MAX_EVTCHN];
+
+int irq_to_evtchn_port(int irq)
+{
+        return irq;
+}
+EXPORT_SYMBOL_GPL(irq_to_evtchn_port);
 
 void mask_evtchn(int port)
 {



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

Hi Ian,

Now I can xen-platform-pci.ko can be loaded after building 
unmodified_drivers modules with the correct kernel header. Thanks for 
pointing out.

However, Xen still hangs up when I try load xenbus.ko module after 
xen-platform-pci.ko is loaded successfully. The problem remains the same 
even though I applied the patch you provided and using the latest 
xen-unstable.hg version.

Thanks,

Liang

----- Original Message ----- 
From: "Ian Campbell" <Ian.Campbell@XenSource.com>
To: "Liang Yang" <multisyncfe991@hotmail.com>
Cc: "xen-devel" <xen-devel@lists.xensource.com>; "Keir
Fraser"
<keir@xensource.com>; <xen-users@lists.xensource.com>
Sent: Saturday, January 06, 2007 4:44 AM
Subject: Re: [Xen-devel] Unmodified_drivers modules broke again for 3.0.4?

> On Fri, 2007-01-05 at 16:51 -0700, Liang Yang wrote:
>> Hi,
>>
>> I tried to load unmodified_drivers modules for vbd device and got error
>> when
>> doing insmod xen-platform-pci.ko in HVM Linux domain:
>> xen_platform_pci: disagrees about version of symbol struct_module
>> insmod: error inserting ''xen-platform-pci.ko'' : -1
invalid module format.
>>
>> I used the same kernel version for HVM Linux kernel and the kernel I
was
>> building unmodified_drivers, i.e. they are both 2.6.16.33. I tested
>> xen-3.0.4-testing and xen-unstable, all got the same problem. Xen 3.0.2
>> with
>> 2.6.16.29 kernel version still works fine.
>>
>> Could anyone point out some links to fix this?
>
> I needed the patch below when I tried the xen-unstable version
> yesterday. I don''t see how it can be related to the problem you
are
> seeing but with it they work fine for me on RHEL4 and SLES9. I
didn''t
> try 2.6.16 but I will on Monday.
>
> Are you sure you are building against the correct kernel headers for the
> kernel you are running?
>
> Ian.
>
> diff -r d04ff58bbe18 unmodified_drivers/linux-2.6/platform-pci/evtchn.c
> --- a/unmodified_drivers/linux-2.6/platform-pci/evtchn.c Fri Jan 05 
> 10:40:19 2007 +0000
> +++ b/unmodified_drivers/linux-2.6/platform-pci/evtchn.c Fri Jan 05 
> 14:40:02 2007 +0000
> @@ -48,6 +48,12 @@ static struct {
>  void *dev_id;
>  int close; /* close on unbind_from_irqhandler()? */
> } evtchns[MAX_EVTCHN];
> +
> +int irq_to_evtchn_port(int irq)
> +{
> +        return irq;
> +}
> +EXPORT_SYMBOL_GPL(irq_to_evtchn_port);
>
> void mask_evtchn(int port)
> {
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

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

Hi,

I noticed Xen used Module directive to load RAMDISK for XenLinux in boot 
grub config file instead of regular initrd. Why can''t we use initrd
here? I
tried to change back to initrd and Linux reports an error kernal panic 
message: Linux kernel must be loaded before ramdisk.

Could anyone here explain about this?

Thanks,

Liang


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

Hello,

When I typed xm info, I got the following information. My question is why 
changeset information is not available. I used the latest Xen-unstable.

host                   : localhost.localdomain
release                : 2.6.16.33-xen
version                : #2 SMP Sat Jan 6 07:00:34 CST 2007
machine                : i686
nr_cpus                : 4
nr_nodes               : 1
sockets_per_node       : 2
cores_per_socket       : 2
threads_per_core       : 1
cpu_mhz                : 2666
hw_caps                : 
bfebfbff:20100000:00000000:00000140:0004e3bd:00000000:00000001
total_memory           : 3326
free_memory            : 127
xen_major              : 3
xen_minor              : 0
xen_extra              : -unstable
xen_caps               : xen-3.0-x86_32 hvm-3.0-x86_32
xen_pagesize           : 4096
platform_params        : virt_start=0xfc000000
xen_changeset          : unavailable
cc_compiler            : gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
cc_compile_by          : build
cc_compile_domain      :
cc_compile_date        : Sat Jan  6 06:44:47 CST 2007
xend_config_format     : 3

Liang


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

>I noticed Xen used Module directive to load RAMDISK for XenLinux in boot 
>grub config file instead of regular initrd. Why can''t we use initrd
here? I
>tried to change back to initrd and Linux reports an error kernal panic 
>message: Linux kernel must be loaded before ramdisk.
>
>Could anyone here explain about this?
''initrd'' is equivalent to ''module'' except
that there can only be a single initrd
statement per boot option. Obviously you need two modules (the kernel
and its initrd), hence you can''t use ''initrd'' here.

Jan

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

> When I typed xm info, I got the following information. My question is why
> changeset information is not available. I used the latest Xen-unstable.
You should find out why the appropriate line in xen/Makefile is failing
(it''s the one that includes the string "@@changeset@@").
Likely reasons
include building from a tarball rather a repository, not having mercurial
installed, or having a too-old version of mercurial installed.

 -- Keir


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

Keir,

All the likely reasons you pointed out are not likely. I installed the 
latest mercurial 0.9.3. Then I used hg clone 
http://xenbits.xensource.com/xen-unstable.hg to pull the whole repository to 
my local machine. Then I built the Xen.

I did not see any build errors when I build xen.

Liang

----- Original Message ----- 
From: "Keir Fraser" <keir@xensource.com>
To: "Liang Yang" <multisyncfe991@hotmail.com>;
"xen-devel"
<xen-devel@lists.xensource.com>; <xen-users@lists.xensource.com>
Sent: Wednesday, January 10, 2007 3:13 AM
Subject: Re: [Xen-devel] Why is xen_changeset information not available when 
doing xm info?

>
>> When I typed xm info, I got the following information. My question is
why
>> changeset information is not available. I used the latest Xen-unstable.
>
> You should find out why the appropriate line in xen/Makefile is failing
> (it''s the one that includes the string "@@changeset@@").
Likely reasons
> include building from a tarball rather a repository, not having mercurial
> installed, or having a too-old version of mercurial installed.
>
> -- Keir
>
> 

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

Jan,

I used SINGLE module to load kernel and SINGLE intird to load ramdisk in 
grub.conf file.

title Xen Unstable /Red Hat Enterprise Linux 2.6.16.33
 kernel /xen.gz console=vga
 module /vmlinuz-2.6-xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet 
console=tty0
 initrd /initrd-2.6.16.33-xen.img

Based on what you explained, this should be fine. However, Xen Linux still 
got a panic message: Linux kernel must be loaded before ramdisk.

How do you explain this?

Thanks,

Liang

----- Original Message ----- 
From: "Jan Beulich" <jbeulich@novell.com>
To: "Liang Yang" <multisyncfe991@hotmail.com>
Cc: "xen-devel" <xen-devel@lists.xensource.com>; 
<xen-users@lists.xensource.com>
Sent: Wednesday, January 10, 2007 3:09 AM
Subject: Re: [Xen-devel] What is the implication to use
''module''directive
instead of ''initrd'' to load ramdis

> >I noticed Xen used Module directive to load RAMDISK for XenLinux in
boot
>>grub config file instead of regular initrd. Why can''t we use
initrd here?
>>I
>>tried to change back to initrd and Linux reports an error kernal panic
>>message: Linux kernel must be loaded before ramdisk.
>>
>>Could anyone here explain about this?
>
> ''initrd'' is equivalent to ''module''
except that there can only be a single
> initrd
> statement per boot option. Obviously you need two modules (the kernel
> and its initrd), hence you can''t use ''initrd''
here.
>
> Jan
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

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

Hi,

what Jan is trying to say is that, since the dom0 kernel needs an
intrd image and since these options are passed to Xen kernel as
modules directives, you´ll need to specify them  as modules in your
grub.

title Xen Unstable /Red Hat Enterprise Linux 2.6.16.33
kernel /xen.gz console=vga <- Xen kernel
module /vmlinuz-2.6-xen  <- dom0 kernel passed as a Xen module
module initrd /initrd-2.6.16.33-xen.img <- dom0 initrd file passed as
a Xen module

Regards!

Matias

2007/1/10, Liang Yang
<multisyncfe991@hotmail.com>:
> Jan,
>
> I used SINGLE module to load kernel and SINGLE intird to load ramdisk in
> grub.conf file.
>
> title Xen Unstable /Red Hat Enterprise Linux 2.6.16.33
>  kernel /xen.gz console=vga
>  module /vmlinuz-2.6-xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
> console=tty0
>  initrd /initrd-2.6.16.33-xen.img
>
> Based on what you explained, this should be fine. However, Xen Linux still
> got a panic message: Linux kernel must be loaded before ramdisk.
>
> How do you explain this?
>
> Thanks,
>
> Liang
>
> ----- Original Message -----
> From: "Jan Beulich" <jbeulich@novell.com>
> To: "Liang Yang" <multisyncfe991@hotmail.com>
> Cc: "xen-devel" <xen-devel@lists.xensource.com>;
> <xen-users@lists.xensource.com>
> Sent: Wednesday, January 10, 2007 3:09 AM
> Subject: Re: [Xen-devel] What is the implication to use
''module''directive
> instead of ''initrd'' to load ramdis
>
>
> > >I noticed Xen used Module directive to load RAMDISK for XenLinux
in boot
> >>grub config file instead of regular initrd. Why can''t we
use initrd here?
> >>I
> >>tried to change back to initrd and Linux reports an error kernal
panic
> >>message: Linux kernel must be loaded before ramdisk.
> >>
> >>Could anyone here explain about this?
> >
> > ''initrd'' is equivalent to ''module''
except that there can only be a single
> > initrd
> > statement per boot option. Obviously you need two modules (the kernel
> > and its initrd), hence you can''t use
''initrd'' here.
> >
> > Jan
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>

-- 
Edney Matias da Silva
<edney@gmail.com>

Prognus Software Livre
http://www.prognus.com.br

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

>I used SINGLE module to load kernel and SINGLE intird to load ramdisk in 
>grub.conf file.
>
>title Xen Unstable /Red Hat Enterprise Linux 2.6.16.33
> kernel /xen.gz console=vga
> module /vmlinuz-2.6-xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet 
>console=tty0
> initrd /initrd-2.6.16.33-xen.img
>
>Based on what you explained, this should be fine. However, Xen Linux still 
>got a panic message: Linux kernel must be loaded before ramdisk.
No, it''s not. I said that initrd and module are equivalents, except
that initrd
can be specified just once. Hence, if there already was a module
statement (being equivalent to initrd), there can''t be a second initrd.

Jan

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

On Thu, 2007-01-11 at 08:49 +0000, Jan Beulich wrote:
> >I used SINGLE module to load kernel and SINGLE intird to load ramdisk
in
> >grub.conf file.
> >
> >title Xen Unstable /Red Hat Enterprise Linux 2.6.16.33
> > kernel /xen.gz console=vga
> > module /vmlinuz-2.6-xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet 
> >console=tty0
> > initrd /initrd-2.6.16.33-xen.img
> >
> >Based on what you explained, this should be fine. However, Xen Linux
still
> >got a panic message: Linux kernel must be loaded before ramdisk.
> 
> No, it''s not. I said that initrd and module are equivalents,
except that initrd
> can be specified just once. Hence, if there already was a module
> statement (being equivalent to initrd), there can''t be a second
initrd.
If your kernel uses the multiboot protocol (which Xen does) then initrd
is invalid, at least by my reading of the grub code, so you must use
module. From stage2/builtins.c:

        static int
        initrd_func (char *arg, int flags)
        {
          switch (kernel_type)
            {
            case KERNEL_TYPE_LINUX:
            case KERNEL_TYPE_BIG_LINUX:
              if (! load_initrd (arg))
                return 1;
              break;
        
            default:
              errnum = ERR_NEED_LX_KERNEL;
              return 1;
            }
        
          return 0;
        }
        
compared with module_func:

        static int
        module_func (char *arg, int flags)
        {
          int len = grub_strlen (arg);
        
          switch (kernel_type)
            {
            case KERNEL_TYPE_MULTIBOOT:
              if (mb_cmdline + len + 1 > (char *) MB_CMDLINE_BUF +
MB_CMDLINE_BUFLEN)
                {
                  errnum = ERR_WONT_FIT;
                  return 1;
                }
              grub_memmove (mb_cmdline, arg, len + 1);
              if (! load_module (arg, mb_cmdline))
                return 1;
              mb_cmdline += len + 1;
              break;
        
            case KERNEL_TYPE_LINUX:
            case KERNEL_TYPE_BIG_LINUX:
              if (! load_initrd (arg))
                return 1;
              break;
        
            default:
              errnum = ERR_NEED_MB_KERNEL;
              return 1;
            }
        
          return 0;
        }

If your kernel is using the Linux kernel boot protocol then Jan is
correct that module and initrd are interchangeable and only one may be
used (in fact it looks to me as if simply the last one takes
precedence).


Ian.


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

Hi,

Just wondering if anyone made any progress on this.  I hit the same
problem when loading xenbus.ko built for RHEL4 U4 and xen 3.0.4.1. 
Doesn''t
lock up the guest, but the modprobe hangs after it gets into read_reply().

Host is x86_64 running 3.0.4.1 and the standard 2.6.16 dom0.  Guest is
x86_64 hvm with RHEL4 U4.

Here''s a stack trace:
modprobe      D 000001006b5f1e58     0  3675   3546                3639
(NOTLB) 
000001006b5f1d58 0000000000000006 000001006b5f1ca8 ffffffffa0158fb0
       000000000000004d ffffffffa0158ff0 0000000000000080
0000000100000000
       00000100759f8030 00000000007766af
Call Trace:
       <ffffffff80138542>{printk+141} 
       <ffffffffa015555e>{:xenbus:read_reply+202}
       <ffffffff80135746>{autoremove_wake_function+0} 
       <ffffffff80135746>{autoremove_wake_function+0}
       <ffffffffa0155870>{:xenbus:xs_talkv+241} 
       <ffffffffa01559c0>{:xenbus:xs_single+95}
       <ffffffffa0155bcc>{:xenbus:xenbus_directory+88} 
       <ffffffffa0157897>{:xenbus:xenbus_probe_devices+67}
       <ffffffff801ea63d>{__up_write+20} 
       <ffffffffa0157dbc>{:xenbus:xenbus_probe+61}
       <ffffffffa016310f>{:xenbus:xenbus_probe_init+271} 
       <ffffffff8014fd37>{sys_init_module+278}
       <ffffffff8011026a>{system_call+126}

I also traced each function entry (within xenbus/) up to the hang:
xenbus_probe_init:864
xenbus_dev_init:366
create_xen_proc_entry:10
xs_init:869
xb_init_comms:200
xenwatch_thread:752
xenbus_probe:803
xenbus_probe_devices:594
xenbus_directory:340
join:302
xs_single:269
xs_talkv:212
xenbus_thread:851
process_msg:790
xb_read:149
xb_write:101
get_output_chunk:77
xb_write:101
get_output_chunk:77
read_reply:128

Looks sort of like it was stuck on the
"spin_lock(&xs_state.reply_lock)"
but I don''t see any imbalanced usage of the reply_lock in xenbus_xs.c
and
I do see the xs_init call which inits the spinlock.

Thanks,
-kurt


On Mon, Jan 08, 2007 at 09:56:00AM -0700, Liang Yang
wrote:
> Hi Ian,
> 
> Now I can xen-platform-pci.ko can be loaded after building 
> unmodified_drivers modules with the correct kernel header. Thanks for 
> pointing out.
> 
> However, Xen still hangs up when I try load xenbus.ko module after 
> xen-platform-pci.ko is loaded successfully. The problem remains the same 
> even though I applied the patch you provided and using the latest 
> xen-unstable.hg version.
> 
> Thanks,
> 
> Liang
> 
> ----- Original Message ----- 
> From: "Ian Campbell" <Ian.Campbell@XenSource.com>
> To: "Liang Yang" <multisyncfe991@hotmail.com>
> Cc: "xen-devel" <xen-devel@lists.xensource.com>; "Keir
Fraser"
> <keir@xensource.com>; <xen-users@lists.xensource.com>
> Sent: Saturday, January 06, 2007 4:44 AM
> Subject: Re: [Xen-devel] Unmodified_drivers modules broke again for 3.0.4?
> 
> 
> >On Fri, 2007-01-05 at 16:51 -0700, Liang Yang wrote:
> >>Hi,
> >>
> >>I tried to load unmodified_drivers modules for vbd device and got
error
> >>when
> >>doing insmod xen-platform-pci.ko in HVM Linux domain:
> >>xen_platform_pci: disagrees about version of symbol struct_module
> >>insmod: error inserting ''xen-platform-pci.ko'' :
-1 invalid module format.
> >>
> >>I used the same kernel version for HVM Linux kernel and the kernel
I was
> >>building unmodified_drivers, i.e. they are both 2.6.16.33. I tested
> >>xen-3.0.4-testing and xen-unstable, all got the same problem. Xen
3.0.2
> >>with
> >>2.6.16.29 kernel version still works fine.
> >>
> >>Could anyone point out some links to fix this?
> >
> >I needed the patch below when I tried the xen-unstable version
> >yesterday. I don''t see how it can be related to the problem
you are
> >seeing but with it they work fine for me on RHEL4 and SLES9. I
didn''t
> >try 2.6.16 but I will on Monday.
> >
> >Are you sure you are building against the correct kernel headers for
the
> >kernel you are running?
> >
> >Ian.
> >
> >diff -r d04ff58bbe18 unmodified_drivers/linux-2.6/platform-pci/evtchn.c
> >--- a/unmodified_drivers/linux-2.6/platform-pci/evtchn.c Fri Jan 05 
> >10:40:19 2007 +0000
> >+++ b/unmodified_drivers/linux-2.6/platform-pci/evtchn.c Fri Jan 05 
> >14:40:02 2007 +0000
> >@@ -48,6 +48,12 @@ static struct {
> > void *dev_id;
> > int close; /* close on unbind_from_irqhandler()? */
> >} evtchns[MAX_EVTCHN];
> >+
> >+int irq_to_evtchn_port(int irq)
> >+{
> >+        return irq;
> >+}
> >+EXPORT_SYMBOL_GPL(irq_to_evtchn_port);
> >
> >void mask_evtchn(int port)
> >{
> >
> >
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@lists.xensource.com
> >http://lists.xensource.com/xen-devel
> >
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 27/1/07 2:43 am, "Kurt Hackel" <kurt.hackel@oracle.com>
wrote:
> Just wondering if anyone made any progress on this.  I hit the same
> problem when loading xenbus.ko built for RHEL4 U4 and xen 3.0.4.1. 
Doesn''t
> lock up the guest, but the modprobe hangs after it gets into read_reply().
This is fixed in xen-unstable but the fix missed 3.0.4.1.

 -- Keir



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

I''m also meeting with the similar issue.
I use IA32e host with staging tree''s c/s 13649, and the Linux guest
kernel is 2.6.16.33.
insmod xen-platform-pci.ko is ok, but when insmod xenbus.ko, the insmod command
never returns -- guest doesn''t hang now since I can switch to another
tty to run "killall -9 insmod", though the insmod process here can
never be killed by killall.
Seems the xenbus''s module_init function never returns.

 -- Dexuan
>-----Original Message-----
>From: xen-devel-bounces@lists.xensource.com
>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser
>Sent: 2007年1月27日 17:07
>To: Kurt Hackel; Liang Yang
>Cc: xen-devel; Keir Fraser; xen-users@lists.xensource.com; Ian Campbell
>Subject: Re: Xen Still hangs up when insmod xenbus.ko. Re:
>[Xen-devel]Unmodified_drivers modules broke again for 3.0.4?
>
>On 27/1/07 2:43 am, "Kurt Hackel" <kurt.hackel@oracle.com>
wrote:
>
>> Just wondering if anyone made any progress on this.  I hit the same
>> problem when loading xenbus.ko built for RHEL4 U4 and xen 3.0.4.1. 
Doesn''t
>> lock up the guest, but the modprobe hangs after it gets into
read_reply().
>
>This is fixed in xen-unstable but the fix missed 3.0.4.1.
>
> -- Keir
>
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 27/1/07 11:59 am, "Cui, Dexuan" <dexuan.cui@intel.com> wrote:
> I''m also meeting with the similar issue.
> I use IA32e host with staging tree''s c/s 13649, and the Linux
guest kernel is
> 2.6.16.33.
> insmod xen-platform-pci.ko is ok, but when insmod xenbus.ko, the insmod
> command never returns -- guest doesn''t hang now since I can switch
to another
> tty to run "killall -9 insmod", though the insmod process here
can never be
> killed by killall.
> Seems the xenbus''s module_init function never returns.
The original problem was misrouted platform-pci interrupt when apic=1 and
acpi=1. Does the insmod hang you are seeing depend on either of those
parameters?

 -- Keir



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

I tried apic=acpi=0, but still suffer from the same symptom. :(

-- Dexuan
>The original problem was misrouted platform-pci interrupt when apic=1
and
>acpi=1. Does the insmod hang you are seeing depend on either of those
>parameters?
>
> -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel