SMP Kernel Panic while heavy load.
Hi, My FreeBSD server panic while running SMP kernel. All work fine if disable SMP feature. uname log: http://upload.hshh.org/homes/hshh/temp/panic/uname.log My kernel conf: http://upload.hshh.org/homes/hshh/temp/panic/kernel.log Backtrace log: http://upload.hshh.org/homes/hshh/temp/panic/kgdb.log ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG 6.1/AMD64 system hangs when SMP enabled
Hi all, I turned kernel debuging on and tried the key combinations when the machine was stuck but it did not really help because the machine was not responding to this. I do think that I might have found the cause of the problem. I was running powerd and the cpufreq module was loaded each I had problems. I now turned powerd of and did not load the cpufreq module and the machine is now running for 23 days in a row. Does anybody know wether this is possible/makes sense ? kind regards Kris Kennaway schreef: On Fri, Oct 27, 2006 at 09:35:09AM +0200, bram wrote: Hi all, I'm rather new to freebsd so forgive me if I am saying things that don't make sense. I have a dual opteron server running freebsd 6.1/amd64 updated 4 weeks ago. Since I moved to 6 I've been having tho following problem. When I put heavy load on the server (python scripts that take 20 minutes to complete) the server sometimes hangs. I can then not ping it anymore and it does not respond to anything (no keyboard power button etc.). Mostly there are no error messages or anything so I have no clue to what the problem is. One time it did give an error but I did not wrote it down, but as I recall it was something like SMP spin lock timed out. It hangs every three weeks Please give me some info on how I can get it to give more info or how to resolve this problem. See the chapter on kernel debugging in the develpers handbook Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
amd64 systems hanging with powerd (Re: RELENG 6.1/AMD64 system hangs when SMP enabled)
On Fri, Dec 15, 2006 at 09:22:32AM +0100, Bram wrote: Hi all, I turned kernel debuging on and tried the key combinations when the machine was stuck but it did not really help because the machine was not responding to this. I do think that I might have found the cause of the problem. I was running powerd and the cpufreq module was loaded each I had problems. I now turned powerd of and did not load the cpufreq module and the machine is now running for 23 days in a row. Does anybody know wether this is possible/makes sense ? The same thing happens on this athlon64 X2. Kris pgp3ccqFfrrC4.pgp Description: PGP signature
Re: p5-Quota issues
Olivier Mueller wrote: Le 15 déc. 06 à 00:57, Oliver Fromme a écrit : Olivier Mueller wrote: I'm trying to get a script working with the p5-Quota module, but no way... : - quota correctely working for the /home partition - tested with edquota/repquota, etc. But when trying to retrieve information or setup quota information from a perl script, I get: Quota::sync: error #45 I guess that's an errno number, and in that case 45 is EOPNOTSUPP (Operation not supported). It is a bug that the errno number is not printed as a human-readable string. Did you try to use Quota::query? Does it work? Tried yes, work: no. Which means, exactly? Same error message? Are you sure that you specify the file system correctly? Is your kernel compiled with options QUOTA? But what bothers me more is that exactely the same script (with the same module) is working fine under linux... According to the p5-Quota documentation, the Quota::sync function is not supported on all platforms, so it's perfectly possible that the p5-Quota code supports it on Linux, but not on FreeBSD. Well, in this case, why would there be a freebsd port for this module? :-) The sync function is optional and not necessarily required for the rest of the module to be useful. (Although it _should_ work on FreeBSD.) Of course, if the query function doesn't work either, then there really is something wrong. I'll continue my tests... And if it doesn't work, I'll simply use the system commands That's how I do it in a Python program. Since I'm not querying quotas ten times per second or so, calling the system commands isn't really a problem. instead of the perl module, but then I would have to rewrite some part of my scripts. Well, should be just three or four lines. In my Python program I'm doing it's the following code (this won't help you, I'm afraid, but I'm quoting it so someone who searches the archives might find it helpful): quotas = dict([ (user, qinfo.split()) for line in getoutput(repquota -a /home).splitlines()[2:] for user, qinfo in [line.split(None,1)] ]) That creates a dictionary (Perl calls it a hash) with the user names as keys and their quota information as values (a list with 9 string elements, corresponding to the columns in repquota output). E.g. quotas[joe][2] will give the soft blocks limit of user joe. If quotas are disabled, the dictionary is empty, so you can simply write if quotas: ... or if not quotas: ... to check whether quotas are enabled at all. I'm sure you can do it similarly in Perl. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind. -- Alan Kay, OOPSLA '97 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Poor NFS performance after recent update
Kimi Ostro [EMAIL PROTECTED] wrote: fserver:/data /media/datanfs rw,-b,-i,-s,-L,noauto A small side note (probably not related to your actual problem): It is usually a bad idea to use the -s (soft) option, because many programs are not prepared to handle unexpected I/O errors, leading to file corruption. The following is an excerpt from the Solaris docs, which applies to FreeBSD as well: | File systems that are mounted read-write or that con- | tain executable files should always be mounted with | the hard option. Applications using soft mounted file | systems may incur unexpected I/O errors, file corrup- | tion, and unexpected program core dumps. The soft | option is not recommended. I think a similar paragraph should be added to FreeBSD's mount_nfs(8) manpage and to the Handbook. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. I have stopped reading Stephen King novels. Now I just read C code instead. -- Richard A. O'Keefe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP Kernel Panic while heavy load.
hshh wrote: Hi, My FreeBSD server panic while running SMP kernel. All work fine if disable SMP feature. uname log: http://upload.hshh.org/homes/hshh/temp/panic/uname.log My kernel conf: http://upload.hshh.org/homes/hshh/temp/panic/kernel.log Backtrace log: http://upload.hshh.org/homes/hshh/temp/panic/kgdb.log Would you please disable ZEROCOPY_SOCKETS and try if things gets improved? Cheers, -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: make buildworld
zen wrote: dear all, i have a problem during upgrading my FreeBSD box to 6.1, this error occured during make buildworld. these are the error mesages: _tools/../../../../contrib/gcc/genemit.c /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genemit.c: In function `gen_expand': /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genemit.c:546: internal compiler error: Segmentation fault: 11 That looks like faulty memory or a temperature problem. Such problems normally only show on very high load. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[CALL FOR TESTERS] (was: ral(4) and second/third gen devices)
Hi! On Fri, Dec 15, 2006 at 06:53:52AM +, Matt Dawson wrote: Is there any timescale/possibility of a MFC of the ral driver that Damien has added second and third generation support to? It is becoming increasingly hard to lay one's hands on first gen kit, especially in MiniPCI. If not, is there a patch lurking somewhere to add this to the RELENG_6_2 branch? Please try this patch: http://samodelkin.net/~fjoe/if_ral.diff Works for me for some RT2561-based card for about 6 months. I had to merge some fixes from OpenBSD (to HEAD) in order to fix a panic during interface reconfiguration. I hesitate to MFC this because the driver has been heavily refactored and I do not have RT2560 card to test with. Any reports from owners of Ralink RT2560-based cards about this patch are highly appreciated. Unfortunately Damien no longer maintains FreeBSD driver. /fjoe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze
Hi, we too, ran into this problem. OS/2 Clients kill our NFS server. It is running a RELENG_6 snapshot from 2006-11-14. rpc.lockd and rpc.statd are running. I'll conduct a test without those two services shortly. You can still log in the system with ssh and cruse around, but mountd is stuck in ufs state and is no longer serving requests. [EMAIL PROTECTED]:~# ps axl | grep ufs 0 39370 1 0 -4 0 3052 2200 ufsDs??0:00.01 /usr/sbin/mountd -r db show lockedvnods Locked vnodes 0xc87b9414: tag ufs, type VDIR usecount 0, writecount 0, refcount 4 mountedhere 0 flags (VV_ROOT) v_object 0xc8c43c60 ref 0 pages 1 lock type ufs: EXCL (count 4) by thread 0xc8bac300 (pid 6926) with 1 pending#0 0xc0668bf9 at lockmgr+0x4ed #1 0xc078572e at ffs_lock+0x76 #2 0xc0838287 at VOP_LOCK_APV+0x87 #3 0xc06d663c at vn_lock+0xac #4 0xc06ca4ca at vget+0xc2 #5 0xc06c24a9 at vfs_hash_get+0x8d #6 0xc07844af at ffs_vget+0x27 #7 0xc078b253 at ufs_lookup+0xa4b #8 0xc083641b at VOP_CACHEDLOOKUP_APV+0x9b #9 0xc06bf499 at vfs_cache_lookup+0xb5 #10 0xc0836347 at VOP_LOOKUP_APV+0x87 #11 0xc06c3626 at lookup+0x46e #12 0xc0734fba at nfs_namei+0x40e #13 0xc0726d81 at nfsrv_lookup+0x1dd #14 0xc0736765 at nfssvc_nfsd+0x3d9 #15 0xc07360b4 at nfssvc+0x18c #16 0xc0825a07 at syscall+0x25b #17 0xc0811f7f at Xint0x80_syscall+0x1f ino 2, on dev da1s2e db trace 6926 Tracing pid 6926 tid 100106 td 0xc8bac300 sched_switch(c8bac300,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 sleepq_switch(c8678200) at sleepq_switch+0xc1 sleepq_wait_sig(c8678200) at sleepq_wait_sig+0x1d msleep(c8678200,c09c9f00,158,c088bec9,0,...) at msleep+0x26a nfssvc_nfsd(c8bac300) at nfssvc_nfsd+0xe5 nfssvc(c8bac300,eafd4d04) at nfssvc+0x18c syscall(3b,3b,3b,1,0,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (155, FreeBSD ELF32, nfssvc), eip = 0x280bd1b7, esp = 0xbfbfe90c, ebp = 0xbfbfe928 --- db trace 39370 Tracing pid 39370 tid 100102 td 0xc8bac900 sched_switch(c8bac900,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 sleepq_switch(c87b946c,c0973440,0,c089798c,211,...) at sleepq_switch+0xc1 sleepq_wait(c87b946c,0,c87b94dc,b7,c08929b8,...) at sleepq_wait+0x46 msleep(c87b946c,c0972500,50,c089c1c1,0,...) at msleep+0x279 acquire(eafe094c,40,6,c8bac900,0,...) at acquire+0x76 lockmgr(c87b946c,2002,c87b94dc,c8bac900) at lockmgr+0x44e ffs_lock(eafe09a4) at ffs_lock+0x76 VOP_LOCK_APV(c0943320,eafe09a4) at VOP_LOCK_APV+0x87 vn_lock(c87b9414,2002,c8bac900,c87b9414) at vn_lock+0xac vget(c87b9414,2002,c8bac900) at vget+0xc2 vfs_hash_get(c86cf2e4,2,2,c8bac900,eafe0abc,0,0) at vfs_hash_get+0x8d ffs_vget(c86cf2e4,2,2,eafe0abc) at ffs_vget+0x27 ufs_root(c86cf2e4,2,eafe0b00,c8bac900,0,...) at ufs_root+0x19 lookup(eafe0ba0) at lookup+0x743 namei(eafe0ba0) at namei+0x39a kern_lstat(c8bac900,bfbfd2a0,0,eafe0c74) at kern_lstat+0x47 lstat(c8bac900,eafe0d04) at lstat+0x1b syscall(3b,3b,3b,281512fb,bfbfc9f1,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (190, FreeBSD ELF32, lstat), eip = 0x2813d427, esp = 0xbfbfc5ac, ebp = 0xbfbfd268 --- I was under the impression, that you are not allowed to sleep while holding a lock in the FreeBSD kernel. Doesn't this also apply to the lockmgr itself? Upon shutting down the system, I had a panic coming in: panic: userret: Returning with 4 locks held. cpuid = 1 KDB: stack backtrace: kdb_backtrace(100,c8bac300,c8bac3c8,c8bad218,c8bac300,...) at kdb_backtrace+0x29 panic(c089806f,4,0,c8bac300,c8bad218,...) at panic+0x114 userret(c8bac300,eafd4d38,0,2,0,...) at userret+0x183 syscall(3b,3b,3b,1,0,...) at syscall+0x321 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (0, FreeBSD ELF32, nosys), eip = 0x280bd1b7, esp = 0xbfbfe90c, ebp = 0xbfbfe928 --- KDB: enter: panic [thread pid 6926 tid 100106 ] Stopped at kdb_enter+0x2b: nop db bt Tracing pid 6926 tid 100106 td 0xc8bac300 kdb_enter(c0894aec) at kdb_enter+0x2b panic(c089806f,4,0,c8bac300,c8bad218,...) at panic+0x127 userret(c8bac300,eafd4d38,0,2,0,...) at userret+0x183 syscall(3b,3b,3b,1,0,...) at syscall+0x321 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (0, FreeBSD ELF32, nosys), eip = 0x280bd1b7, esp = 0xbfbfe90c, ebp = 0xbfbfe928 --- db show lockedvnods Locked vnodes 0xc8761c3c: tag ufs, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0xc86cf2e4 flags () lock type ufs: EXCL (count 1) by thread 0xc8bac780 (pid 59934)#0 0xc0668bf9 at lockmgr+0x4ed #1 0xc078572e at ffs_lock+0x76 #2 0xc0838287 at VOP_LOCK_APV+0x87 #3 0xc06d663c at vn_lock+0xac #4 0xc06c5eba at dounmount+0x62 #5 0xc06c5e31 at unmount+0x1e5 #6 0xc0825a07 at syscall+0x25b #7 0xc0811f7f at Xint0x80_syscall+0x1f ino 8260, on dev ufs/root 0xc87b9414: tag ufs, type VDIR usecount 0, writecount 0, refcount 4 mountedhere 0 flags (VV_ROOT) v_object 0xc8c43c60 ref 0 pages 1 lock type ufs: EXCL (count 4) by thread 0xc8bac300 (pid 6926) with 1 pending#0 0xc0668bf9 at
Re: [CALL FOR TESTERS] (was: ral(4) and second/third gen devices)
On Friday 15 December 2006 12:00, [EMAIL PROTECTED] wrote: Please try this patch: http://samodelkin.net/~fjoe/if_ral.diff This won't compile on my system (6.1-RELEASE-p11). Any ideas? linking kernel if_ral_pci.o(.data+0x120): undefined reference to `rt2661_attach' if_ral_pci.o(.data+0x124): undefined reference to `rt2661_detach' if_ral_pci.o(.data+0x128): undefined reference to `rt2661_shutdown' if_ral_pci.o(.data+0x12c): undefined reference to `rt2661_suspend' if_ral_pci.o(.data+0x130): undefined reference to `rt2661_resume' if_ral_pci.o(.data+0x134): undefined reference to `rt2661_intr' if_ral_pci.o(.data+0x138): undefined reference to `rt2560_attach' if_ral_pci.o(.data+0x13c): undefined reference to `rt2560_detach' if_ral_pci.o(.data+0x140): undefined reference to `rt2560_shutdown' if_ral_pci.o(.data+0x144): undefined reference to `rt2560_suspend' if_ral_pci.o(.data+0x148): undefined reference to `rt2560_resume' if_ral_pci.o(.data+0x14c): undefined reference to `rt2560_intr' *** Error code 1 Stop in /usr/obj/usr/src/sys/LAPTOP64. -- Matt Dawson. [EMAIL PROTECTED] MTD15-RIPE OpenNIC M_D9 MD51-6BONE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1955 Blade - Broadcom NIC not detected (BCM5708S)
On Mon, Oct 30, 2006 at 04:17:00PM +0200, Conrad Burger wrote: I am trying to get FreeBSD to work on a Dell 1955 blade. Looks like the NICs on the blade are not supported by the BCE or BGE driver. On Linux the NICs are identified as 06:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (rev 11) From if_bce.c - * The following controllers are not supported by this driver: * (These are not Production versions of the controller.) * BCM5706C A0, A1 * BCM5706S A0, A1, A2, A3 * BCM5708C A0, B0 * -- BCM5708S -- A0, B0, B1 Is there any reason why the chipset is not supported? Is there anyway of getting the BCE or BGE driver to work with this chipset? Will it be supported sometime in the near future? Any help would be much appreciated. Any development here? We have just started purchasing 1955 Blades and would very much like to install FreeBSD on them :) with regards, -- Morten A. Middelthon To err is human, to forgive is Not Company Policy. pgpzRJQjSAMF2.pgp Description: PGP signature
Re: kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze
On Fri, Dec 15, 2006 at 01:44:23PM +0100, Ulrich Spoerlein wrote: Hi, we too, ran into this problem. OS/2 Clients kill our NFS server. It is running a RELENG_6 snapshot from 2006-11-14. rpc.lockd and rpc.statd are running. I'll conduct a test without those two services shortly. You can still log in the system with ssh and cruse around, but mountd is stuck in ufs state and is no longer serving requests. [EMAIL PROTECTED]:~# ps axl | grep ufs 0 39370 1 0 -4 0 3052 2200 ufsDs??0:00.01 /usr/sbin/mountd -r db show lockedvnods Locked vnodes 0xc87b9414: tag ufs, type VDIR usecount 0, writecount 0, refcount 4 mountedhere 0 flags (VV_ROOT) v_object 0xc8c43c60 ref 0 pages 1 lock type ufs: EXCL (count 4) by thread 0xc8bac300 (pid 6926) with 1 pending#0 0xc0668bf9 at lockmgr+0x4ed #1 0xc078572e at ffs_lock+0x76 #2 0xc0838287 at VOP_LOCK_APV+0x87 #3 0xc06d663c at vn_lock+0xac #4 0xc06ca4ca at vget+0xc2 #5 0xc06c24a9 at vfs_hash_get+0x8d #6 0xc07844af at ffs_vget+0x27 #7 0xc078b253 at ufs_lookup+0xa4b #8 0xc083641b at VOP_CACHEDLOOKUP_APV+0x9b #9 0xc06bf499 at vfs_cache_lookup+0xb5 #10 0xc0836347 at VOP_LOOKUP_APV+0x87 #11 0xc06c3626 at lookup+0x46e #12 0xc0734fba at nfs_namei+0x40e #13 0xc0726d81 at nfsrv_lookup+0x1dd #14 0xc0736765 at nfssvc_nfsd+0x3d9 #15 0xc07360b4 at nfssvc+0x18c #16 0xc0825a07 at syscall+0x25b #17 0xc0811f7f at Xint0x80_syscall+0x1f ino 2, on dev da1s2e db trace 6926 Tracing pid 6926 tid 100106 td 0xc8bac300 sched_switch(c8bac300,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 sleepq_switch(c8678200) at sleepq_switch+0xc1 sleepq_wait_sig(c8678200) at sleepq_wait_sig+0x1d msleep(c8678200,c09c9f00,158,c088bec9,0,...) at msleep+0x26a nfssvc_nfsd(c8bac300) at nfssvc_nfsd+0xe5 nfssvc(c8bac300,eafd4d04) at nfssvc+0x18c syscall(3b,3b,3b,1,0,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (155, FreeBSD ELF32, nfssvc), eip = 0x280bd1b7, esp = 0xbfbfe90c, ebp = 0xbfbfe928 --- db trace 39370 Tracing pid 39370 tid 100102 td 0xc8bac900 sched_switch(c8bac900,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 sleepq_switch(c87b946c,c0973440,0,c089798c,211,...) at sleepq_switch+0xc1 sleepq_wait(c87b946c,0,c87b94dc,b7,c08929b8,...) at sleepq_wait+0x46 msleep(c87b946c,c0972500,50,c089c1c1,0,...) at msleep+0x279 acquire(eafe094c,40,6,c8bac900,0,...) at acquire+0x76 lockmgr(c87b946c,2002,c87b94dc,c8bac900) at lockmgr+0x44e ffs_lock(eafe09a4) at ffs_lock+0x76 VOP_LOCK_APV(c0943320,eafe09a4) at VOP_LOCK_APV+0x87 vn_lock(c87b9414,2002,c8bac900,c87b9414) at vn_lock+0xac vget(c87b9414,2002,c8bac900) at vget+0xc2 vfs_hash_get(c86cf2e4,2,2,c8bac900,eafe0abc,0,0) at vfs_hash_get+0x8d ffs_vget(c86cf2e4,2,2,eafe0abc) at ffs_vget+0x27 ufs_root(c86cf2e4,2,eafe0b00,c8bac900,0,...) at ufs_root+0x19 lookup(eafe0ba0) at lookup+0x743 namei(eafe0ba0) at namei+0x39a kern_lstat(c8bac900,bfbfd2a0,0,eafe0c74) at kern_lstat+0x47 lstat(c8bac900,eafe0d04) at lstat+0x1b syscall(3b,3b,3b,281512fb,bfbfc9f1,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (190, FreeBSD ELF32, lstat), eip = 0x2813d427, esp = 0xbfbfc5ac, ebp = 0xbfbfd268 --- I was under the impression, that you are not allowed to sleep while holding a lock in the FreeBSD kernel. Doesn't this also apply to the lockmgr itself? Upon shutting down the system, I had a panic coming in: panic: userret: Returning with 4 locks held. cpuid = 1 KDB: stack backtrace: kdb_backtrace(100,c8bac300,c8bac3c8,c8bad218,c8bac300,...) at kdb_backtrace+0x29 panic(c089806f,4,0,c8bac300,c8bad218,...) at panic+0x114 userret(c8bac300,eafd4d38,0,2,0,...) at userret+0x183 syscall(3b,3b,3b,1,0,...) at syscall+0x321 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (0, FreeBSD ELF32, nosys), eip = 0x280bd1b7, esp = 0xbfbfe90c, ebp = 0xbfbfe928 --- KDB: enter: panic [thread pid 6926 tid 100106 ] Stopped at kdb_enter+0x2b: nop db bt Tracing pid 6926 tid 100106 td 0xc8bac300 kdb_enter(c0894aec) at kdb_enter+0x2b panic(c089806f,4,0,c8bac300,c8bad218,...) at panic+0x127 userret(c8bac300,eafd4d38,0,2,0,...) at userret+0x183 syscall(3b,3b,3b,1,0,...) at syscall+0x321 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (0, FreeBSD ELF32, nosys), eip = 0x280bd1b7, esp = 0xbfbfe90c, ebp = 0xbfbfe928 --- db show lockedvnods Locked vnodes 0xc8761c3c: tag ufs, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0xc86cf2e4 flags () lock type ufs: EXCL (count 1) by thread 0xc8bac780 (pid 59934)#0 0xc0668bf9 at lockmgr+0x4ed #1 0xc078572e at ffs_lock+0x76 #2 0xc0838287 at VOP_LOCK_APV+0x87 #3 0xc06d663c at vn_lock+0xac #4 0xc06c5eba at dounmount+0x62 #5 0xc06c5e31 at unmount+0x1e5 #6 0xc0825a07 at syscall+0x25b #7 0xc0811f7f at Xint0x80_syscall+0x1f ino 8260, on dev ufs/root 0xc87b9414: tag ufs, type VDIR usecount
Re: [CALL FOR TESTERS] (was: ral(4) and second/third gen devices)
Hi! This won't compile on my system (6.1-RELEASE-p11). Any ideas? linking kernel if_ral_pci.o(.data+0x120): undefined reference to `rt2661_attach' if_ral_pci.o(.data+0x124): undefined reference to `rt2661_detach' if_ral_pci.o(.data+0x128): undefined reference to `rt2661_shutdown' if_ral_pci.o(.data+0x12c): undefined reference to `rt2661_suspend' if_ral_pci.o(.data+0x130): undefined reference to `rt2661_resume' if_ral_pci.o(.data+0x134): undefined reference to `rt2661_intr' if_ral_pci.o(.data+0x138): undefined reference to `rt2560_attach' if_ral_pci.o(.data+0x13c): undefined reference to `rt2560_detach' if_ral_pci.o(.data+0x140): undefined reference to `rt2560_shutdown' if_ral_pci.o(.data+0x144): undefined reference to `rt2560_suspend' if_ral_pci.o(.data+0x148): undefined reference to `rt2560_resume' if_ral_pci.o(.data+0x14c): undefined reference to `rt2560_intr' *** Error code 1 Stop in /usr/obj/usr/src/sys/LAPTOP64. Sorry, forgot to attach the diff for conf/ and for modules/ New patch version is available at http://samodelkin.net/~fjoe/if_ral.diff. But it only builds as a module. cd /sys/modules/ral make make install /fjoe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1955 Blade - Broadcom NIC not detected (BCM5708S)
I am trying to get FreeBSD to work on a Dell 1955 blade. Looks like the NICs on the blade are not supported by the BCE or BGE driver. On Linux the NICs are identified as 06:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (rev 11) From if_bce.c - * The following controllers are not supported by this driver: * (These are not Production versions of the controller.) * BCM5706C A0, A1 * BCM5706S A0, A1, A2, A3 * BCM5708C A0, B0 * -- BCM5708S -- A0, B0, B1 Is there any reason why the chipset is not supported? Is there anyway of getting the BCE or BGE driver to work with this chipset? Will it be supported sometime in the near future? Any help would be much appreciated. Any development here? We have just started purchasing 1955 Blades and would very much like to install FreeBSD on them :) There is not much response regardring this issue other than me too. The need for an updated driver is there and if we want some progress I believe some financing seems to be the only alternative. Maby Scott (Long) has some thought on this (if he's not to busy getting 6.2 ready). Claus ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1955 Blade - Broadcom NIC not detected (BCM5708S)
In response to Morten A. Middelthon [EMAIL PROTECTED]: On Mon, Oct 30, 2006 at 04:17:00PM +0200, Conrad Burger wrote: I am trying to get FreeBSD to work on a Dell 1955 blade. Looks like the NICs on the blade are not supported by the BCE or BGE driver. On Linux the NICs are identified as 06:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (rev 11) From if_bce.c - * The following controllers are not supported by this driver: * (These are not Production versions of the controller.) * BCM5706C A0, A1 * BCM5706S A0, A1, A2, A3 * BCM5708C A0, B0 * -- BCM5708S -- A0, B0, B1 Is there any reason why the chipset is not supported? Is there anyway of getting the BCE or BGE driver to work with this chipset? Will it be supported sometime in the near future? Any help would be much appreciated. Any development here? We have just started purchasing 1955 Blades and would very much like to install FreeBSD on them :) Support for them is in CURRENT and 6.2, although the comment saying that they're _not_ supported is still there as well ;) -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze
On 12/15/06, Kostik Belousov [EMAIL PROTECTED] wrote: This looks like lock leak in nfsd. Could you supply the tcpdump of the session that causes the problem ? Also, it would be very helpful if you could note exact rpc that wedges the server. That would have been my next step. I ran only rpcbind, nfsd and mountd on the file server (no rpc.lockd/rpc.statd). I then had an OS/2 Client mount the filesystem, issue a readdir and then tried to mount the same share from an Linux client. This last mount request never came back, immediately after issueing the mount request the mountd got stuck in state 'ufs' as shown in the backtrace. A tcpdump of the session can be found at: http://coyote.dnsalias.net/rpc.pcap (9kB) Uli PS: Please trim the Email when responding to the GNATS DB as that makes the PR-Trail rather unreadable. Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze
On Fri, Dec 15, 2006 at 03:12:58PM +0100, Ulrich Spoerlein wrote: A tcpdump of the session can be found at: http://coyote.dnsalias.net/rpc.pcap (9kB) Am I right that all you did was ls -l root of nfs mount ? Does OS/2 supports the notion of .. directory ? Could you do just ls -l .. from nfs client and then try stat root of exported fs on the server (i think it shall hang) ? My hypothesis is that LOOKUP RPC for .. causes directory vnode lock leak in nfs_namei. After that, mountd hang is just consequence. pgpdEaqlQC1Fy.pgp Description: PGP signature
Re: SMP Kernel Panic while heavy load.
After recompile kernel with new conf: http://upload.hshh.org/homes/hshh/temp/panic/kernel-1215.log It still panic while SMP enabled. kgdb backtrace: http://upload.hshh.org/homes/hshh/temp/panic/kgdb-1215.log On 12/15/06, LI Xin [EMAIL PROTECTED] wrote: hshh wrote: Hi, My FreeBSD server panic while running SMP kernel. All work fine if disable SMP feature. uname log: http://upload.hshh.org/homes/hshh/temp/panic/uname.log My kernel conf: http://upload.hshh.org/homes/hshh/temp/panic/kernel.log Backtrace log: http://upload.hshh.org/homes/hshh/temp/panic/kgdb.log Would you please disable ZEROCOPY_SOCKETS and try if things gets improved? Cheers, -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in nfsd on 6.2-RC1
On Tue, 2006-12-05 at 12:38 +0900, Hiroki Sato wrote: Kostik Belousov [EMAIL PROTECTED] wrote in [EMAIL PROTECTED]: ko What version of sys/nfsserver/nfs_serv.c do you use ? If it is older than ko 1.156.2.7, please, update the system. Thanks, I updated it just now and see how it works. -- | Hiroki SATO I was/am having the same issue. Updating world (6.2-stable) to include the above update sadly did not fix the problem for me. This is an amd64 box with only one client connecting to it via nfs. Reading further it may seem to be an issue with rpc.statd and/or rpc.lockd. As I only have one client connecting and it is being used as mail storage (i.e. the client pops/imaps the storage) would be safe to not using fcntl forwards over the wire? Is this same issue present in 6.1-RELENG? I am really at my wits end at this point and for the first time am actually considering moving to another OS (solaris more than likely) as I cannot have these types of issues interrupting services every couple days. What other information (spefically) can I provide to help the devs figure out what is going on? What can I do in the meantime to have some semblence of stability? I assume downgrading to 5.5-RELENG is out of the question but perhaps disabling SMP? Sven ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [CALL FOR TESTERS] (was: ral(4) and second/third gen devices)
On Friday 15 December 2006 13:30, you wrote: Sorry, forgot to attach the diff for conf/ and for modules/ New patch version is available at http://samodelkin.net/~fjoe/if_ral.diff. But it only builds as a module. cd /sys/modules/ral make make install Hi Max, Most excellent! The original 2560 (QCom Q802MKG generic RT2560 based Mini-PCI) works fine (maybe just a little better, as it can associate with both my indoor and workshop APs, something I haven't been able to do lately) and the 2561s (Gigabyte GN-WI01GS Mini-PCI) works just as well. Both are using WPA-PSK and wpa_supplicant has no problems with either of them. Many thanks for the efforts. I'm leaving the RT2560 in this machine for now, and will post again if there are any problems. -- Matt Dawson. [EMAIL PROTECTED] MTD15-RIPE OpenNIC M_D9 MD51-6BONE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze
On 12/15/06, Kostik Belousov [EMAIL PROTECTED] wrote: Am I right that all you did was ls -l root of nfs mount ? Does OS/2 supports the notion of .. directory ? Could you do just ls -l .. from nfs client and then try stat root of exported fs on the server (i think it shall hang) ? Yes, you are right about the symptoms. We tried the following on the OS/2 Client mount export umount export mount export umount export this is all working fine, then we do a dir on the mounted FS mount i: /export/foo dir i: umount -- haning, as mountd can't process the RPC. My hypothesis is that LOOKUP RPC for .. causes directory vnode lock leak in nfs_namei. After that, mountd hang is just consequence. So, I mounted from the OS/2 Client, ran a dir on the i: drive and then an stat(1) to the exported partition on the server. This stat would hang, here's the backtraces: db ps pid ppid pgrp uid state wmesg wchancmd 33017 88035 33017 0 S+ ufs 0xc8771880 stat 23627 55476 23627 0 S+ bpf 0xc8e16c00 tcpdump 88035 87505 88035 0 S+ pause0xc882bcc4 tcsh 87505 72558 87505 1000 S+ wait 0xc86f9218 su 72558 89630 72558 1000 Ss+ pause0xc873867c tcsh 21229 1 21229 0 Ss select 0xc09c10c4 mountd 91293 79042 79042 0 S -0xc8668200 nfsd 88479 79042 79042 0 S -0xc8668600 nfsd 86952 79042 79042 0 S -0xc847cc00 nfsd 83659 79042 79042 0 S -0xc8678200 nfsd 79042 1 79042 0 Ss accept 0xc8d649f6 nfsd 55476 52005 55476 0 S+ pause0xc8bcc24c tcsh 52005 95193 52005 1000 S+ wait 0xc8734648 su ... db show lockedvnods Locked vnodes 0xc8771828: tag ufs, type VDIR usecount 0, writecount 0, refcount 4 mountedhere 0 flags (VV_ROOT) v_object 0xc8a8a084 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc882f900 (pid 83659) with 1 pending#0 0xc0668bf9 at lockmgr+0x4ed #1 0xc078572e at ffs_lock+0x76 #2 0xc0838287 at VOP_LOCK_APV+0x87 #3 0xc06d663c at vn_lock+0xac #4 0xc06ca4ca at vget+0xc2 #5 0xc06c24a9 at vfs_hash_get+0x8d #6 0xc07844af at ffs_vget+0x27 #7 0xc078b253 at ufs_lookup+0xa4b #8 0xc083641b at VOP_CACHEDLOOKUP_APV+0x9b #9 0xc06bf499 at vfs_cache_lookup+0xb5 #10 0xc0836347 at VOP_LOOKUP_APV+0x87 #11 0xc06c3626 at lookup+0x46e #12 0xc0734fba at nfs_namei+0x40e #13 0xc0726d81 at nfsrv_lookup+0x1dd #14 0xc0736765 at nfssvc_nfsd+0x3d9 #15 0xc07360b4 at nfssvc+0x18c #16 0xc0825a07 at syscall+0x25b #17 0xc0811f7f at Xint0x80_syscall+0x1f ino 2, on dev da1s2e db tr 33017 Tracing pid 33017 tid 100125 td 0xc86fd600 sched_switch(c86fd600,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 sleepq_switch(c8771880,c0973440,0,c089798c,211,...) at sleepq_switch+0xc1 sleepq_wait(c8771880,0,c87718f0,b7,c08929b8,...) at sleepq_wait+0x46 msleep(c8771880,c0972590,50,c089c1c1,0,...) at msleep+0x279 acquire(eb01694c,40,6,c86fd600,0,...) at acquire+0x76 lockmgr(c8771880,2002,c87718f0,c86fd600) at lockmgr+0x44e ffs_lock(eb0169a4) at ffs_lock+0x76 VOP_LOCK_APV(c0943320,eb0169a4) at VOP_LOCK_APV+0x87 vn_lock(c8771828,2002,c86fd600,c8771828) at vn_lock+0xac vget(c8771828,2002,c86fd600) at vget+0xc2 vfs_hash_get(c87115c8,2,2,c86fd600,eb016abc,0,0) at vfs_hash_get+0x8d ffs_vget(c87115c8,2,2,eb016abc) at ffs_vget+0x27 ufs_root(c87115c8,2,eb016b00,c86fd600,0,...) at ufs_root+0x19 lookup(eb016ba0) at lookup+0x743 namei(eb016ba0) at namei+0x39a kern_lstat(c86fd600,bfbfed99,0,eb016c74) at kern_lstat+0x47 lstat(c86fd600,eb016d04) at lstat+0x1b syscall(3b,3b,3b,0,bfbfebf0,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (190, FreeBSD ELF32, lstat), eip = 0x2812d427, esp = 0xbfbfeb9c, ebp = 0xbfbfec68 --- db tr 83659 Tracing pid 83659 tid 100115 td 0xc882f900 sched_switch(c882f900,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 sleepq_switch(c8678200) at sleepq_switch+0xc1 sleepq_wait_sig(c8678200) at sleepq_wait_sig+0x1d msleep(c8678200,c09c9f00,158,c088bec9,0,...) at msleep+0x26a nfssvc_nfsd(c882f900) at nfssvc_nfsd+0xe5 nfssvc(c882f900,eaf8ad04) at nfssvc+0x18c syscall(3b,3b,3b,1,0,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (155, FreeBSD ELF32, nfssvc), eip = 0x280bd1b7, esp = 0xbfbfe90c, ebp = 0xbfbfe928 --- Do you think you can fix it? Any idea why this seems to only happen with OS/2 Clients? Uli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1955 Blade - Broadcom NIC not detected (BCM5708S)
I am trying to get FreeBSD to work on a Dell 1955 blade. Looks like the NICs on the blade are not supported by the BCE or BGE driver. On Linux the NICs are identified as 06:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (rev 11) From if_bce.c - * The following controllers are not supported by this driver: * (These are not Production versions of the controller.) * BCM5706C A0, A1 * BCM5706S A0, A1, A2, A3 * BCM5708C A0, B0 * -- BCM5708S -- A0, B0, B1 Is there any reason why the chipset is not supported? Is there anyway of getting the BCE or BGE driver to work with this chipset? Will it be supported sometime in the near future? Any help would be much appreciated. Any development here? We have just started purchasing 1955 Blades and would very much like to install FreeBSD on them :) Support for them is in CURRENT and 6.2, although the comment saying that they're _not_ supported is still there as well ;) No, unfortunately not. The controller is recognized but then bails out with SerDes controller not supported. Have tried (many times :-/ ). regards Claus ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze
On Fri, Dec 15, 2006 at 04:18:32PM +0100, Ulrich Spoerlein wrote: [Lot of debugging info trimmed to pacify you ] Do you think you can fix it? Any idea why this seems to only happen with OS/2 Clients? It seems that my guess is right. OS/2 nfs client, in contrast to unix client, send LOOKUP .. on the root vnode to the server. pgpbehxveXZPi.pgp Description: PGP signature
Re: Dell 1955 Blade - Broadcom NIC not detected (BCM5708S)
In response to Claus Guttesen [EMAIL PROTECTED]: I am trying to get FreeBSD to work on a Dell 1955 blade. Looks like the NICs on the blade are not supported by the BCE or BGE driver. On Linux the NICs are identified as 06:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (rev 11) From if_bce.c - * The following controllers are not supported by this driver: * (These are not Production versions of the controller.) * BCM5706C A0, A1 * BCM5706S A0, A1, A2, A3 * BCM5708C A0, B0 * -- BCM5708S -- A0, B0, B1 Is there any reason why the chipset is not supported? Is there anyway of getting the BCE or BGE driver to work with this chipset? Will it be supported sometime in the near future? Any help would be much appreciated. Any development here? We have just started purchasing 1955 Blades and would very much like to install FreeBSD on them :) Support for them is in CURRENT and 6.2, although the comment saying that they're _not_ supported is still there as well ;) No, unfortunately not. The controller is recognized but then bails out with SerDes controller not supported. Have tried (many times :-/ ). Ah ... that part wasn't clear. Unfortunately, I don't have any further information on this. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RC2 ?
Will there be a RC2 or just a realease? Thanks. -- Scott T. Hildreth [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: Dell 1955 Blade - Broadcom NIC not detected (BCM5708S)
I am trying to get FreeBSD to work on a Dell 1955 blade. Looks like the NICs on the blade are not supported by the BCE or BGE driver. On Linux the NICs are identified as 06:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (rev 11) From if_bce.c - * The following controllers are not supported by this driver: * (These are not Production versions of the controller.) * BCM5706C A0, A1 * BCM5706S A0, A1, A2, A3 * BCM5708C A0, B0 * -- BCM5708S -- A0, B0, B1 Is there any reason why the chipset is not supported? Is there anyway of getting the BCE or BGE driver to work with this chipset? Will it be supported sometime in the near future? Any help would be much appreciated. Any development here? We have just started purchasing 1955 Blades and would very much like to install FreeBSD on them :) Support for them is in CURRENT and 6.2, although the comment saying that they're _not_ supported is still there as well ;) No, unfortunately not. The controller is recognized but then bails out with SerDes controller not supported. Have tried (many times :-/ ). Ah ... that part wasn't clear. Unfortunately, I don't have any further information on this. It appears as a generic (blade) issue, Dell- and HP-blades exhibit this behaviour. regards Claus ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-RC1 em(4) issue - freezes during CD boot
Jack Vogel wrote: Since its often the case that a kernel you rebuild is NOT the same as the one install ends you with it might be a good test to go ahead, redefine em back into the kernel and see if THAT new kernel hangs. Just be SURE and keep this other kernel available to boot up again :) Well I ran cvsup prior to doing this, so it's not a perfect test case (i.e. it's not the src that the 6.2-RC1 CD installed). But after building and installing a new world and GENERIC kernel from a cvsup on RELENG_6_2 from yesterday, the box boots fine and detects the em card properly during boot without freezing. I can test future 6.2 RC's or the final release and let you know if I'm still seeing the same issue if you'd like. Thanks for your help! Cheers, -Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RC2 ?
On Friday 15 December 2006 18:33, Scott T. Hildreth wrote: Will there be a RC2 or just a realease? http://www.freebsd.org/releases/6.2R/schedule.html -- patrick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RC2 ?
If memory serves me right, Scott T. Hildreth wrote: Will there be a RC2 or just a realease? Current plans are to do one more release candidate (== 6.2-RC2) and then the final release. If I said it was coming soon, nobody would believe me, so I won't say it. :-p Bruce. signature.asc Description: OpenPGP digital signature
Re: RC2 ?
On Fri, 2006-12-15 at 19:48 +0300, Patrick Okui wrote: On Friday 15 December 2006 18:33, Scott T. Hildreth wrote: Will there be a RC2 or just a realease? http://www.freebsd.org/releases/6.2R/schedule.html And that has expired dates, so I was wondering if RC2 would be released or skipped. -- Scott T. Hildreth [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: RC2 ?
And ? On 12/15/06, Patrick Okui [EMAIL PROTECTED] wrote: On Friday 15 December 2006 18:33, Scott T. Hildreth wrote: Will there be a RC2 or just a realease? http://www.freebsd.org/releases/6.2R/schedule.html -- patrick ___ 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: 6.2-RC1 em(4) issue - freezes during CD boot
At 11:24 AM 12/15/2006, Chris Buechler wrote: Jack Vogel wrote: Since its often the case that a kernel you rebuild is NOT the same as the one install ends you with it might be a good test to go ahead, redefine em back into the kernel and see if THAT new kernel hangs. Just be SURE and keep this other kernel available to boot up again :) Well I ran cvsup prior to doing this, so it's not a perfect test case (i.e. it's not the src that the 6.2-RC1 CD installed). But after building and installing a new world and GENERIC kernel from a cvsup on RELENG_6_2 from yesterday, the box boots fine and detects the em card properly during boot without freezing. I can test future 6.2 RC's or the final release and let you know if I'm still seeing the same issue if you'd like. Thanks for your help! For me, I can trigger the lockup upto and including this morning's RELENG_6. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in nfsd on 6.2-RC1
On Fri, Dec 15, 2006 at 10:01:19AM -0500, Sven Willenberger wrote: On Tue, 2006-12-05 at 12:38 +0900, Hiroki Sato wrote: Kostik Belousov [EMAIL PROTECTED] wrote in [EMAIL PROTECTED]: ko What version of sys/nfsserver/nfs_serv.c do you use ? If it is older than ko 1.156.2.7, please, update the system. Thanks, I updated it just now and see how it works. -- | Hiroki SATO I was/am having the same issue. Updating world (6.2-stable) to include the above update sadly did not fix the problem for me. This is an amd64 box with only one client connecting to it via nfs. Reading further it may seem to be an issue with rpc.statd and/or rpc.lockd. As I only have one client connecting and it is being used as mail storage (i.e. the client pops/imaps the storage) would be safe to not using fcntl forwards over the wire? Is this same issue present in 6.1-RELENG? I am really at my wits end at this point and for the first time am actually considering moving to another OS (solaris more than likely) as I cannot have these types of issues interrupting services every couple days. What other information (spefically) can I provide to help the devs figure out what is going on? What can I do in the meantime to have some semblence of stability? I assume downgrading to 5.5-RELENG is out of the question but perhaps disabling SMP? Just to confirm, can you please post the panic backtrace you are seeing? And can you explain what you mean by may seem to be an issue with rpc.statd and/or rpc.lockd? Sometimes people think they're seeing the same problem as someone else when really it's a completely different problem in the same subsystem, so I'd like to rule that out here. Kris pgp6ZQVPPMtjU.pgp Description: PGP signature
Re: panic in nfsd on 6.2-RC1
On Fri, 2006-12-15 at 13:15 -0500, Kris Kennaway wrote: On Fri, Dec 15, 2006 at 10:01:19AM -0500, Sven Willenberger wrote: On Tue, 2006-12-05 at 12:38 +0900, Hiroki Sato wrote: Kostik Belousov [EMAIL PROTECTED] wrote in [EMAIL PROTECTED]: ko What version of sys/nfsserver/nfs_serv.c do you use ? If it is older than ko 1.156.2.7, please, update the system. Thanks, I updated it just now and see how it works. -- | Hiroki SATO I was/am having the same issue. Updating world (6.2-stable) to include the above update sadly did not fix the problem for me. This is an amd64 box with only one client connecting to it via nfs. Reading further it may seem to be an issue with rpc.statd and/or rpc.lockd. As I only have one client connecting and it is being used as mail storage (i.e. the client pops/imaps the storage) would be safe to not using fcntl forwards over the wire? Is this same issue present in 6.1-RELENG? I am really at my wits end at this point and for the first time am actually considering moving to another OS (solaris more than likely) as I cannot have these types of issues interrupting services every couple days. What other information (spefically) can I provide to help the devs figure out what is going on? What can I do in the meantime to have some semblence of stability? I assume downgrading to 5.5-RELENG is out of the question but perhaps disabling SMP? Just to confirm, can you please post the panic backtrace you are seeing? And can you explain what you mean by may seem to be an issue with rpc.statd and/or rpc.lockd? Sometimes people think they're seeing the same problem as someone else when really it's a completely different problem in the same subsystem, so I'd like to rule that out here. Kris Well I have now added kdb and invariants/witness support to the kernel so I should be able to get some backtrace the next time it happens. Currently, the system just locks and no error is displayed on the console or /var/log/messages; sorry I cannot be of immediate help there. Regarding the rpc issue, I just ran across mention of those in sshfs/nfs threads appearing here and in particular to a link referenced within one of them (http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1362611+0 +archive/2006/freebsd-stable/20060702.freebsd-stable ) - it is more than likely not at all related but I am grasping at straws here trying to solve this. FWIW, I do see the following appearing in the /var/log/messages: ufs_rename: fvp == tvp (can't happen) about once or twice a day, but cannot correlate those to lockup. Now that I have enabled the options mentioned above in the kernel, I am seeing some LOR issues: kernel: lock order reversal: kernel: 1st 0xff00c3bab200 kqueue (kqueue) @ /usr/src/sys/kern/kern_event.c:1547 kernel: 2nd 0xff0005bb6078 struct mount mtx (struct mount mtx) @ /usr/src/sys/ufs/ufs/ufs_vnops.c:138 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RC2 ?
On Friday 15 December 2006 20:14, Scott T. Hildreth wrote: On Fri, 2006-12-15 at 19:48 +0300, Patrick Okui wrote: On Friday 15 December 2006 18:33, Scott T. Hildreth wrote: Will there be a RC2 or just a realease? http://www.freebsd.org/releases/6.2R/schedule.html And that has expired dates, so I was wondering if RC2 would be released or skipped. AFAIR even when the dates/times on the schedules are missed, the sequence is followed so I'd say most probably, but then again I'm not part of [EMAIL PROTECTED] -- patrick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Not panic in nfsd (Re: panic in nfsd on 6.2-RC1)
On Fri, Dec 15, 2006 at 02:12:16PM -0500, Sven Willenberger wrote: On Fri, 2006-12-15 at 13:15 -0500, Kris Kennaway wrote: On Fri, Dec 15, 2006 at 10:01:19AM -0500, Sven Willenberger wrote: On Tue, 2006-12-05 at 12:38 +0900, Hiroki Sato wrote: Kostik Belousov [EMAIL PROTECTED] wrote in [EMAIL PROTECTED]: ko What version of sys/nfsserver/nfs_serv.c do you use ? If it is older than ko 1.156.2.7, please, update the system. Thanks, I updated it just now and see how it works. -- | Hiroki SATO I was/am having the same issue. Updating world (6.2-stable) to include the above update sadly did not fix the problem for me. This is an amd64 box with only one client connecting to it via nfs. Reading further it may seem to be an issue with rpc.statd and/or rpc.lockd. As I only have one client connecting and it is being used as mail storage (i.e. the client pops/imaps the storage) would be safe to not using fcntl forwards over the wire? Is this same issue present in 6.1-RELENG? I am really at my wits end at this point and for the first time am actually considering moving to another OS (solaris more than likely) as I cannot have these types of issues interrupting services every couple days. What other information (spefically) can I provide to help the devs figure out what is going on? What can I do in the meantime to have some semblence of stability? I assume downgrading to 5.5-RELENG is out of the question but perhaps disabling SMP? Just to confirm, can you please post the panic backtrace you are seeing? And can you explain what you mean by may seem to be an issue with rpc.statd and/or rpc.lockd? Sometimes people think they're seeing the same problem as someone else when really it's a completely different problem in the same subsystem, so I'd like to rule that out here. Kris Well I have now added kdb and invariants/witness support to the kernel so I should be able to get some backtrace the next time it happens. Currently, the system just locks and no error is displayed on the console or /var/log/messages; sorry I cannot be of immediate help there. OK, so your issue is not, in fact, a panic in nfsd as you were claiming ;-) Regarding the rpc issue, I just ran across mention of those in sshfs/nfs threads appearing here and in particular to a link referenced within one of them (http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1362611+0 +archive/2006/freebsd-stable/20060702.freebsd-stable ) - it is more than likely not at all related but I am grasping at straws here trying to solve this. Yes, I think you are grasping at straws. At this point, you need to do some debugging to find out the source of your problem, and treat it as a new bug until you find conclusive evidence that it's the same as a previously reported bug. Guessing without evidence that your problem is the same as someone else's problem, because e.g. both involve your system becoming unresponsive, is a very good way to confuse the issue and delay resolution. FWIW, I do see the following appearing in the /var/log/messages: ufs_rename: fvp == tvp (can't happen) about once or twice a day, but cannot correlate those to lockup. Now that I have enabled the options mentioned above in the kernel, I am seeing some LOR issues: kernel: lock order reversal: kernel: 1st 0xff00c3bab200 kqueue (kqueue) @ /usr/src/sys/kern/kern_event.c:1547 kernel: 2nd 0xff0005bb6078 struct mount mtx (struct mount mtx) @ /usr/src/sys/ufs/ufs/ufs_vnops.c:138 OK, this is interesting, so let's proceed from here. Kris pgpiG5YPZdLII.pgp Description: PGP signature
Re: Not panic in nfsd (Re: panic in nfsd on 6.2-RC1)
On Fri, Dec 15, 2006 at 02:29:58PM -0500, Kris Kennaway wrote:
On Fri, Dec 15, 2006 at 02:12:16PM -0500, Sven Willenberger wrote:
On Fri, 2006-12-15 at 13:15 -0500, Kris Kennaway wrote:
On Fri, Dec 15, 2006 at 10:01:19AM -0500, Sven Willenberger wrote:
On Tue, 2006-12-05 at 12:38 +0900, Hiroki Sato wrote:
Kostik Belousov [EMAIL PROTECTED] wrote
in [EMAIL PROTECTED]:
ko What version of sys/nfsserver/nfs_serv.c do you use ? If it is
older than
ko 1.156.2.7, please, update the system.
Thanks, I updated it just now and see how it works.
--
| Hiroki SATO
I was/am having the same issue. Updating world (6.2-stable) to include
the above update sadly did not fix the problem for me. This is an amd64
box with only one client connecting to it via nfs. Reading further it
may seem to be an issue with rpc.statd and/or rpc.lockd. As I only have
one client connecting and it is being used as mail storage (i.e. the
client pops/imaps the storage) would be safe to not using fcntl forwards
over the wire? Is this same issue present in 6.1-RELENG? I am really at
my wits end at this point and for the first time am actually considering
moving to another OS (solaris more than likely) as I cannot have these
types of issues interrupting services every couple days.
What other information (spefically) can I provide to help the devs
figure out what is going on? What can I do in the meantime to have some
semblence of stability? I assume downgrading to 5.5-RELENG is out of the
question but perhaps disabling SMP?
Just to confirm, can you please post the panic backtrace you are
seeing? And can you explain what you mean by may seem to be an issue
with rpc.statd and/or rpc.lockd?
Sometimes people think they're seeing the same problem as someone else
when really it's a completely different problem in the same subsystem,
so I'd like to rule that out here.
Kris
Well I have now added kdb and invariants/witness support to the kernel
so I should be able to get some backtrace the next time it happens.
Currently, the system just locks and no error is displayed on the
console or /var/log/messages; sorry I cannot be of immediate help there.
OK, so your issue is not, in fact, a panic in nfsd as you were
claiming ;-)
Regarding the rpc issue, I just ran across mention of those in sshfs/nfs
threads appearing here and in particular to a link referenced within one
of them (http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1362611+0
+archive/2006/freebsd-stable/20060702.freebsd-stable ) - it is more than
likely not at all related but I am grasping at straws here trying to
solve this.
Yes, I think you are grasping at straws. At this point, you need to
do some debugging to find out the source of your problem, and treat it
as a new bug until you find conclusive evidence that it's the same as
a previously reported bug.
Guessing without evidence that your problem is the same as someone
else's problem, because e.g. both involve your system becoming
unresponsive, is a very good way to confuse the issue and delay
resolution.
FWIW, I do see the following appearing in the /var/log/messages:
ufs_rename: fvp == tvp (can't happen)
about once or twice a day, but cannot correlate those to lockup. Now
that I have enabled the options mentioned above in the kernel, I am
seeing some LOR issues:
kernel: lock order reversal:
kernel: 1st 0xff00c3bab200 kqueue (kqueue) @
/usr/src/sys/kern/kern_event.c:1547
kernel: 2nd 0xff0005bb6078 struct mount mtx (struct mount mtx) @
/usr/src/sys/ufs/ufs/ufs_vnops.c:138
OK, this is interesting, so let's proceed from here.
Kris
Try this.
Index: ufs/ufs/ufs_vnops.c
===
RCS file: /usr/local/arch/ncvs/src/sys/ufs/ufs/ufs_vnops.c,v
retrieving revision 1.283
diff -u -r1.283 ufs_vnops.c
--- ufs/ufs/ufs_vnops.c 6 Nov 2006 13:42:09 - 1.283
+++ ufs/ufs/ufs_vnops.c 15 Dec 2006 21:19:51 -
@@ -133,19 +133,15 @@
{
struct inode *ip;
struct timespec ts;
- int mnt_locked;
ip = VTOI(vp);
- mnt_locked = 0;
- if ((vp-v_mount-mnt_flag MNT_RDONLY) != 0) {
- VI_LOCK(vp);
+ VI_LOCK(vp);
+ if ((vp-v_mount-mnt_flag MNT_RDONLY) != 0)
goto out;
+ if ((ip-i_flag (IN_ACCESS | IN_CHANGE | IN_UPDATE)) == 0) {
+ VI_UNLOCK(vp);
+ return;
}
- MNT_ILOCK(vp-v_mount); /* For reading of mnt_kern_flags. */
- mnt_locked = 1;
- VI_LOCK(vp);
- if ((ip-i_flag (IN_ACCESS | IN_CHANGE | IN_UPDATE)) == 0)
- goto out_unl;
if ((vp-v_type == VBLK || vp-v_type == VCHR) !DOINGSOFTDEP(vp))
ip-i_flag |= IN_LAZYMOD;
@@ -172,10 +168,7 @@
out:
ip-i_flag =
Re: ips(4) in toaster mode
It seems that after upgrading ips firmware to the latest version available on ibm.com solves this problem. One changelog caught me eye: increase timeout when tape driver is attached to the adapter. Indeed, we have a tape on ahd(4), which I think ips(4) is sharing this adapter. however, the mystery is why ips stops work suddenly. Perhaps, I tweaked some hardware settings and I forgot it. On 11/18/06, Scott Long [EMAIL PROTECTED] wrote: I'll look at this. Scott Rong-en Fan wrote: Hi, After upgrading RELENG_6 from Jul 11 to Sep 30 on an i386 box, everytime I run tar to backup my system to a mounted nfs volume. After one hour of operation, it panics with sleeping thread. Upgrading to RELENG_6_2 does not help. Also, the console is complete hang, I can not break into DDB at all. The only thing is do power cycling. Also, the only harddisk on that host is the ips(4), so I can not obtain a kernel dump. I'm not sure if this is a hardware failure, at least, no led on the panel is shown red... OK, the only information on console is attached below. Any suggesstion are welcome. Thanks, Rong-En Fan == ips0: WARNING: command timeout. Adapter is in toaster mode, resetting to known s tate ips0: resetting adapter, this may take up to 5 minutes ips0: syncing config Sleeping thread (tid 12, pid 14) owns a non-sleepable lock sched_switch(c5feec00,0,1,8577f833,d14d2103,...) at sched_switch+0x158 mi_switch(1,0) at mi_switch+0x1d5 sleepq_switch(c60c2604,e9f77b8c,c051acd3,4,1,...) at sleepq_switch+0x93 sleepq_wait(c60c2604,c60c25e0,c06e6957,1,1,...) at sleepq_wait+0x75 cv_wait(c60c2604,c60c25e0,a,e9f77c04,5,...) at cv_wait+0x151 _sema_wait(c60c25e0,0,0,c60c2400,c60c2400,...) at _sema_wait+0x64 ips_send_config_sync_cmd(c60f5000,e9f77c08,1,c60f5000,7,...) at ips_send_config_sync_cmd+0x78 ips_clear_adapter(c60c2400,c60b6e00,0,4,c60f5000,...) at ips_clear_adapter+0x60 ips_morpheus_reinit(c60c2400,1,c053abf7,c0740100,c5feec00,...) at ips_morpheus_reinit+0x2ac ips_timeout(c60c2400,c053a7f5,c5feec00,c5feea80,d69f60ed,...) at ips_timeout+0xf8 softclock(0,e9f77cd4,15dbe,c43ec589,c5feec00,...) at softclock+0x35d ithread_execute_handlers(c5fed430,c6042000,0,0,0,...) at ithread_execute_handlers+0x162 ithread_loop(c5fbc880,e9f77d38,0,0,0,...) at ithread_loop+0x64 fork_exit(c050b22a,c5fbc880,e9f77d38) at fork_exit+0x7b fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe9f77d6c, ebp = 0 --- panic: sleeping thread cpuid = 2 KDB: stack backtrace: kdb_backtrace(c0702303,2,c06ef01b,e9f98bf0,0,...) at kdb_backtrace+0x2f panic(c06ef01b,,e,c051ac54,1,...) at panic+0x129 propagate_priority(c5fefd80,c5fefd80,0,0,0,...) at propagate_priority+0x69 turnstile_wait(c60c25a8,c5feec00,c610c000,c7d064a4,4,...) at turnstile_wait+0x32f _mtx_lock_sleep(c60c25a8,c5fefd80,0,0,0,...) at _mtx_lock_sleep+0xfd ipsd_strategy(c7d064a4,43,200,0,c04e31a1,...) at ipsd_strategy+0x70 g_disk_start(c7d1e4a4,c073bac8,24c,c06e8406,64,...) at g_disk_start+0x1b1 g_io_schedule_down(c5fefd80,4c,c5fefd80,c04e39c1,e9f98d04,...) at g_io_schedule_down+0x15f g_down_procbody(0,e9f98d38,0,0,0,...) at g_down_procbody+0xb3 fork_exit(c04e39c1,0,e9f98d38) at fork_exit+0x7b fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe9f98d6c, ebp = 0 --- ___ 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: Poor NFS performance after recent update
Looks like I was wrong, as SCP is also just as slow as NFS I'm lost. I'm going to install 6.1-RELEASE to see if that fixes my problem. thanks! all!! -- Kimi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/92785: Using exported filesystem on OS/2 NFS client causes filesystem freeze
Kostik Belousov wrote: On Fri, Dec 15, 2006 at 03:12:58PM +0100, Ulrich Spoerlein wrote: A tcpdump of the session can be found at: http://coyote.dnsalias.net/rpc.pcap (9kB) Am I right that all you did was ls -l root of nfs mount ? Does OS/2 supports the notion of .. directory ? Could you do just ls -l .. from nfs client and then try stat root of exported fs on the server (i think it shall hang) ? My hypothesis is that LOOKUP RPC for .. causes directory vnode lock leak in nfs_namei. After that, mountd hang is just consequence. Yes, OS/2 supports the .. directory. FAT, HPFS, and JFS all have a .. directory. jmc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Poor NFS performance after recent update
On Sat, Dec 16, 2006 at 12:30:11AM +, Kimi Ostro wrote: Looks like I was wrong, as SCP is also just as slow as NFS I'm lost. I'm going to install 6.1-RELEASE to see if that fixes my problem. Your problem might be duplex-related. Can you provide some netstat -in output (after you've scp'd stuff, etc.), as well as ifconfig -a output? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Poor NFS performance after recent update
On 16/12/06, Jeremy Chadwick [EMAIL PROTECTED] wrote: Your problem might be duplex-related. Can you provide some netstat -in output (after you've scp'd stuff, etc.), as well as ifconfig -a output? nxclient-1.4.0-91.i386.tar.gz 100% 3423KB 23.1KB/s 02:28 NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll fxp0 1500 Link#1 00:90:27:a4:0f:2c 3940 0 3855 0 0 fxp0 1500 192.168.0./24 192.168.0.2203962 - 3875 - - lo0 16384 Link#2 0 00 0 0 lo0 16384 (28)00:00:00:00:00:00:fe:80:00:02:00:00:00:00:00:00:00:00:00:00:00:01 0 00 0 0 lo0 16384 (28)00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:01 0 00 0 0 lo0 16384 127 127.0.0.10 -0 - - fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=8VLAN_MTU inet 192.168.0.220 netmask 0xff00 broadcast 192.168.0.255 ether 00:90:27:a4:0f:2c media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 looks like a normal day to me besides the 23.1KB/s 02:28 :( -- Kimi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Poor NFS performance after recent update
Okay, this is getting stranger. transferring data between 8 machines on my network which are all running FreeBSD as having this problem, yet I cans download iso file off the internet at over 100KB/s. -- Kimi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Poor NFS performance after recent update
On Sat, Dec 16, 2006 at 02:21:53AM +, Kimi Ostro wrote: Okay, this is getting stranger. transferring data between 8 machines on my network which are all running FreeBSD as having this problem, yet I cans download iso file off the internet at over 100KB/s. Try transfers in different directions. Example: [EMAIL PROTECTED] scp -p [EMAIL PROTECTED]:/dev/urandom /tmp/urandom [EMAIL PROTECTED] scp -p /dev/urandom [EMAIL PROTECTED]:/tmp/urandom Also try the same from machineBB: [EMAIL PROTECTED] scp -p [EMAIL PROTECTED]:/dev/urandom /tmp/urandom [EMAIL PROTECTED] scp -p /dev/urandom [EMAIL PROTECTED]:/tmp/urandom Do you see slow LAN transfer speeds when only receiving data vs. sending data? If so, chances are it's a duplex problem, and you should either adjust some settings in ifconfig_fxp0 in rc.conf to try and work around it (try forcing media 100baseTX mediaopt full-duplex rather than using autonegotiate), or try a different switch. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CARP + VLAN = kernel dump
At Thu, 14 Dec 2006 19:05:04 -0800, Ask Bjørn Hansen wrote: Hi, If I enable carp on a vlan interface in rc.conf the kernel goes boom. This is 6.2-RC from a couple of weeks ago. (IIRC then I had the same problem setting up carp on a bridge'd interface). I'm configuring it like this: ifconfig_vlan2=inet 10.50.0.3/24 vlan 202 vlandev sis2 ifconfig_carp2=vhid 3 advskew 200 pass awe4jkfha4jkfha4f 10.50.0.1 cloned_interfaces=... carp2 ... vlan2 However, if I do the carp2 setup manually after the system is booted, it is working fine. ifconfig carp2 vhid 3 advskew 200 pass hjarefhakjewfha 10.50.0.1 Any ideas? (kernel dump below) - ask fault virtual address = 0x15c fault code = supervisor read, page not present instruction pointer = 0x20:0xc05ba533 stack pointer = 0x28:0xc7975c30 frame pointer = 0x28:0xc7975c90 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 = 13 (swi1: net) trap number = 12 panic: page fault Uptime: 17s Cannot dump. No dump device defined. A bit more information would really help. What is needed is a backtrace, and, if you can set up to dump core (I see by the output that that's not done) that would be great. A backtrace can be gotten with bt [enter] at the console after the panic. Thanks, George ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
