Re: async pass(4) patches available

[Kenneth D. Merry]

I have updated the asynchronous pass(4) changes, and fixed a number of bugs
in camdd(8).

The new patches are here:

FreeBSD/head as of SVN revision 290970:

http://people.freebsd.org/~ken/async_pass.head.20151117.1.txt

FreeBSD stable/10 as of SVN revision 290899:

http://people.freebsd.org/~ken/async_pass.stable10.20151117.1.txt

And a description / draft commit message, this time updated to include all
the files that have changed:

http://people.freebsd.org/~ken/async_pass_commitmsg.20151118.txt

I have also attached the description to this email.

At this point I think I've fixed enough bugs and it is stable enough to go
into the tree.  That will allow others to more easily use the code and add
enhancements.

Ken

On Mon, Mar 30, 2015 at 16:23:58 -0600, Kenneth D. Merry wrote:
> 
> I have put patches to add an asynchronous interface to the pass(4) driver
> and add a new camdd(8) utility here:
> 
> FreeBSD/head as of SVN revision 280857:
> 
> http://people.freebsd.org/~ken/async_pass.head.20150330.1.txt
> 
> FreeBSD stable/10 as of SVN revision 280856:
> 
> http://people.freebsd.org/~ken/async_pass.stable_10.20150330.1.txt
> 
> And the description / draft commit message:
> 
> http://people.freebsd.org/~ken/async_pass_commitmsg.20150330.txt
> 
> I have also attached the description and draft commit message to this
> email.
> 
> The asynchronous changes to the pass(4) driver allow queueing and fetching
> CAM CCBs via two new ioctls.  Notification of completed I/O can come via
> kqueue(2), poll(2), select(2), etc.
> 
> The camdd(8) utility is intended as a simple data transfer utility,
> benchmark, and an in-tree example of how to use the asynchronous pass(4)
> interface.
> 
> camdd(8) is still a work in progress.  It needs to be cleaned up a bit and
> streamlined.
> 
> There is one known arrival and departure bug with the pass(4) driver
> changes.  We've reproduced it with our tests at Spectra, but I haven't yet
> tracked it down.
> 
> There are many more arrival and departure bugs in FreeBSD/head, however.
> We have fixed quite a few in our local tree, but the test (called devad2)
> that triggers all of the problems uses the asynchronous pass(4) interface.
> So this is a prerequisite for fixing/verifying those bugs.
> 
> 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.
> 
> Part of the reason for camdd(8) was as a test facility for the new
> interface.  But, it also serves as a useful demonstration of the
> asynchronous pass(4) functionality, given that the original application
> that used the API doesn't make sense to go into FreeBSD.  (It is
> Spectra-specific, and not generally useful.)
> 
> Ken
> -- 
> Kenneth Merry
> k...@freebsd.org

> Add asynchronous command support to the pass(4) driver, and the new
> camdd(8) utility.
> 
> CCBs may be queued to the driver via the new CAMIOQUEUE ioctl, and
> completed CCBs may be retrieved via the CAMIOGET ioctl.  User
> processes can use poll(2) or kevent(2) to get notification when
> I/O has completed.
> 
> While the existing CAMIOCOMMAND blocking ioctl interface only
> supports user virtual data pointers in a CCB (generally only
> one per CCB), the new CAMIOQUEUE ioctl supports user virtual and
> physical address pointers, as well as user virtual and physical
> scatter/gather lists.  This allows user applications to have more
> flexibility in their data handling operations.
> 
> Kernel memory for data transferred via the queued interface is 
> allocated from the zone allocator in MAXPHYS sized chunks, and user
> data is copied in and out.  This is likely faster than the
> vmapbuf()/vunmapbuf() method used by the CAMIOCOMMAND ioctl in
> configurations with many processors (there are more TLB shootdowns
> caused by the mapping/unmapping operation) but may not be as fast
> as running with unmapped I/O.
> 
> The new memory handling model for user requests also allows
> applications to send CCBs with request sizes that are larger than
> MAXPHYS.  The pass(4) driver now limits queued requests to the I/O
> size listed by the SIM driver in the maxio field in the Path
> Inquiry (XPT_PATH_INQ) CCB.
> 
> There are some things things would be good to add:
> 
> 1. Come up with a way to do unmapped I/O on multiple buffers.
>Currently the unmapped I/O interface operates on a struct bio,
>which includes only one address and length.  It would be nice
>to be able to send an unmapped scatter/gather list down to
>busdma.  This would allow eliminating the copy we currently do
>for data.
> 
> 2. Add an ioctl to list currently outstanding CCBs in the various
>queues.
> 
> 3. Add an ioctl to cancel a request, or use the XPT_ABORT CCB to do
>that.
> 
> 4. Test physical address support.  Virtual pointers and scatter
>gather lists have been tested, 

