Xen devel - Oct 2013 - Failed to read /local/domain/0/backend/qdisk/26/51713/feature-flush-cache.

a problem occurred as follow when i use xen running a os.how can i solve it?
 here is my config 
 
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"
extra="(hd0,0)/boot/grub/grub.conf"
memory = 1024
name = "vir3"
vcpus = 1
vif = ['']
#vif=["mac=00:16:3e:00:00:22, bridge=xenbr0"]
ip = "192.168.226.158"
netmask="255.255.255.0"
getway="192.168.226.1" 
disk = ["tap:aio:/home/a/vir/new.img,xvda1,w"]
root = "/dev/xvda1 ro" 
~                            
  
                             Xen Minimal OS!
  start_info: 0xa78000(VA)
    nr_pages: 0x40000
  shared_inf: 0x8bebd000(MA)
     pt_base: 0xa7b000(VA)
nr_pt_frames: 0x9
    mfn_list: 0x978000(VA)
   mod_start: 0x0(VA)
     mod_len: 0
       flags: 0x0
    cmd_line: root=/dev/xvda1 ro (hd0,0)/boot/grub/grub.conf
  stack:      0x956de0-0x976de0
MM: Init
      _text: 0x0(VA)
     _etext: 0x71008(VA)
   _erodata: 0x87000(VA)
     _edata: 0x8c768(VA)
stack start: 0x956de0(VA)
       _end: 0x977390(VA)
  start_pfn: a87
    max_pfn: 3fffd
Mapping memory range 0xc00000 - 0x3fffd000
setting 0x0-0x87000 readonly
skipped 0x1000
MM: Initialise page allocator for c81000(c81000)-0(3fffd000)
MM: done
Demand map pfns at 3fffe000-bfffe000.
Heap resides at bffff000-fffff000.
Initialising timer interface
Initialising console ... done.
gnttab_table mapped at 0x3fffe000.
Initialising scheduler
Thread "Idle": pointer: 0xbffff030, stack: 0x3ff20000
Thread "xenstore": pointer: 0xbffff4a0, stack: 0x3ff30000
xenbus initialised on irq 1 mfn 0x247795
Dummy main: start_info=0x976ee0
Thread "main": pointer: 0xbffff910, stack: 0x3ff40000
Thread "pcifront": pointer: 0xbffffd80, stack: 0x3ff50000
"main" "root=/dev/xvda1" "ro"
"(hd0,0)/boot/grub/grub.conf"
pcifront_watches: waiting for backend path to appear device/pci/0/backend
vbd 51713 is hd0
******************* BLKFRONT for device/vbd/51713 **********
 
backend at /local/domain/0/backend/qdisk/26/51713
Failed to read /local/domain/0/backend/qdisk/26/51713/feature-flush-cache.
83888128 sectors of 0 bytes
**************************
     GNU GRUB  version 0.97  (1048576K lower / 0K upper memory)
        [ Minimal BASH-like line editing is supported.   For
         the   first   word,  TAB  lists  possible  command
         completions.  Anywhere else TAB lists the possible
         completions of a device/filename. ]
 grubdom>

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

On Tue, 2013-10-29 at 12:02 +0800, 浩樊啊 wrote:
> backend at /local/domain/0/backend/qdisk/26/51713
> Failed to
> read /local/domain/0/backend/qdisk/26/51713/feature-flush-cache. 
feature-* nodes are supposed to be optional and it appears that
qemu-xen-traditional's qdisk does not implement it. This particular node
indicates support for BLKIF_OP_FLUSH_DISKCACHE.

extras/mini-os/blkfront.c should deal with this. However it
unconditionally uses BLKIF_OP_FLUSH_DISKCACHE in blkfront_sync, I'm not
sure what the fallback (if any) is supposed to be. I doubt it can be
safely ignored, but that might be the only/best option?

qemu-xen (the upstream qemu) does seem to implement this feature, FWIW.

Ian.


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

Ian Campbell, le Thu 31 Oct 2013 15:14:59 +0000, a écrit
:
> extras/mini-os/blkfront.c should deal with this. However it
> unconditionally uses BLKIF_OP_FLUSH_DISKCACHE in blkfront_sync,
? It checks for dev->info.flush being 1.  AFAIK the printed warning
does not have consequences by itself.
> I''m not sure what the fallback (if any) is supposed to be. I doubt
it
> can be safely ignored, but that might be the only/best option?
Well, I don''t know the precise semantic of missing barrier and cache
features.  Normally it means (resp.) there is strict ordering of
operations, and no cache, but I doubt all implementations do that.  I''m
indeed afraid there is no other option than what is already implemented.

Samuel

On Thu, 2013-10-31 at 19:13 +0100, Samuel Thibault
wrote:
> Ian Campbell, le Thu 31 Oct 2013 15:14:59 +0000, a écrit :
> > extras/mini-os/blkfront.c should deal with this. However it
> > unconditionally uses BLKIF_OP_FLUSH_DISKCACHE in blkfront_sync,
> 
> ? It checks for dev->info.flush being 1.
Oh, I incorrectly read that as the request being to flush...
>   AFAIK the printed warning
> does not have consequences by itself.
> 
> > I''m not sure what the fallback (if any) is supposed to be. I
doubt it
> > can be safely ignored, but that might be the only/best option?
> 
> Well, I don''t know the precise semantic of missing barrier and
cache
> features.  Normally it means (resp.) there is strict ordering of
> operations, and no cache, but I doubt all implementations do that. 
I''m
> indeed afraid there is no other option than what is already implemented.
OK, so I also incorrectly read init_blkfront() and took the
         char path[strlen(dev->backend) +
strlen("/feature-flush-cache") + 1];
        snprintf(path, sizeof(path), "%s/mode", dev->backend);
        msg = xenbus_read(XBT_NIL, path, &c);
        if (msg) {
            printk("Error %s when reading the mode\n", msg);
            goto error;
        }
to be erroring on reading feature-flush-cache, which it isn''t...

So far I''m 0/2, sorry.

So, the upshot is that this is just a warning message and nothing to
worry about.

fanh2010, if you are really bothered by this warning perhaps a patch to
make a variant of xenbus_read_integer which silently accepts ENOENT
would be reasonable. (wait for Samuel to ack/nack the concept before
putting in the effort though)

Ian.

Ian Campbell, le Thu 31 Oct 2013 18:54:41 +0000, a écrit
:
> fanh2010, if you are really bothered by this warning perhaps a patch to
> make a variant of xenbus_read_integer which silently accepts ENOENT
> would be reasonable.
Yes, that would be fine.

Samuel