panic with cdrecord -- anybody else seeing this? [backtrace obtained]

From: John Reynolds <johnjen_at_reynoldsnet.org>
Date: Sun, 12 Oct 2003 18:32:21 -0700
Hi all, forgive me if I give incomplete information. This is the first time
I've created a debugging kernel and gotten a dump after a panic, so I might not
have done everything right.

Ever since the tail end of July it seems, any time I've tried to burn a CD with
cdrecord (cdrtools 2.0.3 from ports) I get a panic

  vm_fault_copy_wired: page missing

General busy-ness and the thought that "somebody will see it too and fix it"
has prevented me from caring too much about it until now, but it seems it's
still there in the kernel from Oct 11th, and I figured I might as well try to
provide somebody some information ......

My h/w: Abit IC7 i875-based system with one S-ATA disk sitting on ata2 and one
DVD burner sitting on ata0. I have a Tekram DC-390U controller which attaches
to the CD-ROM, CDRW in question, and a tape drive.

I temporarily booted a kernel/modules (with $module_path correctly set at the
loader) built from Oct 11th and saw the same panic, and here's what gdb says
about it:

  GNU gdb 5.2.1 (FreeBSD)
  Copyright 2002 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-undermydesk-freebsd"...
  panic: vm_fault_copy_wired: page missing
  panic messages:
  ---
  panic: vm_fault_copy_wired: page missing
  cpuid = 0; lapic.id = 00000000
  panic: from debugger
  cpuid = 0; lapic.id = 00000000
  boot() called on cpu#0
  Uptime: 6m3s
  ata0: spurious interrupt - status=0x51 error=0x04
  Dumping 1023 MB
   16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008
  ---
  Reading symbols from /usr/obj/usr/src/sys/WHALE/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
  Loaded symbols for /usr/obj/usr/src/sys/WHALE/modules/usr/src/sys/modules/acpi/acpi.ko.debug
  Reading symbols from /usr/obj/usr/src/sys/WHALE/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done.
  Loaded symbols for /usr/obj/usr/src/sys/WHALE/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug
  Reading symbols from /usr/obj/usr/src/sys/WHALE/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
  Loaded symbols for /usr/obj/usr/src/sys/WHALE/modules/usr/src/sys/modules/linux/linux.ko.debug
  Reading symbols from /boot/kernel/snd_ich.ko...done.
  Loaded symbols for /boot/kernel/snd_ich.ko
  Reading symbols from /boot/kernel/snd_pcm.ko...done.
  Loaded symbols for /boot/kernel/snd_pcm.ko
  #0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
  240             dumping++;
  (kgdb) where
  #0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
  #1  0xc050f107 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
  #2  0xc050f4b6 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
  #3  0xc0448c82 in db_panic () at /usr/src/sys/ddb/db_command.c:450
  #4  0xc0448be2 in db_command (last_cmdp=0xc06eea20, cmd_table=0x0, 
      aux_cmd_tablep=0xc06bce9c, aux_cmd_tablep_end=0xc06bcea0)
      at /usr/src/sys/ddb/db_command.c:346
  #5  0xc0448d25 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
  #6  0xc044bd25 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:73
  #7  0xc064bf4c in kdb_trap (type=3, code=0, regs=0xec1b5b30)
      at /usr/src/sys/i386/i386/db_interface.c:171
  #8  0xc0664b0a in trap (frame=
        {tf_fs = -333774824, tf_es = -1067122672, tf_ds = -959709168, tf_edi = -1066719322, tf_esi = 1, tf_ebp = -333751428, tf_isp = -333751460, tf_ebx = 0, tf_edx = 0, tf_ecx = 32, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067138475, tf_cs = 8, tf_eflags = 658, tf_esp = -1066705215, tf_ss = -1066776060})
      at /usr/src/sys/i386/i386/trap.c:579
  #9  0xc064d948 in calltrap () at {standard input}:103
  #10 0xc050f44f in panic (fmt=0xc06b27a6 "vm_fault_copy_wired: page missing")
      at /usr/src/sys/kern/kern_shutdown.c:534
  #11 0xc06151eb in vm_fault_copy_entry (dst_map=0xc6cc88dc, src_map=0xc6cc83f0, 
      dst_entry=0xc71fca14, src_entry=0x0) at /usr/src/sys/vm/vm_fault.c:1187
  #12 0xc061b491 in vm_map_copy_entry (src_map=0xc6cc83f0, dst_map=0xc6cc88dc, 
      src_entry=0xc6d41d5c, dst_entry=0xc71fca14) at /usr/src/sys/vm/vm_map.c:2379
  #13 0xc061b73e in vmspace_fork (vm1=0xc6cc83f0) at /usr/src/sys/vm/vm_map.c:2494
  #14 0xc061676e in vm_forkproc (td=0xc6caad10, p2=0xc72043c8, td2=0xc72005f0, 
      flags=20) at /usr/src/sys/vm/vm_glue.c:624
  #15 0xc04fb6a8 in fork1 (td=0xc6caad10, flags=20, pages=0, procp=0xec1b5cd8)
      at /usr/src/sys/kern/kern_fork.c:654
  #16 0xc04fa71b in fork (td=0xc6caad10, uap=0xec1b5d10)
      at /usr/src/sys/kern/kern_fork.c:102
  #17 0xc0665480 in syscall (frame=
        {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 4096, tf_esi = 65536, tf_ebp = -1077947512, tf_isp = -333750924, tf_ebx = 64, tf_edx = 1307, tf_ecx = 672797952, tf_eax = 2, tf_trapno = 0, tf_err = 2, tf_eip = 672196335, tf_cs = 31, tf_eflags = 582, tf_esp = -1077947556, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1009
  #18 0xc064d99d in Xint0x80_syscall () at {standard input}:145
  ---Can't read userspace from dump, or kernel process---
  
  (kgdb) 

I'm not sure what the "Can't read userspace from dump" implies ...

The command I used to burn the cd was a "vanilla" command that I've used a
thousand times before

  cdrecord -v dev=1,4,0 speed=10 filename.iso

Is anybody else seeing this same panic with cdrecord?

-Jr

-- 
John & Jennifer Reynolds  johnjen at reynoldsnet.org        www.reynoldsnet.org
Structural / Physical Design - ICG/PNG SCD     jreynold at sedona.ch.intel.com
Running FreeBSD since 2.1.5-RELEASE.               FreeBSD: The Power to Serve!
"Unix is user friendly, it's just particular about the friends it chooses."
Received on Sun Oct 12 2003 - 16:32:25 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:25 UTC