Re: async pass(4) patches available

[Fabian Keil]

Kenneth D. Merry k...@freebsd.org wrote:

 On Mon, Apr 06, 2015 at 15:39:56 +0200, Fabian Keil wrote:
  Kenneth D. Merry k...@freebsd.org wrote:
  
   I have put patches to add an asynchronous interface to the pass(4)
   driver and add a new camdd(8) utility here:
   
   FreeBSD/head as of SVN revision 280857:
   
   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.
  
  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.
[...] 
  I also tried to test camdd, but didn't get it to work.
  Some failed attempts:
  
  [fk@kendra ~]$ sudo camdd -i pass=da0,bs=65536 -o file=blafsel.img
  (pass2:umass-sim0:0:0:0): READ(6). CDB: 08 00 00 00 80 00 
  (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 
    55 53 42 53 d9 02 00 00  00 00 01 00 01
  |USBS.| 000d
  [fk@kendra ~]$ sudo dd if=/dev/da0 bs=1k count=1  | hd | head -n 1
  1+0 records in
  1+0 records out
  1024 bytes transferred in 0.000603 secs (1697756 bytes/sec)
    fc 31 c0 8e c0 8e d8 8e  d0 bc 00 0e be 1a 7c bf
  |.1|.|
 
 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.
 
 I've attached patches to camdd that allow you to specify a minimum
 command size.  So, apply the patches, rebuild camdd, and try this:
 
 # sudo camdd -i pass=da0,bs=65536,mcs=10 -o file=blafsel.img
 
 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=da0,bs=65536,mcs=10 -o file=blafsel.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.
AA000958# 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=da0,bs=65536,mcs=10 -o file=-  
/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=/dev/da0 bs=65536 of=/dpool/scratch/blafasel-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) = 12d1d9e82f840a6c6485ffcdb1fbf780266ed266
SHA1 (/dpool/scratch/blafasel.img) = 12d1d9e82f840a6c6485ffcdb1fbf780266ed266

Looks good to me.

Fabian


pgpgjgDl4f968.pgp
Description: OpenPGP digital signature

Re: async pass(4) patches available

[Kenneth D. Merry]

On Tue, Apr 07, 2015 at 13:16:04 +0200, Fabian Keil wrote:
 Kenneth D. Merry k...@freebsd.org wrote:
 
  On Mon, Apr 06, 2015 at 15:39:56 +0200, Fabian Keil wrote:
   Kenneth D. Merry k...@freebsd.org wrote:
   
I have put patches to add an asynchronous interface to the pass(4)
driver and add a new camdd(8) utility here:

FreeBSD/head as of SVN revision 280857:

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.
   
   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.
 [...] 
   I also tried to test camdd, but didn't get it to work.
   Some failed attempts:
   
   [fk@kendra ~]$ sudo camdd -i pass=da0,bs=65536 -o file=blafsel.img
   (pass2:umass-sim0:0:0:0): READ(6). CDB: 08 00 00 00 80 00 
   (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 
     55 53 42 53 d9 02 00 00  00 00 01 00 01
   |USBS.| 000d
   [fk@kendra ~]$ sudo dd if=/dev/da0 bs=1k count=1  | hd | head -n 1
   1+0 records in
   1+0 records out
   1024 bytes transferred in 0.000603 secs (1697756 bytes/sec)
     fc 31 c0 8e c0 8e d8 8e  d0 bc 00 0e be 1a 7c bf
   |.1|.|
  
  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.
  
  I've attached patches to camdd that allow you to specify a minimum
  command size.  So, apply the patches, rebuild camdd, and try this:
  
  # sudo camdd -i pass=da0,bs=65536,mcs=10 -o file=blafsel.img
  
  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=da0,bs=65536,mcs=10 -o file=blafsel.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

Did the file exist before running that command?  If so, camdd will look at
the file size and not write any more than the current file size.  If the
file doesn't exist, it'll stop writing when it reaches the end of the
input, or it gets a write error, or it reaches the specified I/O limit (-m
argument).

It also looks like there is a bug; the command above is attempting to read
0 bytes starting from one sector beyond the last logical block.


 [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.
 AA000958# 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=da0,bs=65536,mcs=10 -o file=-  
 /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

Ahh, yes, that is what I would expect.

 [fk@kendra ~]$ sudo dd if=/dev/da0 bs=65536 of=/dpool/scratch/blafasel-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) = 
 12d1d9e82f840a6c6485ffcdb1fbf780266ed266
 SHA1 (/dpool/scratch/blafasel.img) = 12d1d9e82f840a6c6485ffcdb1fbf780266ed266
 
 Looks good to me.

Great!  I'll see if I can fix the bug that is causing the zero length read
at the end.

Thank you for testing it!

Ken
-- 
Kenneth Merry
k...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: async pass(4) patches available

[Fabian Keil]

Kenneth D. Merry k...@freebsd.org wrote:

 On Tue, Apr 07, 2015 at 13:16:04 +0200, Fabian Keil wrote:
  Kenneth D. Merry k...@freebsd.org wrote:
  
   On Mon, Apr 06, 2015 at 15:39:56 +0200, Fabian Keil wrote:
Kenneth D. Merry k...@freebsd.org wrote:

 I have put patches to add an asynchronous interface to the
 pass(4) driver and add a new camdd(8) utility here:
 
 FreeBSD/head as of SVN revision 280857:
 
 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.

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.
  [...] 
I also tried to test camdd, but didn't get it to work.
Some failed attempts:

[fk@kendra ~]$ sudo camdd -i pass=da0,bs=65536 -o file=blafsel.img
(pass2:umass-sim0:0:0:0): READ(6). CDB: 08 00 00 00 80 00 
(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 
  55 53 42 53 d9 02 00 00  00 00 01 00 01
|USBS.| 000d
[fk@kendra ~]$ sudo dd if=/dev/da0 bs=1k count=1  | hd | head -n 1
1+0 records in
1+0 records out
1024 bytes transferred in 0.000603 secs (1697756 bytes/sec)
  fc 31 c0 8e c0 8e d8 8e  d0 bc 00 0e be 1a 7c bf
|.1|.|
   
   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.
   
   I've attached patches to camdd that allow you to specify a minimum
   command size.  So, apply the patches, rebuild camdd, and try this:
   
   # sudo camdd -i pass=da0,bs=65536,mcs=10 -o file=blafsel.img
   
   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=da0,bs=65536,mcs=10 -o
  file=blafsel.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
 
 Did the file exist before running that command?  If so, camdd will look
 at the file size and not write any more than the current file size.

That was probably it, at least I couldn't reproduce the problem
with a new file a few minutes ago:

[fk@kendra ~]$ sudo camdd -i pass=da0,bs=65536,mcs=10 -o 
file=/dpool/scratch/new-file.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 /dpool/scratch/new-file.img
127.3009 seconds elapsed
30.33 MB/sec

and with an existing file camdd indeed behaved like you described:

[fk@kendra ~]$ truncate -s 100 /dpool/scratch/small-file
[fk@kendra ~]$ sudo camdd -i pass=da0,bs=65536,mcs=10 -o 
file=/dpool/scratch/small-file  
(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
100 bytes written to /dpool/scratch/small-file
128.4956 seconds elapsed
0.00 MB/sec

 Thank you for testing it!

No problem.

Fabian


pgpH4scE603mK.pgp
Description: OpenPGP digital signature

Re: async pass(4) patches available

[Kenneth D. Merry]

On Mon, Apr 06, 2015 at 15:39:56 +0200, Fabian Keil wrote:
 Kenneth D. Merry k...@freebsd.org wrote:
 
  I have put patches to add an asynchronous interface to the pass(4) driver
  and add a new camdd(8) utility here:
  
  FreeBSD/head as of SVN revision 280857:
  
  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.
 
 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.
 
 Scrubbing a pool once revealed checksum errors which I haven't
 seen before:
 
 [fk@kendra ~]$ zpool status -v dpool
   pool: dpool
  state: ONLINE
 status: One or more devices has experienced an unrecoverable error.  An
 attempt was made to correct the error.  Applications are unaffected.
 action: Determine if the device needs to be replaced, and clear the errors
 using 'zpool clear' or replace the device with 'zpool replace'.
see: http://illumos.org/msg/ZFS-8000-9P
   scan: scrub repaired 0 in 1h52m with 0 errors on Thu Apr  2 13:01:44 2015
 config:
 
 NAME  STATE READ WRITE CKSUM
 dpool ONLINE   0 0 0
   gpt/dpool-ada0.eli  ONLINE   0 0 6
 
 errors: No known data errors
 
 Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): READ_FPDMA_QUEUED. ACB: 
 60 30 17 61 55 40 31 00 00 00 00 00
 Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): CAM status: ATA Status 
 Error
 Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): ATA status: 51 (DRDY 
 SERV ERR), error: 40 (UNC )
 Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): RES: 51 40 3e 61 55 40 
 31 00 00 00 00
 Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): Error 5, Retries 
 exhausted
 Apr  2 12:31:34 kendra kernel: GEOM_ELI: g_eli_read_done() failed 
 gpt/dpool-ada0.eli[READ(offset=414970949120, length=24576)]
 
 However the issue doesn't seem to be (easily) reproducible
 and could be unrelated.

