regression with new Nvidia driver (1.0.9631)
I have upgraded x11/nvidia-driver to the latest port version (driver version 1.0.9631) and now my X refuses to start in 1600x1200 mode, I even tried with DefaultDepth 16. Reverting to the old driver (driver version 1.0.8776) restores the correct behavior. I have : nvidia0: mem 0xe800-0xebff,0xd800-0xdfff,0xee00-0xeeff irq 16 at device 0.0 on pci1 FreeBSD ice.irfu.se 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #7: Fri Dec 8 11:09:34 CET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ICE i386 [EMAIL PROTECTED] ~]$ diff /var/log/Xorg.0.log /var/log/Xorg.0.log.old |less 14c14 < (==) Log file: "/var/log/Xorg.0.log", Time: Fri Dec 8 12:25:28 2006 --- > (==) Log file: "/var/log/Xorg.0.log", Time: Fri Dec 8 12:15:34 2006 242c242 < compiled for 4.0.2, module version = 1.0.8776 --- > compiled for 4.0.2, module version = 1.0.9631 285c285 < compiled for 4.0.2, module version = 1.0.8776 --- > compiled for 4.0.2, module version = 1.0.9631 299c299 < (II) NVIDIA dlloader X Driver 1.0-8776 Mon Oct 16 22:00:36 PDT 2006 --- > (II) NVIDIA dlloader X Driver 1.0-9631 Thu Nov 9 17:40:39 PST 2006 390,391c390,391 < (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32 < (==) NVIDIA(0): RGB weight 888 --- > (**) NVIDIA(0): Depth 16, (--) framebuffer bpp 16 > (==) NVIDIA(0): RGB weight 565 395,396c395,396 < (II) NVIDIA(0): NVIDIA GPU Quadro FX 550 at PCI:1:0:0 < (--) NVIDIA(0): VideoRAM: 131072 kBytes --- > (II) NVIDIA(0): NVIDIA GPU Quadro FX 550 at PCI:1:0:0 (GPU-0) > (--) NVIDIA(0): Memory: 131072 kBytes 404a405 > (WW) NVIDIA(0): No valid modes for "1600x1200"; removing. 406d406 < (II) NVIDIA(0): "1600x1200" 14c14 < (==) Log file: "/var/log/Xorg.0.log", Time: Fri Dec 8 12:25:28 2006 --- > (==) Log file: "/var/log/Xorg.0.log", Time: Fri Dec 8 12:15:34 2006 242c242 < compiled for 4.0.2, module version = 1.0.8776 --- > compiled for 4.0.2, module version = 1.0.9631 285c285 < compiled for 4.0.2, module version = 1.0.8776 --- > compiled for 4.0.2, module version = 1.0.9631 299c299 < (II) NVIDIA dlloader X Driver 1.0-8776 Mon Oct 16 22:00:36 PDT 2006 --- > (II) NVIDIA dlloader X Driver 1.0-9631 Thu Nov 9 17:40:39 PST 2006 390,391c390,391 < (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32 < (==) NVIDIA(0): RGB weight 888 --- > (**) NVIDIA(0): Depth 16, (--) framebuffer bpp 16 > (==) NVIDIA(0): RGB weight 565 395,396c395,396 < (II) NVIDIA(0): NVIDIA GPU Quadro FX 550 at PCI:1:0:0 < (--) NVIDIA(0): VideoRAM: 131072 kBytes --- > (II) NVIDIA(0): NVIDIA GPU Quadro FX 550 at PCI:1:0:0 (GPU-0) > (--) NVIDIA(0): Memory: 131072 kBytes 404a405 > (WW) NVIDIA(0): No valid modes for "1600x1200"; removing. 406d406 < (II) NVIDIA(0): "1600x1200" 412,416c412,414 < (II) NVIDIA(0): Virtual screen size determined to be 1600 x 1200 < (WW) NVIDIA(0): No size information available in DFP-0's EDID; cannot compute < (WW) NVIDIA(0): DPI from EDID. < (==) NVIDIA(0): DPI set to (75, 75); computed from built-in default < (--) Depth 24 pixmap format is 32 bpp --- > (II) NVIDIA(0): Virtual screen size determined to be 1280 x 1024 > (--) NVIDIA(0): DPI set to (79, 83); computed from "UseEdidDpi" X config > (--) NVIDIA(0): option 460c458 < (II) NVIDIA(0): Setting mode "1600x1200" --- > (II) NVIDIA(0): Setting mode "1280x1024" 509a508,509 > (II) XINPUT: Adding extended input device "NVIDIA Damage Notification Manager" (type: Other) > (II) XINPUT: Adding extended input device "NVIDIA Kernel RC Handler" (type: Ot her) 513a514 > FreeFontPath: FPE "/usr/X11R6/lib/X11/fonts/misc/" refcount is 2, should be 1; fixing. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NFS/TCP
Will a fix for NFS/TCP (nfs_socket.c rev 1.138) be ever committed to stable? Yuri Khotyaintsev wrote: On Monday 08 May 2006 19:41, Kris Kennaway wrote: On Mon, May 08, 2006 at 01:54:58PM +0200, Yuri Khotyaintsev wrote: I have an NSF server and several clients which write large text files to the server. All machines are running max one week old STABLE and are connected to the same gigabit switch, and have identical nics (em). Amd mount options are: /defaults type:=nfs;cache:=all;opts:=rw,intr,nosuid,grpid,nfsv3,tcp,resvport,soft Almost all the time I get the following messages on the server: nfsd send error 32 nfsd send error 32 nfsd send error 32 nfsd send error 32 nfsd send error 32 ... And corresponding messages on a client: impossible packet length (8996061) from nfs server db:/export/data1/caa impossible packet length (3123011) from nfs server db:/export/data1/caa impossible packet length (893006905) from nfs server db:/export/data1/caa impossible packet length (842018868) from nfs server db:/export/data1/caa impossible packet length (874220) from nfs server db:/export/data1/caa impossible packet length (14182767) from nfs server db:/export/data1/caa impossible packet length (16777216) from nfs server db:/export/data1/caa impossible packet length (758134573) from nfs server db:/export/data1/caa impossible packet length (1503661568) from nfs server db:/export/data1/caa impossible packet length (1300840) from nfs server db:/export/data1/caa ... And from time to time the files which are written to the server get truncated (regardless of the file size)... Does anybody have an idea how to make it work reliably and not to truncate the files? mohan committed a fix for one such problem a few days ago. It will not be in 6.1-RELEASE, but you should be able to apply the patch yourself. It would be nice to know how it works for you. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/nfsclient/nfs_socket.c.diff?r 1=text&tr1=1.136&r2=text&tr2=1.139 I have patched nfs_socket.c on all clients and run the same kind of processing which was causing the problem. I can report that the problem is gone with nfs_socket.c rev 1.139. I only got one "nfs send error 35" on one of the clients instead of hundreds of messages I was seeing before. Thank you very much! -- Dr. Yuri Khotyaintsev Institutet för rymdfysik (IRF), Uppsala ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS/TCP problems
On Monday 08 May 2006 19:41, Kris Kennaway wrote: > On Mon, May 08, 2006 at 01:54:58PM +0200, Yuri Khotyaintsev wrote: > > I have an NSF server and several clients which write large text files to > > the server. All machines are running max one week old STABLE and are > > connected to the same gigabit switch, and have identical nics (em). Amd > > mount options are: /defaults > > type:=nfs;cache:=all;opts:=rw,intr,nosuid,grpid,nfsv3,tcp,resvport,soft > > > > Almost all the time I get the following messages on the server: > > > > nfsd send error 32 > > nfsd send error 32 > > nfsd send error 32 > > nfsd send error 32 > > nfsd send error 32 > > ... > > > > And corresponding messages on a client: > > > > impossible packet length (8996061) from nfs server db:/export/data1/caa > > impossible packet length (3123011) from nfs server db:/export/data1/caa > > impossible packet length (893006905) from nfs server db:/export/data1/caa > > impossible packet length (842018868) from nfs server db:/export/data1/caa > > impossible packet length (874220) from nfs server db:/export/data1/caa > > impossible packet length (14182767) from nfs server db:/export/data1/caa > > impossible packet length (16777216) from nfs server db:/export/data1/caa > > impossible packet length (758134573) from nfs server db:/export/data1/caa > > impossible packet length (1503661568) from nfs server > > db:/export/data1/caa impossible packet length (1300840) from nfs server > > db:/export/data1/caa ... > > > > And from time to time the files which are written to the server get > > truncated (regardless of the file size)... > > > > Does anybody have an idea how to make it work reliably and not to > > truncate the files? > > mohan committed a fix for one such problem a few days ago. It will > not be in 6.1-RELEASE, but you should be able to apply the patch > yourself. It would be nice to know how it works for you. > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/nfsclient/nfs_socket.c.diff?r >1=text&tr1=1.136&r2=text&tr2=1.139 I have patched nfs_socket.c on all clients and run the same kind of processing which was causing the problem. I can report that the problem is gone with nfs_socket.c rev 1.139. I only got one "nfs send error 35" on one of the clients instead of hundreds of messages I was seeing before. Thank you very much! BTW, what is better/faster TCP or UDP for running NFS between hosts connected to the same gigabit switch? -- Dr. Yuri Khotyaintsev Institutet för rymdfysik (IRF), Uppsala ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NFS/TCP problems
I have an NSF server and several clients which write large text files to the server. All machines are running max one week old STABLE and are connected to the same gigabit switch, and have identical nics (em). Amd mount options are: /defaults type:=nfs;cache:=all;opts:=rw,intr,nosuid,grpid,nfsv3,tcp,resvport,soft Almost all the time I get the following messages on the server: nfsd send error 32 nfsd send error 32 nfsd send error 32 nfsd send error 32 nfsd send error 32 ... And corresponding messages on a client: impossible packet length (8996061) from nfs server db:/export/data1/caa impossible packet length (3123011) from nfs server db:/export/data1/caa impossible packet length (893006905) from nfs server db:/export/data1/caa impossible packet length (842018868) from nfs server db:/export/data1/caa impossible packet length (874220) from nfs server db:/export/data1/caa impossible packet length (14182767) from nfs server db:/export/data1/caa impossible packet length (16777216) from nfs server db:/export/data1/caa impossible packet length (758134573) from nfs server db:/export/data1/caa impossible packet length (1503661568) from nfs server db:/export/data1/caa impossible packet length (1300840) from nfs server db:/export/data1/caa ... And from time to time the files which are written to the server get truncated (regardless of the file size)... Does anybody have an idea how to make it work reliably and not to truncate the files? -- Dr. Yuri Khotyaintsev Institutet för rymdfysik (IRF), Uppsala ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fatal trap 9: general protection fault while in kernel mode
bdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model VersaPad, device ID 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A orm0: at iomem 0xc-0xcafff,0xcb000-0xcbfff,0xcc000-0xc,0xd-0xd0fff,0xec000-0xe on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 1.000 msec acd0: CDROM at ata0-master UDMA33 Waiting 5 seconds for SCSI devices to settle ses0 at mpt0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled da0: 70007MB (143374650 512 byte sectors: 255H 63S/T 8924C) da2 at mpt3 bus 0 target 1 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled da2: 1667498MB (3415035904 512 byte sectors: 255H 63S/T 212576C) da1 at mpt2 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled da1: 1667498MB (3415035904 512 byte sectors: 255H 63S/T 212576C) SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! Trying to mount root from ufs:/dev/da0s1a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to deny, logging disabled reboot after panic: general protection fault writing core to vmcore.0 em0: link state changed to UP em1: link state changed to UP -- Dr. Yuri Khotyaintsev Institutet för rymdfysik (IRF), Uppsala ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode
On Friday 02 December 2005 14.54, John Baldwin wrote:
> On Friday 02 December 2005 05:00 am, Yuri Khotyaintsev wrote:
> > I have the following panic occurring several times a week. The machine is
> > an NFS server, and it usually panics early in the morning, when first
> > people try to access it. After reboot it may work OK for 1-2 days, and
> > then panics again. I have tried changing memory and replacing disk which
> > was exported via NFS, but nothing helped :(
> >
> > Any suggestion on how to fix this panic will be very much appreciated !
>
> This panic (in propagate_priority) is usually caused when a thread goes to
> sleep while holding a mutex (which is forbidden). If you enable INVARIANTS
> and/or WITNESS you should get a better panic, and with WITNESS you will
> even be warned when a thread goes to sleep while holding a mutex. However,
> these options do introduce considerable execution overhead, and sometimes
> that overhead changes the timing enough to hide the race. :(
Here are the two panics which I got with INVARIANTS and WITNESS enabled.
# kgdb /usr/obj/usr/src/sys/HEM.DEBUG/kernel.debug vmcore.8
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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-marcel-freebsd".
Unread portion of the kernel message buffer:
Memory modified after free 0xc4759e00(508) val=0 @ 0xc4759e00
panic: Most recently used by UFS dirhash
Uptime: 11h8m36s
Dumping 511 MB (2 chunks)
chunk 0: 1MB (160 pages) ... ok
chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335
319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc050fd4f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
#2 0xc0510043 in panic (fmt=0xc06dccbb "Most recently used by %s\n")
at /usr/src/sys/kern/kern_shutdown.c:555
#3 0xc0648ccf in mtrash_ctor (mem=0xc4759e00, size=0, arg=0x0, flags=2)
at /usr/src/sys/vm/uma_dbg.c:137
#4 0xc06469c1 in uma_zalloc_arg (zone=0xc104d980, udata=0x0, flags=2)
at /usr/src/sys/vm/uma_core.c:1850
#5 0xc05043cd in malloc (size=400, mtp=0xc06fb700, flags=2) at uma.h:275
#6 0xc063fba9 in ufs_readdir (ap=0xd56eaaec)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:1846
#7 0xc06a61cc in VOP_READDIR_APV (vop=0x0, a=0xd56eaaec) at vnode_if.c:1427
#8 0xc0607716 in nfsrv_readdir (nfsd=0xc4368c00, slp=0x0, td=0xc3326780,
mrq=0xd56eac80) at vnode_if.h:746
#9 0xc060fa5b in nfssvc_nfsd (td=0x0)
at /usr/src/sys/nfsserver/nfs_syscalls.c:472
#10 0xc060f280 in nfssvc (td=0xc3326780, uap=0xd56ead04)
at /usr/src/sys/nfsserver/nfs_syscalls.c:181
#11 0xc069b6b0 in syscall (frame=
---Type to continue, or q to quit---
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 0, tf_esi = 0, tf_ebp =
-1077941464, tf_isp = -714166940, tf_ebx = 0, tf_edx = -1077936144, tf_ecx =
1, tf_eax = 155, tf_trapno = 12, tf_err = 2, tf_eip = 671852067, tf_cs = 51,
tf_eflags = 582, tf_esp = -1077941492, tf_ss = 59})
at /usr/src/sys/i386/i386/trap.c:981
#12 0xc068947f in Xint0x80_syscall ()
at /usr/src/sys/i386/i386/exception.s:200
#13 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) quit
# kgdb /usr/obj/usr/src/sys/HEM.DEBUG/kernel.debug vmcore.9
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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-marcel-freebsd".
Unread portion of the kernel message buffer:
Memory modified after free 0xc5172800(508) val=0 @ 0xc5172800
panic: Most recently used by UFS dirhash
Uptime: 1d1h7m17s
Dumping 511 MB (2 chunks)
chunk 0: 1MB (160 pages) ... ok
chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335
319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc050fd4f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
#2
Re: Fatal trap 12: page fault while in kernel mode
On Friday 02 December 2005 14.54, John Baldwin wrote: > On Friday 02 December 2005 05:00 am, Yuri Khotyaintsev wrote: > > I have the following panic occurring several times a week. The machine is > > an NFS server, and it usually panics early in the morning, when first > > people try to access it. After reboot it may work OK for 1-2 days, and > > then panics again. I have tried changing memory and replacing disk which > > was exported via NFS, but nothing helped :( > > > > Any suggestion on how to fix this panic will be very much appreciated ! > > This panic (in propagate_priority) is usually caused when a thread goes to > sleep while holding a mutex (which is forbidden). If you enable INVARIANTS > and/or WITNESS you should get a better panic, and with WITNESS you will > even be warned when a thread goes to sleep while holding a mutex. However, > these options do introduce considerable execution overhead, and sometimes > that overhead changes the timing enough to hide the race. :( I am compiling a new kernel with INVARIANTS and WITNESS now. Will wait for a "better" panic ;-) -- Dr. Yuri Khotyaintsev Institutet för rymdfysik (IRF), Uppsala ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fatal trap 12: page fault while in kernel mode
I have the following panic occurring several times a week. The machine is an
NFS server, and it usually panics early in the morning, when first people try
to access it. After reboot it may work OK for 1-2 days, and then panics
again. I have tried changing memory and replacing disk which was exported via
NFS, but nothing helped :(
Any suggestion on how to fix this panic will be very much appreciated !
/Yuri
[EMAIL PROTECTED]/var/crash]# uname -a
FreeBSD XXX.irfu.se 6.0-STABLE FreeBSD 6.0-STABLE #0: Tue Nov 29 13:31:15 CET
2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HEM i386
[EMAIL PROTECTED]/var/crash]# kgdb /usr/obj/usr/src/sys/HEM/kernel.debug
vmcore.7
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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-marcel-freebsd".
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x74
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc053a426
stack pointer = 0x28:0xd56c0b88
frame pointer = 0x28:0xd56c0b8c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 77 (vnlru)
trap number = 12
panic: page fault
Uptime: 2d12h22m11s
Dumping 511 MB (2 chunks)
chunk 0: 1MB (160 pages) ... ok
chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335
319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc051577a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
#2 0xc0515a84 in panic (fmt=0xc06ce475 "%s")
at /usr/src/sys/kern/kern_shutdown.c:555
#3 0xc06b4815 in trap_fatal (frame=0xd56c0b48, eva=0)
at /usr/src/sys/i386/i386/trap.c:836
#4 0xc06b3f2d in trap (frame=
{tf_fs = 1133445128, tf_es = 40, tf_ds = 40, tf_edi = -1017997312,
tf_esi = -1020120704, tf_ebp = -714339444, tf_isp = -714339468, tf_ebx =
-1012942272, tf_edx = -1020120704, tf_ecx = 0, tf_eax = 0, tf_trapno = 12,
tf_err = 0, tf_eip = -1068260314, tf_cs = 32, tf_eflags = 589831, tf_esp =
-1020120704, tf_ss = -714339408})
at /usr/src/sys/i386/i386/trap.c:269
#5 0xc06a24fa in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#6 0xc053a426 in turnstile_setowner (ts=0xc39fba40, owner=0x0)
at /usr/src/sys/kern/subr_turnstile.c:417
#7 0xc053a752 in turnstile_wait (lock=0xc461fe00, owner=0x0)
at /usr/src/sys/kern/subr_turnstile.c:576
#8 0xc050b511 in _mtx_lock_sleep (m=0xc461fe00, tid=3274846592, opts=0,
file=0x0, line=0)
at /usr/src/sys/kern/kern_mutex.c:555
#9 0xc064becd in ufsdirhash_free (ip=0xc4a33840)
at /usr/src/sys/ufs/ufs/ufs_dirhash.c:289
#10 0xc064de66 in ufs_reclaim (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_inode.c:175
#11 0xc06bef38 in VOP_RECLAIM_APV (vop=0x0, a=0xc3323180) at vnode_if.c:1589
#12 0xc057adfe in vgonel (vp=0xc3cf3aa0) at vnode_if.h:818
#13 0xc0577530 in vtryrecycle (vp=0xc3cf3aa0)
at /usr/src/sys/kern/vfs_subr.c:840
#14 0xc0576ec6 in vnlru_free (count=1376) at /usr/src/sys/kern/vfs_subr.c:668
#15 0xc0577019 in vnlru_proc () at /usr/src/sys/kern/vfs_subr.c:703
#16 0xc04fc310 in fork_exit (callout=0xc0576f24 , arg=0x0,
frame=0x0)
at /usr/src/sys/kern/kern_fork.c:789
#17 0xc06a255c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208
(kgdb) quit
--
Dr. Yuri Khotyaintsev
Institutet för rymdfysik (IRF), Uppsala
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
