qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] QEMU SD card emulation problem


From: Andreas Färber
Subject: Re: [Qemu-devel] QEMU SD card emulation problem
Date: Wed, 18 Sep 2013 19:58:16 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

Hi,

Am 17.09.2013 14:13, schrieb Taimoor Mirza:
> I have been trying to use SD card emulation of QEMU by providing host
> directory to QEMU to treat it as SD card. For this I am using option
> "-sd fat:16:rw:/home/taimoor/temp/sdcard". This works fine for me and
> I can see list of files in guest system.
> But when I delete some file from guest system sdcard directory and
> then try adding new file there, I get following error:
> 
> Could not open /home/taimoor/temp/sdcard... (Is a directory, 21) Error
> handling commits (-3)

The short answer is: Don't delete or change files passed to a guest this
way.

When you plug a physical SD card to a reader, then no one else apart
from the OS will modify the card's contents. Similarly QEMU emulates a
disk image based on the directory contents. You will find similar
discussions for vvfat with USB in the qemu-devel archives.

Feel free to post patches handling this error situation more gracefully,
but if you do want to change files on the host then use NFS or some
other mechanism.

Regards,
Andreas

> 
> I have debugged QEMU and have found that error is coming from open
> function call in qemu_open function that is called from
> commit_one_file call from ACTION_WRITEOUT case in handle_commits.
> 
> Backtrace is:
> 
> (gdb) bt
> #0  qemu_open (name=0x80c7a8c0 "/home/taimoor/temp/sdcard", flags=66)
> at util/osdep.c:202
> #1  0x80091dc1 in commit_one_file (s=0x80c7e3e0, dir_index=4,
> offset=0) at block/vvfat.c:2325
> #2  0x800927b9 in handle_commits (s=0x80c7e3e0) at block/vvfat.c:2588
> #3  0x80092cb1 in do_commit (s=0x80c7e3e0) at block/vvfat.c:2736
> #4  0x80092df2 in try_commit (s=0x80c7e3e0) at block/vvfat.c:2766
> #5  0x8009335a in vvfat_write (bs=0x80c7d258, sector_num=64,
> buf=0x80e1e000 "\370\377\377\377\377\377\004", nb_sectors=1) at
> block/vvfat.c:2860
> #6  0x800933f1 in vvfat_co_write (bs=0x80c7d258, sector_num=64,
> buf=0x80e1e000 "\370\377\377\377\377\377\004", nb_sectors=1) at
> block/vvfat.c:2872
> #7  0x80052898 in bdrv_aio_rw_vector (bs=0x80c7d258, sector_num=64,
> qiov=0xb50869b4, nb_sectors=1, cb=0x800530fe <bdrv_co_io_em_complete>,
> opaque=0xb5ceccf0, is_write=1) at block.c:4065
> #8  0x80052a01 in bdrv_aio_writev_em (bs=0x80c7d258, sector_num=64,
> qiov=0xb50869b4, nb_sectors=1, cb=0x800530fe <bdrv_co_io_em_complete>,
> opaque=0xb5ceccf0) at block.c:4086
> #9  0x800531fd in bdrv_co_io_em (bs=0x80c7d258, sector_num=64,
> nb_sectors=1, iov=0xb50869b4, is_write=true) at block.c:4283
> #10 0x8005336d in bdrv_co_writev_em (bs=0x80c7d258, sector_num=64,
> nb_sectors=1, iov=0xb50869b4) at block.c:4310
> #11 0x8004e772 in bdrv_co_do_writev (bs=0x80c7d258, sector_num=64,
> nb_sectors=1, qiov=0xb50869b4, flags=0) at block.c:2625
> #12 0x8004e8b9 in bdrv_co_writev (bs=0x80c7d258, sector_num=64,
> nb_sectors=1, qiov=0xb50869b4) at block.c:2650
> #13 0x8007a59d in raw_co_writev (bs=0x80c7b8c0, sector_num=64,
> nb_sectors=1, qiov=0xb50869b4) at block/raw.c:31
> #14 0x8004e772 in bdrv_co_do_writev (bs=0x80c7b8c0, sector_num=64,
> nb_sectors=1, qiov=0xb50869b4, flags=0) at block.c:2625
> #15 0x8004d40a in bdrv_rw_co_entry (opaque=0xb508692c) at block.c:2175
> #16 0x8009978c in coroutine_trampoline (i0=-2134407824, i1=0) at
> coroutine-ucontext.c:118
> #17 0x0059482b in makecontext () at
> ../sysdeps/unix/sysv/linux/i386/makecontext.S:88
> #18 0x80c78570 in ?? ()
> #19 0x00008124 in ?? ()
> #20 0x00000001 in ?? ()
> #21 0x00000000 in ?? ()
> 
> 
> Few questions of mine are:
> 1) Is it problem with using directory with -sd option? I have seen
> that most of ppl. use -sd with SD card image file?
> 2) Why WRITE_THROUGH action only calls commit_one_file that looks to
> be handling only single file commits?
> 3) Is SD card emulation stable or its known to be broken?
> 
> Thanks,
> Taimoor
> 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]