It is unlikely that this is related to the pass(4) driver patches.  Possible,
but highly unlikely.  camdd(8) doesn't support ATA passthrough yet, so the
only way to access it with camdd is with the file I/O method.

 I also tried to test camdd, but didn't get it to work.
 Some failed attempts:
 
 [fk@kendra ~]$ sudo camdd -i pass=da0,bs=65536 -o file=blafsel.img
 (pass2:umass-sim0:0:0:0): READ(6). CDB: 08 00 00 00 80 00 
 (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 
   55 53 42 53 d9 02 00 00  00 00 01 00 01   |USBS.|
 000d
 [fk@kendra ~]$ sudo dd if=/dev/da0 bs=1k count=1  | hd | head -n 1
 1+0 records in
 1+0 records out
 1024 bytes transferred in 0.000603 secs (1697756 bytes/sec)
   fc 31 c0 8e c0 8e d8 8e  d0 bc 00 0e be 1a 7c bf  |.1|.|

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.

I've attached patches to camdd that allow you to specify a minimum command
size.  So, apply the patches, rebuild camdd, and try this:

# sudo camdd -i pass=da0,bs=65536,mcs=10 -o file=blafsel.img

We'll see if that helps.  I'm not sure why you were even able to get 13
bytes back.  That is very strange.

 Trying the block size suggested in the manual result in:
 
 [fk@kendra ~]$ sudo camdd -i pass=da0,bs=1M -o file=blafsel.img
 camdd: camdd_pass_run: error sending CAMIOQUEUE ioctl to pass2: Invalid 
 argument
 camdd: camdd_pass_run: CCB address is 0x80250e420: Invalid argument
 0 bytes read from pass2
 0 bytes written to blafsel.img
 0.0007 seconds elapsed
 0.00 MB/sec
 
 Apr  5 19:08:20 kendra kernel: (pass2:umass-sim0:0:0:0): passmemsetup: data 
 length 1048576  max allowed 65536 bytes
 

Yes.  By default, if you don't specify a blocksize, camdd(8) should limit
the I/O size to the controller's maximum or 128K, whichever is smaller.  If
you specify an I/O size, it will try to use that.

Thanks for testing the code, I really appreciate it!

Let me know how the patch works!

Ken
-- 
Kenneth Merry
k...@freebsd.org
 //depot/users/kenm/FreeBSD-test2/usr.sbin/camdd/camdd.8#1 - 
/usr/home/kenm/perforce4/kenm/FreeBSD-test2/usr.sbin/camdd/camdd.8 
*** /tmp/tmp.54366.13   Mon Apr  6 21:56:38 2015
--- /usr/home/kenm/perforce4/kenm/FreeBSD-test2/usr.sbin/camdd/camdd.8  Mon Apr 
 6 21:23:29 2015
***
*** 31,37 
  .\ 
  .\ $FreeBSD$
  .\
! .Dd March 13, 2015
  .Dt CAMDD 8
  .Os
  .Sh NAME
--- 31,37 
  .\ 
  .\ $FreeBSD$
  .\
! .Dd April 6, 2015
  .Dt CAMDD 8
  .Os
  

Re: async pass(4) patches available

[Fabian Keil]

Kenneth D. Merry k...@freebsd.org wrote:

 I have put patches to add an asynchronous interface to the pass(4) driver
 and add a new camdd(8) utility here:
 
 FreeBSD/head as of SVN revision 280857:
 
 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.

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.

Scrubbing a pool once revealed checksum errors which I haven't
seen before:

[fk@kendra ~]$ zpool status -v dpool
  pool: dpool
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://illumos.org/msg/ZFS-8000-9P
  scan: scrub repaired 0 in 1h52m with 0 errors on Thu Apr  2 13:01:44 2015
config:

NAME  STATE READ WRITE CKSUM
dpool ONLINE   0 0 0
  gpt/dpool-ada0.eli  ONLINE   0 0 6

errors: No known data errors

Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): READ_FPDMA_QUEUED. ACB: 60 
30 17 61 55 40 31 00 00 00 00 00
Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): CAM status: ATA Status 
Error
Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): ATA status: 51 (DRDY SERV 
ERR), error: 40 (UNC )
Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): RES: 51 40 3e 61 55 40 31 
00 00 00 00
Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): Error 5, Retries exhausted
Apr  2 12:31:34 kendra kernel: GEOM_ELI: g_eli_read_done() failed 
gpt/dpool-ada0.eli[READ(offset=414970949120, length=24576)]

