I''m having a problem with getting Xen up and running. My root partition is on a RAID array connected to a 3ware board. I''ve run 2.4.22 through 2.6.18 kernel builds with my root on this same board with no problem. However, when trying to boot into Xen (as dom0), I get the following error at boot time: 3w-xxxx: Failed to get io address. The module is loaded, but my card never gets recognized and no drives show up. As a result, the boot fails. I''ve tried using the Debian-built Xen kernels for 2.6.17 and 2.6.18 for both amd64 and i686 with no luck. I tried downloading the 3.0.3 and 3.0.4 tarballs (64-bit) from xensource and had the exact same problem at bootup. I''ve tried building 3.0.3 from source, and still the same problem. I found an old (2004) post on xen-devel regarding some 3ware card problems which mentioned some different boot options to try: ignorebiostables, noacpi, nosmp, acpi=off, pci=noacpi I''ve tried them all with no luck. I really don''t know what else to check or where else to look. Any suggestions would be greatly appreciated. -- Alex Malinovich Support Free Software, delete your Windows partition TODAY! Encrypted mail preferred. You can get my public key from any of the pgp.net keyservers. Key ID: A6D24837 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13/3/07 07:37, "Alex Malinovich" <demonbane@the-love-shack.net> wrote:> However, when trying to boot into Xen (as dom0), I get the following > error at boot time: > > 3w-xxxx: Failed to get io address.Can you boot off a different disc and then send dmesg boot output, and result of ''lspci -vvv''? The same outputs from a native boot would also be useful for comparison. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 2007-03-13 at 09:38 +0000, Keir Fraser wrote:> On 13/3/07 07:37, "Alex Malinovich" <demonbane@the-love-shack.net> wrote: > > > However, when trying to boot into Xen (as dom0), I get the following > > error at boot time: > > > > 3w-xxxx: Failed to get io address. > > Can you boot off a different disc and then send dmesg boot output, and > result of ''lspci -vvv''? The same outputs from a native boot would also be > useful for comparison.Attached are the dmesg and lspci -vvv outputs from two different boots. The first is my native AMD64 system booting to the RAID root partition using kernel 2.6.18. (files: dmesg-amd64-native and lspci-amd64-native) The second is the same machine booting to a different partition on a stand-alone SATA drive. Unfortunately, that particular install is i386 and not AMD64, though it is still kernel 2.6.18. (files: lspci-i386-xen and dmesg-i386-xen) I can confirm that when booting to the AMD64 Xen kernel I get the same errors that you see on the i386 boot log, I just can''t save them since I have no disk to boot to. As part of the dmesg output on this kernel, you''ll see at the bottom of the output what happens when I try to modprobe -r the 3w-xxxx module from the running kernel. Incidentally, this also means that every time I boot into a kernel having that module problem, I have to use Alt+SysRq+B to reboot the system, as everything else fails while unloading modules (and so never completes the shutdown process). If you need any more info please let me know. -- Alex Malinovich Support Free Software, delete your Windows partition TODAY! Encrypted mail preferred. You can get my public key from any of the pgp.net keyservers. Key ID: A6D24837 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13/3/07 10:59, "Alex Malinovich" <demonbane@the-love-shack.net> wrote:> Attached are the dmesg and lspci -vvv outputs from two different boots. > The first is my native AMD64 system booting to the RAID root partition > using kernel 2.6.18. (files: dmesg-amd64-native and lspci-amd64-native)The problem is that the Xen kernel is failing to reserve any I/O-memory or I/O-port resources for your RAID card. It''s not clear why this is (although I observe that there are various scary looking warnings relating to the PCI config space even in the native dmesg output; and the warnings are rather more numerous in the Xen dmesg output). However, the ''lspci'' from both Xen and native show the same bridge configuration, so I would have expected the Xen kernel to pick resources from the bridge''s supported range just fine. If you are happy making small kernel modifications and building your own kernels, we could narrow this down some more by adding some extra printk() messages into the kernel''s PCI subsystem. In particular, it is calls to pci_assign_resources() that are failing. This function in turn makes use of pci_bus_alloc_resource(), and calls to that function are failing. We can add printk() tracing to find out why the invocations are failing when running on Xen but succeeding when runnign natively. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>Attached are the dmesg and lspci -vvv outputs from two different boots. >The first is my native AMD64 system booting to the RAID root partition >using kernel 2.6.18. (files: dmesg-amd64-native and lspci-amd64-native)These show that you have more severe problems with your system than not being able to run Xen. The particular problem here is resulting from XenoLinux forcing the scan of all functions of a given device, regardless of whether function 0 declares the device as multi-function. There''s nothing wrong with this, not doing the full scan is merely an optimization the native kernel makes use of. The result is that under Xen the kernel identifies a different bus topology as some of the incorrectly found devices appear to be bridges (native luckily just finds a single device that looks like a bridge, and this doesn''t confuse it too much). (Keir, is this scan-all-functions approach really necessary? Couldn''t this be done this way just on domU-s?) So, your primary goal will be to make native Linux boot without any PCI related error messages, once you have that Xen will pretty certainly also come up fine. This very likely requires firmware and/or hardware updates. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13/3/07 12:36, "Jan Beulich" <jbeulich@novell.com> wrote:> (Keir, is this scan-all-functions approach really necessary? Couldn''t this > be done this way just on domU-s?)It may have been needed once upon a time when some PCI stuff resided inside Xen. Now that dom0 does the whole lot, we could probably avoid scan-all-functions, at least for domain0 (since I''m not sure about its interaction with pcifront, but I expect devices exported via pcifront get probed in a different way anyway and aren''t scanned for at all). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13/3/07 13:20, "Keir Fraser" <keir@xensource.com> wrote:> It may have been needed once upon a time when some PCI stuff resided inside > Xen. Now that dom0 does the whole lot, we could probably avoid > scan-all-functions, at least for domain0 (since I''m not sure about its > interaction with pcifront, but I expect devices exported via pcifront get > probed in a different way anyway and aren''t scanned for at all).Ah yes, Xen used to hide bridges so the usual scan-all that happened if slot 0 was multifunction didn''t always work. We don''t need that hack in Xenolinux any more so I''ll remove it. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel