Bug 29295

Summary: use of mmap in cp(1) can cause a panic when reading from CD
Product: Base System Reporter: Karel J. Bosschaart <karelj>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.3-STABLE   
Hardware: Any   
OS: Any   

Description Karel J. Bosschaart 2001-07-29 13:10:01 UTC
A significant percentage of CDROMs that I burnt with mkisofs/cdrecord
contains one or more files that I cannot cp(1) from CD to harddisk. I'm 
getting a 'Bad Address'. However, it is possible to access those files with 
other programs such as cat(1). When it is attempted to cp(1) the particular 
file(s) after having used cat(1) on them, a panic on 4.x and 5.0 immediately 
follows. On 3.x (versions after 1998-11-14, when use of mmap was introduced
http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/cp/Makefile?only_with_tag=RELENG_3_1_0_RELEASE ) 
I didn't get an immediate panic, but the machine paniced shortly after issuing 
the shutdown command.

Fix: 

I worked around by removing 
"CFLAGS+=         -W -DVM_AND_BUFFER_CACHE_SYNCHRONIZED"
from /usr/src/bin/cp/Makefile and recompile/reinstall.
How-To-Repeat: Mount a CDROM that contains troublesome files (I could make an ISO available
if that would be useful). Attempting to cp(1) such a file gives 'Bad
Address'. When preceding the cp(1) command with cat(1), which successfully
transfers the file, the machine panics (typical crash dump shown below
with gdb).
I reproduced the problem on four different FreeBSD machines, two of them
with IDE CD drives, two of them with SCSI CD drives. However, I also found
a machine (IDE CD drive) that did *not* have the problem, so I suspect there
are also hardware aspects involved. 

babyflame# gdb -k
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd".
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /home/karelj/crash/kernel.0
(kgdb) core-file /home/karelj/crash/vmcore.0
IdlePTD 3973120
initial pcb at 329b40
panicstr: vm_page_free: freeing wired page

panic messages:
---
panic: vm_page_free: freeing wired page


syncing disks... 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 
giving up on 15 buffers
Uptime: 2m21s

dumping to dev #ad/0x20001, offset 139296
dump ata0: resetting devices .. done
63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
---
#0  dumpsys () at ../../kern/kern_shutdown.c:472
472             if (dumping++) {
(kgdb) bt
#0  dumpsys () at ../../kern/kern_shutdown.c:472
#1  0xc015c6ff in boot (howto=256) at ../../kern/kern_shutdown.c:312
#2  0xc015cacc in poweroff_wait (junk=0xc02cb440, howto=4)
    at ../../kern/kern_shutdown.c:580
#3  0xc023b47e in vm_page_free_toq (m=0xc04f5988) at ../../vm/vm_page.c:1108
#4  0xc0233b75 in vm_fault (map=0xc567b200, vaddr=674942976, fault_type=1 '\001', 
    fault_flags=0) at ../../vm/vm_page.h:527
#5  0xc0296faa in trap_pfault (frame=0xc6119c9c, usermode=0, eva=674942976)
    at ../../i386/i386/trap.c:824
#6  0xc0296bd3 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, 
      tf_edi = -1030774784, tf_esi = 674942976, tf_ebp = -971924072, 
      tf_isp = -971924280, tf_ebx = 1469, tf_edx = 674944445, tf_ecx = 1469, 
      tf_eax = -971931648, tf_trapno = 12, tf_err = 0, tf_eip = -1071031472, 
      tf_cs = 8, tf_eflags = 2163206, tf_esp = -60801, tf_ss = -65536})
    at ../../i386/i386/trap.c:443
#7  0xc0295b50 in fastmove ()
#8  0xc0295a9e in i586_copyin ()
#9  0xc022a449 in ffs_write (ap=0xc6119e68) at ../../ufs/ufs/ufs_readwrite.c:510
#10 0xc0190552 in vn_write (fp=0xc09b0980, uio=0xc6119ed8, cred=0xc09ab700, flags=0, 
    p=0xc610e920) at vnode_if.h:363
#11 0xc016ae29 in dofilewrite (p=0xc610e920, fp=0xc09b0980, fd=4, buf=0x28057000, 
    nbyte=3499453, offset=-1, flags=0) at ../../sys/file.h:162
#12 0xc016ace2 in write (p=0xc610e920, uap=0xc6119f80)
    at ../../kern/sys_generic.c:329
#13 0xc02975e9 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
      tf_edi = 671444992, tf_esi = 671444992, tf_ebp = -1077937708, 
      tf_isp = -971923500, tf_ebx = 3499453, tf_edx = 134660480, tf_ecx = 2, 
      tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = 134561112, tf_cs = 31, 
      tf_eflags = 659, tf_esp = -1077937768, tf_ss = 47})
    at ../../i386/i386/trap.c:1150
#14 0xc0288d25 in Xint0x80_syscall ()
#15 0x8048979 in ?? ()
#16 0x804850e in ?? ()
#17 0x8048135 in ?? ()
(kgdb)
Comment 1 Kris Kennaway freebsd_committer freebsd_triage 2001-07-29 23:47:11 UTC
Responsible Changed
From-To: freebsd-bugs->sos

Soren is the ATA maintainer.  This PR might have been resolved by 
a commit today to -current to correct block size access of CDs.
Comment 2 Karel J. Bosschaart 2001-07-31 15:13:06 UTC
Tried today with 5.0 sources from 31th July, thus including mentioned commit.
The panic still occurs. No surprise actually, because I observe the problem
also with SCSI drives and on FreeBSD 3.x versions, where no ATA driver is
involved.
Comment 3 Søren Schmidt freebsd_committer freebsd_triage 2001-09-06 10:14:04 UTC
Responsible Changed
From-To: sos->freebsd-bugs

This is not an ATA only problem, the bug is of more general nature.ZZ
Comment 4 silby freebsd_committer freebsd_triage 2002-02-26 07:34:36 UTC
State Changed
From-To: open->feedback

Does this still occur in 4.5?  Rev 1.23.2.3 of cd9660_lookup.c 
sounds like it _could_ have fixed the problem.
Comment 5 silby freebsd_committer freebsd_triage 2002-03-03 23:04:19 UTC
State Changed
From-To: feedback->closed

Problem submitter reports that this bug was successfully 
in 4.5.