| > panic: sdstart(): dequeued wrong buf
| > Begin traceback...
| > sdstart(c1aa9f00,c1a73080,0,4,0) at netbsd:sdstart+0x2ea
| > sdstrategy(c1a73080,0,80,0,0) at netbsd:sdstrategy+0x1db
| > spec_strategy(cc927874,cc8771f8,100000,404,c05229a0) at  
| > netbsd:spec_strategy+0x155
| > VOP_STRATEGY(cc8771f8,c1a73080,cc92791c,293,72) at  
| > netbsd:VOP_STRATEGY+0x28
| > rf_DispatchKernelIO(c1a20000,c1ae5074,1,0,3ddcbf) at  
| > netbsd:rf_DispatchKernelIO+0x28b
| 
|  Juergen Hannken-Illjes has reported in private mail a similar problem,
|  on sparc64 without raidframe or ccd involved.

  The traceback looks somewhat familiar, I get -- without using RF
but with an icp raid controller:

_bus_dmamap_load(c075a100,0,c4d0a000,2000,0) at netbsd:_bus_dmamap_load+0xf
icp_ccb_map(c0d1000,c0db8000,c4d0a000,2000,2) at netbsd:icp_ccb_map+0x35
ld_icp_dobio
ld_icp_start
ldstart
ldstrategy
spec_strategy
VOP_STRATEGY
ufs_strategy
VOP_STRATEGY

  I opened a PR for it, #26819

|  Both you and Juergen use the esiop driver, and this driver can call
|  scsipi_done() from esiop_scsipi_request(). This can likely cause sdstart() to
|  call itself. Other HBA drivers may do this as well.

  See above, I'm using an icp controller. Seems like a well-spread
behaviour.

	mjl