Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
On Wed, May 29, 2013 at 09:07:25AM +0800, Fam Zheng wrote: > On Tue, 05/28 12:32, Richard W.M. Jones wrote: > > > > This fixes the obvious bug. > > Thanks for figuring out this. Mainline had this 5s timeout so I kept it, > but you don't experience this bug, right? Since master doesn't setup a > timer to get curl notified about the timing, the option is just not > effective. Indeed, qemu master has: curl_easy_setopt(state->curl, CURLOPT_TIMEOUT, 5); but I don't encounter the bug when using master, and I'm pretty certain about that because I've tested it a lot. It could be that qemu master manages to recover from / restart these incomplete reads, and doesn't deliver EIO up to the guest. > > I wonder if it should be even larger? One use for curl is to install > > guests using ISOs from websites without having to download the ISO, > > and I imagine that even a 30 second timeout could be conservative for > > that task. > > > > Long latency network is common in practice, as well as low bandwidth, > the meaning of the timeout is to complete the request, in extreme cases > if it is a 1Kbps link, downloading 256k takes minutes. Anyway, I think > making it larger won't hurt. I tried playing around with timeouts yesterday. Inside the guest there is a SCSI timeout (30 seconds default, see [1]). This has to be made larger if we make the qemu timeout larger than 30 seconds. With upstream qemu I can increase this timeout to 180 seconds and so read ISOs from slow public websites. (Try changing the test script so the 'disk' variable points to an ISO such as [2]). With the v6 patch, adjusting the SCSI timeout in the guest doesn't have any effect -- the SCSI disk "aborts" after ~40 seconds whatever I do. Rich. [1] http://kb.vmware.com/kb/1009465 [2] http://mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/releases/18/Live/x86_64/ -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top
Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
On Tue, 05/28 12:32, Richard W.M. Jones wrote: > > This fixes the obvious bug. Thanks for figuring out this. Mainline had this 5s timeout so I kept it, but you don't experience this bug, right? Since master doesn't setup a timer to get curl notified about the timing, the option is just not effective. > I wonder if it should be even larger? One use for curl is to install > guests using ISOs from websites without having to download the ISO, > and I imagine that even a 30 second timeout could be conservative for > that task. > Long latency network is common in practice, as well as low bandwidth, the meaning of the timeout is to complete the request, in extreme cases if it is a 1Kbps link, downloading 256k takes minutes. Anyway, I think making it larger won't hurt. -- Fam
Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
On Tue, May 28, 2013 at 12:01:55PM +0100, Richard W.M. Jones wrote: > On Tue, May 28, 2013 at 11:35:20AM +0100, Richard W.M. Jones wrote: > > I'm continuing to investigate. > > Some more data points: > > v6 patch, with my laptop plugged directly into the gigabit ethernet > switch which is connected to the web server: > > - Worked perfectly 5 times in a row. > > v6 patch, with my laptop next to the wifi aerial: > > - Bug is harder to reproduce, maybe only happens 50% of runs. > > v6 patch, with my laptop about 100' from the wifi aerial: > > - Bug reproduces on every run. > > So something to do with long latency links. > > Question: Is there a place in the patch we could put a sleep in order > to simulate a long latency link? Something like this? tc qdisc add dev wlan0 root netem delay 200ms Stefan
Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
This fixes the obvious bug. I wonder if it should be even larger? One use for curl is to install guests using ISOs from websites without having to download the ISO, and I imagine that even a 30 second timeout could be conservative for that task. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top >From b53db35e299f1bf28daa82a322b999a3515a53b5 Mon Sep 17 00:00:00 2001 From: "Richard W.M. Jones" Date: Tue, 28 May 2013 12:30:07 +0100 Subject: [PATCH] curl: Increase block timeout. Signed-off-by: Richard W.M. Jones --- block/curl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/curl.c b/block/curl.c index 3e330b6..759f7cb 100644 --- a/block/curl.c +++ b/block/curl.c @@ -332,7 +332,7 @@ static CURLState *curl_init_state(BDRVCURLState *s) goto out; } curl_easy_setopt(state->curl, CURLOPT_URL, s->url); -curl_easy_setopt(state->curl, CURLOPT_TIMEOUT, 5); +curl_easy_setopt(state->curl, CURLOPT_TIMEOUT, 30); curl_easy_setopt(state->curl, CURLOPT_WRITEFUNCTION, (void *)curl_read_cb); curl_easy_setopt(state->curl, CURLOPT_WRITEDATA, (void *)state); curl_easy_setopt(state->curl, CURLOPT_PRIVATE, (void *)state); -- 1.8.2.1
Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
On Tue, 05/28 12:01, Richard W.M. Jones wrote: > On Tue, May 28, 2013 at 11:35:20AM +0100, Richard W.M. Jones wrote: > > I'm continuing to investigate. > > Some more data points: > > v6 patch, with my laptop plugged directly into the gigabit ethernet > switch which is connected to the web server: > > - Worked perfectly 5 times in a row. > > v6 patch, with my laptop next to the wifi aerial: > > - Bug is harder to reproduce, maybe only happens 50% of runs. > > v6 patch, with my laptop about 100' from the wifi aerial: > > - Bug reproduces on every run. > > So something to do with long latency links. > > Question: Is there a place in the patch we could put a sleep in order > to simulate a long latency link? > > I also checked the logs on the web server. There are no errors, and > each access returned a 200 or 206. So the problem doesn't appear to > be at the web server end. > > Rich. > There seems no easy way to me to inject sleep to io reqs in curl.c. Another option might be configure & compile qemu with CFLAGS=-DDEBUG_CURL and grab the stdout, so that we can see how requests are processed. -- Fam
Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
On Tue, May 28, 2013 at 11:35:20AM +0100, Richard W.M. Jones wrote: > I'm continuing to investigate. Some more data points: v6 patch, with my laptop plugged directly into the gigabit ethernet switch which is connected to the web server: - Worked perfectly 5 times in a row. v6 patch, with my laptop next to the wifi aerial: - Bug is harder to reproduce, maybe only happens 50% of runs. v6 patch, with my laptop about 100' from the wifi aerial: - Bug reproduces on every run. So something to do with long latency links. Question: Is there a place in the patch we could put a sleep in order to simulate a long latency link? I also checked the logs on the web server. There are no errors, and each access returned a 200 or 206. So the problem doesn't appear to be at the web server end. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org
Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
After discussion off-list, I've gone back and retested versions 4, 5, and 6 of this patch. I'm using the test script previously attached. I'm using libguestfs (ada94eb9) & curl (ba9a) & qemu (6a4e177114) all the latest from git. I'm using a 6 GB Windows XP guest. The web server is remote, over quite slow wifi, and is running Apache 2.2.15 on RHEL 6. I ran each test 3 times. v4: Buffer I/O errors reported inside the appliance on each run. No segfault in qemu. v5: Buffer I/O errors reported inside the appliance on each run. No segfault in qemu. v6: Buffer I/O errors reported inside the appliance on each run. No segfault in qemu. no patch (curl driver in upstream qemu): No errors. Everything works. -- So I guess what has happened is NOT a regression from v5 -> v6, but that something has changed in my environment which has stopped this patch from working. I'm continuing to investigate. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
On Tue, 05/28 09:46, Richard W.M. Jones wrote: > On Tue, May 28, 2013 at 08:47:59AM +0100, Richard W.M. Jones wrote: > > I'm not sure if a Windows guest is somehow necessary to show the > > errors. I'll retest with a Linux guest and get back to you about > > that. > > Reproducible with Linux guest (remotely over slow Wifi). > > > Also I'm testing against a remote Apache2 server over a very slow Wifi > > connection. Whereas your test was against localhost. Again, I will > > test this scenario to see if that makes a difference and get back to > > you. > > NOT reproducible with Windows XP guest over localhost, Apache2 server. > > So it seems to have something to do with the long latency and/or low > bandwidth of the slow wifi connection here. > > I will add: This bug is not 100% reproducible on every run. However > it does occur very frequently, probably in 9 out of 10 runs for me. > > Rich. > OK, I'll try a remote image then. -- Fam
Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
On Tue, May 28, 2013 at 08:47:59AM +0100, Richard W.M. Jones wrote: > I'm not sure if a Windows guest is somehow necessary to show the > errors. I'll retest with a Linux guest and get back to you about > that. Reproducible with Linux guest (remotely over slow Wifi). > Also I'm testing against a remote Apache2 server over a very slow Wifi > connection. Whereas your test was against localhost. Again, I will > test this scenario to see if that makes a difference and get back to > you. NOT reproducible with Windows XP guest over localhost, Apache2 server. So it seems to have something to do with the long latency and/or low bandwidth of the slow wifi connection here. I will add: This bug is not 100% reproducible on every run. However it does occur very frequently, probably in 9 out of 10 runs for me. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org
Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
On Tue, May 28, 2013 at 03:30:49PM +0800, Fam Zheng wrote: > > > > Sure, I'm using the attached test script. > > I used your script to test, but I don't see errors as you posted, > attached the output. The only difference is that I put libguestfs in > different directory with you and I'm using a linux guest image instead > of windows xp. Do I need to get a windows image to reproduce? There's actually an error in the output of libguestfs. As a result the test didn't fully run. The error is hidden in all the extra debugging information we're printing, but here it is: > guestfsd: error: feature 'augeas' is not available in this > build of libguestfs. Read 'AVAILABILITY' in the guestfs(3) man page for > how to check for the availability of features. > libguestfs: trace: aug_init = -1 (error) > libguestfs: error: aug_init: feature 'augeas' is not available in this > build of libguestfs. Read 'AVAILABILITY' in the guestfs(3) man page for > how to check for the availability of features. > libguestfs: trace: umount_all You need to install the Augeas development package (augeas-devel on Fedora, libaugeas-dev on Debian) and recompile libguestfs. It's a good idea to make sure you have every dependency installed by doing: yum-builddep libguestfs or apt-get build-dep libguestfs (this is covered in the libguestfs README). - - - I'm not sure if a Windows guest is somehow necessary to show the errors. I'll retest with a Linux guest and get back to you about that. Also I'm testing against a remote Apache2 server over a very slow Wifi connection. Whereas your test was against localhost. Again, I will test this scenario to see if that makes a difference and get back to you. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
> > Sure, I'm using the attached test script. I used your script to test, but I don't see errors as you posted, attached the output. The only difference is that I put libguestfs in different directory with you and I'm using a linux guest image instead of windows xp. Do I need to get a windows image to reproduce? -- Fam libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: trace: set_tmpdir "/home/fam/3rd/libguestfs/tmp" libguestfs: trace: set_tmpdir = 0 libguestfs: trace: set_cachedir "/home/fam/3rd/libguestfs/tmp" libguestfs: trace: set_cachedir = 0 libguestfs: trace: set_path "/home/fam/3rd/libguestfs/appliance" libguestfs: trace: set_path = 0 libguestfs: trace: set_qemu "/home/fam/bin/qemu.wrapper" libguestfs: trace: set_qemu = 0 libguestfs: trace: set_backend "direct" libguestfs: trace: set_backend = 0 libguestfs: create: flags = 0, handle = 0x1154ca0, program = guestfish libguestfs: trace: add_drive "/vm/arch.raw" "readonly:true" "format:raw" "protocol:http" "server:tcp:localhost" libguestfs: trace: add_drive = 0 libguestfs: trace: is_config libguestfs: trace: is_config = 1 libguestfs: trace: launch libguestfs: trace: get_tmpdir libguestfs: trace: get_tmpdir = "/home/fam/3rd/libguestfs/tmp" libguestfs: launch: backend=direct libguestfs: launch: tmpdir=/home/fam/3rd/libguestfs/tmp/libguestfsryyxc3 libguestfs: launch: umask=0022 libguestfs: launch: euid=1000 libguestfs: command: run: supermin-helper libguestfs: command: run: \ --verbose libguestfs: command: run: \ -f checksum libguestfs: command: run: \ /home/fam/3rd/libguestfs/appliance/supermin.d libguestfs: command: run: \ x86_64 supermin helper [0ms] whitelist = (not specified), host_cpu = x86_64, kernel = (null), initrd = (null), appliance = (null) supermin helper [0ms] inputs[0] = /home/fam/3rd/libguestfs/appliance/supermin.d checking modpath /lib/modules/3.9.2-1-ARCH is a directory picked vmlinuz-linux because modpath /lib/modules/3.9.2-1-ARCH exists supermin helper [0ms] finished creating kernel supermin helper [0ms] visiting /home/fam/3rd/libguestfs/appliance/supermin.d supermin helper [0ms] visiting /home/fam/3rd/libguestfs/appliance/supermin.d/base.img supermin helper [0ms] visiting /home/fam/3rd/libguestfs/appliance/supermin.d/daemon.img supermin helper [0ms] visiting /home/fam/3rd/libguestfs/appliance/supermin.d/hostfiles supermin helper [00060ms] visiting /home/fam/3rd/libguestfs/appliance/supermin.d/init.img supermin helper [00060ms] visiting /home/fam/3rd/libguestfs/appliance/supermin.d/udev-rules.img supermin helper [00060ms] adding kernel modules supermin helper [00105ms] finished creating appliance libguestfs: checksum of existing appliance: 7b304f39af320c53e919d598226561b4cfd1b96cc5dedb04a5eecd72191c246c libguestfs: trace: get_cachedir libguestfs: trace: get_cachedir = "/home/fam/3rd/libguestfs/tmp" libguestfs: [00107ms] begin testing qemu features libguestfs: command: run: /home/fam/bin/qemu.wrapper libguestfs: command: run: \ -nographic libguestfs: command: run: \ -help /home/fam/qemu/x86_64-softmmu/qemu-system-x86_64: /home/fam/3rd/curl/lib/.libs/libcurl.so.4: no version information available (required by /home/fam/qemu/x86_64-softmmu/qemu-system-x86_64) libguestfs: command: run: /home/fam/bin/qemu.wrapper libguestfs: command: run: \ -nographic libguestfs: command: run: \ -version /home/fam/qemu/x86_64-softmmu/qemu-system-x86_64: /home/fam/3rd/curl/lib/.libs/libcurl.so.4: no version information available (required by /home/fam/qemu/x86_64-softmmu/qemu-system-x86_64) libguestfs: qemu version 1.4 libguestfs: command: run: /home/fam/bin/qemu.wrapper libguestfs: command: run: \ -nographic libguestfs: command: run: \ -machine accel=kvm:tcg libguestfs: command: run: \ -device ? libguestfs: [00147ms] finished testing qemu features [00147ms] /home/fam/bin/qemu.wrapper \ -global virtio-blk-pci.scsi=off \ -nodefconfig \ -nodefaults \ -nographic \ -device virtio-scsi-pci,id=scsi \ -drive file=http://localhost/vm/arch.raw,snapshot=on,format=raw,id=hd0,if=none \ -device scsi-hd,drive=hd0 \ -drive file=/home/fam/3rd/libguestfs/tmp/.guestfs-1000/root.10296,snapshot=on,id=appliance,if=none,cache=unsafe \ -device scsi-hd,drive=appliance \ -machine accel=kvm:tcg \ -m 500 \ -no-reboot \ -no-hpet \ -device virtio-serial \ -serial stdio \ -device sga \ -chardev socket,path=/home/fam/3rd/libguestfs/tmp/libguestfsryyxc3/guestfsd.sock,id=channel0 \ -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ -kernel /home/fam/3rd/libguestfs/tmp/.guestfs-1000/kernel.10296 \ -initrd /home/fam/3rd/libguestfs/tmp/.guestfs-1000/initrd.10296 \ -append 'panic=1 console=ttyS0 udevtimeout=600 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color'/home/fam/qemu/x86_64-softmmu/qemu-system-x86_64: /home/fam/3rd/curl/lib/.libs
Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
On Mon, May 27, 2013 at 10:25:21AM +0800, Fam Zheng wrote: > On Fri, 05/24 09:07, Richard W.M. Jones wrote: > > On Fri, May 24, 2013 at 01:36:55PM +0800, Fam Zheng wrote: > > > Changes from v5: > > > 05: Rename bs to s for BDRVCURLState. > > > 06: Use int64_t for offsets. > > > Fix printf format string. > > > Move introducing of use_count to 07. > > > 07: Drop explicit cast. > > > Use int64_t for offsets. > > > Use_count moved here. > > > 08: Remove duplicated. > > > Move s->url = NULL to separate patch. > > > 09: Fix while(0); > > > 12: Added: > > > curl: set s->url to NULL after free. > > > > This patch is definitely not working. The guest sees loads of > > disk errors like this: > > > > [ 30.880265] sd 2:0:0:0: [sda] > > [ 30.880265] Add. Sense: I/O process terminated > > [ 30.880265] sd 2:0:0:0: [sda] CDB: > > [ 30.880265] Read(10): 28 00 00 bf b0 87 00 00 01 00 > > [ 32.030702] sd 2:0:0:0: [sda] > > [ 32.031663] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > > [ 32.031663] sd 2:0:0:0: [sda] > > [ 32.031663] Sense Key : Aborted Command [current] > > [ 32.031663] sd 2:0:0:0: [sda] > > [ 32.031663] Add. Sense: I/O process terminated > > [ 32.031663] sd 2:0:0:0: [sda] CDB: > > [ 32.031663] Read(10): 28 00 00 00 08 46 00 00 01 00 > > [ 32.031663] blk_update_request: 32 callbacks suppressed > > [ 32.031663] end_request: I/O error, dev sda, sector 2118 > > [ 32.031663] quiet_error: 46 callbacks suppressed > > [ 32.031663] Buffer I/O error on device sda1, logical block 2055 > > [ 32.031663] sd 2:0:0:0: [sda] > > [ 32.031663] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > > [ 32.031663] sd 2:0:0:0: [sda] > > [ 32.031663] Sense Key : Aborted Command [current] > > [ 32.031663] sd 2:0:0:0: [sda] > > [ 32.031663] Add. Sense: I/O process terminated > > [ 32.031663] sd 2:0:0:0: [sda] CDB: > > [ 32.031663] Read(10): 28 00 00 00 08 45 00 00 01 00 > > [ 32.031663] end_request: I/O error, dev sda, sector 2117 > > [ 32.031663] Buffer I/O error on device sda1, logical block 2054 > > [ 32.031663] sd 2:0:0:0: [sda] > > > > Rich, are you testing with libguestfs or qemu? Since I can't get > libguestfs run with your patch to refuse writable open. You need to add the --ro option and make sure LIBGUESTFS_BACKEND=direct. > Can you post your command? Sure, I'm using the attached test script. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) test.sh Description: Bourne shell script
Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
On Fri, 05/24 09:07, Richard W.M. Jones wrote: > On Fri, May 24, 2013 at 01:36:55PM +0800, Fam Zheng wrote: > > Changes from v5: > > 05: Rename bs to s for BDRVCURLState. > > 06: Use int64_t for offsets. > > Fix printf format string. > > Move introducing of use_count to 07. > > 07: Drop explicit cast. > > Use int64_t for offsets. > > Use_count moved here. > > 08: Remove duplicated. > > Move s->url = NULL to separate patch. > > 09: Fix while(0); > > 12: Added: > > curl: set s->url to NULL after free. > > This patch is definitely not working. The guest sees loads of > disk errors like this: > > [ 30.880265] sd 2:0:0:0: [sda] > [ 30.880265] Add. Sense: I/O process terminated > [ 30.880265] sd 2:0:0:0: [sda] CDB: > [ 30.880265] Read(10): 28 00 00 bf b0 87 00 00 01 00 > [ 32.030702] sd 2:0:0:0: [sda] > [ 32.031663] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > [ 32.031663] sd 2:0:0:0: [sda] > [ 32.031663] Sense Key : Aborted Command [current] > [ 32.031663] sd 2:0:0:0: [sda] > [ 32.031663] Add. Sense: I/O process terminated > [ 32.031663] sd 2:0:0:0: [sda] CDB: > [ 32.031663] Read(10): 28 00 00 00 08 46 00 00 01 00 > [ 32.031663] blk_update_request: 32 callbacks suppressed > [ 32.031663] end_request: I/O error, dev sda, sector 2118 > [ 32.031663] quiet_error: 46 callbacks suppressed > [ 32.031663] Buffer I/O error on device sda1, logical block 2055 > [ 32.031663] sd 2:0:0:0: [sda] > [ 32.031663] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > [ 32.031663] sd 2:0:0:0: [sda] > [ 32.031663] Sense Key : Aborted Command [current] > [ 32.031663] sd 2:0:0:0: [sda] > [ 32.031663] Add. Sense: I/O process terminated > [ 32.031663] sd 2:0:0:0: [sda] CDB: > [ 32.031663] Read(10): 28 00 00 00 08 45 00 00 01 00 > [ 32.031663] end_request: I/O error, dev sda, sector 2117 > [ 32.031663] Buffer I/O error on device sda1, logical block 2054 > [ 32.031663] sd 2:0:0:0: [sda] > Rich, are you testing with libguestfs or qemu? Since I can't get libguestfs run with your patch to refuse writable open. Can you post your command? -- Fam
Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
On Fri, May 24, 2013 at 01:36:55PM +0800, Fam Zheng wrote: > Changes from v5: > 05: Rename bs to s for BDRVCURLState. > 06: Use int64_t for offsets. > Fix printf format string. > Move introducing of use_count to 07. > 07: Drop explicit cast. > Use int64_t for offsets. > Use_count moved here. > 08: Remove duplicated. > Move s->url = NULL to separate patch. > 09: Fix while(0); > 12: Added: > curl: set s->url to NULL after free. This patch is definitely not working. The guest sees loads of disk errors like this: [ 30.880265] sd 2:0:0:0: [sda] [ 30.880265] Add. Sense: I/O process terminated [ 30.880265] sd 2:0:0:0: [sda] CDB: [ 30.880265] Read(10): 28 00 00 bf b0 87 00 00 01 00 [ 32.030702] sd 2:0:0:0: [sda] [ 32.031663] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 32.031663] sd 2:0:0:0: [sda] [ 32.031663] Sense Key : Aborted Command [current] [ 32.031663] sd 2:0:0:0: [sda] [ 32.031663] Add. Sense: I/O process terminated [ 32.031663] sd 2:0:0:0: [sda] CDB: [ 32.031663] Read(10): 28 00 00 00 08 46 00 00 01 00 [ 32.031663] blk_update_request: 32 callbacks suppressed [ 32.031663] end_request: I/O error, dev sda, sector 2118 [ 32.031663] quiet_error: 46 callbacks suppressed [ 32.031663] Buffer I/O error on device sda1, logical block 2055 [ 32.031663] sd 2:0:0:0: [sda] [ 32.031663] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 32.031663] sd 2:0:0:0: [sda] [ 32.031663] Sense Key : Aborted Command [current] [ 32.031663] sd 2:0:0:0: [sda] [ 32.031663] Add. Sense: I/O process terminated [ 32.031663] sd 2:0:0:0: [sda] CDB: [ 32.031663] Read(10): 28 00 00 00 08 45 00 00 01 00 [ 32.031663] end_request: I/O error, dev sda, sector 2117 [ 32.031663] Buffer I/O error on device sda1, logical block 2054 [ 32.031663] sd 2:0:0:0: [sda] (qemu doesn't crash) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
