On 06/01/2015 07:18 PM, Mark Cave-Ayland wrote: > On 02/06/15 00:09, John Snow wrote: > >> On 05/31/2015 04:05 PM, Mark Cave-Ayland wrote: >>> This patchset follows on from my recent work on fixing issues with the >>> macio controller, and remodels the new pmac_dma_read() and pmac_dma_write() >>> functions in a similar manner to the unaligned block functions. >>> >>> With this in place, long chains of overlapping unaligned requests as used >>> by OS X/Darwin will now work correctly without introducting torn sector >>> errors when writing to disk. >>> >>> Also included are some tidy-ups as a result of the above changes. >>> >>> Signed-off-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> >>> >>> Mark Cave-Ayland (4): >>> macio: switch pmac_dma_read() over to new offset/len implementation >>> macio: switch pmac_dma_write() over to new offset/len implementation >>> macio: update comment/constants to reflect the new code >>> macio: remove remainder_len DBDMA_io property >>> >>> hw/ide/macio.c | 271 >>> +++++++++++++++++--------------------------- >>> include/hw/ppc/mac_dbdma.h | 4 +- >>> 2 files changed, 105 insertions(+), 170 deletions(-) >>> >> >> More 32/64bit printf string problems: >> >> macio.c:81: sector_num is int64_t (PRId64) >> macio.c:93: sector_num >> head_bytes is size_t (%zu) >> macio.c:107: sector_num >> tail_bytes is size_t (%zu) >> macio.c:147: sector_num >> macio.c:160: sector_num >> macio.c:178: sector_num > > Ah oops. Do you need me to correct? And do you have a quick way of > testing a 32-bit build on a 64-bit OS? (-m32)? >
Unfortunately that's the best I've got. For my particular case I tend to use this: ./configure --enable-debug '--extra-cflags=-m32 -I/usr/lib/glib-2.0/include' '--extra-ldflags=-m32 -L/usr/lib/iscsi' --disable-glusterfs and that helps guide my F21 through the unholy machinations necessary to produce a 32-ish bit build. I've tried to fix this in the past, but I keep running into edge cases for e.g. cross compilation and issues with how different distros handle multi-lib/multi-arch, so it remains sort of hacky and bad. Wait to send v2 until after I look at the series a little more carefully, in case there's something else. >> But that's an unsatisfying response, so how about: >> >> Tested-by: John Snow <js...@redhat.com> >> >> Fixes the problem as far as I can tell. I'll comb it in a little more >> detail later. Have you tested this patchset with OSX et al to make sure >> it doesn't introduce any obvious regression on that side of things? > > Most of the work was done on Darwin (which definitely does unaligned > accesses) and I booted an OS X CDROM through to the point where the hard > disk started installing, so I'm reasonably confident in the patch. And > more so that it's based upon the existing block alignment code in io.c. > > Basically the point of fixing up the -M g3beige/mac99 loadvm/savevm > (which is almost there except for DBDMA) in the last release was to help > debug this. At least I could get to a point where I could start QEMU > with -loadvm, run a single cp command and then md5 the results to check > for errors rather than having to wait for an entire OS install. > If it's good enough for the mac-minded among us, it's good enough for me! > > ATB, > > Mark. > Thanks again! --js
