Re: NFS locking: lockf freezes (rpc.lockd problem?)
On Mon, 2006-Aug-28 13:23:30 +, Michael Abbott wrote: I think there is a case to be made for special casing SIGKILL, but in a sense it's not so much the fate of the process receiving the SIGKILL that counts: after all, having sent -9 I know that it will never process again. Currently, if you send SIGKILL, the process will never enter userland again. Going further, so that if you send a process SIGKILL, it will always terminate immediately is significantly more difficult. In the normal case, a process is sleeping on some condition with PCATCH specified. If the process receives a signal, sleep(9) will return ERESTART or EINTR and the code has to then arrange to return back to userland (which will cause the signal to be handled as per sigaction(2) and the processes signal handlers). In some cases, it may be inconvenient to unwind back to userland from a particular point so PCATCH isn't specified on the sleep. -- Peter Jeremy pgpWFCSDFpOmv.pgp Description: PGP signature
linux-oracle-instantclient-sqlplus-10.2.0.2.20060331
Hi all, First sorry if this is not the right place to post my questions :) I'm trying to run linux-oracle-instantclient-sqlplus-10.2.0.2.20060331 (ports/databases/linux-oracle-instantclient-sqlplus) on FreeBSD 6.1-STABLE (i386 or/and amd64), but with no success for now. After installation I run: LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/compat/linux/usr/lib/oracle/10.2.0.2.20060331/client/lib /compat/linux/usr/lib/oracle/10.2.0.2.20060331/client/bin/sqlplus /nolog but it just freezes. Friend of mine told me that he have no problems with FreeBSD 5.4(i386) My goal is to run oracle-instant client (i386) on FreeBSD-6.x amd64. So is there some big change in linux module in FreeBSD 6.1 compared to 5.4 ? Did somebody manage to run successfully linux-instant-oracle-client under FreeBSD 6.1 (i386/amd64)? Please help :)) P.S. oracle instant client does not depend on any linux_base, which was little strange for me, but just for info I have installed latest linux_base_fc4. Thanks in advance. -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: linux-oracle-instantclient-sqlplus-10.2.0.2.20060331
On 8/29/06, Stefan Lambrev [EMAIL PROTECTED] wrote: LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/compat/linux/usr/lib/oracle/10.2.0.2.20060331/client/lib /compat/linux/usr/lib/oracle/10.2.0.2.20060331/client/bin/sqlplus /nolog I am running it off a -current system with the following command: LD_LIBRARY_PATH=/compat/linux/usr/lib/oracle/10.2.0.2.20060331/client/lib /compat/linux/usr/bin/sqlplus but it just freezes. Friend of mine told me that he have no problems with FreeBSD 5.4(i386) P.S. oracle instant client does not depend on any linux_base, which was little strange for me, but just for info I have installed latest linux_base_fc4. Thanks in advance. -- Best Wishes, Stefan Lambrev -- Without the userland, the kernel is useless. --inspired by The Tao of Programming ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: linux-oracle-instantclient-sqlplus-10.2.0.2.20060331
Hi, Jiawei Ye wrote: On 8/29/06, Stefan Lambrev [EMAIL PROTECTED] wrote: LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/compat/linux/usr/lib/oracle/10.2.0.2.20060331/client/lib /compat/linux/usr/lib/oracle/10.2.0.2.20060331/client/bin/sqlplus /nolog I am running it off a -current system with the following command: LD_LIBRARY_PATH=/compat/linux/usr/lib/oracle/10.2.0.2.20060331/client/lib /compat/linux/usr/bin/sqlplus using the link doesn't help here :( but it just freezes. Friend of mine told me that he have no problems with FreeBSD 5.4(i386) P.S. oracle instant client does not depend on any linux_base, which was little strange for me, but just for info I have installed latest linux_base_fc4. Thanks in advance. -- Best Wishes, Stefan Lambrev -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS locking: lockf freezes (rpc.lockd problem?)
it's all is very good, but what can you say about to fix problem with rpc.lockd ??? 2006/8/29, Peter Jeremy [EMAIL PROTECTED]: On Mon, 2006-Aug-28 13:23:30 +, Michael Abbott wrote: I think there is a case to be made for special casing SIGKILL, but in a sense it's not so much the fate of the process receiving the SIGKILL that counts: after all, having sent -9 I know that it will never process again. Currently, if you send SIGKILL, the process will never enter userland again. Going further, so that if you send a process SIGKILL, it will always terminate immediately is significantly more difficult. In the normal case, a process is sleeping on some condition with PCATCH specified. If the process receives a signal, sleep(9) will return ERESTART or EINTR and the code has to then arrange to return back to userland (which will cause the signal to be handled as per sigaction(2) and the processes signal handlers). In some cases, it may be inconvenient to unwind back to userland from a particular point so PCATCH isn't specified on the sleep. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS locking: lockf freezes (rpc.lockd problem?)
Alexey Karagodov wrote: it's all is very good, but what can you say about to fix problem with rpc.lockd ??? It has been mentioned several times in this mailing list: rpc.lockd is in need of a complete rewrite. Someone will have to write a new rpc.lockd implementation. As far as I know, there is currently nobody working on it. 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. And believe me, as a C++ programmer, I don't hesitate to question the decisions of language designers. After a decent amount of C++ exposure, Python's flaws seem ridiculously small. -- Ville Vainio ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS locking: lockf freezes (rpc.lockd problem?)
On Tue, 29 Aug 2006, Alexey Karagodov wrote: it's all is very good, but what can you say about to fix problem with rpc.lockd ??? Well, I will repeat the test with RELENG_6 (as of yesterday lunchtime), probably tonight, and report back. Unfortunately building takes around 8 hours on my test machine! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: linux-oracle-instantclient-sqlplus-10.2.0.2.20060331
On Tue, Aug 29, 2006 at 10:55:42AM +0300, Stefan Lambrev wrote: Hi all, First sorry if this is not the right place to post my questions :) I'm trying to run linux-oracle-instantclient-sqlplus-10.2.0.2.20060331 (ports/databases/linux-oracle-instantclient-sqlplus) on FreeBSD 6.1-STABLE (i386 or/and amd64), but with no success for now. After installation I run: LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/compat/linux/usr/lib/oracle/10.2.0.2.20060331/client/lib /compat/linux/usr/lib/oracle/10.2.0.2.20060331/client/bin/sqlplus /nolog but it just freezes. Friend of mine told me that he have no problems with FreeBSD 5.4(i386) My goal is to run oracle-instant client (i386) on FreeBSD-6.x amd64. So is there some big change in linux module in FreeBSD 6.1 compared to 5.4 ? Did somebody manage to run successfully linux-instant-oracle-client under FreeBSD 6.1 (i386/amd64)? Please help :)) P.S. oracle instant client does not depend on any linux_base, which was little strange for me, but just for info I have installed latest linux_base_fc4. Thanks in advance. -- Best Wishes, Stefan Lambrev ICQ# 24134177 FWIW, I have oracle8-client-0.1.1_1 package running in FreeBSD 6-STABLE. This package does not have sqlplus but allows me to connect to Oracle using p5-DBD-Oracle-1.16_3 p5-DBI-1.50 and perl. $ pkg_info | egrep Oracle|DBI oracle8-client-0.1.1_1 Oracle 8 client p5-DBD-Oracle-1.16_3 DBI driver for Oracle RDBMS server p5-DBI-1.50 The perl5 Database Interface. Required for DBD::* modules $ uname -sr FreeBSD 6.1-STABLE regards, joseph ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
bce0 watchdog timeout errors
I'm still seeing an ongoing problem with the bce device on my Dell 1950. I'm running AMD64 6-STABLE, with the stock SMP kernel, and I'm running the most recent version of the bce driver, which did cure the other errors we were seeing (the mbuf related ones). The card is currently connected at an auto-negotiated 100BaseTX full duplex (rather than gigabit) as we don't currently have a gigabit switch to test on (the machine is under test rather than deployed). I can consistently cause the system to go into a 'Watchdog timeout occurred, resetting!' loop, by trying to do any reasonable amount of work over an nfs mounted filesystem. An easy way to reproduce this for me is to try and build some reasonably large port on our nfs mounted copy of the ports tree. I can also cause this by running bonnie++ against an nfs mounted filesystem. I've so far failed to find some simpler network only test to trigger the problem (I've tried sshing large amounts of data back and forth, iperf, ping floods, etc). NFS seems to do the trick every time though. Once it's reported the watchdog timeout, the networking on the box never recovers. Is anyone else seeing anything similar? And does anyone have any suggestions as to what I can do to try and diagnose this further so we can get to the bottom of it? Thanks, Sam. -- Fortified with Essential Bitterness and Sarcasm Matt Groening, Binky's Guide to Love. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS locking: lockf freezes (rpc.lockd problem?)
An alternative would be to update to RELENG_6 (or at least RELENG_6_1) and then try again. So. I have done this. And I can't reproduce the problem. # uname -a FreeBSD venus.araneidae.co.uk 6.1-STABLE FreeBSD 6.1-STABLE #1: Mon Aug 28 18:32:17 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Hmm. Hopefully this is a *good* thing, ie, the problem really has been fixed, rather than just going into hiding. So, as far as I can tell, lockf works properly in this release. Sorry to have generated so much traffic on this! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: invalid ife-ifm_data (0xa) in mii_phy_setmedia
Hi, I've got panic on FreeBSD 6.1-STABLE when I enabled following kernel options: options WITNESS options WITNESS_KDB options WITNESS_SKIPSPIN options INVARIANTS options INVARIANT_SUPPORT options DEBUG_LOCKS options DEBUG_VFS_LOCKS FreeBSD devil.micom.mng.net 6.1-STABLE FreeBSD 6.1-STABLE #10: Mon Aug 28 12:32:10 ULAST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEVIL i386 bge0: Broadcom BCM5752 A2, ASIC rev. 0x6002 mem 0xdfcf-0xdfcf irq 18 at device 0.0 on pci9 bge0: firmware handshake timed out miibus0: MII bus on bge0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:14:22:fb:32:a6 [EMAIL PROTECTED]:0:0: class=0x02 card=0x01c21028 chip=0x160014e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'Broadcom NetXtreme Gigabit Ethernet' class= network subclass = ethernet panic: invalid ife-ifm_data (0xa) in mii_phy_setmedia cpuid = 1 KDB: enter: panic [thread pid 251 tid 100062 ] Stopped at kdb_enter+0x2b: nop db bt Tracing pid 249 tid 100054 td 0xc4c5 kdb_enter(c07a8a15) at kdb_enter+0x2b panic(c0796b5a,a,c086a7e0,2,c07aa244,...) at panic+0x127 mii_phy_setmedia(c4be6600) at mii_phy_setmedia+0x7f ukphy_service(c4be6600,c4bde880,2) at ukphy_service+0xfd mii_mediachg(c4bde880,8803,c4bde880,c4be7400,c4be9000,...) at mii_mediachg+0x27 bge_stop(c4be9000,80206910,c4db26c0,c4be9000,e5036c0c,...) at bge_stop+0x5b8 bge_init_locked(c4be9000) at bge_init_locked+0x36 bge_ioctl(c4be7400,80206910,c4db26c0) at bge_ioctl+0x1ef ifhwioctl(80206910,c4be7400,c4db26c0,c4c5) at ifhwioctl+0x303 ifioctl(c4eca164,80206910,c4db26c0,c4c5,0,...) at ifioctl+0xbd soo_ioctl(c4e00240,80206910,c4db26c0,c4ac2780,c4c5) at soo_ioctl+0x2db ioctl(c4c5,e5036d04) at ioctl+0x370 syscall(3b,3b,3b,3,1,...) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281472ff, esp = 0xbfbfe5dc, ebp = 0xbfbfe628 --- db c Uptime: 11s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort KDB: stack backtrace: kdb_backtrace(e4fd1c2c,c05fb7ba,c07b2a73,c07b2b98,c4e962b8,...) at kdb_backtrace+0x29 vfs_badlock(c07b2a73,c07b2b98,c4e962b8) at vfs_badlock+0x11 assert_vop_locked(c4e962b8,c07b2b98) at assert_vop_locked+0x4a vop_lock_post(e4fd1c78,0,1002,c4e962b8,e4fd1c94,...) at vop_lock_post+0x2a VOP_LOCK_APV(c081c280,e4fd1c78) at VOP_LOCK_APV+0xa0 vn_lock(c4e962b8,1002,c4c06480) at vn_lock+0xac sync_vnode(c4e963c4,c4c06480) at sync_vnode+0xe3 sched_sync(0,e4fd1d38,0,c05f9150,0,...) at sched_sync+0x1ed fork_exit(c05f9150,0,e4fd1d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4fd1d6c, ebp = 0 --- VOP_LOCK: 0xc4e962b8 is not locked but should be KDB: enter: lock violation [thread pid 46 tid 100042 ] Stopped at kdb_enter+0x2b: nop db c KDB: stack backtrace: kdb_backtrace(e4fd1c78,c05fb86d,c07b2ab5,c07ceb78,c4e962b8,...) at kdb_backtrace+0x29 vfs_badlock(c07b2ab5,c07ceb78,c4e962b8) at vfs_badlock+0x11 assert_vop_elocked(c4e962b8,c07ceb78,c4e962b8,c07ceb78) at assert_vop_elocked+0x4d VOP_FSYNC_APV(c081c280,e4fd1cbc) at VOP_FSYNC_APV+0x8e sync_vnode(c4e963c4,c4c06480) at sync_vnode+0x106 sched_sync(0,e4fd1d38,0,c05f9150,0,...) at sched_sync+0x1ed fork_exit(c05f9150,0,e4fd1d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4fd1d6c, ebp = 0 --- VOP_FSYNC: 0xc4e962b8 is not exclusive locked but should be KDB: enter: lock violation [thread pid 46 tid 100042 ] Stopped at kdb_enter+0x2b: nop db c KDB: stack backtrace: kdb_backtrace(e4fd1c78,c05fb86d,c07b2ab5,c07ceb78,c4e962b8,...) at kdb_backtrace+0x29 vfs_badlock(c07b2ab5,c07ceb78,c4e962b8) at vfs_badlock+0x11 assert_vop_elocked(c4e962b8,c07ceb78,c4e962b8,c07ceb78) at assert_vop_eloc ked+0x4d VOP_FSYNC_APV(c081c280,e4fd1cbc) at VOP_FSYNC_APV+0xcb sync_vnode(c4e963c4,c4c06480) at sync_vnode+0x106 sched_sync(0,e4fd1d38,0,c05f9150,0,...) at sched_sync+0x1ed fork_exit(c05f9150,0,e4fd1d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4fd1d6c, ebp = 0 --- VOP_FSYNC: 0xc4e962b8 is not exclusive locked but should be KDB: enter: lock violation [thread pid 46 tid 100042 ] Stopped at kdb_enter+0x2b: nop db c KDB: tack backtrace: kdb_backtrace(e4fd1c70,c05fb7ba,c07b2a73,c07b2ba1,c4e962b8,...) at kdb_backtrace+0x29 vfs_badlock(c07b2a73,c07b2ba1,c4e962b8) at vfs_badlock+0x11 assert_vop_locked(c4e962b8,c07b2ba1,c081c280,e4fd1c98,c0762f26,...) at assert_vop_locked+0x4a vop_unlock_pre(e4fd1cac) at vop_unlock_pre+0x2d VOP_UNLOCK_APV(c081c280,e4fd1cac) at VOP_UNLOCK_APV+0x82 sync_vnode(c4e963c4,c4c06480) at sync_vnode+0x129
Re: panic: invalid ife-ifm_data (0xa) in mii_phy_setmedia
Hi,
Thanks a lot for your patch. Your patch fixes panic, however I still see
bge0: firmware handshake timed out
bge0: link state changed to DOWN
messages.
When I tried to use Oleg's if_bge.c, rev. 1.140 in STABLE buildkernel stops:
mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I-
-DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I@/../include
-I/usr/include -I/usr/obj/usr/src/sys/DEVIL
/usr/src/sys/modules/bge/../../dev/bge/if_bge.c
/usr/src/sys/modules/bge/../../dev/bge/if_bge.c:2570:35: macro
VLAN_INPUT_TAG requires 4 arguments, but only 3 given
mkdep: compile failed
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
mkdep: compile failed
*** Error code 1
2 errors
*** Error code 2
1 error
*** Error code 2
1 error
I see VLAN_INPUT_TAG is defined as VLAN_INPUT_TAG(_ifp, _m, _t,
_errcase) in if_vlan_var.h, rev v 1.21.2.2 with 4 arguments, however
new if_bge.c, rev. 1.140 uses 3 arguments.
Is it safe to use if_vlan_var.h, rev 1.24 and if_vlan.c, rev 1.114 only?
What other patches should I use?
When all these changes MFC to STABLE?
thanks,
Ganbold
Pyun YongHyeon wrote:
I think your PHY was not recognized by brgphy(4). But I don't know it
fixes firmware handshake timed out issue you've seen.
Recently oleg fixed a long standing bug in bge(4). So you may also want
to merge the change.(See if_bge.c, rev. 1.140)
Patch generated against RELENG_6(compile tested only).
Index: miidevs
===
RCS file: /home/ncvs/src/sys/dev/mii/miidevs,v
retrieving revision 1.30.2.3
diff -u -r1.30.2.3 miidevs
--- miidevs 8 Aug 2006 07:51:21 - 1.30.2.3
+++ miidevs 30 Aug 2006 02:28:07 -
@@ -118,6 +118,7 @@
model xxBROADCOM BCM5400 0x0004 Broadcom 1000baseTX PHY
model xxBROADCOM BCM5401 0x0005 BCM5401 10/100/1000baseTX PHY
model xxBROADCOM BCM5411 0x0007 BCM5411 10/100/1000baseTX PHY
+model xxBROADCOM BCM5752 0x0010 BCM5752 10/100/1000baseTX PHY
model xxBROADCOM BCM5701 0x0011 BCM5701 10/100/1000baseTX PHY
model xxBROADCOM BCM5703 0x0016 BCM5703 10/100/1000baseTX PHY
model xxBROADCOM BCM5704 0x0019 BCM5704 10/100/1000baseTX PHY
Index: brgphy.c
===
RCS file: /home/ncvs/src/sys/dev/mii/brgphy.c,v
retrieving revision 1.34.2.6
diff -u -r1.34.2.6 brgphy.c
--- brgphy.c8 Aug 2006 04:37:18 - 1.34.2.6
+++ brgphy.c30 Aug 2006 02:28:07 -
@@ -126,6 +126,12 @@
}
if (MII_OUI(ma-mii_id1, ma-mii_id2) == MII_OUI_xxBROADCOM
+ MII_MODEL(ma-mii_id2) == MII_MODEL_xxBROADCOM_BCM5752) {
+ device_set_desc(dev, MII_STR_xxBROADCOM_BCM5752);
+ return(BUS_PROBE_DEFAULT);
+ }
+
+ if (MII_OUI(ma-mii_id1, ma-mii_id2) == MII_OUI_xxBROADCOM
MII_MODEL(ma-mii_id2) == MII_MODEL_xxBROADCOM_BCM5701) {
device_set_desc(dev, MII_STR_xxBROADCOM_BCM5701);
return(BUS_PROBE_DEFAULT);
@@ -665,6 +671,7 @@
bcm5704_load_dspcode(sc);
break;
case MII_MODEL_xxBROADCOM_BCM5750:
+ case MII_MODEL_xxBROADCOM_BCM5752:
case MII_MODEL_xxBROADCOM_BCM5714:
case MII_MODEL_xxBROADCOM_BCM5780:
case MII_MODEL_xxBROADCOM_BCM5706C:
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
