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