aboutsummaryrefslogtreecommitdiff
path: root/dma-helpers.c
diff options
context:
space:
mode:
authorJason Baron <jbaron@redhat.com>2012-08-03 15:57:06 -0400
committerKevin Wolf <kwolf@redhat.com>2012-08-10 10:25:12 +0200
commit61f52e06f0a21bab782f98ef3ea789aa6d0aa046 (patch)
treee60508f702ec2b898782a3bdb5366d2f90ce00fb /dma-helpers.c
parent730a9c53b4e52681fcfe31cf38854cbf91e132c7 (diff)
ahci: Fix ahci cdrom read corruptions for reads > 128k
While testing q35, which has its cdrom attached to the ahci controller, I found that the Fedora 17 install would panic on boot. The panic occurs while squashfs is trying to read from the cdrom. The errors are: [ 8.622711] SQUASHFS error: xz_dec_run error, data probably corrupt [ 8.625180] SQUASHFS error: squashfs_read_data failed to read block 0x20be48a I was also able to produce corrupt data reads using an installed piix based qemu machine, using 'dd'. I found that the corruptions were only occuring when then read size was greater than 128k. For example, the following command results in corrupted reads: dd if=/dev/sr0 of=/tmp/blah bs=256k iflag=direct The > 128k size reads exercise a different code path than 128k and below. In ide_atapi_cmd_read_dma_cb() s->io_buffer_size is capped at 128k. Thus, ide_atapi_cmd_read_dma_cb() is called a second time when the read is > 128k. However, ahci_dma_rw_buf() restart the read from offset 0, instead of at 128k. Thus, resulting in a corrupted read. To fix this, I've introduced 'io_buffer_offset' field in IDEState to keep track of the offset. I've also modified ahci_populate_sglist() to take a new 3rd offset argument, so that the sglist is property initialized. I've tested this patch using 'dd' testing, and Fedora 17 now correctly boots and installs on q35 with the cdrom ahci controller. Signed-off-by: Jason Baron <jbaron@redhat.com> Tested-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'dma-helpers.c')
0 files changed, 0 insertions, 0 deletions