From rivers@dignus.com Mon May 31 18:13:58 1999
Return-Path: <rivers@dignus.com>
Received: from smtp2.vnet.net (smtp2.vnet.net [166.82.1.32])
	by hub.freebsd.org (Postfix) with ESMTP id 8882B14C34
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 31 May 1999 18:13:52 -0700 (PDT)
	(envelope-from rivers@dignus.com)
Received: from dignus.com (ponds.vnet.net [166.82.177.48])
	by smtp2.vnet.net (8.9.1a/8.9.1) with ESMTP id VAA18062
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 31 May 1999 21:14:40 -0400 (EDT)
Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3])
	by dignus.com (8.9.2/8.8.5) with ESMTP id VAA36051
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 31 May 1999 21:13:49 -0400 (EDT)
Received: (from rivers@localhost) by lakes.dignus.com (8.9.2/8.6.9) id VAA00620; Mon, 31 May 1999 21:13:49 -0400 (EDT)
Message-Id: <199906010113.VAA00620@lakes.dignus.com>
Date: Mon, 31 May 1999 21:13:49 -0400 (EDT)
From: Thomas David Rivers <rivers@dignus.com>
Reply-To: rivers@dignus.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: VM_fault with mmap'd CDROM data.
X-Send-Pr-Version: 3.2

>Number:         11969
>Category:       kern
>Synopsis:       VM_fault with mmap'd CDROM data.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon May 31 18:20:01 PDT 1999
>Closed-Date:    Sat Nov 17 09:04:01 PST 2001
>Last-Modified:  Sat Nov 17 09:04:15 PST 2001
>Originator:     Thomas David Rivers
>Release:        FreeBSD 3.1-RELEASE i386
>Organization:
Dignus, LLC
>Environment:

FreeBSD lakes.dignus.com 3.1-RELEASE FreeBSD 3.1-RELEASE #0: Sat Mar  6 17:34:47 EST 1999     rivers@lakes.dignus.com:/usr/src/sys/compile/LAKES  i386

Pentium 150 - 32 meg of memory, AHA2940 SCSI card, HP 6020i CDROM.


>Description:

  Sometimes, when using cmp(1) or cp(1) on data read from a CD, I
 encounter the following:

May 31 21:07:20 lakes su: rivers to root on /dev/ttyp2
(cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 2 9b dc 0 0 1 0 
(cd0:ahc0:0:4:0): VOLUME OVERFLOW info:29bdc asc:aa,0
(cd0:ahc0:0:4:0): Vendor Specific ASC
(cd0:ahc0:0:4:0): cddone: got error 0x5 back
vm_fault: pager read error, pid 388 (cmp)
May 31 21:07:33 lakes /kernel: pid 388 (cmp), uid 500: exited on signal 11

  However, cat(1) will read the data just fine, and it seems to be
correct.

  I believe cmp(1) and cp(1) both mmap() the source files, whilc cat(1)
does not - does this imply mmap()ing CD-ROM data has a problem?

  Also - after encountering this, an umount of the CD-ROM will
panic and crash the system.



>How-To-Repeat:

  The easiest thing I've found for repeating this is to cut your
 own CD from a large file system.  Then, run the following shell
 script to compare all the files (<src> is the source directory
 of the written CD, /cdrom is where the CD-ROM is mounted):

	cd <src>
	for i in `find . -print`
	do
	   if test -f $i
	   then
		cmp $i /cdrom/$i
	   fi
	done

  Sometimes, you'll get a Segmentation Fault from cmp.  A cp(1)
 on the troublesome file will give you the error "Bad Address".

>Fix:
	
   ???

>Release-Note:
>Audit-Trail:

From: "Kenneth D. Merry" <ken@plutotech.com>
To: rivers@dignus.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/11969: VM_fault with mmap'd CDROM data.
Date: Tue, 1 Jun 1999 10:02:20 -0600 (MDT)

 Thomas David Rivers wrote...
 > 
 > >Number:         11969
 > >Category:       kern
 > >Synopsis:       VM_fault with mmap'd CDROM data.
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    freebsd-bugs
 > >State:          open
 > >Quarter:        
 > >Keywords:       
 > >Date-Required:
 > >Class:          sw-bug
 > >Submitter-Id:   current-users
 > >Arrival-Date:   Mon May 31 18:20:01 PDT 1999
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     Thomas David Rivers
 > >Release:        FreeBSD 3.1-RELEASE i386
 > >Organization:
 > Dignus, LLC
 > >Environment:
 > 
 > FreeBSD lakes.dignus.com 3.1-RELEASE FreeBSD 3.1-RELEASE #0: Sat Mar  6 17:34:47 EST 1999     rivers@lakes.dignus.com:/usr/src/sys/compile/LAKES  i386
 > 
 > Pentium 150 - 32 meg of memory, AHA2940 SCSI card, HP 6020i CDROM.
 > 
 > 
 > >Description:
 > 
 >   Sometimes, when using cmp(1) or cp(1) on data read from a CD, I
 >  encounter the following:
 > 
 > May 31 21:07:20 lakes su: rivers to root on /dev/ttyp2
 > (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 2 9b dc 0 0 1 0 
 > (cd0:ahc0:0:4:0): VOLUME OVERFLOW info:29bdc asc:aa,0
 > (cd0:ahc0:0:4:0): Vendor Specific ASC
 > (cd0:ahc0:0:4:0): cddone: got error 0x5 back
 > vm_fault: pager read error, pid 388 (cmp)
 > May 31 21:07:33 lakes /kernel: pid 388 (cmp), uid 500: exited on signal 11
 > 
 >   However, cat(1) will read the data just fine, and it seems to be
 > correct.
 > 
 >   I believe cmp(1) and cp(1) both mmap() the source files, whilc cat(1)
 > does not - does this imply mmap()ing CD-ROM data has a problem?
 > 
 >   Also - after encountering this, an umount of the CD-ROM will
 > panic and crash the system.
 
 The problem here may be two-fold.  First, your CDROM drive is barfing on
 the read command above.  I don't know why that's happening, especially
 since there's a vendor-specific ASC and ASCQ.  If you can get the SCSI
 specs for that drive, you may be able to figure out what's going on.
 
 The second problem is that the upper level code may not be handling the
 error from the CD driver when it gets a bad block.
 
 For what it's worth, the CD driver doesn't handle the mmaping of the files
 on the filesystem.  That's handled by the upper-level code somewhere.  (You
 can tell I'm an expert on that code, can't you? :)
 
 If you can get a stack trace from the panic, someone might be interested in
 taking a look at it.
 
 
 Ken
 -- 
 Kenneth Merry
 ken@plutotech.com
 

From: Thomas David Rivers <rivers@dignus.com>
To: ken@plutotech.com, rivers@dignus.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/11969: VM_fault with mmap'd CDROM data.
Date: Tue, 1 Jun 1999 12:10:26 -0400 (EDT)

 > The problem here may be two-fold.  First, your CDROM drive is barfing on
 > the read command above.  I don't know why that's happening, especially
 > since there's a vendor-specific ASC and ASCQ.  If you can get the SCSI
 > specs for that drive, you may be able to figure out what's going on.
 > 
 
  True -
 
    But - it's something specific to the read - somehow...  because,
   cat of that file works correctly, gets the right data and doesn't
   cause the SCSI drive/driver to "barf".
 
    So - what's different when the read is a result of an mmap()?  
   The size of the read maybe?
 
 	- Dave Rivers -
 
 

From: "Kenneth D. Merry" <ken@plutotech.com>
To: rivers@dignus.com (Thomas David Rivers)
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/11969: VM_fault with mmap'd CDROM data.
Date: Tue, 1 Jun 1999 10:17:21 -0600 (MDT)

 Thomas David Rivers wrote...
 > > The problem here may be two-fold.  First, your CDROM drive is barfing on
 > > the read command above.  I don't know why that's happening, especially
 > > since there's a vendor-specific ASC and ASCQ.  If you can get the SCSI
 > > specs for that drive, you may be able to figure out what's going on.
 > > 
 > 
 >  True -
 > 
 >    But - it's something specific to the read - somehow...  because,
 >   cat of that file works correctly, gets the right data and doesn't
 >   cause the SCSI drive/driver to "barf".
 > 
 >    So - what's different when the read is a result of an mmap()?  
 >   The size of the read maybe?
 
 That's possible, but your drive should handle the 1-block read that the
 ISO9660 code tried to do.
 
 I believe there are other portions of the ISO9660 code and the CD driver
 that will try to read 1 block at a time.
 
 It could be some sort of firmware bug that happens in certain situations.
 
 It would help if we could get hold of the SCSI specs for that drive.  They
 might shed light on what that error code means.
 
 Ken
 -- 
 Kenneth Merry
 ken@plutotech.com
 

From: Thomas David Rivers <rivers@dignus.com>
To: ken@plutotech.com, rivers@dignus.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/11969: VM_fault with mmap'd CDROM data.
Date: Tue, 1 Jun 1999 12:27:31 -0400 (EDT)

 > Thomas David Rivers wrote...
 > > > The problem here may be two-fold.  First, your CDROM drive is barfing on
 > > > the read command above.  I don't know why that's happening, especially
 > > > since there's a vendor-specific ASC and ASCQ.  If you can get the SCSI
 > > > specs for that drive, you may be able to figure out what's going on.
 > > > 
 > > 
 > >  True -
 > > 
 > >    But - it's something specific to the read - somehow...  because,
 > >   cat of that file works correctly, gets the right data and doesn't
 > >   cause the SCSI drive/driver to "barf".
 > > 
 > >    So - what's different when the read is a result of an mmap()?  
 > >   The size of the read maybe?
 > 
 > That's possible, but your drive should handle the 1-block read that the
 > ISO9660 code tried to do.
 > 
 > I believe there are other portions of the ISO9660 code and the CD driver
 > that will try to read 1 block at a time.
 > 
 > It could be some sort of firmware bug that happens in certain situations.
 > 
 > It would help if we could get hold of the SCSI specs for that drive.  They
 > might shed light on what that error code means.
 
  Where's a good place to look?  This is an HP 6020i.
 
 	- Dave Rivers -
 
 

From: "Kenneth D. Merry" <ken@plutotech.com>
To: rivers@dignus.com (Thomas David Rivers)
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/11969: VM_fault with mmap'd CDROM data.
Date: Tue, 1 Jun 1999 10:30:50 -0600 (MDT)

 Thomas David Rivers wrote...
 > > Thomas David Rivers wrote...
 > > > > The problem here may be two-fold.  First, your CDROM drive is barfing on
 > > > > the read command above.  I don't know why that's happening, especially
 > > > > since there's a vendor-specific ASC and ASCQ.  If you can get the SCSI
 > > > > specs for that drive, you may be able to figure out what's going on.
 > > > > 
 > > > 
 > > >  True -
 > > > 
 > > >    But - it's something specific to the read - somehow...  because,
 > > >   cat of that file works correctly, gets the right data and doesn't
 > > >   cause the SCSI drive/driver to "barf".
 > > > 
 > > >    So - what's different when the read is a result of an mmap()?  
 > > >   The size of the read maybe?
 > > 
 > > That's possible, but your drive should handle the 1-block read that the
 > > ISO9660 code tried to do.
 > > 
 > > I believe there are other portions of the ISO9660 code and the CD driver
 > > that will try to read 1 block at a time.
 > > 
 > > It could be some sort of firmware bug that happens in certain situations.
 > > 
 > > It would help if we could get hold of the SCSI specs for that drive.  They
 > > might shed light on what that error code means.
 > 
 >  Where's a good place to look?  This is an HP 6020i.
 
 Look on HP's web site, or call them up and ask for the info if you can't
 find it on their web site.
 
 Ken
 -- 
 Kenneth Merry
 ken@plutotech.com
 

From: Thomas David Rivers <rivers@dignus.com>
To: ken@plutotech.com, rivers@dignus.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/11969: VM_fault with mmap'd CDROM data.
Date: Tue, 1 Jun 1999 12:31:45 -0400 (EDT)

 > >  Where's a good place to look?  This is an HP 6020i.
 > 
 > Look on HP's web site, or call them up and ask for the info if you can't
 > find it on their web site.
 > 
 
 Looking now...
 
 	- Dave R. -
 
State-Changed-From-To: open->feedback 
State-Changed-By: mike 
State-Changed-When: Fri Jul 20 15:32:33 PDT 2001 
State-Changed-Why:  

Does this problem still occur in newer versions of FreeBSD, 
such as 4.3-RELEASE? 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=11969 
State-Changed-From-To: feedback->closed 
State-Changed-By: bmah 
State-Changed-When: Sat Nov 17 09:04:01 PST 2001 
State-Changed-Why:  
Feedback timeout (3+ months). 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=11969 
>Unformatted:
