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;
}
================================================================================
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
On Tue, Aug 9, 2011 at 6:57 PM, Eric Camachat <eric.camachat@gmail.com> wrote:> Hi, >This is probably a better question for the xen-devel mailing list. See: http://wiki.xensource.com/xenwiki/AskingXenDevelQuestions> 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; > } > ================================================================================> > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >-- Todd Deshane http://www.linkedin.com/in/deshantm http://www.xen.org/products/cloudxen.html http://runningxen.com/ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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;
}
================================================================================
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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
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
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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 spaceIt 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/memSo, 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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? >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mark Schneider
2011-Aug-10 20:59 UTC
[Xen-devel] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. > > /EricWell, 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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 ignoredThat''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
Konrad Rzeszutek Wilk
2011-Aug-13 15:15 UTC
Re: [Xen-devel] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel