mmap in PV xen-4.0.1

mmap in PV xen-4.0.1

[Eric Camachat]

[-- Attachment #1: Type: text/plain, Size: 9318 bytes --]

Hi,

I have a problem to map kernel memory to userspace via /dev/mem.
The mmap() succeeded, but when I try to access it, the program will
hang forever (until press ctrl-c to terminate it).

# memtest-user
memtest_vma_open: virt 0x7fbc90085000, phys 0x3eee8000
paddr = 0x3eee8000
 mem = 0x7fbc90089000
 map = 0x7fbc90085000
map[0]= 4c4c4c4c
map[1]= 4c4c4c4c
*** Hang here, it cannot (finish) access the memory mapped via /dev/mem ***

My test source below, and it runs properly on HVM, VirtualBox, QEM and
physical machines.
What mistake I did?

My kernel module look like this:
=================================================================================
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/fs.h>
#include <linux/mm.h>
#include <asm/io.h>
#include <asm/page.h>

#define MEMTEST_MAJOR           886
#define MEMTEST_NAME            "memtest"

#define MEMTEST_MAGIC           'M'
#define MEMTEST_DMA_SIZE        _IO(MEMTEST_MAGIC, 0)
#define MEMTEST_DMA_PADDR       _IO(MEMTEST_MAGIC, 1)
#define MEMTEST_DMA_VADDR       _IO(MEMTEST_MAGIC, 2)

#define SIZE_ORDER              2
static uint32_t _size = (PAGE_SIZE << SIZE_ORDER);
static unsigned long _vbase = 0;
static phys_addr_t _pbase = 0;

static int
memtest_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
              unsigned long arg)
{
       int ret = -ENOIOCTLCMD;
       phys_addr_t *paddr;
       unsigned long *vaddr;
       uint32_t *size;

       switch(cmd) {
       case MEMTEST_DMA_SIZE:
               size = (uint32_t*)arg;
               *size = _size;
               ret = 0;
               break;
       case MEMTEST_DMA_PADDR:
               paddr = (phys_addr_t*)arg;
               *paddr = _pbase;
               ret = 0;
               break;
       case MEMTEST_DMA_VADDR:
               vaddr = (unsigned long*)arg;
               *vaddr = _vbase;
               ret = 0;
               break;
       }
       return ret;
}

static void memtest_vma_open(struct vm_area_struct *vma)
{
       printk("%s: virt %#lx, phys %#lx\n", __func__, vma->vm_start,
vma->vm_pgoff << PAGE_SHIFT);
}
static void memtest_vma_close(struct vm_area_struct *vma)
{
       printk("%s\n", __func__);
}
static struct vm_operations_struct memtest_vm_ops = {
       .open   = memtest_vma_open,
       .close  = memtest_vma_close,
};
static int memtest_mmap(struct file * file, struct vm_area_struct * vma)
{
       /* Remap-pfn-range will mark the range VM_IO and VM_RESERVED */
       if (remap_pfn_range(vma,
                           vma->vm_start,
                           vma->vm_pgoff,
                           vma->vm_end - vma->vm_start,
                           vma->vm_page_prot)) {
               return -EAGAIN;
       }

       vma->vm_ops = &memtest_vm_ops;
       memtest_vma_open(vma);
       return 0;
}

static struct file_operations memtest_fops = {
       .owner          = THIS_MODULE,
       .llseek         = no_llseek,
       .ioctl          = memtest_ioctl,
       .mmap           = memtest_mmap,
};

static int __init memtest_init(void)
{
       int retval;

       printk(MEMTEST_NAME ": registering /dev/" MEMTEST_NAME "
(%d)\n",MEMTEST_MAJOR );
       retval = register_chrdev(MEMTEST_MAJOR, MEMTEST_NAME, &memtest_fops);
       if (retval < 0)
       {
               printk(MEMTEST_NAME ": failed to register /dev/"
MEMTEST_NAME "\n");
       }
       printk(MEMTEST_NAME ": size of phys_addr_t is %lu bytes\n",
sizeof(phys_addr_t));

       //_vbase = get_zeroed_page(GFP_KERNEL);
       _vbase = __get_free_pages(GFP_KERNEL, SIZE_ORDER);
       if (_vbase == 0)
       {
               printk(MEMTEST_NAME ": kmalloc(%d, GFP_KERNEL) failed\n", _size);
       }
       else
       {
               memset((void*)_vbase, 'L', _size);
               ((uint32_t*)_vbase)[0] = 0x1234;
               ((uint32_t*)_vbase)[1] = 0xabcd;
               ((uint32_t*)_vbase)[2] = 0xeeee;
               ((uint32_t*)_vbase)[3] = 0xffff;
               _pbase = virt_to_bus((void*)_vbase);
       }

       printk(MEMTEST_NAME ": _vbase = %#lx\n", _vbase);
       printk(MEMTEST_NAME ": _pbase = %#lx\n", (unsigned long)_pbase);
       return retval;
}

static void __exit memtest_exit(void)
{
       if (_vbase != 0)
               free_page(_vbase);
       unregister_chrdev(MEMTEST_MAJOR, MEMTEST_NAME);
}


MODULE_LICENSE("GPL");

module_init(memtest_init);
module_exit(memtest_exit);
=================================================================================

Here is my user program:

=================================================================================
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <errno.h>
#include <stdint.h>

#define MEMTEST_MAGIC           'M'
#define MEMTEST_DMA_SIZE        _IO(MEMTEST_MAGIC, 0)
#define MEMTEST_DMA_PADDR       _IO(MEMTEST_MAGIC, 1)
#define MEMTEST_DMA_VADDR       _IO(MEMTEST_MAGIC, 2)

#define DEVDIAG                 "/dev/memtest"
#define DEVMEM                  "/dev/mem"
uint32_t get_size(void);
unsigned long get_paddr(void);
unsigned int * mmap_memtest(unsigned long paddr, uint32_t size);
unsigned int * mmap_mem(unsigned long paddr, uint32_t size);

uint32_t get_size(void)
{
       int diagfd, rv;
       uint32_t size;

       diagfd = open( DEVDIAG, O_RDWR | O_SYNC | O_DSYNC | O_RSYNC );
       if (diagfd < 0)
       {
               perror("Error : fail to open" DEVDIAG);
               return 0;
       }

       rv = ioctl( diagfd, MEMTEST_DMA_SIZE, &size);
       if (rv < 0)
       {
               perror("Fail to perform ioctl");
               return 0;
       }
       close(diagfd);

       return size;
}

unsigned long get_paddr(void)
{
       int diagfd, rv;
       unsigned long paddr;

       diagfd = open( DEVDIAG, O_RDWR | O_SYNC | O_DSYNC | O_RSYNC );
       if (diagfd < 0)
       {
               perror("Error : fail to open" DEVDIAG);
               return 0;
       }
       rv = ioctl( diagfd, MEMTEST_DMA_PADDR, &paddr);
       if ( rv < 0 ) {
               perror("Fail to perform ioctl");
               return 0;
       }
       close(diagfd);

       return paddr;
}

unsigned int * mmap_memtest(unsigned long paddr, uint32_t size)
{
       int diagfd;
       unsigned int page_size = getpagesize();
       unsigned int page_mask = ~(page_size - 1);
       unsigned int *vaddr = NULL;

       /** test mmap */
       if ( paddr & ~page_mask ) {
               printf("Error : not algined %#lxx & %08x\n", paddr, ~page_mask );
               return NULL;
       }

       diagfd = open( DEVDIAG, O_RDWR | O_SYNC | O_DSYNC | O_RSYNC );
       if (diagfd < 0)
       {
               printf("Error : fail to open "DEVDIAG);
               return NULL;
       }


       vaddr =  (unsigned int*) mmap(NULL, size, PROT_READ, MAP_SHARED,
diagfd, paddr);
       close(diagfd);

       return vaddr;
}

unsigned int * mmap_mem(unsigned long paddr, uint32_t size)
{
       int memfd;
       unsigned int page_size = getpagesize();
       unsigned int page_mask = ~(page_size - 1);
       unsigned int *vaddr = NULL;

       /** test mmap */
       if ( paddr & ~page_mask ) {
               printf("Error : not algined %#lxx & %08x\n", paddr, ~page_mask );
               return NULL;
       }

       memfd = open(DEVMEM, O_RDWR |  O_SYNC | O_DSYNC | O_RSYNC);
       if (memfd < 0)
       {
               perror("Error : fail to open "DEVMEM);
               return NULL;
       }

       vaddr =  (unsigned int*) mmap(NULL, size, PROT_READ,
MAP_SHARED, memfd, paddr);
       close(memfd);

       return vaddr;
}

int main(int argc, char **argv)
{
       uint32_t size = get_size();
       unsigned long paddr = get_paddr();
       unsigned int *mem = mmap_mem(paddr, size);
       unsigned int *map = mmap_memtest(paddr, size);

       printf("paddr = %#lx\n", paddr);
       printf("  mem = %p\n", mem);
       printf("  map = %p\n", map);

       if (map)
       {
               printf("map[0]= %x\n", map[0]);
               printf("map[1]= %x\n", map[1]);
       }

       if (mem)
       {
               printf("mem[0]= %x\n", mem[0]);
               printf("mem[1]= %x\n", mem[1]);
       }

         return 0;
}
=================================================================================

[-- Attachment #2: memtest-module.c --]
[-- Type: text/x-csrc, Size: 3131 bytes --]


#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/fs.h>
#include <linux/mm.h>
#include <asm/io.h>
#include <asm/page.h>

#define MEMTEST_MAJOR		886
#define MEMTEST_NAME		"memtest"

#define MEMTEST_MAGIC		'M'
#define MEMTEST_DMA_SIZE	_IO(MEMTEST_MAGIC, 0)
#define MEMTEST_DMA_PADDR	_IO(MEMTEST_MAGIC, 1)
#define MEMTEST_DMA_VADDR	_IO(MEMTEST_MAGIC, 2)

#define SIZE_ORDER		2
static uint32_t _size = (PAGE_SIZE << SIZE_ORDER);
static unsigned long _vbase = 0;
static phys_addr_t _pbase = 0;

static int
memtest_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
	       unsigned long arg)
{
	int ret = -ENOIOCTLCMD;
	phys_addr_t *paddr;
	unsigned long *vaddr;
	uint32_t *size;

	switch(cmd) {
	case MEMTEST_DMA_SIZE:
		size = (uint32_t*)arg;
		*size = _size;
		ret = 0;
		break;
	case MEMTEST_DMA_PADDR:
		paddr = (phys_addr_t*)arg;
		*paddr = _pbase;
		ret = 0;
		break;
	case MEMTEST_DMA_VADDR:
		vaddr = (unsigned long*)arg;
		*vaddr = _vbase;
		ret = 0;
		break;
	}
	return ret;
}

static void memtest_vma_open(struct vm_area_struct *vma)
{
	printk("%s: virt %#lx, phys %#lx\n", __func__, vma->vm_start, vma->vm_pgoff << PAGE_SHIFT);
}
static void memtest_vma_close(struct vm_area_struct *vma)
{
	printk("%s\n", __func__);
}
static struct vm_operations_struct memtest_vm_ops = {
	.open	= memtest_vma_open,
	.close	= memtest_vma_close,
};
static int memtest_mmap(struct file * file, struct vm_area_struct * vma)
{
	/* Remap-pfn-range will mark the range VM_IO and VM_RESERVED */
	if (remap_pfn_range(vma,
			    vma->vm_start,
			    vma->vm_pgoff,
			    vma->vm_end - vma->vm_start,
			    vma->vm_page_prot)) {
		return -EAGAIN;
	}

	vma->vm_ops = &memtest_vm_ops;
	memtest_vma_open(vma);
	return 0;
}

static struct file_operations memtest_fops = {
	.owner		= THIS_MODULE,
	.llseek		= no_llseek,
	.ioctl		= memtest_ioctl,
	.mmap		= memtest_mmap,
};

static int __init memtest_init(void)
{
	int retval;

        printk(MEMTEST_NAME ": registering /dev/" MEMTEST_NAME " (%d)\n",MEMTEST_MAJOR );
	retval = register_chrdev(MEMTEST_MAJOR, MEMTEST_NAME, &memtest_fops);
	if (retval < 0)
	{
		printk(MEMTEST_NAME ": failed to register /dev/" MEMTEST_NAME "\n");
	}
        printk(MEMTEST_NAME ": size of phys_addr_t is %lu bytes\n", sizeof(phys_addr_t));

	//_vbase = get_zeroed_page(GFP_KERNEL);
	_vbase = __get_free_pages(GFP_KERNEL, SIZE_ORDER);
	if (_vbase == 0)
	{
	        printk(MEMTEST_NAME ": kmalloc(%d, GFP_KERNEL) failed\n", _size);
	}
	else
	{
		memset((void*)_vbase, 'L', _size);
		((uint32_t*)_vbase)[0] = 0x1234;
		((uint32_t*)_vbase)[1] = 0xabcd;
		((uint32_t*)_vbase)[2] = 0xeeee;
		((uint32_t*)_vbase)[3] = 0xffff;
		_pbase = virt_to_bus((void*)_vbase);
	}

        printk(MEMTEST_NAME ": _vbase = %#lx\n", _vbase);
        printk(MEMTEST_NAME ": _pbase = %#lx\n", (unsigned long)_pbase);
        return retval;
}

static void __exit memtest_exit(void)
{
	if (_vbase != 0)
		free_page(_vbase);
	unregister_chrdev(MEMTEST_MAJOR, MEMTEST_NAME);
}


MODULE_LICENSE("GPL");

module_init(memtest_init);
module_exit(memtest_exit);


[-- Attachment #3: memtest-user.c --]
[-- Type: text/x-csrc, Size: 2993 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <errno.h>
#include <stdint.h>

#define MEMTEST_MAGIC		'M'
#define MEMTEST_DMA_SIZE	_IO(MEMTEST_MAGIC, 0)
#define MEMTEST_DMA_PADDR	_IO(MEMTEST_MAGIC, 1)
#define MEMTEST_DMA_VADDR	_IO(MEMTEST_MAGIC, 2)

#define DEVDIAG			"/dev/memtest"
#define DEVMEM			"/dev/mem"
uint32_t get_size(void);
unsigned long get_paddr(void);
unsigned int * mmap_memtest(unsigned long paddr, uint32_t size);
unsigned int * mmap_mem(unsigned long paddr, uint32_t size);

uint32_t get_size(void)
{
	int diagfd, rv;
	uint32_t size;

	diagfd = open( DEVDIAG, O_RDWR | O_SYNC | O_DSYNC | O_RSYNC );
	if (diagfd < 0)
	{
		perror("Error : fail to open" DEVDIAG);
    		return 0;
  	}

	rv = ioctl( diagfd, MEMTEST_DMA_SIZE, &size);
    	if (rv < 0)
	{
	      	perror("Fail to perform ioctl");
      		return 0;
    	}
	close(diagfd);

	return size;
}

unsigned long get_paddr(void)
{
	int diagfd, rv;
	unsigned long paddr;

	diagfd = open( DEVDIAG, O_RDWR | O_SYNC | O_DSYNC | O_RSYNC );
	if (diagfd < 0)
	{
		perror("Error : fail to open" DEVDIAG);
    		return 0;
  	}
	rv = ioctl( diagfd, MEMTEST_DMA_PADDR, &paddr);
    	if ( rv < 0 ) {
	      	perror("Fail to perform ioctl");
      		return 0;
    	}
	close(diagfd);

	return paddr;
}

unsigned int * mmap_memtest(unsigned long paddr, uint32_t size)
{
	int diagfd;
	unsigned int page_size = getpagesize();
	unsigned int page_mask = ~(page_size - 1);
	unsigned int *vaddr = NULL;

	/** test mmap */
	if ( paddr & ~page_mask ) {
		printf("Error : not algined %#lxx & %08x\n", paddr, ~page_mask );
		return NULL;
	}

	diagfd = open( DEVDIAG, O_RDWR | O_SYNC | O_DSYNC | O_RSYNC );
	if (diagfd < 0)
	{
		printf("Error : fail to open "DEVDIAG);
    		return NULL;
  	}


	vaddr =  (unsigned int*) mmap(NULL, size, PROT_READ, MAP_SHARED, diagfd, paddr);
	close(diagfd);

	return vaddr;
}

unsigned int * mmap_mem(unsigned long paddr, uint32_t size)
{
	int memfd;
	unsigned int page_size = getpagesize();
	unsigned int page_mask = ~(page_size - 1);
	unsigned int *vaddr = NULL;

	/** test mmap */
	if ( paddr & ~page_mask ) {
		printf("Error : not algined %#lxx & %08x\n", paddr, ~page_mask );
		return NULL;
	}

	memfd = open(DEVMEM, O_RDWR |  O_SYNC | O_DSYNC | O_RSYNC);
	if (memfd < 0)
	{
		perror("Error : fail to open "DEVMEM);
		return NULL;
	}

	vaddr =  (unsigned int*) mmap(NULL, size, PROT_READ, MAP_SHARED, memfd, paddr);
	close(memfd);

	return vaddr;
}

int main(int argc, char **argv)
{
	uint32_t size = get_size();
	unsigned long paddr = get_paddr();
	unsigned int *mem = mmap_mem(paddr, size);
	unsigned int *map = mmap_memtest(paddr, size);

  	printf("paddr = %#lx\n", paddr);
	printf("  mem = %p\n", mem);
	printf("  map = %p\n", map);

	if (map)
	{
		printf("map[0]= %x\n", map[0]);
		printf("map[1]= %x\n", map[1]);
	}

	if (mem)
	{
		printf("mem[0]= %x\n", mem[0]);
		printf("mem[1]= %x\n", mem[1]);
	}

	  return 0;
}


[-- Attachment #4: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: mmap in PV xen-4.0.1

[Wei Liu]

On Tue, Aug 09, 2011 at 11:29:51PM -0700, Eric Camachat wrote:
> Hi,
> 
> I have a problem to map kernel memory to userspace via /dev/mem.
> The mmap() succeeded, but when I try to access it, the program will
> hang forever (until press ctrl-c to terminate it).
> 
> # memtest-user
> memtest_vma_open: virt 0x7fbc90085000, phys 0x3eee8000
> paddr = 0x3eee8000
>  mem = 0x7fbc90089000
>  map = 0x7fbc90085000
> map[0]= 4c4c4c4c
> map[1]= 4c4c4c4c
> *** Hang here, it cannot (finish) access the memory mapped via /dev/mem ***
> 
> My test source below, and it runs properly on HVM, VirtualBox, QEM and
> physical machines.
> What mistake I did?
> 
> My kernel module look like this:
> =================================================================================

[...snip...]

> memtest_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
>               unsigned long arg)
> {
>        int ret = -ENOIOCTLCMD;
>        phys_addr_t *paddr;
>        unsigned long *vaddr;
>        uint32_t *size;
> 
>        switch(cmd) {
>        case MEMTEST_DMA_SIZE:
>                size = (uint32_t*)arg;
>                *size = _size;

Though your output shows that this assignment works, shouldn't this
kind of direct assignment across kernel space and user land be
avoided? It is bad practice to do direct assignment I think.

copy_{from,to}_user should do the job.

>                ret = 0;
>                break;
>        case MEMTEST_DMA_PADDR:
>                paddr = (phys_addr_t*)arg;
>                *paddr = _pbase;
>                ret = 0;
>                break;
>        case MEMTEST_DMA_VADDR:
>                vaddr = (unsigned long*)arg;
>                *vaddr = _vbase;
>                ret = 0;
>                break;
>        }
>        return ret;
> }
> 
>

[...snip...]
 
> static struct file_operations memtest_fops = {
>        .owner          = THIS_MODULE,
>        .llseek         = no_llseek,
>        .ioctl          = memtest_ioctl,

My kernel doesn't have field called 'ioctl' in file_operations.

So which kernel do you use? 2.6.18? I don't have old kernel at the
moment so I can't help you much...

>        .mmap           = memtest_mmap,
> };
> 
>

[...snip...]
 
> static void __exit memtest_exit(void)
> {
>        if (_vbase != 0)
>                free_page(_vbase);

I suppose you should use free_pages here, since you use
__get_free_pages when allocating.

>        unregister_chrdev(MEMTEST_MAJOR, MEMTEST_NAME);
> }
> 
> 
> MODULE_LICENSE("GPL");
> 
> module_init(memtest_init);
> module_exit(memtest_exit);
> =================================================================================
> 
> Here is my user program:
> 
> =================================================================================
>

[...snip...]
 
> 	if (map)
> 	{
> 		printf("map[0]= %x\n", map[0]);
> 		printf("map[1]= %x\n", map[1]);

This confuses me. You did write different values in _vbase[0],
_vbase[1]. But the output '4C4C4C4C' shows that the value is 'L'.

I just skimmed the output and the code. I don't run your code since I
don't have a suitible environment at the moment...

Wei.

Re: mmap in PV xen-4.0.1

[Ranjith Ravi]

[-- Attachment #1.1: Type: text/plain, Size: 4615 bytes --]

I am also seeing a similar issue.
User space process on DOMU(pv) hangs while accessing mmap() area.
And getting the following message in "xm dmesg"

(XEN) mm.c:878:d2 Error getting mfn 70d70 (pfn 43a15) from L1 entry
8000000070d70625 for l1e_owner=2, pg_owner=32753
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry
8000000001574625 for l1e_owner=2, pg_owner=32753

Running FC13-Dom0 X86_64  Xen4.0.2,
DOMU - Debian6.0 X86_64 (pv)

Code snippet is below and the complete 'xm dmesg' is attached.
Any idea about the issue/fix ?

Thanks
Ranjith

kernel module
===========
vaddr = __get_free_pages(GFP_ATOMIC, 0);
SetPageReserved(virt_to_page(vaddr));
paddr = virt_to_bus((volatile void *)  vaddr) ; //paddr-> bus address to use
in user space

userspace
=========
_memfd = open("/dev/mem", O_RDWR |  O_SYNC | O_DSYNC | O_RSYNC))
p =  (unsigned int*) mmap( NULL, 4096, PROT_READ, MAP_SHARED, _memfd,
paddr);
printf("==> %08x\n", (*p));    =====>  hangs here till ^C
printf("==> %08x\n", (*(p+1)));

Thanks
Ranjith


On Wed, Aug 10, 2011 at 2:12 AM, Wei Liu <liuw@liuw.name> wrote:

> On Tue, Aug 09, 2011 at 11:29:51PM -0700, Eric Camachat wrote:
> > Hi,
> >
> > I have a problem to map kernel memory to userspace via /dev/mem.
> > The mmap() succeeded, but when I try to access it, the program will
> > hang forever (until press ctrl-c to terminate it).
> >
> > # memtest-user
> > memtest_vma_open: virt 0x7fbc90085000, phys 0x3eee8000
> > paddr = 0x3eee8000
> >  mem = 0x7fbc90089000
> >  map = 0x7fbc90085000
> > map[0]= 4c4c4c4c
> > map[1]= 4c4c4c4c
> > *** Hang here, it cannot (finish) access the memory mapped via /dev/mem
> ***
> >
> > My test source below, and it runs properly on HVM, VirtualBox, QEM and
> > physical machines.
> > What mistake I did?
> >
> > My kernel module look like this:
> >
> =================================================================================
>
> [...snip...]
>
> > memtest_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
> >               unsigned long arg)
> > {
> >        int ret = -ENOIOCTLCMD;
> >        phys_addr_t *paddr;
> >        unsigned long *vaddr;
> >        uint32_t *size;
> >
> >        switch(cmd) {
> >        case MEMTEST_DMA_SIZE:
> >                size = (uint32_t*)arg;
> >                *size = _size;
>
> Though your output shows that this assignment works, shouldn't this
> kind of direct assignment across kernel space and user land be
> avoided? It is bad practice to do direct assignment I think.
>
> copy_{from,to}_user should do the job.
>
> >                ret = 0;
> >                break;
> >        case MEMTEST_DMA_PADDR:
> >                paddr = (phys_addr_t*)arg;
> >                *paddr = _pbase;
> >                ret = 0;
> >                break;
> >        case MEMTEST_DMA_VADDR:
> >                vaddr = (unsigned long*)arg;
> >                *vaddr = _vbase;
> >                ret = 0;
> >                break;
> >        }
> >        return ret;
> > }
> >
> >
>
> [...snip...]
>
> > static struct file_operations memtest_fops = {
> >        .owner          = THIS_MODULE,
> >        .llseek         = no_llseek,
> >        .ioctl          = memtest_ioctl,
>
> My kernel doesn't have field called 'ioctl' in file_operations.
>
> So which kernel do you use? 2.6.18? I don't have old kernel at the
> moment so I can't help you much...
>
> >        .mmap           = memtest_mmap,
> > };
> >
> >
>
> [...snip...]
>
> > static void __exit memtest_exit(void)
> > {
> >        if (_vbase != 0)
> >                free_page(_vbase);
>
> I suppose you should use free_pages here, since you use
> __get_free_pages when allocating.
>
> >        unregister_chrdev(MEMTEST_MAJOR, MEMTEST_NAME);
> > }
> >
> >
> > MODULE_LICENSE("GPL");
> >
> > module_init(memtest_init);
> > module_exit(memtest_exit);
> >
> =================================================================================
> >
> > Here is my user program:
> >
> >
> =================================================================================
> >
>
> [...snip...]
>
> >       if (map)
> >       {
> >               printf("map[0]= %x\n", map[0]);
> >               printf("map[1]= %x\n", map[1]);
>
> This confuses me. You did write different values in _vbase[0],
> _vbase[1]. But the output '4C4C4C4C' shows that the value is 'L'.
>
> I just skimmed the output and the code. I don't run your code since I
> don't have a suitible environment at the moment...
>
> Wei.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 6337 bytes --]

[-- Attachment #2: xm-dmesg.txt --]
[-- Type: text/plain, Size: 19579 bytes --]

 __  __            _  _    ___   ____     _    __      _ _  _   
 \ \/ /___ _ __   | || |  / _ \ |___ \   / |  / _| ___/ | || |  
  \  // _ \ '_ \  | || |_| | | |  __) |__| | | |_ / __| | || |_ 
  /  \  __/ | | | |__   _| |_| | / __/|__| |_|  _| (__| |__   _|
 /_/\_\___|_| |_|    |_|(_)___(_)_____|  |_(_)_|  \___|_|  |_|  
                                                                
(XEN) Xen version 4.0.2 (mockbuild@(none)) (gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) ) Thu Jun 16 00:02:00 UTC 2011
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=1024M
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b800 (usable)
(XEN)  000000000009b800 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bb780000 (usable)
(XEN)  00000000bb780000 - 00000000bb78e000 (ACPI data)
(XEN)  00000000bb78e000 - 00000000bb7d0000 (ACPI NVS)
(XEN)  00000000bb7d0000 - 00000000bb7e0000 (reserved)
(XEN)  00000000bb7ed000 - 00000000c0000000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ffa00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000138000000 (usable)
(XEN) ACPI: RSDP 000F9B20, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT BB780100, 005C (r1 061311 XSDT1813 20110613 MSFT       97)
(XEN) ACPI: FACP BB780290, 00F4 (r4 061311 FACP1813 20110613 MSFT       97)
(XEN) ACPI: DSDT BB780460, 73E4 (r2  580MX 580MX002        2 INTL 20051117)
(XEN) ACPI: FACS BB78E000, 0040
(XEN) ACPI: APIC BB780390, 008C (r2 061311 APIC1813 20110613 MSFT       97)
(XEN) ACPI: MCFG BB780420, 003C (r1 061311 OEMMCFG  20110613 MSFT       97)
(XEN) ACPI: OEMB BB78E040, 007D (r1 061311 OEMB1813 20110613 MSFT       97)
(XEN) ACPI: GSCI BB78E0C0, 2024 (r1 061311 GMCHSCI  20110613 MSFT       97)
(XEN) ACPI: DMAR BB7900F0, 00E0 (r1    AMI  OEMDMAR        1 MSFT       97)
(XEN) ACPI: SSDT BB791510, 0363 (r1 DpgPmm    CpuPm       12 INTL 20051117)
(XEN) System RAM: 3895MB (3988588kB)
(XEN) Domain heap initialised
(XEN) Processor #0 6:5 APIC version 21
(XEN) Processor #4 6:5 APIC version 21
(XEN) Processor #1 6:5 APIC version 21
(XEN) Processor #5 6:5 APIC version 21
(XEN) IOAPIC[0]: apic_id 6, version 32, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) [VT-D]iommu.c:1116: IOMMU: unsupported
(XEN) ---- print_iommu_regs ----
(XEN)  drhd->address = fed91000
(XEN)  VER = ffffffff
(XEN)  CAP = ffffffffffffffff
(XEN)  n_fault_reg = 100
(XEN)  fault_recording_offset = 3ff0
(XEN)  ECAP = ffffffffffffffff
(XEN)  GCMD = ffffffff
(XEN)  GSTS = ffffffff
(XEN)  RTADDR = ffffffffffffffff
(XEN)  CCMD = ffffffffffffffff
(XEN)  FSTS = ffffffff
(XEN)  FECTL = ffffffff
(XEN)  FEDATA = ffffffff
(XEN)  FEADDR = ffffffff
(XEN)  FEUADDR = ffffffff
(XEN) Failed to parse ACPI DMAR.  Disabling VT-d.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 3066.746 MHz processor.
(XEN) Initing memory sharing.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) EPT supports 2MB super page.
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) I/O virtualisation disabled
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) Total of 4 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) TSC is reliable, synchronization unnecessary
(XEN) Platform timer is 3.579MHz ACPI PM Timer
(XEN) Allocated console ring of 16 KiB.
(XEN) Brought up 4 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1b3a000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000130000000->0000000134000000 (245760 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81b3a000
(XEN)  Init. ramdisk: ffffffff81b3a000->ffffffff83bb1200
(XEN)  Phys-Mach map: ffffffff83bb2000->ffffffff83db2000
(XEN)  Start info:    ffffffff83db2000->ffffffff83db24b4
(XEN)  Page tables:   ffffffff83db3000->ffffffff83dd6000
(XEN)  Boot stack:    ffffffff83dd6000->ffffffff83dd7000
(XEN)  TOTAL:         ffffffff80000000->ffffffff84000000
(XEN)  ENTRY ADDRESS: ffffffff817fd200
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM: ............................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 168kB init memory.
(XEN) mm.c:878:d2 Error getting mfn 70d70 (pfn 43a15) from L1 entry 8000000070d70625 for l1e_owner=2, pg_owner=32753
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 891276 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 889548 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 894982 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 895960 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896345 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 898653 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896975 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 899084 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897608 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897929 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897238 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 899850 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 900504 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897622 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 898048 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897099 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 898194 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 898645 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897057 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897753 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896340 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 899585 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896799 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896723 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 898321 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896323 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896070 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 895380 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897029 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896337 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896645 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 899687 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 898171 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 895895 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 895962 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896605 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897304 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897911 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897705 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897156 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896937 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 898177 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 899355 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 898846 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 900535 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896696 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 894569 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896360 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 895842 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897386 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897366 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896720 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897464 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896929 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897869 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896629 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897531 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896621 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897118 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897179 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897267 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896991 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 900040 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 898668 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896888 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896528 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896360 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897120 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897387 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 898191 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 895571 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897841 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 898250 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 898574 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897657 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 895323 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 895005 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 896414 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 895810 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 895133 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 897309 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 895994 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 899228 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 890138 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
(XEN) printk: 898281 messages suppressed.
(XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: mmap in PV xen-4.0.1

[Konrad Rzeszutek Wilk]

On Wed, Aug 10, 2011 at 10:14:59AM -0700, Ranjith Ravi wrote:
> I am also seeing a similar issue.
> User space process on DOMU(pv) hangs while accessing mmap() area.
> And getting the following message in "xm dmesg"
> 
> (XEN) mm.c:878:d2 Error getting mfn 70d70 (pfn 43a15) from L1 entry
> 8000000070d70625 for l1e_owner=2, pg_owner=32753
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry
> 8000000001574625 for l1e_owner=2, pg_owner=32753
> 
> Running FC13-Dom0 X86_64  Xen4.0.2,
> DOMU - Debian6.0 X86_64 (pv)
> 
> Code snippet is below and the complete 'xm dmesg' is attached.
> Any idea about the issue/fix ?

Sure. But I am still trying to understand _why_ you want to do this?

> 
> Thanks
> Ranjith
> 
> kernel module
> ===========
> vaddr = __get_free_pages(GFP_ATOMIC, 0);
> SetPageReserved(virt_to_page(vaddr));
> paddr = virt_to_bus((volatile void *)  vaddr) ; //paddr-> bus address to use
> in user space

It actually is not the bus address. It is the guest physical address - which
is not really the hardware physical address.

> 
> userspace
> =========
> _memfd = open("/dev/mem", O_RDWR |  O_SYNC | O_DSYNC | O_RSYNC))
> p =  (unsigned int*) mmap( NULL, 4096, PROT_READ, MAP_SHARED, _memfd,
> paddr);
> printf("==> %08x\n", (*p));    =====>  hangs here till ^C
> printf("==> %08x\n", (*(p+1)));
> 
> Thanks
> Ranjith
> 
> 
> On Wed, Aug 10, 2011 at 2:12 AM, Wei Liu <liuw@liuw.name> wrote:
> 
> > On Tue, Aug 09, 2011 at 11:29:51PM -0700, Eric Camachat wrote:
> > > Hi,
> > >
> > > I have a problem to map kernel memory to userspace via /dev/mem.
> > > The mmap() succeeded, but when I try to access it, the program will
> > > hang forever (until press ctrl-c to terminate it).
> > >
> > > # memtest-user
> > > memtest_vma_open: virt 0x7fbc90085000, phys 0x3eee8000
> > > paddr = 0x3eee8000
> > >  mem = 0x7fbc90089000
> > >  map = 0x7fbc90085000
> > > map[0]= 4c4c4c4c
> > > map[1]= 4c4c4c4c
> > > *** Hang here, it cannot (finish) access the memory mapped via /dev/mem

So, if you just the standard char device and mmap on /dev/mem it works right?

> > ***
> > >
> > > My test source below, and it runs properly on HVM, VirtualBox, QEM and
> > > physical machines.
> > > What mistake I did?
> > >
> > > My kernel module look like this:
> > >
> > =================================================================================
> >
> > [...snip...]
> >
> > > memtest_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
> > >               unsigned long arg)
> > > {
> > >        int ret = -ENOIOCTLCMD;
> > >        phys_addr_t *paddr;
> > >        unsigned long *vaddr;
> > >        uint32_t *size;
> > >
> > >        switch(cmd) {
> > >        case MEMTEST_DMA_SIZE:
> > >                size = (uint32_t*)arg;
> > >                *size = _size;
> >
> > Though your output shows that this assignment works, shouldn't this
> > kind of direct assignment across kernel space and user land be
> > avoided? It is bad practice to do direct assignment I think.
> >
> > copy_{from,to}_user should do the job.
> >
> > >                ret = 0;
> > >                break;
> > >        case MEMTEST_DMA_PADDR:
> > >                paddr = (phys_addr_t*)arg;
> > >                *paddr = _pbase;
> > >                ret = 0;
> > >                break;
> > >        case MEMTEST_DMA_VADDR:
> > >                vaddr = (unsigned long*)arg;
> > >                *vaddr = _vbase;
> > >                ret = 0;
> > >                break;
> > >        }
> > >        return ret;
> > > }
> > >
> > >
> >
> > [...snip...]
> >
> > > static struct file_operations memtest_fops = {
> > >        .owner          = THIS_MODULE,
> > >        .llseek         = no_llseek,
> > >        .ioctl          = memtest_ioctl,
> >
> > My kernel doesn't have field called 'ioctl' in file_operations.
> >
> > So which kernel do you use? 2.6.18? I don't have old kernel at the
> > moment so I can't help you much...
> >
> > >        .mmap           = memtest_mmap,
> > > };
> > >
> > >
> >
> > [...snip...]
> >
> > > static void __exit memtest_exit(void)
> > > {
> > >        if (_vbase != 0)
> > >                free_page(_vbase);
> >
> > I suppose you should use free_pages here, since you use
> > __get_free_pages when allocating.
> >
> > >        unregister_chrdev(MEMTEST_MAJOR, MEMTEST_NAME);
> > > }
> > >
> > >
> > > MODULE_LICENSE("GPL");
> > >
> > > module_init(memtest_init);
> > > module_exit(memtest_exit);
> > >
> > =================================================================================
> > >
> > > Here is my user program:
> > >
> > >
> > =================================================================================
> > >
> >
> > [...snip...]
> >
> > >       if (map)
> > >       {
> > >               printf("map[0]= %x\n", map[0]);
> > >               printf("map[1]= %x\n", map[1]);
> >
> > This confuses me. You did write different values in _vbase[0],
> > _vbase[1]. But the output '4C4C4C4C' shows that the value is 'L'.
> >
> > I just skimmed the output and the code. I don't run your code since I
> > don't have a suitible environment at the moment...
> >
> > Wei.
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >

>  __  __            _  _    ___   ____     _    __      _ _  _   
>  \ \/ /___ _ __   | || |  / _ \ |___ \   / |  / _| ___/ | || |  
>   \  // _ \ '_ \  | || |_| | | |  __) |__| | | |_ / __| | || |_ 
>   /  \  __/ | | | |__   _| |_| | / __/|__| |_|  _| (__| |__   _|
>  /_/\_\___|_| |_|    |_|(_)___(_)_____|  |_(_)_|  \___|_|  |_|  
>                                                                 
> (XEN) Xen version 4.0.2 (mockbuild@(none)) (gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) ) Thu Jun 16 00:02:00 UTC 2011
> (XEN) Latest ChangeSet: unavailable
> (XEN) Bootloader: GNU GRUB 0.97
> (XEN) Command line: dom0_mem=1024M
> (XEN) Video information:
> (XEN)  VGA is text mode 80x25, font 8x16
> (XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
> (XEN) Disc information:
> (XEN)  Found 1 MBR signatures
> (XEN)  Found 1 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN)  0000000000000000 - 000000000009b800 (usable)
> (XEN)  000000000009b800 - 00000000000a0000 (reserved)
> (XEN)  00000000000e0000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 00000000bb780000 (usable)
> (XEN)  00000000bb780000 - 00000000bb78e000 (ACPI data)
> (XEN)  00000000bb78e000 - 00000000bb7d0000 (ACPI NVS)
> (XEN)  00000000bb7d0000 - 00000000bb7e0000 (reserved)
> (XEN)  00000000bb7ed000 - 00000000c0000000 (reserved)
> (XEN)  00000000fee00000 - 00000000fee01000 (reserved)
> (XEN)  00000000ffa00000 - 0000000100000000 (reserved)
> (XEN)  0000000100000000 - 0000000138000000 (usable)
> (XEN) ACPI: RSDP 000F9B20, 0024 (r2 ACPIAM)
> (XEN) ACPI: XSDT BB780100, 005C (r1 061311 XSDT1813 20110613 MSFT       97)
> (XEN) ACPI: FACP BB780290, 00F4 (r4 061311 FACP1813 20110613 MSFT       97)
> (XEN) ACPI: DSDT BB780460, 73E4 (r2  580MX 580MX002        2 INTL 20051117)
> (XEN) ACPI: FACS BB78E000, 0040
> (XEN) ACPI: APIC BB780390, 008C (r2 061311 APIC1813 20110613 MSFT       97)
> (XEN) ACPI: MCFG BB780420, 003C (r1 061311 OEMMCFG  20110613 MSFT       97)
> (XEN) ACPI: OEMB BB78E040, 007D (r1 061311 OEMB1813 20110613 MSFT       97)
> (XEN) ACPI: GSCI BB78E0C0, 2024 (r1 061311 GMCHSCI  20110613 MSFT       97)
> (XEN) ACPI: DMAR BB7900F0, 00E0 (r1    AMI  OEMDMAR        1 MSFT       97)
> (XEN) ACPI: SSDT BB791510, 0363 (r1 DpgPmm    CpuPm       12 INTL 20051117)
> (XEN) System RAM: 3895MB (3988588kB)
> (XEN) Domain heap initialised
> (XEN) Processor #0 6:5 APIC version 21
> (XEN) Processor #4 6:5 APIC version 21
> (XEN) Processor #1 6:5 APIC version 21
> (XEN) Processor #5 6:5 APIC version 21
> (XEN) IOAPIC[0]: apic_id 6, version 32, address 0xfec00000, GSI 0-23
> (XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
> (XEN) [VT-D]iommu.c:1116: IOMMU: unsupported
> (XEN) ---- print_iommu_regs ----
> (XEN)  drhd->address = fed91000
> (XEN)  VER = ffffffff
> (XEN)  CAP = ffffffffffffffff
> (XEN)  n_fault_reg = 100
> (XEN)  fault_recording_offset = 3ff0
> (XEN)  ECAP = ffffffffffffffff
> (XEN)  GCMD = ffffffff
> (XEN)  GSTS = ffffffff
> (XEN)  RTADDR = ffffffffffffffff
> (XEN)  CCMD = ffffffffffffffff
> (XEN)  FSTS = ffffffff
> (XEN)  FECTL = ffffffff
> (XEN)  FEDATA = ffffffff
> (XEN)  FEADDR = ffffffff
> (XEN)  FEUADDR = ffffffff
> (XEN) Failed to parse ACPI DMAR.  Disabling VT-d.
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Detected 3066.746 MHz processor.
> (XEN) Initing memory sharing.
> (XEN) VMX: Supported advanced features:
> (XEN)  - APIC MMIO access virtualisation
> (XEN)  - APIC TPR shadow
> (XEN)  - Extended Page Tables (EPT)
> (XEN)  - Virtual-Processor Identifiers (VPID)
> (XEN)  - Virtual NMI
> (XEN)  - MSR direct-access bitmap
> (XEN)  - Unrestricted Guest
> (XEN) EPT supports 2MB super page.
> (XEN) HVM: ASIDs enabled.
> (XEN) HVM: VMX enabled
> (XEN) HVM: Hardware Assisted Paging detected.
> (XEN) I/O virtualisation disabled
> (XEN) Enabled directed EOI with ioapic_ack_old on!
> (XEN) Total of 4 processors activated.
> (XEN) ENABLING IO-APIC IRQs
> (XEN)  -> Using old ACK method
> (XEN) TSC is reliable, synchronization unnecessary
> (XEN) Platform timer is 3.579MHz ACPI PM Timer
> (XEN) Allocated console ring of 16 KiB.
> (XEN) Brought up 4 CPUs
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN)  Xen  kernel: 64-bit, lsb, compat32
> (XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1b3a000
> (XEN) PHYSICAL MEMORY ARRANGEMENT:
> (XEN)  Dom0 alloc.:   0000000130000000->0000000134000000 (245760 pages to be allocated)
> (XEN) VIRTUAL MEMORY ARRANGEMENT:
> (XEN)  Loaded kernel: ffffffff81000000->ffffffff81b3a000
> (XEN)  Init. ramdisk: ffffffff81b3a000->ffffffff83bb1200
> (XEN)  Phys-Mach map: ffffffff83bb2000->ffffffff83db2000
> (XEN)  Start info:    ffffffff83db2000->ffffffff83db24b4
> (XEN)  Page tables:   ffffffff83db3000->ffffffff83dd6000
> (XEN)  Boot stack:    ffffffff83dd6000->ffffffff83dd7000
> (XEN)  TOTAL:         ffffffff80000000->ffffffff84000000
> (XEN)  ENTRY ADDRESS: ffffffff817fd200
> (XEN) Dom0 has maximum 4 VCPUs
> (XEN) Scrubbing Free RAM: ............................done.
> (XEN) Xen trace buffers: disabled
> (XEN) Std. Loglevel: Errors and warnings
> (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
> (XEN) Xen is relinquishing VGA console.
> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
> (XEN) Freed 168kB init memory.
> (XEN) mm.c:878:d2 Error getting mfn 70d70 (pfn 43a15) from L1 entry 8000000070d70625 for l1e_owner=2, pg_owner=32753
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 891276 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 889548 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 894982 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 895960 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896345 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 898653 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896975 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 899084 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897608 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897929 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897238 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 899850 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 900504 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897622 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 898048 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897099 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 898194 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 898645 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897057 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897753 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896340 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 899585 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896799 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896723 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 898321 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896323 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896070 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 895380 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897029 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896337 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896645 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 899687 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 898171 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 895895 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 895962 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896605 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897304 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897911 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897705 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897156 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896937 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 898177 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 899355 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 898846 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 900535 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896696 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 894569 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896360 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 895842 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897386 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897366 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896720 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897464 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896929 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897869 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896629 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897531 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896621 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897118 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897179 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897267 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896991 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 900040 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 898668 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896888 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896528 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896360 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897120 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897387 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 898191 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 895571 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897841 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 898250 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 898574 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897657 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 895323 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 895005 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 896414 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 895810 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 895133 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 897309 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 895994 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 899228 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 890138 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753
> (XEN) printk: 898281 messages suppressed.
> (XEN) mm.c:878:d2 Error getting mfn 1574 (pfn 9339) from L1 entry 8000000001574625 for l1e_owner=2, pg_owner=32753

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: mmap in PV xen-4.0.1

[Eric Camachat]

[-- Attachment #1: Type: text/plain, Size: 3738 bytes --]

On Wed, Aug 10, 2011 at 2:12 AM, Wei Liu <liuw@liuw.name> wrote:
> On Tue, Aug 09, 2011 at 11:29:51PM -0700, Eric Camachat wrote:
>> Hi,
>>
>> I have a problem to map kernel memory to userspace via /dev/mem.
>> The mmap() succeeded, but when I try to access it, the program will
>> hang forever (until press ctrl-c to terminate it).
>>
>> # memtest-user
>> memtest_vma_open: virt 0x7fbc90085000, phys 0x3eee8000
>> paddr = 0x3eee8000
>>  mem = 0x7fbc90089000
>>  map = 0x7fbc90085000
>> map[0]= 4c4c4c4c
>> map[1]= 4c4c4c4c
>> *** Hang here, it cannot (finish) access the memory mapped via /dev/mem ***
>>
>> My test source below, and it runs properly on HVM, VirtualBox, QEM and
>> physical machines.
>> What mistake I did?
>>
>> My kernel module look like this:
>> =================================================================================
>
> [...snip...]
>
>> memtest_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
>>               unsigned long arg)
>> {
>>        int ret = -ENOIOCTLCMD;
>>        phys_addr_t *paddr;
>>        unsigned long *vaddr;
>>        uint32_t *size;
>>
>>        switch(cmd) {
>>        case MEMTEST_DMA_SIZE:
>>                size = (uint32_t*)arg;
>>                *size = _size;
>
> Though your output shows that this assignment works, shouldn't this
> kind of direct assignment across kernel space and user land be
> avoided? It is bad practice to do direct assignment I think.
>
> copy_{from,to}_user should do the job.
>

I want share some memory between kernel and user applications, so I am
trying to use mmap instead of copy_{from,to} multiple times.

>>                ret = 0;
>>                break;
>>        case MEMTEST_DMA_PADDR:
>>                paddr = (phys_addr_t*)arg;
>>                *paddr = _pbase;
>>                ret = 0;
>>                break;
>>        case MEMTEST_DMA_VADDR:
>>                vaddr = (unsigned long*)arg;
>>                *vaddr = _vbase;
>>                ret = 0;
>>                break;
>>        }
>>        return ret;
>> }
>>
>>
>
> [...snip...]
>
>> static struct file_operations memtest_fops = {
>>        .owner          = THIS_MODULE,
>>        .llseek         = no_llseek,
>>        .ioctl          = memtest_ioctl,
>
> My kernel doesn't have field called 'ioctl' in file_operations.
>
> So which kernel do you use? 2.6.18? I don't have old kernel at the
> moment so I can't help you much...

I am using linux-2.5.32.24 kernel.

>
>>        .mmap           = memtest_mmap,
>> };
>>
>>
>
> [...snip...]
>
>> static void __exit memtest_exit(void)
>> {
>>        if (_vbase != 0)
>>                free_page(_vbase);
>
> I suppose you should use free_pages here, since you use
> __get_free_pages when allocating.
>
>>        unregister_chrdev(MEMTEST_MAJOR, MEMTEST_NAME);
>> }
>>
>>
>> MODULE_LICENSE("GPL");
>>
>> module_init(memtest_init);
>> module_exit(memtest_exit);
>> =================================================================================
>>
>> Here is my user program:
>>
>> =================================================================================
>>
>
> [...snip...]
>
>>       if (map)
>>       {
>>               printf("map[0]= %x\n", map[0]);
>>               printf("map[1]= %x\n", map[1]);
>
> This confuses me. You did write different values in _vbase[0],
> _vbase[1]. But the output '4C4C4C4C' shows that the value is 'L'.
>
> I just skimmed the output and the code. I don't run your code since I
> don't have a suitible environment at the moment...
>
> Wei.
>

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: mmap in PV xen-4.0.1

[Konrad Rzeszutek Wilk]

> I am using linux-2.5.32.24 kernel.

whoa.. Can't help you there. That is so ancient I've no idea how the Xen MMU works there.

Why don't you update to something more recent? Say 3.0?

Re: mmap in PV xen-4.0.1

[Ian Campbell]

On Wed, 2011-08-10 at 20:25 +0100, Konrad Rzeszutek Wilk wrote:
> > I am using linux-2.5.32.24 kernel.
> 
> whoa.. Can't help you there. That is so ancient I've no idea how the Xen MMU works there.

I presume he meant 2.6.32.24 ;-)

> Why don't you update to something more recent? Say 3.0?

...and confirm it works on native as well...

Ian.

Re: mmap in PV xen-4.0.1

[Eric Camachat]

On Wed, Aug 10, 2011 at 12:42 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2011-08-10 at 20:25 +0100, Konrad Rzeszutek Wilk wrote:
>> > I am using linux-2.5.32.24 kernel.
>>
>> whoa.. Can't help you there. That is so ancient I've no idea how the Xen MMU works there.
>
> I presume he meant 2.6.32.24 ;-)
Thanks! Should be 2.6.32.24, I made a typo.
>
>> Why don't you update to something more recent? Say 3.0?
>
> ...and confirm it works on native as well...
>
> Ian.
>
>
>

BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]

[Mark Schneider]

Hello,

I can't boot HVM with debian squeeze 6.0.2.1 when I use more than 4VCPUs 
in the hvm.cfg file (s. some error messages from the console are below)

I am wondering about the following lines:
# ---
#root@xen411dom0:/etc/xen# xm console 7
[  134.220058] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
[  134.220058] Modules linked in: uhci_hcd thermal ehci_hcd ata_piix 
xen_netfront libata xen_blkfront floppy usbcore thermal_sys nls_base 
scsi_mod
[  134.292664] CPU 0:
[  134.292664] Modules linked in: uhci_hcd thermal ehci_hcd ata_piix 
xen_netfront libata xen_blkfront floppy usbcore thermal_sys nls_base 
scsi_mod
[  134.319566] Pid: 0, comm: swapper Not tainted 2.6.32-5-amd64 #1 HVM domU
# ---

Do I need some patches or special additional setting of my the squeezy HVM?

Thank you / regards,
Mark

-- 
ms@it-infrastrukturen.org

# ---
root@xen411dom0:/etc/xen# xm console 7
[  134.220058] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
[  134.220058] Modules linked in: uhci_hcd thermal ehci_hcd ata_piix xen_netfront libata xen_blkfront floppy usbcore thermal_sys nls_base scsi_mod
[  134.292664] CPU 0:
[  134.292664] Modules linked in: uhci_hcd thermal ehci_hcd ata_piix xen_netfront libata xen_blkfront floppy usbcore thermal_sys nls_base scsi_mod
[  134.319566] Pid: 0, comm: swapper Not tainted 2.6.32-5-amd64 #1 HVM domU
[  134.369933] RIP: 0010:[<ffffffff8102c58c>]  [<ffffffff8102c58c>] native_safe_halt+0x2/0x3
[  134.369933] RSP: 0018:ffffffff8142ded0  EFLAGS: 00000246
[  134.420796] RAX: ffffffff8142dfd8 RBX: ffffffff814d67d0 RCX: 0000000000000000
[  134.420796] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
[  134.420796] RBP: ffffffff81011dce R08: 0000000000000000 R09: 0000000081528d90
[  134.470673] R10: 00000000fffede31 R11: 0000000000000001 R12: ffffffff814d4dc0
[  134.470673] R13: ffffffff8102cdcc R14: ffffffff8102cdcc R15: ffff88020bd80710
[  134.521042] FS:  00007f6b183817a0(0000) GS:ffff880008c00000(0000) knlGS:0000000000000000
[  134.521042] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[  134.521042] CR2: 00007f6b17c6de10 CR3: 000000020c797000 CR4: 00000000000006f0
[  134.571410] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  134.571410] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  134.571410] Call Trace:
[  134.571410]  [<ffffffff81017201>] ? default_idle+0x34/0x51
[  134.571410]  [<ffffffff8101758d>] ? c1e_idle+0xf5/0xfb
[  134.621779]  [<ffffffff8100feb1>] ? cpu_idle+0xa2/0xda
[  134.621779]  [<ffffffff814f3140>] ? early_idt_handler+0x0/0x71
[  134.621779]  [<ffffffff814f3cdd>] ? start_kernel+0x3dc/0x3e8
[  134.621779]  [<ffffffff814f33b7>] ? x86_64_start_kernel+0xf9/0x106
udevd[98]: worker [107] unexpectedly returned with status 0x0100

udevd[98]: worker [107] failed while handling '/devices/pci0000:00/0000:00:01.1'

udevd[98]: worker [109] unexpectedly returned with status 0x0100

udevd[98]: worker [109] failed while handling '/devices/pci0000:00/0000:00:01.2'


udevadm settle - timeout of 180 seconds reached, the event queue contains:
   /sys/devices/vif-0 (509)
   /sys/devices/vif-0/net/eth0 (629)
   /sys/devices/pci0000:00/0000:00:01.1/host0 (636)
   /sys/devices/pci0000:00/0000:00:01.1/host0/scsi_host/host0 (637)
   /sys/devices/pci0000:00/0000:00:01.1/host1 (638)
   /sys/devices/pci0000:00/0000:00:01.1/host1/scsi_host/host1 (639)
[  199.716053] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
[  199.716053] Modules linked in: scsi_wait_scan(+) uhci_hcd thermal ehci_hcd ata_piix xen_netfront libata xen_blkfront floppy usbcore thermal_sys nls_base scsi_mod
[  199.792417] CPU 0:
[  199.804323] Modules linked in: scsi_wait_scan(+) uhci_hcd thermal ehci_hcd ata_piix xen_netfront libata xen_blkfront floppy usbcore thermal_sys nls_base scsi_mod
[  199.828661] Pid: 0, comm: swapper Not tainted 2.6.32-5-amd64 #1 HVM domU
[  199.828661] RIP: 0010:[<ffffffff8102c58c>]  [<ffffffff8102c58c>] native_safe_halt+0x2/0x3
[  199.828661] RSP: 0018:ffffffff8142ded0  EFLAGS: 00000246
[  199.828661] RAX: ffffffff8142dfd8 RBX: ffffffff814d67d0 RCX: 0000000000000000
[  199.828661] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
[  199.828661] RBP: ffffffff81011dce R08: 0000000000000000 R09: 0000000081528d90
[  199.828661] R10: 00000000fffede31 R11: 0000000000000001 R12: ffffffff814d4dc0
[  199.828661] R13: ffffffff8102cdcc R14: ffffffff8102cdcc R15: ffff88020bd80710
[  199.828661] FS:  00007f6b183817a0(0000) GS:ffff880008c00000(0000) knlGS:0000000000000000
[  199.828661] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[  199.828661] CR2: 00007f6b17c6de10 CR3: 000000020c797000 CR4: 00000000000006f0
[  199.828661] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  199.828661] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  199.828661] Call Trace:
[  199.828661]  [<ffffffff81017201>] ? default_idle+0x34/0x51
[  199.828661]  [<ffffffff8101758d>] ? c1e_idle+0xf5/0xfb
[  199.828661]  [<ffffffff8100feb1>] ? cpu_idle+0xa2/0xda
[  199.828661]  [<ffffffff814f3140>] ? early_idt_handler+0x0/0x71
[  199.828661]  [<ffffffff814f3cdd>] ? start_kernel+0x3dc/0x3e8
[  199.828661]  [<ffffffff814f33b7>] ? x86_64_start_kernel+0xf9/0x106
[  242.368420] INFO: task modprobe:110 blocked for more than 120 seconds.
[  242.397772] "echo 0>  /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  242.433087] modprobe      D ffff88020c750000     0   110      1 0x00000008
[  242.467191]  ffff88020c750000 0000000000000086 ffff88020bc31eb8 ffff88020bc31eb4
[  242.529192]  0000000000000001 ffffffff8114017a 000000000000f9e0 ffff88020bc31fd8
[  242.580440]  0000000000015780 0000000000015780 ffff88020c7e0710 ffff88020c7e0a08
[  242.643053] Call Trace:
[  242.655368]  [<ffffffff8114017a>] ? sysfs_addrm_finish+0x1d/0x20a
[  242.682685]  [<ffffffff812fbab6>] ? mutex_lock+0xd/0x31
[  242.706564]  [<ffffffff812fbab6>] ? mutex_lock+0xd/0x31
[  242.730188]  [<ffffffff8106a173>] ? async_synchronize_cookie_domain+0xac/0x106
[  242.770192]  [<ffffffff81064f1a>] ? autoremove_wake_function+0x0/0x2e
[  242.801989]  [<ffffffff810689cd>] ? __blocking_notifier_call_chain+0x51/0x5f
[  242.839526]  [<ffffffff8106a1e9>] ? async_synchronize_full+0x10/0x2c
[  242.853035]  [<ffffffff8107aa93>] ? sys_init_module+0x18c/0x21a
[  242.865641]  [<ffffffff81010b42>] ? system_call_fastpath+0x16/0x1b
[  242.878727] INFO: task modprobe:114 blocked for more than 120 seconds.
[  242.892536] "echo 0>  /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  242.923819] modprobe      D ffff88020c750000     0   114      1 0x00000008
[  242.950968]  ffff88020c750000 0000000000000086 ffff88020bc7feb8 ffff88020bc7feb4
[  242.980742]  0000000000000001 ffffffff8114017a 000000000000f9e0 ffff88020bc7ffd8
[  243.010580]  0000000000015780 0000000000015780 ffff88020c7e0e20 ffff88020c7e1118
[  243.045486] Call Trace:
[  243.056195]  [<ffffffff8114017a>] ? sysfs_addrm_finish+0x1d/0x20a
[  243.079447]  [<ffffffff812fbab6>] ? mutex_lock+0xd/0x31
[  243.101785]  [<ffffffff812fbab6>] ? mutex_lock+0xd/0x31
[  243.120773]  [<ffffffff8106a173>] ? async_synchronize_cookie_domain+0xac/0x106
[  243.144224]  [<ffffffff81064f1a>] ? autoremove_wake_function+0x0/0x2e
[  243.157902]  [<ffffffff810689cd>] ? __blocking_notifier_call_chain+0x51/0x5f
[  243.179377]  [<ffffffff8106a1e9>] ? async_synchronize_full+0x10/0x2c
[  243.199721]  [<ffffffff8107aa93>] ? sys_init_module+0x18c/0x21a
[  243.220748]  [<ffffffff81010b42>] ? system_call_fastpath+0x16/0x1b
[  243.243504] INFO: task modprobe:156 blocked for more than 120 seconds.
[  243.266942] "echo 0>  /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  243.292222] modprobe      D 0000000000000000     0   156      1 0x00000000
[  243.323701]  ffff88020f097100 0000000000000082 0000000000000000 ffffffff8105a8dc
[  243.359538]  0000000000000000 0000000000000292 000000000000f9e0 ffff88020bf15fd8
[  243.378636]  0000000000015780 0000000000015780 ffff88020bed8710 ffff88020bed8a08
[  243.397627] Call Trace:
[  243.403676]  [<ffffffff8105a8dc>] ? try_to_del_timer_sync+0x63/0x6c
[  243.416619]  [<ffffffff812fbab6>] ? mutex_lock+0xd/0x31
[  243.427784]  [<ffffffff812fbab6>] ? mutex_lock+0xd/0x31
[  243.444511]  [<ffffffff812e7966>] ? klist_next+0x3c/0xa7
[  243.462728]  [<ffffffff8106a173>] ? async_synchronize_cookie_domain+0xac/0x106
[  243.488071]  [<ffffffff81064f1a>] ? autoremove_wake_function+0x0/0x2e
[  243.501905]  [<ffffffff810689cd>] ? __blocking_notifier_call_chain+0x51/0x5f
[  243.516667]  [<ffffffff8106a1e9>] ? async_synchronize_full+0x10/0x2c
[  243.529964]  [<ffffffff8107aa93>] ? sys_init_module+0x18c/0x21a
[  243.542466]  [<ffffffff81010b42>] ? system_call_fastpath+0x16/0x1b

Re: BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]

[Konrad Rzeszutek Wilk]

On Wed, Aug 10, 2011 at 10:59:55PM +0200, Mark Schneider wrote:
> Hello,
> 
> I can't boot HVM with debian squeeze 6.0.2.1 when I use more than
> 4VCPUs in the hvm.cfg file (s. some error messages from the console
> are below)

Mark, what version of Xen are you using? Did you try using 4.1.1?

> 
> I am wondering about the following lines:
> # ---
> #root@xen411dom0:/etc/xen# xm console 7
> [  134.220058] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
> [  134.220058] Modules linked in: uhci_hcd thermal ehci_hcd ata_piix
> xen_netfront libata xen_blkfront floppy usbcore thermal_sys nls_base
> scsi_mod
> [  134.292664] CPU 0:
> [  134.292664] Modules linked in: uhci_hcd thermal ehci_hcd ata_piix
> xen_netfront libata xen_blkfront floppy usbcore thermal_sys nls_base
> scsi_mod
> [  134.319566] Pid: 0, comm: swapper Not tainted 2.6.32-5-amd64 #1 HVM domU
> # ---
> 
> Do I need some patches or special additional setting of my the squeezy HVM?
> 
> Thank you / regards,
> Mark
> 
> -- 
> ms@it-infrastrukturen.org
> 
> # ---
> root@xen411dom0:/etc/xen# xm console 7
> [  134.220058] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
> [  134.220058] Modules linked in: uhci_hcd thermal ehci_hcd ata_piix xen_netfront libata xen_blkfront floppy usbcore thermal_sys nls_base scsi_mod
> [  134.292664] CPU 0:
> [  134.292664] Modules linked in: uhci_hcd thermal ehci_hcd ata_piix xen_netfront libata xen_blkfront floppy usbcore thermal_sys nls_base scsi_mod
> [  134.319566] Pid: 0, comm: swapper Not tainted 2.6.32-5-amd64 #1 HVM domU
> [  134.369933] RIP: 0010:[<ffffffff8102c58c>]  [<ffffffff8102c58c>] native_safe_halt+0x2/0x3
> [  134.369933] RSP: 0018:ffffffff8142ded0  EFLAGS: 00000246
> [  134.420796] RAX: ffffffff8142dfd8 RBX: ffffffff814d67d0 RCX: 0000000000000000
> [  134.420796] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
> [  134.420796] RBP: ffffffff81011dce R08: 0000000000000000 R09: 0000000081528d90
> [  134.470673] R10: 00000000fffede31 R11: 0000000000000001 R12: ffffffff814d4dc0
> [  134.470673] R13: ffffffff8102cdcc R14: ffffffff8102cdcc R15: ffff88020bd80710
> [  134.521042] FS:  00007f6b183817a0(0000) GS:ffff880008c00000(0000) knlGS:0000000000000000
> [  134.521042] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> [  134.521042] CR2: 00007f6b17c6de10 CR3: 000000020c797000 CR4: 00000000000006f0
> [  134.571410] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  134.571410] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  134.571410] Call Trace:
> [  134.571410]  [<ffffffff81017201>] ? default_idle+0x34/0x51
> [  134.571410]  [<ffffffff8101758d>] ? c1e_idle+0xf5/0xfb
> [  134.621779]  [<ffffffff8100feb1>] ? cpu_idle+0xa2/0xda
> [  134.621779]  [<ffffffff814f3140>] ? early_idt_handler+0x0/0x71
> [  134.621779]  [<ffffffff814f3cdd>] ? start_kernel+0x3dc/0x3e8
> [  134.621779]  [<ffffffff814f33b7>] ? x86_64_start_kernel+0xf9/0x106
> udevd[98]: worker [107] unexpectedly returned with status 0x0100
> 
> udevd[98]: worker [107] failed while handling '/devices/pci0000:00/0000:00:01.1'
> 
> udevd[98]: worker [109] unexpectedly returned with status 0x0100
> 
> udevd[98]: worker [109] failed while handling '/devices/pci0000:00/0000:00:01.2'
> 
> 
> udevadm settle - timeout of 180 seconds reached, the event queue contains:
>   /sys/devices/vif-0 (509)
>   /sys/devices/vif-0/net/eth0 (629)
>   /sys/devices/pci0000:00/0000:00:01.1/host0 (636)
>   /sys/devices/pci0000:00/0000:00:01.1/host0/scsi_host/host0 (637)
>   /sys/devices/pci0000:00/0000:00:01.1/host1 (638)
>   /sys/devices/pci0000:00/0000:00:01.1/host1/scsi_host/host1 (639)
> [  199.716053] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
> [  199.716053] Modules linked in: scsi_wait_scan(+) uhci_hcd thermal ehci_hcd ata_piix xen_netfront libata xen_blkfront floppy usbcore thermal_sys nls_base scsi_mod
> [  199.792417] CPU 0:
> [  199.804323] Modules linked in: scsi_wait_scan(+) uhci_hcd thermal ehci_hcd ata_piix xen_netfront libata xen_blkfront floppy usbcore thermal_sys nls_base scsi_mod
> [  199.828661] Pid: 0, comm: swapper Not tainted 2.6.32-5-amd64 #1 HVM domU
> [  199.828661] RIP: 0010:[<ffffffff8102c58c>]  [<ffffffff8102c58c>] native_safe_halt+0x2/0x3
> [  199.828661] RSP: 0018:ffffffff8142ded0  EFLAGS: 00000246
> [  199.828661] RAX: ffffffff8142dfd8 RBX: ffffffff814d67d0 RCX: 0000000000000000
> [  199.828661] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
> [  199.828661] RBP: ffffffff81011dce R08: 0000000000000000 R09: 0000000081528d90
> [  199.828661] R10: 00000000fffede31 R11: 0000000000000001 R12: ffffffff814d4dc0
> [  199.828661] R13: ffffffff8102cdcc R14: ffffffff8102cdcc R15: ffff88020bd80710
> [  199.828661] FS:  00007f6b183817a0(0000) GS:ffff880008c00000(0000) knlGS:0000000000000000
> [  199.828661] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> [  199.828661] CR2: 00007f6b17c6de10 CR3: 000000020c797000 CR4: 00000000000006f0
> [  199.828661] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  199.828661] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  199.828661] Call Trace:
> [  199.828661]  [<ffffffff81017201>] ? default_idle+0x34/0x51
> [  199.828661]  [<ffffffff8101758d>] ? c1e_idle+0xf5/0xfb
> [  199.828661]  [<ffffffff8100feb1>] ? cpu_idle+0xa2/0xda
> [  199.828661]  [<ffffffff814f3140>] ? early_idt_handler+0x0/0x71
> [  199.828661]  [<ffffffff814f3cdd>] ? start_kernel+0x3dc/0x3e8
> [  199.828661]  [<ffffffff814f33b7>] ? x86_64_start_kernel+0xf9/0x106
> [  242.368420] INFO: task modprobe:110 blocked for more than 120 seconds.
> [  242.397772] "echo 0>  /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [  242.433087] modprobe      D ffff88020c750000     0   110      1 0x00000008
> [  242.467191]  ffff88020c750000 0000000000000086 ffff88020bc31eb8 ffff88020bc31eb4
> [  242.529192]  0000000000000001 ffffffff8114017a 000000000000f9e0 ffff88020bc31fd8
> [  242.580440]  0000000000015780 0000000000015780 ffff88020c7e0710 ffff88020c7e0a08
> [  242.643053] Call Trace:
> [  242.655368]  [<ffffffff8114017a>] ? sysfs_addrm_finish+0x1d/0x20a
> [  242.682685]  [<ffffffff812fbab6>] ? mutex_lock+0xd/0x31
> [  242.706564]  [<ffffffff812fbab6>] ? mutex_lock+0xd/0x31
> [  242.730188]  [<ffffffff8106a173>] ? async_synchronize_cookie_domain+0xac/0x106
> [  242.770192]  [<ffffffff81064f1a>] ? autoremove_wake_function+0x0/0x2e
> [  242.801989]  [<ffffffff810689cd>] ? __blocking_notifier_call_chain+0x51/0x5f
> [  242.839526]  [<ffffffff8106a1e9>] ? async_synchronize_full+0x10/0x2c
> [  242.853035]  [<ffffffff8107aa93>] ? sys_init_module+0x18c/0x21a
> [  242.865641]  [<ffffffff81010b42>] ? system_call_fastpath+0x16/0x1b
> [  242.878727] INFO: task modprobe:114 blocked for more than 120 seconds.
> [  242.892536] "echo 0>  /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [  242.923819] modprobe      D ffff88020c750000     0   114      1 0x00000008
> [  242.950968]  ffff88020c750000 0000000000000086 ffff88020bc7feb8 ffff88020bc7feb4
> [  242.980742]  0000000000000001 ffffffff8114017a 000000000000f9e0 ffff88020bc7ffd8
> [  243.010580]  0000000000015780 0000000000015780 ffff88020c7e0e20 ffff88020c7e1118
> [  243.045486] Call Trace:
> [  243.056195]  [<ffffffff8114017a>] ? sysfs_addrm_finish+0x1d/0x20a
> [  243.079447]  [<ffffffff812fbab6>] ? mutex_lock+0xd/0x31
> [  243.101785]  [<ffffffff812fbab6>] ? mutex_lock+0xd/0x31
> [  243.120773]  [<ffffffff8106a173>] ? async_synchronize_cookie_domain+0xac/0x106
> [  243.144224]  [<ffffffff81064f1a>] ? autoremove_wake_function+0x0/0x2e
> [  243.157902]  [<ffffffff810689cd>] ? __blocking_notifier_call_chain+0x51/0x5f
> [  243.179377]  [<ffffffff8106a1e9>] ? async_synchronize_full+0x10/0x2c
> [  243.199721]  [<ffffffff8107aa93>] ? sys_init_module+0x18c/0x21a
> [  243.220748]  [<ffffffff81010b42>] ? system_call_fastpath+0x16/0x1b
> [  243.243504] INFO: task modprobe:156 blocked for more than 120 seconds.
> [  243.266942] "echo 0>  /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [  243.292222] modprobe      D 0000000000000000     0   156      1 0x00000000
> [  243.323701]  ffff88020f097100 0000000000000082 0000000000000000 ffffffff8105a8dc
> [  243.359538]  0000000000000000 0000000000000292 000000000000f9e0 ffff88020bf15fd8
> [  243.378636]  0000000000015780 0000000000015780 ffff88020bed8710 ffff88020bed8a08
> [  243.397627] Call Trace:
> [  243.403676]  [<ffffffff8105a8dc>] ? try_to_del_timer_sync+0x63/0x6c
> [  243.416619]  [<ffffffff812fbab6>] ? mutex_lock+0xd/0x31
> [  243.427784]  [<ffffffff812fbab6>] ? mutex_lock+0xd/0x31
> [  243.444511]  [<ffffffff812e7966>] ? klist_next+0x3c/0xa7
> [  243.462728]  [<ffffffff8106a173>] ? async_synchronize_cookie_domain+0xac/0x106
> [  243.488071]  [<ffffffff81064f1a>] ? autoremove_wake_function+0x0/0x2e
> [  243.501905]  [<ffffffff810689cd>] ? __blocking_notifier_call_chain+0x51/0x5f
> [  243.516667]  [<ffffffff8106a1e9>] ? async_synchronize_full+0x10/0x2c
> [  243.529964]  [<ffffffff8107aa93>] ? sys_init_module+0x18c/0x21a
> [  243.542466]  [<ffffffff81010b42>] ? system_call_fastpath+0x16/0x1b
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: mmap in PV xen-4.0.1

[Eric Camachat]

The idea is move servers into XEN domU.
I saw that 3.0 has built-in XEN support, I can try it later.
But I don't know if other components are compatible with 3.0.

I just wonder that MFN should equals PFN in PV (para-virtualization),
so it should works properly.

On Wed, Aug 10, 2011 at 12:25 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>> I am using linux-2.5.32.24 kernel.
>
> whoa.. Can't help you there. That is so ancient I've no idea how the Xen MMU works there.
>
> Why don't you update to something more recent? Say 3.0?
>

Re: mmap in PV xen-4.0.1

[Wei Liu]

On Wed, Aug 10, 2011 at 12:45:20PM -0700, Eric Camachat wrote:
> The idea is move servers into XEN domU.
> I saw that 3.0 has built-in XEN support, I can try it later.
> But I don't know if other components are compatible with 3.0.
> 
> I just wonder that MFN should equals PFN in PV (para-virtualization),
> so it should works properly.
> 

If by "PFN" you mean "Physical Frame Number", then I think you made a
wrong assumption here.

MFN and PFN has no linear, 1:1 mapping relationship, let alone say
they are equal.

Wei.

Re: mmap in PV xen-4.0.1

[Eric Camachat]

On Wed, Aug 10, 2011 at 6:31 PM, Wei Liu <liuw@liuw.name> wrote:
> On Wed, Aug 10, 2011 at 12:45:20PM -0700, Eric Camachat wrote:
>> The idea is move servers into XEN domU.
>> I saw that 3.0 has built-in XEN support, I can try it later.
>> But I don't know if other components are compatible with 3.0.
>>
>> I just wonder that MFN should equals PFN in PV (para-virtualization),
>> so it should works properly.
>>
>
> If by "PFN" you mean "Physical Frame Number", then I think you made a
> wrong assumption here.
>
> MFN and PFN has no linear, 1:1 mapping relationship, let alone say
> they are equal.
>
> Wei.
>
I misunderstood in GFN and PFN, MFN and GFN should be equal.
So PV domU has the same memory view with real hardware, right?

