Re: Unusual TCP/IP Packet Size
14.02.2013 14:54, Doug Hardie пишет: How do I configure the msk0 interface in rc.conf to disable tso4? I can easily do it with ifconfig, but don't see how to make sure its disabled after a boot. Just add corresponding flag to ifconfig_msk0 line in rc.conf: ifconfig_msk0=inet 10.0.1.199 netmask 0xff00 -tso -vlanhwtso ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9.1 - openldap slapd lockups, mutex problems
Hi, On Thu, Feb 14, 2013 at 03:13:57AM +0100, Pierre Guinoiseau wrote: I have seen openldap spin the cpu and even run out of memory to get killed on some of our test systems running ~9.1-rel with zfs. [...] I've the same problem too, inside a jail, stored on ZFS. I've tried various tuning in slapd.conf, but none fixed the problem. While hanging, db_stat -c shows that all locks are being used, I've tried to set the limit really high, far more than normally needed, but it didn't help. I may have the same problem with amavisd-new but I've to verify that to be sure the symptoms are similar. I have amd64 9.1-STABLE r245456 (about Jan 15) running. I have openldap openldap-server-2.4.33_2 running, depending on libltdl-2.4.2 and db46-4.6.21.4 . The system is zfs only (for the local filesystems, where openldap is running - it has several NFS mounts for other purposes though). It's up and running for about a month now (29 days) and never showed any problematic behaviour regarding to slapd. I have ~10 SEARCH requests per seconds avg and only minor ADD/MODIFY/DELETE operations. It has several binds und unbinds, about 1/10th of the requests. It runs in slurpd slave mode for my master LDAP. zroot/var/db runs with compression=off, dedup=off, zroot is a mirrored pool on 2 Intel SATA SSD drives inside a GPT partition. Swap is on a ZFS zvol. - Oliver -- | Oliver Brandmueller http://sysadm.in/ o...@sysadm.in | |Ich bin das Internet. Sowahr ich Gott helfe. | pgplZkz_4YApY.pgp Description: PGP signature
Re: stable/9 Xorg freezes and hangs in drmlk2
On 10/02/2013 12:54, Dominic Fandrey wrote: Occasionally Xorg freezes and hangs in state drmlk2, when I start the compositing manager or an overlay window (i.e. mplayer) opens. The last time that happened (starting the compositor) I ssh'ed into the box and collected some data. … It happened again, this time when I tried to play back a video with mplayer. This time Xorg hung in the state _drmwtq_. Everything looks the same apart from the state: http://pastebin.com/hXVKyjp1 This time however I wasn't able to revive Xorg, so this time I've got an Xorg.0.log full of juicy error output, that I hope may be able to give someone a clue: http://pastebin.com/yTzXyjG7 Uptime ~3d 16h. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Why scf (sfcd) monitoring sometimes doesn't work
Hello, I found fsc (http://www.freshports.org/sysutils/fsc/) to be extremely useful. Unfortunately, I can't get some services to be monitored, fscadm enable just failes with Could not monitor service. I don't know how kqueue interaction is working, so I can't guess why some services can be monitored fine and others not. How can I start finding out what goes wrong? How does the rc-name play into that role? Thanks, -Harry signature.asc Description: OpenPGP digital signature
Why fsc (fscd) monitoring sometimes doesn't work [Was: Re: Why scf (sfcd) monitoring sometimes doesn't work]
schrieb Harald Schmalzbauer am 14.02.2013 13:34 (localtime): Hello, I found fsc (http://www.freshports.org/sysutils/fsc/) to be extremely useful. Unfortunately, I can't get some services to be monitored, fscadm enable just failes with Could not monitor service. I don't know how kqueue interaction is working, so I can't guess why some services can be monitored fine and others not. How can I start finding out what goes wrong? How does the rc-name play into that role? Sorry for the ugly typo in the topic! signature.asc Description: OpenPGP digital signature
i386: vm.pmap kernel local race condition
Hi! I've got FreeBSD 8.3-STABLE/i386 server that can be reliably panicked using just 'squid -k rotatelog' command. It seems the system suffers from the problem described here: http://cxsecurity.com/issue/WLB-2010090156 I could not find any FreeBSD Security Advisory containing a fix. My server has 4G physical RAM (about 3.2G available) and runs squid (about 110M VSS) with 500 ntlm_auth subprocesses. Lesser number of ntlm_auth sometimes results in squid crash as it sometimes has several hundreds requests per second to authorize and is intolerant to exhaustion of free ntlm_auth. squid -k rotatelog at midnight results in crash: Feb 14 00:03:00 irl savecore: reboot after panic: get_pv_entry: increase vm.pmap.shpgperproc Feb 14 00:03:00 irl savecore: writing core to vmcore.1 Btw, I have coredump. vm.pmap.shpgperproc has default value (200) here, as well as m.v_free_min, vm.v_free_reserved, and vm.v_free_target and KVA_PAGES. These crashes are pretty regular # last|fgrep reboot reboot ~ Thu Feb 14 00:03 reboot ~ Wed Feb 13 19:08 reboot ~ Wed Feb 13 10:40 reboot ~ Wed Feb 13 00:04 reboot ~ Tue Feb 12 00:09 reboot ~ Mon Feb 11 00:03 reboot ~ Sun Feb 10 00:03 reboot ~ Thu Feb 7 00:03 reboot ~ Wed Feb 6 10:52 reboot ~ Sun Feb 3 00:03 reboot ~ Sat Feb 2 00:03 May this be considered as security problem? Can it be fixed without switch to amd64? I have only remote access to this production server, no serial console. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Why can't gcc-4.2.1 build usable libreoffice?
Hello! I just finished building editors/libreoffice with gcc-4.2.1 -- had to edit the port's Makefile to prevent it from picking a different compiler. Everything built and installed, but libreoffice dies on start-up (right after flashing the splash-window): (gdb) where #0 0x00080596c1aa in cppu::__getTypeEntries () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #1 0x00080596c333 in cppu::__queryDeepNoXInterface () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #2 0x00080596d4a2 in cppu::WeakImplHelper_query () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #3 0x0008116f2b03 in cppu::WeakImplHelper1com::sun::star::lang::XEventListener::queryInterface () from /opt/lib/libreoffice/ure/lib/bootstrap.uno.so #4 0x000805970347 in cppu::OInterfaceContainerHelper::disposeAndClear () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #5 0x0008059705b2 in cppu::OMultiTypeInterfaceContainerHelper::disposeAndClear () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #6 0x00080593309f in cppu::OComponentHelper::dispose () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #7 0x000805963d00 in cppu::OFactoryComponentHelper::dispose () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #8 0x0008116ec296 in stoc_smgr::OServiceManager::disposing () from /opt/lib/libreoffice/ure/lib/bootstrap.uno.so #9 0x00080596af05 in cppu::WeakComponentImplHelperBase::dispose () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #10 0x0008116e6244 in stoc_smgr::ORegistryServiceManager::dispose () from /opt/lib/libreoffice/ure/lib/bootstrap.uno.so #11 0x00080596a573 in cppu::WeakComponentImplHelperBase::release () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #12 0x0008059482f6 in (anonymous namespace)::createTypeRegistry () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #13 0x0008059487bf in cppu::defaultBootstrap_InitialComponentContext () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #14 0x000805948918 in cppu::defaultBootstrap_InitialComponentContext () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #15 0x00080212f883 in desktop::Desktop::InitApplicationServiceManager () from /opt/lib/libreoffice/program/libmergedlo.so #16 0x00080211f362 in desktop::Desktop::Init () from /opt/lib/libreoffice/program/libmergedlo.so #17 0x000807622113 in InitVCL () from /opt/lib/libreoffice/program/libvcllo.so #18 0x000807623151 in ImplSVMain () from /opt/lib/libreoffice/program/libvcllo.so #19 0x0008076232d5 in SVMain () from /opt/lib/libreoffice/program/libvcllo.so #20 0x00080214942e in soffice_main () from /opt/lib/libreoffice/program/libmergedlo.so #21 0x00400773 in main () I do not blame the office@ team -- the port did not want to use gcc-4.2.1, I forced it to. But I'd like to know, what is wrong with the compiler shipped by FreeBSD-9.1 (and the only one, if WITHOUT_CLANG is defined), that prevents building a healthy libreoffice? Is there a bug fixed in gcc-4.6? Or is it some (incorrect) assumption made by libreoffice code? Thank you, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unusual TCP/IP Packet Size
On Wed, Feb 13, 2013 at 11:54:24PM -0800, Doug Hardie wrote: On 13 February 2013, at 22:45, YongHyeon PYUN pyu...@gmail.com wrote: On Wed, Feb 13, 2013 at 09:10:36PM -0800, Kevin Oberman wrote: On Wed, Feb 13, 2013 at 5:37 PM, YongHyeon PYUN pyu...@gmail.com wrote: On Wed, Feb 13, 2013 at 05:00:59AM -0800, Jeremy Chadwick wrote: On Wed, Feb 13, 2013 at 05:29:53PM +0700, Eugene Grosbein wrote: 13.02.2013 17:25, Doug Hardie ??: Monitoring a tcpdump between two systems, a FreeBSD 9.1 system has the following interface: msk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c011bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE ether 00:11:2f:2a:c7:03 inet 10.0.1.199 netmask 0xff00 broadcast 10.0.1.255 inet6 fe80::211:2fff:fe2a:c703%msk0 prefixlen 64 scopeid 0x1 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex,flowcontrol,rxpause,txpause) status: active It sent the following packet: (data content abbreviated) 02:14:42.081617 IP 10.0.1.199.443 10.0.1.2.61258: Flags [P.], seq 930:4876, ack 846, win 1040, options [nop,nop,TS val 401838072 ecr 920110183], length 3946 0x: 4500 0f9e ea89 4000 4006 2a08 0a00 01c7 E.@.@.*. 0x0010: 0a00 0102 01bb ef4a ece1 680b ae37 1bbc ...J..h..7.. 0x0020: 8018 0410 3407 0101 080a 17f3 8ff8 4...??. The indicated packet length is 3946 and the load of data shown is that size. The MTU on both interfaces is 1500. The receiving system received 3 packets. There is a router and switch between them. One of them fragmented that packet. This is part of a SSL/TLS exchange and one side or the other is hanging on this and just dropping the connection. I suspect the packet size is the issue. ssldump complains about the packet too and stops monitoring. Could this possibly be related to the hardware checksums? You have TSO enabled on the interface, so large outgoing TCP packet is pretty normal. It will be split by the NIC. Disable TSO with ifconfig if it interferes with your ssldump. This is not the behaviour I see with em(4) on a 82573E with all defaults used (which includes TSO4). Note that Doug is using msk(4). I can provide packet captures on both ends of a LAN segment using both tcpdump (on the FreeBSD side) and Wireshark (on the Windows side) that show a difference in behaviour compared to what Doug sees. This is strange. tcpdump sees a (big) TCP segment right before controller actually transmits it. So if TSO is active for the TCP segment, you should see a series of small TCP packets on receiver side(i.e. 3 TCP packets in Doug's case). If you don't see a big TCP segment with tcpdump on TX path, probably TSO was not used for the TCP segment. It's possible for controller to corrupt the TCP segment during segmentation but Doug's tcpdump looks completely normal to me since tcpdump sees the segment before TCP segmentation. What I see on the FreeBSD side with tcpdump is repeated bad-len 0 messages for payloads which are chunked or segmented as a result of TSO. I do not see a 1:1 ratio of bad-len entries to chunked payloads; I only see one bad-len entry for all chunks (up until the next ACK or PSH+ACK of course). I vaguely recall that some users reported similar TSO issues on various drivers. The root cause of the issue was not identified though. Personally I couldn't reproduce the issue at that time. It could be a driver or network stack bug. Beware TSO. It can significantly improve throughput on high speed networks, but it really has issues. TSO segments the data and transmits all of them back-to-back with no delay beyond IFG (the 802.3 mandated space between frames) TSO does not understand congestion control. If there is congestion and TSO sends several frames in a row, it is entirely possible that a queue is full or getting close enough to full to start dropping packets and these segmented frames are excellent candidates. I'm not saying the drawback of TSO. Sometimes segmented packets have malformed IP header length under certain circumstances such that these packets were dropped on receiver side. How do I configure the msk0 interface in rc.conf to disable tso4? I can easily do it with ifconfig, but don't see how to make sure its disabled after a boot. Adjust your ifconfig_msk0 line in rc.conf to contain -tso, i.e.: ifconfig_msk0=inet 10.0.1.199 netmask 255.255.255.0 -tso -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___
Re: 9-STABLE - NFS - NetAPP:
Marc Fournier wrote: On 2013-02-13, at 3:54 PM, Rick Macklem rmack...@uoguelph.ca wrote: The pid that is in T state for the ps auxlH. Different server, last kernel update on Jan 22nd, https process this time instead of du last time. I've attached: ps auxlH ps auxlH of just the processes that are in TJ state (6 httpd servers) procstat output for each of the 6 process They are included as attachments … if these don't make it through, let me know, just figured I'd try and keep it compact ... Ok, I took a look and the interesting process seems to be 16693. It is stopped (T state) and several of its threads (22, but not all) have a procstat like this: 16693 104135 httpd-mi_switch+0x186 thread_suspend_check+0x19f sleepq_catch_signals+0x1c5 sleepq_timedwait_sig+0x19 _sleep+0x2ca clnt_vc_call+0x763 clnt_reconnect_call+0xfb newnfs_request+0xadb nfscl_request+0x72 nfsrpc_accessrpc+0x1df nfs34_access_otw+0x56 nfs_access+0x306 vn_open_cred+0x5a8 kern_openat+0x20a amd64_syscall+0x540 Xfast_syscall+0xf7 The sleep in clnt_vc_call is waiting for an RPC reply (while a vnode lock is held) with PCATCH | PBDRY flags, since it interruptible. I can see that the thread_suspend_check() has a 1 argument (return_instead == 1), since there is only one call to thread_suspend_check() in sleepq_catch_signals(). When looking at thread_suspend_check(), I basically got lost, although it seems that it can only return_instead if there is a single thread and not multiple threads doing this. If these threads are stuck here and won't return from msleep(), that would explain the hang. If they would wakeup and return from the msleep() when a wakeup occurs, it would suggest that there is a lost reply or similar, so the wakeup isn't occurring. I also don't know if a timeout of the msleep() will still occur and make the msleep() return? Although it wasn't done to fix this, it looks like jhb@'s recent patch to head (r246417) might fix this, since it reworks how STOP signals are handled for interruptible mounts. Hopefully kib or jhb can provide more insight. Btw Marc, if you just want this problem to go away, I suspect getting rid of the intr mount option would do that. rick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Ipsec VPN tunnel from a Win/7 box?
I read around the net that using racoon and the kernel-based IPSEC options do not work with Windows 7. Is there a configuration that does? -- -- Karl Denninger /The Market Ticker ®/ http://market-ticker.org Cuda Systems LLC ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9-STABLE - NFS - NetAPP:
On 2013-02-14, at 08:41 , Rick Macklem rmack...@uoguelph.ca wrote: Btw Marc, if you just want this problem to go away, I suspect getting rid of the intr mount option would do that. Am more interested in fixing the problem (if possible) then just masking it, but ... Based on the man page for mount_nfs, wouldn't that have the opposite effect: intrMake the mount interruptible, which implies that file system calls that are delayed due to an unresponsive server will fail with EINTR when a termination signal is posted for the process. I may be mis-reading, but from the above it sounds like a -9 *should* terminate the process if intr is enabled, while with it disabled, it would ignore it … ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Ipsec VPN tunnel from a Win/7 box?
On Thu, Feb 14, 2013, Karl Denninger wrote: I read around the net that using racoon and the kernel-based IPSEC options do not work with Windows 7. Is there a configuration that does? I don't know about IPsec, but OpenVPN works very nicely. Bill Bill -- INTERNET: b...@celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax:(206) 232-9186 Skype: jwccsllc (206) 855-5792 Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes...Such laws make things worse for the assaulted and better for the assailants. --- http://www.lewrockwell.com/alston/alston60.1.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Ipsec VPN tunnel from a Win/7 box?
On 2/14/2013 1:29 PM, Bill Campbell wrote: On Thu, Feb 14, 2013, Karl Denninger wrote: I read around the net that using racoon and the kernel-based IPSEC options do not work with Windows 7. Is there a configuration that does? I don't know about IPsec, but OpenVPN works very nicely. Bill I can get PPTP to come up with mpd5, but IPSEC is a better option if it can be made to work.. thus far no joy in that direction though. -- -- Karl Denninger /The Market Ticker ®/ http://market-ticker.org Cuda Systems LLC ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
NFS resources, how to check version
Hello, I set up NFSv4 server. To make sure I set vfs.nfsd.server_min_nfsvers=4. I can check its version, for example, by tcpduming and then I can see in wireshark lines like: Network File System Program Version: 4 V4 Procedure: COMPOUND is there any easier way to check its version? I see there is nfsstat -e option which shows delegs and locks. But all other ones are combined with nfsv3 I guess (On Ubuntu there are separate lines: v3 and v4) and on the client side, is it possible to check which version is exported or mounted? something like % showmount -e nfsserver Is forcing mount to use nfsv4 100% sure? (mount -t nfs -o nfsv4 ) and btw. Is forcing mount to use -sec=krb5 (with -sec=sys:krb5:krb5i:krb5p in /etc/exports) also 100% sure? because it mounts and doesn't give ticket for nfs/nfsserver. So, I guess if -sec=krb5 is not available, it mounts with -sec=sys, right? With -sec=krb5:krb5i:krb5p in /etc/exports it doesn't mount. I am wondering if you force -o nfsv4, it wouldn't mount it like nfsv3. Happy Valentines! -- Best wishes Janusz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Panic at shutdown
Le mardi 12 février 2013 21:42:01 Ronald Klop a écrit :
On Tue, 12 Feb 2013 19:44:49 +0100, David Demelier
demelier.da...@gmail.com wrote:
Le mardi 12 février 2013 10:01:10 Andriy Gapon a écrit :
on 12/02/2013 09:57 David Demelier said the following:
Yes I have added debugging option in my kernel. I have makeoptions
DEBUG=-g in my config. Do I need more ?
.symbols?
I don't understand what you are saying, I have
/boot/kernel/kernel.symbols.
Please tell me what I'm doing wrong. I've just read and done the steps
written
there :
http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-
gdb.html
So I've run
# cd /usr/obj/usr/src/sys/Melon
# kgdb kernel.debug /var/crash/vmcore.0
Why not something like kgdb /boot/kernel/kernel.symbols
/var/crash/vmcore.0?
That looks like what the manual page of kgdb seems to suggest.
Regards,
Ronald.
and that's the only trace I get using bt full :
229 #define IS_BSP()(PCPU_GET(cpuid) == 0)
(kgdb) bt full
#0 doadump (textdump=value optimized out) at pcpu.h:229
No locals.
#1 0x in ?? ()
No symbol table info available.
--
David Demelier
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Today I have a little bit more :
#0 0x804f358b in isbufbusy (bp=0xfe0003810480) at
/usr/src/sys/kern/kern_shutdown.c:280
280 if (((bp-b_flags (B_INVAL | B_PERSISTENT)) == 0
(kgdb) bt full
#0 0x804f358b in isbufbusy (bp=0xfe0003810480) at
/usr/src/sys/kern/kern_shutdown.c:280
No locals.
#1 0x0004 in ?? ()
No symbol table info available.
#2 0x804f3aa6 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:451
_ep = (struct eventhandler_entry *) 0x100
_el = (struct eventhandler_list *) 0x804f35b3
first_buf_printf = 1
#3 0x804f3f69 in panic (fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:624
td = (struct thread *) 0x1
bootopt = 260
newpanic = 1
ap = {{gp_offset = 16, fp_offset = 48, overflow_arg_area =
0xff80daaf0420, reg_save_area = 0xff80daaf0350}}
panic_cpu = 0
buf = general protection fault, '\0' repeats 231 times
#4 0x806fcf69 in trap_fatal (frame=0x9, eva=Variable eva is not
available.
) at /usr/src/sys/amd64/amd64/trap.c:851
code = Variable code is not available.
--
David Demelier
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unusual TCP/IP Packet Size
On Thu, Feb 14, 2013 at 10:37:23AM +0900, YongHyeon PYUN wrote: On Wed, Feb 13, 2013 at 05:00:59AM -0800, Jeremy Chadwick wrote: On Wed, Feb 13, 2013 at 05:29:53PM +0700, Eugene Grosbein wrote: 13.02.2013 17:25, Doug Hardie ??: Monitoring a tcpdump between two systems, a FreeBSD 9.1 system has the following interface: msk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c011bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE ether 00:11:2f:2a:c7:03 inet 10.0.1.199 netmask 0xff00 broadcast 10.0.1.255 inet6 fe80::211:2fff:fe2a:c703%msk0 prefixlen 64 scopeid 0x1 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex,flowcontrol,rxpause,txpause) status: active It sent the following packet: (data content abbreviated) 02:14:42.081617 IP 10.0.1.199.443 10.0.1.2.61258: Flags [P.], seq 930:4876, ack 846, win 1040, options [nop,nop,TS val 401838072 ecr 920110183], length 3946 0x: 4500 0f9e ea89 4000 4006 2a08 0a00 01c7 E.@.@.*. 0x0010: 0a00 0102 01bb ef4a ece1 680b ae37 1bbc ...J..h..7.. 0x0020: 8018 0410 3407 0101 080a 17f3 8ff8 4...??. The indicated packet length is 3946 and the load of data shown is that size. The MTU on both interfaces is 1500. The receiving system received 3 packets. There is a router and switch between them. One of them fragmented that packet. This is part of a SSL/TLS exchange and one side or the other is hanging on this and just dropping the connection. I suspect the packet size is the issue. ssldump complains about the packet too and stops monitoring. Could this possibly be related to the hardware checksums? You have TSO enabled on the interface, so large outgoing TCP packet is pretty normal. It will be split by the NIC. Disable TSO with ifconfig if it interferes with your ssldump. This is not the behaviour I see with em(4) on a 82573E with all defaults used (which includes TSO4). Note that Doug is using msk(4). I can provide packet captures on both ends of a LAN segment using both tcpdump (on the FreeBSD side) and Wireshark (on the Windows side) that show a difference in behaviour compared to what Doug sees. This is strange. tcpdump sees a (big) TCP segment right before controller actually transmits it. So if TSO is active for the TCP segment, you should see a series of small TCP packets on receiver side(i.e. 3 TCP packets in Doug's case). If you don't see a big TCP segment with tcpdump on TX path, probably TSO was not used for the TCP segment. It's possible for controller to corrupt the TCP segment during segmentation but Doug's tcpdump looks completely normal to me since tcpdump sees the segment before TCP segmentation. Let me explain what I'm referring to. In the below tcpdump on the server, you'll find 5 bad-len 0 messages. These correlate directly with TCP payloads that exceed MTU -- this is verified by comparing to the number of lines labelled TCP segment of reassembled PDU **that exceed MTU (1500)** in Wireshark (when analysing the same server capture). Thus, the bad-len 0 messages in tcpdump are indicators of TSO being used. Doug's capture with msk(4) + TSO shows a TCP length that exceeds MTU, yet my capture with em(4) + TSO shows bad-len 0. Wireshark seems to decode server capture correctly, so I'm inclined to think this is a libpcap/tcpdump quirk/bug of sorts. I just find it very strange that NIC difference manifests itself like this (and in some regards, concerns me). I'm happy to provide the pcap files from both server and client if someone wants to do the analysis, as well as a verbose output from Wireshark (vs. just the summary lines) if all packet fields are desired. Server = 192.168.1.51 (FreeBSD, Intel 82573E, em(4), with TSO) Client = 192.168.1.50 (Windows XP SP3) Server capture (tcpdump -p -i em0 -n -s 0 -w server.pcap): 12:14:54.512542 IP 192.168.1.50.1300 192.168.1.51.80: Flags [S], seq 375412185, win 65535, options [mss 1460,nop,wscale 3,nop,nop,sackOK], length 0 12:14:54.512576 IP 192.168.1.51.80 192.168.1.50.1300: Flags [S.], seq 339580135, ack 375412186, win 65535, options [mss 1460,nop,wscale 6,sackOK,eol], length 0 12:14:54.512659 IP 192.168.1.50.1300 192.168.1.51.80: Flags [.], ack 1, win 64240, length 0 12:14:54.512784 IP 192.168.1.50.1300 192.168.1.51.80: Flags [P.], seq 1:330, ack 1, win 64240, length 329 12:14:54.515194 IP 192.168.1.51.80 192.168.1.50.1300: Flags [P.], seq 1:279, ack 330, win 1026, length 278 12:14:54.515230 IP bad-len 0 12:14:54.515410 IP 192.168.1.50.1300 192.168.1.51.80: Flags [.], ack 1739, win 64240, length 0 12:14:54.515423 IP bad-len 0 12:14:54.515429 IP 192.168.1.50.1300
Re: 9.1-RELEASE AMD64 crash under VBox 4.2.6 when IO APIC is disabled
On Wednesday, February 13, 2013 6:56:06 pm CeDeROM wrote: On Wed, Feb 13, 2013 at 4:48 PM, John Baldwin j...@freebsd.org wrote: The simple answer that I have deduced is that APIC is MANDATORY for AMD64 machines and they won't run otherwise? This is why generic AMD64 install fails when no APIC is enabled in the VBox? No, it is not quite like that. x86 machines have two entirely different sets of interrupt controllers. (...) Hello John :-) Things now are more clear to me, thank you for your extensive explanation!! :-) I am wondering in that case if it wouldn't be a good idea to put atpci (old x86 IRQ handler) in the GENERIC configuration, or at least in the default installer kernel, so it is a safe fallback for a AMD64 machines with no APIC support, as for example VBox with APIC disabled..? Is atpic removed on purpose so it enforces use of new APIC and so better performance? Real hardware should always use device apic on amd64. Even for a VM you should prefer apic. That is, I think you should just enable APIC when using VBox. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why does poudriere always rebuild nginx and GraphicsMagick13?
Am 12.02.2013 um 23:11 schrieb Baptiste Daroussin b...@freebsd.org: On Tue, Feb 12, 2013 at 10:59:28PM +0100, Rainer Duffner wrote: Hi, poudriere 2.2 here, running on 9.1-amd64 Of the 730-ish ports, whenever I run a build, it always rebuilds the above two ports. Even if nothing changed. Is there are specific reason for this? I don't really mind nginx, because it builds so quickly - but GraphicsMagick takes a bit too long. 2.2 is so old :) please upgrade to at least 2.3.1, lots of things as been fixed since, and soon 2.3.2 with lots of other bug fixes. I'm sure 2.3.1 fixes your problems, or at least will explain you why something is rebuilt (it is now explained during the sanity check) regards, Bapt Hi Baptiste, so I upgraded to 2.3.1 but it still rebuilds those two ports every single time I run a bulk build. … Options changed, deleting: GraphicsMagick-nox11-1.3.16_1.txz Options changed, deleting: nginx-1.2.6,1.txz ... drwxr-xr-x 2 root wheel 512 Dec 21 09:20 GraphicsMagick/ drwxr-xr-x 2 root wheel 512 Dec 21 09:20 GraphicsMagick13/ drwxr-xr-x 2 root wheel 512 Dec 21 09:20 nginx/ Somehow, it thinks the options have changed. Maybe, the options-file has an error? Regards, Rainer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: NFS resources, how to check version
Janusz Bulik wrote: Hello, I set up NFSv4 server. To make sure I set vfs.nfsd.server_min_nfsvers=4. I can check its version, for example, by tcpduming and then I can see in wireshark lines like: Network File System Program Version: 4 V4 Procedure: COMPOUND is there any easier way to check its version? I see there is nfsstat -e option which shows delegs and locks. But all other ones are combined with nfsv3 I guess (On Ubuntu there are separate lines: v3 and v4) At the server, not that I can think of. As you noted, if you see non-zero values for the OpenOwners etc line when you do nfsstat -e -s, then some client is using NFSv4. jwd@ was working on some per-client stats, but we need to resurrect that work. (I can't remember if he has a patch for testing lying about these days?) and on the client side, is it possible to check which version is exported or mounted? something like % showmount -e nfsserver Is forcing mount to use nfsv4 100% sure? (mount -t nfs -o nfsv4 ) Yes, w.r.t. the FreeBSD client. Also, there is now a -m option on nfsstat that you can use on the client to dump exactly what mount options are being used. (It is in head and stable/9, but not 9.1-release.) and btw. Is forcing mount to use -sec=krb5 (with -sec=sys:krb5:krb5i:krb5p in /etc/exports) also 100% sure? Nope. I didn't code this and I've never been sure if it the correct thing to do, but the code falls through to using sys if it can't get a Kerberos credential. I'm guessing that the original author figured that, if the server cared, it would fail the RPC when a sys authenticator was used. because it mounts and doesn't give ticket for nfs/nfsserver. So, I guess if -sec=krb5 is not available, it mounts with -sec=sys, right? It is actually per-RPC. It will try to get a Kerberos credential, but fall through to using sys if that fails. With -sec=krb5:krb5i:krb5p in /etc/exports it doesn't mount. Correct. I think that was the original author's assumption. I am wondering if you force -o nfsv4, it wouldn't mount it like nfsv3. Yes, as above. Personally, I think it should always use whatever version the command line option specifies, but that is really up to the FreeBSD collective. It currently defaults to nfsv3 if no option is specified and, maybe. someday that should change to nfsv4, but it is not that way now. rick Happy Valentines! -- Best wishes Janusz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9-STABLE - NFS - NetAPP:
Marc Fournier wrote: On 2013-02-14, at 08:41 , Rick Macklem rmack...@uoguelph.ca wrote: Btw Marc, if you just want this problem to go away, I suspect getting rid of the intr mount option would do that. Am more interested in fixing the problem (if possible) then just masking it, but ... Based on the man page for mount_nfs, wouldn't that have the opposite effect: intr Make the mount interruptible, which implies that file system calls that are delayed due to an unresponsive server will fail with EINTR when a termination signal is posted for the process. I may be mis-reading, but from the above it sounds like a -9 *should* terminate the process if intr is enabled, while with it disabled, it would ignore it … ? Yes, you have misread it (or english is a wonderfully ambiguous thing, if you prefer;-). For hard mounts (which is what you get if you don't specify either soft nor intr), the RPCs behave like other I/O subsystems, which means they do non-interruptible sleeps (D stat in ps) waiting for server replies and continue to try and complete the RPC forever. You can't kill off the process/thread with any signal. If umount -f of the filesystem works, that terminates the thread(s). Unfortunately, umount -f is quite broken again. I have an idea on how to resolve this, but I haven't coded it yet. (The problem is that the process doing umount -f gets stuck before it does the VFS_UNMOUNT(), so the NFS client doesn't see it.) rick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9-STABLE - NFS - NetAPP:
On 2013-02-14, at 16:24 , Rick Macklem rmack...@uoguelph.ca wrote: Marc Fournier wrote: On 2013-02-14, at 08:41 , Rick Macklem rmack...@uoguelph.ca wrote: Btw Marc, if you just want this problem to go away, I suspect getting rid of the intr mount option would do that. Am more interested in fixing the problem (if possible) then just masking it, but ... Based on the man page for mount_nfs, wouldn't that have the opposite effect: intr Make the mount interruptible, which implies that file system calls that are delayed due to an unresponsive server will fail with EINTR when a termination signal is posted for the process. I may be mis-reading, but from the above it sounds like a -9 *should* terminate the process if intr is enabled, while with it disabled, it would ignore it … ? Yes, you have misread it (or english is a wonderfully ambiguous thing, if you prefer;-). For hard mounts (which is what you get if you don't specify either soft nor intr), the RPCs behave like other I/O subsystems, which means they do non-interruptible sleeps (D stat in ps) waiting for server replies and continue to try and complete the RPC forever. You can't kill off the process/thread with any signal. If umount -f of the filesystem works, that terminates the thread(s). Unfortunately, umount -f is quite broken again. I have an idea on how to resolve this, but I haven't coded it yet. (The problem is that the process doing umount -f gets stuck before it does the VFS_UNMOUNT(), so the NFS client doesn't see it.) For how infrequently this problem generally manifests itself, is there an overall benefit from a debugging standpoint of my leaving intr on and reporting when it happens, including procstat output, and then upgrading to latest kernel … ? Its an annoyance, but it isn't like it happens daily, so I don't mind going through the process *towards* having it fixed if there is an overall benefit … ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why does poudriere always rebuild nginx and GraphicsMagick13?
Hi Baptiste, so I upgraded to 2.3.1 but it still rebuilds those two ports every single time I run a bulk build. … Options changed, deleting: GraphicsMagick-nox11-1.3.16_1.txz Options changed, deleting: nginx-1.2.6,1.txz ... drwxr-xr-x 2 root wheel 512 Dec 21 09:20 GraphicsMagick/ drwxr-xr-x 2 root wheel 512 Dec 21 09:20 GraphicsMagick13/ drwxr-xr-x 2 root wheel 512 Dec 21 09:20 nginx/ Somehow, it thinks the options have changed. Maybe, the options-file has an error? OK, another issue crept up. I started to build www/rt40 and it worked - until I updated it to the latest commit. Now I get: [02] Finished build of www/rt40: Ignored: please select one of AP_MODPERL, AP_MODFASTCGI, LIGHTTPD, SPAWN_FCGI or BUILTIN But I have: cat /usr/local/etc/poudriere.d/91amd64-options/rt40/options # This file is auto-generated by 'make config'. # Options for rt-4.0.10_1 _OPTIONS_READ=rt-4.0.10_1 _FILE_COMPLETE_OPTIONS_LIST=DEV GD GPG GRAPHVIZ SSL_MAILGATE MYSQL ORACLE PGSQL SQLITE AP_MODFASTCGI AP_MODPERL LIGHTTPD SPAWN_FCGI OPTIONS_FILE_UNSET+=DEV OPTIONS_FILE_SET+=GD OPTIONS_FILE_SET+=GPG OPTIONS_FILE_SET+=GRAPHVIZ OPTIONS_FILE_SET+=SSL_MAILGATE OPTIONS_FILE_UNSET+=MYSQL OPTIONS_FILE_UNSET+=ORACLE OPTIONS_FILE_SET+=PGSQL OPTIONS_FILE_UNSET+=SQLITE OPTIONS_FILE_UNSET+=AP_MODFASTCGI OPTIONS_FILE_UNSET+=AP_MODPERL OPTIONS_FILE_UNSET+=LIGHTTPD OPTIONS_FILE_SET+=SPAWN_FCGI If I run make patch in my local ports tree, with the above options file, it runs through. Is this a poudriere problem or more of a problem with the port itself? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why does poudriere always rebuild nginx and GraphicsMagick13?
On Fri, Feb 15, 2013 at 12:37:19AM +0100, Rainer Duffner wrote: Am 12.02.2013 um 23:11 schrieb Baptiste Daroussin b...@freebsd.org: On Tue, Feb 12, 2013 at 10:59:28PM +0100, Rainer Duffner wrote: Hi, poudriere 2.2 here, running on 9.1-amd64 Of the 730-ish ports, whenever I run a build, it always rebuilds the above two ports. Even if nothing changed. Options changed, deleting: GraphicsMagick-nox11-1.3.16_1.txz Options changed, deleting: nginx-1.2.6,1.txz Somehow, it thinks the options have changed. Maybe, the options-file has an error? Regards, Rainer Try deleting the options file for each and run poudriere twice to test. I had the same problem with mailman and it turned out I was missing a required but not enforced option due to another option I had selected. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why does poudriere always rebuild nginx and GraphicsMagick13?
On Thu, Feb 14, 2013 at 08:29:19PM -0500, Adam McDougall wrote:
On Fri, Feb 15, 2013 at 12:37:19AM +0100, Rainer Duffner wrote:
Am 12.02.2013 um 23:11 schrieb Baptiste Daroussin b...@freebsd.org:
On Tue, Feb 12, 2013 at 10:59:28PM +0100, Rainer Duffner wrote:
Hi,
poudriere 2.2 here, running on 9.1-amd64
Of the 730-ish ports, whenever I run a build, it always rebuilds the
above two ports.
Even if nothing changed.
Options changed, deleting: GraphicsMagick-nox11-1.3.16_1.txz
Options changed, deleting: nginx-1.2.6,1.txz
Somehow, it thinks the options have changed.
Maybe, the options-file has an error?
Regards,
Rainer
Try deleting the options file for each and run poudriere twice to test.
I had the same problem with mailman and it turned out I was missing a
required but not enforced option due to another option I had selected.
Note: I have no familiarity with this tool or its code. *sigh* Oh
look, more shell hell... :-)
Here's the code for what causes the Options changed logic to get
called (I did not include pkg_get_options() nor pkg_cache_dir()
definitions, i.e. functions used within src/poudriere.d/common.sh):
1355 # Check if the compiled options match the current options from
make.conf and /var/db/options
1356 if [ ${CHECK_CHANGED_OPTIONS:-no} != no ]; then
1357 current_options=$(injail make -C /usr/ports/${o}
pretty-print-config | tr ' ' '\n' | sed -n 's/^\+\(.*\)/\1/p' | sort | tr '\n'
' ')
1358 compiled_options=$(pkg_get_options ${pkg})
1359
1360 if [ ${compiled_options} != ${current_options} ]; then
1361 msg Options changed, deleting: ${pkg##*/}
1362 if [ ${CHECK_CHANGED_OPTIONS} = verbose ]; then
1363 msg Pkg: ${compiled_options}
1364 msg New: ${current_options}
1365 fi
1366 delete_pkg ${pkg}
1367 return 0
1368 fi
1369 fi
Note what the comment says. I have no idea what /var/db/options is, but
possibly it's referring to /var/db/ports/*/options.
You might try setting CHECK_CHANGED_OPTIONS=verbose (wherever it gets
that from). It should print something helpful to you which you can use
to work backwards.
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| 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 freebsd-stable-unsubscr...@freebsd.org
Re: 9-STABLE - NFS - NetAPP:
Marc Fournier wrote:
On 2013-02-13, at 3:54 PM, Rick Macklem rmack...@uoguelph.ca wrote:
The pid that is in T state for the ps auxlH.
Different server, last kernel update on Jan 22nd, https process this
time instead of du last time.
I've attached:
ps auxlH
ps auxlH of just the processes that are in TJ state (6 httpd servers)
procstat output for each of the 6 process
They are included as attachments … if these don't make it through, let
me know, just figured I'd try and keep it compact ...
Well, I've looked at this call path a little closer:
16693 104135 httpd-mi_switch+0x186
thread_suspend_check+0x19f sleepq_catch_signals+0x1c5
sleepq_timedwait_sig+0x19 _sleep+0x2ca clnt_vc_call+0x763
clnt_reconnect_call+0xfb newnfs_request+0xadb
nfscl_request+0x72 nfsrpc_accessrpc+0x1df nfs34_access_otw+0x56
nfs_access+0x306 vn_open_cred+0x5a8
kern_openat+0x20a amd64_syscall+0x540 Xfast_syscall+0xf7
I am probably way off, since I am not familiar with this stuff, but it
seems to me that thread_suspend_check() should just return 0 for the
case where stop_allowed == SIG_STOP_NOT_ALLOWED (TDF_SBDRY flag set)
instead of sitting in the loop and doing a mi_switch(). I'm not even
sure if it should call thread_suspend_check() for this case, but there
are cases in thread_suspend_check() that I don't understand.
Although I don't really understand thread_suspend_check(), I've attached
a simple patch that might be a starting point for fixing this?
I wouldn't recommend trying the patch until kib and/or jhb weigh in
on whether it makes any sense.
rick
--- kern/subr_sleepqueue.c.sav 2013-02-14 20:39:47.0 -0500
+++ kern/subr_sleepqueue.c 2013-02-14 21:03:03.0 -0500
@@ -443,7 +443,7 @@ sleepq_catch_signals(void *wchan, int pr
sig = cursig(td, stop_allowed);
if (sig == 0) {
mtx_unlock(ps-ps_mtx);
- ret = thread_suspend_check(1);
+ ret = thread_suspend_check(1, stop_allowed);
MPASS(ret == 0 || ret == EINTR || ret == ERESTART);
} else {
if (SIGISMEMBER(ps-ps_sigintr, sig))
--- kern/kern_exit.c.sav 2013-02-14 21:04:21.0 -0500
+++ kern/kern_exit.c 2013-02-14 21:04:50.0 -0500
@@ -159,7 +159,7 @@ exit1(struct thread *td, int rv)
* First check if some other thread got here before us.
* If so, act appropriately: exit or suspend.
*/
- thread_suspend_check(0);
+ thread_suspend_check(0, SIG_STOP_ALLOWED);
/*
* Kill off the other threads. This requires
--- kern/kern_sig.c.sav 2013-02-14 21:05:06.0 -0500
+++ kern/kern_sig.c 2013-02-14 21:05:40.0 -0500
@@ -1463,7 +1463,7 @@ kern_sigsuspend(struct thread *td, sigse
while (msleep(p-p_sigacts, p-p_mtx, PPAUSE|PCATCH, pause,
0) == 0)
/* void */;
- thread_suspend_check(0);
+ thread_suspend_check(0, SIG_STOP_ALLOWED);
mtx_lock(p-p_sigacts-ps_mtx);
while ((sig = cursig(td, SIG_STOP_ALLOWED)) != 0)
has_sig += postsig(sig);
--- kern/kern_thread.c.sav 2013-02-14 21:07:06.0 -0500
+++ kern/kern_thread.c 2013-02-14 21:44:10.0 -0500
@@ -762,7 +762,7 @@ stopme:
* return_instead is set.
*/
int
-thread_suspend_check(int return_instead)
+thread_suspend_check(int return_instead, int stop_allowed)
{
struct thread *td;
struct proc *p;
@@ -794,6 +794,9 @@ thread_suspend_check(int return_instead)
(p-p_flag P_SINGLE_BOUNDARY) return_instead)
return (ERESTART);
+ if (stop_allowed == SIG_STOP_NOT_ALLOWED return_instead)
+ return (0);
+
/*
* If the process is waiting for us to exit,
* this thread should just suicide.
--- kern/subr_trap.c.sav 2013-02-14 21:09:43.0 -0500
+++ kern/subr_trap.c 2013-02-14 21:10:02.0 -0500
@@ -283,7 +283,7 @@ ast(struct trapframe *framep)
*/
if (flags TDF_NEEDSUSPCHK) {
PROC_LOCK(p);
- thread_suspend_check(0);
+ thread_suspend_check(0, SIG_STOP_ALLOWED);
PROC_UNLOCK(p);
}
--- sys/proc.h.sav 2013-02-14 21:10:58.0 -0500
+++ sys/proc.h 2013-02-14 21:12:01.0 -0500
@@ -943,7 +943,7 @@ void thread_stopped(struct proc *p);
void childproc_stopped(struct proc *child, int reason);
void childproc_continued(struct proc *child);
void childproc_exited(struct proc *child);
-int thread_suspend_check(int how);
+int thread_suspend_check(int how, int stop_allowed);
void thread_suspend_switch(struct thread *);
void thread_suspend_one(struct thread *td);
void thread_unlink(struct thread *td);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9-STABLE - NFS - NetAPP:
Marc Fournier wrote: On 2013-02-14, at 16:24 , Rick Macklem rmack...@uoguelph.ca wrote: Marc Fournier wrote: On 2013-02-14, at 08:41 , Rick Macklem rmack...@uoguelph.ca wrote: Btw Marc, if you just want this problem to go away, I suspect getting rid of the intr mount option would do that. Am more interested in fixing the problem (if possible) then just masking it, but ... Based on the man page for mount_nfs, wouldn't that have the opposite effect: intr Make the mount interruptible, which implies that file system calls that are delayed due to an unresponsive server will fail with EINTR when a termination signal is posted for the process. I may be mis-reading, but from the above it sounds like a -9 *should* terminate the process if intr is enabled, while with it disabled, it would ignore it … ? Yes, you have misread it (or english is a wonderfully ambiguous thing, if you prefer;-). For hard mounts (which is what you get if you don't specify either soft nor intr), the RPCs behave like other I/O subsystems, which means they do non-interruptible sleeps (D stat in ps) waiting for server replies and continue to try and complete the RPC forever. You can't kill off the process/thread with any signal. If umount -f of the filesystem works, that terminates the thread(s). Unfortunately, umount -f is quite broken again. I have an idea on how to resolve this, but I haven't coded it yet. (The problem is that the process doing umount -f gets stuck before it does the VFS_UNMOUNT(), so the NFS client doesn't see it.) For how infrequently this problem generally manifests itself, is there an overall benefit from a debugging standpoint of my leaving intr on and reporting when it happens, including procstat output, and then upgrading to latest kernel … ? Its an annoyance, but it isn't like it happens daily, so I don't mind going through the process *towards* having it fixed if there is an overall benefit … Well, hopefully kib and/or jhb can make some progress w.r.t. this. I'll let them weigh in on what to do next, rick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why does poudriere always rebuild nginx and GraphicsMagick13?
On 15/02/2013 01:27, Rainer Duffner wrote: OK, another issue crept up. I started to build www/rt40 and it worked - until I updated it to the latest commit. Now I get: [02] Finished build of www/rt40: Ignored: please select one of AP_MODPERL, AP_MODFASTCGI, LIGHTTPD, SPAWN_FCGI or BUILTIN But I have: cat /usr/local/etc/poudriere.d/91amd64-options/rt40/options # This file is auto-generated by 'make config'. # Options for rt-4.0.10_1 _OPTIONS_READ=rt-4.0.10_1 _FILE_COMPLETE_OPTIONS_LIST=DEV GD GPG GRAPHVIZ SSL_MAILGATE MYSQL ORACLE PGSQL SQLITE AP_MODFASTCGI AP_MODPERL LIGHTTPD SPAWN_FCGI OPTIONS_FILE_UNSET+=DEV OPTIONS_FILE_SET+=GD OPTIONS_FILE_SET+=GPG OPTIONS_FILE_SET+=GRAPHVIZ OPTIONS_FILE_SET+=SSL_MAILGATE OPTIONS_FILE_UNSET+=MYSQL OPTIONS_FILE_UNSET+=ORACLE OPTIONS_FILE_SET+=PGSQL OPTIONS_FILE_UNSET+=SQLITE OPTIONS_FILE_UNSET+=AP_MODFASTCGI OPTIONS_FILE_UNSET+=AP_MODPERL OPTIONS_FILE_UNSET+=LIGHTTPD OPTIONS_FILE_SET+=SPAWN_FCGI If I run make patch in my local ports tree, with the above options file, it runs through. Is this a poudriere problem or more of a problem with the port itself? This part of the rt40 port -- options handling -- hasn't changed for around 6 months. My guess is that you've somehow got a mangled set of options choices somewhere where poudriere sees it. Poudriere can use a separate collection of options -- see the CUSTOMIZATION section in poudriere(8). If you want it to use the same /var/db/ports set of options as used by the ports by default, then you can make a link lie this: % ls -l /usr/local/etc/poudriere.d/options lrwxr-xr-x 1 root wheel 13 Dec 24 15:54 /usr/local/etc/poudriere.d/options@ - /var/db/ports Or else try running: poudriere options www/rt40 to set the options poudriere will use. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
