Subject: Re: Disk IO / UVM and Crypt FS..
To: Jaromir Dolecek <jdolecek@netbsd.org>
From: Jorgen Lundman <lundman@lundman.net>
List: tech-kern
Date: 05/08/2002 12:56:06
Apologise, it's "M_ZERO" which I am guessing just means malloc() clears 
the memory as well? If it is, I'm guessing it shouldn't affect ccd more 
than be somewhat more efficient.


Full trace follows:

db> trace
ccd_encode(c0c31000,c0cc105c,1) at ccd_encode+0x83
ccdstart(c0c31000,c0c3b0d0) at ccdstart+0x18e
ccdstrategy(c0c3b0d0,c0c3b0d0,d7d72c08,c02577a2,d7d72c14) at 
ccdstrategy+0x116
spec_strategy(d7d72c14,c0c3b0d0,b30,0,d7d75894) at spec_strategy+0x47
ufs_strategy(d7d72c14,c04cbe00,c0c3b0d0,d7d2ca0,c02ab35c) at 
ufs_strategy+0xae
VOP_STRATEGY(c0c3b0d0) at VOP_STRATEGY+0x28
genfs_gop_write(d7d7a180,d7d72cb8,3,11,c0821cfc) at genfs_gop_write+0x334
genfs_putpages(d7d72dec,d7d7a180,d7d77008,d7d7a180,c04cc9e0) at 
genfs_putpages+0x774
VOP_PUTPAGES(d7d7a180,0,0,0,0,11) at VOP_PUTPAGES+0x46
ffs_full_fsync(d7d72ed4,d7d7a180,d7d77008,0,d7cd1650) at ffs_full_fsync+0x89
ffs_fsync(d7d72ed4,d7d7a180,d7d7a0e8,c0c97800,c04cc240) at ffs_fsync+0x3a
VOP_FSYNC(d7d7a180,c0c94800,0,0,0,0,0,d7d77008) at VOP_FSYNC+0x52
ffs_sync(c0ca1000,2,c0c94800,d7d77008) at ffs_sync+0xc3
sys_sync(d7d77008,d7d72f80,d7d72f78) at sys_sync+0x56
syscall_plain(1f,1f,1f,1f,bfbfdff0) at syscall_plain+0x98


Phew, hopefully I didn't make too many typo's.

If you are curious what I do, codewise, in ccd_encode, the fragments 
look like:

void ccd_encode(struct ccd_softc *ccd, struct buf *bp, int encrypt);

unsigned char *ptr;
ptr = (unsigned char *) bp->b_data;

                         for (i = 0; i < bp->b_bcount; i++)
                                 ptr[i] ^= 0x20;


Lund





Jaromir Dolecek wrote:
> Jorgen Lundman wrote:
> 
>>fjord# sync
>>May  2 03:27:43 fjord /netbsd: ccd_encode(0xc4b33000, 8192, 2928)
>>uvm_fault(0xc063ef00, 0xcb33000, 0, 2) -> e
>>kernel: page fault trap, code=0
>>Stopped in pid 819 (sync) at   ccd_encode+0x83:   xorb   %al,    0(%edx)
>>db>
> 
> 
> Full traceback could be useful here.
> 
> 
>>[1] - Some clean up done, removed M_CLEAR from most malloc calls etc. 
>>"Shouldn't" affect it?
> 
> 
> What is M_CLEAR?
> 
> Jaromir


-- 
Jorgen "Lord" Lundman <lundman@lundman.net>
Technology Manager, Unix Administrator
Phone: +44 (0)20-86591860  Mobile: +44 (0)79-58642918
Pager: 07958642918@one2one.net
"Rare is the person who can weigh the faults of others
  without putting his thumb on the scales": Byron J. Langenfeld