On Wed, 17 Dec 2008, FUJITA Tomonori wrote: > On Tue, 16 Dec 2008 00:24:27 +0200 (EET) > Kai Makisara <Kai.Makisara@xxxxxxxxxxx> wrote: > > > On Thu, 11 Dec 2008, FUJITA Tomonori wrote: > > > > > This patchset is the second half of the patchset to remove > > > scsi_execute_async in st driver. IOW, this converts st driver to use > > > the block layer functions. > > > ... > > I have looked at this patch set and run some tests. The patches make > > st_do_scsi() do everything it used to do before your patch sets. So, I > > could not resist making a patch that obsoletes st_scsi_kern_execute() from > > your first patch set :-) The patch is at the end of this message. > > I have to admit that I thought about the same thing. :) > > I prefer symmetric APIs (e.g. st_do_scsi always needs st_request or > st_allocate/release_request are used in st_do_scsi) but yeah, I agree > that your patch makes st look much prettier. > I have learned to like having only one function for submitting SCSI commands from the driver. It has sometimes made debugging easier. > > > The simple tests pass without problems. Unfortunately, the same does not > > apply to tests with bigger blocks. I wrote some data to tape and read it > > with dd. Whenever the block size exceeded 1 MB, I got data corruption just > > after the 1 MB limit. > ... > Can you replace the first and second patches in the patchset with the > following patch (that is, scsi-misc and this patch + #3-13 patches in > the patchset)? > I did this and have done both the basic tests and tests with big block sizes. No problems and data corruption seen so far. However, one thing puzzles me: today trying block size above 6144 kB returns EBUSY whereas yesterday I could use 16000 kB (although with data corruption but this should be fixed by your new patch that increments the offset between bios)? I will do some more tests tomorrow but your code looks really good. Thanks, Kai -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
