[Xen-ia64-devel] Re: blkbk/netbk modules fail to load on fedora xen/ia64
Hi, Aron and all netbk/xennet modules fail to load by using xen-ia64-unstable again. This issue is caused by the following patches. http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?cs=c757ebffd500 We can probably resolve this issue. 1. Tristan's xencomm patches is applied. (I test by using xen-ia64-unstable, but these patches have some issue.) 2. revert the below patch. (I have not test yet.) 3. built in these modules. (I have not test yet.) I think the best way is 1. But Tristan's patches still have some issues. What do you think about this? Best Regards, Akio Takebe Akio Takebe wrote: [Thu Sep 21 2006, 09:53:16PM EDT] I can solve this problem by using dom0_mem=1G. This allows blkbk/netbk to load, but I guess a domU won't install yet. xenguest-install fails with a panic in dom0. I used this command: xenguest-install -n domu -r 1024 -f /root/domu.img \ -l http://hummer.zko.hp.com/fedora/linux/core/development/ia64/os/ \ -s 4 --nographics -p -x 'ide0=noprobe ide1=noprobe ide2=noprobe ide3= noprobe' Here is the output on the dom0 console: (XEN) ### domain f7bb4080: rid=8-c mp_rid=2000 (XEN) arch_domain_create: domain=f7bb4080 (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- 0x3fff4000) (1023MB) (XEN) dom mem: type=12, attr=0x0001, range=[0x0c00- 0x1000) (64MB) audit(1158891786.948:4): dev=vif1.0 prom=256 old_prom=0 auid=4294967295 kernel unaligned access to 0xa002009e405f, ip=0xa00100295e91 kernel unaligned access to 0xa002009e4067, ip=0xa00100295e91 kernel unaligned access to 0xa002009e406f, ip=0xa00100295e91 kernel unaligned access to 0xa002009e4077, ip=0xa00100295e91 kernel unaligned access to 0xa002009e407f, ip=0xa00100295e91 (XEN) vcpu_get_lrr0: Unmasked interrupts unsupported (XEN) vcpu_get_lrr1: Unmasked interrupts unsupported (XEN) Linux version 2.6.18-1.2679.fc6xen ([EMAIL PROTECTED] com) (gcc version 4.1.1 20060917 (Red Hat 4.1.1-23)) #1 SMP Wed Sep 20 01: 18:10 EDT 2006 EFI v1.00 by Xen/ia64: SALsystab=0x2178 ACPI 2.0=0x1000 rsvd_region[0]: [0xe0002228, 0xe00022f0) rsvd_region[1]: [0xe0003000, 0xe0003030) rsvd_region[2]: [0xe400, 0xe4c2899b) rsvd_region[3]: [0xe4c2c000, 0xe597ac00) rsvd_region[4]: [0xe0003fff4000, 0xe0003fff8000) rsvd_region[5]: [0x, 0x) Initial ramdisk at: 0xe4c2c000 (13954048 bytes) 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=0xfffd nr_pages=65536 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. Total pages: 61440 Kernel command line: method=http://hummer.zko.hp.com/fedora/linux/core/ development/ia64/os/ ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe ide_setup: ide0=noprobe ide_setup: ide1=noprobe ide_setup: ide2=noprobe ide_setup: ide3=noprobe PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour dummy device 80x25 (file=grant_table.c, line=704) gnttab_transfer: error writing resp 0/1 kernel BUG at drivers/xen/netback/netback.c:631! swapper[0]: bugcheck! 0 [1] Modules linked in: loop xt_physdev bridge netloop netbk blkbk autofs4 hidp rfcomm l2cap bluetooth sunrpc ip_conntrack_netbios_ns ipt_REJECT iptable_filter ip_tables xt_state ip_conntrack nfnetlink xt_tcpudp ip6table_filter ip6_tables x_tables ipv6 vfat fat dm_multipath button parport_pc lp parport ide_cd sg e1000 cdrom dm_snapshot dm_zero dm_mirror dm_mod mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd Pid: 0, CPU 0, comm: swapper psr : 001008026010 ifs : 8694 ip : [a00200c80590] Not tainted ip is at net_rx_action+0x990/0x17a0 [netbk] unat: pfs : 8694 rsc : 0008 rnat: bsps: pr : 00019665 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a00200c80590 b6 : a001000b80c0 b7 :
[Xen-ia64-devel] Re: blkbk/netbk modules fail to load on fedora xen/ia64
Akio Takebe wrote: [Thu Sep 28 2006, 02:44:54AM EDT] Hi, Aron and all netbk/xennet modules fail to load by using xen-ia64-unstable again. This issue is caused by the following patches. http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?cs=c757ebffd500 I guess it's no surprise this would continue to break... :-| We can probably resolve this issue. 1. Tristan's xencomm patches is applied. (I test by using xen-ia64-unstable, but these patches have some issue.) What issues are you seeing? They seem to be working well for me, but I haven't tried on Fedora's kernel yet, which is my next goal. 2. revert the below patch. (I have not test yet.) 3. built in these modules. (I have not test yet.) I think the best way is 1. But Tristan's patches still have some issues. What do you think about this? I agree with you. If possible, let's fix the issues in xencomm and get them added to Fedora. Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Re: blkbk/netbk modules fail to load on fedora xen/ia64
Aron Griffis wrote: [Thu Sep 28 2006, 10:31:41AM EDT] What issues are you seeing? They seem to be working well for me, but I haven't tried on Fedora's kernel yet, which is my next goal. Nevermind this question... I just caught up on xen-ia64-devel emails, so I hadn't seen your report to Tristan. I see it now, and also Tristan's updated patch, so I'll test that on Fedora. Regards, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: blkbk/netbk modules fail to load on fedora xen/ia64
Hi, Aron and all We may have to change dom0_mem of FC6 default to 1GB. But I think the best fix is (1) statically link the modules. (Because all kernel-xen need blkbk/netbk and xenblk/net. ide module is also static link. And because xen community member test the statically linked modules, I think the statically linked modules is stabler than the dynamic linked modlues.) I don't mind asking RH to statically link the modules if there is good reason. However I don't understand why it is needed. 512M is a lot of memory! How can it be filled to the extent that the blkbk/netbk modules won't load? What are their requirements? Please see the following error message. FATAL: Error inserting blkbk (/lib/modules/2.6.17-1.2566.fc6xen/kernel/drivers/xen/ blkback/blkbk.ko): Cannot allocate memory modprobe: page allocation failure. order:8, mode:0xd0 blkbk.ko request order8 pages in blkif_init(). order8 pages is very big. page_alloc() probably fail when it is requested order8 pages, because page_alloc() must return contiguos pages. Especially after boot and terminate some processes, page_alloc() is hard to allocate order8 pages. So when dom0_mem=1G, page_allo() is easier to allocate them than dom0_mem=512M. And when statically linked modules, page_alloc() is the easest to allocate them. I think implementation of blk/netbk.ko is not good. But I think statically linked modules is the best solution in your solutions. And I think this issue is happened in the case of not only ia64, but also x86. (In the case of x86, default size of dom0_mem is physcal memory size. So this issue is hard to be happened.) Please commets. FYI https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202971 Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: blkbk/netbk modules fail to load on fedora xen/ia64
Hi, Aron and all I can solve this problem by using dom0_mem=1G. FC6 test3 uses many daemons and services. Because booting xend is late, we fail insmod blk/netbk if dom0_mem=512M(default size). We may have to change dom0_mem of FC6 default to 1GB. But I think the best fix is (1) statically link the modules. (Because all kernel-xen need blkbk/netbk and xenblk/net. ide module is also static link. And because xen community member test the statically linked modules, I think the statically linked modules is stabler than the dynamic linked modlues.) Please give me some comments. Best Regards, Akio Takebe Presently the showstopper bug in Fedora Xen/ia64 is the failure of the blkbk/netbk modules to load. Akio Takebe and Kouya Shimura worked on a patch to fix this earlier (changeset bef360142b62), unfortunately it doesn't seem to have fixed the problem on the Fedora kernel. I filed the bug at RH: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202971 In that report, I suggest three options: (1) statically link the modules, (2) wait for xen-ia64-devel to finish xencomm, (3) debug the issue preventing the current drivers from loading. Regarding #1, I don't think RH will do it. Jeremy Katz has mentioned on the ML that Fedora is depending on the front/back-end drivers being compiled as modules. I'm looking forward to the completion of #2, but I think it would be wise to fix #3 if we can, especially since it might be easier. I have looked at it but I'm out of my depth. Would Kouya, Akio or somebody else mind trying to fix it? Note: I will have sporadic email contact starting tomorrow until Wednesday 9/27, so I may not respond until then. Thanks, Aron ---application/pgp-signature--- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFEzj8JrHF4yAQTrARAuLWAJ4v2e4HFnmyq01n48SC0PKIK3gjyACdGRI+ Wv/7SXoRNtXgssrk42mlfB8= =hoQO -END PGP SIGNATURE- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: blkbk/netbk modules fail to load on fedora xen/ia64
Akio Takebe wrote: [Thu Sep 21 2006, 09:53:16PM EDT] I can solve this problem by using dom0_mem=1G. FC6 test3 uses many daemons and services. Because booting xend is late, we fail insmod blk/netbk if dom0_mem=512M(default size). Wow, thank you! That is a big relief. We may have to change dom0_mem of FC6 default to 1GB. But I think the best fix is (1) statically link the modules. (Because all kernel-xen need blkbk/netbk and xenblk/net. ide module is also static link. And because xen community member test the statically linked modules, I think the statically linked modules is stabler than the dynamic linked modlues.) I don't mind asking RH to statically link the modules if there is good reason. However I don't understand why it is needed. 512M is a lot of memory! How can it be filled to the extent that the blkbk/netbk modules won't load? What are their requirements? It is possible that knowing the dom0_mem=1G workaround will be enough until Tristan's xencomm work is finished (I think he's almost done) Thanks again, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: blkbk/netbk modules fail to load on fedora xen/ia64
Akio Takebe wrote: [Thu Sep 21 2006, 09:53:16PM EDT] I can solve this problem by using dom0_mem=1G. This allows blkbk/netbk to load, but I guess a domU won't install yet. xenguest-install fails with a panic in dom0. I used this command: xenguest-install -n domu -r 1024 -f /root/domu.img \ -l http://hummer.zko.hp.com/fedora/linux/core/development/ia64/os/ \ -s 4 --nographics -p -x 'ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe' Here is the output on the dom0 console: (XEN) ### domain f7bb4080: rid=8-c mp_rid=2000 (XEN) arch_domain_create: domain=f7bb4080 (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-0x3fff4000) (1023MB) (XEN) dom mem: type=12, attr=0x0001, range=[0x0c00-0x1000) (64MB) audit(1158891786.948:4): dev=vif1.0 prom=256 old_prom=0 auid=4294967295 kernel unaligned access to 0xa002009e405f, ip=0xa00100295e91 kernel unaligned access to 0xa002009e4067, ip=0xa00100295e91 kernel unaligned access to 0xa002009e406f, ip=0xa00100295e91 kernel unaligned access to 0xa002009e4077, ip=0xa00100295e91 kernel unaligned access to 0xa002009e407f, ip=0xa00100295e91 (XEN) vcpu_get_lrr0: Unmasked interrupts unsupported (XEN) vcpu_get_lrr1: Unmasked interrupts unsupported (XEN) Linux version 2.6.18-1.2679.fc6xen ([EMAIL PROTECTED]) (gcc version 4.1.1 20060917 (Red Hat 4.1.1-23)) #1 SMP Wed Sep 20 01:18:10 EDT 2006 EFI v1.00 by Xen/ia64: SALsystab=0x2178 ACPI 2.0=0x1000 rsvd_region[0]: [0xe0002228, 0xe00022f0) rsvd_region[1]: [0xe0003000, 0xe0003030) rsvd_region[2]: [0xe400, 0xe4c2899b) rsvd_region[3]: [0xe4c2c000, 0xe597ac00) rsvd_region[4]: [0xe0003fff4000, 0xe0003fff8000) rsvd_region[5]: [0x, 0x) Initial ramdisk at: 0xe4c2c000 (13954048 bytes) 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=0xfffd nr_pages=65536 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. Total pages: 61440 Kernel command line: method=http://hummer.zko.hp.com/fedora/linux/core/development/ia64/os/ ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe ide_setup: ide0=noprobe ide_setup: ide1=noprobe ide_setup: ide2=noprobe ide_setup: ide3=noprobe PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour dummy device 80x25 (file=grant_table.c, line=704) gnttab_transfer: error writing resp 0/1 kernel BUG at drivers/xen/netback/netback.c:631! swapper[0]: bugcheck! 0 [1] Modules linked in: loop xt_physdev bridge netloop netbk blkbk autofs4 hidp rfcomm l2cap bluetooth sunrpc ip_conntrack_netbios_ns ipt_REJECT iptable_filter ip_tables xt_state ip_conntrack nfnetlink xt_tcpudp ip6table_filter ip6_tables x_tables ipv6 vfat fat dm_multipath button parport_pc lp parport ide_cd sg e1000 cdrom dm_snapshot dm_zero dm_mirror dm_mod mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd Pid: 0, CPU 0, comm: swapper psr : 001008026010 ifs : 8694 ip : [a00200c80590]Not tainted ip is at net_rx_action+0x990/0x17a0 [netbk] unat: pfs : 8694 rsc : 0008 rnat: bsps: pr : 00019665 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a00200c80590 b6 : a001000b80c0 b7 : a002007c36c0 f6 : 1003e00a0 f7 : 1003e20c49ba5e353f7cf f8 : 1003e04e2 f9 : 1003e0fa0 f10 : 1003e3b9aca00 f11 : 1003e431bde82d7b634db r1 : a00100bcee60 r2 : a001009e5758 r3 : a001009e59f0 r8 : 0034 r9 : a001009da5e0 r10 : a001009e5788 r11 : a001009e5788 r12 : a00100733b10 r13 : a0010072c000 r14 : a001009e5758 r15 : r16 : f1004c18 r17 : a001009e59f0 r18 : a001008978fc r19 : 0001 r20 : r21 : a001009cf4b0 r22 : r23 :