However the issue doesn't seem to be (easily) reproducible
and could be unrelated.

I also tried to test camdd, but didn't get it to work.
Some failed attempts:

[fk@kendra ~]$ sudo camdd -i pass=da0,bs=65536 -o file=blafsel.img
(pass2:umass-sim0:0:0:0): READ(6). CDB: 08 00 00 00 80 00 
(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 
  55 53 42 53 d9 02 00 00  00 00 01 00 01   |USBS.|
000d
[fk@kendra ~]$ sudo dd if=/dev/da0 bs=1k count=1  | hd | head -n 1
1+0 records in
1+0 records out
1024 bytes transferred in 0.000603 secs (1697756 bytes/sec)
  fc 31 c0 8e c0 8e d8 8e  d0 bc 00 0e be 1a 7c bf  |.1|.|

Trying the block size suggested in the manual result in:

[fk@kendra ~]$ sudo camdd -i pass=da0,bs=1M -o file=blafsel.img
camdd: camdd_pass_run: error sending CAMIOQUEUE ioctl to pass2: Invalid argument
camdd: camdd_pass_run: CCB address is 0x80250e420: Invalid argument
0 bytes read from pass2
0 bytes written to blafsel.img
0.0007 seconds elapsed
0.00 MB/sec

Apr  5 19:08:20 kendra kernel: (pass2:umass-sim0:0:0:0): passmemsetup: data 
length 1048576  max allowed 65536 bytes

Fabian


pgpzmTviVSYQN.pgp
Description: OpenPGP digital signature

Re: async pass(4) patches available

[Konstantin Belousov]

On Tue, Mar 31, 2015 at 04:50:51PM -0600, Kenneth D. Merry wrote:
 On Tue, Mar 31, 2015 at 03:49:12 +0300, Konstantin Belousov wrote:
  On Mon, Mar 30, 2015 at 04:23:58PM -0600, Kenneth D. Merry wrote:
   Kernel memory for data transferred via the queued interface is 
   allocated from the zone allocator in MAXPHYS sized chunks, and user
   data is copied in and out.  This is likely faster than the
   vmapbuf()/vunmapbuf() method used by the CAMIOCOMMAND ioctl in
   configurations with many processors (there are more TLB shootdowns
   caused by the mapping/unmapping operation) but may not be as fast
   as running with unmapped I/O.
  cam_periph_mapmem() uses vmapbuf() with an indicator to always map the
  user pages mostly because I do not know CAM code and wanted to make
  the least intrusive changes there.  It is not inherently impossible
  to pass unmapped pages down from cam_periph_mapmem(), but might
  require some more plumbing for driver to indicate that it is acceptable.
 
 I think that would probably not be too difficult to change.  That API isn't
 one that is exposed, so changing it shouldn't be a problem.  The only
 reason not to do unmapped I/O there is just if the underlying controller
 doesn't support it.  The lower parts of the stack shouldn't be trying to
 sniff the data that is read or written to the device, although that has
 happened in the past.  We'd have to audit a couple of the drivers to
 make sure they aren't trying to access the data.
This is why I mentioned 'plumbing' required to map pages when needed.

 
   The new memory handling model for user requests also allows
   applications to send CCBs with request sizes that are larger than
   MAXPHYS.  The pass(4) driver now limits queued requests to the I/O
   size listed by the SIM driver in the maxio field in the Path
   Inquiry (XPT_PATH_INQ) CCB.
   
   There are some things things would be good to add:
   
   1. Come up with a way to do unmapped I/O on multiple buffers.
  Currently the unmapped I/O interface operates on a struct bio,
  which includes only one address and length.  It would be nice
  to be able to send an unmapped scatter/gather list down to
  busdma.  This would allow eliminating the copy we currently do
  for data.
  Only because nothing more was needed.  The struct bio does not use
  address/length pair when unmapped, it passes the list of physical
  pages, see bio_ma array pointer.  It is indeed taylored to be a pointer
  to struct buf' b_pages, but it does not have to be.
  
  The busdma unmapped non-specific interface is bus_dmamap_load_ma(),
  which again takes array of pages to load.  If you want some additional
  helper, suitable for your goals, please provide the desired interface
  definition.
 
 What I'd like to be able to do is pass down a CCB with a user virtual
 S/G list (CAM_DATA_SG, but with user virtual pointers) and have busdma deal
 with it.
Is there an existing definition of the 'user s/g list' ?  Some structure,
or existing example of use ?

 
 The trouble would likely be figuring out a flag to use to indicate that the
 S/G list in question contains user virtual pointers.  (Backwards/binary
 compatibility is always an issue with CCB flags, since they have all been
 used.)
 
 But that is essentially what is needed.  
 

I can write the code, but I need API specification.  Also, ideally I need
a rough example which uses the API.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: async pass(4) patches available

[Kenneth D. Merry]

On Tue, Mar 31, 2015 at 03:49:12 +0300, Konstantin Belousov wrote:
 On Mon, Mar 30, 2015 at 04:23:58PM -0600, Kenneth D. Merry wrote:
  Kernel memory for data transferred via the queued interface is 
  allocated from the zone allocator in MAXPHYS sized chunks, and user
  data is copied in and out.  This is likely faster than the
  vmapbuf()/vunmapbuf() method used by the CAMIOCOMMAND ioctl in
  configurations with many processors (there are more TLB shootdowns
  caused by the mapping/unmapping operation) but may not be as fast
  as running with unmapped I/O.
 cam_periph_mapmem() uses vmapbuf() with an indicator to always map the
 user pages mostly because I do not know CAM code and wanted to make
 the least intrusive changes there.  It is not inherently impossible
 to pass unmapped pages down from cam_periph_mapmem(), but might
 require some more plumbing for driver to indicate that it is acceptable.

I think that would probably not be too difficult to change.  That API isn't
one that is exposed, so changing it shouldn't be a problem.  The only
reason not to do unmapped I/O there is just if the underlying controller
doesn't support it.  The lower parts of the stack shouldn't be trying to
sniff the data that is read or written to the device, although that has
happened in the past.  We'd have to audit a couple of the drivers to
make sure they aren't trying to access the data.

  The new memory handling model for user requests also allows
  applications to send CCBs with request sizes that are larger than
  MAXPHYS.  The pass(4) driver now limits queued requests to the I/O
  size listed by the SIM driver in the maxio field in the Path
  Inquiry (XPT_PATH_INQ) CCB.
  
  There are some things things would be good to add:
  
  1. Come up with a way to do unmapped I/O on multiple buffers.
 Currently the unmapped I/O interface operates on a struct bio,
 which includes only one address and length.  It would be nice
 to be able to send an unmapped scatter/gather list down to
 busdma.  This would allow eliminating the copy we currently do
 for data.
 Only because nothing more was needed.  The struct bio does not use
 address/length pair when unmapped, it passes the list of physical
 pages, see bio_ma array pointer.  It is indeed taylored to be a pointer
 to struct buf' b_pages, but it does not have to be.
 
 The busdma unmapped non-specific interface is bus_dmamap_load_ma(),
 which again takes array of pages to load.  If you want some additional
 helper, suitable for your goals, please provide the desired interface
 definition.

What I'd like to be able to do is pass down a CCB with a user virtual
S/G list (CAM_DATA_SG, but with user virtual pointers) and have busdma deal
with it.

The trouble would likely be figuring out a flag to use to indicate that the
S/G list in question contains user virtual pointers.  (Backwards/binary
compatibility is always an issue with CCB flags, since they have all been
used.)

But that is essentially what is needed.  

Ken
-- 
Kenneth Merry
k...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: async pass(4) patches available

[Konstantin Belousov]

On Mon, Mar 30, 2015 at 04:23:58PM -0600, Kenneth D. Merry wrote:
 Kernel memory for data transferred via the queued interface is 
 allocated from the zone allocator in MAXPHYS sized chunks, and user
 data is copied in and out.  This is likely faster than the
 vmapbuf()/vunmapbuf() method used by the CAMIOCOMMAND ioctl in
 configurations with many processors (there are more TLB shootdowns
 caused by the mapping/unmapping operation) but may not be as fast
 as running with unmapped I/O.
cam_periph_mapmem() uses vmapbuf() with an indicator to always map the
user pages mostly because I do not know CAM code and wanted to make
the least intrusive changes there.  It is not inherently impossible
to pass unmapped pages down from cam_periph_mapmem(), but might
require some more plumbing for driver to indicate that it is acceptable.

 
 The new memory handling model for user requests also allows
 applications to send CCBs with request sizes that are larger than
 MAXPHYS.  The pass(4) driver now limits queued requests to the I/O
 size listed by the SIM driver in the maxio field in the Path
 Inquiry (XPT_PATH_INQ) CCB.
 
 There are some things things would be good to add:
 
 1. Come up with a way to do unmapped I/O on multiple buffers.
Currently the unmapped I/O interface operates on a struct bio,
which includes only one address and length.  It would be nice
to be able to send an unmapped scatter/gather list down to
busdma.  This would allow eliminating the copy we currently do
for data.
Only because nothing more was needed.  The struct bio does not use
address/length pair when unmapped, it passes the list of physical
pages, see bio_ma array pointer.  It is indeed taylored to be a pointer
to struct buf' b_pages, but it does not have to be.

The busdma unmapped non-specific interface is bus_dmamap_load_ma(),
which again takes array of pages to load.  If you want some additional
helper, suitable for your goals, please provide the desired interface
definition.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org