Re: panic with cdrecord -- anybody else seeing this? [backtrace obtained]
[ On Wednesday, October 15, Bruce M Simpson wrote: ] > On Mon, Oct 13, 2003 at 05:26:59AM -0700, John Reynolds wrote: > > Thanks. I haven't tried cdrtools-devel in "a while" so I probably didn't see > > the work-around that was committed. I will try it and report back as to if it > > works (to further narrow down the mlockall(2) bit). > > It looks like alc@ has fixed the problem in vm_fault.c rev 1.181. > > BMS I can definitely confirm this too! With the unpatched cdrecord (in the non-devel port) and this versio of vm_fault.c there was no panic! Awesome! Thanks! -Jr -- John & Jennifer Reynolds johnjen at reynoldsnet.orgwww.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." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic with cdrecord -- anybody else seeing this? [backtrace obtained]
[ On Wednesday, October 15, Bruce M Simpson wrote: ] > > It looks like alc@ has fixed the problem in vm_fault.c rev 1.181. > > BMS excellent! I'll CVSup, buildworld/kernel and try it out and report back (with the "unpatched" cdrecord of course). -Jr -- John & Jennifer Reynolds johnjen at reynoldsnet.orgwww.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." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic with cdrecord -- anybody else seeing this? [backtrace obtained]
On Mon, Oct 13, 2003 at 05:26:59AM -0700, John Reynolds wrote: > Thanks. I haven't tried cdrtools-devel in "a while" so I probably didn't see > the work-around that was committed. I will try it and report back as to if it > works (to further narrow down the mlockall(2) bit). It looks like alc@ has fixed the problem in vm_fault.c rev 1.181. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic with cdrecord -- anybody else seeing this? [backtrace obtained]
[ On Monday, October 13, Marius Strobl wrote: ] > > And > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/57611 > > The latter is a bit more detailed and correct (it's not limited to ATAPI > burners). It also doesn't seem to be limited to cdrecord, the latest > ntpd also causes a panic when using mlockall(2) as reported on this list, > however the backtrace looks different. > Btw., the cdrtools-devel port contains a workaround. I can confirm that using the latest and greatest cdrtools-devel port works around the bug, so it's a definite problem related to mlockall(2). I've burned a cd with a kernel from Aug 19th, and also from Oct 11th and all seems well with this work-around. If there are further patches to try and apply to the kernel to work-around this issue or if people need further print's from gdb from my crash dumps, please let me know! -Jr -- John & Jennifer Reynolds johnjen at reynoldsnet.orgwww.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." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic with cdrecord -- anybody else seeing this? [backtrace obtained]
[ On Monday, October 13, Marius Strobl wrote: ] > > And > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/57611 > > The latter is a bit more detailed and correct (it's not limited to ATAPI > burners). It also doesn't seem to be limited to cdrecord, the latest > ntpd also causes a panic when using mlockall(2) as reported on this list, > however the backtrace looks different. > Btw., the cdrtools-devel port contains a workaround. Thanks. I haven't tried cdrtools-devel in "a while" so I probably didn't see the work-around that was committed. I will try it and report back as to if it works (to further narrow down the mlockall(2) bit). -Jr -- John & Jennifer Reynolds johnjen at reynoldsnet.orgwww.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." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic with cdrecord -- anybody else seeing this? [backtrace obtained]
On Sun, Oct 12, 2003 at 09:18:08PM -0700, Kris Kennaway wrote: > On Sun, Oct 12, 2003 at 06:32:21PM -0700, John Reynolds wrote: > > 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 .. > > Thanks..Alan made a commit which he thought might have fixed this, but > someone else also claimed it did not. > > See also > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/56380 > And http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/57611 The latter is a bit more detailed and correct (it's not limited to ATAPI burners). It also doesn't seem to be limited to cdrecord, the latest ntpd also causes a panic when using mlockall(2) as reported on this list, however the backtrace looks different. Btw., the cdrtools-devel port contains a workaround. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic with cdrecord -- anybody else seeing this? [backtrace obtained]
On Sun, Oct 12, 2003 at 09:49:59PM -0700, John Reynolds wrote: > > [ On Sunday, October 12, Kris Kennaway wrote: ] > > > > Thanks..Alan made a commit which he thought might have fixed this, but > > someone else also claimed it did not. > > > > See also > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/56380 > > > > Kris > > Is there any more information that I can provide which might help a VM guru out > there figure out what has gone awry? BTW: I've tried the cdrtools-devel port as > well thinking it was cdrecord's fault, but even the latest devel version panics > with the same panic message. The backtrace might be enough (I was waiting on the PR author to provide one), but alan will ask if he needs more information. Kris pgp0.pgp Description: PGP signature
Re: panic with cdrecord -- anybody else seeing this? [backtrace obtained]
[ On Sunday, October 12, Kris Kennaway wrote: ] > > Thanks..Alan made a commit which he thought might have fixed this, but > someone else also claimed it did not. > > See also > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/56380 > > Kris Is there any more information that I can provide which might help a VM guru out there figure out what has gone awry? BTW: I've tried the cdrtools-devel port as well thinking it was cdrecord's fault, but even the latest devel version panics with the same panic message. I can provide full "boot -v" dmesg output or anything else that somebody wants/needs. For what it's worth, I do NOT have atapicam compiled into or loaded into this system, though I was planning on it in the future so that cdrecord good grok my recently acquired DVD burner. -Jr -- John & Jennifer Reynolds johnjen at reynoldsnet.orgwww.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." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic with cdrecord -- anybody else seeing this? [backtrace obtained]
On Sun, Oct 12, 2003 at 06:32:21PM -0700, John Reynolds wrote: > 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 .. Thanks..Alan made a commit which he thought might have fixed this, but someone else also claimed it did not. See also http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/56380 Kris pgp0.pgp Description: PGP signature
panic with cdrecord -- anybody else seeing this? [backtrace obtained]
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 =
panic: from debugger
cpuid = 0; lapic.id =
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
