Date: Mon, 9 Dec 2013 06:42:39 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Stefan Hegnauer <stefan.hegnauer@gmx.ch> Cc: mav@freebsd.org, freebsd-current@freebsd.org Subject: Re: nanobsd / dd problem? Message-ID: <20131209044239.GS59496@kib.kiev.ua> In-Reply-To: <52a4ad05.892ee50a.41cd.084aSMTPIN_ADDED_BROKEN@mx.google.com> References: <52a4ad05.892ee50a.41cd.084aSMTPIN_ADDED_BROKEN@mx.google.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Qwua2IE5osIB7M43 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 08, 2013 at 06:31:36PM +0100, Stefan Hegnauer wrote: > Hi, >=20 > =20 >=20 > 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@BUILDMASTER:/usr/obj/usr/src/sys/ASUS i386) in a VirtualBox as a bu= ild > machine for nanobsd images to be used on pc-engines.ch alix boards. The o= nly > difference to GENERIC is the inclusion of 'march=3Dgeode' and disabling of > most debugging switches (malloc, Witness etc). Worked like a charm in the > past. >=20 > =20 >=20 > Since late summer - sorry, no exact date / svn revision - nanobsd.sh fails > at the last stage when building the disk image, e.g. with >=20 > ... >=20 > 00:00:25 ### log: /usr/obj/nanobsd.alixpf//_.di >=20 > # >=20 > =20 >=20 > Looking a bit closer it seems that dd(1) returns with an I/O error whenev= er > the input is a file created with mdconfig(8): >=20 > # dd if=3D/dev/zero of=3Dsomebackingfile bs=3D1k count=3D5k >=20 > # mdconfig -f somebackingfile -u md0 >=20 > # newfs -U /dev/md0 >=20 > # dd if=3D/dev/md0 of=3D/dev/null >=20 > dd: /dev/md0: Input/output error >=20 > 10241+0 records in >=20 > 10241+0 records out >=20 > 5243392 bytes transferred in 3.240345 secs (1618159 bytes/sec) >=20 > =20 >=20 > The outputfile in nanobsd.sh seems to be error-free. It should be one block larger than the right size. \ >=20 > Anyone else seen similar behaviour? How to proceed/fix it? >=20 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 @@ -3679,7 +3679,6 @@ bufdonebio(struct bio *bip) =20 bp =3D bip->bio_caller2; bp->b_resid =3D bp->b_bcount - bip->bio_completed; - bp->b_resid =3D bip->bio_resid; /* XXX: remove */ bp->b_ioflags =3D bip->bio_flags; bp->b_error =3D bip->bio_error; if (bp->b_error) --Qwua2IE5osIB7M43 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSpUo+AAoJEJDCuSvBvK1BsRgP+wd0KK76PjGbHPLm4fBUaHEW oyf8ZqMd1GcUYU4hQjRX8ibOooVCqFwTE+GqdIEoum1mWYOaXPYvHgG+adT6QTV+ ylV+gyc+BilaUcfwR6yC4xLLTK8aMN3J8i9b/Ek5bPM0g1XseLou7Kmh5fkpM0ft 8CRrsmBaTOesJYhiHwvTaJiawBqO8+XyJcJTvZQAeyvhj0uYXj235hhbMiBb0Ta8 +HYO8Y0hEvcZGThg6K45Cd1cbpRZcHRsPniAxatl4W1buTw9sVGDHS7HPWmDBJfM 0OGq6CZPUyPPXqQZ7WpOk8HP68MpAZmqgORJBf9/asVKAtsE+5GzGndgjUmveyPW TfgEiAqc08SNfOLP9l0WineL1BWu1kMui/HU2vvdwGR3zN/aGPs8oEX13FwFj+5s etCkWGKDu3kKfUOqAzR9PNSrzotsCsdMFLb3uvFdFZeqDpUjX6tmDdeuRIxW2HfK 3q5IdH/GIE4XDe1qIhM7R2wCfdxN5aHa+0i6qTMRrSyRFoO4wCXQCCbnZqTozEdD qrW43dUVUNfRUxMK2qfhwNDktQJVtlEYCodWQx+P1GBMgMHX9LdA47ok4EDhxW3H mUjwkNocUpvvJq1H7p2Bm2YBbTNozqJR+1+DLDOWdDxHHBVRZ5TmIck99qBBJJZz /hCVqer6aHUAAXiT1b4Z =YqvJ -----END PGP SIGNATURE----- --Qwua2IE5osIB7M43--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131209044239.GS59496>