Ref. http://blog.xen.org/index.php/2009/10/09/xen-memory-management-overview-presentation/

Re: mmap in PV xen-4.0.1

[Eric Camachat]

On Wed, Aug 10, 2011 at 8:10 PM, Eric Camachat <eric.camachat@gmail.com> wrote:
> On Wed, Aug 10, 2011 at 6:31 PM, Wei Liu <liuw@liuw.name> wrote:
>> On Wed, Aug 10, 2011 at 12:45:20PM -0700, Eric Camachat wrote:
>>> The idea is move servers into XEN domU.
>>> I saw that 3.0 has built-in XEN support, I can try it later.
>>> But I don't know if other components are compatible with 3.0.
>>>
>>> I just wonder that MFN should equals PFN in PV (para-virtualization),
>>> so it should works properly.
>>>
>>
>> If by "PFN" you mean "Physical Frame Number", then I think you made a
>> wrong assumption here.
>>
>> MFN and PFN has no linear, 1:1 mapping relationship, let alone say
>> they are equal.
>>
>> Wei.
>>
> I misunderstood in GFN and PFN, MFN and GFN should be equal.
> So PV domU has the same memory view with real hardware, right?
>
> Ref. http://blog.xen.org/index.php/2009/10/09/xen-memory-management-overview-presentation/
>

Let us back to my original concern:
Why remap_pfn_range() woks with my own device node, but deesn't work
with /dev/mem node?
This behavior is confused me.

/Eric

Re: mmap in PV xen-4.0.1

[Wei Liu]

On Thu, Aug 11, 2011 at 10:11:20AM -0700, Eric Camachat wrote:
> 
> Let us back to my original concern:
> Why remap_pfn_range() woks with my own device node, but deesn't work
> with /dev/mem node?
> This behavior is confused me.
> 
> /Eric

Well, I slightly modify your code -- remove the ioctl and hardcoded
*base into mapper, and run on my box in dom0 (Xen 4.2 + 2.6.39 PVOPS),
I get following output and kernel log:

paddr = 0x6d368000
  mem = 0xffffffffffffffff
  map = 0x7fa928e88000
map[0]= 1234
map[1]= abcd

[  405.039120] memtest: registering /dev/memtest (886)
[  405.039125] memtest: size of phys_addr_t is 8 bytes
[  405.039132] memtest: _vbase = 0xffff88006d368000
[  405.039134] memtest: _pbase = 0x6d368000
[  405.039135] memtest: _mbase = 0x6fbaa000
[  781.414747] Program mapper tried to access /dev/mem between 6d368000->6d36c000.
[  781.414764] memtest_vma_open: virt 0x7f327a275000, phys 0x6d368000
[  781.414942] mapper[2744]: segfault at ffffffffffffffff ip 00000000004008d7 sp 00007fff233638e0 error 4 in mapper[400000+1000]
[  781.415064] memtest_vma_close
[  891.350796] Program mapper tried to access /dev/mem between 6d368000->6d36c000.
[  891.350813] memtest_vma_open: virt 0x7fa928e88000, phys 0x6d368000
[  891.350987] mapper[2811]: segfault at ffffffffffffffff ip 00000000004008d7 sp 00007fffc154efd0 error 4 in mapper[400000+1000]
[  891.351102] memtest_vma_close

Looking into the kernel source, a check in range_is_allowed failed so
I just can't map /dev/mem with specified range (-EPERM).

But please note that my output of map[0] and map[1] are correct, while
your output is not correct ('4C4C4C4C'), which you ignored
previously. Why not make sure your mapper works correctly? Or can you
try newer kernel and Xen?

Wei.

Re: mmap in PV xen-4.0.1

[Eric Camachat]

On Thu, Aug 11, 2011 at 9:26 PM, Wei Liu <liuw@liuw.name> wrote:
> On Thu, Aug 11, 2011 at 10:11:20AM -0700, Eric Camachat wrote:
>>
>> Let us back to my original concern:
>> Why remap_pfn_range() woks with my own device node, but deesn't work
>> with /dev/mem node?
>> This behavior is confused me.
>>
>> /Eric
>
> Well, I slightly modify your code -- remove the ioctl and hardcoded
> *base into mapper, and run on my box in dom0 (Xen 4.2 + 2.6.39 PVOPS),
> I get following output and kernel log:
>
> paddr = 0x6d368000
>  mem = 0xffffffffffffffff
>  map = 0x7fa928e88000
> map[0]= 1234
> map[1]= abcd
>
> [  405.039120] memtest: registering /dev/memtest (886)
> [  405.039125] memtest: size of phys_addr_t is 8 bytes
> [  405.039132] memtest: _vbase = 0xffff88006d368000
> [  405.039134] memtest: _pbase = 0x6d368000
> [  405.039135] memtest: _mbase = 0x6fbaa000
> [  781.414747] Program mapper tried to access /dev/mem between 6d368000->6d36c000.
> [  781.414764] memtest_vma_open: virt 0x7f327a275000, phys 0x6d368000
> [  781.414942] mapper[2744]: segfault at ffffffffffffffff ip 00000000004008d7 sp 00007fff233638e0 error 4 in mapper[400000+1000]
> [  781.415064] memtest_vma_close
> [  891.350796] Program mapper tried to access /dev/mem between 6d368000->6d36c000.
> [  891.350813] memtest_vma_open: virt 0x7fa928e88000, phys 0x6d368000
> [  891.350987] mapper[2811]: segfault at ffffffffffffffff ip 00000000004008d7 sp 00007fffc154efd0 error 4 in mapper[400000+1000]
> [  891.351102] memtest_vma_close
>
> Looking into the kernel source, a check in range_is_allowed failed so
> I just can't map /dev/mem with specified range (-EPERM).
>
> But please note that my output of map[0] and map[1] are correct, while
> your output is not correct ('4C4C4C4C'), which you ignored

That's I memset() 'L' to _vbase. Sorry, I pasted wrong output.

> previously. Why not make sure your mapper works correctly? Or can you
> try newer kernel and Xen?
>
> Wei.
>

It works with newer kernel (like 2.6.37), so I think its not XEN's problem.
Thanks for your help!

/Eric

Re: mmap in PV xen-4.0.1

[Ranjith Ravi]

