From owner-freebsd-ports-bugs@freebsd.org Fri Aug 10 08:03:21 2018 Return-Path: Delivered-To: freebsd-ports-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0691810613CA for ; Fri, 10 Aug 2018 08:03:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 96D827E504 for ; Fri, 10 Aug 2018 08:03:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5B92010613C9; Fri, 10 Aug 2018 08:03:20 +0000 (UTC) Delivered-To: ports-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3955510613C8 for ; Fri, 10 Aug 2018 08:03:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C8D3E7E500 for ; Fri, 10 Aug 2018 08:03:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id E495B22AF9 for ; Fri, 10 Aug 2018 08:03:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w7A83IFG075971 for ; Fri, 10 Aug 2018 08:03:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w7A83I4a075970 for ports-bugs@FreeBSD.org; Fri, 10 Aug 2018 08:03:18 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 230493] sysutils/dvd+rw-tools: Cannot append data to BD-R DL used more than 25gb Date: Fri, 10 Aug 2018 08:03:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: scdbackup@gmx.net X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ports-bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ merge-quarterly? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 08:03:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230493 scdbackup@gmx.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |scdbackup@gmx.net --- Comment #5 from scdbackup@gmx.net --- Hi, ports r383719 / Ubuntu 1113679 is about a differnt bug, which caused an inappropriate command to be sent to the drive and consequentially an error reoly by the drive and an error message by growisofs. The mistake was that the BD-R was formatted automatically but growisofs still memorized the unformatted state. About the bug discussed here (Debian 615978): nwa =3D 0; if (buf[7]&1 && !bdr_plus_pow) // NWA_V { nwa =3D buf[12]<<24; nwa |=3D buf[13]<<16; nwa |=3D buf[14]<<8; nwa |=3D buf[15]; } free_blocks =3D buf[16]<<24; free_blocks |=3D buf[17]<<16; free_blocks |=3D buf[18]<<8; free_blocks |=3D buf[19]; ret =3D nwa + free_blocks; This obviously is meant to compute the total capacity of the medium, as sum of the effectively consumed blocks (Next Writable Address, NWA) and of the free blocks. Andy Polyakov expected the whole media capacity to be reported by the Free Blocks field of the drive's reply, because the BD-R is in state Pseudo-Overwrite, where all addresses are valid for writing. But the fact that the NWA_V bit in buf[7] is set announces a valid NWA and thus indicates that the drive does not count all blocks as free. --------------------------------------------------------------------- The only riddle that remains is why this bug is reported only with BD-R DL. MMC-5 4.5.3.6.4 gives an example which does not match the code neither with the fix nor without it. But the example situation differs somewhat from growisofs' doings. If i mentally move it towards growisofs, then the fixed code seems more plausible. All in all Pseudo-Overwrite is complicated and based on the mechanisms of Defect Management, which do not work very well when actually needed. I have a single-layer POW BD-R for testing purposes (so libburn-1.4.8 can refuse to write onto it). Indeed the drive reports to libburn for its "invisible" track a track description which would match the unfixed code: $ xorriso -scsi_log on -outdev /dev/cd0 ... READ TRACK INFORMATION 52 01 00 00 00 01 00 00 14 00=20 From drive: 20b 00 26 01 01 00 04 61 01 00 00 00 00 00 00 00 00 00 b4 74 00 5783 us [ 5021775 ] ... buf[7] is 0x01 here, NWA is 0x00000000, Free Blocks is 0x00b47400 =3D 11826176, which matches READ CAPACITY 0x00b473ff =3D 11826175. So for this medium, the unfixed code would work. The fixed code would work too, because NWA is 0. I failed yet to read from MMC specs that BD-R DL shall bevave different from BD-R. The statement of growisofs: builtin_dd of=3D/dev/pass1 obs=3D32k seek=3D1057160 indicates that the burn run was to start at block 16*1057160 =3D 16,914,560 which is already in the second layer. Have a nice day :) Thomas --=20 You are receiving this mail because: You are the assignee for the bug.=