Date: Tue, 7 Apr 2015 13:16:04 +0200 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: freebsd-current@freebsd.org Subject: Re: async pass(4) patches available Message-ID: <00653530.74872429@fabiankeil.de> In-Reply-To: <20150406220744.GA92212@mithlond.kdm.org> References: <20150330222358.GA46342@mithlond.kdm.org> <2147223b.4518a234@fabiankeil.de> <20150406220744.GA92212@mithlond.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/7f2isj_2LzmDxoKePj+HxAa Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable "Kenneth D. Merry" <ken@FreeBSD.ORG> wrote: > On Mon, Apr 06, 2015 at 15:39:56 +0200, Fabian Keil wrote: > > "Kenneth D. Merry" <ken@FreeBSD.ORG> wrote: > >=20 > > > I have put patches to add an asynchronous interface to the pass(4) > > > driver and add a new camdd(8) utility here: > > >=20 > > > FreeBSD/head as of SVN revision 280857: > > >=20 > > > http://people.freebsd.org/~ken/async_pass.head.20150330.1.txt > > [...] > > > Comments and testing are welcome! As I said, camdd(8) in particular > > > is a work in progress. It could use some cleanup and there are some > > > more useful features that could be added there. > >=20 > > I've been using the patch for a couple of days on an amd64 system > > based on 11.0-CURRENT r280952 and didn't notice any obvious > > regressions using the system as usual. [...]=20 > > I also tried to test camdd, but didn't get it to work. > > Some failed attempts: > >=20 > > [fk@kendra ~]$ sudo camdd -i pass=3Dda0,bs=3D65536 -o file=3Dblafsel.img > > (pass2:umass-sim0:0:0:0): READ(6). CDB: 08 00 00 00 80 00=20 > > (pass2:umass-sim0:0:0:0): CAM status: CCB request completed with an > > error 13 bytes read from pass2 > > 13 bytes written to blafsel.img > > 20.3203 seconds elapsed > > 0.00 MB/sec > > [fk@kendra ~]$ sudo hd blafsel.img=20 > > 00000000 55 53 42 53 d9 02 00 00 00 00 01 00 01 > > |USBS.........| 0000000d > > [fk@kendra ~]$ sudo dd if=3D/dev/da0 bs=3D1k count=3D1 | hd | head -n 1 > > 1+0 records in > > 1+0 records out > > 1024 bytes transferred in 0.000603 secs (1697756 bytes/sec) > > 00000000 fc 31 c0 8e c0 8e d8 8e d0 bc 00 0e be 1a 7c bf > > |.1............|.| >=20 > One possibility is that the device doesn't support 6-byte read/write > requests. The da(4) driver has quirk entries and code to figure that out > and default to 10-byte read/write requests, but camdd(8) doesn't have > anything like that yet. >=20 > I've attached patches to camdd that allow you to specify a minimum > command size. So, apply the patches, rebuild camdd, and try this: >=20 > # sudo camdd -i pass=3Dda0,bs=3D65536,mcs=3D10 -o file=3Dblafsel.img >=20 > We'll see if that helps. I'm not sure why you were even able to get 13 > bytes back. That is very strange. With the patch, reading from da0 seems to work until the end, but again only 13 bytes are written out when writing to a file: [fk@kendra ~]$ sudo camdd -i pass=3Dda0,bs=3D65536,mcs=3D10 -o file=3Dblafs= el.img (pass2:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 78 a8 00 00 00 00 00 (pass2:umass-sim0:0:0:0): CAM status: CCB request completed with an error 4048551936 bytes read from pass2 13 bytes written to blafsel.img 127.6488 seconds elapsed 0.00 MB/sec [fk@kendra ~]$ diskinfo -v /dev/da0 /dev/da0 512 # sectorsize 4048551936 # mediasize in bytes (3.8G) 7907328 # mediasize in sectors 0 # stripesize 0 # stripeoffset 492 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. AA00000000000958 # Disk ident. It works as expected when writing to stdout, though, so this is probably just a camdd-internal issue: [fk@kendra ~]$ sudo camdd -i pass=3Dda0,bs=3D65536,mcs=3D10 -o file=3D- > /= dpool/scratch/blafasel.img (pass2:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 78 a8 00 00 00 00 00 (pass2:umass-sim0:0:0:0): CAM status: CCB request completed with an error 4048551936 bytes read from pass2 4048551936 bytes written to - 128.7222 seconds elapsed 29.99 MB/sec [fk@kendra ~]$ sudo dd if=3D/dev/da0 bs=3D65536 of=3D/dpool/scratch/blafase= l-dd.img 61776+0 records in 61776+0 records out 4048551936 bytes transferred in 134.993030 secs (29990822 bytes/sec) [fk@kendra ~]$ sha1 /dpool/scratch/blafasel*.img SHA1 (/dpool/scratch/blafasel-dd.img) =3D 12d1d9e82f840a6c6485ffcdb1fbf7802= 66ed266 SHA1 (/dpool/scratch/blafasel.img) =3D 12d1d9e82f840a6c6485ffcdb1fbf780266e= d266 Looks good to me. Fabian --Sig_/7f2isj_2LzmDxoKePj+HxAa Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUjvHAACgkQBYqIVf93VJ3V9ACfbaVhbHVn8Xyd6Sc0xndaMdBf lWQAoLn7ReGmhMFz03W2mPe/730bsKeo =jJ8S -----END PGP SIGNATURE----- --Sig_/7f2isj_2LzmDxoKePj+HxAa--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00653530.74872429>