Date: Tue, 27 Nov 2001 22:21:09 -0700 From: "Kenneth D. Merry" <ken@kdm.org> To: Christoph Herrmann <C.Herrmann@science-computing.de> Cc: current@FreeBSD.ORG Subject: Re: cdrecord produces broken CDs on -CURRENT Message-ID: <20011127222108.A18996@panzer.kdm.org> In-Reply-To: <Pine.BSF.4.21.0111270837240.49965-100000@scmsrv1.science-computing.de>; from C.Herrmann@science-computing.de on Tue, Nov 27, 2001 at 09:06:48AM %2B0100 References: <20011126133027.A5112@panzer.kdm.org> <Pine.BSF.4.21.0111270837240.49965-100000@scmsrv1.science-computing.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--tThc/1wpZn/ma/RB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Tue, Nov 27, 2001 at 09:06:48 +0100, Christoph Herrmann wrote:
> On Mon, 26 Nov 2001, Kenneth D. Merry wrote:
>
> > So did you try the statically linked -stable binary on -current?
>
> Yes, I used the newest version from the ports (compiled on -CURRENT) and
> the staticly linked from -STABLE both on -CURRENT, and the CDs are
> identical.
>
> > Is it completely static? (i.e. ldd cdrecord should report that it isn't a
> > dynamic executable)
>
> Yes it is.
>
> > That may help narrow the problem down somewhat. I'm not sure, though,
> > whether the -stable binary will work with the pass interface on -current.
>
> It doesn't matter wether I take cdrecord from -CURRENT or from -STABLE,
> the CDs (I burn on -CURRENT) are identical.
>
> > Are there any areas with good data on the CD? i.e. can you see any pattern
> > to the corruption? If you compare the same CD burned from -current and
> > -stable you might begin to see a patern.
>
> Yes, about half of the CD is correct, and the rest is filled up with
> binary zero. If there are data other then zero on the CD, then they are
> correct.
>
> > Is the table of contents correct?
>
> I don't know, but I don't think so. The first 60kB (exact 60kB!) of the
> broken CD are zeros, and I can't mount it.
Okay, that sounds suspicious. That is, I think, the I/O size that cdrecord
uses. (i.e. each transaction it sends down is 60KB.)
I'm not entirely sure what's going on, so let's try an experiment.
I've attached a patch to back out version 1.175 of
sys/i386/i386/vm_machdep.c. Apply it, recompile, reboot, etc. and re-run
your experiment.
The first hunk of the patch will fail -- don't worry about that, it's just
the RCS Id.
Also, do you recall when burning CDs on -current first broke for you?
Ken
--
Kenneth Merry
ken@kdm.org
--tThc/1wpZn/ma/RB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="vm_machdep.c.1.175-1.174"
Index: vm_machdep.c
===================================================================
RCS file: /usr/local/cvs/src/sys/i386/i386/vm_machdep.c,v
retrieving revision 1.175
retrieving revision 1.174
diff -c -r1.175 -r1.174
*** vm_machdep.c 2001/10/14 21:09:04 1.175
--- vm_machdep.c 2001/10/02 18:34:19 1.174
***************
*** 38,44 ****
*
* from: @(#)vm_machdep.c 7.3 (Berkeley) 5/13/91
* Utah $Hdr: vm_machdep.c 1.16.1.1 89/06/23$
! * $FreeBSD: src/sys/i386/i386/vm_machdep.c,v 1.175 2001/10/14 21:09:04 tegge Exp $
*/
#include "opt_npx.h"
--- 38,44 ----
*
* from: @(#)vm_machdep.c 7.3 (Berkeley) 5/13/91
* Utah $Hdr: vm_machdep.c 1.16.1.1 89/06/23$
! * $FreeBSD: src/sys/i386/i386/vm_machdep.c,v 1.174 2001/10/02 18:34:19 mjacob Exp $
*/
#include "opt_npx.h"
***************
*** 344,362 ****
{
register caddr_t addr, v, kva;
vm_offset_t pa;
- int pidx;
- struct vm_page *m;
GIANT_REQUIRED;
if ((bp->b_flags & B_PHYS) == 0)
panic("vmapbuf");
! for (v = bp->b_saveaddr,
! addr = (caddr_t)trunc_page((vm_offset_t)bp->b_data),
! pidx = 0;
! addr < bp->b_data + bp->b_bufsize;
! addr += PAGE_SIZE, v += PAGE_SIZE, pidx++) {
/*
* Do the vm_fault if needed; do the copy-on-write thing
* when reading stuff off device into memory.
--- 344,358 ----
{
register caddr_t addr, v, kva;
vm_offset_t pa;
GIANT_REQUIRED;
if ((bp->b_flags & B_PHYS) == 0)
panic("vmapbuf");
! for (v = bp->b_saveaddr, addr = (caddr_t)trunc_page((vm_offset_t)bp->b_data);
! addr < bp->b_data + bp->b_bufsize;
! addr += PAGE_SIZE, v += PAGE_SIZE) {
/*
* Do the vm_fault if needed; do the copy-on-write thing
* when reading stuff off device into memory.
***************
*** 366,381 ****
pa = trunc_page(pmap_kextract((vm_offset_t) addr));
if (pa == 0)
panic("vmapbuf: page not present");
! m = PHYS_TO_VM_PAGE(pa);
! vm_page_hold(m);
! bp->b_pages[pidx] = m;
}
! if (pidx > btoc(MAXPHYS))
! panic("vmapbuf: mapped more than MAXPHYS");
! pmap_qenter((vm_offset_t)bp->b_saveaddr, bp->b_pages, pidx);
!
kva = bp->b_saveaddr;
- bp->b_npages = pidx;
bp->b_saveaddr = bp->b_data;
bp->b_data = kva + (((vm_offset_t) bp->b_data) & PAGE_MASK);
}
--- 362,372 ----
pa = trunc_page(pmap_kextract((vm_offset_t) addr));
if (pa == 0)
panic("vmapbuf: page not present");
! vm_page_hold(PHYS_TO_VM_PAGE(pa));
! pmap_kenter((vm_offset_t) v, pa);
}
!
kva = bp->b_saveaddr;
bp->b_saveaddr = bp->b_data;
bp->b_data = kva + (((vm_offset_t) bp->b_data) & PAGE_MASK);
}
***************
*** 388,408 ****
vunmapbuf(bp)
register struct buf *bp;
{
! int pidx;
! int npages;
! vm_page_t *m;
GIANT_REQUIRED;
if ((bp->b_flags & B_PHYS) == 0)
panic("vunmapbuf");
! npages = bp->b_npages;
! pmap_qremove(trunc_page((vm_offset_t)bp->b_data),
! npages);
! m = bp->b_pages;
! for (pidx = 0; pidx < npages; pidx++)
! vm_page_unhold(*m++);
bp->b_data = bp->b_saveaddr;
}
--- 379,399 ----
vunmapbuf(bp)
register struct buf *bp;
{
! register caddr_t addr;
! vm_offset_t pa;
GIANT_REQUIRED;
if ((bp->b_flags & B_PHYS) == 0)
panic("vunmapbuf");
! for (addr = (caddr_t)trunc_page((vm_offset_t)bp->b_data);
! addr < bp->b_data + bp->b_bufsize;
! addr += PAGE_SIZE) {
! pa = trunc_page(pmap_kextract((vm_offset_t) addr));
! pmap_kremove((vm_offset_t) addr);
! vm_page_unhold(PHYS_TO_VM_PAGE(pa));
! }
bp->b_data = bp->b_saveaddr;
}
--tThc/1wpZn/ma/RB--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011127222108.A18996>