The following reply was made to PR kern/36878; it has been noted by GNATS.

From: Greg Oster <oster@cs.usask.ca>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/36878: overflow in raidframe parity rebuild status 
Date: Mon, 03 Sep 2007 11:30:52 -0600

 dieter.NetBSD@pandora.be writes:
 > >Number:         36878
 > >Category:       kern
 > >Synopsis:       overflow in raidframe parity rebuild status
 > >Confidential:   no
 > >Severity:       non-critical
 > >Priority:       medium
 > >Responsible:    kern-bug-people
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Sat Sep 01 13:50:00 +0000 2007
 > >Originator:     Dieter Roelants
 > >Release:        NetBSD 4.0_BETA2
 > >Organization:
 > >Environment:
 > System: NetBSD bsdusr.net 4.0_BETA2 NetBSD 4.0_BETA2 (GENERIC) #0: Tue Aug 28
 >  12:16:38 CEST 2007 dieter@simult.amelgem.be:/build/obj.amd64.4/sys/arch/amd6
 > 4/compile/GENERIC amd64
 > Architecture: x86_64
 > Machine: amd64
 > >Description:
 > 	When rebuilding the parity of a RAID set, it can happen
 > 	that querying the status of this process returns a (large)
 > 	negative percentage.
 >
 > >How-To-Repeat:
 > 	Build a RAID set which is either large enough or has a low
 > 	number of sectors per stripe unit. Check the status with
 > 	raidctl -s while the parity is being written.
 
 I'm trying to figure out how this can happen....  all the variables 
 in use should be 64-bit quantities....  I know there used to be some 
 isuses with this, but I'm sure 4.0_BETA2 has those fixes in it... 
 
 > >Fix:
 > 
 > I have 2 patches. The first one is only cosmetic, it wraps a long
 > line, and unnests some conditions. The second changes the way the
 > percentage is calculated when there is a possibility of overflowing
 
 Does casting things to RF_uint64 fix the issue without having to do 
 the (1<<24) stuff?  e.g. one shouldn't need to, but does:
 
   *(int *) data = (RF_uint64) 100 *
 				raidPtr->reconControl->numRUsComplete /
 				raidPtr->reconControl->numRUsTotal;
 
 behave any differently? 
 
 Later...
 
 Greg Oster