Re: nanobsd / dd problem?

On Mon, Dec 09, 2013 at 06:42:39AM +0200, Konstantin Belousov wrote:
> On Sun, Dec 08, 2013 at 06:31:36PM +0100, Stefan Hegnauer wrote:
> > Hi,
> > 
> >  
> > 
> > I am using freebsd-current (FreeBSD BUILDMASTER 11.0-CURRENT FreeBSD
> > 11.0-CURRENT #0 r259095: Sun Dec  8 10:20:40 CET 2013
> > root_at_BUILDMASTER:/usr/obj/usr/src/sys/ASUS  i386) in a VirtualBox as a build
> > machine for nanobsd images to be used on pc-engines.ch alix boards. The only
> > difference to GENERIC is the inclusion of 'march=geode' and disabling of
> > most debugging switches (malloc, Witness etc). Worked like a charm in the
> > past.
> > 
> >  
> > 
> > Since late summer - sorry, no exact date / svn revision - nanobsd.sh fails
> > at the last stage when building the disk image, e.g. with
> > 
> > ...
> > 
> > 00:00:25 ### log: /usr/obj/nanobsd.alixpf//_.di
> > 
> > #
> > 
> >  
> > 
> > Looking a bit closer it seems that dd(1) returns with an I/O error whenever
> > the input is a file created with mdconfig(8):
> > 
> > # dd if=/dev/zero of=somebackingfile bs=1k count=5k
> > 
> > # mdconfig -f somebackingfile -u md0
> > 
> > # newfs -U /dev/md0
> > 
> > # dd if=/dev/md0 of=/dev/null
> > 
> > dd: /dev/md0: Input/output error
> > 
> > 10241+0 records in
> > 
> > 10241+0 records out
> > 
> > 5243392 bytes transferred in 3.240345 secs (1618159 bytes/sec)
> > 
> >  
> > 
> > The outputfile in nanobsd.sh seems to be error-free.
> It should be one block larger than the right size.
> \
> > 
> > Anyone else seen similar behaviour? How to proceed/fix it?
> > 
> 
> The following patch should clear the error.
> 
> The issue is that kern_physio() incorrectly detects EOF due to incorrect
> calculation of bio bio_resid after the bio_length was clipped by the
> 'excess' code in g_io_check(). Both bio_length and bio_resid appear
> to be 0 in the pre-last dd transfer, which starts exactly and the
> mediasize, and kern_physio() thinks that it transferred one more block
> than was transferred.
> 
> I _suspect_ that it was caused by 'excess' code moving in r256880,
> but I am really not in the right condition to analyze it.  If somebody
> could try the same dd experiment to confirm or deny my suspicion, it
> would be useful.
> 
> The patch below should be a right thing to do anyway.
> 
> diff --git a/sys/kern/vfs_bio.c b/sys/kern/vfs_bio.c
> index c23a74b..b7c4d60 100644
> --- a/sys/kern/vfs_bio.c
> +++ b/sys/kern/vfs_bio.c
> _at__at_ -3679,7 +3679,6 _at__at_ bufdonebio(struct bio *bip)
>  
>  	bp = bip->bio_caller2;
>  	bp->b_resid = bp->b_bcount - bip->bio_completed;
> -	bp->b_resid = bip->bio_resid;	/* XXX: remove */
>  	bp->b_ioflags = bip->bio_flags;
>  	bp->b_error = bip->bio_error;
>  	if (bp->b_error)

I have tested this patch with a buildworld + selected other tests. No
problems seen (and problem fixed, of cause).

- Peter