Re: gmirror Issues
Hello! On Sun, Mar 25, 2007 at 05:12:59PM -0700, Joe Kelsey wrote: > The major thing that needs doing is a detailed explanation of how to > take two brand new disk drives and mirror them. Nothing in the > documentation discusses this. It is supposed to work like this: http://people.freebsd.org/~rse/mirror/ I've created two shellscripts for myself from that documentation that set up a mirrored system in no time. You need to recalculate the sizes for labelling the mirror manually, though. HTH, Patrick -- punkt.de GmbH * Vorholzstr. 25 * 76137 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 [EMAIL PROTECTED] http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: gmirror Issues
Regarding the gmirror talk: I found this helpful, as well: http://www.onlamp.com/pub/a/bsd/2005/11/10/FreeBSD_Basics.html Has there been any talk of a "gmirror aware" sysinstall that would adjust the size of the disk layout by one sector to ensure that the metadata is not overwritten? (and perhaps make loader.conf and fstab changes) As I understand it now, the user has to manually account for this at OS install, and adjust the disk layout accordingly... yes? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror Issues
> The major thing that needs doing is a detailed explanation of how to > take two brand new disk drives and mirror them. You're right. This is a tutorial. > Nothing in the > documentation discusses this. The in-tree documentation explains the syntax of the admin commands and the technical aspects of the subsystem. > Do you have to create file systems on the > drives first? No you use the raw devices. > Do you have to use fdisk to slice them up? You can do that. It is not required. > Is there a size limit on drives? The size limit would be file-system related; not gmirror. You're pretty safe into the terabytes with UFS2 > I am trying to mirror two 400G drives, is this > supported? Sure, follow the RSE link you were sent. > There is no information anywhere that I can find about these > topics. Always search the mailing list archives. > /Joe > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror Issues
On Mar 25, 2007, at 5:12 PM, Joe Kelsey wrote: Ivan Voras wrote: Joe Kelsey wrote: So, after loading the mirror stuff, I regularly lock up the system by trying to perform simple activities on the mirror. What do I need to do differently? Here are the relevant dmesg lines: atapci0: port 0xa000-0xa007,0x9800-0x9803,0x9400-0x9407,0x9000-0x9003,0x8800-0x880 f mem 0xfba0-0xfba001ff irq 18 at device 13.0 on pci0 I did almost the same thing you did with gmirror on 6.2-release on amd64 the other day and it worked. There were several complaints about "SiI" hardware in the past, though - you might want to search the lists. Thank you for the suggestion, but it does not help. There is some traffic on the list about the 3112, but I have a 3512, which does not have any list traffic about bugs. The major thing that needs doing is a detailed explanation of how to take two brand new disk drives and mirror them. Nothing in the documentation discusses this. Do you have to create file systems on the drives first? Do you have to use fdisk to slice them up? Is there a size limit on drives? I am trying to mirror two 400G drives, is this supported? There is no information anywhere that I can find about these topics. Have you seen this: http://people.freebsd.org/~rse/mirror/ g. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: socketpair: No buffer space available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Monday, March 26, 2007 00:08:07 +0100 "Bruce M. Simpson" <[EMAIL PROTECTED]> wrote: > Marc G. Fournier wrote: >> Mar 20 07:59:26 mars sshd[717]: error: reexec socketpair: No buffer space >> available >> >> >> If I have a login session on the machine, I can easily do a reboot of the >> machine, and it seems to come up clean every time (ie. no fsck's need to be >> run) ... >> Does anyone have any ideas of what I can look at? >> > How odd. The re-exec feature is not documented in the man page. It appears > that it can be turned off with the -r switch according to sshd.c. Can you > give that a try and see if that offers symptomatic relief? It would be > somewhat less secure as sshd will fork rather than fork..exec. That was actually just one example ... I get more of: sendmail[82066]: l2NEA1Ht082066: SYSERR(root): makeconnection: cannot create socket: No buffer space available then I do the sshd errors ... in another 15 hours or so, they will all start up again, like clock work :( - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGBxZ84QvfyHIvDvMRAoNTAKDBkGZL7aCOXEW22QibCCpnJJJnEgCfafMa ex0pM7sKPgCjVdURJ9nwfH0= =egaO -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror Issues
Ivan Voras wrote: Joe Kelsey wrote: So, after loading the mirror stuff, I regularly lock up the system by trying to perform simple activities on the mirror. What do I need to do differently? Here are the relevant dmesg lines: atapci0: port 0xa000-0xa007,0x9800-0x9803,0x9400-0x9407,0x9000-0x9003,0x8800-0x880f mem 0xfba0-0xfba001ff irq 18 at device 13.0 on pci0 I did almost the same thing you did with gmirror on 6.2-release on amd64 the other day and it worked. There were several complaints about "SiI" hardware in the past, though - you might want to search the lists. Thank you for the suggestion, but it does not help. There is some traffic on the list about the 3112, but I have a 3512, which does not have any list traffic about bugs. The major thing that needs doing is a detailed explanation of how to take two brand new disk drives and mirror them. Nothing in the documentation discusses this. Do you have to create file systems on the drives first? Do you have to use fdisk to slice them up? Is there a size limit on drives? I am trying to mirror two 400G drives, is this supported? There is no information anywhere that I can find about these topics. /Joe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror Issues
Joe Kelsey wrote: > The major thing that needs doing is a detailed explanation of how to > take two brand new disk drives and mirror them. Nothing in the > documentation discusses this. Do you have to create file systems on the This is actually easy: 1. Create everything you need on the first drive (ok, you don't need *everything* - just the base system and partitions) 2. gmirror label myraid mydrive0 3. gmirror insert myraid mydrive1 This way, mydrive0 will be the "master", which would be replicated on the mydrive1 hereafter. After the first sync is complete, they will be equal and mirrored. If the mirror is your root drive, don't forget to fixup fstab and add geom_mirror module to the loader before rebooting. signature.asc Description: OpenPGP digital signature
Re: Processes get stuck in "ufs" state
Цитирую Oleg Derevenetz <[EMAIL PROTECTED]>: > On Wed, Mar 07, 2007 at 05:22:38AM +0300, Oleg Derevenetz wrote: > > >> Sometimes (once a week approximately) I have a problem with the same > >> symptoms described here on SMP FreeBSD 6.2-STABLE with dual AMD > Opteron(tm) > >> Processor 850: > >> > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=104406&cat= > >> > >> Sometimes (apparently when CPU load suddenly goes up) all processes > that > >> interacts with disk gets stuck in "ufs" state, but in my case > >> SIGSTOP/SIGCONT seemingly does not help. > > > > See developer handbook, Deadlock Debugging chapter for instruction > what > > information shall be gathered to debug the problem. > > OK, I built kernel with debug options and will wait for stuck. By the > way, when debug options turned on, I see this message on every > boot when nullfs mounting in progress: > > acquiring duplicate lock of same type: "vnode interlock" > 1st vnode interlock @ /usr/src/sys/kern/vfs_vnops.c:806 > 2nd vnode interlock @ /usr/src/sys/kern/vfs_subr.c:2040 > KDB: stack backtrace: > kdb_backtrace(3,cfc60300,c05926d0,c05926d0,c05542c4,...) at > kdb_backtrace+0x29 > witness_checkorder(cfd5c4dc,9,c051cf1e,7f8) at witness_checkorder+0x578 > _mtx_lock_flags(cfd5c4dc,0,c051cf1e,7f8,cfb28b90,...) at > _mtx_lock_flags+0x78 > vrefcnt(cfd5c414) at vrefcnt+0x20 > null_checkvp(cff5eae0,c050c4a6,215) at null_checkvp+0x56 > null_lock(f02f1a68) at null_lock+0x66 > VOP_LOCK_APV(c054d540,f02f1a68) at VOP_LOCK_APV+0x87 > vn_lock(cff5eae0,1002,cfc60300,cff5eae0,cff5ed04,...) at vn_lock+0xac > nullfs_root(cff76b90,2,f02f1ae0,cfc60300,0,8,0,c05cfca0,0,c051c79c,407) > at nullfs_root+0x26 > vfs_domount(cfc60300,cfe3d340,cfe3d130,d,cfe3d3f0,c05817e0,0,c051c79c,2bf) > at vfs_domount+0x975 > vfs_donmount(cfc60300,d,cfe73080,cfe73080,0,...) at vfs_donmount+0x3f9 > nmount(cfc60300,f02f1d04) at nmount+0x8b > syscall(3b,3b,3b,bf7fe5f5,bf7feea0,...) at syscall+0x25b > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280bc0e7, esp = > 0xbf7fe5bc, ebp = 0xbf7fee38 --- > > This host have nullfs filesystems. Is this can be related to deadlock ? FYI: after replacing nullfs filesystems with unionfs (using new unionfs implementation): http://people.freebsd.org/~daichi/unionfs/ all deadlocks are gone. It seems to be a problem in current nullfs implementation, but I can't debug it properly because deadlock cases are relatively rare and machine that uses nullfs is heavily loaded so WITNESS and DEBUG options leads to unacceptable performance penalty. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: socketpair: No buffer space available
Marc G. Fournier wrote: Mar 20 07:59:26 mars sshd[717]: error: reexec socketpair: No buffer space available If I have a login session on the machine, I can easily do a reboot of the machine, and it seems to come up clean every time (ie. no fsck's need to be run) ... Does anyone have any ideas of what I can look at? How odd. The re-exec feature is not documented in the man page. It appears that it can be turned off with the -r switch according to sshd.c. Can you give that a try and see if that offers symptomatic relief? It would be somewhat less secure as sshd will fork rather than fork..exec. The code does indeed appear to use socketpair. FreeBSD implements socketpair as a system call. Only AF_UNIX, SOCK_STREAM sockets are accepted. A quick look in KScope suggests the first place where this can fail with ENOBUFS is soalloc() from socreate(). Is this machine under heavy memory load in any way? soalloc() uses a zone allocator. I'm not sure how to track that from userland, vmstat -m only deals with kernel malloc() stats. BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror Issues
Joe Kelsey wrote: > So, after loading the mirror stuff, I regularly lock up the system by > trying to perform simple activities on the mirror. What do I need to do > differently? > > Here are the relevant dmesg lines: > atapci0: port > 0xa000-0xa007,0x9800-0x9803,0x9400-0x9407,0x9000-0x9003,0x8800-0x880f > mem 0xfba0-0xfba001ff irq 18 at device 13.0 on pci0 I did almost the same thing you did with gmirror on 6.2-release on amd64 the other day and it worked. There were several complaints about "SiI" hardware in the past, though - you might want to search the lists. signature.asc Description: OpenPGP digital signature
gmirror Issues
I am having a real hard time with gmirror. I recently bought two new 400G SATA disks and I want to mirror them. I think I am following the directions, but I am not sure. I generally do the following steps: edit /boot/loader.conf to add geom_mirror_load. reboot into single-user gmirror label -v -b round-robin gm0 ad4s1 ad6s1 bsdlabel -w mirror/gm0 bsdlabel -e mirror/gm0 newfs mirror/gm0a When I attempt to perform the newfs, it generally goes through all of the backup super blocks and hangs the system at the end of the newfs. At that point, my only recourse is pushing the reset button. When the system comes up, GEOM_MIRROR tries to rebuild one of the providers (usually ad4s1), but never seems to succeed. Anyway, the first problem I had was not having geom_mirror loaded. The only solution seems to be adding the load to /boot/loader.conf. None of the manual pages or handbook pages says anything about this except when discusssing making your system disk mirrored. I am not doing that. So, after loading the mirror stuff, I regularly lock up the system by trying to perform simple activities on the mirror. What do I need to do differently? Here are the relevant dmesg lines: atapci0: port 0xa000-0xa007,0x9800-0x9803,0x9400-0x9407,0x9000-0x9003,0x8800-0x880f mem 0xfba0-0xfba001ff irq 18 at device 13.0 on pci0 ata2: on atapci0 ata3: on atapci0 ad4: 381554MB at ata2-master SATA150 ad6: 381554MB at ata3-master SATA150 FreeBSD zircon.zircon.seattle.wa.us 6.2-STABLE FreeBSD 6.2-STABLE #0: Sat Mar 24 16:32:06 PDT 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ZIRCON amd64 amd64 amd64 FreeBSD /Joe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: bsdlabel blues again
Michel, On 12/23/-58 20:59, Michel Talon wrote: > Volker said: > >> As I've done this procedure twice yesterday and once more today, >> I've double and triple checked everything but I'm running into one >> single problem: >> >> partition c extends past end of unit and doesn't start at 0. > > I think you should run bsdlabel on the mirror, not on the > raw partitions or disks. Then you will have no more problem > of the above type, only the innocuous following one: Thanks for your answer but I should have stated in my first message I'm not a totally stupid bloody newby. I do know the difference between raw disk slices and mirrored slices. I've also done this procedure a lot times before with less trouble. I was talking about something what I would like to name a bug or call it strange behavior. Just for the archives, I've got it working now. As I've converted from one (working) mirror to another, gmirror seemed to cache slice / partition infos. To work around that kind of trouble, one needs to create the slices, label the mirror, reboot (!) and then continue with partioning. Otherwise gmirror is working on old, cached values which will give out of bound partitioning values. Creating the slices, label the mirror and create the partitions in one go will most likely get you to bad partition values. This extra step of rebooting should most likely not be needed if one is able to `gmirror load' after labeling the mirror but in my case I've been unable to unload gmirror because I've already been working on a live mirror. So the reboot was needed as there's no command to re-sync geom values. My description does not mean to be technically correct but this is what I've experienced and the only thing I can imagine what's going on in the background. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
freebsd-update changes kernel to SMP-GENERIC
Colin Percival wrote: > Jan Henrik Sylvester wrote: > > Before the last freebsd-update, I had a GENERIC kernel installed. > > Are you sure? :-) I was... since I "always" had one, but looking at my old logs, I found: FreeBSD 6.2-RELEASE #0: Fri Jan 12 11:05:30 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP Sorry for bothering you! (kern.bootfile: /boot/kernel/kernel) Jan Henrik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-update changes kernel to SMP-GENERIC
Jan Henrik Sylvester wrote: > Before the last freebsd-update, I had a GENERIC kernel installed. Are you sure? :-) > Now 'uname -v -i' gives me: > > FreeBSD 6.2-RELEASE-p2 #0: Tue Feb 27 22:56:09 UTC 2007 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP SMP-GENERIC > > Did something go wrong? What does `sysctl kern.bootfile` say? Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
freebsd-update changes kernel to SMP-GENERIC
Hello! Before the last freebsd-update, I had a GENERIC kernel installed. Now 'uname -v -i' gives me: FreeBSD 6.2-RELEASE-p2 #0: Tue Feb 27 22:56:09 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP SMP-GENERIC Did something go wrong? Does SMP have any negative side effects (Pentium M)? Should I rollback? (Is this related to FreeBSD-EN-07:05.freebsd-update.asc?) Thanks Jan Henrik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Amd64 Unstable Areca
Nikolas Britton wrote: Yeah are hardware is nearly identical. I don't remember what I did to my custom driver, I know I fixed some syntax errors and merged in changes that were made on top of the 1.20.00.02 code base. I'm not sure but I think most of those changes were thrown out with the import of 1.20.00.13 and 14. Yes ..0.13 is the driver from 6.2-RELEASE-p2 and no I don't see any g_vfs errors, I do see a crap load of httpd errors that someone needs to investigate, lucky me. :-/ It's not likely I'd see them anyhow because the business slows way down during this time of year: Please try the following patch against the latest 6-STABLE driver sources: http://people.freebsd.org/~scottl/arcmsr.simq.diff. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
options VFS_AIO vs. qemu vs. shell accounts
Hi, sys/conf/NOTES contains this comment in RELENG_6 (for as long as the AIO option exists, which is more than 7 years): # Use real implementations of the aio_* system calls. There are numerous # stability and security issues in the current aio code that make it # unsuitable for inclusion on machines with untrusted local users. options VFS_AIO Does that warning about stability and security issues still apply on RELENG_6? If it does, is somebody working on a fix for that? The problem is that recent versions of qemu seem to require AIO (for IDE DMA). Given the above comment, it seems to be impossible to use qemu on machines with shell accounts. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Being really good at C++ is like being really good at using rocks to sharpen sticks." -- Thant Tessman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kernel crash ... httpd process ??
Hello,
This morning, I found my web server rebooted after a kernel crash. You
can find below a debug of the kernel but I do not see anything special
except it seems there was a problem with httpd process.
This machine is hosting 16 jails machines, all of them running with
Apache-1.3.37 or Apache-2.059 with a FreeBSD-6.2 on an SMP athlon-mp
host with 2Go ECC Registered memory.
Thanks to help me.
Vincent.
---
kgdb kernel.debug /var/crash/vmcore.0
[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:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 00
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x20:0x0
stack pointer = 0x28:0xece02a48
frame pointer = 0x28:0xece02a58
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 25063 (httpd)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 9d4h35m19s
Dumping 2047 MB (3 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 2046MB (523760 pages) 2030 2014 1998 1982 1966 1950 1934 1918
1902 1886 1870 1854 1838
1822 1806 1790 1774 1758 1742 1726 1710 1694 1678 1662 1646 1630 1614
1598 1582 1566 1550 1534 1
518 1502 1486 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310
1294 1278 1262 1246 1230 121
4 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 1038 1022 1006 990
974 958 942 926 910 894 87
8 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606
590 574 558 542 526 510 494
478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206
190 174 158 142 126 110
94 78 62 46 30 14 ... ok
chunk 2: 1MB (128 pages)
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb)
(kgdb)
(kgdb) list *0x20:0x0
A syntax error in expression, near `:0x0'.
(kgdb) list *0x20
No source file for address 0x20.
(kgdb) backtrace
#0 doadump () at pcpu.h:165
#1 0xc0549dc2 in boot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc054a0e9 in panic (fmt=0xc06ee065 "%s")
at /usr/src/sys/kern/kern_shutdown.c:565
#3 0xc06c9a00 in trap_fatal (frame=0xece02a08, eva=0)
at /usr/src/sys/i386/i386/trap.c:837
#4 0xc06c973f in trap_pfault (frame=0xece02a08, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:745
#5 0xc06c9399 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -951789624, tf_esi =
-962362032, tf_ebp = -320853416, tf_isp = -320853452, tf_ebx = 4, tf_edx
= -965622128, tf_ecx = 4, tf_eax = -949792768, tf_trapno = 12, tf_err =
0, tf_eip = 0, tf_cs = 32, tf_eflags = 2163202, tf_esp = -951269120,
tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:435
#6 0xc06b5dda in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0x in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) quit
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
