From owner-freebsd-current@FreeBSD.ORG Sun Oct 12 18:32:25 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B38016A4B3 for ; Sun, 12 Oct 2003 18:32:25 -0700 (PDT) Received: from fed1mtao03.cox.net (fed1mtao03.cox.net [68.6.19.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 044C743FA3 for ; Sun, 12 Oct 2003 18:32:24 -0700 (PDT) (envelope-from jjreynold@ip68-2-101-74.ph.ph.cox.net) Received: from ip68-2-101-74.ph.ph.cox.net ([68.2.101.74]) by fed1mtao03.cox.netESMTP <20031013013219.WLSO23864.fed1mtao03.cox.net@ip68-2-101-74.ph.ph.cox.net> for ; Sun, 12 Oct 2003 21:32:19 -0400 Received: from whale.home-net (whale.home-net [192.168.1.2]) h9D1WN0H061574 for ; Sun, 12 Oct 2003 18:32:23 -0700 (MST) (envelope-from jjreynold@dolphin.home-net) Received: from whale.home-net (localhost [127.0.0.1]) by whale.home-net (8.12.9/8.12.9) with ESMTP id h9D1WMeJ000928 for ; Sun, 12 Oct 2003 18:32:22 -0700 (MST) (envelope-from jjreynold@whale.home-net) Received: (from jjreynold@localhost) by whale.home-net (8.12.9/8.12.9/Submit) id h9D1WMIx000925; Sun, 12 Oct 2003 18:32:22 -0700 (MST) (envelope-from jjreynold) From: John Reynolds MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16266.165.855721.885956@whale.home-net> Date: Sun, 12 Oct 2003 18:32:21 -0700 To: current@freebsd.org X-Mailer: VM 7.17 under Emacs 21.3.1 Subject: panic with cdrecord -- anybody else seeing this? [backtrace obtained] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2003 01:32:25 -0000 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."