On Tue, Sep 07, 2004 at 10:30:15AM +0000, Martin J. Laubach wrote:
> | > 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

I think this is a completely different problem. Here, the problem is that
I made some changes to sdstart() and now it's not reentrant.
I think your problem is completely different (you're not even using the
sd(4) driver).

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
     NetBSD: 24 ans d'experience feront toujours la difference
--