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

Re: [Xen-devel] 3w-xxxx module problems with Xen


  • To: Alex Malinovich <demonbane@xxxxxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Tue, 13 Mar 2007 12:13:36 +0000
  • Delivery-date: Tue, 13 Mar 2007 05:13:04 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdlaQaYRUj7SNFcEduMWwAX8io7RQ==
  • Thread-topic: [Xen-devel] 3w-xxxx module problems with Xen



On 13/3/07 10:59, "Alex Malinovich" <demonbane@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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