Re: Unusual TCP/IP Packet Size

[Eugene Grosbein]

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

[Oliver Brandmueller]

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

[Dominic Fandrey]

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

[Harald Schmalzbauer]

 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]

[Harald Schmalzbauer]

 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

[Eugene Grosbein]

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?

[Mikhail T.]

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::WeakImplHelper1::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

[Jeremy Chadwick]

On Wed, Feb 13, 2013 at 11:54:24PM -0800, Doug Hardie wrote:
> 
> On 13 February 2013, at 22:45, YongHyeon PYUN  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  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=8843 metric 0 mtu 
> >> 1500
> >>  
> >> options=c011b
> >>  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=29
> >>  media: Ethernet autoselect (100baseTX 
> >> )
> >>  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 Sy

Re: 9-STABLE -> NFS -> NetAPP:

[Rick Macklem]

Marc Fournier wrote:
> On 2013-02-13, at 3:54 PM, Rick Macklem  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?

[Karl Denninger]

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 ®/ 
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:

[Marc G. Fournier]

On 2013-02-14, at 08:41 , Rick Macklem  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?

[Bill Campbell]

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?

[Karl Denninger]

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 ®/ 
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

[Janusz Bulik]

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

[David Demelier]

Le mardi 12 février 2013 21:42:01 Ronald Klop a écrit :
> On Tue, 12 Feb 2013 19:44:49 +0100, David Demelier
> 
>  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=) 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' 
#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

[Jeremy Chadwick]

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=8843 metric 0 mtu 
> > > > 1500
> > > > 
> > > > options=c011b
> > > > 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=29
> > > > media: Ethernet autoselect (100baseTX 
> > > > )
> > > > 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:1

Re: 9.1-RELEASE AMD64 crash under VBox 4.2.6 when IO APIC is disabled

[John Baldwin]

On Wednesday, February 13, 2013 6:56:06 pm CeDeROM wrote:
> On Wed, Feb 13, 2013 at 4:48 PM, John Baldwin  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?

[Rainer Duffner]

Am 12.02.2013 um 23:11 schrieb Baptiste Daroussin :

> 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

[Rick Macklem]

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:

[Rick Macklem]

Marc Fournier wrote:
> On 2013-02-14, at 08:41 , Rick Macklem  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:

[Marc G. Fournier]

On 2013-02-14, at 16:24 , Rick Macklem  wrote:

> Marc Fournier wrote:
>> On 2013-02-14, at 08:41 , Rick Macklem  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?

[Rainer Duffner]

> 
> 
> 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?

[Adam McDougall]

On Fri, Feb 15, 2013 at 12:37:19AM +0100, Rainer Duffner wrote:
  
  Am 12.02.2013 um 23:11 schrieb Baptiste Daroussin :
  
  > 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?

[Jeremy Chadwick]

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 :
>   
>   > 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:

[Rick Macklem]

Marc Fournier wrote:
> On 2013-02-13, at 3:54 PM, Rick Macklem  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:

[Rick Macklem]

Marc Fournier wrote:
> On 2013-02-14, at 16:24 , Rick Macklem  wrote:
> 
> > Marc Fournier wrote:
> >> On 2013-02-14, at 08:41 , Rick Macklem 
> >> 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?

[Matthew Seaman]

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