From nobody  Sun Feb 14 07:08:20 1999
Received: (from nobody@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id HAA04728;
          Sun, 14 Feb 1999 07:08:20 -0800 (PST)
          (envelope-from nobody)
Message-Id: <199902141508.HAA04728@hub.freebsd.org>
Date: Sun, 14 Feb 1999 07:08:20 -0800 (PST)
From: remy@synx.com
To: freebsd-gnats-submit@freebsd.org
Subject: dd'ing a ccd stripped partition sometimes hangs in physstr.
X-Send-Pr-Version: www-1.0

>Number:         10077
>Category:       kern
>Synopsis:       dd'ing a ccd stripped partition sometimes hangs in physstr.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    dillon
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Feb 14 07:10:00 PST 1999
>Closed-Date:    Wed Sep 29 09:53:46 PDT 1999
>Last-Modified:  Wed Sep 29 09:55:09 PDT 1999
>Originator:     Remy Nonnenmacher
>Release:        3.0 (various brands)
>Organization:
Synchronix
>Environment:
FreeBSD rn.synx.com 3.0-971012-SNAP FreeBSD 3.0-971012-SNAP
FreeBSD gate3.synx.com 3.0-STABLE FreeBSD 3.0-STABLE
FreeBSD fs2.synx.com 3.0-971225-SNAP FreeBSD 3.0-971225-SNAP
FreeBSD bench18.synx.com 3.0-19980804-SNAP
etc....
>Description:
When dd'ing a partition constituted of two stripped disks via ccd,
the dd process hangs in state 'physstr' when it reaches the end of the partition
in some cases.

Exemple : (dd if=/dev/rccd...bs=<bssize>)

 - two disks partitions each of 8914935 blocks, strip size 32
	hang on any bssize (even 512)

 - two disks partitions each of 4102272 blocks, strip size 32
	OK on any bssize

 - two disks partitions each of 15733520 blocks, strip size 32
	OK on any bssize

 - two disks partitions each of 17829870 blocks, strip size 32
	OK for bssize 512 and 1K
	hang for bssize 2K or more

Filesystem accesses or always OK (probably since filesystem relies on
logical boundings created at newfs time).

Not really a problem but a little cleanup there would be nice...
(even a little warning note in ccd(4) would be OK)
Thanks for your work.

>How-To-Repeat:
- build a ccd strip, then dd if=/dev/rccd.. of=/dev/null bs=XX
- Enjoy with various bs values...


>Fix:
(Sorry, lost myself in all bounds checkings, labels, partitions
and various offsets constants. Can't help).

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: sheldonh 
State-Changed-When: Tue Jun 22 05:08:57 PDT 1999 
State-Changed-Why:  
I think this is either a problem with dd's handling of large structures 
or a known problem with dd reading past the end of a device. To rule out 
the former, could you try with Brian Feldman's recent type fixes to 
dd, committed to CURRENT on 10077 
(sorry, not 10077) 1999/06/19 12:49:37 PDT? 
State-Changed-From-To: feedback->open 
State-Changed-By: sheldonh 
State-Changed-When: Tue Jun 22 06:16:54 PDT 1999 
State-Changed-Why:  
As the submitter points out, the process hangs in kernel, so Brian's 
dd type fixes have nothing to do with this. Back to the drawing board. 
Responsible-Changed-From-To: freebsd-bugs->sheldonh 
Responsible-Changed-By: sheldonh 
Responsible-Changed-When: Tue Aug 10 05:58:02 PDT 1999 
Responsible-Changed-Why:  
I've added this one to my list. 

From: Tor.Egge@fast.no
To: sheldonh@FreeBSD.ORG
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/10077: dd'ing a ccd stripped partition sometimes hangs in physstr.
Date: Wed, 18 Aug 1999 04:33:57 +0200

 The ccd driver assumes that the request size is constant in order
 for bp->b_resid to become 0 when all requests havve been completed.
 This is not always true, since dscheck might truncate one or more
 of the requests fired off by ccdstart.
 
 ccd must either perform some bounds checks or handle truncation
 of requests by the underlying devices.
 
 Index: sys/dev/ccd/ccd.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/dev/ccd/ccd.c,v
 retrieving revision 1.52
 diff -u -r1.52 ccd.c
 --- ccd.c	1999/08/14 11:40:34	1.52
 +++ ccd.c	1999/08/18 02:29:34
 @@ -739,9 +739,22 @@
  	 * error, the bounds check will flag that for us.
  	 */
  	wlabel = cs->sc_flags & (CCDF_WLABEL|CCDF_LABELLING);
 -	if (ccdpart(bp->b_dev) != RAW_PART)
 +	if (ccdpart(bp->b_dev) != RAW_PART) {
  		if (bounds_check_with_label(bp, lp, wlabel) <= 0)
  			goto done;
 +	} else if (bp->b_blkno < 0 ||
 +		   bp->b_blkno + (bp->b_bcount >> DEV_BSHIFT) > cs->sc_size) {
 +		if (bp->b_blkno == cs->sc_size) {
 +			bp->b_resid = bp->b_bcount;
 +			goto done;
 +		}
 +		if (bp->b_blkno < 0 || bp->b_blkno > cs->sc_size) {
 +			bp->b_error = EINVAL;
 +			bp->b_flags |= B_ERROR;
 +			goto done;
 +		}
 +		bp->b_bcount = (cs->sc_size - bp->b_blkno) << DEV_BSHIFT;
 +	}
  
  	bp->b_resid = bp->b_bcount;
  
 
 
 - Tor Egge
 
 

From: Sheldon Hearn <sheldonh@uunet.co.za>
To: Remy Nonnenmacher <remy@synx.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/10077: dd'ing a ccd stripped partition sometimes hangs in physstr. 
Date: Wed, 18 Aug 1999 14:03:52 +0200

 Hi Remy,
 
 Could you test out Tor's patch and provide us with feedback once you've
 had it in place for a while?
 
 Thanks,
 Sheldon.
 

From: Remy Nonnenmacher <remy@synx.com>
To: FreeBSD-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/10077: dd to a ccd hangs
Date: Mon, 30 Aug 1999 14:59:42 +0200 (CEST)

 On 30 Aug, Sheldon Hearn wrote:
 > 
 > Hi Remy,
 > 
 > Any feedback on Tor's patch for the problem with dd which you reported
 > on PR 10077?
 > 
 > Ciao,
 > Sheldon.
 
 Hello Sheldon,
 
 I'm just back from hollydays. Allow me two-three days to recover and
 i'll build a test machine.
 
 Please remind me if you have not got a reply by end of this week...
 
 Thanks for all.
 
 RN.
 
 IaM
 
 
 
Responsible-Changed-From-To: sheldonh->dillon 
Responsible-Changed-By: sheldonh 
Responsible-Changed-When: Wed Sep 29 07:00:29 PDT 1999 
Responsible-Changed-Why:  
Matt's been busy with ccd. I've sent him private mail. 
State-Changed-From-To: open->closed 
State-Changed-By: dillon 
State-Changed-When: Wed Sep 29 09:53:46 PDT 1999 
State-Changed-Why:  
Tor's patch has been committed, along with many other changes since 3.0 
which should hopefully solve the lockups-on-EOF problems with ccd. 
>Unformatted:
