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

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

[Isaku Yamahata]

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

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

[-- Attachment #2: 13183_222d8ad62562_fix_balloon_init.patch --]
[-- Type: text/plain, Size: 1451 bytes --]

# 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;

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: [PATCH] make balloon driver not return pages which are in [xen_start_info->nr_pages,

[Jan Beulich]

>>> 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

Re: [PATCH] make balloon driver not return pages which are in [xen_start_info->nr_pages,

[Isaku Yamahata]

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

Re: [PATCH] make balloon driver not return pages which are in [xen_start_info->nr_pages, max_pfn] on ia64

[Alex Williamson]

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.

Re: [PATCH] make balloon driver not return pages which are in [xen_start_info->nr_pages, max_pfn] on ia64

[Keir Fraser]

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

Unmodified_drivers modules broke again for 3.0.4?

[Liang Yang]

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

Re: Unmodified_drivers modules broke again for 3.0.4?

[Ian Campbell]

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 Still hangs up when insmod xenbus.ko. Re: Unmodified_drivers modules broke again for 3.0.4?

[Liang Yang]

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
> 

What is the implication to use 'module' directive instead of 'initrd' to load ramdisk?

[Liang Yang]

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

Why is xen_changeset information not available when doing xm info?

[Liang Yang]

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

Re: What is the implication to use 'module' directive instead of 'initrd' to load ramdis

[Jan Beulich]

>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

Re: Why is xen_changeset information not available when doing xm info?

[Keir Fraser]

> 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

Re: Why is xen_changeset information not available when doing xm info?

[Liang Yang]

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
>
> 

Re: What is the implication to use 'module'directive instead of 'initrd' to load ramdis

[Liang Yang]

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
> 

Re: Re: [Xen-devel] What is the implication to use 'module'directive instead of 'initrd' to load ramdis

[Edney Matias]

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

Re: What is the implication to use 'module'directive instead of 'initrd' to load ramdis

[Jan Beulich]

>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

Re: What is the implication to use 'module'directive instead of 'initrd' to load ramdis

[Ian Campbell]

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.

Re: Xen Still hangs up when insmod xenbus.ko. Re: Unmodified_drivers modules broke again for 3.0.4?

[Kurt Hackel]

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

Re: Xen Still hangs up when insmod xenbus.ko. Re: Unmodified_drivers modules broke again for 3.0.4?

[Keir Fraser]

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

RE: Xen Still hangs up when insmod xenbus.ko. Re: Unmodified_drivers modules broke again for 3.0.4?

[Cui, Dexuan]

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

Re: Xen Still hangs up when insmod xenbus.ko. Re: Unmodified_drivers modules broke again for 3.0.4?

[Keir Fraser]

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

RE: Xen Still hangs up when insmod xenbus.ko. Re: Unmodified_drivers modules broke again for 3.0.4?

[Cui, Dexuan]

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