Re: [Xen-ia64-devel] [Patch] fix unaligned access of netfron/back
Le Mardi 17 Octobre 2006 05:38, Akio Takebe a écrit : Hi, We make a patch to avoid the following warnings. The noisy warnings are happend only when we enabele network of domU on xen/ia64. kernel unaligned access to 0xe00019247a1e, ip=0xa0010093d681 kernel unaligned access to 0xe00019247a1e, ip=0xa0010093d751 kernel unaligned access to 0xe00019247a1e, ip=0xa0010093d800 kernel unaligned access to 0xe00019247a2e, ip=0xa0010093da10 kernel unaligned access to 0xe00019247a1e, ip=0xa0010093da90 Signed-off-by: Kouya SHIMURA [EMAIL PROTECTED] Signed-off-by: Akio Takebe [EMAIL PROTECTED] Hi, thank you for fixing this boring issue! Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Please try PV-on-HVM on IPF
Hi all,
I (Doi.Tsunehisa) said:
We've ported PV-on-HVM drivers for IPF. But I think that
only few tries it. Thus, I try to describe to use it.
And I attach several patches about PV-on-HVM.
+ fix-warning.patch
- warning fix for HVM PV driver
+ notsafe-comment.patch
- add not-SMP-safe comment about PV-on-HVM
- to take Isaku's suggestion.
+ pv-backport.patch (preliminary)
- current HVM PV driver for only 2.6.16 or 2.6.16.* kernel
- this is preliminary patch for backporting to before 2.6.16
kernel
- we tested only compiling on RHEL4.
Today, I was testing my preliminary patch on RHEL4 U2.
But, xen-platform-pci.ko could not be attached with RHEL4 U2 original
kernel. Thus I was investigating it. So, I found a strange movement about
PCI configuration.
I tested on two envrionments, linux-2.6.16.29 and RHEL4 U2 original.
Outputs of lspci command are same on both environment.
The output is follow:
[Both environment of VT-i domain]
# lspci -v
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
Flags: fast devsel
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
Flags: medium devsel
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
(prog-if 80 [Master])
Flags: bus master, fast devsel, latency 0
I/O ports at 1100 [size=16]
00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00 [VGA])
Flags: bus master, fast devsel, latency 0
Memory at c000 (32-bit, prefetchable) [size=32M]
Memory at c300 (32-bit, non-prefetchable) [size=4K]
00:03.0 Class ff80: Unknown device 5853:0001 (rev 01)
Flags: fast devsel
I/O ports at 1000 [disabled] [size=256]
Memory at c200 (32-bit, prefetchable) [disabled] [size=16M]
There is `Unknown device' in thie message. It's pyseudo-device for
PV-on-HVM called `xen-platform-pci'.
Next, I showed IO-memory maps with /proc/iomem. But, IO-memory maps
are different on both environment.
[linux-2.6.16.29 on VT-i domain]
# cat /proc/iomem
-0009 : System RAM
000a-000b : reserved
000c-000f : reserved
0010-03ff : System RAM
0400-04bf3fff : System RAM
0400-046d34bf : Kernel code
046d34c0-04bf373f : Kernel data
04bf4000-3c458fff : System RAM
deleted *
3ff7-3fffdfff : System RAM
3fffe000-3fff : reserved
c000-c1ff : :00:02.0
c200-c2ff : :00:03.0
c300-c3000fff : :00:02.0
e000-e033dcf7 : PCI Bus :00 I/O Ports -0cf7
e0340d00-e3ff : PCI Bus :00 I/O Ports 0d00-
[RHEL4 U2 on VT-i domain]
# cat /proc/iomem
c000-c1ff : PCI Bus :00
c000-c1ff : :00:02.0
c200-c2ff : :00:03.0
c200-c2000fff : PCI Bus :00
c300-c3000fff : :00:02.0
On RHEL4 U2 environment, I could show only this message. It's
strange, and it's the reason that xen-platform-pci.ko module can't
be attached, I think.
I don't understand what is happend. Does anyone know the reason ?
Thanks,
- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Please try PV-on-HVM on IPF
Sorry, I forgot to write about my test environment. I tested with xen-ia64-unstable.hg (cs:11810). I (Doi.Tsunehisa) said: Hi all, I (Doi.Tsunehisa) said: We've ported PV-on-HVM drivers for IPF. But I think that only few tries it. Thus, I try to describe to use it. And I attach several patches about PV-on-HVM. + fix-warning.patch - warning fix for HVM PV driver + notsafe-comment.patch - add not-SMP-safe comment about PV-on-HVM - to take Isaku's suggestion. + pv-backport.patch (preliminary) - current HVM PV driver for only 2.6.16 or 2.6.16.* kernel - this is preliminary patch for backporting to before 2.6.16 kernel - we tested only compiling on RHEL4. Today, I was testing my preliminary patch on RHEL4 U2. But, xen-platform-pci.ko could not be attached with RHEL4 U2 original kernel. Thus I was investigating it. So, I found a strange movement about PCI configuration. I tested on two envrionments, linux-2.6.16.29 and RHEL4 U2 original. Outputs of lspci command are same on both environment. The output is follow: [Both environment of VT-i domain] # lspci -v 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) Flags: fast devsel 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II ] Flags: medium devsel 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] (prog-if 80 [Master]) Flags: bus master, fast devsel, latency 0 I/O ports at 1100 [size=16] 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00 [VGA] ) Flags: bus master, fast devsel, latency 0 Memory at c000 (32-bit, prefetchable) [size=32M] Memory at c300 (32-bit, non-prefetchable) [size=4K] 00:03.0 Class ff80: Unknown device 5853:0001 (rev 01) Flags: fast devsel I/O ports at 1000 [disabled] [size=256] Memory at c200 (32-bit, prefetchable) [disabled] [siz e=16M] There is `Unknown device' in thie message. It's pyseudo-device for PV-on-HVM called `xen-platform-pci'. Next, I showed IO-memory maps with /proc/iomem. But, IO-memory maps are different on both environment. [linux-2.6.16.29 on VT-i domain] # cat /proc/iomem -0009 : System RAM 000a-000b : reserved 000c-000f : reserved 0010-03ff : System RAM 0400-04bf3fff : System RAM 0400-046d34bf : Kernel code 046d34c0-04bf373f : Kernel data 04bf4000-3c458fff : System RAM deleted * 3ff7-3fffdfff : System RAM 3fffe000-3fff : reserved c000-c1ff : :00:02.0 c200-c2ff : :00:03.0 c300-c3000fff : :00:02.0 e000-e033dcf7 : PCI Bus :00 I/O Ports -0cf7 e0340d00-e3ff : PCI Bus :00 I/O Ports 0d00- [RHEL4 U2 on VT-i domain] # cat /proc/iomem c000-c1ff : PCI Bus :00 c000-c1ff : :00:02.0 c200-c2ff : :00:03.0 c200-c2000fff : PCI Bus :00 c300-c3000fff : :00:02.0 On RHEL4 U2 environment, I could show only this message. It's strange, and it's the reason that xen-platform-pci.ko module can't be attached, I think. I don't understand what is happend. Does anyone know the reason ? Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Please try PV-on-HVM on IPF
Le Mardi 17 Octobre 2006 14:30, [EMAIL PROTECTED] a écrit : Hi all, I (Doi.Tsunehisa) said: [...] Today, I was testing my preliminary patch on RHEL4 U2. But, xen-platform-pci.ko could not be attached with RHEL4 U2 original kernel. Thus I was investigating it. So, I found a strange movement about PCI configuration. I tested on two envrionments, linux-2.6.16.29 and RHEL4 U2 original. Outputs of lspci command are same on both environment. The output is follow: [Both environment of VT-i domain] # lspci -v 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) Flags: fast devsel 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] Flags: medium devsel 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] (prog-if 80 [Master]) Flags: bus master, fast devsel, latency 0 I/O ports at 1100 [size=16] 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00 [VGA]) Flags: bus master, fast devsel, latency 0 Memory at c000 (32-bit, prefetchable) [size=32M] Memory at c300 (32-bit, non-prefetchable) [size=4K] 00:03.0 Class ff80: Unknown device 5853:0001 (rev 01) Flags: fast devsel I/O ports at 1000 [disabled] [size=256] Memory at c200 (32-bit, prefetchable) [disabled] [size=16M] There is `Unknown device' in thie message. It's pyseudo-device for PV-on-HVM called `xen-platform-pci'. Next, I showed IO-memory maps with /proc/iomem. But, IO-memory maps are different on both environment. [linux-2.6.16.29 on VT-i domain] # cat /proc/iomem -0009 : System RAM 000a-000b : reserved 000c-000f : reserved 0010-03ff : System RAM 0400-04bf3fff : System RAM 0400-046d34bf : Kernel code 046d34c0-04bf373f : Kernel data 04bf4000-3c458fff : System RAM deleted * 3ff7-3fffdfff : System RAM 3fffe000-3fff : reserved c000-c1ff : :00:02.0 c200-c2ff : :00:03.0 c300-c3000fff : :00:02.0 e000-e033dcf7 : PCI Bus :00 I/O Ports -0cf7 e0340d00-e3ff : PCI Bus :00 I/O Ports 0d00- [RHEL4 U2 on VT-i domain] # cat /proc/iomem c000-c1ff : PCI Bus :00 c000-c1ff : :00:02.0 c200-c2ff : :00:03.0 c200-c2000fff : PCI Bus :00 c300-c3000fff : :00:02.0 On RHEL4 U2 environment, I could show only this message. It's strange, and it's the reason that xen-platform-pci.ko module can't be attached, I think. I don't understand what is happend. Does anyone know the reason ? I do not really understand what is strange for you. The output is not the same but: * it may be due to kernel version * the xen pseudo device appears in both version. What is the error message when you try to insmod xen-platform-pci ? Have you ever succeed to insmod it in RHEL 4 ? Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Please try PV-on-HVM on IPF
Hi Tristan,
Thank you for your comment.
You (Tristan.Gingold) said:
[linux-2.6.16.29 on VT-i domain]
# cat /proc/iomem
-0009 : System RAM
000a-000b : reserved
000c-000f : reserved
0010-03ff : System RAM
0400-04bf3fff : System RAM
0400-046d34bf : Kernel code
046d34c0-04bf373f : Kernel data
04bf4000-3c458fff : System RAM
deleted *
3ff7-3fffdfff : System RAM
3fffe000-3fff : reserved
c000-c1ff : :00:02.0
c200-c2ff : :00:03.0
c300-c3000fff : :00:02.0
e000-e033dcf7 : PCI Bus :00 I/O Ports -0cf7
e0340d00-e3ff : PCI Bus :00 I/O Ports 0d00-
[RHEL4 U2 on VT-i domain]
# cat /proc/iomem
c000-c1ff : PCI Bus :00
c000-c1ff : :00:02.0
c200-c2ff : :00:03.0
c200-c2000fff : PCI Bus :00
c300-c3000fff : :00:02.0
On RHEL4 U2 environment, I could show only this message. It's
strange, and it's the reason that xen-platform-pci.ko module can't
be attached, I think.
I don't understand what is happend. Does anyone know the reason ?
I do not really understand what is strange for you.
The output is not the same but:
* it may be due to kernel version
* the xen pseudo device appears in both version.
I think that the diffence are noticed..
[linux-2.6.16.29 on VT-i domain]
c200-c2ff : :00:03.0
[RHEL4 U2 on VT-i domain]
c200-c2ff : :00:03.0
c200-c2000fff : PCI Bus :00
On RHEL4 U2 kernel (Linux version 2.6.9-22.EL), xen-platform-pci
includes `PCI Bus :00', but it should be the leaf node, I think.
To insmod xen-platform-pci, this iomem space was conflicted with
the inner device, thus it can't be attached.
What is the error message when you try to insmod xen-platform-pci ?
Have you ever succeed to insmod it in RHEL 4 ?
I've never succeeded to insmod it in RHEL 4 original kernel.
The error message is follows:
# insmod xen-platform-pci.ko
PCI: Enabling device :00:03.0 (0010 - 0013)
:MEM I/O resource 0xc200 @ 0x100 busy
xen-platform-pci: probe of :00:03.0 failed with error -16
This message is outputted from follow codes:
[unmodified_drivers/linux-2.6/platform-pci/platform-pci.c] 202
181 static int __devinit platform_pci_init(struct pci_dev *pdev,
182 const struct pci_device_id *ent)
183 {
184 int i, ret;
185 long ioaddr, iolen;
186 long mmio_addr, mmio_len;
187
...
202
203 if (request_mem_region(mmio_addr, mmio_len, DRV_NAME) == NULL)
204 {
205 printk(KERN_ERR :MEM I/O resource 0x%lx @ 0x%lx
busy\n,
206 mmio_addr, mmio_len);
207 return -EBUSY;
208 }
I've tried to insert checking code before request_mem_region()
to show the resource tree. So, I found the reason that it can't be
attaced.
- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] crash on xen-ia64-unstable 11810:fcd746cf4647
I got this panic booting an rx2600 (which normally boots with xen). Does this look familiar to anybody? ELILO boot: xen desc : cmdline: vmlinux-xen.gz ro vmcode : xen.gz ELILO boot: xen Uncompressing Linux... done Loading file vmlinux-xen.gz...done Uncompressing... done __ ___ ___ __ _ \ \/ /___ _ __ |___ / / _ \_ _ _ __ ___| |_ __ _| |__ | | ___ \ // _ \ '_ \|_ \| | | |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | ___) | |_| |__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |(_)___/\__,_|_| |_|___/\__\__,_|_.__/|_|\___| http://www.cl.cam.ac.uk/netos/xen University of Cambridge Computer Laboratory Xen version 3.0-unstable ([EMAIL PROTECTED]) (gcc version 4.1.0 (Gentoo 4.1.0)) Wed Sep 27 17:25:14 EDT 2006 Latest ChangeSet: Wed Sep 27 17:05:45 2006 -0400 11638:75b47fc791bb (XEN) Xen command line: (XEN) xen image pstart: 0x400, xenheap pend: 0x800 (XEN) find_memory: efi_memmap_walk returns max_page=103ffef (XEN) Before xen_heap_start: f4129d58 (XEN) After xen_heap_start: f4338000 (XEN) warning: skipping physical page 0 (XEN) Init boot pages: 0x4000 - 0x400. (XEN) Init boot pages: 0x800 - 0x3f5e4000. (XEN) Init boot pages: 0x3fb0 - 0x3fb2c000. (XEN) Init boot pages: 0x404000 - 0x40fcb51000. (XEN) Init boot pages: 0x40fd9b3d00 - 0x40fdf8c008. (XEN) Init boot pages: 0x40fdf8c068 - 0x40fdf8ffdf. (XEN) Init boot pages: 0x40fdf90008 - 0x40fef98008. (XEN) Init boot pages: 0x40fef986f8 - 0x40ffd68000. (XEN) Init boot pages: 0x40ffda4000 - 0x40ffe1. (XEN) Init boot pages: 0x40ffe8 - 0x40fffbc000. (XEN) System RAM: 4085MB (4183168kB) (XEN) size of virtual frame_table: 10288kB (XEN) virtual machine to physical table: f3fff7e00088 size: 2096kB (XEN) max_page: 0x103ffef (XEN) Xen heap: 60MB (62240kB) (XEN) ACPI: RSDP (v002 HP) @ 0x3fb2e000 (XEN) ACPI: XSDT (v001 HP rx2600 0x HP 0x) @ 0x3fb2e02c (XEN) ACPI: FADT (v003 HP rx2600 0x HP 0x) @ 0x3fb36800 (XEN) ACPI: SPCR (v001 HP rx2600 0x HP 0x) @ 0x3fb36938 (XEN) ACPI: DBGP (v001 HP rx2600 0x HP 0x) @ 0x3fb36988 (XEN) ACPI: MADT (v001 HP rx2600 0x HP 0x) @ 0x3fb36a48 (XEN) ACPI: SPMI (v004 HP rx2600 0x HP 0x) @ 0x3fb369c0 (XEN) ACPI: CPEP (v001 HP rx2600 0x HP 0x) @ 0x3fb36a10 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb33870 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb33a50 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb33da0 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb347c0 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb351e0 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb35c00 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb36620 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb36710 (XEN) ACPI: DSDT (v001 HP rx2600 0x0007 INTL 0x02012044) @ 0x (XEN) SAL 3.1: HP version 2.31 (XEN) SAL Platform features: None (XEN) SAL: AP wakeup using external interrupt vector 0xff (XEN) No logical to physical processor mapping available (XEN) avail:0x1180c600, status:0x600,control:0x1180c000, vm?0x0 (XEN) No VT feature supported. (XEN) cpu_init: current=f40dc000 (XEN) vhpt_init: vhpt paddr=0x40fcb4, end=0x40fcb4 (XEN) ACPI: Local APIC address e800fee0 (XEN) ACPI: LAPIC_ADDR_OVR (address[fee0]) (XEN) ACPI: LSAPIC (acpi_id[0x00] lsapic_id[0x00] lsapic_eid[0x00] enabled) (XEN) CPU 0 (0x) enabled (BSP) (XEN) ACPI: LSAPIC (acpi_id[0x01] lsapic_id[0x01] lsapic_eid[0x00] enabled) (XEN) CPU 1 (0x0100) enabled (XEN) ACPI: IOSAPIC (id[0x0] address[fed20800] gsi_base[16]) (XEN) ACPI: IOSAPIC (id[0x1] address[fed22800] gsi_base[27]) (XEN) ACPI: IOSAPIC (id[0x2] address[fed24800] gsi_base[38]) (XEN) ACPI: IOSAPIC (id[0x3] address[fed26800] gsi_base[49]) (XEN) ACPI: IOSAPIC (id[0x4] address[fed28800] gsi_base[60]) (XEN) ACPI: IOSAPIC (id[0x6] address[fed2c800] gsi_base[71]) (XEN) 2 CPUs available, 2 CPUs total (XEN) MCA related initialization done (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) CPU 0: base freq=200.000MHz, ITC ratio=13/2, ITC freq=1300.000MHz+/-650ppm (XEN) Time init: (XEN) System Time: 18750095ns (XEN) scale: C4EC4EC4 (XEN) Boot processor id 0x0/0x0 (XEN) num_online_cpus=1, max_cpus=64 (XEN) cpu_init:
Re: [Xen-ia64-devel] Please try PV-on-HVM on IPF
Le Mardi 17 Octobre 2006 15:12, [EMAIL PROTECTED] a écrit : Hi Tristan, Thank you for your comment. You (Tristan.Gingold) said: [linux-2.6.16.29 on VT-i domain] # cat /proc/iomem -0009 : System RAM 000a-000b : reserved 000c-000f : reserved 0010-03ff : System RAM 0400-04bf3fff : System RAM 0400-046d34bf : Kernel code 046d34c0-04bf373f : Kernel data 04bf4000-3c458fff : System RAM deleted * 3ff7-3fffdfff : System RAM 3fffe000-3fff : reserved c000-c1ff : :00:02.0 c200-c2ff : :00:03.0 c300-c3000fff : :00:02.0 e000-e033dcf7 : PCI Bus :00 I/O Ports -0cf7 e0340d00-e3ff : PCI Bus :00 I/O Ports 0d00- [RHEL4 U2 on VT-i domain] # cat /proc/iomem c000-c1ff : PCI Bus :00 c000-c1ff : :00:02.0 c200-c2ff : :00:03.0 c200-c2000fff : PCI Bus :00 c300-c3000fff : :00:02.0 On RHEL4 U2 environment, I could show only this message. It's strange, and it's the reason that xen-platform-pci.ko module can't be attached, I think. I don't understand what is happend. Does anyone know the reason ? I do not really understand what is strange for you. The output is not the same but: * it may be due to kernel version * the xen pseudo device appears in both version. I think that the diffence are noticed.. [linux-2.6.16.29 on VT-i domain] c200-c2ff : :00:03.0 [RHEL4 U2 on VT-i domain] c200-c2ff : :00:03.0 c200-c2000fff : PCI Bus :00 OK, it is now clearer. Sorry I missed it! On RHEL4 U2 kernel (Linux version 2.6.9-22.EL), xen-platform-pci includes `PCI Bus :00', but it should be the leaf node, I think. To insmod xen-platform-pci, this iomem space was conflicted with the inner device, thus it can't be attached. At least RHEL4 U2 is coherent! But I do not understand where 'c200-c2000fff : PCI Bus :00' comes from. According to your lspci, there is nothing here. Maybe it was added by the ACPI table ? This is strange indeed :-( Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] crash on xen-ia64-unstable 11810:fcd746cf4647
Unfortunately fixing the xen/xenlinux mismatch didn't solve the problem... Xen version 3.0-unstable ([EMAIL PROTECTED]) (gcc version 4.1.1 20060828 (Red Hat 4.1.1-20)) Tue Oct 17 09:43:08 EDT 2006 Latest ChangeSet: Mon Oct 16 22:44:25 2006 -0400 11811:e06634ca24f6 (XEN) Xen command line: (XEN) xen image pstart: 0x400, xenheap pend: 0x800 (XEN) Xen patching physical address access by offset: 0x0 (XEN) find_memory: efi_memmap_walk returns max_page=103ffef (XEN) Before xen_heap_start: f4139e58 (XEN) After xen_heap_start: f4348000 (XEN) warning: skipping physical page 0 (XEN) Init boot pages: 0x4000 - 0x400. (XEN) Init boot pages: 0x800 - 0x3f5e4000. (XEN) Init boot pages: 0x3fb0 - 0x3fb2c000. (XEN) Init boot pages: 0x404000 - 0x40fcb51000. (XEN) Init boot pages: 0x40fd9b3d00 - 0x40fdf8c008. (XEN) Init boot pages: 0x40fdf8c068 - 0x40fdf8ffdf. (XEN) Init boot pages: 0x40fdf90008 - 0x40fef98008. (XEN) Init boot pages: 0x40fef986f8 - 0x40ffd68000. (XEN) Init boot pages: 0x40ffda4000 - 0x40ffe1. (XEN) Init boot pages: 0x40ffe8 - 0x40fffbc000. (XEN) System RAM: 4085MB (4183168kB) (XEN) size of virtual frame_table: 10288kB (XEN) virtual machine to physical table: f3fff7e00088 size: 2096kB (XEN) max_page: 0x103ffef (XEN) Xen heap: 60MB (62176kB) (XEN) ACPI: RSDP (v002 HP) @ 0x3fb2e000 (XEN) ACPI: XSDT (v001 HP rx2600 0x HP 0x) @ 0x3fb2e02c (XEN) ACPI: FADT (v003 HP rx2600 0x HP 0x) @ 0x3fb36800 (XEN) ACPI: SPCR (v001 HP rx2600 0x HP 0x) @ 0x3fb36938 (XEN) ACPI: DBGP (v001 HP rx2600 0x HP 0x) @ 0x3fb36988 (XEN) ACPI: MADT (v001 HP rx2600 0x HP 0x) @ 0x3fb36a48 (XEN) ACPI: SPMI (v004 HP rx2600 0x HP 0x) @ 0x3fb369c0 (XEN) ACPI: CPEP (v001 HP rx2600 0x HP 0x) @ 0x3fb36a10 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb33870 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb33a50 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb33da0 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb347c0 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb351e0 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb35c00 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb36620 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb36710 (XEN) ACPI: DSDT (v001 HP rx2600 0x0007 INTL 0x02012044) @ 0x (XEN) SAL 3.1: HP version 2.31 (XEN) SAL Platform features: None (XEN) SAL: AP wakeup using external interrupt vector 0xff (XEN) No logical to physical processor mapping available (XEN) avail:0x1180c600, status:0x600,control:0x1180c000, vm?0x0 (XEN) No VT feature supported. (XEN) cpu_init: current=f40e (XEN) vhpt_init: vhpt paddr=0x40fcb4, end=0x40fcb4 (XEN) ACPI: Local APIC address e800fee0 (XEN) ACPI: LAPIC_ADDR_OVR (address[fee0]) (XEN) ACPI: LSAPIC (acpi_id[0x00] lsapic_id[0x00] lsapic_eid[0x00] enabled) (XEN) CPU 0 (0x) enabled (BSP) (XEN) ACPI: LSAPIC (acpi_id[0x01] lsapic_id[0x01] lsapic_eid[0x00] enabled) (XEN) CPU 1 (0x0100) enabled (XEN) ACPI: IOSAPIC (id[0x0] address[fed20800] gsi_base[16]) (XEN) ACPI: IOSAPIC (id[0x1] address[fed22800] gsi_base[27]) (XEN) ACPI: IOSAPIC (id[0x2] address[fed24800] gsi_base[38]) (XEN) ACPI: IOSAPIC (id[0x3] address[fed26800] gsi_base[49]) (XEN) ACPI: IOSAPIC (id[0x4] address[fed28800] gsi_base[60]) (XEN) ACPI: IOSAPIC (id[0x6] address[fed2c800] gsi_base[71]) (XEN) 2 CPUs available, 2 CPUs total (XEN) MCA related initialization done (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) CPU 0: base freq=200.000MHz, ITC ratio=13/2, ITC freq=1300.000MHz+/-650ppm (XEN) Time init: (XEN) System Time: 18750245ns (XEN) scale: C4EC4EC4 (XEN) Boot processor id 0x0/0x0 (XEN) num_online_cpus=1, max_cpus=64 (XEN) cpu_init: current=f7ff (XEN) vhpt_init: vhpt paddr=0x40fef8, end=0x40fef8 (XEN) CPU 1: synchronized ITC with CPU 0 (last diff -13 cycles, maxerr 604 cycles) (XEN) CPU 1: base freq=200.000MHz, ITC ratio=13/2, ITC freq=1300.000MHz+/-650ppm (XEN) Brought up 2 CPUs (XEN) Total of 2 processors activated (0.52 BogoMIPS). (XEN) Maximum number of domains: 63; 18 RID bits per domain (XEN) GSI 34 (edge, high) - CPU 0 (0x) vector 48 (XEN) ERROR: Failed to allocate na16550 IRQ 3 (XEN) tlb_track_allocate_entries:68 allocated 256 num_entries 256 num_free 256 (XEN) tlb_track_create:114 hash 0xf040fd9b4000 hash_size 512 (XEN) ### domain f7c88080:
RE: [Xen-ia64-devel] Please try PV-on-HVM on IPF
Hi Tsunehisa,
I have tried your patch and tried the modules in VTI domains.
VBD hasn't problem. I can mount VBD hard disk xvda successfully.
But VNIF modules has problems. After I tried to insmod VNIF driver, VTI domain
crashed.
My vnif config: vif= [ 'type=ioemu, bridge=xenbr0', ' ' ]
BTW, I remake the VTI kernel with 2.6.16.
Following is the log:
＝＝＝
[EMAIL PROTECTED] ~]# insmod xen-platform-pci.ko
PCI: Enabling device :00:03.0 (0010 - 0013)
Grant table initialized
[EMAIL PROTECTED] ~]# insmod xenbus.ko
[EMAIL PROTECTED] ~]# insmod xen-vnif.ko
[EMAIL PROTECTED] ~]# vif vif-0: 2 parsing device/vif/0/mac
netif_release_rx_bufs: fix me for copying receiver.
kernel BUG at net/core/dev.c:3073!
xenwatch[3970]: bugcheck! 0 [1]
Modules linked in: xen_vnif xenbus xen_platform_pci sunrpc binfmt_misc dm_mod
thermal processor fan container button
Pid: 3970, CPU 0, comm: xenwatch
psr : 1010081a6018 ifs : 838b ip : [a001005eec40]Not
tainted
ip is at unregister_netdevice+0x1a0/0x580
unat: pfs : 038b rsc : 0003
rnat: a00100a646c1 bsps: 0007 pr : 6941
ldrs: ccv : fpsr: 0009804c8a70433f
csd : ssd :
b0 : a001005eec40 b6 : a001000b79c0 b7 : a001bbc0
f6 : 1003e00a0 f7 : 1003e20c49ba5e353f7cf
f8 : 1003e04e2 f9 : 1003e0fa0
f10 : 1003e3b9aca00 f11 : 1003e431bde82d7b634db
r1 : a00100b34120 r2 : 0002 r3 : 00104000
r8 : 0026 r9 : 0001 r10 : e1014644
r11 : 0003 r12 : e25b7da0 r13 : e25b
r14 : 4000 r15 : a0010086f558 r16 : a0010086f560
r17 : e1d9fde8 r18 : e1d98030 r19 : e1014638
r20 : 0073 r21 : 0003 r22 : 0002
r23 : e1d98040 r24 : e1014608 r25 : e1014d80
r26 : e1014d60 r27 : 0073 r28 : 0073
r29 : r30 : r31 :
Call Trace:
[a00100011df0] show_stack+0x50/0xa0
sp=e25b7910 bsp=e25b12e0
[a001000126c0] show_regs+0x820/0x840
sp=e25b7ae0 bsp=e25b1298
[a00100037030] die+0x1d0/0x2e0
sp=e25b7ae0 bsp=e25b1250
[a00100037180] die_if_kernel+0x40/0x60
sp=e25b7b00 bsp=e25b1220
[a001000373d0] ia64_bad_break+0x230/0x480
sp=e25b7b00 bsp=e25b11f0
[a001c3c0] ia64_leave_kernel+0x0/0x280
sp=e25b7bd0 bsp=e25b11f0
[a001005eec40] unregister_netdevice+0x1a0/0x580
sp=e25b7da0 bsp=e25b1198
[a001005ef050] unregister_netdev+0x30/0x60
sp=e25b7da0 bsp=e25b1178
[a002000c5cd0] close_netdev+0x90/0xc0 [xen_vnif]
sp=e25b7da0 bsp=e25b1140
[a002000c7870] backend_changed+0x1030/0x1080 [xen_vnif]
sp=e25b7da0 bsp=e25b10a8
[a002000e5160] otherend_changed+0x160/0x1a0 [xenbus]
sp=e25b7dc0 bsp=e25b1068
[a002000e3e70] xenwatch_handle_callback+0x70/0x100 [xenbus]
sp=e25b7dc0 bsp=e25b1040
[a002000e4230] xenwatch_thread+0x330/0x3a0 [xenbus]
sp=e25b7dc0 bsp=e25b1018
[a001000b6e20] kthread+0x180/0x200
sp=e25b7e20 bsp=e25b0fd8
[a001000141b0] kernel_thread_helper+0xd0/0x100
sp=e25b7e30 bsp=e25b0fb0
[a00194c0] start_kernel_thread+0x20/0x40
sp=e25b7e30 bsp=e25b0fb0
BUG: xenwatch/3970, lock held at task exit time!
[a002000f0cf8] {xenwatch_mutex}
.. held by: xenwatch: 3970 [e25b, 110]
... acquired at: xenwatch_thread+0x1e0/0x3a0 [xenbus]
Best Regards,
Yongkang (Kangkang) 永康
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of DOI
Tsunehisa
Sent: 2006年10月16日 20:31
To: xen-ia64-devel
Subject: [Xen-ia64-devel] Please try PV-on-HVM on IPF
Hi all,
We've ported PV-on-HVM drivers for IPF. But I think that
only few tries it. Thus, I try to describe to use it.
And I attach several patches about PV-on-HVM.
+ fix-warning.patch
- warning fix for HVM PV driver
+ notsafe-comment.patch
- add not-SMP-safe comment about PV-on-HVM
- to take Isaku's suggestion.
+ pv-backport.patch (preliminary)
RE: [Xen-ia64-devel] Please try PV-on-HVM on IPF
EM~. If I didn't use both ioemu and vnif at the same time, I can use vnif. :) The workable vnif config: vnif=[ ' ' ] But I also meet kernel call trace, when running kuduz, after insmod vnif moduel. The call trace log: = Modules linked in: xen_vnif xenbus xen_platform_pci sunrpc binfmt_misc dm_mod thermal processor fan container button Pid: 4061, CPU 0, comm:kudzu psr : 121008026038 ifs : 8003 ip : [a00100461621]Not taintede selects | F12 next screen ip is at serial_in+0x301/0x340 unat: pfs : 060f rsc : 0003 rnat: a00100a646c1 bsps: 0007 pr : 05566aa5 ldrs: ccv : fpsr: 0009804c8a70033f csd : ssd : b0 : a00100462ff0 b6 : a00100462f80 b7 : a0010004cfe0 f6 : 1003e000b421fa3e8 f7 : 1003e018f f8 : 1003e000b421fa259 f9 : 1003e0001 f10 : 0fffdc8c0 f11 : 1003e r1 : a00100b34120 r2 : 00ff r3 : a00100a646a8 r8 : 0100 r9 : 0080 r10 : a00100a645d4 r11 : c000e00fe3f8 r12 : eb15fbe0 r13 : eb158000 r14 : 03fa r15 : 000fe3fa r16 : a00100a645d4 r17 : a0010094de00 r18 : 0001 r19 : 0002 r20 : 03f8 r21 : c000e00fe3fa r22 : c000e000 r23 : a0010094de00 r24 : 03fa r25 : 0001 r26 : a0010094de08 r27 : a0010094de00 r28 : r29 : a0010094de00 r30 : 03fa r31 : 00ff Call Trace: [a00100011df0] show_stack+0x50/0xa0 sp=eb15f830 bsp=eb1595d0 [a001000126c0] show_regs+0x820/0x840 sp=eb15fa00 bsp=eb159588 [a001000d2a30] softlockup_tick+0x150/0x180 sp=eb15fa00 bsp=eb159558 [a0010009e210] do_timer+0x990/0x9c0 sp=eb15fa10 bsp=eb159510 [a00100035fa0] timer_interrupt+0x200/0x340 sp=eb15fa10 bsp=eb1594d0 [a001000d30b0] handle_IRQ_event+0x90/0x120 sp=eb15fa10 bsp=eb159490 [a001000d3290] __do_IRQ+0x150/0x3e0 sp=eb15fa10 bsp=eb159440 [a00100010e60] ia64_handle_irq+0xa0/0x140 sp=eb15fa10 bsp=eb159418 [a001c3c0] ia64_leave_kernel+0x0/0x280 sp=eb15fa10 bsp=eb159418 [a00100461620] serial_in+0x300/0x340 sp=eb15fbe0 bsp=eb159400 [a00100462ff0] serial8250_interrupt+0x70/0x200 sp=eb15fbe0 bsp=eb159398 [a001000d30b0] handle_IRQ_event+0x90/0x120 sp=eb15fbf0 bsp=eb159358 [a001000d3400] __do_IRQ+0x2c0/0x3e0 sp=eb15fbf0 bsp=eb159308 [a00100010e60] ia64_handle_irq+0xa0/0x140 sp=eb15fbf0 bsp=eb1592e0 [a001c3c0] ia64_leave_kernel+0x0/0x280 sp=eb15fbf0 bsp=eb1592e0 Best Regards, Yongkang (Kangkang) 永康 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of You, Yongkang Sent: 2006年10月17日 22:27 To: DOI Tsunehisa; xen-ia64-devel Subject: RE: [Xen-ia64-devel] Please try PV-on-HVM on IPF Hi Tsunehisa, I have tried your patch and tried the modules in VTI domains. VBD hasn't problem. I can mount VBD hard disk xvda successfully. But VNIF modules has problems. After I tried to insmod VNIF driver, VTI domain crashed. My vnif config: vif= [ 'type=ioemu, bridge=xenbr0', ' ' ] BTW, I remake the VTI kernel with 2.6.16. Following is the log: ＝＝ ＝ [EMAIL PROTECTED] ~]# insmod xen-platform-pci.ko PCI: Enabling device :00:03.0 (0010 - 0013) Grant table initialized [EMAIL PROTECTED] ~]# insmod xenbus.ko [EMAIL PROTECTED] ~]# insmod xen-vnif.ko [EMAIL PROTECTED] ~]# vif vif-0: 2 parsing device/vif/0/mac netif_release_rx_bufs: fix me for copying receiver. kernel BUG at net/core/dev.c:3073! xenwatch[3970]: bugcheck! 0 [1] Modules linked in: xen_vnif xenbus xen_platform_pci sunrpc binfmt_misc dm_mod thermal processor fan container button Pid: 3970, CPU 0, comm: xenwatch psr : 1010081a6018 ifs : 838b ip : [a001005eec40]Not tainted ip is at unregister_netdevice+0x1a0/0x580 unat: pfs : 038b rsc : 0003 rnat: a00100a646c1 bsps: 0007 pr : 6941 ldrs: ccv : fpsr: 0009804c8a70433f csd :
Re: [Xen-ia64-devel] crash on xen-ia64-unstable 11810:fcd746cf4647
On Tue, 2006-10-17 at 09:17 -0400, Aron Griffis wrote: I got this panic booting an rx2600 (which normally boots with xen). Does this look familiar to anybody? Xen version 3.0-unstable ([EMAIL PROTECTED]) (gcc version 4.1.0 (Gentoo 4.1.0)) Wed Sep 27 17:25:14 EDT 2006 Latest ChangeSet: Wed Sep 27 17:05:45 2006 -0400 11638:75b47fc791bb ^ Xen/XenLinux mismatch? ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] progress on blktap
I started with Chris Wright's patch and backported it to xen-ia64-unstable, from 2.6.18 base to 2.6.16, which means simply that ioremap.c isn't available so the code needs another home. hypervisor.c seems like the right place. The patch at the bottom of this mail allows blktap to build. The kernel boots and other backend methods continue to work (tested booting domu). blktap method starts to boot but hits a problem. /etc/xen/domu-g2-blktap contains: kernel = /boot/vmlinux-xen.gz memory = 512 name = domu-g2 vif = [ '' ] disk = [ 'tap:aio:/var/lib/xen/domu-g2.img,hda1,w' ] root = /dev/hda1 ro domu messages: ... netfront: device eth0 has flipping receive path. IP route cache hash table entries: 4096 (order: 1, 32768 bytes) TCP established hash table entries: 16384 (order: 4, 262144 bytes) TCP bind hash table entries: 16384 (order: 4, 262144 bytes) TCP: Hash tables configured (established 16384 bind 16384) TCP reno registered TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 Bridge firewalling registered xen privcmd uses pseudo physical addr range [0x2000, 0x300] (4193776MB) Xen p2m: assign p2m table of [0x, 0x2000) Xen p2m: to [0x2000, 0x23ffc000) (65536 KBytes) [stops here] dom0 messages: ... (XEN) tlb_track_allocate_entries:68 allocated 256 num_entries 256 num_free 256 (XEN) tlb_track_create:114 hash 0xf040e5858000 hash_size 512 (XEN) ### domain f7b74080: rid=8-c mp_rid=2000 (XEN) arch_domain_create: domain=f7b74080 (XEN) DomainU EFI build up: ACPI 2.0=0x1000 (XEN) dom mem: type=13, attr=0x8008, range=[0x-0x1000) (4KB) (XEN) dom mem: type=10, attr=0x8008, range=[0x1000-0x2000) (4KB) (XEN) dom mem: type= 6, attr=0x8008, range=[0x2000-0x3000) (4KB) (XEN) dom mem: type= 7, attr=0x0008, range=[0x3000-0x1fff4000) (511MB) (XEN) dom mem: type=12, attr=0x0001, range=[0x0c00-0x1000) (64MB) (XEN) vcpu_get_lrr0: Unmasked interrupts unsupported (XEN) vcpu_get_lrr1: Unmasked interrupts unsupported (XEN) Domain set shared_info_va to 0xfff0 (XEN) Linux version 2.6.16.29-xen ([EMAIL PROTECTED]) (gcc version 4.1.1 (Gentoo 4.1.1-r1)) #1 SMP Tue Oct 17 13:52:41 EDT 2006 EFI v1.00 by Xen/ia64: SALsystab=0x2178 ACPI 2.0=0x1000 SAL 0.1: Xen/ia64 Xen/ia64 version 0.0 SAL: AP wakeup using external interrupt vector 0xf3 xen_pal_emulator: UNIMPLEMENTED PAL CALL 42 (XEN) No logical to physical processor mapping available ACPI: Local APIC address c000fee0 ACPI: Error parsing MADT - no IOSAPIC entries 1 CPUs available, 1 CPUs total Running on Xen! start_info_pfn=0x7ffd nr_pages=32768 flags=0x0 *** CALLED SAL_MC_SET_PARAMS. IGNORED... (XEN) *** CALLED SAL_MC_SET_PARAMS. IGNORED... (XEN) *** CALLED SAL_SET_VECTORS 0. IGNORED... (XEN) *** CALLED SAL_SET_VECTORS 1. IGNORED... (XEN) MCA related initialization done SMP: Allowing 1 CPUs, 0 hotplug CPUs Built 1 zonelists Kernel command line: root=/dev/hda1 ro PID hash table entries: 2048 (order: 11, 65536 bytes) lookup_domain_mpa: d 0xf7b74080 id 2 current 0xf7b58000 id 0 (XEN) lookup_domain_mpa: bad mpa 0xc019064 (= 0x2000) (XEN) Warning: UC to WB for mpaddr=c019064 gnttab_map_grant_ref_pre:308 GNTMAP_application_map is not supported yet: flags 0x1a xvd 2[7209]: bugcheck! 0 [1] Modules linked in: Pid: 7209, CPU 0, comm:xvd 2 psr : 001008026010 ifs : 838b ip : [a0010006a170]Not tainted ip is at HYPERVISOR_grant_table_op+0x170/0x280 unat: pfs : 838b rsc : 000b rnat: 401475d0 bsps: 4012b9c0 pr : 6681 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a0010006a170 b6 : a00100072e20 b7 : a001000681b0 f6 : 1003e0028 f7 : 1003e28f5c28f5c28f5c3 f8 : 1003e00fa f9 : 1003e3200 f10 : 1003e3b9aca00 f11 : 1003ed6bf94d5e57a42bd r1 : a0010102d710 r2 : a00100e52738 r3 : a00100e52738 r8 : 0031 r9 : fff1 r10 : r11 : fff04c20 r12 : e00016447b20 r13 : e0001644 r14 : 4000 r15 : 0001 r16 : fff04c18 r17 : e0014248 r18 : 0001 r19 : e0014b58 r20 : e0001c418030 r21 : e0001c418030 r22 : 0001 r23 : e00152a8 r24 : e00152a0 r25 : 0750 r26 : 0730 r27 : 0073 r28 : 0073 r29 : 0073 r30 : d6bf94d5e57a42bd r31 : e0001c418078 Call Trace: [a0010001ca20] show_stack+0x40/0xa0 sp=e000164476b0 bsp=e00016441260
Re: [Xen-ia64-devel] crash on xen-ia64-unstable 11810:fcd746cf4647
Hi, Aron Do you use FC6? If so, it's compiler issue. Please see the following link. I posted a patch to fix it. https://www.redhat.com/archives/fedora-ia64-list/2006-August/msg00059.html Best Regards, Akio Takebe Unfortunately fixing the xen/xenlinux mismatch didn't solve the problem... Xen version 3.0-unstable ([EMAIL PROTECTED]) (gcc version 4.1.1 20060828 (Red Hat 4.1.1-20)) Tue Oct 17 09:43:08 EDT 2006 Latest ChangeSet: Mon Oct 16 22:44:25 2006 -0400 11811:e06634ca24f6 (XEN) Xen command line: (XEN) xen image pstart: 0x400, xenheap pend: 0x800 (XEN) Xen patching physical address access by offset: 0x0 (XEN) find_memory: efi_memmap_walk returns max_page=103ffef (XEN) Before xen_heap_start: f4139e58 (XEN) After xen_heap_start: f4348000 (XEN) warning: skipping physical page 0 (XEN) Init boot pages: 0x4000 - 0x400. (XEN) Init boot pages: 0x800 - 0x3f5e4000. (XEN) Init boot pages: 0x3fb0 - 0x3fb2c000. (XEN) Init boot pages: 0x404000 - 0x40fcb51000. (XEN) Init boot pages: 0x40fd9b3d00 - 0x40fdf8c008. (XEN) Init boot pages: 0x40fdf8c068 - 0x40fdf8ffdf. (XEN) Init boot pages: 0x40fdf90008 - 0x40fef98008. (XEN) Init boot pages: 0x40fef986f8 - 0x40ffd68000. (XEN) Init boot pages: 0x40ffda4000 - 0x40ffe1. (XEN) Init boot pages: 0x40ffe8 - 0x40fffbc000. (XEN) System RAM: 4085MB (4183168kB) (XEN) size of virtual frame_table: 10288kB (XEN) virtual machine to physical table: f3fff7e00088 size: 2096kB (XEN) max_page: 0x103ffef (XEN) Xen heap: 60MB (62176kB) (XEN) ACPI: RSDP (v002 HP) @ 0x3fb2e000 (XEN) ACPI: XSDT (v001 HP rx2600 0x HP 0x) @ 0x3fb2e02c (XEN) ACPI: FADT (v003 HP rx2600 0x HP 0x) @ 0x3fb36800 (XEN) ACPI: SPCR (v001 HP rx2600 0x HP 0x) @ 0x3fb36938 (XEN) ACPI: DBGP (v001 HP rx2600 0x HP 0x) @ 0x3fb36988 (XEN) ACPI: MADT (v001 HP rx2600 0x HP 0x) @ 0x3fb36a48 (XEN) ACPI: SPMI (v004 HP rx2600 0x HP 0x) @ 0x3fb369c0 (XEN) ACPI: CPEP (v001 HP rx2600 0x HP 0x) @ 0x3fb36a10 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb33870 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb33a50 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb33da0 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb347c0 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb351e0 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb35c00 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb36620 (XEN) ACPI: SSDT (v001 HP rx2600 0x0006 INTL 0x02012044) @ 0x3fb36710 (XEN) ACPI: DSDT (v001 HP rx2600 0x0007 INTL 0x02012044) @ 0x (XEN) SAL 3.1: HP version 2.31 (XEN) SAL Platform features: None (XEN) SAL: AP wakeup using external interrupt vector 0xff (XEN) No logical to physical processor mapping available (XEN) avail:0x1180c600, status:0x600,control: 0x1180c000, vm?0x0 (XEN) No VT feature supported. (XEN) cpu_init: current=f40e (XEN) vhpt_init: vhpt paddr=0x40fcb4, end=0x40fcb4 (XEN) ACPI: Local APIC address e800fee0 (XEN) ACPI: LAPIC_ADDR_OVR (address[fee0]) (XEN) ACPI: LSAPIC (acpi_id[0x00] lsapic_id[0x00] lsapic_eid[0x00] enabled) (XEN) CPU 0 (0x) enabled (BSP) (XEN) ACPI: LSAPIC (acpi_id[0x01] lsapic_id[0x01] lsapic_eid[0x00] enabled) (XEN) CPU 1 (0x0100) enabled (XEN) ACPI: IOSAPIC (id[0x0] address[fed20800] gsi_base[16]) (XEN) ACPI: IOSAPIC (id[0x1] address[fed22800] gsi_base[27]) (XEN) ACPI: IOSAPIC (id[0x2] address[fed24800] gsi_base[38]) (XEN) ACPI: IOSAPIC (id[0x3] address[fed26800] gsi_base[49]) (XEN) ACPI: IOSAPIC (id[0x4] address[fed28800] gsi_base[60]) (XEN) ACPI: IOSAPIC (id[0x6] address[fed2c800] gsi_base[71]) (XEN) 2 CPUs available, 2 CPUs total (XEN) MCA related initialization done (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) CPU 0: base freq=200.000MHz, ITC ratio=13/2, ITC freq=1300.000MHz+/- 650ppm (XEN) Time init: (XEN) System Time: 18750245ns (XEN) scale: C4EC4EC4 (XEN) Boot processor id 0x0/0x0 (XEN) num_online_cpus=1, max_cpus=64 (XEN) cpu_init: current=f7ff (XEN) vhpt_init: vhpt paddr=0x40fef8, end=0x40fef8 (XEN) CPU 1: synchronized ITC with CPU 0 (last diff -13 cycles, maxerr 604 cycles) (XEN) CPU 1: base freq=200.000MHz, ITC ratio=13/2, ITC freq=1300.000MHz+/- 650ppm (XEN) Brought up 2 CPUs (XEN) Total of 2 processors activated (0.52 BogoMIPS). (XEN) Maximum number of domains: 63; 18 RID bits per domain (XEN) GSI 34 (edge, high) - CPU 0 (0x) vector 48 (XEN)
Re: [Xen-ia64-devel] crash on xen-ia64-unstable 11810:fcd746cf4647
Akio Takebe wrote: [Tue Oct 17 2006, 05:19:06PM EDT] Hi, Aron Do you use FC6? If so, it's compiler issue. Please see the following link. I posted a patch to fix it. https://www.redhat.com/archives/fedora-ia64-list/2006-August/msg00059.html Thanks Akio, that was the problem. I switched to a Gentoo compiler and the problem went away. I wonder if the patch should be applied to xen-ia64-unstable.hg even though it is already fixed in linux-2.6.18. The eventual merge should be easy, and it enables Fedora users to work with xen-ia64-unstable bits. What do you think? Regards, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] crash on xen-ia64-unstable 11810:fcd746cf4647
Hi, Aron and Alex It may be so, we need to add the patch into patches/ directory. I had thought xen-ia64-unstable was not needed because it was linux kernel problem. Alex, do you also think necessry? I can post the new patch. Best Regards, Akio Takebe Akio Takebe wrote: [Tue Oct 17 2006, 05:19:06PM EDT] Hi, Aron Do you use FC6? If so, it's compiler issue. Please see the following link. I posted a patch to fix it. https://www.redhat.com/archives/fedora-ia64-list/2006-August/msg00059.html Thanks Akio, that was the problem. I switched to a Gentoo compiler and the problem went away. I wonder if the patch should be applied to xen-ia64-unstable.hg even though it is already fixed in linux-2.6.18. The eventual merge should be easy, and it enables Fedora users to work with xen-ia64-unstable bits. What do you think? Regards, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] crash on xen-ia64-unstable 11810:fcd746cf4647
On Wed, 2006-10-18 at 07:07 +0900, Akio Takebe wrote: Hi, Aron and Alex It may be so, we need to add the patch into patches/ directory. I had thought xen-ia64-unstable was not needed because it was linux kernel problem. Alex, do you also think necessry? I can post the new patch. Hi Akio, I've heard of several people hitting this problem now, so I'd be willing to take a backport of the upstream linux-ia64 patch. I assume we just need the ia64/kernel/Makefile and ia64/kernel/gate.lds.S changes from this patch, right? http://www.kernel.org/hg/linux-2.6/?cs=dfbee33b0693 Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] BUG at mm.c:605
I seem to be hitting the BUG below with increasing regularity lately. Typically it occurs right when a domU is in the middle of rebooting (it appears to have shut down completely, I get a dom0 console prompt, then the BUG below). It's random enough that I haven't been able to isolate it to a particular changeset. Has anyone else seen this or (better yet) have a fix? It's getting in the way of testing all the new patches since I'm seeing this on xen-ia64-unstable.hg. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. (XEN) BUG at mm.c:605 (XEN) die_if_kernel: bug check 0 (XEN) d 0xf7c88080 domid 0 (XEN) vcpu 0xf7c6 vcpu 0 (XEN) (XEN) CPU 0 (XEN) psr : 101008226038 ifs : 8288 ip : [f4048e50] (XEN) ip is at __bug+0x40/0x60 (XEN) unat: pfs : 0288 rsc : 0003 (XEN) rnat: 4000 bsps: 435b pr : 0059aa69 (XEN) ldrs: ccv : fpsr: 0009804c8a70033f (XEN) csd : ssd : (XEN) b0 : f4048e50 b6 : f4049e10 b7 : a0010064afa0 (XEN) f6 : 0fffbc8c0 f7 : 0ffdbf300 (XEN) f8 : 10001c000 f9 : 10002a000 (XEN) f10 : 0fffe9690 f11 : 1003e (XEN) r1 : f4326f00 r2 : 435b r3 : f040fdad7781 (XEN) r8 : r9 : r10 : (XEN) r11 : 005a0969 r12 : f7c67900 r13 : f7c6 (XEN) r14 : 4000 r15 : f412ff2a r16 : 4001 (XEN) r17 : f41294fc r18 : 035b r19 : f41294f8 (XEN) r20 : f7c67860 r21 : f7c60010 r22 : 0080 (XEN) r23 : 0002003c r24 : f7c67e20 r25 : f7c67e28 (XEN) r26 : r27 : r28 : (XEN) r29 : 0001 r30 : r31 : f4133db8 (XEN) (XEN) Call Trace: (XEN) [f40a0330] show_stack+0x80/0xa0 (XEN) sp=f7c67520 bsp=f7c612c0 (XEN) [f407abc0] die_if_kernel+0x90/0xe0 (XEN) sp=f7c676f0 bsp=f7c61290 (XEN) [f406f330] ia64_handle_break+0x220/0x2d0 (XEN) sp=f7c676f0 bsp=f7c61258 (XEN) [f409d220] ia64_leave_kernel+0x0/0x310 (XEN) sp=f7c67700 bsp=f7c61258 (XEN) [f4048e50] __bug+0x40/0x60 (XEN) sp=f7c67900 bsp=f7c61218 (XEN) [f4063f10] lookup_noalloc_domain_pte+0x40/0x130 (XEN) sp=f7c67900 bsp=f7c611e8 (XEN) [f4065d40] lookup_domain_mpa+0x30/0x250 (XEN) sp=f7c67900 bsp=f7c611b8 (XEN) [f40664f0] gmfn_to_mfn_foreign+0xc0/0xf0 (XEN) sp=f7c67900 bsp=f7c61190 (XEN) [f4026910] __acquire_grant_for_copy+0x3a0/0x490 (XEN) sp=f7c67900 bsp=f7c61140 (XEN) [f4029870] do_grant_table_op+0x1f80/0x2c20 (XEN) sp=f7c67900 bsp=f7c61038 (XEN) [f402f060] do_multicall+0x2b0/0x390 (XEN) sp=f7c67960 bsp=f7c60fa0 (XEN) [f405ec40] ia64_hypercall+0x990/0x1020 (XEN) sp=f7c67960 bsp=f7c60f40 (XEN) [f406f260] ia64_handle_break+0x150/0x2d0 (XEN) sp=f7c67df0 bsp=f7c60f08 (XEN) [f409d220] ia64_leave_kernel+0x0/0x310 (XEN) sp=f7c67e00 bsp=f7c60f08 (XEN) domain_crash_sync called from xenmisc.c:108 (XEN) Domain 0 (vcpu#0) crashed on cpu#0: (XEN) d 0xf7c88080 domid 0 (XEN) vcpu 0xf7c6 vcpu 0 (XEN) (XEN) CPU 0 (XEN) psr : 101208026030 ifs : 840b ip : [a0010006d4d0] (XEN) ip is at ??? (XEN) unat: pfs : 840b rsc : 000b (XEN) rnat: bsps: e00079609260 pr : 005a5a65 (XEN) ldrs: 0168 ccv : fpsr: 0009804c8a70433f (XEN) csd : ssd : (XEN) b0 : a0010006d4a0 b6 : a001006aee00 b7 : a0010064afa0 (XEN) f6 : 1003e f7 : 1003e023a (XEN) f8 : 0fffe8e7fdc60 f9 : 1003efc00 (XEN) f10 : 0 f11 : 0 (XEN) r1 : a0010102cc90 r2 : 000d r3 : 84fb7758 (XEN) r8 : 04fb7758 r9 : r10 : (XEN) r11 : a00100da9248 r12 : e0007960fbd0 r13 : e00079608000 (XEN) r14 :
Re: [Xen-ia64-devel] progress on blktap
Hi Aron. This is the Xen/IA64 specific issues that Xen/IA64 doesn't support grant table page mapping with GNTMAP_application_map and/or GNTMAP_contains_pte specified. Xen/IA64 fully virtualizes MMU and Xen/IA64 grant table mapping mechanism is based on pseudo physical address, not virtual address, so that those flags doesn't make sense. I suppose that the basic functionalities of Xen/IA64 VMM itself necessary for blktap are already there and only the Linux part effort is necessary. Probably the grant table interface for GNTMAP_application_map and GNTMAP_contains_pte should be re-defined for XENFEAT_auto_translated_physmap mode and the blktap code should be made ware of it. Maybe specialized mmap method and vm area methods are also necessary. thanks. On Tue, Oct 17, 2006 at 04:54:58PM -0400, Aron Griffis wrote: I started with Chris Wright's patch and backported it to xen-ia64-unstable, from 2.6.18 base to 2.6.16, which means simply that ioremap.c isn't available so the code needs another home. hypervisor.c seems like the right place. The patch at the bottom of this mail allows blktap to build. The kernel boots and other backend methods continue to work (tested booting domu). blktap method starts to boot but hits a problem. /etc/xen/domu-g2-blktap contains: kernel = /boot/vmlinux-xen.gz memory = 512 name = domu-g2 vif = [ '' ] disk = [ 'tap:aio:/var/lib/xen/domu-g2.img,hda1,w' ] root = /dev/hda1 ro domu messages: ... netfront: device eth0 has flipping receive path. IP route cache hash table entries: 4096 (order: 1, 32768 bytes) TCP established hash table entries: 16384 (order: 4, 262144 bytes) TCP bind hash table entries: 16384 (order: 4, 262144 bytes) TCP: Hash tables configured (established 16384 bind 16384) TCP reno registered TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 Bridge firewalling registered xen privcmd uses pseudo physical addr range [0x2000, 0x300] (4193776MB) Xen p2m: assign p2m table of [0x, 0x2000) Xen p2m: to [0x2000, 0x23ffc000) (65536 KBytes) [stops here] dom0 messages: ... (XEN) tlb_track_allocate_entries:68 allocated 256 num_entries 256 num_free 256 (XEN) tlb_track_create:114 hash 0xf040e5858000 hash_size 512 (XEN) ### domain f7b74080: rid=8-c mp_rid=2000 (XEN) arch_domain_create: domain=f7b74080 (XEN) DomainU EFI build up: ACPI 2.0=0x1000 (XEN) dom mem: type=13, attr=0x8008, range=[0x-0x1000) (4KB) (XEN) dom mem: type=10, attr=0x8008, range=[0x1000-0x2000) (4KB) (XEN) dom mem: type= 6, attr=0x8008, range=[0x2000-0x3000) (4KB) (XEN) dom mem: type= 7, attr=0x0008, range=[0x3000-0x1fff4000) (511MB) (XEN) dom mem: type=12, attr=0x0001, range=[0x0c00-0x1000) (64MB) (XEN) vcpu_get_lrr0: Unmasked interrupts unsupported (XEN) vcpu_get_lrr1: Unmasked interrupts unsupported (XEN) Domain set shared_info_va to 0xfff0 (XEN) Linux version 2.6.16.29-xen ([EMAIL PROTECTED]) (gcc version 4.1.1 (Gentoo 4.1.1-r1)) #1 SMP Tue Oct 17 13:52:41 EDT 2006 EFI v1.00 by Xen/ia64: SALsystab=0x2178 ACPI 2.0=0x1000 SAL 0.1: Xen/ia64 Xen/ia64 version 0.0 SAL: AP wakeup using external interrupt vector 0xf3 xen_pal_emulator: UNIMPLEMENTED PAL CALL 42 (XEN) No logical to physical processor mapping available ACPI: Local APIC address c000fee0 ACPI: Error parsing MADT - no IOSAPIC entries 1 CPUs available, 1 CPUs total Running on Xen! start_info_pfn=0x7ffd nr_pages=32768 flags=0x0 *** CALLED SAL_MC_SET_PARAMS. IGNORED... (XEN) *** CALLED SAL_MC_SET_PARAMS. IGNORED... (XEN) *** CALLED SAL_SET_VECTORS 0. IGNORED... (XEN) *** CALLED SAL_SET_VECTORS 1. IGNORED... (XEN) MCA related initialization done SMP: Allowing 1 CPUs, 0 hotplug CPUs Built 1 zonelists Kernel command line: root=/dev/hda1 ro PID hash table entries: 2048 (order: 11, 65536 bytes) lookup_domain_mpa: d 0xf7b74080 id 2 current 0xf7b58000 id 0 (XEN) lookup_domain_mpa: bad mpa 0xc019064 (= 0x2000) (XEN) Warning: UC to WB for mpaddr=c019064 gnttab_map_grant_ref_pre:308 GNTMAP_application_map is not supported yet: flags 0x1a xvd 2[7209]: bugcheck! 0 [1] Modules linked in: Pid: 7209, CPU 0, comm:xvd 2 psr : 001008026010 ifs : 838b ip : [a0010006a170] Not tainted ip is at HYPERVISOR_grant_table_op+0x170/0x280 unat: pfs : 838b rsc : 000b rnat: 401475d0 bsps: 4012b9c0 pr : 6681 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a0010006a170 b6 : a00100072e20 b7 : a001000681b0 f6 :
RE: [Xen-ia64-devel] Please try PV-on-HVM on IPF
HI Tsunehisa, More testing results based on changeset 11810: -- 1. I did a continuous KB in VTI VBD disk 35 times, all passed. The KB speed in VBD is a little faster than in IOEMU disk. 2. I did a lot of scp 1G file by VTI VNIF, all pass. The scp speed is extraordinary higher than without VNIF. 3. UP and SMP(2vcpus) VTI can both use PV drivers. Issues: -- I noticed there are too many kernel unaligned access reported by VTI, after insert vnif module. Two issues reported by yesterday: --- 1. If use IOEMU NIC too, insert VNIF driver will cause VTI domain crash. IA32 hasn't this issue. 2. After insert VNIF driver, VTI kernel often calls trace when running applications (kudzu, vi etc.). Best Regards, Yongkang (Kangkang) 永康 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DOI Tsunehisa Sent: 2006年10月16日 20:31 To: xen-ia64-devel Subject: [Xen-ia64-devel] Please try PV-on-HVM on IPF Hi all, We've ported PV-on-HVM drivers for IPF. But I think that only few tries it. Thus, I try to describe to use it. And I attach several patches about PV-on-HVM. + fix-warning.patch - warning fix for HVM PV driver + notsafe-comment.patch - add not-SMP-safe comment about PV-on-HVM - to take Isaku's suggestion. + pv-backport.patch (preliminary) - current HVM PV driver for only 2.6.16 or 2.6.16.* kernel - this is preliminary patch for backporting to before 2.6.16 kernel - we tested only compiling on RHEL4. [Usage of PV-on-HVM] 1) get xen-ia64-unstable.hg tree (after cs:11805) and built it. 2) create a guest system image. - simply, install guest system on VT-i domain 3) build linux-2.6.16 kernel for guest system - get linux-2.6.16 kernel source and build 4) change guest kernel in the image to linux-2.6.16 kernel - edit config file of boot loader 5) build PV-on-HVM drivers # cd xen-ia64-unstable.hg/unmodified_drivers/linux-2.6 # sh mkbuildtree # make -C /usr/src/linux-2.6.16 M=$PWD modules 6) copy the drivers to guest system image - mount guest system image with lomount command. - copy the drivers to guest system image # cp -p */*.ko guest_system... 7) start VT-i domain 8) attach drivers domvti# insmod xen-platform-pci.ko domvti# insmod xenbus.ko domvti# insmod xen-vbd.ko domvti# insmod xen-vnif.ko 9) attach devices with xm block-attach/network-attach - this operation is same for dom-u Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] BUG at mm.c:605
Hi Alex. I think the issue is same as reported in the below thread. http://lists.xensource.com/archives/html/xen-ia64-devel/2006-09/msg00204.html I tried to convince him, but failed. I think that the best way is to revert the patch and we should seek for the right fix. I guess that making xennet.rx_copy default enabled is the beginning. The root cause is that relinquish_memory() writes the P2M simulteniously with __acquire_grant_for_copy(). relinquish_memory() of IA64 assumes that no one else read the P2M table at the same time. However the such assumption is wrong now. Although I haven't dug into its details, I suspect that the race between relinquish_memory() and get_page() (or __acquire_grant_for_copy()) exists not only on ia64, but also on x86. thanks. On Tue, Oct 17, 2006 at 05:13:21PM -0600, Alex Williamson wrote: I seem to be hitting the BUG below with increasing regularity lately. Typically it occurs right when a domU is in the middle of rebooting (it appears to have shut down completely, I get a dom0 console prompt, then the BUG below). It's random enough that I haven't been able to isolate it to a particular changeset. Has anyone else seen this or (better yet) have a fix? It's getting in the way of testing all the new patches since I'm seeing this on xen-ia64-unstable.hg. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. (XEN) BUG at mm.c:605 (XEN) die_if_kernel: bug check 0 (XEN) d 0xf7c88080 domid 0 (XEN) vcpu 0xf7c6 vcpu 0 (XEN) (XEN) CPU 0 (XEN) psr : 101008226038 ifs : 8288 ip : [f4048e50] (XEN) ip is at __bug+0x40/0x60 (XEN) unat: pfs : 0288 rsc : 0003 (XEN) rnat: 4000 bsps: 435b pr : 0059aa69 (XEN) ldrs: ccv : fpsr: 0009804c8a70033f (XEN) csd : ssd : (XEN) b0 : f4048e50 b6 : f4049e10 b7 : a0010064afa0 (XEN) f6 : 0fffbc8c0 f7 : 0ffdbf300 (XEN) f8 : 10001c000 f9 : 10002a000 (XEN) f10 : 0fffe9690 f11 : 1003e (XEN) r1 : f4326f00 r2 : 435b r3 : f040fdad7781 (XEN) r8 : r9 : r10 : (XEN) r11 : 005a0969 r12 : f7c67900 r13 : f7c6 (XEN) r14 : 4000 r15 : f412ff2a r16 : 4001 (XEN) r17 : f41294fc r18 : 035b r19 : f41294f8 (XEN) r20 : f7c67860 r21 : f7c60010 r22 : 0080 (XEN) r23 : 0002003c r24 : f7c67e20 r25 : f7c67e28 (XEN) r26 : r27 : r28 : (XEN) r29 : 0001 r30 : r31 : f4133db8 (XEN) (XEN) Call Trace: (XEN) [f40a0330] show_stack+0x80/0xa0 (XEN) sp=f7c67520 bsp=f7c612c0 (XEN) [f407abc0] die_if_kernel+0x90/0xe0 (XEN) sp=f7c676f0 bsp=f7c61290 (XEN) [f406f330] ia64_handle_break+0x220/0x2d0 (XEN) sp=f7c676f0 bsp=f7c61258 (XEN) [f409d220] ia64_leave_kernel+0x0/0x310 (XEN) sp=f7c67700 bsp=f7c61258 (XEN) [f4048e50] __bug+0x40/0x60 (XEN) sp=f7c67900 bsp=f7c61218 (XEN) [f4063f10] lookup_noalloc_domain_pte+0x40/0x130 (XEN) sp=f7c67900 bsp=f7c611e8 (XEN) [f4065d40] lookup_domain_mpa+0x30/0x250 (XEN) sp=f7c67900 bsp=f7c611b8 (XEN) [f40664f0] gmfn_to_mfn_foreign+0xc0/0xf0 (XEN) sp=f7c67900 bsp=f7c61190 (XEN) [f4026910] __acquire_grant_for_copy+0x3a0/0x490 (XEN) sp=f7c67900 bsp=f7c61140 (XEN) [f4029870] do_grant_table_op+0x1f80/0x2c20 (XEN) sp=f7c67900 bsp=f7c61038 (XEN) [f402f060] do_multicall+0x2b0/0x390 (XEN) sp=f7c67960 bsp=f7c60fa0 (XEN) [f405ec40] ia64_hypercall+0x990/0x1020 (XEN) sp=f7c67960 bsp=f7c60f40 (XEN) [f406f260] ia64_handle_break+0x150/0x2d0 (XEN) sp=f7c67df0 bsp=f7c60f08 (XEN) [f409d220] ia64_leave_kernel+0x0/0x310 (XEN) sp=f7c67e00 bsp=f7c60f08 (XEN) domain_crash_sync called from xenmisc.c:108 (XEN) Domain 0 (vcpu#0) crashed on cpu#0: (XEN) d 0xf7c88080 domid 0 (XEN) vcpu
Re: [Xen-ia64-devel] crash on xen-ia64-unstable 11810:fcd746cf4647
Hi, Alex Yes, you're right. Best Regards, Akio Takebe On Wed, 2006-10-18 at 07:07 +0900, Akio Takebe wrote: Hi, Aron and Alex It may be so, we need to add the patch into patches/ directory. I had thought xen-ia64-unstable was not needed because it was linux kernel problem. Alex, do you also think necessry? I can post the new patch. Hi Akio, I've heard of several people hitting this problem now, so I'd be willing to take a backport of the upstream linux-ia64 patch. I assume we just need the ia64/kernel/Makefile and ia64/kernel/gate.lds.S changes from this patch, right? http://www.kernel.org/hg/linux-2.6/?cs=dfbee33b0693 Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] BUG at mm.c:605
Hi,
You (yamahata) said:
I think the issue is same as reported in the below thread.
http://lists.xensource.com/archives/html/xen-ia64-devel/2006-09/msg00204.html
I tried to convince him, but failed.
I think that the best way is to revert the patch and we should seek
for the right fix.
I agree with Isaku's opinion. I think that the patch was preliminary
to avoid crash hypervisor.
I guess that making xennet.rx_copy default enabled is the beginning.
The root cause is that relinquish_memory() writes the P2M simulteniously
with __acquire_grant_for_copy().
I think so.
relinquish_memory() of IA64 assumes that no one else read the P2M
table at the same time. However the such assumption is wrong now.
In my investigation, it was right the assumption before shadow2 on
x86. But shadow2 changed it. In shadow2 code, the P2M table destruction
was moved from domain_kill phase to domain_destroy() phase. I guess
that the spec change is for VNIF copy receiver indeed.
Although I haven't dug into its details, I suspect that
the race between relinquish_memory() and get_page()
(or __acquire_grant_for_copy()) exists not only on ia64,
but also on x86.
Before shadow2 age, the P2M table can be destructed in
domain_relinquish_resource(), because gnttab_release_mapping() releases
P2M table referencing concerned with grant table.
203 void domain_kill(struct domain *d)
204 {
205 domain_pause(d);
206
207 if ( test_and_set_bit(_DOMF_dying, d-domain_flags) )
208 return;
209
210 gnttab_release_mappings(d);
211 domain_relinquish_resources(d);
212 put_domain(d);
213
214 send_guest_global_virq(dom0, VIRQ_DOM_EXC);
215 }
But after the copy receiver of VNIF intruduction,
gnttab_release_mapping() became not to be able to release to reference
P2M table. Thus, shadow2 introduced `delayed destruction of P2M table',
I think.
I'm afraid that P2M table may be available after the page body
releasing in shadow2. But I've not spend to investigate this issue.
Thanks
- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [PATCH] remove dom0_align (was Re: [Xen-ia64-devel] [PATCH] fix dom0 builder)
On Mon, 2006-10-16 at 11:06 +0900, Isaku Yamahata wrote: remove dom0_align Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] tlbflush_clock
On Mon, 2006-10-16 at 16:00 +0900, Isaku Yamahata wrote: tlbflush_clock This patch introduces xen compile time option, xen_ia64_tlbflush_clock=y. Applied. This one and your other micro-optimization together reduced my domU parallel kernel build by several seconds! Nice work! Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] micro optimize __domain_flush_vtlb_track_entry
On Mon, 2006-10-16 at 16:01 +0900, Isaku Yamahata wrote: micro optimize __domain_flush_vtlb_track_entry. try to use local purge instead of global purge when possible. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Xen panics when domvti is destroyed
On Mon, 2006-10-16 at 21:00 +0900, Kouya SHIMURA wrote: Hi Alex, Could you apply an attached patch? There is no difference between Anthony's patch and my old one because all vcpus are stopped completely. Ok, applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Please try PV-on-HVM on IPF
On Mon, 2006-10-16 at 21:31 +0900, DOI Tsunehisa wrote: And I attach several patches about PV-on-HVM. + fix-warning.patch - warning fix for HVM PV driver + notsafe-comment.patch - add not-SMP-safe comment about PV-on-HVM - to take Isaku's suggestion. I applied the two above. I assume the one below is not meant for upstream/not ready. Thanks, Alex + pv-backport.patch (preliminary) - current HVM PV driver for only 2.6.16 or 2.6.16.* kernel - this is preliminary patch for backporting to before 2.6.16 kernel - we tested only compiling on RHEL4. -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [patch] deopfuscate vcpu.c and priop.c and related headers
On Mon, 2006-10-16 at 14:41 +0200, Jes Sorensen wrote: In the end I decided to bite the bullet and clean it up so the next person doesn't have to suffer the same way :) Anyway, this patch Lindent's vcpu.c and privop.c, cleans up related header files and also eliminates the redundant UINT64/UINT typedefs which we really don't need. Applied. Thanks for taking the time to do this, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] BUG at mm.c:605
On Wed, 2006-10-18 at 12:59 +0900, [EMAIL PROTECTED] wrote: Hi, You (yamahata) said: I think the issue is same as reported in the below thread. http://lists.xensource.com/archives/html/xen-ia64-devel/2006-09/msg00204.html I tried to convince him, but failed. I think that the best way is to revert the patch and we should seek for the right fix. I agree with Isaku's opinion. I think that the patch was preliminary to avoid crash hypervisor. Ok, should I simply revert xen-ia64-unstable cset 11636:3470d9cd27e5? I guess that making xennet.rx_copy default enabled is the beginning. The root cause is that relinquish_memory() writes the P2M simulteniously with __acquire_grant_for_copy(). I think so. I was using xennet.rx_copy on my domU. I have not seen this BUG when I use the page flipping interface for the domU network. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
