[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [PATCH] Re: [Xen-ia64-devel] Help? Red Hat fails, Suse/Debian both work fine

Hi, Kevin

Already the problem has been fixed by Keir.
FYI, I tried again with cset 9079, but I have the same error.

Error: Device 769 (vbd) could not be connected. Hotplug scripts not 

the patch which I tried is the below.
--- drivers/xen/Makefile.orig   2006-03-03 22:39:06.000000000 +0900
+++ drivers/xen/Makefile        2006-03-03 22:40:05.000000000 +0900
@@ -2,7 +2,7 @@
 obj-y  += util.o
 obj-y  += core/
+obj-y  += char/
 obj-y  += console/
 obj-y  += evtchn/
 #obj-y += balloon/
diff -r b4f1084177cc linux-2.6-xen-sparse/drivers/char/mem.c
--- a/linux-2.6-xen-sparse/drivers/char/mem.c   Wed Mar  1 15:06:24 2006 
+++ b/linux-2.6-xen-sparse/drivers/char/mem.c   Mon Mar  6 10:02:03 2006 
@@ -7,6 +7,7 @@
  *    Jan-11-1998, C. Scott Ananian <cananian@xxxxxxxxxxxxxxxxxxxx>
  *  Shared /dev/zero mmaping support, Feb 2000, Kanoj Sarcar <kanoj@sgi.
 #include <linux/config.h>
 #include <linux/mm.h>
Best Regards,

Akio Takebe

>After thinking more, I still think the cause that drivers/xen/char/mem.c is 
>not compiled into xen0 kernel image (for xen/ia64 only). See 
>uncached_access() within that file which is simple and different as original 
>linux one:
>static inline int uncached_access(struct file *file)
>        if (file->f_flags & O_SYNC)
>                return 1;
>        /* Xen sets correct MTRR type on non-RAM for us. */
>        return 0;
>By this way, xenstore page of domU will be always presented as WB to 
>dom0, and then memory attribute will become correct.
>Akio told me that he seemed to make an incomplete experiment to include 
>xen style kmem. Could you confirm whether following quick change can 
>work for you: (Sorry for not patch style, due to no access to my box now:-)
>1.     Modify drivers/xen/Makefile by adding:
>               obj-y   += char/
>2.     Then modify drivers/char/mem.c by define ARCH_HAS_DEV_MEM at 
>the very start. (Just for quick experiment to ensure correct code included. 
>If it works, please move the definition to appropriate header file)
>>-----Original Message-----
>>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Tian, Kevin
>>Sent: 2006ト\xF3ヤツ3ネユ 20:08
>>To: Kouya SHIMURA; Magenheimer, Dan (HP Labs Fort Collins)
>>Cc: xen-devel; xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>>Subject: RE: [Xen-devel] [PATCH] Re: [Xen-ia64-devel] Help? Red Hat
>>fails,Suse/Debian both work fine
>>>From: Kouya SHIMURA
>>>Sent: 2006ト\xF3ヤツ3ネユ 19:02
>>>Hi all
>>>Finally I found out the unstable problem about domU boot on ia64.
>>>Please see the comment in patch.
>>>This patch is one solution.
>>>Another solution is to ask the memory attributes to
>>>hypervisor but it looks excessive modification.
>>>Signed-off-by Kouya SHIMURA <kouya@xxxxxxxxxxxxxx>
>>>Best Regards,
>>Hi, Kouya,
>>Good finding for the cause, however several minor comments about your
>>      - Be conservative when you want to modify common linux files, if
>>without strong reasons.
>>      - Your change has potential issue. Your change actually makes all
>>illegal addresses which is out of EFI memmap can get WB attribute, only
>>for accommodating another special page (store page) out of domU's
>>knowledge. I don't think it's right way to go.
>>      - See how x86 works. All special pages including store page, console
>>page, start info, etc. are constructed within domU's memory, and domU
>>is aware of that. For XEN/IA64, you may want to steal last several pages
>>from configured memory of domU. There's an ia64 specific field named
>>sys_pgnr (in xc_linux_build), which was targeted for this issue before
>>however incomplete yet. Then you can pass to Xen and add one reserved
>>EFI memmap entry to cover sys_pgnr pages with attribute WB at
>>dom_fw_init. Since it's reserved, domU won't use it. However
>>efi_mem_attributes can give ideal result you want. This workaround has
>>no impact to xenlinux code, which may be quick solution. Of course, we
>>may consider reconstruct more to make it cleaner in the future. ;-)
>>Xen-devel mailing list
>Xen-devel mailing list

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.