[-- Attachment #1.1: Type: text/plain, Size: 2769 bytes --]

> Looking into the kernel source, a check in range_is_allowed failed so
> I just can't map /dev/mem with specified range (-EPERM).

 mmap() and read access  works on 2.6.37.6
( dom0 - fc13 xen 4.0.2)
Tried it after disabling 'CONFIG_STRICT_DEVMEM' in kernel config.

Can someone point out the changes/patches in 2.6.37.6 which fixes mmap()
problem ?

Thanks
Ranjith


On Fri, Aug 12, 2011 at 10:20 AM, Eric Camachat <eric.camachat@gmail.com>wrote:

> On Thu, Aug 11, 2011 at 9:26 PM, Wei Liu <liuw@liuw.name> wrote:
> > On Thu, Aug 11, 2011 at 10:11:20AM -0700, Eric Camachat wrote:
> >>
> >> Let us back to my original concern:
> >> Why remap_pfn_range() woks with my own device node, but deesn't work
> >> with /dev/mem node?
> >> This behavior is confused me.
> >>
> >> /Eric
> >
> > Well, I slightly modify your code -- remove the ioctl and hardcoded
> > *base into mapper, and run on my box in dom0 (Xen 4.2 + 2.6.39 PVOPS),
> > I get following output and kernel log:
> >
> > paddr = 0x6d368000
> >  mem = 0xffffffffffffffff
> >  map = 0x7fa928e88000
> > map[0]= 1234
> > map[1]= abcd
> >
> > [  405.039120] memtest: registering /dev/memtest (886)
> > [  405.039125] memtest: size of phys_addr_t is 8 bytes
> > [  405.039132] memtest: _vbase = 0xffff88006d368000
> > [  405.039134] memtest: _pbase = 0x6d368000
> > [  405.039135] memtest: _mbase = 0x6fbaa000
> > [  781.414747] Program mapper tried to access /dev/mem between
> 6d368000->6d36c000.
> > [  781.414764] memtest_vma_open: virt 0x7f327a275000, phys 0x6d368000
> > [  781.414942] mapper[2744]: segfault at ffffffffffffffff ip
> 00000000004008d7 sp 00007fff233638e0 error 4 in mapper[400000+1000]
> > [  781.415064] memtest_vma_close
> > [  891.350796] Program mapper tried to access /dev/mem between
> 6d368000->6d36c000.
> > [  891.350813] memtest_vma_open: virt 0x7fa928e88000, phys 0x6d368000
> > [  891.350987] mapper[2811]: segfault at ffffffffffffffff ip
> 00000000004008d7 sp 00007fffc154efd0 error 4 in mapper[400000+1000]
> > [  891.351102] memtest_vma_close
> >
> > Looking into the kernel source, a check in range_is_allowed failed so
> > I just can't map /dev/mem with specified range (-EPERM).
> >
> > But please note that my output of map[0] and map[1] are correct, while
> > your output is not correct ('4C4C4C4C'), which you ignored
>
> That's I memset() 'L' to _vbase. Sorry, I pasted wrong output.
>
> > previously. Why not make sure your mapper works correctly? Or can you
> > try newer kernel and Xen?
> >
> > Wei.
> >
>
> It works with newer kernel (like 2.6.37), so I think its not XEN's problem.
> Thanks for your help!
>
> /Eric
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 3833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: mmap in PV xen-4.0.1

[Konrad Rzeszutek Wilk]

On Mon, Aug 15, 2011 at 08:13:37PM -0700, Ranjith Ravi wrote:
> > Looking into the kernel source, a check in range_is_allowed failed so
> > I just can't map /dev/mem with specified range (-EPERM).
> 
>  mmap() and read access  works on 2.6.37.6
> ( dom0 - fc13 xen 4.0.2)
> Tried it after disabling 'CONFIG_STRICT_DEVMEM' in kernel config.

So it did not work with CONFIG_STRICT_DEVMEM=y?

> 
> Can someone point out the changes/patches in 2.6.37.6 which fixes mmap()
> problem ?

Um, so 2.6.37 did not work?
> 
> Thanks
> Ranjith
> 
> 
> On Fri, Aug 12, 2011 at 10:20 AM, Eric Camachat <eric.camachat@gmail.com>wrote:
> 
> > On Thu, Aug 11, 2011 at 9:26 PM, Wei Liu <liuw@liuw.name> wrote:
> > > On Thu, Aug 11, 2011 at 10:11:20AM -0700, Eric Camachat wrote:
> > >>
> > >> Let us back to my original concern:
> > >> Why remap_pfn_range() woks with my own device node, but deesn't work
> > >> with /dev/mem node?
> > >> This behavior is confused me.
> > >>
> > >> /Eric
> > >
> > > Well, I slightly modify your code -- remove the ioctl and hardcoded
> > > *base into mapper, and run on my box in dom0 (Xen 4.2 + 2.6.39 PVOPS),
> > > I get following output and kernel log:
> > >
> > > paddr = 0x6d368000
> > >  mem = 0xffffffffffffffff
> > >  map = 0x7fa928e88000
> > > map[0]= 1234
> > > map[1]= abcd
> > >
> > > [  405.039120] memtest: registering /dev/memtest (886)
> > > [  405.039125] memtest: size of phys_addr_t is 8 bytes
> > > [  405.039132] memtest: _vbase = 0xffff88006d368000
> > > [  405.039134] memtest: _pbase = 0x6d368000
> > > [  405.039135] memtest: _mbase = 0x6fbaa000
> > > [  781.414747] Program mapper tried to access /dev/mem between
> > 6d368000->6d36c000.
> > > [  781.414764] memtest_vma_open: virt 0x7f327a275000, phys 0x6d368000
> > > [  781.414942] mapper[2744]: segfault at ffffffffffffffff ip
> > 00000000004008d7 sp 00007fff233638e0 error 4 in mapper[400000+1000]
> > > [  781.415064] memtest_vma_close
> > > [  891.350796] Program mapper tried to access /dev/mem between
> > 6d368000->6d36c000.
> > > [  891.350813] memtest_vma_open: virt 0x7fa928e88000, phys 0x6d368000
> > > [  891.350987] mapper[2811]: segfault at ffffffffffffffff ip
> > 00000000004008d7 sp 00007fffc154efd0 error 4 in mapper[400000+1000]
> > > [  891.351102] memtest_vma_close
> > >
> > > Looking into the kernel source, a check in range_is_allowed failed so
> > > I just can't map /dev/mem with specified range (-EPERM).
> > >
> > > But please note that my output of map[0] and map[1] are correct, while
> > > your output is not correct ('4C4C4C4C'), which you ignored
> >
> > That's I memset() 'L' to _vbase. Sorry, I pasted wrong output.
> >
> > > previously. Why not make sure your mapper works correctly? Or can you
> > > try newer kernel and Xen?
> > >
> > > Wei.
> > >
> >
> > It works with newer kernel (like 2.6.37), so I think its not XEN's problem.
> > Thanks for your help!
> >
> > /Eric
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: mmap in PV xen-4.0.1

[Ranjith Ravi]

[-- Attachment #1.1: Type: text/plain, Size: 3689 bytes --]

On Mon, Aug 15, 2011 at 10:06 PM, Konrad Rzeszutek Wilk <
konrad.wilk@oracle.com> wrote:

> On Mon, Aug 15, 2011 at 08:13:37PM -0700, Ranjith Ravi wrote:
> > > Looking into the kernel source, a check in range_is_allowed failed so
> > > I just can't map /dev/mem with specified range (-EPERM).
> >
> >  mmap() and read access  works on 2.6.37.6
> > ( dom0 - fc13 xen 4.0.2)
> > Tried it after disabling 'CONFIG_STRICT_DEVMEM' in kernel config.
>
> So it did not work with CONFIG_STRICT_DEVMEM=y?
>
>
mmap() returns failure with CONFIG_STRICT_DEVMEM=y

 >
> > Can someone point out the changes/patches in 2.6.37.6 which fixes mmap()
> > problem ?
>
> Um, so 2.6.37 did not work?
> >
>

mmap()/read access worked on 2.6.37.6
Would like to try the same changes on 2.6.32 (Debian 6.0-pvops)
if some one can point the changes/patches.




> > Thanks
> > Ranjith
> >
> >
> > On Fri, Aug 12, 2011 at 10:20 AM, Eric Camachat <eric.camachat@gmail.com
> >wrote:
> >
> > > On Thu, Aug 11, 2011 at 9:26 PM, Wei Liu <liuw@liuw.name> wrote:
> > > > On Thu, Aug 11, 2011 at 10:11:20AM -0700, Eric Camachat wrote:
> > > >>
> > > >> Let us back to my original concern:
> > > >> Why remap_pfn_range() woks with my own device node, but deesn't work
> > > >> with /dev/mem node?
> > > >> This behavior is confused me.
> > > >>
> > > >> /Eric
> > > >
> > > > Well, I slightly modify your code -- remove the ioctl and hardcoded
> > > > *base into mapper, and run on my box in dom0 (Xen 4.2 + 2.6.39
> PVOPS),
> > > > I get following output and kernel log:
> > > >
> > > > paddr = 0x6d368000
> > > >  mem = 0xffffffffffffffff
> > > >  map = 0x7fa928e88000
> > > > map[0]= 1234
> > > > map[1]= abcd
> > > >
> > > > [  405.039120] memtest: registering /dev/memtest (886)
> > > > [  405.039125] memtest: size of phys_addr_t is 8 bytes
> > > > [  405.039132] memtest: _vbase = 0xffff88006d368000
> > > > [  405.039134] memtest: _pbase = 0x6d368000
> > > > [  405.039135] memtest: _mbase = 0x6fbaa000
> > > > [  781.414747] Program mapper tried to access /dev/mem between
> > > 6d368000->6d36c000.
> > > > [  781.414764] memtest_vma_open: virt 0x7f327a275000, phys 0x6d368000
> > > > [  781.414942] mapper[2744]: segfault at ffffffffffffffff ip
> > > 00000000004008d7 sp 00007fff233638e0 error 4 in mapper[400000+1000]
> > > > [  781.415064] memtest_vma_close
> > > > [  891.350796] Program mapper tried to access /dev/mem between
> > > 6d368000->6d36c000.
> > > > [  891.350813] memtest_vma_open: virt 0x7fa928e88000, phys 0x6d368000
> > > > [  891.350987] mapper[2811]: segfault at ffffffffffffffff ip
> > > 00000000004008d7 sp 00007fffc154efd0 error 4 in mapper[400000+1000]
> > > > [  891.351102] memtest_vma_close
> > > >
> > > > Looking into the kernel source, a check in range_is_allowed failed so
> > > > I just can't map /dev/mem with specified range (-EPERM).
> > > >
> > > > But please note that my output of map[0] and map[1] are correct,
> while
> > > > your output is not correct ('4C4C4C4C'), which you ignored
> > >
> > > That's I memset() 'L' to _vbase. Sorry, I pasted wrong output.
> > >
> > > > previously. Why not make sure your mapper works correctly? Or can you
> > > > try newer kernel and Xen?
> > > >
> > > > Wei.
> > > >
> > >
> > > It works with newer kernel (like 2.6.37), so I think its not XEN's
> problem.
> > > Thanks for your help!
> > >
> > > /Eric
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> > >
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
>
>

[-- Attachment #1.2: Type: text/html, Size: 5699 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: mmap in PV xen-4.0.1

[Konrad Rzeszutek Wilk]

On Tue, Aug 16, 2011 at 11:27:03AM -0700, Ranjith Ravi wrote:
> On Mon, Aug 15, 2011 at 10:06 PM, Konrad Rzeszutek Wilk <
> konrad.wilk@oracle.com> wrote:
> 
> > On Mon, Aug 15, 2011 at 08:13:37PM -0700, Ranjith Ravi wrote:
> > > > Looking into the kernel source, a check in range_is_allowed failed so
> > > > I just can't map /dev/mem with specified range (-EPERM).
> > >
> > >  mmap() and read access  works on 2.6.37.6
> > > ( dom0 - fc13 xen 4.0.2)
> > > Tried it after disabling 'CONFIG_STRICT_DEVMEM' in kernel config.
> >
> > So it did not work with CONFIG_STRICT_DEVMEM=y?
> >
> >
> mmap() returns failure with CONFIG_STRICT_DEVMEM=y
> 
>  >
> > > Can someone point out the changes/patches in 2.6.37.6 which fixes mmap()
> > > problem ?
> >
> > Um, so 2.6.37 did not work?
> > >
> >
> 
> mmap()/read access worked on 2.6.37.6
> Would like to try the same changes on 2.6.32 (Debian 6.0-pvops)
> if some one can point the changes/patches.

No idea. Looking at the changelog of 2.6.37 nothing really strikes
me as having fixed this.

Re: mmap in PV xen-4.0.1

[Eric Camachat]

On Wed, Aug 10, 2011 at 12:25 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>> I am using linux-2.5.32.24 kernel.
>
> whoa.. Can't help you there. That is so ancient I've no idea how the Xen MMU works there.
>
> Why don't you update to something more recent? Say 3.0?
Sorry, that's my typo, linux-2.6.32.24 actually.

Re: mmap in PV xen-4.0.1

[Wei Liu]

On Wed, Aug 10, 2011 at 11:31:29AM -0700, Eric Camachat wrote:
> >>
> >>        switch(cmd) {
> >>        case MEMTEST_DMA_SIZE:
> >>                size = (uint32_t*)arg;
> >>                *size = _size;
> >
> > Though your output shows that this assignment works, shouldn't this
> > kind of direct assignment across kernel space and user land be
> > avoided? It is bad practice to do direct assignment I think.
> >
> > copy_{from,to}_user should do the job.
> >
> 
> I want share some memory between kernel and user applications, so I am
> trying to use mmap instead of copy_{from,to} multiple times.
> 

I understand. 

But I still insist you use copy_{from,to}_user when doing syscalls,
just to validate the pointer for syscalls. AFAICT, a syscall is not
about sharing things, it is about providing service routines to user
space. If user space application issues syscall with wrong pointer,
your system is likely to get compromised. (well, I major in
Information Security so may be to sensitive on this...)

When you're running your own application, you can choose whatever
method you like to share data between kernel and user land.

Wei.

Re: mmap in PV xen-4.0.1

[Eric Camachat]

On Wed, Aug 10, 2011 at 6:21 PM, Wei Liu <liuw@liuw.name> wrote:
> On Wed, Aug 10, 2011 at 11:31:29AM -0700, Eric Camachat wrote:
>> >>
>> >>        switch(cmd) {
>> >>        case MEMTEST_DMA_SIZE:
>> >>                size = (uint32_t*)arg;
>> >>                *size = _size;
>> >
>> > Though your output shows that this assignment works, shouldn't this
>> > kind of direct assignment across kernel space and user land be
>> > avoided? It is bad practice to do direct assignment I think.
>> >
>> > copy_{from,to}_user should do the job.
>> >
>>
>> I want share some memory between kernel and user applications, so I am
>> trying to use mmap instead of copy_{from,to} multiple times.
>>
>
> I understand.
>
> But I still insist you use copy_{from,to}_user when doing syscalls,
> just to validate the pointer for syscalls. AFAICT, a syscall is not
> about sharing things, it is about providing service routines to user
> space. If user space application issues syscall with wrong pointer,
> your system is likely to get compromised. (well, I major in
> Information Security so may be to sensitive on this...)
>
> When you're running your own application, you can choose whatever
> method you like to share data between kernel and user land.
>
> Wei.
>

Even though it can resolved by copy_{from,to}, I still don't know why
it didn't work in PV.
I want figure out this, cause we want port our existing servers into
XEN and keep minimum code changes to avoid any side effects.

/Eric

Re: BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]

[Mark Schneider]

Thanks a lot for your answer Konrad.

I use xen 4.1.2* (sources from the site of Boris with patches based on 
xen 4.1.1 I guess).
I have created debian packages and deployed them on the xen debian live 
image (kernel 3.0.1 final with such kernel config: 
http://www.it-infrastrukturen.com/fileadmin/linux/debian-live-xen/config-3.0.1)

You could easy test it on another hardware booting the image from USB 
stick. I use for tests HP DL385 g7 servers with 32GB RAM and RAID5 (4 x 
15k SAS drives) or RADI50 (8 x 15k SAS drives)

rsync -avP rsync://www.it-infrastrukturen.ch/ftp/xen411-wheezy-kernel3-amd64-live-gnome-binary-hybrid.iso .
dd if=./xen411-wheezy-kernel3-amd64-live-gnome-binary-hybrid.iso of=/dev/sdX bs=1M

more details at:
http://www.it-infrastrukturen.com/fileadmin/linux/debian-live-xen/README.xen-live

In live mode you can add additional packages however after reboot they 
are gone.
It is possible to prepare persistent USB stick (script) to save addons 
on the stick.

I use HVM domU domain for squeeze 6.0.2.1. DomU (HVM) domains for wheezy 
don't have such limits.

Thank you / regars, Mark

Ps. I hope to start a new thread with this mail (no reference header inside)


Am 13.08.2011 17:15, schrieb Konrad Rzeszutek Wilk:
> On Wed, Aug 10, 2011 at 10:59:55PM +0200, Mark Schneider wrote:
>    
>> Hello,
>>
>> I can't boot HVM with debian squeeze 6.0.2.1 when I use more than
>> 4VCPUs in the hvm.cfg file (s. some error messages from the console
>> are below)
>>      
> Mark, what version of Xen are you using? Did you try using 4.1.1?
>
>    
>> I am wondering about the following lines:
>> # ---
>> #root@xen411dom0:/etc/xen# xm console 7
>> [  134.220058] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
>> [  134.220058] Modules linked in: uhci_hcd thermal ehci_hcd ata_piix
>> xen_netfront libata xen_blkfront floppy usbcore thermal_sys nls_base
>> scsi_mod
>> [  134.292664] CPU 0:
>> [  134.292664] Modules linked in: uhci_hcd thermal ehci_hcd ata_piix
>> xen_netfront libata xen_blkfront floppy usbcore thermal_sys nls_base
>> scsi_mod
>> [  134.319566] Pid: 0, comm: swapper Not tainted 2.6.32-5-amd64 #1 HVM domU
>> # ---
>>
>> Do I need some patches or special additional setting of my the squeezy HVM?
>>
>> Thank you / regards,
>> Mark
>>
>> -- 
>> ms@it-infrastrukturen.org
>>
>> # ---
>> root@xen411dom0:/etc/xen# xm console 7
>> [  134.220058] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
>> [  134.220058] Modules linked in: uhci_hcd thermal ehci_hcd ata_piix xen_netfront libata xen_blkfront floppy usbcore thermal_sys nls_base scsi_mod
>> [  134.292664] CPU 0:
>> [  134.292664] Modules linked in: uhci_hcd thermal ehci_hcd ata_piix xen_netfront libata xen_blkfront floppy usbcore thermal_sys nls_base scsi_mod
>> [  134.319566] Pid: 0, comm: swapper Not tainted 2.6.32-5-amd64 #1 HVM domU
>> [  134.369933] RIP: 0010:[<ffffffff8102c58c>]  [<ffffffff8102c58c>] native_safe_halt+0x2/0x3
>> [  134.369933] RSP: 0018:ffffffff8142ded0  EFLAGS: 00000246
>> [  134.420796] RAX: ffffffff8142dfd8 RBX: ffffffff814d67d0 RCX: 0000000000000000
>> [  134.420796] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
>> [  134.420796] RBP: ffffffff81011dce R08: 0000000000000000 R09: 0000000081528d90
>> [  134.470673] R10: 00000000fffede31 R11: 0000000000000001 R12: ffffffff814d4dc0
>> [  134.470673] R13: ffffffff8102cdcc R14: ffffffff8102cdcc R15: ffff88020bd80710
>> [  134.521042] FS:  00007f6b183817a0(0000) GS:ffff880008c00000(0000) knlGS:0000000000000000
>> [  134.521042] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
>> [  134.521042] CR2: 00007f6b17c6de10 CR3: 000000020c797000 CR4: 00000000000006f0
>> [  134.571410] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [  134.571410] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> [  134.571410] Call Trace:
>> [  134.571410]  [<ffffffff81017201>] ? default_idle+0x34/0x51
>> [  134.571410]  [<ffffffff8101758d>] ? c1e_idle+0xf5/0xfb
>> [  134.621779]  [<ffffffff8100feb1>] ? cpu_idle+0xa2/0xda
>> [  134.621779]  [<ffffffff814f3140>] ? early_idt_handler+0x0/0x71
>> [  134.621779]  [<ffffffff814f3cdd>] ? start_kernel+0x3dc/0x3e8
>> [  134.621779]  [<ffffffff814f33b7>] ? x86_64_start_kernel+0xf9/0x106
>> udevd[98]: worker [107] unexpectedly returned with status 0x0100
>>
>> udevd[98]: worker [107] failed while handling '/devices/pci0000:00/0000:00:01.1'
>>
>> udevd[98]: worker [109] unexpectedly returned with status 0x0100
>>
>> udevd[98]: worker [109] failed while handling '/devices/pci0000:00/0000:00:01.2'
>>
>>
>> udevadm settle - timeout of 180 seconds reached, the event queue contains:
>>    /sys/devices/vif-0 (509)
>>    /sys/devices/vif-0/net/eth0 (629)
>>    /sys/devices/pci0000:00/0000:00:01.1/host0 (636)
>>    /sys/devices/pci0000:00/0000:00:01.1/host0/scsi_host/host0 (637)
>>    /sys/devices/pci0000:00/0000:00:01.1/host1 (638)
>>    /sys/devices/pci0000:00/0000:00:01.1/host1/scsi_host/host1 (639)
>> [  199.716053] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
>> [  199.716053] Modules linked in: scsi_wait_scan(+) uhci_hcd thermal ehci_hcd ata_piix xen_netfront libata xen_blkfront floppy usbcore thermal_sys nls_base scsi_mod
>> [  199.792417] CPU 0:
>> [  199.804323] Modules linked in: scsi_wait_scan(+) uhci_hcd thermal ehci_hcd ata_piix xen_netfront libata xen_blkfront floppy usbcore thermal_sys nls_base scsi_mod
>> [  199.828661] Pid: 0, comm: swapper Not tainted 2.6.32-5-amd64 #1 HVM domU
>> [  199.828661] RIP: 0010:[<ffffffff8102c58c>]  [<ffffffff8102c58c>] native_safe_halt+0x2/0x3
>> [  199.828661] RSP: 0018:ffffffff8142ded0  EFLAGS: 00000246
>> [  199.828661] RAX: ffffffff8142dfd8 RBX: ffffffff814d67d0 RCX: 0000000000000000
>> [  199.828661] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
>> [  199.828661] RBP: ffffffff81011dce R08: 0000000000000000 R09: 0000000081528d90
>> [  199.828661] R10: 00000000fffede31 R11: 0000000000000001 R12: ffffffff814d4dc0
>> [  199.828661] R13: ffffffff8102cdcc R14: ffffffff8102cdcc R15: ffff88020bd80710
>> [  199.828661] FS:  00007f6b183817a0(0000) GS:ffff880008c00000(0000) knlGS:0000000000000000
>> [  199.828661] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
>> [  199.828661] CR2: 00007f6b17c6de10 CR3: 000000020c797000 CR4: 00000000000006f0
>> [  199.828661] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [  199.828661] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> [  199.828661] Call Trace:
>> [  199.828661]  [<ffffffff81017201>] ? default_idle+0x34/0x51
>> [  199.828661]  [<ffffffff8101758d>] ? c1e_idle+0xf5/0xfb
>> [  199.828661]  [<ffffffff8100feb1>] ? cpu_idle+0xa2/0xda
>> [  199.828661]  [<ffffffff814f3140>] ? early_idt_handler+0x0/0x71
>> [  199.828661]  [<ffffffff814f3cdd>] ? start_kernel+0x3dc/0x3e8
>> [  199.828661]  [<ffffffff814f33b7>] ? x86_64_start_kernel+0xf9/0x106
>> [  242.368420] INFO: task modprobe:110 blocked for more than 120 seconds.
>> [  242.397772] "echo 0>   /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> [  242.433087] modprobe      D ffff88020c750000     0   110      1 0x00000008
>> [  242.467191]  ffff88020c750000 0000000000000086 ffff88020bc31eb8 ffff88020bc31eb4
>> [  242.529192]  0000000000000001 ffffffff8114017a 000000000000f9e0 ffff88020bc31fd8
>> [  242.580440]  0000000000015780 0000000000015780 ffff88020c7e0710 ffff88020c7e0a08
>> [  242.643053] Call Trace:
>> [  242.655368]  [<ffffffff8114017a>] ? sysfs_addrm_finish+0x1d/0x20a
>> [  242.682685]  [<ffffffff812fbab6>] ? mutex_lock+0xd/0x31
>> [  242.706564]  [<ffffffff812fbab6>] ? mutex_lock+0xd/0x31
>> [  242.730188]  [<ffffffff8106a173>] ? async_synchronize_cookie_domain+0xac/0x106
>> [  242.770192]  [<ffffffff81064f1a>] ? autoremove_wake_function+0x0/0x2e
>> [  242.801989]  [<ffffffff810689cd>] ? __blocking_notifier_call_chain+0x51/0x5f
>> [  242.839526]  [<ffffffff8106a1e9>] ? async_synchronize_full+0x10/0x2c
>> [  242.853035]  [<ffffffff8107aa93>] ? sys_init_module+0x18c/0x21a
>> [  242.865641]  [<ffffffff81010b42>] ? system_call_fastpath+0x16/0x1b
>> [  242.878727] INFO: task modprobe:114 blocked for more than 120 seconds.
>> [  242.892536] "echo 0>   /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> [  242.923819] modprobe      D ffff88020c750000     0   114      1 0x00000008
>> [  242.950968]  ffff88020c750000 0000000000000086 ffff88020bc7feb8 ffff88020bc7feb4
>> [  242.980742]  0000000000000001 ffffffff8114017a 000000000000f9e0 ffff88020bc7ffd8
>> [  243.010580]  0000000000015780 0000000000015780 ffff88020c7e0e20 ffff88020c7e1118
>> [  243.045486] Call Trace:
>> [  243.056195]  [<ffffffff8114017a>] ? sysfs_addrm_finish+0x1d/0x20a
>> [  243.079447]  [<ffffffff812fbab6>] ? mutex_lock+0xd/0x31
>> [  243.101785]  [<ffffffff812fbab6>] ? mutex_lock+0xd/0x31
>> [  243.120773]  [<ffffffff8106a173>] ? async_synchronize_cookie_domain+0xac/0x106
>> [  243.144224]  [<ffffffff81064f1a>] ? autoremove_wake_function+0x0/0x2e
>> [  243.157902]  [<ffffffff810689cd>] ? __blocking_notifier_call_chain+0x51/0x5f
>> [  243.179377]  [<ffffffff8106a1e9>] ? async_synchronize_full+0x10/0x2c
>> [  243.199721]  [<ffffffff8107aa93>] ? sys_init_module+0x18c/0x21a
>> [  243.220748]  [<ffffffff81010b42>] ? system_call_fastpath+0x16/0x1b
>> [  243.243504] INFO: task modprobe:156 blocked for more than 120 seconds.
>> [  243.266942] "echo 0>   /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> [  243.292222] modprobe      D 0000000000000000     0   156      1 0x00000000
>> [  243.323701]  ffff88020f097100 0000000000000082 0000000000000000 ffffffff8105a8dc
>> [  243.359538]  0000000000000000 0000000000000292 000000000000f9e0 ffff88020bf15fd8
>> [  243.378636]  0000000000015780 0000000000015780 ffff88020bed8710 ffff88020bed8a08
>> [  243.397627] Call Trace:
>> [  243.403676]  [<ffffffff8105a8dc>] ? try_to_del_timer_sync+0x63/0x6c
>> [  243.416619]  [<ffffffff812fbab6>] ? mutex_lock+0xd/0x31
>> [  243.427784]  [<ffffffff812fbab6>] ? mutex_lock+0xd/0x31
>> [  243.444511]  [<ffffffff812e7966>] ? klist_next+0x3c/0xa7
>> [  243.462728]  [<ffffffff8106a173>] ? async_synchronize_cookie_domain+0xac/0x106
>> [  243.488071]  [<ffffffff81064f1a>] ? autoremove_wake_function+0x0/0x2e
>> [  243.501905]  [<ffffffff810689cd>] ? __blocking_notifier_call_chain+0x51/0x5f
>> [  243.516667]  [<ffffffff8106a1e9>] ? async_synchronize_full+0x10/0x2c
>> [  243.529964]  [<ffffffff8107aa93>] ? sys_init_module+0x18c/0x21a
>> [  243.542466]  [<ffffffff81010b42>] ? system_call_fastpath+0x16/0x1b
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>      


-- 
ms@it-infrastrukturen.org

Re: BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]

[Konrad Rzeszutek Wilk]

On Sat, Aug 13, 2011 at 05:33:24PM +0200, Mark Schneider wrote:
> Thanks a lot for your answer Konrad.

Mark,
I am just getting to this email. You are still experiencing this issue right?

> 
> I use xen 4.1.2* (sources from the site of Boris with patches based
> on xen 4.1.1 I guess).
> I have created debian packages and deployed them on the xen debian
> live image (kernel 3.0.1 final with such kernel config: http://www.it-infrastrukturen.com/fileadmin/linux/debian-live-xen/config-3.0.1)
> 
> You could easy test it on another hardware booting the image from
> USB stick. I use for tests HP DL385 g7 servers with 32GB RAM and
> RAID5 (4 x 15k SAS drives) or RADI50 (8 x 15k SAS drives)
> 
> rsync -avP rsync://www.it-infrastrukturen.ch/ftp/xen411-wheezy-kernel3-amd64-live-gnome-binary-hybrid.iso .
> dd if=./xen411-wheezy-kernel3-amd64-live-gnome-binary-hybrid.iso of=/dev/sdX bs=1M
> 
> more details at:
> http://www.it-infrastrukturen.com/fileadmin/linux/debian-live-xen/README.xen-live
> 
> In live mode you can add additional packages however after reboot
> they are gone.
> It is possible to prepare persistent USB stick (script) to save
> addons on the stick.
> 
> I use HVM domU domain for squeeze 6.0.2.1. DomU (HVM) domains for
> wheezy don't have such limits.

OK, so if I use
http://cdimage.debian.org/debian-cd/6.0.2.1/amd64/iso-dvd/debian-6.0.2.1-amd64-DVD-1.iso

I should be able to reproduce what you have. Can you also send
me your guest config file please?