Hello Ian,
My domU config file:
# cat /cluster/xen/xps-106.cfg
kernel = '/cluster/kernels/vmlinuz-2.6.37-trunk-686-bigmem'
ramdisk = '/cluster/kernels/initrd.img-2.6.37-trunk-686-bigmem'
builder = 'linux'
memory = '398'
vcpus = '1'
cpus = '2'
localtime = 0
serial = 'pty'
boot = 'cdn'
disk = [ 'drbd:xps-106,xvda,w' ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
extra = "root=/dev/mapper/xps--106-root ro iommu=soft swiotlb=force
console=hvc0 xencons=tty"
pci = [ '04:00.0' ]
name = 'xps-106'
hostname = 'xps-106.clichy.jbfavre.org'
Le 02/02/2011 10:27, Ian Campbell a écrit :
> On Tue, 2011-02-01 at 22:04 +0000, Jean Baptiste Favre wrote:
> > Le 01/02/2011 17:23, Ian Campbell a écrit :
>
> >> I assume you are not seeing "rx mapping error" in your domU dmesg? Did
> >> you post a full guest console log at some point? Comparing the logs for
> >> the 256MB, 398MB and 512MB guest RAM case might be useful.
> > No sure I've ever posted that logs. But I can redo my tests :)
>
> yes, please do that.
Please find attached both console startup logs with 256M and 512M:
256M_domU_console_logs.txt
512M_domU_console_logs.txt
For 512M, I saw some kernel CallTrace I can not explain. There are not
present with 256M.
For 398M memory, I can't even start domU :
# xm create /cluster/xen/xps-106.cfg -c
Using config file "/cluster/xen/xps-106.cfg".
[215739.007871] pciback 0000:04:00.0: device has been assigned to
another domain! Over-writting the ownership, but beware.
Started domain xps-106 (id=23)
(XEN) mm.c:798:d23 Non-privileged (23) attempt to map I/O space 00000000
(XEN) mm.c:4644:d23 ptwr_emulate: could not get_page_from_l1e()
As I told you, I'm still using Debian 2.6.37 kernel because I've some
problem to compile 2.6.32.27 from Jeremy's git repository.
I hope I can get it compiled today so I'll be able to test with that
kernel as well.
>
> Please can you also collect and post the information from ifconfig and
> ethtool -S which I asked for earlier.
Attached as well:
256_domU_ifconfig_ping_ethtool.txt
512_domU_ifconfig_ping_ethtool.txt
> Can you confirm that on the domU tcpdump shows no incoming frames at
> all, including no corrupted or strange frames. It has been suggested
> that the frames could be being received ok but contain garbage (e.g. due
> to swiotlb not syncing the memory properly) and hence are not ICMP
> Responses but appear as some random frame type.
>
> Please can you use "tcpdump -w" on both the gateway/peer side and the
> affected domU to capture a short session while the failing ping is
> running and post (or link to if large) the resulting pcap files. On the
> peer side you can use "ether host <domU-MAC>" (plus optionally "or ether
> broadcast") on the tcpdump command line to limit the capture to just the
> one peer and reduce the size of the capture.
I'll update you as soon as I have tcpdump captures ready.
Regards,
JB
512M_domU_ifconfig_ping_ethtool.txt
Description: Text document
256M_domU_console_logs.txt
Description: Text document
256M_domU_ifconfig_ping_ethtool.txt
Description: Text document
512M_domU_console_logs.txt
Description: Text document
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home